IRC channel logs


back to list of logs

<nckx>I got that scary-lookin' thing twice whilst I was somewhere in the process of testing & switching to c-u-f. It hasn't occured since I completed that, and I assumed it was some ABI mismatch $somewhere.
<nckx>Are you in such a situation, roptat?
<nckx>I can't say what ‘fixed’ it (maybe nothing!) but enough cleaning & re-making & pulling eventually got me out of it.
<nckx>Oh, I think I also updated guile-gcrypt for good measure, another untested variable :)
<nckx>raspbeguy: You there?
<roptat>nckx, yeah I guess I'll try cleaning stuff
<roptat>I didn't switch to c-u-f, but I suppose the new environment was created from a commit after the merge, while the previous environment I used was from a commit before the merge
<edgarvincent[m]>Hi everyone. Sorry if the answer to this is obvious, but I don't seem to find it in the documentation. Could anyone tell me what the `-L` flag stands for in this `guix pack` invocation: ? Thank you.
<nckx>edgarvincent[m]: I didn't find a direct explanation of Guile load paths in the Guix manual (only references to the Guile manual, which makes sense), but I guess footnote 17 of <> comes closest.
<nckx>But it's really just a Guile concept further exposed by Guix.
<nckx> gives a little less information.
***ChanServ sets mode: +o nckx
***nckx sets mode: +b $a:raspbeguy*$##fix-your-connection
***ChanServ sets mode: -o nckx
<edgarvincent[m]>Oh, I see. Thank you very much indeed nckx.
<nckx>No problem, hope it helped.
<edgarvincent[m]>It certainly did. It's exactly the flag I was looking for, but I'm new to Guix and Guile.
<nckx>Let us know if there's anything missing or unclear in the manual (or linked resources).
<edgarvincent[m]>Thank you. So far, the documentation looks very clear to me, but there's a lot to grasp :)
<roptat>nckx, it worked :)
<nckx>Yay! Thanks for reporting back. For future reference: do you know which part exactly?
<nckx>I wish I'd investigated now, but 🤷
<roptat>nckx, no, I suppose something to do with guile-gcrypt
<roptat>I just "make clean && make"
<jackhill>I seem to not understand something about how to use gexps. I'm trying to use one to wrap a program like so but I've done something wrong and get the inscrutable (to me) error: unbound-variable #f "Unbound variable: ~S" (gexp) #f
<roptat>jackhill, I'm not sure this is the right place to start a gexp
<nckx>Gexp the whole modify-phases expression.
<roptat>also, you'll need (guix gexp)
<nckx>The unbound-variable error is because you're invoking gexp on the build side.
<jackhill>nckx, roptat: very good, thanks! Now I've got with error "no code for module (guix gexp)"
<luis-felipe>nckx, apteryx: Hi, just to confirm that now I can log in to a system configured with the wip branch for a #52051 fix :)
<nckx>jackhill: Remove the #:modules, import it at the top level (i.e., the top of the file).
<nckx>luis-felipe: Sweet.
<luis-felipe>(Although when I log in, GNOME tells me the system can't recover from some error and I must relog in, but that's probably a different thing)
<luis-felipe>(And I get stuck in that loop forever)
*luis-felipe is upgrading his profile to see if that has something to do with it...
<nckx>Is ‘some error’ qualified?
<luis-felipe>nckx: I gotta check, it's just an uninformative dialog box.
<nckx>Yeah, GNOME.
<nckx>I probably won't be able to help either way.
<luis-felipe>No worries
<nckx>But that won't stop me from trying.
<nckx>I was just about to reset the box I can't SSH into to. Let's see how that goes.
<KarlJoad>Quick check, how well does Sway & Wayland work on NVIDIA GPUs in Guix?
<luis-felipe>Profile upgraded flawlessly, rebooted, and the GNOME issue is gone.
<nckx>Sweet II.
***lukedashjr is now known as luke-jr
<jackhill>nckx: did that, and now I'm on to:
<nckx>Did what?
<nckx>Please paste your evil offending code.
<jackhill>put '#:use-module (guix gexp)' at the top level, and removed #:modules from arguments. Now the whole package definition is
<nckx>jackhill: You're still evaluating gexp ‘build-side’ because of the '(#:tests? quote.
<nckx>Use (list #:tests?
<nckx>#~(list (string-append "CC=" #$(cc-for-target)) accordingly.
<nckx>At a glance (didn't test) you should be good to go then…
<nckx>Oh, and %output → #$output
<jackhill>nckx: do I have to move the gexp call up to surrount the arments list as well? I think I've gotten myself really turned around here. Neither "error: ungexp: unbound variable" or "In procedure apply: Apply to non-list:…" (full error if needed) are happy
<nckx>#~(list #:tests? is definitely wrong
<nckx>(list #:tests? is correct! But is missing the #~ after #:configure-flags.
<nckx>Sorry, my bad, #:make-flags.
<jackhill>doh, of course!
<nckx>(See snippet above with ‘gcc’ in it.)
<jackhill>nckx: thanks for your patient help. I have a building package now. Next is to see if it helped with my theory :)
<nckx>I forgot what that was… 😛
<nckx>Happy to help, and I promise this will become as natural (and IMO, *more* natural/fun) as quotes soon.
<jackhill>I'm trying out ideas for having webkitgtk browsers find what they want of gstreamer plugins so folks won't have to install them seperatly
<nckx>Glad to hear that; not a fan of the suggested propagation &c.
<nckx>Of all of -bad, I mean.
<nckx>I don't like that webkitgtk upstream is strong-arming distroes into ignoring gstreamer upstream's own assessment of this junk.
<jackhill>It is nice taht we have the gst-plugins/selection proc. things like webrtc is in -bad so I see why they want it. I just, yeah, wish the web weren't so terrible and that wich plugins they want were better documented.
<nckx>Right, I don't mean leave webkitgtk broken, just give it the minimum it needs. Seems like that's exactly your plan. Great.
<jackhill>yep indeed.
<jackhill>Speaking of gst-plugins/selection, its docstring says "… Optionally, if CONFIGURE-FLAGS are given …", but it's defined as "lambda* (pkg #:key plugins configure-flags)" so something must be passed as configure-flags. I gave the empty list above, but perhaps that could be improved 🤔
<nckx>Oops yes.
<nckx>Almost certainly a bug/oversight.
<nckx>Would it be too much trouble to ask you for a simple patch?
<nckx>I am, and especially should be, working.
<jackhill>sure, fortunately it's only used by pitivi currently and that passes #:configure-flags
<nckx>This is triggering extreme déjà vu, and yet I don't think I dealt with gstreamer lately. Must have been something very similar. Probably not the last such subtle bug with only 1 user waiting to be exposed.
<nckx>Thanks jackhill.
<jackhill>I'm still suspicious of the ",@(or configure-flags flags)" in the body of the procedure, but it woks for pitivi and my experiment now, so yay?
<jackhill>or rather, I'm suspicious of the ",@(or configure-flags '())" the other one seems ok
<lfam>Light at the end of the tunnel of #52051: <>
<apteryx>lfam: yes :-)
<rekado>nckx: I restarted mumi when it wouldn’t update any more.
<podiki[m]>are there some package I can look at for synopsis/description for autogenerated packages? meaning packages that are just some language's bindings to an ffi or such
<podiki[m]>(I have the huge Haskell gobject introspection packages I want to polish to submit patches for, but it is like 1300 lines of packages)
<rekado>podiki[m]: most of the R packages are generated, but I still fix up the synopsis and description.
<lilyp>some rust GTK bindings are too
<lilyp>at least last I checked
<podiki[m]>thanks, maybe I'll look at the rust gtk bindings as that sounds similar
<podiki[m]>I was also thinking this would make sense for a new module, haskell-gi (the name of the main package that generates all the bindings)
***ChanServ sets mode: +o litharge
***litharge sets mode: +b $a:epony
***epony was kicked by litharge (You are banned from this channel (by nckx))
***litharge sets mode: -o litharge
***ChanServ sets mode: +o nckx
***nckx sets mode: -b $a:raspbeguy*$##fix-your-connection
***nckx sets mode: +b $a:raspbeguy*$#guix-fix-your-connection
***nckx sets mode: -b $a:betelgeus*$##fix-your-connection
***nckx sets mode: +b $a:betelgeus*$#guix-fix-your-connection
***ChanServ sets mode: -o nckx
<lilyp>probably no, unless it gets too unmanageable in whatever module it currently is
<podiki[m]>these packages don't exist in guix currently
<podiki[m]>was thinking since they all will be upgraded together and are autogenerated packages (library bindings)
<podiki[m]>(or maybe broaden to haskell-gtk)
<lilyp>we still tend to go for larger things like rust-graphics :)
*lilyp off to work
<podiki[m]>have a good day!
*podiki[m] off to bed
<apteryx>night, podiki[m] !
<apteryx>python2 packages are expensive to keep working... let's get rid of it soon
***lukedashjr is now known as luke-jr
<jackhill>nckx, apteryx: progress, I've determined that the minium plugin from gst-plugins-bad needed to solve my tab crashing problem is debuguitls. Next: clean up my proof of concept and start a conversation on guix-devel@. For now though, sleep!
<nckx>(utils or uitls?)
<nckx>That's some nice work, thanks again.
<nckx>And good night :)
<AIM[m]>How do I get a list of installed packages to stdout?
<nckx>guix package -I
<antlers>And on GuixSD you can see the system package-set too, by pointing it at the system profile: `--profile=/run/current-system/profile`
<nckx>Goode pointe.
<mekeor[m]>hi guix. how can i tell "guix upgrade" to only upgrade packages with substitutes?
<nckx>Not to one-up that, but you can extend that to ‘all users' packages’ by looping over all $HOME/.guix-profile.
<nckx>mekeor[m]: There is no built-in way to do so.
<nckx>One approach is to, assuming you use a manifest: pull, then wait until guix weather -m FILE returns an acceptable number, then upgrade.
<mekeor[m]>nckx: "guix upgrade" fails for me with a memory allocation error (while building rust analyzer). no chance for me to upgrade at the moment?
<nckx>Or, if that isn't ugly^Wgranular enough for you, you could consider looping over
<nckx>guix package -I | cut -f1-3 | sed -E -e 's/[[:space:]]+/@/' -e 's/[[:space:]]+/:/'
<tissevert>hi guix
<nckx>and doing unspeakable things to the output, like checking the weather and installing it if it contains the string "100%".
<mekeor[m]>yeah i was considering that too, thx nckx
<nckx>There is probably a better way, I'm just riffing.
<nckx>Hi tissevert (and, belatedly, mekeor[m]).
<tissevert>o/ nckx
<nckx>mekeor[m]: Are you building with --cores=1 already?
<antlers>Can you not approach it like forcing offloading with --max-jobs=0?
<tissevert>I had to reconfigure my system from root yesterday because I forgot to add the nss-certs in the original configuration
<nckx>Talk me through it, antlers.
<nckx>I'm not seeing it.
<tissevert>and then guix wouldn't let me reconfigure as my normal user
<tissevert>so I had to guix pull and all, I suppose it's messy since guix shouldn't be used from root
<tissevert>can I clean up the mess in /root ? like, everything ? or isn't that safe ?
<nckx>That sounds familiar, did you mention that previously? Otherwise someone had the same issue or was concerned about it.
<tissevert>me ?
<tissevert>in any case no it's the first time it happens
<nckx>What's the mess? It should be limited to .config/guix, .cache/guix, .guix-profile. Then the dead symlinks in /var/guix/gcroots should be collected by the GC next it runs.
<antlers>I'm probably just confused, it's frankly time for bed :p
<antlers>Thx for being here and being so helpful for everyone
<tissevert>I usually let the installer write my config but since it wasn't working on that particular box I was installing, I wrote the config and forgot it
<tissevert>root also got a .bashrc and .bash_profile
<nckx>I wanted to search the logs, but search is broken. Someone definitely mentioned ‘forgot nss-certs, now guix broke, how fix’. I don't remember the details though.
<tissevert>and a .gdbinit
<nckx>They existed before you used guix as root.
<tissevert>sounds vaguely familiar, I may have seen it and thought that would never happen to me
<nckx>You're free to delete them (it's your system) but they are not ‘mess’ in the sense you used above.
<nckx>I'd leave them if unsure.
<tissevert>is there a recommended way out of this instead of running as root should the case occur again
<nckx>antlers: Good night!
<tissevert>well I am unsure and they're not eating up a lotta space, so, yeah, I suppose I'll leave them
<tissevert>thanks for the advice
<nckx>They were there from the first boot, if it's any consolation. I have them too; never guixed as root.
<nckx>You might want them some day.
<tissevert>ohh, I see
<tissevert>all the more reasons to leave them then
<tissevert>you're right, I still have to fix the fonts
<tissevert>thanks for the reminder
<tissevert>and I still get weird graphical glitches when switching between Qt windows
<mothacehe>hey guix!
<eyJhb>Morning mothacehe !
<eyJhb>Day two of trying to install Guix :p
<mekeor[m]>nckx: btw, there's also guix package --list-installed
<mothacehe>nice dedication eyJhb ;)
<nckx>mekeor[m]: -I is shorter.
<tissevert>eyJhb: good luck !
<nckx>Good luck eyJhb.
<tissevert>ah, it's better with a font
<mekeor[m]>nckx: no its not the same
<tissevert>: )
<eyJhb>Want to see what it's all about, currently running NixOS. So I guess it's only reasonable to check out the other alternatives :P
<nckx>mekeor[m]: ?
<nckx>It really is.
<mekeor[m]>nckx: -l is --list-generations
<nckx>I, not l.
<mekeor[m]>ah haha ok xD sry
<mekeor[m]>bad font here
<tissevert>always a matter of font
<nckx>Found the proportional font user 😉
<tissevert>: )
<tissevert>btw any font recommended with a decent UTF-8 coverage ?
<nckx>(No judgment, I also use proportional fonts — oh noes the IRC ascii arts — but at least I and l ar different.)
<nckx>tissevert: font-google-noto is 1.5 GiB of ridiculous coverage.
<nckx>It's a bit outdated but otherwise the most complete we have.
<tissevert>yeah it looks huge but doing the job
<tissevert>it still lacks a glyph for the ball of yarn though 🧶
<nckx>I tried splitting it into :ttf (‘only’ ~350MiB IIRC) and :otf but it doesn't seem to work.
<nckx>tissevert: That's what I mean by ‘outdated’.
<tissevert>: )
<tissevert>I see
<nckx>The latest ‘Apple M1 user yeeting at COVID’ emojis are not included.
<tissevert>I'm pretty sure I got that yarn to display but I can't remember what font was used
<nckx>Let me know if you find out.
<tissevert>meanwhile, some actual languages used by actual people on earth, and a good proportion of them, still lack glyphs for their languages… : S
<mekeor[m]>how can i list all dependencies of a package per cli?
<tissevert>aren't they in guix search's output ?
<mekeor[m]>tissevert: spoken languages are valid too. are you shaming them?
<mekeor[m]>tissevert: ah right, direct deps are listed. thanks. i guess thats enough for me
<tissevert>hmmm not sure what you mean
<tissevert>do you need their transitive closure ?
<eyJhb>Finally got it installed. Now I just need to update it :)
<tissevert>great ! congrats : )
<tissevert>my install (from yesterday) is still far from being ok
<tissevert>I've got this weird "vesa"-ish feel in i3 and Qt windows
<tissevert>like the characters are huge even though the font size looks ok
<tissevert>and I have this random glitches on the windows when they open before I move the cursor inside them
<mothacehe>eyJhb: with the graphical installer?
<mothacehe>congrats anyway :)
<tissevert>the resolution is better in my tty windows that in qterminal's ^^
<nckx>KMScon is crisp.
<efraim>hello guix!
<mothacehe>hey efraim!
<nckx>tissevert: Might be
<nckx>Hi efraim.
<tissevert>would that mean that chromium can somehow ignore X's dpi ??
<nckx>It wouldn't surprise me if they did.
<nckx>I'm sure they reimplement a lot of layers on top of X/Waytever themselves.
<tissevert>which is bad : (
<tissevert>the font inside regular web pages is smaller that the title of my i3 windows (default config: pango monospace size 8) ^^
<ss2>fonts are smaller thanks to xorg'r recent update? My fix: ‘xrander --dpi 96’
<nckx>I thought they were bigger.
<ss2>which isn't actually, it just forces a dpi and maybe your usually font size.
<tissevert>yeah, I found that 96 was the appropriate parameter
<tissevert>at least everything looks normal again
<tissevert>and yeah, they were bigger
<nckx>ss2: ‘Isn't actually’? As in, bug?
<tissevert>so I wonder when I should run it
<tissevert>(also, gdm is entirely unaffected by the issue…)
<ss2>I concluded many years that this is no bug, only a way to force a fontsize over a screen you want to have.
<tissevert>I wonder if it's a job for .xsession
<ss2>And this upgrade doesn't affect my laptop, which has a small screen, but does on my slightly bigger screen (they have a slightly higher dpi), so the fonts wen't smaller.
<tissevert>or if I should have a lxsession task for that or if that would come too late
<ss2>went, I've got to fix my grammer somehow.. -.-
<ss2>damn, grammar!
<ss2>sorry, good morning everyone.
<tissevert>good morning ss2 : )
<jpoiret>yeah, many programs/toolkits actually ignore X's dpi
<ss2>more than you'd think. The DEs themselves know how to override the defaults anyway, and they come with their own concept of doing things.
<tissevert>it's sad…
<ss2>just read the length and references to other problems alone to get fonts configured:
<tissevert>so anyway I simply reused .xsession and everything is fine again
<tissevert>what a nightmare ^^
<tissevert>thanks for the help !
<tissevert>strangely (!) that got rid of the weird glitches too ?
<tissevert>so I suppose the 142 DPI used by default didn't please my hardware somehow
<ss2>fonts, and especially font rendering is an art form that has been around since the dawn of computer systems "trying" to render fonts.
<jpoiret>the issue is that in the end, it's up to each client to render the fonts properly, there's no way to enforce some specific font rendering system-wide
<jpoiret>unless they all conform to a specification
<ss2>that's right. And there is no one specification.
<tissevert>wait, people should just make a new specification to unify them and… ^^
<jpoiret>xdg-font-rendering when?
<tissevert>found it !
<tissevert>nckx: it was font-gnu-unifont
<tissevert>and font-openmoji provides it too, it looks a bit better though still black and white
<phf-1>Hello Guix! I've just installed Guix on a foreign distro. I keep having this message when running Guix: even if I installed the necessary packages: and configured my environment: What did I do wrong? Thank you.
<nckx>tissevert: GNU Unifont is great but it's a bitmap font.
<nckx>Not very 2022 in 2022.
<tissevert>yeah I know : )
<nckx>Thanks for the tips!
<tissevert>it has the glyphs though
<nckx>I'd forgot about openmoji.
<nckx>tissevert: Are they discernible?
<nckx>Legibility was my only issue with it when I tried it, otherwise it's a great project.
<nckx>Giving GRUB impressive i18n capabilities for a boot loader etc.
<jpoiret>phf-1: if you `echo $GUIX_LOCPATH` in the shell that just printed out the warning, does it echo the right path?
<jpoiret>it might be that you put all of that in your .bash_profile (or equivalent) and didn't logout->login again
<tissevert>I don't really know, I don't know enough about fonts
<phf-1>jpoiret: Thank you for the reply. `$ echo $GUIX_LOCPATH => $HOME/.guix-profile/lib/locale'
<phf-1>so it looks good to me: I sourced the env and `systemctl restart guix-daemon.service'
<phf-1>it's in the .bashrc for now
<phf-1>maybe that's the problem? it should be in `.bash_profile' ?
<jpoiret>GUIX_LOCPATH isn't something that guix-daemon should have to worry about
<jpoiret>generally, env vars should be set inside the .profile file, otherwise you run the risk of setting them twice in specific cases
<jpoiret>exemple: you login from a vt, it sets them once, then you start whatever compositor you want and start a terminal with a shell in it, setting them a second time
<nckx>I'm a bit surprised that (guix)Application Setup doesn't mention that fact. OK, ‘we’ know this, and it's technically not our job (isn't it though?) but it's quite arcane unix lore.
<jpoiret>is $HOME actually your /home/<> dir or is it literally $HOME?
<nckx>s/job/& to document unix/
<phf-1>It's my home dir
<nckx>Here it just feels unhelpful not to say what ‘set’ means in practice.
<phf-1>not literally $HOME
<phf-1>yes for the .bash_profile/.bashrc distinction. This machine is just... very old.
<jpoiret>and if you `ls $GUIX_LOCPATH`, it's not an empty directory, right?
<jpoiret>tbh i've never had these problems since I run guix system, but these are the easiest troubleshooting steps teehee
<jpoiret>nckx: thanks for pushing the patch by the way
<phf-1>ls $GUIX_LOCPATH gives 2.33
<nckx>Uhhh whatever that was, you're welcome.
<eyJhb>mothacehe: Graphical installer doesn't work on stable, but it works on the latest you linked, BUT in that one it can't build some drv. So I ended up with using the stable, and instead not using the graphical installer
***nckx is now known as nckxmas
<jpoiret>eyJhb: do you know which derivation it wasn't able to build?
<phf-1>jpoiret: I've added the env variables to `.bash_profile' and still:
<phf-1>and logged out/in of course
<mothacehe>jpoiret: i guess the latest installer points to guix-1.3.0-15.f98edfa that had a test failure
<mothacehe>we would need to update guix again
<mothacehe>because the installer point to the N-1 guix package
<jpoiret>how? In `gnu/installer/final.scm` I only see a `run-command` invocation with a usual `guix system init ...`
<mothacehe>yes but that guix is current-guix from (gnu guix package-management)
<zamfofex>Hello, Guix! I have recently been reading about Mes and bootstrapping, and it felt really interesting to me! I spent some time thinking, and I came up with an approach for boostrapping Guix using a minimal set of binaries and an existing operating system installation. No code yet, but I wrote my idea in a GitHub Gist and I wanted to be able to know what y’all might think about it, and whether it seems sensible or not.
<zamfofex>This is the Gist I mentioned:
<zamfofex>(Any kinds of thoughts would be really appreciated!)
<nckxmas>Thanks zamfofex! #bootstrappable might be interested in this as well (I think… I can't always gauge their reaction to things).
<zamfofex>I might try to ask there, but I feel like I’m always frightened of joining new communities! 😬
<janneke>zamfofex: yes, i think what you writes makes (some) sense, it would be nice to create a next step that can do things like that, mainly: run bits of gash and guix on mes
<nckxmas>Sure, no presh.
<janneke>the former, running gash on mes will be worked on the coming year by samplet and myself (hopefully)
<zamfofex>janneke: What parts do you feel like don’t make sense? And could I be able to help with it somehow?
<attila_lendvai>mothacehe, thanks for applying the test cleanup patch. while you're rolling, you may consider this, too: (smarten up git testing machinery)
<janneke>zamfofex: i do not see things that do not make sense, it's just that i cannot predict how things will go
<mothacehe>attila_lendvai: sure, at first glance the gnupg part should probably be extracted in a dedicated commit
<attila_lendvai>mothacehe, ok, i'll look into splitting it later today
<janneke>zamfofex: the thing is, in the very next step we will still use guile+gash and guile+guix, but remove the mes binary seed; in the next steps as you lay them out, the mes binary is re-introduced but now as a replacement for guile
<phf-1>Is there a way to debug what the command `guix' is doing to reach this message ( ?
<janneke>that makes sense, but it's an interesting puzzle
<rekado>phf-1: you need to have the locales available in the daemon’s environment and in the current environment.
<zamfofex>janneke: I feel like it makes more sense to use Mes rather than Guile because it is a simpler project, and thus its binary is (supposedly) smaller.
<phf-1>that looks like a good idea!!
<phf-1>will try
<janneke>zamfofex: i agree
<jpoiret>mothacehe: well, i still don't see where the installer gets its N-1 guix from. If you fix this, could you ping me with the commit, so that I can understand it better?
<phf-1>rekado: The guix service is:
<phf-1>A GUIX_LOCPATH is actually defined there. ll $GUIX_LOCPATH gives 2.31 which is different from the 2.33 of the `phf' user.
<mothacehe>jpoiret: if you run qemu on the latest installation image, and run "guix build guix" you will see that it tries to build the 15 guix revision. That's because the guix package 16 is a snaphsot of guix that embeds the guix 15 revision. So when running guix init ..., you are using the 16th revision to install the 15th
<phf-1>But still, the locals seems to be accessible for the daemon
<phf-1>*But still, the locales seem to be accessible to the daemon.
<mothacehe>which means that when the guix package is broken it needs to be updated twice, which sucks
<jpoiret>oh! i get it. that's a quirk if i've ever seen one :)
<mothacehe>hehe yeah quite terrible. The installer tests use current-guix to work around that and install the checkouted guix
<attila_lendvai>[git] i can't seem to find the answer anywhere: how can i do the equivalent of this (which doesn't work): git send-email 4a9e702a86..8f7ffdf36a, or any other way to specify a range of commits that are below the HEAD
<nckxmas>attila_lendvai: *If* it's the same as format-patch: -NUMBER NEWEST-COMMIT
<attila_lendvai>nckxmas, unfortunately that is rejected by sent-email
*attila_lendvai double checks
<phf-1>rekado: "$ strace guix" shows that it cannot find locales for 2.33 of glibc: (I've done a `$ sudo guix pull') in the hope to update the root version of guix. Then, locales should be updated to 2.33.
<nckxmas>attila_lendvai: Works here.
<attila_lendvai>nckxmas, scratch that, it works indeed. (i was in the wrong directory) thanks!
<rekado>phf-1: have you installed glibc-locales and set GUIX_LOCPATH?
<phf-1>rekado: yes.
<attila_lendvai>mothacehe, FYI, i've resent the test framework stuff as two commits (
<phf-1>rekado: That's confusing...
<attila_lendvai>[debbugs] i've sent a mail to #52600 on monday (when there was the outage), but it's still not showing at
<nckxmas>attila_lendvai: It's not at either, and there's nothing stuck in moderation. Just re-send it.
<nckxmas>We can't easily investigate what happened on the GNU side.
<nckxmas>It's not related to the outage; totally separate infra.
<attila_lendvai>ok, will do, thanks!
<nckxmas>Thank you!
<phf-1>rekado: any idea ?
<phf-1>How to explain this?
<jpoiret>is the very file it's trying to access there?
<nckxmas>phf-1: We don't ship the Debian ‘C’ locale.
<nckxmas>Try with your locale set to e.g. en_US.
<phf-1>Will try this thanks!
<phf-1>jpoiret: no, it's not. I thought it should have been.
<phf-1>since locales were installed
<phf-1>since it's expected c.f. nckxmas, then changing my locales en_US should to the trick
<nckxmas>s/C/C.UTF8/, of course we ‘ship’ the C locale in every programme 😉
<nckxmas>C.UTF-8 is… I'm not sure if it's controversial or just non-standard, but it's not in our glibc.
<jpoiret>it's non-standard iirc
<jpoiret>there are plans to add it upstream
<nckxmas>Definitely that.
<phf-1>ok thanks!
<nckxmas>Oh, OK.
<phf-1>will try
<nckxmas>So not (that) controversial then.
<phf-1>It worked !!
<jpoiret> is the upstream issue
<phf-1>as in
<nckxmas>Thanks for the background jpoiret.
<phf-1>Thank you!
<tissevert>that's it I finally got a satisfying guix install on one of my computers
<tissevert>nothing can stop me now : )
<nckxmas>Great! Note that C is pretty Spartan compared to the (extant) .utf8 locales.
<phf-1>What would you recommend instead?
<nckxmas>Great! Note that Guix is pretty addictive and a gateway drug to using Guile in front of friends.
<the_tubular>nckxmas sorry, reading old logs, what are proportional font ?
<the_tubular>I mean can they print character that looks the same in other fonts ?
<nckxmas>phf-1: [your_language].utf8, in general, but C is not ‘wrong’ either.
<phf-1>Ok thanks, LC_ALL=en_US.utf8 and LANGUAGE=en_US.ut8 should suffice then.
<nckxmas>the_tubular: The opposite of monospace. It's not directly related, of course, but *in practice* techy monospace fonts put more emphasis on unique glyph shapes like I and l than many proportional fonts used for prose where it's less important.
<nckxmas>Morning civodul.
<civodul>rekado: i've restarted mumi, which was apparently stuck in an infinite loop or something, with things like this in the log: Throw to key `match-error' with args `("match" "no matching pattern" (HEAD "52051"))'.
<civodul>hey nckxmas :-) ⛄
*nckxmas steals that emoji.
<nckxmas>civodul: Before I forget: how do you substitute-keyword-arguments a gexpificated package? Couldn't get it to work.
<civodul>nckxmas: same as before!
<civodul>lemme see if i can find an example
<jpoiret>the official name is `en_US.UTF-8` though. using `utf8` can lead to some issues
<nckxmas>Please, because that answer confuses me :)
<nckxmas>jpoiret: And I thought it was the exact opposite.
<jpoiret>i myself search on the internet every single time
<nckxmas>utf8 being the ‘normalised’ one.
<civodul>nckxmas: you can look at petsc-{complex,openmpi} for instance
<nckxmas>But I'm sure this area is fraught with competing ‘standards’.
<nckxmas>I was positutely positive that I tried exactly what petsc-openmpi is doing here.
<nckxmas>Let me retry.
<nckxmas>Thanks for the pointer!
<nckxmas>civodul: FMI, are there any existing packages that *can't* be rewritten as gexps at this time?
<nckxmas>Just wondering how ‘complete’ the illusion is.
<civodul>normally no
<civodul>plus i mean you can always keep refering to the input alist on the build side
<civodul>but rekado found a case in Java packages where we refer to implicit inputs by label (for "jdk")
<civodul>that one cannot be translated to (this-package-input "jdk")
<civodul>but maybe that's not a problem, dunno
<nckxmas>I defaulted to that in a (local) package because I don't think what I wrote could be sanely done without labels, but I'm pretty sure a rewrite will solve that, it's not a fundamental issue.
<civodul>but i'm interested in seeing things that are not easily translatable
<nckxmas>-builder:1:6417: Unknown # object: "#<"
<nckxmas>I must be missing something…
<nckxmas>(That's when the builder contains #<gexp oops nope nono> as I'm sure you know.)
<nckxmas>OK! Fixed it, I was fixated on the wrong bit :)
*nckxmas feels like there's a story-of-my-life joke waiting to be made, but would rather not, and goes to work. Thanks again!
<mroh>is there a way to get --skip-tests to the target host on guix deploy?
<civodul>mroh: to skip tests of a package? nope
<mroh>sorry, I mean --skip-checks for reconfigure, not --skip-tests
<eyJhb>jpoiret: I did not take notice, sorry. I should have.
<jpoiret>no problem
<civodul>mroh: ah, maybe not hmm
<civodul>yeah we should fix it
<florhizome[m]>Anybody else been having emacs freezes when running guix.el commands?
<florhizome[m]>since roughly a week or so
<mroh>civodul: that would be cool! I'm building a kernel for one machine that need's --skip-checks, but can't deploy it because of this (deploy has no --skip-checks).
<civodul>mroh: could you open a bug report so we don't forget?
<mroh>ok, will do.
<attila_lendvai>florhizome[m], i've seen freezes recently, but my emacs config is a mess currently.
<awb99>I am having troubles in creating a shephed service.
<awb99>Essentially I want to run "clj -X:goldly-docs" in a specific directory.
<awb99>I have written this service
<awb99>it seems to start it,
<awb99>but herd is stopping it immediately
<awb99>unfortunately I cannot find out what goes wrong.
<civodul>rekado, nckxmas, mothacehe, cbaines: i'd like to reconfigure berlin and bayfront now that i've managed to bundle as a single service type
<eyJhb>Is it normal that `guix system reconfigure` takes a _long_ time for just adding ie. ssh networking module? Like, 10 minutes?
<civodul>eyJhb: it depends on what you did; if you pulled right before, then it'll not just add your ssh service, but also update the whole system
<eyJhb>I did nothing besides adding that service, no pull beforoe. Even though it looks like I did
<mothacehe>civodul: you mean the nginx configuration?
<florhizome[m]><attila_lendvai> "florhizome, i've seen freezes..." <- No it’s only about the guix.el (guix–emacs) related commands...
<florhizome[m]>Like guix–packages–by–name. It freezes for a few min, then reports it couldn’t get a connection.
<bricewge>Hello Guix!
<bricewge>On a foreign distro, what package (in addition to adwaita-icon-theme) do I need to have a nice cursor on GUI application?
<cbaines>civodul, cool, how are you getting on? I'd also like to reconfigure bayfront at some point to deploy the guix-build-coordinator update I just pushed.
<awb99>eyhb: I had the same problem. For me with the guix versions in the last 3 days this delays were dramatically reduced. core-update-frozen merge has fixed a lot of problems.
<fiesh>is there no way of defining elogind-configuration without ditching %desktop-services and listing them all manually?
<eyJhb>It took 35 minutes to get the ssh-daemon added as a service. It must have done something else as well
<bricewge>fiesh: Have you tried to use the modify-services procedure?
<florhizome[m]><bricewge> "On a foreign distro, what..." <- I think i saw a gist sometime about adjusting guix to foreign distros.
<florhizome[m]>but i remember i had that Problem, too including the gsettings of my packages not showing up
<efraim>the go test failures on aarch64 are a solved issue, but for some reason GOARCH isn't picked up in the build environment :/
<fiesh>bricewge: no, that was precisely what I was looking for, thank you!
<f1refly>I'm trying follow the guix manual for declaring my own package as a modification of another one with import, this is what I did so far:
<f1refly>But when I run guix-pull and include my own repo in the channels.scm it tells me "(value "no code for module ~S") (value ((picom))) (value #f)"
<f1refly>does this mean it can't find the original picom?
<jpoiret>aren't you missing a `define-module` for your code?
<jpoiret>also, you shouldn't use git-fetch with github-generated zip files, either you point to the git repo and change the commit hash, or use url-fetch
<f1refly>i meant to use url-fetch
<f1refly>i was trying around a bit, i think i just forgot to change it back
<f1refly>so i'd define-module and in that define i'd #:use-module the stuff i currently have in my use-module?
<jpoiret>yes. Also, you'd need the module name to actually follow the file tree
<jpoiret>if you're just modifying one package because you need a different version, i'd suggest using a manifest instead
<jpoiret>so that you don't need to create a whole new channel
<f1refly>I was planning to use the channel anyways for some personal tools I use, but I wanted to try something "easier" before packaging my own stuff
<f1refly>so if my picom.scm is in $repo/modules/picom.scm (define-module (modules picom)) would be right?
<jpoiret>depends, you can use to have your modules reside in a subdirectory, so for example you could have "modules/" be the subdir and your module would be called (picom) instead
<jpoiret>i'd suggest namespacing your modules too, ie having "$repo/modules/f1refly/picom.scm" and (f1refly picom) (or whatever you might want to call it), since channel modules are actually merged with the guix tree
<jpoiret>i see you're trying to use the latest available picom commit, for that use case i'd really suggest using `guix install --with-latest=picom picom` or equivalent
<jpoiret>actually, --with-latest won't work since there's no new tag, sorry. `--with-commit=picom=<commit-sha>` will though
<f1refly>okay, I'll do it like that. And I'll put the next package definitio in a proper namespace
<f1refly>the package built went well but unfortunatly xorg still lags like crazy with the newest version :)
<jpoiret>heh. One more reason to switch to Wayland
<raghavgururajan>Hello Guix!
<f1refly>herbstluftwm has yet to be rewritten to be workable with wayland I'm afraid
<yewscion>Good Morning, Guix!
<civodul>cbaines: you can go ahead then (i haven't reconfigured yet)
<civodul>i'll do berlin
<civodul>note that we'll need to copy certs from berlin or nginx will fail to start
<cbaines>ok, I've already gone ahead and reconfigured, but I only restarted the guix-build-coordinator service
<civodul>ah good
<civodul>should we copy LE certs over rsync (on the VPN), until there's a "proper" solution?
<civodul>alright, i restarted nginx on both machines, and everything seems to be fine
<yewscion>Hello all, could someone point me somewhere that (wrap-program) might be documented? I'm attempting to modify a package definition to ensure a python library can find $GUIX_PYTHONPATH, but unfortunately I am unfamiliar with how that works. I'm combing through the sources now to find a good example, but I was hoping asking here might point me in a
<yewscion>more efficient direction.
<roptat>hi guix!
<roptat>yewscion, I'm afraid it's not documented
<yewscion>roptat: Copy that (something I could help with eventually, once I really understand it? I enjoy documenting software).
<yewscion>Is the best way to find the source for a built-in like that just grepping under /guix/guix in the repo? Or is there another way that might be more efficient?
<roptat>sure! I see only one mention in the manual, in an example on section 8.6.4
<roptat>I always grep
<roptat>I think section 8.6 only has very basic documentation, it could be improved by a lot
<yewscion>Copy that, is the process for patching the docs the same as for patching the package defs? Edit the source, open an issue, send a patch?
<attila_lendvai>yewscion, if you use emacs, and set up geiser, and load the code into the inferior guile, then M-. and M-, should work, too
<roptat>yewscion, yes, the file to modify is doc/guix.texi
<yewscion>attila_lendvai: Oh! I hadn't thought to do that. That would help me a lot, actually. Thanks for the suggestion!
<yewscion>roptat: Thanks! Sorry for asking so many questions; Just wanna make sure I do things in the right way.
<roptat>that's fine :)
<mekeor[m]>hello guix. did anyone succeed in installing guix-system on pine64's single-board-computer quartz64?
<mekeor[m]>phodina: do you have experience with guix on quartz64?
<attila_lendvai>can i configure the niceness (priority) of the guix builder service? i can't seem to find anything.
<attila_lendvai>i have just found max-1min-load-average, but what i want is process priority, not load-average
*attila_lendvai is patching shepherd's exec-command, even though he has no clue how to actually test it
<civodul>attila_lendvai: that looks like the right approach; you could test it with a service that spawns "sleep", say
<attila_lendvai>civodul, but i have no clue how to start my own standalone shepherd, and then how to configure that with a custom service.
*attila_lendvai is staring at the shepherd docs
<attila_lendvai>civodul, how about me sending you an untested patch...? :)
<civodul>nope :-)
<attila_lendvai>daaamn, that didn't work out...! :)
<attila_lendvai>i wish the shepherd docs had a chapter about running/testing shepherd. i'll record this patch into a branch and continue hacking on other stuff.
<jlicht>attila_lendvai: I might be mistaken, but shouldn't `make check' run tests?
<jlicht>which you might find in the tests directory
<attila_lendvai>jlicht, the tests dir has some shell scripts
<attila_lendvai>...which is good enough as a template. thanks!
<roptat>some ocaml packages have not been switched to the new style yet, probably because the labels are not exactly the same as the package name. I'd like to change that. Should I make it one commit per package, or a single commit? there's no functional change, except for ocaml-4.07, and the changes unfortunately affect the derivation
<attila_lendvai>these shepherd tests print all kinds of stuff, including error messages. no clue what is expected.
<civodul>roptat: if there's no functional change, and once you've made sure nothing breaks, i think it's fine to make a single commit
<roptat>ok, I think I'll make ocaml-4.07 a separate commit, just because I changed a (assoc-ref inputs ...) with (search-input-file ...)
<roptat>the rest is just changing the style of inputs
<roptat>is there a way to change the input style when the input is an origin record that I use in a phase?
<attila_lendvai>daaaaamn! the shepherd tests are running shepherd from the PATH, not the actual checked out codebase... the last thing i would have expected
<jlicht>attila_lendvai: how are you running the tests? If you get this behaviour /w `make check`, that seems like a mistake
<attila_lendvai>jlicht, i was just running them. i'm installing the autotools now. only now have realized that there's only a i'm not very familiar with the auto* stuff (nor fond of them).
<yewscion>Quick Question: If a file with a package definition is pulling in python.scm, which exports (customize-site guix-pythonpath-search-path), how can I use that export in the aforementioned package definition? I want to avoid propagating python unnecessarily, but I need $GUIX_PYTHONPATH to be set to include the local libraries.
*attila_lendvai is waiting for local rebuilds now
<unmatched-paren>hi guix! i'm having problems with rust-anyhow
<unmatched-paren>error: failed to select a version for the requirement `trybuild = "^1.0.49"`
<unmatched-paren>candidate versions found which didn't match: 1.0.38
<unmatched-paren>location searched: directory source `/tmp/guix-build-rust-anyhow-1.0.46.drv-0/anyhow-1.0.46/guix-vendor` (which is replacing registry ``)
<unmatched-paren>required by package `anyhow v1.0.46 (/tmp/guix-build-rust-anyhow-1.0.46.drv-0/anyhow-1.0.46)`
<unmatched-paren>which is bizarre, since i do not define rust-anyhow; it's a package in `guix`, not `paren`
<unmatched-paren>My tree-sitter depends on it, which causes `guix upgrade`
<unmatched-paren>to fail
<unmatched-paren>`guix build rust-anyhow` fails for me, could somebody else confirm?
<bricewge>unmatched-paren: Cuirass has the same issue
<unmatched-paren>bricewge: thanks :)
<unmatched-paren>i'll fix that with a local package, then maybe submit it to guix proper
<unmatched-paren>i wonder how that could possibly have happened, tho
<bricewge>I guess, all the package dependent on the updated packages in the patchset weren't tested
<unmatched-paren>how can i do a ./pre-inst-env sort of thing in my channel's working environment? is it even possible without cloning the guix makefile?
<robin>hm, 'guix upgrade texlive' dies with an 'integer expected from stream' error from the daemon. this should be fun to debug (initially i thought it was some more general problem communicating with the substitute servers)
<jackhill>apteryx: I've started the discussion about webkitgtk and gst-plugins on guix-devel@
<vivien>My keyboard layout is supported by GNOME but not the TTYs (I get to use qwerty). Which package is responsible for that failure? I’d like to try and patch it.
<robin>vivien, 'kbd' probably?
<robin>vivien, or possibly a bug in (@ (gnu system keyboard) keyboard-layout->console-keymap) or related functions
<taterbase>Is there an arm variant of guix?
<unmatched-paren>Yes :)
<unmatched-paren>but some packages may not work
<unmatched-paren>and there's less substitutes
<taterbase>That's fine!
<taterbase>Is there a live cd for it?
<unmatched-paren>Rust is an example; anything that depends on Rust will not work; mrustc, which is the bootstrap, has inline asm that currently only works on x86
<unmatched-paren>taterbase: Yep, think so
<jacereda>what about static linking? is there a variant for that?
<unmatched-paren>actually, i'm not sure...
<taterbase>I don't have a libre arm laptop but I was hoping to try running it on qemu on my m1 macbook
<jpoiret>what's the difference between gpl3 and gpl3+? can't seem to find anything about gpl3+
<unmatched-paren>hm, looks like there's no system installation for arm, sorry
<taterbase>gpl+ just means if a gpl4 comes out it will use that license
<unmatched-paren>jpoiret: doesn't gpl+ mean gpl-VERSION-or-later?
<jpoiret>oh, right. How do people usually write this down in eg LICENSE?
<jpoiret>do they state GPLv3 or later?
<unmatched-paren>taterbase: you might be able to build the image yourself, idk
<vivien>robin, kbd supports my keymap, but the name is unexpected, how can I specify the console keymap name in the config file (overriding keyboard-layout->console-keymap)?
<unmatched-paren>jpoiret: generally, each file has a `Under license foo` header that points to the LICENSE file for the contents of a license
<unmatched-paren>I'm fairly sure that the LICENSE file on its own does not mean that the code is under the license in it, technically
<unmatched-paren>You have to have a header, really
<taterbase>unmatched-paren: good call thank you
<jpoiret>yeah, that's what I can gather as well. Welp, seems that what I'm packaging doesn't have anything other than the LICENSE file :/
<unmatched-paren>So you'd say `this code is under gpl3-or-later, see the /LICENSE file for details of this license`
<unmatched-paren>jpoiret: most projects don't use the header, it's probably fine
<unmatched-paren>even if it isn't technically legally under the license, basically everyone treats it like that
<robin>vivien, ah, i guessed wrong about kbd; guix appears to *always* use ckbcomp from console-setup to generate a console keymap based on xkb keymaps, even for basic layouts like 'us' and 'dvorak'
<unmatched-paren>Often the project puts the license note in their readme, which is probably more than adequate
<robin>vivien, so maybe it's a bug in ckbcomp, or the way guix invokes it
<lfam>It's completely typical for free software projects to omit license headers
<vivien>In fact, I don’t think the exact variant I want is supported, but I would rather use a closer variant than qwerty
<lfam>You don't have to worry about it
<unmatched-paren>yeah, it's pretty hard to tell what _technically_ applies and what _technically_ doesn't
<lfam>However, if there's no actual use of the "or later" clause, then we do not interpret the license as being "N or later"
<lfam>Technically, you will only find out for sure after a lawsuit over the subject is completed
<lfam>This is what use of the "or later" clause looks like: <>
<vivien>If guix were using goops, I could overload keyboard-layout->console-keymap and there wouldn’t be any problen
<unmatched-paren>Probably the best way to do license headers now is an SPDX identifier, I guess, since it gets your point across unambiguously without a large annoying comment block
<unmatched-paren>Not sure that legally applies either, tho
<lfam>None of this is settled law, at least in the US
<lfam>Just do your best to interpret what the authors intend, and if you are unsure, then ask them
<unmatched-paren>I've seen some projects do `(your language's comment symbol) SPDX-License-Identifier: (license identifier)`
<lfam>Remember, the law is not the same as software / code. It doesn't happen automatically, nor are there "bugs" in the law
<lfam>It's interpreted by humans in a human way
<unmatched-paren>The law is not reproducible; we must start
<lfam>So, if a program includes a license file, and no other information, it's reasonable to assume that the software is given to you under that license
<lfam>And like I said, if you are still unsure, then ask the authors
<civodul>mothacehe, zimoun: hey! any thoughts on v2 of --tune?
<civodul>if not, i could merge it before going +/- "on vacation"
<mothacehe> hey! the micro architectures are still duplicated in (guix cpu) and (gnu ci) right? Fine with me if we fix it later on
<mothacehe>great job factorizing btw!
<civodul>mothacehe: ah yes, it's duplicated, but that's because i chose an arbitrary subset in (gnu ci)
<civodul>on the grounds that it we don't want to build for every CPU
<civodul>so it's semi-duplicated!
<jpoiret>lfam: about the xorg-server patch, I don't use Xorg at all, sorry
<attila_lendvai>is gettext an assumed dependency everywhere, or the shepherd package is missing it in native-inputs?
<attila_lendvai>i can't compile shepherd. i'd appreciate if someone could update the README. it requires at least `guix shell gettext guile -D shepherd` and `autoreconf --install`, or somesuch. i'm clueless about these tools.
<attila_lendvai>and/or the shepherd guix package requires adjustment
<robin>attila_lendvai, for gnu-build-system at least, iirc the implicit inputs are the %final-inputs in (gnu packages commencement), and don't include gettext (or autoconf, automake, ...)
<attila_lendvai>robin, based on my experience in a shell, i'm not sure how/why the guix package compiles.
<lfam>jpoiret: Okay!
<robin>attila_lendvai, well, the package is building the contents of a tarball, presumably prepared with 'make dist' or similar so it doesn't depend on autotools and such
<attila_lendvai>robin, oh, i see! thanks!
*attila_lendvai is afk
<lfam>Any more testers for the proposed fix for #52051? <>
<lfam>Or, should I write the commit message myself and go ahead and push
<unmatched-paren>uh, what does Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
<unmatched-paren>It happens when i guix pull
<unmatched-paren>...and now it says 'nothing to be done' when i try again???
<lfam>Does `guix describe` report the thing you expect?
<unmatched-paren>lilyp: the `guix` process uses 3.0GB of memory... I'll try guix describe
<unmatched-paren>Yes, it looks fine to me
<unmatched-paren>And it uses >10% CPU power
<lfam>Suggests that it's a warning, not an error: <>
<lfam>Anyways, it means you ran out of memory
<unmatched-paren>well, yeah
<unmatched-paren>but i have no idea why
<unmatched-paren>it's never done this before
<unmatched-paren>My machine has 16GB of RAM btw
<lfam>Typically, it is because either 1) You don't have enough memory or 2) There's a bug in the code causing an import cycle
<lfam>Okay, that is enough
<unmatched-paren>hm, my channel probably has an import cycle then
<lfam>Yes, if you are using 3rd party code, I would look there first
<unmatched-paren>i'm trying to fix packages that were broken by an update
<unmatched-paren>so i'm just committing then pulling
<lfam>It does happen in Guix sometimes, but it's more likely to happen when mixing in 3rd party channels
<unmatched-paren>over and over
<unmatched-paren>is there a better workflow for channel work? something like `guix`'s ./pre-inst-env thing?
<unmatched-paren>my channel looks fine to me... i see no import cycles
<awb99>does anyone know in which package I can find "netstat" ?
<unmatched-paren>the import dependencies go like:
<lfam>awb99: net-tools
<unmatched-paren>lua.scm, (crates-io.scm -> tree-sitter.scm) -> vim.scm
<awb99>thanks Ifam
<unmatched-paren>i don't see any cycles in
<lfam>Are these packages that exist in GNU Guix?
<lfam>I was asking because if they were, the workflow would be simpler
<unmatched-paren>I name my files after ones already in guix; i think where they would go if they were submitted into the main channel
<unmatched-paren>maybe there's a recursive dependency, not import?
<unmatched-paren>Yep, looks to be... guix package -f on a file with a recently added package does the same memory creep thing
<fnurkla>awb99: netstat is a part of net-tools
<avp>Hello Guixers, I've prepared a patch that updates Guile-SSH to 0.14.0 in Guix:
***lukedashjr is now known as luke-jr
<lfam>Thanks avp. Because Guix itself depends on guile-ssh, I'm wondering if you did any testing of the guile-ssh update?
<unmatched-paren>hm, it's possible that guix itself has a dependency cycle
<avp>No, I haven't tested Guix with the new Guile-SSH version.
<lfam>Okay, thanks for letting us know avp. Can you mention it in the thread on the patch tracker?
<lfam>That info will help with review
<unmatched-paren>the reason i'm having to deal with this in the first place is because an untested patch was merged in to guix itself
<avp>As I mentioned in the new release announcement I'd appretiate if anyone could test it properly.
<unmatched-paren>it broke my tree-sitter package
<unmatched-paren>rust-addr2line depends on rust-backtrace, but rust-backtrace depends on rust-addr2line!
<awb99>thanks fnurkla!
<awb99>how can I add a configuration file to /etc? I managed to get files to /etc/static, but I have some apps that require config file to be in /etc directly.
<KarlJoad>Does the linux-libre kernel that Guis ships with have support for the ipmi kernel modules? I see documentation on, but want to be sure.
<unmatched-paren>i would be surprised if there wasn't some way to add those from your config.scm
<avp>lfam: Sure, I just sent an update email to the bugtracker with this information. Thanks for the hint!
<unmatched-paren>(the /etc files)
<unmatched-paren>i'm pretty sure that reconfigure sometimes regenerates them
<unmatched-paren>...ah. it's because i thought you were now able to lump together #:cargo-inputs and #:cargo-development-inputs in the inputs field.
<KarlJoad>awb99: It should be possible. There is probably a setting somewhere in the manual that details how to do it.
<opalvaults[m]>Unable to load any of the alternatives:
<opalvaults[m]> ("" "" "")
<opalvaults[m]> [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]
<opalvaults[m]>Getting this error when trying to quickload a handful of packages in sly
<opalvaults[m]>any package that provides those? or do I need to point sbcl somewhere in particular?
<jlicht>does guix's emacs-eldev work for anyone? It can't seem to find eldev.el when invoking 'eldev'
<lfam>opalvaults[m]: libcrypto is provided by OpenSSL
<opalvaults[m]>lfam: it appears that sly/sbcl doesn't know about it through installation of the package alone. i have openssl installed
<lfam>I suppose you'll have to figure out how to tell sly where to look
<opalvaults[m]>oh, well that's fairly simple then.
<opalvaults[m]>thanks for the info :)
<lfam>Probably somebody else can give more specific advice
<unmatched-paren>woo, i've fixed the loop \o/
<unmatched-paren>cargo-development-inputs is a very deceptive thing
<unmatched-paren>it looks like it's ok to lump it in with inputs, until it doesn't
***lukedashjr is now known as luke-jr
<opalvaults[m]>lfam: guix has a package called cl-cl+ssl that providesthe correct directory/points sly to the correct location of
<opalvaults[m]>woot, got it working
<the_tubular>I don't want to start an holy war, but is there somewhere I can read on the differences on the lisp family language ?
<the_tubular>Scheme, Racket, Clojure, etc
<unmatched-paren>clojure runs on the jvm
<unmatched-paren>scheme is the smallest, purest one
<unmatched-paren>racket is a beefed up scheme
<the_tubular>What is jvm ?
<the_tubular>Java something ... I guess ?
<unmatched-paren>common lisp is a bit more kitchen sink than scheme
<unmatched-paren>jvm is the java virtual machine
<the_tubular>Got it
<unmatched-paren>basically, clojure and java can interoperate
<unmatched-paren>because they both compile to java bytecode
<unmatched-paren>in scheme, functions are just variables assigned to lambdas, but in common lisp, they're their own thing
<jackhill>of course kawa scheme runs on the JVM too, and clojure has other interesting/unique design choices, but yeah, manybe a better question for #lisp :)
<unmatched-paren>(e.g. defvar/defun versus define and (define (lambda)))
<unmatched-paren>fennel compiles to lua
<unmatched-paren>emacs lisp... idk, i've never really used emacs; after a few minutes of using it i went back to vim
<unmatched-paren>there's quite a lot of lisps, its simplicity means it's generally comparatively easy to implement
<unmatched-paren>actually, many languages compile themselves to a lisp-like ir for easier analysis, iirc
<the_tubular>Yeah, I'm still trying to learn emacs unmatched-paren
<the_tubular>Can't say I don't like it
<the_tubular>But that's a lot of keybinds to remember
<unmatched-paren>vim is better :)
<the_tubular>Also I think you can't configure emacs with guix-home yet, I guess when that happens, that would make porting my emacs config way easier
<the_tubular>How so ?
<unmatched-paren>yeah, i don't like the way that you need to press control for everything
<unmatched-paren>the_tubular: mostly because it's modal
<AIM[m]>unmatched-paren: You do know they're different suites of software, right?
<unmatched-paren>yes, this is my opinion
<the_tubular>I mean, emacs-evil exists for that reason
<AIM[m]>emacs has an editor inside it but that doesn't mean it's an editor
<opalvaults[m]>the_tubular: Common Lisp: standardized lisp, lots of enterprise libs.
<opalvaults[m]>Scheme: Before Common Lisp -- minimalist and encourages building abstractions by hand instead of relying on libraries
<opalvaults[m]>Clojure: Runs on Java's virtual machine, and thus can interop with Java libraries -- it's purely functional (afair)
<opalvaults[m]>Racket: An offspring of scheme, born ~2010. could arguably be called the Python of Schemes. Lots of metaprogramming functionality and learning materials.
<AIM[m]>Org mode and magit are some of the reasons people use emacs
<unmatched-paren>ok, so vim is better than the editor that is inside emacs
<opalvaults[m]>Emacs Lisp: An offshoot of common lisp made for extending emacs
<the_tubular>Thanks for that opalvaults[m] :)
<unmatched-paren>AIM[m]: there are several org mode plugins for nvim, and one (neorg) that betters it (imo)
<opalvaults[m]>vim is nowhere near better than emacs?
<opalvaults[m]>like it's just not even comparable
<unmatched-paren>opalvaults[m]: haha, let's not get too far into this :P
<AIM[m]>Emacs has a Gui editor, like it's no terminal interface
<opalvaults[m]>emacs can literally do everything vim can do and like 9000x more with little effort.
<opalvaults[m]>#guix-offtopic territory
<AIM[m]>opalvaults[m]: Yep
<unmatched-paren>i still feel like BOTH emacs and vim are handicapped by their text-based-ness
<the_tubular>I even replaced tmux with emacs
<AIM[m]> Let's take it to the streets, then!
<AIM[m]>AIM[m]: I'll bring my gang
<unmatched-paren>(wait, is there a #guix-offtopic channel?)
<the_tubular>*Queues the mortal Kombat music*
<opalvaults[m]>unmatched-paren: sure be!
<unmatched-paren>huh, ok then, bye :)
<AIM[m]>You can't install normal tar files right?
<AIM[m]>Can ya?
<AIM[m]>What about git cloned stuff?
<AIM[m]>Can I do some guix environment and package it and send it to /gnu/store ?
<lfam>What is your goal?
<AIM[m]>Like how do I compile and install normal programs?
<AIM[m]>They don't store in /gnu/store, no?
<the_tubular>I'm not sure I understand your question, isn't that how guix works fundamentally?
<zamfofex>Hello, Guix! Quick question: Would it be sensible to use the bit‐by‐bit identity of built packages on the store to determine compatibility? So imagine a package at ‘/gnu/store/aaa-hello-2.10’ has a dependency on GCC 10, and its definition is then updated to depend on GCC 11.
<zamfofex>But if the new ‘/gnu/store/bbb-hello-2.10’ is bit‐by‐bit equal to the previous ‘aaa-’ one, then dependencies of the new ‘hello’ package would’t be rebuilt, and instead simply copied over from the previous store path (if they are already available in the store).
<zamfofex>I feel like this would alleviate the need to keep package definitions intact (specially those with a lot of dependents), as long as dependent don’t change because of that.
<zamfofex>the_tubular: I think AIM[m] wants to e.g. ‘git clone’ a repository and ‘sudo make install’ it like they would in other systems, without needing to package it.
<AIM[m]>zamfofex: Exactly
<AIM[m]>I wanna implement something like that
<zamfofex>Normally in those cases (which I try to limit), I just run plain ‘make’ and add a Bash alias to the exectuable in my home directory.
<civodul>zamfofex: yes i think so, that's something we should be able to implement
<zamfofex>civodul: Has that been considered before?
***lukedashjr is now known as luke-jr
<lfam>zamfofex: Yes, it's been considered, if I understand your suggestion correctly
<lfam>It sounds like the difference between an "extensional" (what we use) and "intensional" model, as describe in Eelco Dolstra's thesis where Nix was first presented
<fiesh>is there any way to execute shell code during the boot process to fix permissions / values that I can't seem to address otherwise? (sysfs)
<lfam>Some Nix discussion, zamfofex: <>
<lfam>fiesh: Are you trying to set some sysfs values at boot?
<fiesh>lfam: write them, and change some permissions in /sys/..., yes
<KarlJoad>Sorry, I may have missed the answer, but does Guix's linux-libre kernel support Linux's IPMI modules?
<lfam>fiesh: You might check out the sysctl service type: <>
<lfam>And an example: <>
<lfam>KarlJoad, it's also worth asking in the gnu-linux-libre channel
<fiesh>lfam: looking into it, thank you
<lfam>Maybe somebody else has a specific answer for you KarlJoad
<lfam>Personally I don't know where that support comes from so I can't look it up
<fiesh>lfam: but this is purely sysctl, not sysfs, or am I mistaken?
<lfam>Oh, sorry
<KarlJoad>lfam: Ok, thanks for the redirect.
<zamfofex>lfam: That’s pretty much exactly what I suggested. I think an elegant solution would have been to consider the hashes of the built outputs of a dependency (rather than the dependency definition itself), but I feel like that would be a far more drastic change.
<lfam>zamfofex: So, Nix actually implemented this recently. I guess it's a hybrid of the two paradigms now? I don't really know the details
<lfam>If you search our mailing list archives for the terminology, I think there is some recent-ish discussion
<zamfofex>Also, another (perhaps more computationally difficult) thing that would also be really neat would be to infer grafts instead of explicitly defining them. So that if the output of a package only change by dependency path (in the same position within the binaries/outputs), a graft can be applied automatically. Though in that case, I suppose it would be useful to allow for the build farm to communicate that with clients somehow.
<lfam>zamfofex: Something to consider is that, at the time the thesis was published (2006), an intensional model was not useful at all. It was unreasonable to count on bit-identical outputs of builds, even when nothing had changed at all
<lfam>So, it's only through the efforts of Nix, Guix, and the reproducible builds movement that the intensional model is a viable option
<lfam>I'm not sure I understand your suggestion about grafts
*fiesh just realized there's no podman, only docker, in guix :(
<jackhill>fiesh: podman is being worked on though: If you're in a position to help test, I'm sure it would be appreciated.
<fiesh>jackhill: oh that's awesome, thanks, I'll look into it
<fiesh>(podman is so much better than docker, it should be called the-dockest)
<fiesh>well that leaves me with my seemingly unsurmountable sysfs problem... I can't believe I'm the only one facing it
<zamfofex>lfam: I mean if two outputs only differ by the store path of a dependency in their binaries, then the dependency could be considered interchangeable, and thus the build farm could let clients know that a graft can be made.
<zamfofex>When I say “the dependency could be considered interchangeable”, I mean the two paths of the dependency.
<jackhill>fiesh: what's your systfs problem (sorry, I wasn't paying attention earlier)?
<lfam>fiesh: It's definitely not insurmountable. But nobody has a "ready to use" example for you. Once can define custom services that can do anything you like
<lfam>I mean, "One can define ..."
<lfam>Makes sense zamfofex
<zamfofex>I feel like that would make more sense than requiring package mantainers to specify grafts explicitly.
<fiesh>jackhill: changing permissions / values in /sys during / after boot
<lfam>With the current model, it makes sense to specify grafts explicitly, because they are a kludge and can mask serious bugs
<lfam>A vital kludge, but a kludge
<fiesh>lfam: ok, I suppose that surpasses my current understanding of Guix, I'll have to get myself somewhat more educated in it first
<lfam>fiesh: Stick around, somebody will probably be able to help you with it
<fiesh>lfam: always lurking ;-)
<lfam>It's definitely unusual to change permissions of sysfs, but changing values is normal
<jackhill>fiesh: oh yeah, I would use that to, I've just been lazy about looking into it :) For a minute you had me worried that there was something broken. It's sad to be missing a feature but less worrysome
<lfam>In general, you'll get the best advice if you say exactly what you are trying to do, rather than beating around the bush
<fiesh>lfam: idk, that was the only non-awful solution I found to adjusting my laptop's backlight -- by using xbindkeys and having a script that alters /sys/class/backlight/intel_backlight/brightness
<lfam>I see
<fiesh>and for that to work, chgrp'ing to video and setting g+w was a reasonable approach
<lfam>Are you using Xorg, or Wayland? Or the console?
<fiesh>jackhill: nothing broken ;)
<fiesh>lfam: Xorg
<lfam>Did you look into the xbacklight package?
<fiesh>lfam: yeah it somehow didn't work for me at all -- which may be my fault, but it seemed it shouldn't be too hard to use
<lfam>There is also brightnessctl
<lfam>Apparently it includes some udev rules that set up permissions correctly
<lfam>So, you might have to set up some udev service thing
<lfam>I'm *sure* that somebody else has a controllable backlight on Guix System
<lfam>And they will eventually offer to help
<fiesh>well there are other values in /sys that I'd like to alter as well (no permission change necessary though)
<fiesh>I gave brightnessctl a try as well
<lfam>It makes me wonder what my computers do. The brightness keys "just work" on them
<fiesh>heh indeed
<fiesh>was alas not the case for me
<lfam>A benefit of using Thinkpads with linux, I suppose
<fiesh>I ditched mine for the librem 14
<fiesh>in every way a good decision, except for the brightness keys ;)
<fiesh>I didn't take a look at how the PureOS that shipped with it handled the brightness... that might be a good resource, but either way I'll be stuck with trying to alter values in sysfs
<samplet>lfam: That timeout patch is okay by me. Like you said, it fixes a rather serious issue for some people, and I think Maxime is right about the security considerations.
<samplet>I’m pretty sure it is only masking a symptom of some other issue, though.
<lfam>samplet: I admit I didn't follow the issue closely. Are the commit message and code comment that I wrote accurate?
<lfam>Maybe samplet, maybe not. I've experienced similar "new timeouts" after big upgrades, and my hunch is that the storage layout changed in a way that seeking took much longer.
<lfam>But, whether it's a real fix or not, it's a fix
<lfam>As for security considerations, are you referring to Maxime's point about a local DOS, and the difficulty of protecting against it
<samplet>lfam: I would only change “60 second timeout” -> “60 second authentication timeout”, just to be a little clearer.
<lfam>fiesh: You might also ask upstream in xbacklight or brightnessctl
<lfam>samplet: Okay
<samplet>lfam: Yeah. Upstream lowered the timeout from 30s to 5s in response to a DoS CVE. They increased back to 30s because it was breaking logins.
<fiesh>lfam: you got me thinking... how's that work, installing brightnessctl as a user cannot possibly allow a permission change via udev? do I have to install via my config.scm for it to work?
<lfam>fiesh: You would install brightnessctl however you like, and use the example udev rules it includes in your config.scm. The latter part requires privileges
<lfam>samplet: Right. I guess that nobody in their right mind would still be using a Thinkpad X200 with an HDD
<lfam>Especially not developers
<fiesh>oh and these udev rules are basically exactly what I need to do, so I suppose udev makes it possible to change permissions :)
<lfam>I wonder if the X200 has exceptionally low I/O bandwidth, or if it's the only 13 year old laptop Guix users are using with HDDs
<civodul>samplet: new Disarchive, yay! \o/
<samplet>lfam: I tested two other older laptops with the same HDD, and they all had the same problem.
<lfam>I'm curious samplet, also Core2Duo CPUs?
<samplet>civodul: Yeah, but I forgot to update ‘(guix self)’, so it’s not working! :(
<samplet>Also, I think there’s another regression with Disarchive fallback (from before my commit). I’m looking into it now.
<lfam>samplet: I didn't realize that you have commit access. Can you please push the #52051 patch?
<civodul>samplet: not working because you need to add guile-lzma in (guix self)?
<podiki[m]>there's also "light" for backlight control
<samplet>civodul: Yes, plus whatever else is wrong. (I think it’s a SWH download issue.)
<samplet>lfam: Possibly. One definitely. I don’t remember the other.
<KE0VVT>fiesh: lfam: Still gawking at the ancient X200 and its ancient disks.
<ns12>Hello Guix!
<ns12>I noticed that some packages have a "release-monitoring-url" property in the package's "properties" field. What is release-monitoring-url used for?
<fiesh>KE0VVT: I tried installing a new display into my X220 and screwed up the soldering, hardware just isn't for me, so I threw it away and got a new laptop ;)
<civodul>ns12: hi! this is used by the 'generic-html' updater, for "guix refresh"
<PotentialUser-34>Has anyone ever encountered qtile not creating a .desktop file for the display manager? For context, all I did is put (specifiation->package "qtile") in my config.scm, and I did the same with a couple of other wms and had no problems with them
<KarlJoad>lfam: Just checked with the linux-libre log, no IPMI modules are removed. Good to know. Maybe my computer will shut off this time.
<ns12>civodul: Thanks. When is that property needed? I noticed that only some packages have/need it.
<civodul>ns12: it's needed for packages that (1) rely on generic-html to determine their latest version, and (2) where the default choice of URL is incorrect