IRC channel logs


back to list of logs

<nckx>(Reading the mentioned ‘ECMAScript’ part in the Guile manual, I think it's quite obvious the author is talking about themselves. Maybe I'm missing some self-deprecating humour on Caleb's part but it's sad if the project left them so demotivated that they actually feared ending up a pariah.)
<ix>dstolfa: take that up with just about everyone ive ever argued with
<danderson>I dunno, I suppose I have a different threshold for that. It's emotional for sure, but not unreasonably so. And given the content being conveyed, it seems like a legitimate place to talk about the non-technical problems
<dstolfa>ix: i think it's just a case of text-based communication being an less-than-great medium for some things
<nckx>ix: Have you sobered up yet.
<drakonis>go sober up my guy
<nckx>Me neither.
<drakonis>sunday night drunk ravings :V?
<danderson>anyway. Thanks for the background all. Very useful context.
<ix>In fact im probably more drunk than earlier, but at least a lot less generalized anger
*ix o/
<nckx>Yes. Focus the rage beam. Preferably onto something written in C++.
<drakonis>do notice that email refers to the 2017 implementation, i think you should look for the 2020 code
<drakonis>ix: 5 states of acceptance?
<drakonis>this weekend i'm going to write an arcan service, for some of that sweet sweet cool software moolah
<drakonis>freedom from xorg and wayland
<Noisytoot>nckx, the nix daemon?
<drakonis>cbaines: what are the implications of using bordeaux?
<nckx>Noisytoot: Ideally.
<drakonis>i'm not sure if i fully understand it
<drakonis>does it mean that mirrors for serving packages can be added?
<nckx>drakonis: What do you mean?
<drakonis>adding the ability to have multiple substitute servers for performance
<nckx>That's always been the case but yes.
<nckx>I use 5.
<nckx>It's a trade-off, since you increase the query overhead by asking each server in turn, but they are tested in order so if you put ci.guix first (or whichever is fastest to build) it's not too bad.
<drakonis>hmm, i see.
<nckx>bordeaux is just the new name for bayfront, not a new server.
<drakonis>ah okay
<nckx>Some new scheduling software (the Guix Build Coordinator) but the same good(?) old KGPE D16 box.
<drakonis>ah i see
<nckx>You're not trusting new hardware.
<ixmpp>sneek: later tell abcdw why keep this? It massively threw me off just now
<vslg_>Hi, this might be a stupid question, but I'm new to Guix and I'm trying to do a bit of packaging. Every time I run ./pre-inst-env guix [...], it rebuilds Guix from scratch, there are a lot of notes saying that the source file is newer than the compiled one (in the store). Is this normal? Every time I want to test a change in my package, it rebuilds everything an it takes time.
<vslg_>Should I mention that I'm running Guix package manager from other distro different than Guix.
<nckx>vslg_: First run ‘guix environment guix -- ./pre-inst-env make -j$(nproc)‘ to recompile all those modified files.
<nckx>From then on it will only print that warning (and incur a slight delay) for the file(s) you're actually working on.
<nckx>When editing different files, repeat as needed.
<nckx>Good night, Guix o/
<vslg_>Thank you very much, I'll try it.
<dstolfa>good night nckx
<bauermann>mbakke, FYI: I'm halfway through (I hope!) creating a patch which updates TeX Live to version 2021.1. I have a hunch that it will fix the current irreproducibility of texlive packages (bug 48064)
<bauermann>though that may be just unwarranted blind hope...
<danderson>hmm, does a default guix install not allow pubkey login to root@?
<danderson>ah, looks like no.
<danderson>so, I was reading the blog post about speeding up substitution downloads... Is that in guix 1.3.x?
<danderson>I ask because one of the cases it covered (FTTH downloads) still seems terribly slow for me. I can barely hit 2MiB/s in steady state :(
<danderson>compounded by the download seemingly being serial and 1-at-a-time, so almost all the reconfig time ends up being trying to retrieve these files
<drakonis>you can make it parallel by increasing the number of jobs
<drakonis>thanks nix daemon
<danderson>oh, so guix defaults to 1 job or something?
<drakonis>once the daemon is in guile, first thing is to let people decide how many things they want to download at a time
<danderson>hmkay, time to find the knob for that...
<flatwhatson>> successfully built /gnu/store/qnk2wpghlf4fa85pzssbbxyw7ija7kgx-gtk-4.2.1.drv
<drakonis>its a flag
<drakonis>--jobs=4 for 4 jobs at once
<danderson>hrm. Ran reconfigure again immediately after doing it once, without altering the system config, and... it's rebuilding and regrafting a bunch of stuff? Confused.
<drakonis>did you do a pull recently?
<danderson>no. In this VM, I did a `guix system reconfigure /etc/config.scm`, which took a while pulling a bunch of substitutes, but eventually finished. Then I ran the exact same thing again, and now it's building guix-1.3.0rc2 from source?
<danderson>mostly I'm confused as to why the second `guix system reconfigure` wasn't a no-op. It seems to be doing more stuff that it didn't do the first time round.
<drakonis>i see
<drakonis>wait but how
***sneek_ is now known as sneek
<danderson>that's exactly my question :)
<danderson>naively, I expected the second reconfigure to take a while to evaluate the config, then go "ope, all built already, I'm done"
<danderson>instead it's building guix from source, which is taking _longer_ than the first run.
<danderson>So, ???
<drakonis>hmm, is config.scm the one you wrote yourself?
<danderson>it's the config.scm from the guix installer, with one change to the sshd config to allow pubkey logins by root
<drakonis>oh i see
<drakonis>do a guix pull
<danderson>okay, but why though :(
<drakonis>update your copy of the guix channel
<danderson>I mean, running guix pull now, but I'd like to understand what happened. Right now my mental model of what guix was doing is clearly not quite right
<drakonis>hmm, what were you expecting here?
<danderson>okay, so, coming from nixos, I'm thinking of `guix system reconfigure` as like `nixos-rebuild`. So, I ran it once, it computed and applied a new config to the system.
<danderson>The second time I run a nixos-rebuild with an unchanged config, it's effectively instant. It just reruns the activation script and you're done.
<danderson>But `guix system reconfigure` seems to have decided, on the _second_ run of the exact same config, that it needed to do a bunch of new work.
<danderson>so... why? Why didn't it eval the config, conclude "this is unchanged" and do basically nothing? Or just the guix equivalent of the nixos activation script?
<drakonis>just a sec
<danderson>am I making sense? I applied a declarative config once, then applied the same one a second time, and afaict the second run "discovered" a bunch of new work it had to do
<danderson>which doesn't make sense to me, so I must be missing a subtlety of guix
<drakonis>i'll have that answered in a bit
<drakonis>since i'm due for a system upgrade
<danderson>okay, after `guix pull`, my $PATH is still pointing to the system version, and `guix system reconfigure` still rebuilds guix from source
<danderson>so... I guess `guix pull` doesn't actually alter the system config at all, so my problem remains the same
<danderson>very confused :(
<drakonis>okay so
<drakonis>guix pull updates your profile
<danderson>right, but why isn't my profile wired into my $PATH? I'm running on GuixSD, surely the shell comes preconfigured to do that...
<drakonis>it does, yes.
<drakonis>i should point you towards the docs
<danderson>hmkay, so, turns out I was running on a `su` root shell. Maybe the root user isn't wired up this way...
<danderson>retrying as the regular user
<drakonis>i should've asked that
<drakonis>the root user has a separate profile
<danderson>sure, and guix pull updated that profile, but it's not wired into the shell $PATH
<danderson>hence my (continuing) confusion
<drakonis>the root user itself has the proper shell configurations btw
<danderson>well, apparently not, in my case
<danderson>hence my confusion
<drakonis>and reconfiguring evals but does not waste any more time downloading
<drakonis>it behaves like nixos does on rebuilds
<danderson>when I `su`, my path is /run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin
<drakonis>same here
<danderson>so that explains the pothole I hit, `guix pull` is effectively a no-op in a su shell
<drakonis>use sudo
<danderson>but okay, without a su shell, as a regular user, guix pull does the right thing
<danderson>(all quite slow compared to nix still, that worries me a bit for ongoing use... But, pressing on)
<drakonis>ah i see the problem here
<drakonis>basically, if you do a guix pull as root, it'll update its copy of the channels it uses
<drakonis>the root user
<drakonis>if you have any configs that depend on channels not in here will lead to rebuilds
<drakonis>actually, that one didnt make a lot of sense
<danderson>I don't get it. `guix pull` updated channels and the guix binary in the root profile, the problem is the guix binary in the root profile isn't the one that gets used
<danderson>unlike on a non-root account, where the profile is wired up correctly
<drakonis>one moment, i'm going to do some rebuilding with my root user profile
<The_tubular>Hi all, anybody tried ?
<The_tubular>I'm having trouble at starting the distro, I get an error message 1
<drakonis>danderson: ah yes
<drakonis>root is janky as heck
<drakonis>i remember now
<drakonis>its about the same annoying behavior as in the install images where you cannot do a pull as a root user
<danderson>right. So... why? AFAICT this boils down to "root isn't correctly set up to run guix on guixSD". I assume that's for some really good reason I don't understand yet.
<drakonis>i cannot answer that
<drakonis>but use your own user to do these things
<drakonis>i think it has to do with a missing provenance file?
<danderson>yup, doing that now.
<danderson>I need to read up about provenance, because guix is complaining on every command that it can't establish provenance for the system.
<drakonis>hmm maybe the docs have an answer to that
<danderson>which is... a bit weird given that I installed it from an official guix ISO
<danderson>I'd expect it to have the provenance figured out
<drakonis>i think the problems are similar to the ones you'd find on nixos though
<drakonis>rebuilding as a root user is discouraged afaik?
<danderson>no idea, but I can say it works fine
<danderson>I have no idea if it's encouraged or not, but it's never not worked for me :)
<drakonis>ah right, i remember now
<drakonis>its because there was a time people still used nix-env
<drakonis>so it was a bad idea to do it as root
<danderson>okay, well, now that I'm running via sudo, `guix system reconfigure` seems to behave like nixos-rebuild. Still a bit slower, but not "it'll take 30 minutes" any more, I can live with that
<drakonis>ah i also see why it isnt working
<danderson>okay, next problem - term-auto fails to start, whatever that is.
<drakonis>hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/root/.config/guix/current/bin/guix'.
<danderson>Time to learn how to debug a shepherd service...
<drakonis>this doesnt work
<drakonis>as root
<danderson>yes, because guix doesn't set up root's profile in $PATH for whatever reason
<danderson>unlike regular users.
<drakonis>i'm sure that can be fixed later
<drakonis>hash doesnt work
<drakonis>if you're root anyways
<danderson>sure. I'm documenting the potholes I'm encountering as a new user :)
<danderson>`hash guix` also doesn't work as a regular user, fwiw
<drakonis>hash itself works though
<danderson>oh, wait, no, I misread the instructons. I expected it to tell me what the path is, so I could check it against the expected one.
<drakonis>but the command isnt needed on guix system
<danderson>but it just silently updates the cached path.
<drakonis>its a hint for when people run it as a package manager
<drakonis>i believe
<drakonis>not so much as a whole system
<danderson>sure. And it's a useful hint in that it's trying to tell me how to fix root's shell config.
<danderson>I'm confused because I expected guixSD to get thatright for me out of the box.
<drakonis>to be fair, i dont complain about that because i never actually use root to do anything
<danderson>... okay, shepherd's manual is next to useless for debugging a failing service. Is theresome guide somewhere to root-cause why a service won't start?
<drakonis>it is definitely an issue with the install though
<danderson>`sudo herd restart term-auto` just states "Service term-auto could not be started."
<danderson>... okay, _why_ ? Where do I get more details than "no" ?
<drakonis>herd status
<danderson>herd status is also useless. "It is stopped."
<drakonis>also that's not broken i guess?
<drakonis>herd status term-auto?
<danderson>yes, I know it is stopped, because you failed to start it. _why_?
<danderson>yes, "It is stopped."
<danderson>I presume, somewhere, there is a log that tells me more than "lol, no", but I can't find it. On a systemd distro that'd be journalctl, and the status output would helpfully show me exerpts from it. So far I'm not finding anything like that for shepherd.
<danderson>Nothing in /var/log, obviously no journald...
<danderson>note I'm only even caring about this because `guix system reconfigure` told me that it failed to start some stuff and I should do it myself.
<drakonis>but this service doesnt have any impact as far as i'm concerned
<danderson>Sure. Pretend it does though. As a system operator, I want to know how to fix failing systems.
<danderson>So far, all the logs I can find just say the same useless thing as herd status "no, you can't have that service"
<dstolfa>danderson: most services will do stuff via syslog, so they well end up in /var/log somewhere
<danderson>dstolfa: that's what I guessed, but all I can find in there is shepherd repeating the same unhelpful line about not being able to start this service :(
<dstolfa>danderson: that's probably because it probably doesn't log anything unfortunately :/
<drakonis>i dont think term-auto ever restarts for me
<dstolfa>FWIW term-auto is stopped for me too
<dstolfa>i have no idea what it does though
<drakonis>it depends on udev and the scheme file generated has launch parameters for some pretty boring terminal stuff
<The_tubular>Anybody got guix running in WSL ?
<dstolfa>it might be a oneshot
<dstolfa>if it's WSL2, it will work
<The_tubular>I can't get it to work :/
<dstolfa>WSL2 is just using hyperv to virtualize a linux kernel
<dstolfa>i assume the issue is with /gnu/store?
<The_tubular>No, I can't start the machine at all
<danderson>okay, guess I need to find the bugtracker then. Either this service is useless and should be removed, or it shouldn't generate a complaint every time you reconfigure guixsd.
<The_tubular>I tried following this :
<drakonis>i think you need to not overthink the whole thing and just play around with it
<The_tubular>But this does not work : C:\Users\Giuliano\Documents\WSL\guix>wsl -d guix --exec /busybox sh
<danderson>drakonis: dude, I'm an SRE. When the system gives me noises about being broken, I care.
<dstolfa>danderson: might be worth checking how the service is specified
<danderson>"oh those are just normal errors, ignore them" is not very encouraging :/
<danderson>hm. Well, I didn't specify it, so I guess it's time to track down where that definition comes from.
<The_tubular>dstolfa any clue ?
<danderson>(separately, I started this whole thing because I wanted to reconfigure sshd to permit root pubkey login, and even with the new config applied it won't let me, so...)
<dstolfa>The_tubular: not really, sorry :/. i don't use windows personally
<The_tubular>Yeah, I wish I wasn't using Windows too :/
<dstolfa>The_tubular: it *should* work though, but it obviously has issues and i don't really have a way to troubleshoot since i don't have windows here to test on
<dstolfa>danderson: maybe this is relevant still today?
<dstolfa>in any case, mailing lists are you friend in this case i think
<drakonis>i'm not sure what even provides term-auto
<drakonis>i'm grepping the repository
<danderson>I mean, it helps in the sense that it tells me these errors have been ignored by everyone for the last 3 years. Can't say that reassures me much, but I'll let it go I guess.
<drakonis>explore the system first
<danderson>ah, and despite guix system reconfigure's noises about restarting services, it hadn't restarted sshd, which is why my config change wasn't visible.
<drakonis>weird though?
<danderson>I am exploring the system. I'm attempting to do the things the manual tells me, and finding problems. You telling me that I'm exploring wrong when I'm trying to do that the manual says isn't helping :(
<drakonis>but fair enough
<drakonis>hmm, i dont know if i can help you properly
<danderson>But usure, now that I've given up on this particular weirdness, I'll keep exploring.
<dstolfa>danderson: might be worth documenting the weirdnesses you've encountered and shooting an email off to the mailing list that describes them
<dstolfa>all of these things you're hitting are worth fixing
<danderson>sorry if I sound frustrated, it's because I am. Maybe it's time for me to walk away, honestly.
<danderson>sure, I'll do that.
*dstolfa -> bed
<vldn>The_tubular hey i'm running guix on wsl :)
<vldn>i made a gist because the github doc you mentioned was way too complicated
<The_tubular>Ohh, mind sharing it to me :D ?
<vldn>i comment with my gist on the bottom
<vldn>i hope it helps with your problem
<The_tubular>Giving it a try right now
<vldn>it is not really built for other people running it in a whole, maybe try it command by command for your needs or modify the script and then run it :)
<The_tubular>Thanks a lot
<The_tubular>Yeah, I'll read a bit on what it is doing and what I was doing wrong
<vldn>i also used a prebuilt busybox and started from there (like the first command)
<vldn>have fun :)
<The_tubular>Does that mean that busybox won't be tracked by guix?
<vldn> instead of building my own rootfs like the other github doc you mentioned proposed
<vldn>thats what i ment
<The_tubular>Haa gotcha
<vldn>download it from the release page
<vldn>go to your cmd.exe shell and run :
<vldn>wsl --import guix /guix rootfs.tgz --version 2
<vldn>wsl -d guix /bin/busybox sh
<vldn>then you got your busybox shell and can run alle the commands in my gist
<The_tubular>Gotcha ^^' It's my first time running guix so the second part that is confusing me is all the guile stuff :P
<The_tubular>Like why do you define a file system if Windows already makes it for you ?
<vldn>the guile part is the guix system configuration
<vldn>wsl is creating a virtual filesystem for the wsl parts
<vldn>and there guix system needs to know where the root file system "/" lives
<vldn>try to run "df -a" in the busybox shell and you'll see something like this
<vldn>tools 96.3G 56.1G 40.2G 58% /init
<vldn>none 3.0G 0 3.0G 0% /dev
<vldn>tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup
<vldn>none 3.0G 1.0M 3.0G 0% /run
<vldn>none 3.0G 0 3.0G 0% /run/lock
<vldn>none 3.0G 0 3.0G 0% /run/shm
<vldn>none 3.0G 0 3.0G 0% /run/user
<vldn>tmpfs 3.0G 0 3.0G 0% /mnt/wsl
<vldn>C:\ 96.3G 56.1G 40.2G 58% /mnt/c
<vldn>G:\ 812.5G 647.5G 165.0G 80% /mnt/g
<The_tubular>Gotcha, I'll have fun hacking on it for a few hours, try to understand basic guile, I'll hit you up later if I have some more question :)
<The_tubular>Anyway, it's just a small, VM. I can just blow it and start another one if I do something stupid
<vldn>you are not supposed to run the guile part, it is piped to the guix system reconfigure command (the last in the
<vldn>a bit much to begin with but you'll have fun :)
<vldn>just comment the gist if you got questions and I'm not online
<vldn>good night
<The_tubular>Yeah, I understand what guile is. Watched a few talks of guix. I just doubt I'm able to write a package definition as of now :P
***ec_ is now known as ec
<apteryx>ecbrown: i'm about to push the new qt 6.1.1 package as a base to your patch series
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, yoctocell says: have you seen ? Sometime ago you mentioned that the generated docs for service configurations had a different style compared to the hand-written ones. This should fix that.
<apteryx>sneek: yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet.
<apteryx>sneek: later tell yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet.
<sneek>Got it.
<The_tubular>Is there somewhere I can see what exactly is include in %base-package ?
<flatwhatson>The_tubular: guix repl > (use-modules (gnu system)) > %base-packages
<mothacehe>hey guix!
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: looks like Cuirass can't build, say, 'version-1.2.0', due to assumptions about the (gnu ci) module i think; thoughts?
<mothacehe>mmmh right, I should maybe backport some changes to this branch.
<civodul>Hello Guix!
<mothacehe>hey civodul!
<solene>efraim: hello, I don't understand what you changed in my gnumeric patch
<solene>I'm trying to send patches with no issue, improving each time I get feedback what I don't understand here
<efraim>solene: the from line appeared like this: From: Solene Rapenne via Guix-patches via <>
<efraim>To be honest I have no idea why it does that sometimes
<tissevert>hi guix
<Horizon-1207>Greetings. I have an amd ryzen 7 radeon vega & gpu picasso hardware, will the 1.3 release or the latest Guix work if I install? Thank you
<apapsch>Horizon-1207: your best bet is if the installer boots, the installed system will boot as well
<Horizon-1207>apapsch: thanls, Ill give it go!
<Horizon-1207>apasch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards
<Horizon-1207>apapsch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards
<apapsch>Horizon-1207: I remember a conversation here a few days ago that revolved around amdgpu driver not having the firmware for a card. You should see a message via dmesg. If you are affected, you are out of luck in a pure libre system
<itd>nckx: re hg-reference-recursive? [1], in case you care: ; thanks again [1]:
<Horizon-1207>apapsch: I was thinking of trying trisquel as that pure libre and if tht works guix should work, assuming same kernel?
<roelj>When running 'guix gc --verify=contents,repair' I get 'guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed'. Any ideas?
<nckx>itd: I always care! Thanks, I'll apply it right away.
<nckx>roelj: Eh, sounds like DB corruption… I'd try an ‘sqlite3 /var/guix/db/db.sqlite’ ‘pragma integrity_check;’ before you try anything else.
*nckx → awayzors.
***pinoaffe1 is now known as pinoaffe
<apapsch>Horizon-1207: I wouldn't bet on it, the versions and configuration may differ much
<Horizon-1207>apapsch: its more to do with the kernel, as 5.4 added support for amdgpu (i think), but not sure if it's libre?
<nckx>Knowing AMD (and GPUs), probably not.
<Horizon-1207>nckx: it seems the drivers are open but a binary blob is needed to use it!
<nckx>AMD have successfully misled most free software users into calling their tiny GPL-compatible loader for proprietary binary blobs a ‘driver’. It's sad.
<jonsger>i don't think their "tiny GPL-compatible loader" is really tiny
<mothacehe> /query jonsger
<civodul>mothacehe: hey! i have issu^W interesting feedback regarding :-)
<civodul>one of them is that i enabled substitutes and Cuirass seems to think that stuff that was substituted did not "succeed"
<civodul>hence "35%" for the 'guix' jobset
<mothacehe>civodul: hey! interesting indeed, you enabled remote building right? Could you provide me the cuirass-remote-server.log file?
<civodul>mothacehe: sure! lemme see
<civodul>mothacehe: there are two workers, here's one:
<civodul>looks legit
<mothacehe>ok the issue seems to be on the remote-server side
<thorwil>hi! i’m trying to package mda.lv2 ( it has a `waf configure --prefix`, but also `waf install --destdir`. alternatively, it checks a DESTDIR environment variable.
<thorwil>not entirely sure just setting prefix is the thing to, but that’s what i started with. only: error: Failed to import waf (cannot import name 'Context' from 'waflib' (unknown location))
<thorwil>command "python" "waf" "configure" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" failed with status 1
<civodul>mothacehe: remote server log looks like this:
<civodul>hi thorwil!
<civodul>waf is a bit special because it's entirely bundled
<civodul>did you use waf-build-system?
<mothacehe>civodul: ok so the remote-server is trying to fetch substitutes from the workers but it hangs (113 items in the fetch queue)
<mothacehe>could you try to run something like: "wget http://the-remote-server:5558/nar/06f8z9956nz03pnxp2hq31v1dgf2mbjb-jupyter-1.0.0?
<mothacehe>no sorry, http://the-remote-worker:5558/nar/06f8z9956nz03pnxp2hq31v1dgf2mbjb-jupyter-1.0.
<mothacehe>from the server
<civodul>mothacehe: so from localhost, right?
<mothacehe>from the machine running the cuirass-remote-server yes
<civodul>so "wget -O - | guix archive -t" (from the head node) works initially (it shows the first few files) but quickly hangs
<civodul>yeah it systematically hangs after 6.09KB
<mothacehe>i know :)
<mothacehe>that's related to the keep-alive mechanism introduction
<civodul>ah ha!
<civodul>in 'guix publish'?
<mothacehe>the workers are probably running an older daemon
<civodul>yes, could be
<civodul>but here's i'm talking to a 'guix publish' instance of the workers, right?
<civodul>so the worker's guix-daemon version shouldn't matter, should it?
<mothacehe>oh then it's the other way around
<civodul>but here wget is opening a single connection, so no keep-alive?
<civodul>ah well, "wget --debug" shows it's passing "Connection: Keep-Alive"
<thorwil>civodul: yes, (build-system waf-build-system)
<mothacehe>yes if you pass something like -H "Connection: close" it should work
<civodul>it works with --no-http-keep-alive
<civodul>we're on the right track :-)
<mothacehe>so you may need to update the guix-daemon on the machine running the remote-server so that the "guix substitute" script is updated with 0b8fa24b
<civodul>yeah the head node is currently running guix-1.3.0-2.9f2b2c4
*civodul upgrades
<civodul>now it's running guix-1.3.0-3.50dfbbf
<civodul>but wait, the problem is on the worker's 'guix publish', no?
<mothacehe>if the worker's guix-publish is now respecting the keep-alive mechanism, and doesn't hang-up at the end of every NAR transfer, then on the remote-server side must be updated
<mothacehe>*the "guix substitute" script must be updated
<civodul>still, wget shouldn't hang
<mothacehe>it won't hang for /nar/gzip as the content-length is passed properly
<mothacehe>for raw nars, wget cannot know when the transfer is over
<civodul>but "guix archive -t" should know?
<civodul>not entirely sure
<mothacehe>oh wait
<dstolfa>hello guix
<mothacehe>guix substitute knows the length because its asks the narinfo beforehand put I wasn't aware of "guix archive -t"
<thorwil>apparently there should be a waflib, but the tarball for mda.lv2 comes with an empty "waflib" folder. bbl.
<civodul>mothacehe: "guix archive -t" parses the raw nar, but the nar itself doesn't have a clear end marker
<civodul>in HTTP terms though, there should be "something" happening when the response is complete no?
<mothacehe>when the server is able to send the content-length everything works fine, as Guile http-get will do the right thing. When it's not the case, as there's no nar end marker, the client cannot know when the transfer is complete
<mothacehe>and the server must not hang-up to respect the keep-alive
<mothacehe>leading to this wget hanging
<apapsch>on boot there are some messages printed on the console by services which is then removed by the login prompt. is it possible to retrieve or persist the messages?
<itd>nckx: Sorry, didn't mean to offend. Thanks for your quick response! (Yay, now `guix import json` works for me.) :)
<cbaines>civodul, I haven't looked much at the guix publish code, but the Guix Build Coordinator uses chunked transfer encoding with HTTP for transfering nars when the size is unknown
<cbaines>that way you send chunks with the size, then an empty chunk to signal the end
<mbakke>bauermann: that is great news, thanks! fingers crossed :-)
<civodul>cbaines: ah yes, makes sense; 'guix publish' does no such thing, which i guess is a problem we didn't notice until now because the connection would be closed upon completion
<civodul>so maybe keep-alive should have no effect on /nar URLs when --cache is not in effect
<civodul>(this is getting complicated)
<civodul>mothacehe: ↑ WDYT?
<civodul>that said, "guix archive -t" & co. should see the end of nar, weird
<mothacehe>Using keep-alive without --cache is required for Cuirass, otherwise there the remote-server guix-publish server is flooded on Berlin, causing those errors:
<mothacehe>we could implement what Chris is proposing
<mothacehe>but that's complex, if the only goal is to have wget on /nar working
<mothacehe>when wget --no-http-keep-alive does the trick
<irfus>how do I use a module provided by some channel for a package definition in a different local channel?
<abcdw>hi guix!
<sneek>Welcome back abcdw, you have 2 messages!
<sneek>abcdw, ixmpp says: im happy with yoctocell's patch, merge as you please. Would reply but's anti-html thing is a shitfest im not gonna play part of
<sneek>abcdw, ixmpp says: why keep this? It massively threw me off just now
<civodul>mothacehe: yes, and chunked encoding prevents sendfile(2)
<abcdw>ixmpp: Some of that I use for reference, I didn't complete the migration of all necessary stuff for me to rde.
<civodul>mothacehe: flooding is due to a client-side bug, hopefully fixed by (by cbaines), right?
<mothacehe>civodul: I think the problem is that guix-publish doesn't keep up when multiple workers are requesting substitutes at the same time, without keep-alive. The worker connection requests cannot be honored in less thn 5 seconds (connection timeout), causing this:
<abcdw>civodul, leoprikler, roptat: I would like to get a commit access to work on Guix Home migration from rde repo to guix-home branch of guix repository. Can you vouch for me, please?
<mothacehe>Since the keep-alive fix deployment I haven't seen this error
<mothacehe>but there are still some "server is somewhat slow" substitute warning denoting that guix-publish is a bit under water
<leoprikler>Do I qualify for vouching? I don't recall having reviewed any of your work on the ML.
<leoprikler>(Or maybe I'm bad in mapping IRC nicks to mail addresses.)
<abcdw>leoprikler: I don't have too much work on guix ML, but we had few discussions on emacs build system. I'm Andrew Tropin BTW)
<civodul>abcdw: i'll sure do! could you email guix-maintainers once you have three people?
<civodul>mothacehe: thing is, 'guix publish' is single-threaded...
<civodul>so either we "do it right" and fiberize it
<civodul>or, at least as a short-term fix, we add a tiny bit of nginx caching
<leoprikler>This is my first time vouching for someone. Are there any formal requirements or is "I'm vouching for Andrew" enough?
<mothacehe>civodul: oh nginx caching is the reason we don't have much "somewhat slow" warnings when using the publish server at
<civodul>leoprikler: no formal requirement, but it implies that you trust abcdw to "follow the rules"; ideally you'd mentor them when they get started
<civodul>perhaps a discussion to be had beforehand together
<mothacehe>the fiberized web server that cuirass-web uses seems to perform nicely, maybe we could also use it for guix-publish
<civodul>mothacehe: there's nginx but no caching at (i removed it a while back)
<civodul>i liked the idea of a simple/simplistic 'guix publish', but maybe that's no longer an option
<civodul>we should understand exactly where those "somewhat slow" diagnostics come from, though
<mothacehe>yes you're right that would be a first step
<mothacehe>perf on the cuirass publish server should help us
<civodul>workers talk to the main 'guix publish', no?
*civodul is confused :-)
<mothacehe>remote-server is spawning a guix-publish
<mothacehe>all workers talk to this guix-publish
<mothacehe>each worker spawn a guix-publish
<mothacehe>that the remote-server uses to fetch build results
<civodul>ah ok, so contention on Cuirass's publish should not affect
<civodul>we do see "somewhat slow" messages on, though
<civodul>since ~1.3.0 more or less
<civodul>so something must be wrong somewhere
<mothacehe>yes, but there are way more present on Cuirass
<mothacehe>hence my nginx caching question
<civodul>is the "somewhat slow" diagnostic even correct?
<abcdw>civodul: Sure, will drop a message!) Do 3 maintainers should send their vouch messages separately before I describe my intents or they can just reply to my thread?
<mothacehe>civodul: not even sure about that
<civodul>abcdw: typically vouchers email guix-maintainers individually, and you can also email guix-maintainers (or guix-devel) individually describing your goals
<abcdw>civodul: Good. Will send a brief plan, once I get 2 more responses)
<irfus>ah, nvm, got it. I need to add a channel dependency.
<civodul>abcdw: alright! do take a look at the "Commit Access" section of the manual, too
<civodul>we can discuss details if you want
<jonsger>abcdw: whats your name/mail address?
<abcdw>jonsger: Andrew Tropin andrew [-at-]
<jonsger>abcdw: ah, you are involved in this guix-home thing :)
<abcdw>jonsger: Yup) Work with yoctocell on Guix Home. The repo is here: The documentation is here:
<muradm>hi, emacs with gcc pgtk plans? anything better than ?
<leoprikler>emacs-next-pgtk is a package in Guix, what's the difference to flatwhatson's package?
<flatwhatson>native compilation, xwidgets
<abcdw>civodul: Read this section a few times already) Only thing is that I use SHA-256, not SHA-512, but I think it's ok)
<muradm>seems to be nothing better :)
<muradm>flatwatson: are you merging gcc and pgtk your self?
<abcdw>flatwhatson: There are xwidgets in emacs-next-pgtk BTW.
<abcdw>muradm: gcc in master, pgtk merges changes from master from time to time.
<ixmpp>So why is gcc not in emacs-next-pgtk?
<muradm>it is not by default enabled afaik
<flatwhatson>none of the guix packages have native-comp enabled in the build
<flatwhatson>i think it got a bit mired in discussions of package options?
<abcdw>ixmpp: Because gcc was not at master, when I wrote emacs-next-pgtk package definition.
<muradm>now it is, may be it is time for next?
<flatwhatson>abcdw: good to know and thanks :)
<ixmpp>Im surprised people dont pester flat to upstream those
<abcdw>muradm: There are some new bugs in latest pgtk commits, so I'm not sure that it's a good idea to update emacs-next-pgtk right now, especially with new build flags.
<flatwhatson>guix makes it pretty easy to use a channel, so i guess it's not that annoying
<abcdw>flatwhatson: ;)
<muradm>abcdw: is there any sw without bugs? :) as name suggests it is "next" :)
<flatwhatson>the stable emacs package is there
<muradm>btw, flatwatson's is with libgccjit-10, guix still has 9 in packages
<flatwhatson>i would consider going to gcc-11, but i didn't want to punish everyone with bootstrapping a new libgccjit
<flatwhatson>got enough bug reports about OOMs :P
<abcdw>muradm: Few of them is hitting me right now on emacs-next-pgtk-latest and emacs-next-pgtk doesn't have them) Anyway, I think it will be updated one way or another in some near future.
<flatwhatson>actually the libgccjit build could also do with some trimming, i don't think a fully-bootstrapped gcc is necessary, there are other things to turn off for a "gccjit-only" build
<muradm>abcdw: dodging bugs is part of business here)
<muradm>any way, thanks for info
<civodul>mothacehe: anyway, the guix-daemon upgrade on the head node did the trick and is back at 100%
<civodul>mothacehe: by second issue is those -1.2.0 jobsets, which don't work, but we can discuss it later
<mothacehe> yes i saw, nice :)
<mothacehe>I fixed the guix-1.2.0 spec
<civodul>what do you mean?
<mothacehe>I backported some stuff to gnu/ci.scm in version-1.2.0 branch
<mothacehe>which fixes your guix-1.2.0 spec
<civodul>ah good
<mothacehe>it doesn't fix guix-hpc-1.2.0 and guix-past-1.2.0
<mothacehe>because they use the "channel" build type
<mothacehe>which is hard to backport
<civodul>yes, and not necessarily desirable
<civodul>IWBM™ to rely on as little code as possible from the target Guix
<mothacehe>true, you can still rely on some manifests for those specifications
<civodul>actually my colleagues want a mixture of channels + manifests
<civodul>so essentially a sophisticated manifest, i guess
<mothacehe>I introduced the custom build type
<mothacehe>which is an awful hack to build whatever you want
<mothacehe>from a channel script
<civodul>ok, but i think manifests are already custom enough
<civodul>where's the manifest file looked up?
<civodul>in the same repo as the channel?
<mothacehe>in all channels is I recall correctly
<civodul>i see, thanks!
<civodul>fun fact: i turned my previous head node into a build node, and with unattended upgrade it reconfigured itself back as a head node during the week end :-)
<mothacehe>haha the machine is taking the control
<civodul>yup, it's artificial stubbornness!
<efraim>I tried setting JULIA_NUM_THREADS to parallel-job-count and it slowed down the build :/
<daviwil>Seeya, Matrix bridge
***link2xt[nm] is now known as link2xt
<abcdw>civodul: The draft of the plan:
<civodul>abcdw: looks nice to me :-)
<civodul>you can add "write a blog post" there ;-)
<civodul>would be good to popularize the concept and tool once it's merged
<dstolfa>i don't think that will be very hard civodul
<dstolfa>a lot of us are already waiting for it
<apteryx_>hello Guix! Quick check; supposed I was to build some package (e.g. qtbase) using a custom toolchain made of our current GCC (7.5) and an old glibc (we have 2.28), I should be able to link against it on any GNU/Linux system that has a glibc >= 2.28, correct?
<abcdw>civodul: Sure, will add a Finalization section to the document!)
<civodul>apteryx_: hi! maybe you don't even need an old glibc; what matters most is the minimum kernel version required by glibc
<civodul>unless you want to build a custom pack stripped of Guix's own libc
<apapsch>is there a way to to get details about "invalid G-expression input"? I have a hard time figuring out what is invalid
<civodul>apapsch: usually it means you're "inserting" something in the gexp that cannot be "lowered" to a file in the store
<civodul>for example, if you do #$(begin foo bar #$(current-module)), you'll get that error
<civodul>because (current-module) returns a <module> record that cannot be lowered to a file
<apapsch>ah, I see it now, a procedure that wasn't invoked but passed as value, thanks
<apapsch>my paren fu is lacking
<apteryx_>apapsch: emacs + paredit changed my life
<apapsch>apteryx_: I have the Perfect Setup set up, though without the fu it ain't enough. It's an immaterial thing not obtainable via guix install ;-)
<apteryx_>civodul: the idea would be to build the target application (e.g., jami-qt) with Guix's Qt but otherwise using the system's native libraries (e.g. Debian 10's own libraries but with Guix's Qt). Since the linking would be made by Debian 10's glibc, the glibc used to build Guix's qt would need to be older on equal than the glibc of Debian, no?
<apteryx_>apapsch: OK! Nice. It's all about practice then, which is the fun part :-).
<apteryx_>err, the linking would be made by Debian's linker, rather. Which would link using the Debian's glibc symbols, IIUC.
<civodul>apteryx_: you should check with dongcarl who did something like that for Bitcoin Core, IIRC
<civodul>that requires some surgery though, such as changing the loader's file name and stripping RUNPATH
<civodul>we could make that an option for 'guix pack'
<civodul>(though i won't handle bug reports :-))
<apteryx_>hehe, OK, I will look into that and perhaps ping dongcarl, thank you
<apteryx_>or go directly to the .deb guix pack generator :-)
<apteryx_>I started looking into that and it doesn't seem too difficult to achieve
<civodul>yeah, i guess we could run code in a Debian VM, and possibly use checkinstall
<apteryx_>the .deb format is very simple; we just need to provide three files; two which are metadata and one which is the file system tarball
<iskarian>when sending a patchset, is it still recommended to use `--in-reply-to=... --no-thread` when sending to (in reply to the cover letter)?
<apteryx_>I think the difficulty would be in the details, such as when wanting to install different Guix-generated .deb files that would own the same set of /gnu/store files, they'd likely conflict together.
<civodul>oh right
<civodul>i was thinking about .deb files containing an FHS layout
<apteryx_>OK, yeah that's for the to be written --fhs option ;-)
<apteryx_>hmm, why isn't (specification->package "gcc@7") valid? It says: gcc: package not found for version 7.
<apteryx_>we do have a "gcc" named package at version 7.5.0.
<apteryx_>is it because it's hidden?
<civodul>apteryx_: it would have been good to keep (define qtbase qtbase-5)
<apteryx_>that means we have a couple broken examples in the doc, e.g.: guix edit gcc@4.8
<civodul>otherwise it could break channels
<civodul>apteryx_: there's a "gcc" alias for "gcc-toolchain"
<civodul>the goal being so "guix install gcc" is effectively "guix install gcc-toolchain"
<apteryx_>yeah, I did it that way based on previous feedback from Mark w.r.t. to inkscape. They were surprised that inkscape in their manifest would not resolve to the latest and greatest.
<apteryx_>it does come at the cost of more code changes (though automated) and more disruption for channels.
<civodul>yes, i think the change is the right way to handle transition; i would just add (define qtbase qtbase-5)
<civodul>which would later be changed to (define qtbase qtbase-6)
<apteryx_>I see, that seems a good thing indeed. I'll try it now.
<civodul>i have Qt-related build failures starting from this commit:
<civodul>though it's kinda weird because the qtbase@5 derivation hasn't changed, presumably, right?
<apteryx_>it shouldn't
<ecbrown>apteryx: sounds awesome! good luck
<apteryx_>civodul: but perhaps I've missed something
<apteryx_>w.r.t. to the specification->package not working for 'gcc', do I understand that it's an understood consequence of adding the 'gcc' alias?
<civodul>(specification->package "gcc") does work, thanks to the alias
<apteryx_>but not (specification->package "gcc@7") on any specified version
<civodul>right, see gcc-toolchain-aka-gcc in commencement.scm
<civodul>it's defined just for one version
<civodul>pretty arbitrary!
<apteryx_>I see :-)
<apteryx_>that's a weird Qt error to have following my change; I don't have an explanation in mind.
<apteryx_>that paraview package comes from a channel?
<apteryx_>civodul: just realized, in my case (specification->package "gcc@7") was used in a manifest in constructing my custom c-toolchain; what I really want to get is the lonely gcc package rather than the toolchain. Seems I'll have to use the gcc-7 variable directly.
<apteryx_>civodul: note that if we add (define qtbase qtbase-5), the same will also be needed to be done for each qt module (define qtsvg qtsvg-5) when they get updated (there's a patch in review from ecbrown upgrading many qt modules for version 6)
<apteryx_>civodul: for the error you see (qt 5 not being found), I guess I missed some reference to it somewhere, and it's now at qt 6 in your build, causing it to not be found
<apteryx_>but that's just a guess
<ecbrown>(not to but in but i expect if a new package arrived with qt it may not have gotten the -5 treatment)
<apteryx_>ah, given that's in a channel, it didn't get the automatic rewriting treatment
<apteryx_>so that explains it
<apteryx_>all your qtbase references in your channel are now at qtbase-6
<apteryx_>afte we add (define qtbase qtbase-5) that build failure will probably go away.
<apteryx_>hmm, thinking more about it, I don't really like the idea of having qtbase point to qt5. It means we wouldn't likely be able to have the qtbase variable be at qtbase-6 for a year or more (I'm expecting the transition will take a lot of time, similar to Python 2 -> Python 3).
<civodul>apteryx_: you cannot refer to 'gcc' (the variable) via specification->package, because it's hidden
<ecbrown>no it should point at qt6
<ecbrown>now or never ;-)
<apteryx_>civodul: so I'd just suggest running the commands found in ea0a51071e68c37a4c9c25421cf03bc2f442c67b to automatically migrate your channel. Does that sound reasonable?
<civodul>apteryx_: actually that paraview package refers to the 'qtbase' variable, so evaluation should have failed:
<apapsch>given a one-shot service that is a requirement of a daemon service, the daemon service will start as soon as the one-shot service is successfully started, no? one-shot must not complete before daemon is started?
<civodul>apteryx_: i'm fine with running sed on my channel, np, but it still sounds useful to keep a 'qtbase' variable
<apteryx_>If qtbase was to point to qtbase-6, how would it be useful? In my opinion, Qt5 users should use qtbase-5 from now on, the same Python 2 users must specificy python-2 :-)
<ecbrown>people would have 64-bit containers everywhere
<ecbrown>QMap will no longer blow up when moving from laptop test cases to SMP
<ecbrown>but retains 32-bit for those platforms
<ecbrown>that need it
<abcdw>Have a good evening, Guix!)
<ecbrown>Qt5 compatility exists in the Qt5Compat module, and guix accomodates legacy users with -5 versions already patched up
*ecbrown ends sales pitch for qt6 being default
***apteryx_ is now known as apteryx
***natrys is now known as _natrys_
<wenngle>New to Guix System, trying to configure SDDM as a display manager, but I get the error: service 'xorg-server' provided more than once. I'm using the service modules desktop sddm and xorg. How can I resolve this?
<tissevert>hi wenngle
<ecbrown>wenngle: perhaps you have to (delete (gdm-service-type))
<tissevert>it's probably because the default display manager hasn't been deactivated and still provides xorg
<dstolfa>i think you have to (modify-services %desktop-services (delete gdm-service-type))
<dstolfa>in your (services ...)
<wenngle>dstolfa: I do have that in my config
<dstolfa>could you share your entire configuration?
***_natrys_ is now known as natrys_
<ecbrown>wenngle: also make sure there is not a a stray extra %desktop-services
<dstolfa>there might also be the keyboard being provided
<iskarian>wenngle, are you saying you explicitly have (service xorg) in your (services ...)?
<dstolfa>if you have a keyboard configuration, it will provide xorg
<dstolfa>(for xorg at least)
*ecbrown flames about gdm causing suspend when at gui login window
<wenngle>dstolfa: here
<dstolfa>wenngle: get rid of (xorg-configuration ...)
<dstolfa>that's providing your second xorg
<dstolfa>though, i'm not sure how you're supposed to configure xorg then, but i'm pretty sure that (set-xorg-configuration) is the issue in this case
<dstolfa>because that's what the issue was for me
<wenngle>dstolfa: where do I put the xorg configuration then? Without configuring the refresh rate, my monitor will not work.
<dstolfa>i have no clue unfortunately :/
<mothacehe>civodul: you are the first officiel Cuirass badge user, congrats ;)
<wenngle>dstolfa: Oh well, thanks for the help.
<civodul>mothacehe: and a happy badge user :-)
<civodul>very cool
<civodul>apteryx: oh you're right, i thought qtbase@6 hadn't been pushed yet, apologies for the confusion!
<civodul>so yes, i'll definitely update those packages :-)
<mothacehe>hehe, thanks :) they are maybe a bit large compared to "standard" badges
***natrys_ is now known as natrys
<civodul>yes, but it's scalable! :-)
<apteryx>civodul: np. Glad the resolution is an agreeable one :-)
<civodul>apteryx: besides, thumbs up on getting qt6 in shape!
<civodul>i expect to have a 100% badge again soonish
<apteryx>civodul: thanks! ecbrown has made a lot of work too on the the qt modules (in review)
<raghavgururajan>Hello Guix!
<iskarian>wenngle, the (set-xorg-configuration ...) should be fine, see:
<iskarian>I'm no scheme expert, but I haven't seen guix use cons*, usually I see (append (list ...) ...)
<civodul>apteryx: neat! i feel like we should have tools that automatically try s/qtbase-5/qtbase-6/ on all the dependents
<dstolfa>iskarian: the issue crops up when you use sddm as a DM, it works when you don't
<dstolfa>i don't know why this happens
<dstolfa>cons* is fine
<civodul>cons* is fine; it's rather obscure to newcomers though, which is why documentation resorts to (append (list ...) ...)
<dstolfa>it would be worth chasing down in any case, (service sddm-service-type) shouldn't cause (set-xorg-configuration) to not be happy
<raghavgururajan>Speaking of badges, any more thoughts on Guix Badge (
<iskarian>oh, in that case you can use (service sddm-service-type (sddm-configuration (xorg-configuration (xorg-configuration (extra-config ...)))))
<raghavgururajan>> civodul‎: i expect to have a 100% badge again soonish
<raghavgururajan>What badge you were referring to?
<bsima>does the guix world have any thoughts on nix flakes?
<lispmacs[work]>raghavgururajan: not sure if you were looking for my opinion, but the badges in the 48827 issue look good. If you wanted me to be really picky, I'd probably suggest /thinking about/ maybe a slightly simpler logo text, like "GNU Guix ready"
<lispmacs[work]>sometimes simpler phrases are more catchy
<lispmacs[work]>but your wording certainly communicates more
<dongcarl>apteryx: I see that I was pinged, still need help?
<raghavgururajan>lispmacs[work]: I see. Thanks for the input. :) I'll look into it.
<apteryx>dongcarl: thanks for asking :-). I'm investigating the feasibility of having qtbase built by Guix, and used as part of foreign builds (Debian, Fedora, etc.). My simplest idea is to 'guix pack qtbase', then point the foreign build system to it so that it can be used linked against by the native build. I've read that for this to work, usually the linker/gcc must be newer than any of the constituting
<apteryx>parts, so perhaps I'd have to downgrade the glibc used to build qtbaes on Guix. Any thoughts?
<apteryx>civodul: that could be useful, although we are not ready yet because most qt packages will not only depend on qtbase but also on the qt modules (e.g., qtsvg), which need to be updated first.
<apteryx>civodul: strangely, when building qtbase using a gcc-toolchain made using the 'make-gcc-toolchain' helper, the implicit input named "libc" doesn't seem to exist among the builder inputs; (assoc-ref inputs "libc") apparently return #f, breaking qtbase's patch-paths phase. Any idea why that might be?
<ixmpp>$ guix home build -L . (echo '((@ (gnu home) home-environment))' | psub)
<ixmpp>guix home: error: '/tmp/.psub.BNciJvBgSh' does not return a home configuration
<ixmpp>Im lost for words now
<ixmpp>How has this got so broken
<roptat>is home-environment a function?
<roptat>what's psub?
<ixmpp>This fails for all my versions of my home config now
<ixmpp>(echo "blah" | psub) == <(echo "blah")
<ixmpp>I tried time machine too, no luck
<ixmpp>I dont know whats wrong
<roptat>the time machine wouldn't go back in time on other channels, so maybe it's an issue in the guix home chanel?
<ixmpp>I used -C though
<ixmpp>I also just tried a few old guixes, no luck
<roptat>can you run that in a repl?
<ixmpp>If i run (home-environment? (home-environment)) its true
<ixmpp>So it makes so little sense
<roptat>is this home-environment really the one that comes from (gnu home)? could it come from somewhere else?
<ixmpp>Not to mention, my home-config that worked fine til now suddenly doesnt work
<ixmpp>Its definitely that
<roptat>could it be that there are two conflicting (gnu home) modules somewhere?
<roptat>(I don't use guix home, so I help too much ^^)
<ixmpp>Maybe, actually! I'll test removing one
<Noisytoot>What is guix home?
<ixmpp>roptat: Clever man! I removed guix-home-manager, guess it was conflicting with rde
<apteryx>civodul: with a pk I can see that indeed the implicit build inputs seem to be hidden when using a custom gcc-toolchain:
<roptat>ixmpp, oh, there's no (gnu home) in guix home manager I think, but it does add a "guix home" command
<ixmpp>No wonder
<roptat>so guix was confused which one to run ^^
<roptat>Noisytoot, that's the home manager, guix home a different project with similar goals
<apteryx>civodul: the diff of the inputs when using a custom toolchain; seems the toolchain inputs usually appearing flatly in the bag are now hidden behind the "toolchain" package:
<muradm>i'm trying to use libgccjit for emacs, is there any example on how to use it with other package?
<muradm>just puting it to native-inputs or inputs does not work
<muradm>ld: cannot find crtbeginS.o: No such file or directory
<muradm>ld: cannot find -lgcc
<muradm>snippet here:
<muradm>ripgrep, no uses of libgccjit in guix at all...
<ixmpp>A library that nobody uses but still got added, that seems a familiar situation
<ixmpp>Where are the cries of "maintenance burden" and "needs uses"
<jackhill>I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code.
<daviwil>libgccjit will get used by Emacs as soon as 28 drops, provided that maintainers turn on the native comp feature for the main Emacs package
<dstolfa>daviwil: you're sending empty messages
<daviwil>Wow, sorry for the blank lines there, no idea what ERC did
<dstolfa>heh :D
<jackhill>muradm: an emacs-native-comp examples:
<muradm>jackhill: yeah, copy paste of those magic phases helps, but why magic
<jackhill>hrm, although looks like that channel defines it's own gccjit
<jackhill>muradm: I haven't studied it in detail yet, sorry
<muradm>jackhill: yes, i know, today was my fifth attempt to build it, but no patience, libgccjit takes like forever to build
<daviwil>yeah, it's painful waiting for that to build
<muradm>guix has libgccjit-9 built already
<muradm>but using it another pain.. )
<jackhill>yeah, I read the gccjit documentation once, but haven't yet had the oppertunity to get into it more.
<ixmpp>> jackhill wrote:
<ixmpp>> I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code.
<ixmpp>I was lamenting the fact that this is the exact reason libsystemd hasnt been added
<ixmpp>Doublestandards etc
<muradm>i would not add libsystemd also ) shepherd is more than fine, guix hosts me until there is no systemd
<dongcarl>apteryx: This is likely what you want:
<muradm>ixmpp: why need libsystemd any way?
<ixmpp>muradm: I had a program that depends on it
<dongcarl>apteryx: Oh, you can also construct a gcc-toolchain targeting any glibc version with make-gcc-toolchain
<ixmpp>But apparently while thats enough of a reason for any other library, it's not for this one
<apteryx>yeah, I've tried the make-gcc-toolchain helper, but it seems to mask the implicit inputs from under "toolchain", which breaks some phases (e.g., (assoc-ref inputs "libc") now returns #f).
<apteryx>dongcarl: thanks for the link!
<muradm>ixmpp: i would argue that libgccjit is very core thing to execution of binaries, libsystemd is diffrent thing.
<muradm>it is like distro without glibc
<daviwil>I'm not even sure what libsystemd would even do without systemd running
<ixmpp>> jackhill wrote:
<ixmpp>> I think it's okay to add libraries that aren't (yet or ever) used by Guix packages. Folks may want to use them in their own code.
<daviwil>Maybe this program can be built without the dependency with a compiler flag?
<muradm>eactly, to put libsystemd, you need to pull systemd ecosystem in
<dongcarl>apteryx: Hmm you might want to compare make-gcc-toolchain with the gnu-build-system and see how they compare
<dongcarl>Also worth looking at: build-system-with-c-toolchain
<muradm>ixmpp: what is that important program that dependes on libsystemd?
<muradm>ixmpp: bad program, by any means should be optinal..
<muradm>imho )
<muradm>this compiles emacs with gcc and pgtk inheriting emacs-next-pgtk using libgccjit-9 from guix, much faster
<muradm>checking if it working at all :)
<muradm>thanks to magic from flatwatson of course
<apteryx>dongcarl: thanks
<apteryx>are there any differences between .lzma and .xz archives?
<jackhill>systemd sounds like its special software, so probably takes more wrangling than usual to get a working package :) It looks like some of the concerns are being worked though in the ticket, and we'll probably get a systemd package eventually. I guess gccjit is special too, but at least its a component of the already-packaged gcc
<muradm>native compilation will definetly require additional step in emacs-build-system
<jackhill>I wonder if native comp will make the emacs build more reproducable
<dstolfa>i hope it will make emacs drain less battery...
<dstolfa>emacs right now is really heavy on battery usage in large files
<jackhill>all the improvements!
<muradm>jackhill: repoducable?
<muradm>isn't it now?
<muradm>for now i just want lsp to work faster
<jackhill>muradm: separate build invocations produce identicle results.
<muradm>jackhill: obviously i know what does it mean ) just wander why emacs build isn't
<muradm>if it wasn't reproducable before, why libgccjit should make it so, i can't imagine
<jackhill>well, if we knew exactly why, then it would be easier to fix :) Overall, I think non-reproducable aspects were introduced over the many years, and it hasn't been a priority by the emacs developers to fix. My thought about native comp helping came from seeing many of the reproducability problems in .elc files and the new prortable dumper, which native comp may make irrelivant.
<jackhill>Or it could mean that I really don't understand the big picture.
<apteryx>seems like the upstream of guile-hashing vanished
<muradm>ok, this seems to work:
<muradm>much faster build time, ~30mins instead of ~30mins + libgccjit infinity build :)
<muradm>basically it sets NATIVE_AOT_FULL=1
<muradm>that makes emacs ~3min build + remaining ~20 min native byte comp of lisp code
<muradm>may be it just not necessary to make NATIVE_AOT_FULL=1 at all, any way they will be built on first use
<muradm>in general it feels much much better )
<muradm>this will need solution also /home/muradm/.cache/guix-extra-profiles/desktop/share/emacs/site-lisp/mu4e-view.el: Error: File error Opening output file
<muradm>site-lisp packages cannot be libgccjit'ed
<apteryx>does someone know how to invoke 'ar' manually to create archives with arbitrary members?
<apteryx>a deb is an 'ar' archive
<efraim>Not in front of my computer but we also have a dpkg package I think
<apteryx>thanks. Perhaps digging through its sources can provide clues.
<pkill9>ar is in binutils, that's all i know
<muradm>maybe add binutils to native-inputs, and then (invoke "unpack" ...)
<muradm>sorry (invoke "ar" ...)
<muradm>guix/build/gnu-build-system.scm:147 unpack phase