IRC channel logs


back to list of logs

<nisha>guixy no, I installed it manually using these steps:
<nisha>lfam `guix describe` and `guix --version` work
<lfam>Great, can you share the results of the first command on <>?
<lfam>This will help us understand exactly which code you are running
<nisha>lfam not familiar with debian's pastebin, but I did send it :)
<lfam>I'm not sure I see it yet... where did you send it? :)
<lfam>Okay, and zooming out... I'm not coming up with ideas about what could be wrong, that would cause you to be logged out or to crash SSH or something while installing a Guix package
<lfam>Installing a Guix package involves downloading some files to /gnu/store, maybe doing some compilation in /tmp, updating a database in /var/guix, and then making some symlinks in your user's home directory
<lfam>I'm also not familiar with Vagrant boxes. It's like a virtual machine?
<lfam>Or just a way to specify a system that will be virtualized?
<nisha>lfam it's a virtualbox VM
<lfam>Also, I'm curious, after you type `guix install hello` and press Enter, does it log you out instantly? Or does it look like it's doing something first? etc
<nisha>It does fetch some things first
<nisha>Aha! pastebin doesn't want special characters:
<nckx>W, as they say, TF.
<lfam>So, nothing about how Guix operates should be able to control your user session or SSH server
<lfam>But I notice that "ACL for archive imports seems to be uninitialized, substitutes may be unavailable"
<lfam>That means that you haven't enabled the ability to download binaries, and so instead Guix will compile *everything* that is required to compile 'hello'
<lfam>I wonder if your VM is running out of memory or something
<nckx>nisha: Is there anything interesting logged in the output of ‘dmesg’?
<nckx>Same question really.
<nisha>yeah...just realized I don't just get logged out - my vm crashes
<lfam>It's fine to avoid substitutes, Guix is actually a build-from-source distro that supports transparent substitution of binaries. But it may require some resources
<nckx>Oh jeez.
<lfam>So this is my first guess
<nckx>How much RAM does it have, nisha?
<rekado>in a package with ant-build-system I cannot get at the JDK with #$(this-package-input "jdk")
<rekado>I looked at the ant-build-system and it explicitly labels the jdk input as “jdk”
<rekado>we do this in a few places to distinguish the jre from the jdk
<rekado>#$(this-package-input "icedtea") also doesn’t work
<nckx>I don't think this-package-input looks at implicit inputs, unless you have a counterexample.
<nckx>Which is to say, I tried it once, didn't work either.
<civodul>yeah, no implicit inputs
<nisha>1987MB according to `free`
<nckx>OK, that's not ridiculously low and shouldn't crash immediately.
<lfam>I feel like it should work unless it is attempting many package builds concurrently, or unless the storage is RAM-backed and becomes exhausted
<guixy>Could it be something to do with build users and build group?
<lfam>Like maybe if /tmp is a tmpfs
<lfam>Yeah, should double-check the setup of the build users
<nisha>I tried it both as a configured user and root
<nckx>That won't make a difference.
<nckx>The build runs as the same user(s).
<nisha>but upping the RAM sounds like a good try
<lfam>Guix kind of expects there to be about 10 "guixbuild01" "guixbuild02" etc user accounts that the actual work is delegated to
<nckx>I don't actually think it will work, but cheap & worth a try!
<lfam>nisha: Did you definitely create the guixbuild users?
<nckx>‘Virtual RAM is cheap’ — now that I can agree with.
<lfam>As described here:
<rekado>oops, I just accidentally pushed to core-updates-frozen…
<lfam>Breaking the ice
<nckx>Christmas is ruined.
<nisha>lfam I have a guixbuild group
<nisha>and I added a user to that group
<nisha>oooh does guix expect a specific user??
<nisha>like guixbuild01?
<lfam>Can you also do `ps aux | grep guix-daemon` to double-check that the guix-daemon has an argument like '--build-users-group=guixbuild'
<lfam>The daemon finds its build users via that argument
<nckx>nisha: It shouldn't, it should just look at the membership of the guixbuild group, but I doubt other names are well tested.
<lfam>I mean, it *should* work, according to spec. But I agree with nckx that it's probably not very well tested, since many of us install with the script or copy and paste that code snippet
<nisha>The script didn't work for me...that's why I went the manual mode
<lfam>I'm just trying to get a sense of how the system is provisioned and how the Guix installation is configured
<lfam>That's okay! I also install manually
<lfam>It's definitely supported
<lfam>Can you check that the guix-daemon is running with that argument?
<nisha>here's what's running /root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild
<lfam>Okay, that looks good
<lfam>So, everyone else... any ideas?
<nisha>biab - let me update the RAM and try again
<lfam>Okay cool
<lfam>Let us know how it goes
<florhizome[m]><jpoiret> "it doesn't compile to native..." <- I thought it has a jit, and that's native compilation
<gnucode>hey guix!
<gnucode>I'm wanting to try to run guix from a console for a while...Essentially I would just start emacs after I login.
<gnucode>But I think I would be tempted to give up this experiment after a few days...Is there someway that I could give a friend my "sudo" password and force myself to only use the console for a while? ie: make it impossible for me on "Guix System" to run X or wayland?
<patched[m]>Is it possible to build using source from a local git repository? guix build doesn't seem to find a git repo when I give url "file:///path/to/my/repo"
<singpolyma>patched[m]: you have to run a git server
<gnucode> patched[m] It should be possible. You might be able to define a package for it.
<guixy>gnucode: If it's a guix system, use the base services.
<guixy>Don't include any desktop services
<gnucode>guixy: thanks! That's a great way to do it!
<guixy>gnucode: I've been trying to get startx to work from that setup for a while now. I probably would have had more success if I understood x a little better.
<patched[m]>singpolyma: I'd like to try out changes locally first before pushing anywhere
<singpolyma>patched[m]: try --with-source=.
<guixy>gnucode: But if you can get a user-run startx to work let me know :)
<gnucode>guixy: I would reccomend just running sway with %desktop-services.
<guixy>patched[m]: --with-source=package-name=package-location
<gnucode>guixy: I know it is possible to use %base-services and get a user-run startx. BUT I think you have to define various programs to be setuid, which %desktop-services does for you.
<guixy>gnucode: Then you'd be good as long as those programs aren't setuid.
<guixy>And you can control setuid in config.scm
<gnucode>guixy: I'm actually tempted to make my laptop NOT have a sound server...I'm going really old school. :)
<gnucode>BUT thanks for mentioning that I can just make various programs NOT setuid. I hadn't thought of that.
<lfam>You could always pull to a commit that pre-dates ec7fb669945bfb47c5e1fdf7de3a5d07f7002ccf and then exploit that vulnerability to gain root
<lfam>Sorry I know that's the opposite of what you want to do
<gnucode>lfam: Well I'm going to try to forget that you mentioned that. hahah.
<gnucode>and I'll will avoid looking up how to exploit that vunerability. :)
<gnucode>and no need to apologize. I thought it was funny. :)
<guixy>How long ago was that commit?
<lfam>March 2021
<guixy>that recent?
<ss2>I'm reconfiguring and python2-pygtk is failing.
<gnucode>thanks again for the help everyone! night!
<ss2>with recent checkout.
<guixy>ss2: When it's finally fixed, will you say "python2-pygtk has failed me for the last time!"
<guixy>Or will you drop it and say that?
<ss2>oh, sorry, I missed the conversation.
<lfam>It's fallout from the "simplified inputs" style change
<lfam>I think I see the fix
<lfam>I'll test it now
<guixy>I know a lot of python packages fail to coexist because of conflicting inputs.
<drakonis>wow, the mesa upgrade is a success
<drakonis>i can actually run graphical applications on a foreign system
<lfam>guixy: That's true, but I think this issue is different
<ss2>okay, sorry, looking higher up this has been discussed so far. :)
<lfam>I have to recompile my development tree. It will take a few minutes
<ss2>I'll leave it for tonight then. Will complete the upgrade tomorrow. Heading off!
<lfam>Note that there is no longer an input that is labelled "python-pygobject"
<lfam>We just have to adjust that reference and then I expect it to be fine
<GNUtoo>Hi, is there some people that use Guix SD on ARM 32bit computers?
<guixy>At one point I used it on a raspberry pi v2. Now I'm all aarch63
<guixy>sorry, I meant package manager
<guixy>Never got guixsd working on my bananapi
<lfam>I think there is a small number of people. Build farm support for 32-bit ARM has been lacking so the user experience is not as good as other types of systems
<GNUtoo>I got it working long time ago but all the last times I tried it didn't boot so I was wonderinf if for some other people it still boots.
<GNUtoo>The isue was some lisp error during boot if I recall well, like the kernel booted but it didn't get to a shell prompt
<GNUtoo>I've only boards with not much RAM though, like 512M or 1GiB to test with
<tschilptschilp23>after pulling, reconfigure fails for me at "fix-codegen" for /gnu/store/c8xdxh6xpra2bw5d2q9jfb6r5s27bn4g-python2-pygtk-2.24.0.drv' with
<lfam>Thanks <tschilptschilp23>
<lfam>Working on a fix now
<podiki[m]>tschilptschilp23: was about to say the same
<podiki[m]>lfam: thanks!
<tschilptschilp23>lfam: thanks!
<guixy>Looks like my gcc-toolchain is trying to use headers provided by clang-toolchain.
<tschilptschilp23>podiki: ;) it was almost done...
<podiki[m]>haha I know me too
<lfam>podiki[m]: Were you also working on a fix?
<podiki[m]>Did not look (dinner now)
<lfam>Okay, I'll do it shortly
<rekado>our old tensorflow 1.9.0 doesn’t like python 3.9:
<rekado>sorry, I meant:
<lfam>tschilptschilp23, ss2, jpoiret: The pygtk2 package should be fixed now, after your next `guix pull`: <>
<lfam>I wasn't sure how to fix it "properly" so I just reverted the breaking change in order to save time
<lfam>I'm testing the build of wicd (which depends on pygtk2) to make sure it builds too
<tschilptschilp23>lfam: pulling right now. cannot promise to report back right away, as it's pretty late here and my eyes are tired already!
<lfam>No worries. I'm confident this package will build for you
<lfam>Or you can wait until tomorrow and get a substitute
<KE0VVT>Is there a channel for RDE?
<GNUtoo>What is RDE?
<KE0VVT>GNUtoo: Guix Home configuration.
<lfam>Looks like the 'guix' jobset is running out of memory on i686-linux: <>
<lfam>"Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS"
<nckx>What does rde stand for?
<lfam>I notice that the pankow and kreuzberg machines don't appear on <>
<tschilptschilp23>lfam: it built ;) I'm out for tonight! Thanks
<lfam>Great :)
<lfam>nckx: Do you know how offloading is configured on berlin? It seems that when I build an aarch64 derivation there, it is always handled by the overdrive, but I'd like to make it use one of the honeycombs
<nckx>Are they dover & grunewald?
<nckx>(They are.)
<lfam>And also pankow
<lfam>There are three, IIUC
<nckx>But it's not up yet.
<nckx>I forgot why.
<lfam>I mean, kreuzberg, grunewald, and pankow are the honeycombs
<lfam>In any case
<lfam>At least one of them is in use, right? :)
<nckx>‘Kind of’, grunewald.
<lfam>overdrive1 is the overdrive
<nckx>It is configured but perma-idle.
<lfam>I don't quite know my way around how the farm is configured. I mainly grep in the maintenance repo and hope I find the info I need
<nckx>Unless I'm missing an obvious, grunewald's simply not configured as an offload machine. rekado?
<lfam>Can you tell me where that is configured?
<nckx>machines-for-berlin.scm (I also checked /etc/guix/machines.scm but there's no uncommitted cheatery going on there).
<nckx>The Wireguard tunnel's configured, and SSH'ing into the node works.
<nckx>cat /proc/loadavg
<nckx>0.00 0.00 0.00 1/333 5783
<nckx>No surprise there.
<nckx>I could trivially add it to the list of offload boxes (and so could you) but we should wait for rekado.
<nckx>Now I've said rekado 3 times.
*nckx goes to get a mirror.
<drakonis>trip report: post cuf merge guix works with foreign distros
<drakonis>fully functional
<nckx> implies the downyness might not be as intentional as I assumed.
<KE0VVT>I'm debating what is a good convention for naming system declaration files, as opposed to home configuration files. Perhaps $(hostname).scm.
<nckx>But since no ‘attempt’ was made to add them to machines-for-berlin.scm, I'm still cautious.
<drakonis>welcome to the club
<nckx>KE0VVT: Probably.
<KE0VVT>And, for home configs, "$USER-home.scm".
<nckx>Makes it easy to do magic hostname-based ‘auto’-loading.
<KE0VVT>nckx: Auto-loading?
<KE0VVT>Also, does the graphical installer allow you to load a prewritten system declaration?
<apteryx>drakonis: thanks for the report
<KE0VVT>Mm... Pull my config from Git!
<drakonis>i think i forgot a few words
<drakonis>apteryx: i ran graphical applications with a debian install with binary drivers
<drakonis>it ran perfectly well
<drakonis>which is excellent news
<drakonis>maybe a 2.0.0 is in order?
<apteryx>was it not the case before?
<drakonis>it was not
<apteryx>nothing changed in that regard except a newer mesa stack
<drakonis>i even rolled back to pre c-u-f pull and it had problems launching the applications
<apteryx>well, that's good to know!
<nckx>KE0VVT: Just that you can have a small /etc/guix/system.scm or whatever that automatically loads the right (gethostname).scm.
<drakonis>looking forward to find out if it also applies to system installs
<drakonis>its going to make my life much easier
<apteryx>drakonis: what do you mean by "if it applies to system installs" ?
<drakonis>hardware compat
<nckx>In a complete changing of the mind, I'm going to start up building on grunewald, because I can't find anything wrong with it. Maybe it still has heat issues so I'm going to limit the number of parallel builds to 2.
<drakonis>gotta make my gpu last until i can upgrade it
<drakonis>if it does work, it'll simplify maintenance
<drakonis>but you get my point
<lfam>Thanks nckx
<lfam>Even a max-jobs of 1 would be alright if we are worried about heat
<nckx>@ unsupported-platform /gnu/store/w9ciifkn95pzqsjd5kykybmskr03h8j4-gcc-toolchain-10.3.0.drv aarch64-linux
<nckx>while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/w9ciifkn95pzqsjd5kykybmskr03h8j4-gcc-toolchain-10.3.0.drv', but I am a `x86_64-linux'
<nckx>It's been years since I set up offloading and things are not going well.
<nckx>guix offload test /etc/guix/machines.scm works dandy.
<apteryx>badly configured binfmt perhaps?
<podiki[m]>lfam: thanks for the quick fix, all good here! (well it downloaded the substitute, so even better)
<nckx>apteryx: You need binfmt to offload?
<apteryx>if you select different --systems
<apteryx>or perhaps your declared machine 'system' field is wrong
<apteryx>not sure, just throwing ideas
<nckx>(systems '("aarch64-linux" "armhf-linux"))
<podiki[m]>lfam: that should also fix the failing networkmanager, gnome-shell, etc. builds since they were missing that dependency
<lfam>It's so refreshing to have NO GRAFTS
<podiki[m]>do you feel clean and wholesome? :)
<lfam>I feel unburdened
<podiki[m]>a fresh new body?
<lfam>I feel like I need about half the storage space I did previously
<podiki[m]>even though I was on c-u-f I do too, feel like i've been waiting for so long and holding off on some packaging
<podiki[m]>also can finally do some more gc-ing too
<nckx>I GC'd 157 GiB yesterday (not all ‘master’-related, of course!).
<nckx>Felt good, man.
<podiki[m]>maybe I can finally setup a periodic gc too (didn't want to while "testing" c-u-f for so long just in case)
<podiki[m]>maybe routinely guix pull too!
<podiki[m]>perhaps someone should make an annoucement to guix-devel (and help?) about the big merge and next steps?
<podiki[m]>(mutter and gnome-shell built successfully locally, should be a good sign for the CI now that pygtk is fixed)
<lfam>I'm sure those involved are resting now :)
<lfam>Would you like to do it? :)
<podiki[m]>haha no thanks, I don't know what I'm doing
<podiki[m]>nor would want to steal any spotlight
<podiki[m]>let the harder workers rest
<podiki[m]>just building emacs (native-comp pgtk version) and then will do the reboot test
<lfam>podiki[m]: Looks a message has arrived
<apteryx>nckx: this on an aarch64-linux native machine (able to do armhf-linux natively as well), right?
<nckx>Yeah, but I stopped pursuing that avenue. It was supposed to be a quick sanity check. Won't do if it's not sane!
<nckx>It was an attempt to work around my complete lack of familiarity with the cuirass-worker mechanism and see if the thing even worked.
***jonsger1 is now known as jonsger
<podiki[m]>lfam: 👍️
<lfam>"gpg: problem with the agent: End of file"
<lfam>Any ideas?
<lfam>It cropped up after updating my installation
<nckx>(cuirass-remote-worker-configuration (workers 4) …) ; on grunewald. As you might have noticed, there were only ever 3 workers listed at, not 4. Now I've shut down the remote-worker service on grunewald and 2 of those have vanished, as expected, but one does not.
<nckx>It's dangerous to assume bugs when you have no idea how things work, but I wonder if that could be a bug 😛
<nckx>lfam: I can only say that I'm using gpg-agent without problems on an up-to-date system.
<nckx>cuirass-remote-server has crashed…
<apteryx>oh! now that's clearly bug report worthy
<nckx>Uh oh.
<nckx>I think berlin's down.
<podiki[m]>can't reach here either
<nckx>Oh boy.
<apteryx>same, at least the CI web interface
<podiki[m]>and when guix looks for subs just stays at 0%
<apteryx>hmm, SSH too.
<podiki[m]>perhaps the CI partied too hard post-merge :-|
<apteryx>perhaps having issues with the network
<nckx>I hope so.
<apteryx>we'll have to resume work on Gnunet-powered substitutes ;-)
<apteryx>the european night will be long
*nckx sigh.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ is down ⚠️ | 1.3.0 is out! | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
***ChanServ sets mode: -b *!*M6piz7wk*@*
<raghavgururajan>Hmm. Guix complains about GUIX_LOCPATH after guix pull, on guix system.
<nckx>It can do that if you haven't updated all your user+system packages yet.
<nckx>Because locales are glibc-version specific :-/
<nckx>I hope a lot of people have cold houses and/or laps tonite.
<raghavgururajan>guix system reconfigure build texlive ghc rust etc stuff, which my melty x200t can't take up. So gonna retry after few hours.
<nckx>*Panics in German*
<nckx>I hear bordeaux is nice this time of year.
<vagrantc>it's probably time to boot up the apm mustang and build all of aarch64 to heat things up a bit
<vagrantc>i am running a heater using about 150 watts ... the arm64 server will only use 60 watts ... amittedly also produces a lot of noise
<vagrantc>whereas the heater is silent... hrm.
<nckx>But can the heater be aimed at your face like an industrial heat gun? I think no.
<lfam>I'm testing a gpg upgrade. Signing works, symmetric decryption does not
<lispmacs[work]>can I install packages from a manifest, using guix-emacs?
<lispmacs[work]>instead of `guix package -m ...'?
<podiki[m]> on the same servers? or something? (down for me)
<nckx>As Unfortunately, yes.
<nckx>Much redundancy. Very HA.
<podiki[m]>syncthing-gtk fails to run for me due to some librsvg thing; will investigate later
<apteryx>on x86_64?
<nckx> is critical infrastructure so remains up.
<podiki[m]>yes on x86_64
<podiki[m]>thread '<unnamed>' panicked at 'Type RsvgHandle has already been registered', /tmp/guix-build-librsvg-2.50.7.drv-0/librsvg-2.50.7/guix-vendor/rust-glib-0.9.3.tar.gz/src/subclass/
<apteryx>during its test suite?
<podiki[m]>no, on running
<podiki[m]>and it was working on c-u-f prior to the big merge (but maybe pre-librsvg workaround?)
<nckx> → 0.0% substitutes available (1 out of 21,005)
<nckx>Eh, wat.
<podiki[m]>was there some discussion on bordeaux out of space?
<lfam>The datefudge source code disappeared upstream 🤦
<podiki[m]>or was it just running low
<nckx>Oh dear.
<nckx>I was reading that mail as you spoke.
<nckx>This is a fun night.
<podiki[m]>the guix gods giveth, so they taketh
<nckx>lfam: It's on if you need it.
<lfam>Thanks nckx
<nckx>And now it's at <> in a manner that doesn't require a key dance.
<nckx>Not that you shouldn't let me provide you with arbitrary binaries.
<lfam>My gpg problem was fixed in 2.2.31
<PotentialUser-33>oh jeez
<cehteh>is the bug-guix list moderated? i replied there and it didnt seem to get through
<nckx>It is. Sec.
<PotentialUser-33>i just wanted to try guix rn
<nckx>cehteh: Fixed.
<cehteh>ok thanks
<nckx>rn might not be the bestest of all times, alas.
<PotentialUser-33>true, since its down
<PotentialUser-33>since when btw?
<lfam>An hour or so
<PotentialUser-33>oh wow
<nckx>I forgot about until now; it does not seem like a viable back-up because… redirects.
<nckx>At least I can't get my Guix to use it.
<jackhill>I need to re-read cbaines's emails about setting up mirrors of guix build coordinator output, as I'd like to try doing so.
<jackhill>I have a willing partner with a bunch of disks, but they need a better explaintation than, "we may have to write some code, and the code may want access to a database"
<PotentialUser-33>is legit?
<PotentialUser-33>so i can at least get the iso etc?
<nckx>All mirrors at are official.
<nckx>So yes.
<PotentialUser-33>i just wanted to be sure
<nckx>It's a very good point.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ is down ⚠️ | Download: | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
<nckx>(Mirror chosen highly arbitrarily to be both short and non-commercial and European because that was the status quo.)
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ is down ⚠️ | Download: | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
<cehteh>haha just noticed
<cehteh>is that just the website or more?
<PotentialUser-33>ci too
<cehteh>just send mail lests see if that gets through
<cehteh>nckx: ah damn under wrong sender :D nckx could you please whitelist my normal address too? :)
<nckx>Mail works fine (please don't send ‘test’ messages, anyone).
<vagrantc>so ⚠️
<nckx>vagrantc: You'd be amazed at what is required to get people to read the topic…
<nckx>I'm very impressed so far.
*apteryx is curious as to what exploded on berlin
<vagrantc>nckx: impressive indeed
<cehteh>but hey people will notice it anyway that the server is down :D
<PotentialUser-33>thats a good sign
<vagrantc>i see all these ⚠️,, but is really down?
<PotentialUser-33>i mean of people noticing it
<cehteh>i didnt asked how long ago the last gc run on berlin was :D
<cehteh>i mean the once before the 5TB trash collected
<nckx>cehteh: issues.guix is just a prettier Web front-end to the back-end behind
<cehteh>nckx: you can login to berlin too? seem my last message,
<nckx>cehteh: I think it ran about 24h ago, IIRC.
<nckx>cehteh: I can when it's up.
<nckx>I don't have iWhatever access or anything.
<cehteh>nah i meant the one before the shit hits the fan .. that must be months ago?
<cehteh>then i wait for rekado_
<nckx>When what shit hit what fan? I don't follow.
<nckx>cehteh: We all do!
<cehteh>while i was brainfarting here it just came to me "omg they didnt forget relatime?!?!"
<nckx>He's the only one who can fix this if it doesn't fix itself.
<nckx>cehteh: Isn't that the default since kernel $forever.
<cehteh>iirc its not default
<nckx>You have to do $something to get old-timey atimes, at least.
<nckx>That's not default.
<nckx>For a good while now.
<cehteh>well i am not sure, just asking
<nckx>Maybe we access files in a way that relatime still murders us.
<cehteh>i doubt relatime has a pretty simple heuristic
<cehteh>but deletion *is* slow
<cehteh>thats to be expected on spinning platters
<nckx>It's a good point, though, definitely something to investigate, although I don't think it's likely unless something is actively fighting the kernel defaults.
<cehteh>well some things could be tuned for sure, but since its a production machine i woulnt try too much
<nckx>XFS when.
<nckx>I never really took ‘deletion speed’ in fs benchmarks seriously (when is that ever on the critical path?), now I get it.
<ns12>"guix substitute: error: connect*: No route to host"
<ns12>"substitution of /gnu/store/b9x0w06vjb0lwhcagxj442lw6jx3vyxf-module-import-compiled failed"
<nckx>See topic ns12.
<cehteh>sometimes setting laptop_mode to some higher value helps to batch writes better, also the disk schedulers have some knobs to tune, make longer queues, longer timeouts to allow the scheduler to coalesque jobs better
<ns12>"guix install: error: corrupt input while restoring archive from socket"
<cehteh>nckx: dunno how XFS is now .. but when i tried it 15+ years ago it was pretty poor on massive metadata operations
<nckx>Yeah, I don't actually have any experience with it, it just seems like a meme.
<ns12>What should I do to install packages in the meantime? Build everything from source?
<nckx>What is a good file system for those?
<cehteh>anyway my plan is "dont care about the speed, just take it out of the hot/locked path"
<nckx>Yes ns12. We're in something of a perfect shitstorm as far as substitutes are concerned.
<cehteh>dunno but i think ext4 shouldnt be so bad
<ns12>nckx: Is this an unexpected outage?
<ns12>What is the underlying cause of the problem?
<cehteh>5TB trash with zillions of hardlinked files is just massive
<nckx>Yes. And no idea.
<nckx>ns12 ☝
<nckx>cehteh: <just take it> Yes, I agree that seems like the only real solution.
<vagrantc>downgrade to whatever version bordeaux last built? ... which is also more-or-less out-of-disk space as i recall
<nckx>I was just checking that but there's no Cuirass UI I can find.
<nckx>Though I didn't look very hard yet.
<vagrantc>it's very behind
<nckx>Yeah, I don't want people to actually downgrade their systems, even if few will actually be using the log4js of the world in practice.
<cehteh>you could throw money on it some TB enterprise grade SSD's but i am still believing in proper programming is more sustainable than thowing hardware on a problem
<vagrantc>e.g. i think it's been paused since ~ December 3rd last i hear
<nckx>We are in agreement. We have money. We don't have throwin' money.
<nckx>If complexity weren't such a problem already I'd consider pitching something like bcache (to be clear: I won't).
<vagrantc>i presume this is the most current update on bordeaux's substitutes:
<nckx>At least there's a ‘12’ in that link. *clicks*
<cehteh>locally here i have dmcache which is really great, but no cache would help with the deletion problem, whatever you delete is likely cold in the cache
<nckx>I don't think bayfront's been resumed since that mail.
<nckx>So yes, that's about it. Almost a month old.
<cehteh>for my testing here dmcache is nice i can walk 200Million files in 1 hr in my tests, on pure platters that will take many hours
<nckx>Put the metadata on SSDs. /s
<vagrantc>ok, it's really time to boot up my aarch64 server with a pretty old guix install on it :)
<apteryx> /gnu/store/b4vr6046c36g2b0q3d0zh9bpa9gczkqc-icecat-91.4.0-guix0-preview1.tar.xz.drv takes forever -- is parallel xz compression not working for that one?
<nckx>vagrantc: Its time to shine!
<cehteh>yes, but neither bcache nor dmcache can do that, zfs can do that with some efforts
<apteryx>or perhaps it does its own thing as a computed file origin
*vagrantc coughs as the fans spew dust everywhere
<vagrantc>will see if i can't carve out some time tomorrow for that :)
<apteryx>ah yes, the later: (invoke "tar" "xf" #+upstream-firefox-source)
<PotentialUser-33>wellp, lets make foot
<nckx>Does anyone have /gnu/store/rfb2s26azhlqzznamfqydv3s3ab90sqf-python-minimal-3.9.6.drv they could share as a nar?
<nckx>Mmm, foot.
<nckx>Hi rms.
<nckx><Does anyone> I have reached sneakernet-levels of desperation in mere hours, yes.
*lfam wonders if they should push the gnupg update
*apteryx slaps (setenv "XZ_DEFAULTS" (string-join (%xz-parallel-args))) in there
<lfam>I suppose no, since I can't actually test it on current HEAD
<vagrantc>lfam: it couldn't possibly break anything harder than it is right now :)
<nckx>What's the rebuild count?
<lfam>It grew to a very large number
<nckx>Well, still, let's severely limit the number of rebuilds people have to perform now…
<lfam>That's new...
<vagrantc>someone seems to have recreated core-updates-frozen :)
<lfam>We'll have to deal with it once CI is back online because the gnupg version we have on master doesn't do symmetric encryption
<vagrantc>people use that? :)
<nckx>vagrantc: Was it actually deleted yet?
<lfam>I use it vagrantc
<lfam>I'd guess it sees use in password managers
<lfam>Like, `gpg -c`
*vagrantc waves
<apteryx>lfam: it'll be best to build this away from master, on the version-1.4.0 branch; but not now, berlin probably run out of disk space or something, let's not burden it more yet
<lfam>Once CI is back up, I think we should make some effort to fix it on master because one of its critical features is missing
<lfam>Maybe we can add a gnupg-next package and use it in specific places, for example
<PotentialUser-33>what is happening to the domain name?
<lfam>The site is down
<PotentialUser-33>i know it redirects me to this domain https://ci.guix.gnu.xn--org-5o0a/
<nckx>Nothing PotentialUser-33. The DNS is handled by GNU, so at least the * subdomains hosted on other machines should remain up.
<nckx>That just looks like a typo or Unicode attack?
<lfam>I don't experience that redirect
<nckx>Did you perhaps hit an accidental compose key or something?
<PotentialUser-33>when i go to“ it sends me there
<nckx>That's how Unicode URLs ‘work‘.
<PotentialUser-33>no i clicked the link in my terminal
<nckx>Yes, and it included the “ in the URL.
<nckx>Which is wrong.
<nckx>It's not a redirect.
<PotentialUser-33>oh wow, real "gnome-terminal" moment
<nckx>At least we're not under attack… o_O
<PotentialUser-33>it includes the " in the url link
<nckx>That was creepy for a brief moment.
<nckx>Not your fault!
<jackhill>the things one learns in adventures without substitues: half of ruby-land is needed for `guix pull`. I would never have guessed.
<nckx>So is Python-‘minimal’, which reliably fails its test suite on my laptop.
<nckx>If I get it to build maybe we'll see npm scroll by.
<nckx>Well, it's what ‘guix pull’ is stuck on here.
<apteryx>I've rebuilt core-updates-frozen dozen of times, and don't recall python being flaky :-/
<jackhill>hey, at least we have so many of these packages packaged!
<PotentialUser-33>what happend anyway ? did a server go boom or was hosted at OVH?
<PotentialUser-33>(which is the same basically)
<lfam>Unknown what happened
<nckx>And yes, it has ‘dodgy’ written all over it.
<lfam>It's hosted in the datacenter of a research institute
<nckx>They are gracious and competent hosts.
<lfam>Currently it's the middle of the night in that place
<nckx>I'm sure it's somehow our fault.
<lfam>Tests result: FAILURE then FAILURE
<apteryx>nckx: I'm guessing file system related
*raghavgururajan is confused with guix-home
<nckx>I've tried on bcachefs, tmpfs, and btrfs so far.
<lfam>Does anybody know why gnupg has so many dependents?
<nckx>Am I really going to loop-mount an ext4 image?
<nckx>…yes, I probably am, because what else is there to try.
<raghavgururajan>Should ~/src/guix-config/* be preserved and use forever?
<apteryx>nckx: it reminds me of something... trying to recall
<nckx>Loop image mounted, guix-daemon pointed, build started.
<PotentialUser-33>lol i go watch <propritary streaming service> now
<AwesomeAdam54321>I'm getting closer to running the GNU Shepherd as my init system
<raghavgururajan>build stopped, device fried.
<nckx>apteryx: Any specific part?
<PotentialUser-33>i want to switch to guix system soon(tm)
<AwesomeAdam54321>The problem is that about half of my services get disabled because they respawn too fast
<nckx>raghavgururajan: I hope you were riffing on my last message and not talking about yours!
<apteryx>nckx: it's was some basic tool that failed on Btrfs, and then there was some plan to devise a linux-specific tool to replace it
<apteryx>anyway, I can't find it, but this looks like your problem:
<raghavgururajan>AwesomeAdam54321: You mean on foriegn distro?
<apteryx>with the best kind of resolution
<AwesomeAdam54321>raghavgururajan: yes
<PotentialUser-33>what you usin with guix, AwesomeAdom
<PotentialUser-33>i cant type lol
<raghavgururajan>nckx: Yeah xD
<nckx>‘Resolution: fixed’
<nckx>That's great.
<apteryx>nckx: perhaps you should chime in with a revenge of the dead note
<PotentialUser-33>im tired and distracted by a funni swedish man
<AwesomeAdam54321>PotentialUser-33: I haven't used the Guix package manager yet
<PotentialUser-33>i use it on fedora for emacs and nyxt
<raghavgururajan>AwesomeAdam54321: Woah!
<PotentialUser-33>will make a full switch
<lfam>There already *is* a newer gnupg package! ffcf4ea9abbbc35fefbe4a491e1e5eac1c7c0002
<lfam>The big part of the reverse graph is gpgme
<KE0VVT> is unreachable
*raghavgururajan starts a dial-up connection
<nckx>vagrantc: …see?
<nckx>Oh right, they left.
<KE0VVT>i rm rf'd a lot of my ~ and no bavkup
<AwesomeAdam54321>Is there a way to conveniently start multiple services with 1 'herd start' command or something similiar?
<lfam>KE0VVT: The site is down
<lfam>Deleted some of ~?
<lfam>Oof, that's rough
<PotentialUser-33>read topic
<AwesomeAdam54321>PotentialUser-33: Oh, ok
<KE0VVT>i guess everybodys deleting stuff tonight
*KE0VVT checks moon phase
<PotentialUser-33>na i have 3 computers, no deletion jet
<KE0VVT>i need to learn borg backup
*nckx promotes the health benefits of hourly backups.
<lfam>Borg has saved my skin several times
<PotentialUser-33>btrfs timeshiters
<KE0VVT>and with guix config in my home, maybe i dont need to worry about /
<apteryx>PotentialUser-33: haven't heard of the timeshiter feature yet
<nckx>The servpocalypse might be upon us but at least there's entertainment!
<KE0VVT>i need a guide to back up
*raghavgururajan hums "sync sync sync thing thing thing ..."
<nckx>ERROR: test_fcntl_64_bit (test.test_fcntl.TestFcntl)
<nckx>On (loopy) ext4.
<nckx>So it's… the kernel?
*nckx fingers random components.
<KE0VVT>raghavgururajan: syncthing helps a lot but not for everything
*nckx hums rsync rsync don't overengineer ♪
<KE0VVT>nckx: so rsync no borg
*raghavgururajan 's mind was picked by nckx
*nckx wrote an 821-line wrapper around rsync so don't take advice from them!
<lfam>New versions of rsync provide plenty of opportunities to overengineer, with a wide variety of modern compression and hasning algorithms ;)
<KE0VVT>nckx: oh yeah im not maintaining a wrapper screw that
<nckx>Wise KE0VVT.
<lfam>My borg wrapper is only 67 lines long
<lfam>And it's still too long
*apteryx needs to devise a guile wrapper around 'btrfs send'
*raghavgururajan goes into a cloud called next
<KE0VVT>lfam: ... how ...
<lfam>I don't know, it just happens to me
<apteryx>nckx: the hunk of these 821 lines must be the ignore list I hope?
<lfam>I put it in my crontab
<apteryx>mine was stolen from
<apteryx>version 2018-05-18
<apteryx>you can tell when the script was hacked up
<raghavgururajan>A ☁️ that can be your own or the next.
<lfam>My wrapper script is pretty bonkers
<nckx>apteryx: No, it's a few orders of magnitude more insane.
<lfam>[ $# -lt 1 -o $# -gt 2 ]
<nckx>It pries apart rsync and partially reimplements its own ‘protocol’ in bash.
<nckx>So we can rsync the rsync file list, which is about a gigabyte in size.
<lfam>Okay you win
<nckx>Oh yes I do.
*nckx → foot.
*raghavgururajan is sleep drunk
<podiki[m]>nckx: still looking for that python-minimal? I have it
<nckx>!!! Yes please.
<apteryx>nckx: you should make an xkcd out of it
<podiki[m]>what exactly do you need and how do I get it to you
<PotentialUser-33>we are like the people whos house is burning and we have a beer and chat
<nckx>podiki[m]: guix archive --export /gnu/store/[the result of building that .drv] > /tmp/nar
<lfam>What else can we do
<lfam>It's kind of like the electricity is out so we just hang around and tell jokes
<apteryx>it has that vibe of when the power is out
<nckx>Nah, it's not that bad. It's more like a friendly neighbourhood get-together around a flaming barrel during a blackout.
<apteryx>lfam: ha!
<lfam>The humanity that emerges when productivity is off the table
<nckx>So what apteryx said, derp.
<lfam>It's a good argument against hosting our own chat
*nckx → now really going to eat something, thanks in advance podiki[m].
<podiki[m]>nckx: so you want the python-minimal output, e.g. guix build /gnu/store/...that.drv, export what that tells me is the store dir?
<podiki[m]>sneek: later tell nckx whenever you are back I have it for you
<sneek>Will do.
<podiki[m]>sneek botsnack
<PotentialUser-33>raghavgururajan yes
<PotentialUser-33>oh we have matrix users here
<PotentialUser-33>can you tell me the address?
<raghavgururajan>I am connected via XMPP
<PotentialUser-33>didnt knew that was possible
<PotentialUser-33>but i meant podoki
<podiki[m]>PotentialUser-33: what address? to connect via matrix?
<PotentialUser-33>yeah the roomID
<podiki[m]>I think you just use
<podiki[m]>...I take it that means PotentialUser-33 made it over the bridge...
<nckx>podiki[m]: I should've used $(…) instead of inventing my own syntax, but it's 6am for me too 😉 I will now gladly curl your arbitrary executable blobs.
<sneek>nckx, you have 1 message!
<sneek>nckx, podiki[m] says: whenever you are back I have it for you
<Seven-ALB[m]>nice thanks podiki
<podiki[m]>welcome! (in both senses of the word)
<podiki[m]>anyone else need anything by any chance? I won't be able to set up a mirror suddenly, but did manage to have everything (and then some) before the CI went down
<nckx>podiki[m]: Sweet, it worked, thanks again.
<podiki[m]>no problem!
*apteryx waves
<apteryx>good night, off the grid Guix
<nckx>o/ apteryx.
<nckx>Thank you so much for your work on c-u-f.
<podiki[m]>yes, thanks apteryx!
<apteryx>:-) thanks for the encouragement; at some point I wasn't sure if I was breaking more than fixing ;-)
<ns12>Is there a place to report severely outdated packages?
<nckx>In all honesty, I'm not sure that's something we want to encourage.
<nckx>I mean, mentioning one or two is fine, but updating severely outdated packages is rarely easy.
<nckx>‘Knowing x is outdated’ is very, very rarely the bottleneck.
<nckx>Which package did you have in mind?
<ns12>I'm just asking in general. Whether or not there is a formal mechanism to notify the maintainers, just in case they forgot about updating packages or somehow didn't know about the existence of new versions.
<nckx>Not really.
<nckx>People tend to submit patches instead.
<nckx>It's not that hard!
<ns12>Okay, I'll give it a try.
<nckx>Wow, great ☺ If you get stuck, don't hesitate to ask questions.
<ns12>Thanks for the encouragement. :)
<podiki[m]>guix refresh is your friend
<podiki[m]>errr... I was going to link ns12 to the manual, only to hit the down server (duh)
<nckx>D'oh, I forgot about guix refresh.
<podiki[m]>or also guix build --with-latest for a one liner to see if it "just works"
<nckx>My distrust of automagical tooling is showing and is probably undeserved.
<nckx>guix refresh is definitely the way to go first.
<nckx>(slash --with-latest)
<podiki[m]>there's probably a (longer) one liner to do a git checkout, build, and refresh in the pre-inst-env, AND submit the patch all in one
<podiki[m]>transformations always feel like superpowers to me, love them
<Seven-ALB[m]>we need a 2nd ci
<nckx>We have one, but it's also out of service.
<nckx>We need a 3rd CI.
<nckx>We need many CIs.
<nckx>Nah, just more robust mirrors.
<Seven-ALB[m]>how to host?
<Seven-ALB[m]>we have some servers
<Seven-ALB[m]>is nr2 in berlin?
<nckx>No, in France.
<nckx> might be a good start (I'm not familiar with the operational details either)
<Seven-ALB[m]>we mirror alpine too
<nckx>Mirroring Guix is not as simple as most other distributions which are just nearly-static directory trees you can rsync.
<nckx>Seven-ALB[m]: The 2nd CI (bordeaux from now on) isn't ‘down’ per se, it was paused begin December because we ran out of space and thought we had plenty of time to decide what to do.
<nckx>As it always goes.
<Seven-ALB[m]>i see
<Seven-ALB[m]>how much space does a CI or mirror need?
<Seven-ALB[m]>10TB? 20?
<nckx>And the other half of the perfect storm is that today a branch was merged that makes all of bordeaux historical substitutes ‘obsolete’ for current master. If this had happened yesterday, it would have been comparatively less bad.
<nckx>10TB will certainly suffice.
<Seven-ALB[m]>we have 12TB free, ill ask my coworkers
<Seven-ALB[m]>is there a way to mirror only the store needed by a config.scmn
<nckx>Remarkably yes. guix gc --requisites $(guix system build /etc/guix/system.scm) will get you extremely close, if not 100% there.
<nckx>Substitute the file name of your choice.
<nckx>No pun intended…
<nckx>(This command does not collect garbage at all; ‘guix gc’ has grown some options that make it more like ‘guix store’ now.)
<Seven-ALB[m]>then we could at least deploy multible small once
<Seven-ALB[m]>plus one complete
<nckx>That command does imply you've already built the system on the machine it's running on.
<nckx>But there are ways around that at the trivial cost of no longer being a one-liner :)
<Seven-ALB[m]>well i need some food
<Seven-ALB[m]>i hope there is a CI soon ;)
<guixy>blueman-applet shows a dialog with this error:
<guixy>g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2)
<guixy>How is this typically handled?
<rekado_>nckx: have I been summoned?
<nckx>And how! I didn't even know then.
<nckx>Berlin is down.
<nckx>Or unreachable, at least.
<nckx>(Good morning! :)
<zimoun`>Is Berlin ( down?
<rekado_>I gotta prep my kid for daycare, will check in 20 mins
<zimoun`>:-) Good luck!
<efraim>hello guix!
<efraim>with c-u-f merged I can poke guix.m4 and the manual about deprecated architectures
<nckx> is having the time of its little life. Pity it's still stuck bootstrapping Rust itself…
<florhizome[m]>Where did gdk pixbuf+svg go though?
<florhizome[m]>Does it just work now (without +svg)
<abrenon>hello guix !
***ChanServ sets mode: +o nckx
***nckx sets mode: -b ix!*@*
***ChanServ sets mode: -o nckx
<mothacehe>hey guix!
<abrenon>thanks for all the clear messages and the fallback nckx
<nckx>There isn't really a fallback :(
<abrenon>not for the substitutes but I mean to download guix itself
<abrenon>isn't that the content of the nluug ftp thing ?
<nckx>That is a trustworthy GNU mirror, at least.
<allana>Hi everyone. Is anyone having issues updating substitutes on a "guix pull"?
<allana>A "guix pull" is not succeeding on my system, staying at 0.0% for an extended period of time.
<PurpleSym>See topic. The CI is down.
<allana>PurpleSym: Thanks, apologies
<PurpleSym>No worries :)
<unmatched-paren>hi guix, have substitutes for the c-u-f merge been mostly made yet?
<mothacehe>hi unmatched-paren, unpossible to know the whole guix infra is down atm
<rekado_>meh, I can’t get connected to the serial console
<unmatched-paren>what happened to the servers? i can't get to in a web browser either
<abrenon>unmatched-paren: see the topic
<abrenon>the whole thing is down
<unmatched-paren>oh, i see it now
<abrenon>I suppose it's pretty bad if even the serial console doesn't respond ?
<unmatched-paren>i can still get to; are those hosted elsewhere?
<nckx>And after this, is definitely going to be a thing, so I can just slap that in the topic & be done with it.
<florhizome[m]>Oh no
<florhizome[m]>How easy do CIs break?
<civodul>Hello Guix!
<mothacehe>florhizome[m]: that's not the CI, it's the whole server
<mothacehe>hey civodul!
<nckx>rekado_: Are any of the berlin build nodes reachable?
<abrenon>hi civodul
<rekado_>I’m expecting that it’s the switch
<rekado_>trying to get ahold of the networking team
<rekado_>can’t access any of the build nodes either
<florhizome[m]>salut civodul
<nckx>Oh hullo!
<rekado_>and not a single person has responded to my requests for help
<rekado_>very frustrating
<abrenon>I guess so : (
<abrenon>don't we have status monitoring for the various pieces of hardware ? (plugs, switch…)
<rekado_>‘we’ is not ’us’
<abrenon>oh : /
<abrenon>how come ?
<nckx>From what I've seen, what status monitoring there is runs in a Windows VM(?), that kind of thing.
<nckx>At least I hope it's a VM 😛
<florhizome[m]>Bordeaux shows a starting page
<nckx>Bordeaux is in France.
<nckx>It is completely separate from the berlin server.
<florhizome[m]>I thought the main was in the us?
<nckx>Berlin hosts,,, probably something else I forget.
<florhizome[m]> ?
<nckx>Bordeaux hosts, well,, and
<nckx>florhizome[m]: It would be exceptionally trolly if it didn't host that.
<cehteh>mhm .. so berlin is completely down now? or somehow reachable?
<rekado_>nckx: that’s just the management interface of the storage
<florhizome[m]>And I felt smart I found that
<rekado_>I’m not the IT department. *They* have monitoring for the data centre, obviously.
<florhizome[m]>But if Bordeaux works that means it’s a Berlin server problem
<rekado_>it is not a server problem necessarily
<nckx>s/server // yes.
<florhizome[m]>it’s a local infra problem
<cehteh>well there was the gc/rm thing ... maybe there was some glitch on the fs and it crashed/rebootng/fscking
<florhizome[m]>dammit German internetz
<nckx>It was acting weird, but I can really not say if it was weirder than usual.
<nckx>Services failing, that sort of thing. Unfortunately not that unusual.
<cehteh>rekado_: seen my mail i wanted to ask you if perhaps (small chance) the filesytem was not mounted with relatime (and possibly nodiratime) which may or may not be part of the slow delete process
<nckx>I'm just glad rekado_ is OK and Germany is still there.
<cehteh>is berlin really located in berlin? :)
<nckx>(Maybe not just right now, cehteh :)
<nckx>cehteh: Yes.
<nckx>Prime real estate.
<rekado_>so, I’m on the serial console; no response from the server
<cehteh>ba prepared that booting/fsck will take quite some time
<florhizome[m]>the knowledge that guix is hosted in Germany doesn’t help my urging need to bridge the situation with awkward jokes
<nckx>Oh god fsck.
<nckx>Imagine if it were ext2.
<rekado_>I’ll reset the machine
<cehteh>no hands on site you can call for a check?
<unmatched-paren>"fsck!" is an appropriate interjection at this moment
<nckx>It is not a commercial DC.
<cehteh>i mean reset .. mkay last resort
<AwesomeAdam54321>hey mothacehe!
<zimoun`>I noted that the web page of was not responding yesterday; end of my afternoon.
<cehteh>sometimes a reboot is a good thing .. you notice everything you broken in the boot process since the last boot :D ... except that shoudnt happen on guix
<nckx>There are a few hacks in place to boot on the Dell HBA thingamabob etc., but they should be quite settled at this point.
<rekado_>cehteh: I could bike there now, of course
<rekado_>zimoun: end of your afternoon would have been the network outage.
<rekado_>which was actually unrelated to the MDC.
<unmatched-paren>wait, so two unrelated incidents at the same time?
<abrenon>not exactly the same, if I follow
<rekado_>server doesn’t recognize its disk
<rekado_>I don’t mean the external one
<rekado_>it’s own hard disks
<unmatched-paren>i suppose i'd better read the logs
<abrenon>I didn't mean *that* terminal ! : (
<rekado_>nice. ‘All of the disks from your previous configuration are gone. If this is
<rekado_>an unexpected message, then please power off your system and check your cables
<rekado_>to ensure all disks are present.’
<vivien>Hello guix!
<vivien>Thank you for the core-updates-frozen merge :)
*cehteh remembers back the time with compaq servers ands scsi disks in plastic cages .. one disk tried to escape by melting its was into freedom D:
<Seven-ALB[m]>any news
<rekado_>I’m restoring the controller’s disk config
<rekado_>‘Unified Server Configurator does not support console redirection.’
<rekado_>good job, Dell.
<cehteh>bike ride? :)
<vivien>I decided to reconfigure without substitutes, but now that I’m building one of the webkits, I remember why that’s a bad idea.
<rekado_>it now recognizes the virtual disk again
<jlicht>happy day-after-merge-day, guix! \o/
<nckx>jlicht: Somebody celebrated by stealing our discs, but they put them back.
<rekado_>but the ‘Lifecycle Controller’ is now in recovery mode and it tells me to ‘Repair Lifecycle Controller firmware using the Lifecycle Controller Dell UpdatePackage (DUP) or Lifecycle Controller Repair Package via iDRAC. For moreinformation, see Lifecycle Controller User's Guide.’
<nckx>Be sure to have your enterprise subscription key ready.
<jlicht>it's not a party of some disks don't get misplaced!
<vivien>nckx, did that somebody inject a self replicating backdoor into our binary seeds while the disks were missing?
<nckx>Let's not joke about everything just now.
<abrenon>that wouldn't be very funny, party or not
<nckx>(It had occurred to me, though not in that literal a sense.)
<csantosb>Anyone lucky with the following command ?
<csantosb>'guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' -- chromium'
<nckx>But crappy Dell hardware is Occam's friend.
<zimoun`>why “guix time-machine --commit=94836b2 -- weather“ fail because /gnu/store/v8m3nivqdq9wp77x2wv0p51nw6sddg9g-guile-json-3.5.0 and do not build it?
<csantosb>I just get an ugly 'Authorization required, but no authorization protocol specified' message
<abrenon>vivien: but then wouldn't that show when we build packages locally and they don't match the substitutes on the server ?
<abrenon>csantosb: I suppose you're using X11 then ? you need to pass some dir in /tmp too
<nckx>abrenon: Yes, but not all packages are bit-reproducible yet, so it would require some human filtering of the (more than a handful of) false positives. But it could be done!
<jlicht>nckx: I learned about existing last week; might be useful for a future, if that is to be done with prometheus
<csantosb>abrenon: correct, X11. So I need the '--share=/tmp=/tmp' flag or similar ... ?
<abrenon>csantosb: /tmp/.X11-unix, preferably not with share
<abrenon>uh… -E ? is there such a thing ? I don't remember
<abrenon>nckx: even if it needs a lot of work, that's still good news that it'd be possible
<nckx>jlicht: I was thinking of something waay simpler, but omething that fancy would certainly be nice.
<rekado_>switched the LC back to ‘enabled’ from ‘recovery’
<csantosb>abrenon: --preserve=REGEXP, you mean ?
<rekado_>nobody removed any disks
<rekado_>the RAID controller config changed
<rekado_>perhaps because of a RAID controller firmware upgrade, or the fact that it was extended with SSDs
<nckx>How does it upgrade?
<rekado_>all Dell servers get their upgrades pushed to their iDRAC via a management server.
<rekado_>we explicitly acknowledge all upgrades that are pushed
<rekado_>we hadn’t rebooted when we last applied the RAID controller upgrade
<zimoun`>why even «guix time-machine --commit=94836b2 --no-substitutes -- weather» does not work?
*jonsger still waits on server vendors jumping on the fwupd train...
<nckx>jonsger: Firmware update?
<nckx>(No: it's apparently a firmware blob uploader for GNOME. Unlikely future Guix material.)
<jonsger>jop. Dell and Lenovo are doing that for Laptops/PCs quite broad, but not for servers. As they wanna sell bs firmware upgrade software...
<nckx>‘In December 2015, it was revealed that Hughes had been working with a Dell developer to test the system on actual hardware, and that its Dell Edge Gateway product will support firmware servicing via fwupd.’
<jlicht>nckx: it's a service to get the right proprietary bits to your usrs even faster
<nckx>I see that went nowhere.
<abrenon>csantosb: I don't have the documentation right now and I'm late for a webconference
<abrenon>I thought it was something like --expose ?
<nckx>jlicht: So I sliced through the marketing spin correctly 😛 Thanks for the confirmation.
<abrenon>it'll work with --share, it's just not necsseray to give RW, RO should be enough
<jonsger>jlicht: there is also foss firmware up there :)
<csantosb>abrenon: Tried this 'guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' --share=/tmp/.X11-unix --share=/tmp/.XIM-unix --share=/tmp/.X0-lock -- chromium'. Still no luck.
<csantosb>Using expose instead of share doesn't make any difference.
<csantosb>Thanks anyway, not in a hurry.
<jlicht>jonsger: cool! Perhaps the FSDG-projects can have a look some day when there is a reasonable amount of firmware on there for a libre spin of fwupd
<attila_lendvai>rekado_, a hypothesis: maybe the firmware got upgraded, the config got migrated/adjusted to the new version, no reboot, and then something happened that caused the old version to change/overwrite the config... that would be stupid, but i've seen worse.
<cehteh>there are a lot reasons speaking for linux software raid (and few against)
<nckx>It's great when you have the luxury.
<nckx>zimoun`: Works here.
<efraim>(NOT A BUG REPORT) it seems I now need to launch icecat with MOZ_WAYLAND_ENABLED
<efraim>(STILL NOT A BUG REPORT) and torsocks isn't happy with me
<efraim>still need to upgrade by user packages
<zimoun`>nckx: how many derivations do you build?
<nckx>I didn't check. Was that the problem? That it silently does nothing/too little?
<nckx>‘computing 19,666 package derivations for x86_64-linux’
<nckx>A bit satanic, but nothing over the top.
<nckx>I don't understand what the problem is, you'll have to share more than ‘x doesn't work’.
<nckx>Otherwise, it seems like something's wrong with your installation, and what is anybody's guess.
<zimoun`>nckx, the time-machine tries to build many derivations. Then fails. For instance cannot build derivation `/gnu/store/pw35ppk895rdzwykb5zhr20m5kkp0qrq-datefudge_1.23.tar.xz.drv': 1 dependencies couldn't be built
<nckx>Yeah, but I don't get any of that.
<zimoun`>if you have all already in your store that’s not a problem :-)
<nckx>That error isn't unusual in itself. Things fail. Why did it fail?
<zimoun`>my expectation is: it just works, building many many thing. But no, it just fails.
<nckx>Sometimes things do. I just had 3 packages fail to build in so many hours. I tried them again (2 on a different machine) and voila, they worked.
<jonsger>efraim: you could create an icecat-wayland package like icedove-wayland...
<zimoun`>nckx: because is missing
<rekado_>progress I guess
<nckx>zimoun`: OK, that's known.
<rekado_>I switched the controller from BIOS boot to UEFI boot
<rekado_>and it worked
<zimoun`>ahah! And?
<rekado_>which means: guix system reconfigure thought it was a good idea to just switch modes on me
<rekado_>and is back up
*rekado_ shakes head
<zimoun`>it is not possible that because Berlin is down, ‘guix pull --no-substitutes’ fails! When Bordeaux is up!
<rekado_>berlin is not down any more
<nckx>What does bordeaux have to do with --no-substitutes?
<efraim>jonsger: I know, I'm not ready to commit to wayland icecat, it wasn't working for me before
<zimoun`>rekado_: cool! Thanks for the work!
<rekado_>zimoun: how does it fail?
<zimoun`>nckx: what have to do with --no-substitutes?
<nckx>I don't know zimoun`. That's a different URL than the previous one (which is known vanished) and I still don't understand what you're actually asking.
<nckx>This is the first time you mention ci.guix.
<zimoun`>I am asking why ‘guix pull’ does not work when Berlin is down when we are running Bordeaux.
<rekado_>for the record I changed two things: enabled disk fallback, so that more disks are retried when one cannot be booted from (shouldn’t have any effect because there’s just one virtual disk, RAID0, two SSDs, and one HDD as a spare)
<rekado_>and: switched to UEFI boot.
<nckx>zimoun`: And I'm asking, I guess, besides actual details, why bordeaux being up should make it succeed.
***chris is now known as Guest599
<nckx>You're saying that like it's a logical conclusion.
<nckx>Why should bordeaux have substitutes for 94836b2? (Spoiler: it probably doesn't.)
<nckx> doesn't exist.
***Talisman is now known as Dio
<nckx>So I still don't understand how bordeaux is supposed to make your command work.
***Dio is now known as CarDio
<zimoun`>nckx: that’s my point! We are running 2 build farms. I am not asking that the 2 build farms serve all the substitutes, I am asking why when Berlin is down, ‘guix pull’ becomes broken despite Bordeaux is up.
<nckx>Because vanished.
<CarDio>Site is working for me
<cbaines> doesn't serve content addressed files in the same way that does
<nckx>cbaines: How's that?
<cbaines>I'm looking at addressing that at some point, and then I guess there's a list it needs adding to somewhere
***sam__ is now known as sam_
***gmodena_ is now known as gmodena
***ft_ is now known as ft
***lukedashjr is now known as luke-jr
<cbaines>nckx, the requests look different, the sha256 is used rather than the hash bit of the narinfo
<cbaines>guix publish does the translation, and it's something I'm hoping to enable with the nar-herder thing that I'm setting up currently
<nckx>So we could get that file from bordeaux somehow, today, with a different URL scheme?
<nckx>Oh boy, a new name ☺
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
<nckx>I think that's all the old URLs?
<nckx>I left out ‘1.3.0 is out!’ because c'mon.
<cbaines>nckx, maybe, I think bordeaux might have nars for the relevant file
<cbaines>just needs to serve it in a way that's understood
***jave_ is now known as jave
*** changes topic to 'GNU Guix | ⚠️ is down ⚠️ | Download: | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
<nckx>cbaines: guix build datefudge --source --substitute-urls=
<nckx>I see.
***ChanServ sets mode: -o nckx
<nckx>zimoun`: Also, bordeaux has been, er, ‘paused’ since the beginning of the month.
<nckx>The situation is really not great.
<zimoun`>nckx: ok.
<nckx>zimoun`: It still serves older substitutes but its ability to serve as a back-up is virtually nil.
<zimoun`>nckx, I understand.
<civodul>hey, it's back!
<efraim>anyone have a patch for lagrange?
<civodul>rekado_: big thank you! you're our hero!
<nckx>how many beers do we owe rekado_ now?
<nckx>Are we bankrupt?
<civodul>i think so
<nckx>Oh well. It's been fun.
<efraim>I hear he also takes payment in making a service copy the necessary bits to /boot for berlin
<nckx>rekado_: Seriously though, you will not be spending too much next FOSDEM (if that ever happens).
<civodul>i know the kind of pressure you have when you're *the* person who can access the machine
<nckx>efraim: Heh.
<civodul>it's no fun
<civodul>thumbs up, rekado_!
<civodul>how about a hackathon to improve redundancy/backups?
<civodul>for example, we talked about redundancy for the web site but never got around to implementing it
<civodul>cbaines is also looking at synchronizing nars among multiple servers, that's another thing we could work on
<nckx>Good idea. I think we all had certain ideas during this ordeal. We should give them form while they are still fresh.
<civodul>and there's, too
<civodul>yeah, let's come up with a list of tasks
<nckx>Seven-ALB[m] proposed possibly hosting another mirror.
<nckx>I also noticed that the Chinese one doesn't actually function in the absence of berlin. Or at least not for me. That might've been for whatever other reason (GFW?) but it's something that I'll investigate further, because I was kind of counting on it as a fallback.
<civodul>re the Chinese mirror, does it actually use rsync?
<nckx>I'm not aware of any that do?
<civodul>i know rsync was almost, but not quite, ready to use
<nckx>I don't think it works as things are now.
<civodul>not sure what's missing now
<florhizome[m]>So something around Origin record type has changed?
<nckx>Erp, I thought you knew.
<nckx>Another thing to look up.
<nckx>(me or florhizome[m]?)
<civodul>nckx: "yes" to you, "no" to florhizome[m] :-)
<civodul>florhizome[m]: if you have updated your checkout, i suggest running "make clean-go && make"
<efraim>I went full 'git clean -dfx' for this one
<efraim>and then a second time after rebooting
<nckx>‘As I said earlier, this does not
<nckx>work well for Guix because Guix client does not handle HTTP 302 redirection correctly. So we tweaked the program a little bit to offer transparent proxy to Guix client. The program is here:‘
<nckx>But if rsync is close to being ready, that's what mirror operators actually understand.
<nckx>I didn't know it was, that's good news.
<CarDio>Hello, here i can find an answer about packages like haskell's gi-gtk?
<florhizome[m]>I just pulled -- which checkout? i get a few error messages like this and some package names are not found anymore. guix build: Warnung: „(gnu packages my-fonts)“ konnte nicht geladen werden:
<florhizome[m]>In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
<nckx>(gnu packages my-fonts) is not a Guix module 😉
<florhizome[m]>the german says "warning: (...) couldn't be loaded"
<nckx>Is it your channel?
<florhizome[m]>yes it's a local file under GUIX-PACKAGE_PATH
<abrenon>it's a local package of yours that needs recompilation because it was compiled with an old version of guile
<nckx>You need to (at least) make clean-go in your local checkout.
<abrenon>I get those all the time after I finally guix pull (twice a year)
<abrenon>more or less
<florhizome[m]>where is that :D
<nckx>It's more often if you pull more often. Remarkably so.
<nckx>…GUIX-PACKAGE_PATH, according to you 😛
<nckx>I don't know what it looks like.
<abrenon>but there's also some stuff in ~/.cache/guile or something, isn't there ?
<nckx>But that would be printed in the error message if it were the problem, I think.
<abrenon>so apparently I did miss all the fun
<civodul>nckx: rsync may well be ready, we should get in touch with mirror operators
<nckx>Although it's possible that guix pull swallows errors.
<abrenon>the server is back online
<nckx>abrenon: Yes, poor you.
<florhizome[m]>i don't even have make in my profile
<nckx>If you don't have a Makefile it's not relevant.
<florhizome[m]>GUIX PACKAGE PATH are just scheme files though ...?
<nckx>And the cache directory abrenon mentioned?
<florhizome[m]>I don't
<nckx>I find it very strange that there are no .go files mentioned in the error message; my Guix always spams me with them, copiously.
<nckx>civodul: ‘May well’ sounds… like you're guessing. Not that I know much about mirror operation.
<abrenon>so how can we make sure the disk in berlin hasn't been tampered with ?
<nckx>We'll use Seven-ALB[m] as a guinea pig, if they get approval to go ahead with it.
<florhizome[m]>nckx: i can have a look at the usual place
<civodul>nckx: the last issue i was aware of was a permission issue on /var/cache/guix/publish, which was fixed months ago
<civodul>but yeah, for the rest i'm just guessing
<nckx>abrenon: Maybe there are cameras. I don't see an ‘internal’ way.
<florhizome[m]>what should i be looking for in the chache?
<civodul>did someone write a recap of the new things that were just merged?
<florhizome[m]>just rm -rf
<civodul>i think mothacehe had written one a few months ago
<nckx>florhizome[m]: Nothing, just delete it.
<florhizome[m]>wiping is a good thing.
<abrenon>it should reproduce the structure of the paths where it found the code to compile
<abrenon>so you can rm -rf selectively if you like
<abrenon>but you can also just wipe everything
<nckx>I need to sleep, it's noon and I haven't slept. Good, er, night.
<abrenon>oyasumi nckx !!
<florhizome[m]>hm maybe geiser/emacs caches would be worth saving but idk shouldn'tbe toomuch damage
<florhizome[m]>gn8 nckx
<abrenon>ohhhh so cool it works in german ! (I was wondering why good neight ^^)
<abrenon>csantosb: it's Xauthority. You need to pass it too
<abrenon>guix shell --container --network --no-cwd ungoogled-chromium --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=/tmp/.X11-unix --expose=$XAUTHORITY -- chromium
<abrenon>should work better
<florhizome[m]>i actually read it in english in my head but yeah^^
<abrenon>aber es wirkt nicht auf Englisch : S
<florhizome[m]>Ok the errors are gone but my packages are just not found now 😐
<florhizome[m]>it's a legit Expression i think :D
<florhizome[m]>germans everywhere, damnit -.-
<csantosb>abrenon: much better, thanks !
<abrenon>: )
<abrenon>(I forget all the time and I always struggle to find it back, so thanks for the practice)
<csantosb>Maybe someone should update the doc (guix shell) ?
<florhizome[m]>Maybe i just pull another time?
<abrenon>csantosb: I tell myself that all the time, and then I find it depends on too many things
<abrenon>(for one, it's a X11-only issue, wayland people shouldn't have to be concerned…)
<abrenon>and I finally leave it as it is
<abrenon>if you find a way to improve it, I'd be glad, because it's a concrete use-case that would be nice to find as-is in the manual
<mothacehe> /query zimoun
<jpoiret>hello everyone
<csantosb>abrenon: the doc as it is now does it for wayland ?
<vivien>So I fixed my issue with the SMTP server (always listen on addresses, not interfaces), and now I can finally switch to the static networking service \o/
<jpoiret>csantosb: wayland only needs --preserve="^WAYLAND_DISPLAY"
<jpoiret>ah, for a container it might need something more (you won't make me admit that i don't know what the wayland transport is)
<unmatched-paren>oh, is berlin back up now? :D
<Seven-ALB[m]>Just had a nap
<Seven-ALB[m]>Is it down still?
<Seven-ALB[m]>I mean i can see the site
<Seven-ALB[m]>But can i guix pull?
<drakonis>It is installing fast now
<Seven-ALB[m]>Really ? Neato
<Seven-ALB[m]>Will install guix on testmachine now
<Seven-ALB[m]>Is it known what happend?
<mbakke>is there a way to force evaluation of inherited package arguments with new variables? i.e. if a package uses the 'version' variable in its builder, it won't change even if the inherited package uses a different version
<EdwardIII>hey, if you want to install guix system on qemu on an ARM guest, what are the options? build it on the host first? interested in playing with it but on mac m1
<EdwardIII>i see you can get guix actual for multiple platforms, but not guix system
<ngz>Nice to see c-u-f eventually merged!
<sneek>Welcome back ngz, you have 1 message!
<sneek>ngz, luis-felipe says: thanks for reviewing and integrating my package :)
<ngz>Party time :)
<EdwardIII>what's c-u-f?
<EdwardIII>what does that mean? time for a release?
<ngz>Yup, it should happen soon. It means most core packages got a version bump.
<EdwardIII>cool stuff
<ngz>Default GCC is now 10, for example
<ngz>It was 7.5 previously.
***aweinsto1k is now known as aweinstock
<jpoiret>mbakke: i think you'll have to inherit but still respecify the version manually
<jpoiret>oh, I typed before I could actually think it through
<jpoiret>I don't think there's a way to do this unfortunately
<mbakke>jpoiret: I worked around it by checking for a magic variable in the invokation environment:
<mbakke>I suppose a proper fix would be to pass #:version to the build system arguments
<rekado_>tensorflow 1.9.0 cannot be built with Python 3.9. 3.7 works (after minor patching).
<rekado_>even if we did fix that by patching the sources, we’d still have the problem that this version of tensorflow is not meant to work with a more recent numpy.
<rekado_>did someone just stop cuirass?
<civodul>not me!
<civodul>but yeah the service is stopped
<rekado_>I’ll start it again
<civodul>it was stopped at 12:41
<civodul>sneek: later tell mothacehe postgres is logging lots of things to syslog, is that intended?
<sneek>Got it.
<ngz>Do I get that there is now a cleaner way to do (string-append "PREFIX=" %output) in #:make-flags using gexps?
<ngz>Like #:make-flags (list (string-append "PREFIX=" %output)) -> #:make-flags #~(list (string-append "PREFIX=" #$output))
<jpoiret>system successfully reconfigured, see you on the other side :)
<ngz>jpoiret: let us know, for the sake of humanity, how it is like on the other side…
<jpoiret>hello again from the new world :)
<jpoiret>although i'm cheating a bit: i had been running c-u-f for a while
<ngz>I want to move to modular texlive. What would be a good starting point as a manifest? I currently use (specifications->manifest '("texlive")).
<civodul>ngz: hi! you might find this helpful:
<ngz>civodul: I do, thank you!
<civodul>i've pushed a draft blog post on simplified inputs and all:
<civodul>i'd welcome feedback!
<civodul>i'd like to publish it tomorrow
<ngz>civodul: speaking of which, is it fine to push inputs simplification changes in master? I noticed many Emacs packages were not updated to the new syntax?
<civodul>ngz: yes, just check the amount of rebuild involved (but for Emacs packages it should be fine)
<civodul>when you know what you're doing, you can do "guix style --input-simplification=always PKG"
<ngz>Yup. I read "Invoking guix style" section already.
<civodul>wonderful :-)
<ngz>You bet I know what I'm doing ;)
<civodul>no doubt! :-)
<civodul>also, i hope the post above answers questions packagers/developers here may have
<ngz>I'm reading it. I assume it'll answer my earlier question about gexps.
<jpoiret>civodul: lengthy read, but quite complete :)
<jpoiret>so, when modifying/updating packages now, should we also add commits that restyle them, or leave it to big `guix style` commits?
<civodul>jpoiret: personally i don't mind smaller commits at this point
<civodul>i think it's ok
<civodul>and yes, the post is quite long (perhaps a little boring?), but i failed to make it shorter :-)
<jpoiret>no, i think it's pretty good. I didn't know about the intricacies of guix style, but the alternative read seems like a great idea
<jpoiret>i could end up using it for personal projects :)
<rekado_>civodul: one minor correction(?):
<civodul>eventually we could add that to (ice-9 read)
<ngz>civodul: nitpick: line 478 , we should enforce usual one-semicolon syntax for end-of-line comments.
<rekado_>in English the ‘h’ is before the ’a’ in the onomapoetic expression for laughter.
<civodul>ngz: yes--future work :-)
<civodul>rekado_: ha ha! i stand corrected!
<rekado_>ah ah!
<civodul>i'm never quite sure about onomatopoetic phrases
<ngz>civodul: I'm just suggesting to manually change it in the document, for posterity (in both old style and new style example).
<ngz>Nice explaination, BTW.
<civodul>ngz: yes, makes sense
<civodul>also, i'd do ";comment" rather than "; comment"
<ngz>I concur.
<civodul>cool, stylistic symbiosis
<ngz>There is also a strange indentation artifact at line 79
<sailorCat>Hi, I'm looking for a two features. First, there is a package — show all executable files it provides. Actually I can find a dir in the /gnu/storage, then inspect /gnu/storage/hash-package-version/bin, but perhaps there is a more straitforward option. Second, find a package that provides a given command. For instance I expected to find hcitool in the bluez package, but it's not here. What else, except install all
<sailorCat>bluetooth-related packages and check them, I can do to find it?
<civodul>ngz: ah, tabs!
<jpoiret>sailorCat: for the first one, you can do `ls $(guix build thepackage)`
<rekado_>sailorCat: it’s a common request, but no, at this point there’s no central service that you can query to answer the question of what files an arbitrary package provides.
<jpoiret>or rather `ls $(guix build thepackage)/bin`
<rekado_>the commands given require the package to be downloaded/built locally.
<rekado_>there’s no way to query this remotely
<jpoiret>the way I usually find which package an executable belongs to is search for its manpage on the internet, and look for what project it is a part of
<abrenon>civodul: strange that no else has noticed but isn't the subject missing at the very begining of the article l'8 «if are to to keep» (I suppose «if *we* are to keep»)
<civodul>abrenon: oops indeed, thanks!
<abrenon>you're most welcome
<civodul>i wrote the first half ~10 days ago and the second half today; maybe that shows...
<ngz>civodul: Actually, the document doesn't answer my earlier question: should we also turn #:make-flags (list (string-append "PREFIX=" %output)) into #:make-flags #~(list (string-append "PREFIX=" #$output)), or is that overdoing it?
<sailorCat>jpoiret: rekado_: thanks for your help
<rekado_>ngz: we should and have done so.
<rekado_>I think it’s a bit funny how we’ve gone from %output to (assoc-ref %outputs "out") to (lambda* (#:key outputs #:allow-other-keys) (assoc-ref outputs "out")) to #$output :)
<rekado_>okay, I cheated with the lambda
<civodul>seen that way, we have one extra character compared to the initial implementation :-)
<ngz>rekado_: it's not always the case, e.g., in `f3' package. Hence my question. But I understand. Now, it's gexp all over the place.
<abrenon>error messages aren't always very helpful
<abrenon>what could "Wrong type to apply: #<syntax-transformer local-file>" mean ?
<jpoiret>going to warm up with the new style by rewriting the pipewire-0.3 inputs
<abrenon>I supposed "apply" refers to something being understood as a function when it's not
<abrenon>but I have no idea what the syntax-transformer type could be, or if that's a good thing
<jpoiret>looks like local-file is not defined at expansion time
<abrenon>thanks !
<jpoiret>syntax-transformer is the type of what syntax objects are bound to (roughly)
<civodul>abrenon: right: you can only "apply" a procedure, as in (+ 2 3), where '+' is "applicable", but here 'local-file' is a macro
<civodul>so yeah, what jpoiret wrote
<abrenon>yeah, but I had forgotten to use-module what brought local-file once in a different file while converting my guix.scm files here and there to use local-file
<abrenon>and the error message was totally different, I wonder why
<abrenon>or what I did differently
<nisha>Hello! just reaching out with my findings about the VM crash: I tried the script and it worked. However, when I run the install steps manually it does crash. I upped my ram and CPU cores on the VM and the manual install steps continued for a little longer and then crashed.
<jpoiret>so, with the new style being significantly terser, should we still try to keep to the one input per line rule, to facilitate merges?
<notmaximed>civodul: Wasn't there a bug report about this-package-input not interacting well with package inheritance?
<jpoiret>esp. for modify-inputs
<notmaximed>Unless that has been fixed since then, it would seem that the blog post is somewhat inaccurate.
<mbakke>civodul: I suppose the manual link should be for the "devel" manual until the next release
<mbakke>eh, derp, the relevant link goes to devel indeed
<civodul>notmaximed: hmm i don't remember seeing such a bug report; do you have a link?
<civodul>this-package-input refers to this-package, so we should be all fine, no?
<apteryx>rekado_: Hi! Thank you for getting berlin up and running again! I'll cherry pick the 3 commits you pushed to core-updates-frozen to master, then delete the core-updates-frozen branch. Is this OK?
<notmaximed>The problem was that 'this-package' is the original package definition, not the new package definition that inherits from the old .
*notmaximed searches
<jpoiret>notmaximed: doesn't that mean that it is a bug of (guix records) rather?
<notmaximed>a bug or a missing feature, I dunno
<abrenon>is there a way to somehow "evaluate" a (local-file …) entry ? since I started using it in that repos, it doesn't find my (git-versioned) files anymore
<abrenon>is a remote needed or something ? I don't understand what's going on
<jpoiret>civodul: the blog post may be missing an example for a non-out package output
<civodul>jpoiret: you mean with #$output:foobar?
<civodul>perhaps more an example for the manual though, WDYT?
<jpoiret>no, rather for a new-style package input using a package's non-out output
<jpoiret>eg (list `(,util-linux "lib")), see in gnu/packages/linux.scm
<jpoiret>also, I'd like some input (heh) for the one-line-per-input rule wrt the new style
<civodul>notmaximed: works fine for me
<rekado_>the postgres logging to /var/log/messages is a bit excessive
<rekado_>that log file is 34G now
<civodul>this-package-input honors lexical scoping so i don't see how it could do something else
<civodul>rekado_: yeah i noticed that
<civodul>we should turn it off
<civodul>i presume mothacehe might have been testing things?
*rekado_ tries to figure out why the machine failed
<civodul>jpoiret: ah yes, we could add such an example
<civodul>will do
<rekado_>interestingly we got a clean SIGTERM at 2:55am
<civodul>"we" = PID 1?
<notmaximed>civodul: it wasn't quite that
*notmaximed writes example
<rekado_>civodul: yes, all services were orderly shut down
<rekado_>acording to the chat logs there were problems at 1:54am
<ngz>jpoiret: I think the document explains it at some point. It's up to 5 inputs on a single if that fits, one line per input for greater values, IIUC.
<rekado_>could be off by one hour
<ngz>jpoiret: on a single line*
<civodul>rekado_: could you share the /var/log/messages excerpt somewhere? navigating it is... hard
<rekado_>also: the root account’s .bash_history has been cleared
<cehteh>cleared as totally empty or as in some old content?
<civodul>rekado_: it was reconfigured at 02:11am
<rekado_>three lines
<civodul>per "guix system describe"
<rekado_>bash_history really shouldn’t be empty
<efraim>got to dive into wikipedia and power architecture to add a section to the manual about powerpc-linux existing but being unsupported
<notmaximed>civodul: something along these lines:
<notmaximed>Though you gave some numerical computing package as an example, I think
<civodul>rekado_: can it end up being emptied if there are concurrent shells running, and/or root runs "reboot"?
<civodul>i don't think so, but i'm not sure
<notmaximed>It's unsurprising the hello+broken-sed2 is brokenly succeeding, but it is a limitation of this-package-input
<rekado_>civodul: I don’t know. I just find it really suspicious.
<civodul>notmaximed: ok; so i think it's working as advertised
<rekado_>we get a clean shutdown and all traces in bash_history of executed root commands removed. This doesn’t smell right.
<civodul>rekado_: perhaps we should have an email thread among people with root access first to sort this out
<civodul>it does look fishy
<ngz>Hmmm texlive-fira has a wrong hash.
<tschilptschilp23>wow, building the new ungoogled-chromium at updating packages toasts my laptop for 1.5hours already...
<abrenon>tschilptschilp23: yes it's usually pretty long
<mbakke>tschilptschilp23: I hope you don't need your laptop for the next 8-12 hours
<notmaximed>Looking at line 187 of guix/records, it appears 'this-package' refers to the package the thunk is used in, not the package it was originally defined in.
<tschilptschilp23>mbakke: it's running anyway, I'm writing from it :) not doing any heavy calculations...
<notmaximed>So all is ok, though the substitute-keyword-arguments thing not interacting well is suboptimal
<abrenon>what could've been the target ? corrupting binaries ?
<notmaximed>Maybe we need some extra syntax like (package (inherit old) (arguments old => (substitute-keyword-arguments old [...]))
<ngz>latex-textpos also has a wrong hash... what's wrong with those texlive packages....
<mbakke>ngz: perhaps they were added on 'master' after TeX Live had been updated on 'core-updates'?
<sozuba>Hi, I am facing the same error as mentioned in this mail thread (, but there seems to be no response to it since 2019. While, as mentioned by jpoiret earlier, i can use the shell based process for installation. I still would like to find out why I am facing this issue (OCD? :D ) .
<sozuba>Any headers/help?
<vivien>rekado_, you pushed 3 commits to core-updates-frozen after it has been merged, maybe you would want to push them to master instead?
<rekado_>vivien: I have
<rekado_>oh, the push was rejected
<jpoiret>sozuba: FTR, using qemu directly, not virt-manager as in the thread
<ngz>mbakke: When %texlive-revision is changed, all hashes need to be updated in tex.scm?
<jpoiret>did you try to enable the interface and manually dhcpcd on it? the qemu default network configuration runs a dhcp server on the virtual interface
<mbakke>ngz: correct
<ngz>mbakke: It makes sense, but ouch nonetheless.
<samplet>It looks like emacs-libgit fails to build on master. Is it just me? It seems it can’t find the “emacs” input. Could be a problem with the simplified inputs.
<tex_milan>Seeing all the troubles, it looks like ability to seed build packages automtically is needed. Do you remember bittorrent? :)
<sozuba>jpoiret thanks for responding again, as much as I am aware, I am not running qemu through virt-manager. But incase I am wrong, could you please let em know how to know if i am using virt manager?.
<samplet>It fails to build in the ‘make-autoloads’ phase, when ‘(assoc-ref inputs "emacs")’ returns ‘#f’.
<sozuba>jpoiret, I tried yesterday as per the docs on manually enabling network, interfaces seems to be up and i try to enable dhcpcd as well. Then gave up. I will try again now
<jpoiret>sozuba: as long as you are running the qemu command line, you are not using virt manager
<jpoiret>what happens when you `dhcpcd` on the interface? does `ip addr` report an IP address afterwards
<ngz>samplet: Ouch. Subtle problem. make-autoloads expects "emacs" label.
<samplet>I thought it might work with "emacs-no-x", but no luck. (I haven’t learned the new system yet! :p)
<ngz>Would it make sense to change (string-append (assoc-ref inputs "emacs") "/bin/emacs") into (search-input-file inputs "/bin/emacs") in `make-autoloads'?
<jpoiret>yes, although I think it would require a rebuild of every package using the emacs build system
<ngz>Not a biggie. Emacs packages are very light.
<ss2>is being 502 for anyone?
<sozuba>jpoiret, in that case i am running qemu directly. The manual talks about "dhclient -v interface (eth0)".. results in IP  dhcpcd (tried, says unknown command).
<ss2>no, all good, was on my side.
<jpoiret>uhm, right it's `dhclient`, my bad :)
<samplet>Ah. I see the commit came from 44 minutes ago. I guess it’s not my lucky day today! :)
<sozuba>i tried to ping, unknown host. I think that;s due to the chosen interface not supporting icmp?
<jpoiret>have you tried using wget (or curl, can't remember which one is included in the install image) to try to reach a random website? (ping might not work, because ICMP requires priviledges)
<sozuba>will try wget or curl,
<jpoiret>although unknown host is more of a DNS issue
<sozuba>brb, on a call i can;t ignore
<jpoiret>no problem. You might want to check if you have a DNS server configured (your router might not have a default one, and so dhclient might not pickup any)
<ngz>samplet: I need to go. Hopefully, the issue is fixed.
<samplet>Me too. I’m sure one of the many Magit users will do something.
<jpoiret>samplet: too bad, I haven't yet made the switch to guix emacs packages, still using straight.el
<samplet>I didn’t use Emacs nearly as much until switching to Guix, so I didn’t ever have to migrate a config or anything.
<abrenon>bye everyone
<abrenon>good luck with the post mortem ! I hope it's not too bad
<jonsger>Hm starting with firefox 95, they wanna have WASI (webassembly) which we need to package. I hope it will not require to much work. At least it's only optional ATM...
<sozuba>jpoiret it works after configuring dns server, thanks
<jpoiret>no problem, glad it's working for you :)
<sozuba>jpoiret, thank you :). Although I feel this is probably a bug and should be corrected, so as to be helpful to people. after connecting, going through the guided installer cases the same issue. So I am going to go ahead with the manual installation for now, but will submit a bug report.
<jpoiret>sozuba: for sure, I will open a bug on the installer, hopefully we can add this feature for 1.4
<jpoiret>it should just be a matter of checking for and optional set dns servers manually
<jpoiret>optionally *
<sozuba>that's awesome. thank you :)
<jonsger>btw congrats @all and @maintainers to the core-updates-frozen merge :)
<jonsger>makes life simpler :)
<apteryx>seems the make-autoloads phase was fixed by 6717ce28d0; thanks to Nicolas!
<apteryx>jonsger: I feel that's probably going to translate into more bundled rust crates.
<jpoiret>anything against patchsets that improve related packages at the same time? i have a couple of patches updating pipewire, xdg-desktop-portal-wlr, flameshot and adding wireplumber
<jpoiret>I'd like to avoid opening multiple issues for that, and the leaf changes require the others version bumps
<apteryx>it's OK to send related patches (commits) to the same guix-patches issue (preferred, actually, to have the full context)
<apteryx>makes it easier to review/work with
<apteryx>ah, I've reached that emacs-libgit failure
*mbakke just used 'git format-patch -U' for the first time, neat
<apteryx>(assoc-ref inputs "emacs") returns #f in the build phase of emacs-build-system.scm
<mbakke>sometimes you want applying a patch to fail if the surrounding context changes, even if your one-line hunk could be auto-merged
<jonsger>apteryx: this WASI thing?
<civodul>mbakke: oh nice
<civodul>though often i find it annoying that "git am" is stricter than "patch"
<mbakke>civodul: git am -3 to the rescue :)
<civodul>i always end up doing "git am --show-current-patch=diff|patch -p1" in such cases
<civodul>"git am -3" sounds nicer
*apteryx tests a fix
<mbakke>that pipe to 'patch -p1' is a neat trick, I've always manually merged when am fails...
<dissent>hey guix major update today. i can't upgrade any packages or install anything.
<jpoiret>what do you mean by "can't upgrade any packages"? what fails exactly?
<apteryx>civodul: is it ok to lookup emacs in the build phase amongst inputs? (thinking about cross builds)
<ngz>uh oh. It looks like I broke Emacs packages.
<apteryx>civodul: like this:
<ngz>apteryx: No it doesn't work apparently =/
<apteryx>what doesn't work?
<ngz>(search-input-file inputs "/bin/emacs") raises the following error: In procedure string-append: Wrong type (expecting string): #f
<apteryx>works here (I built emacs-libgit with the change)
<dissent>jpoiret: i'm sorry, that wasn't correct. the packages that give me trouble are network-manager-applet deluge gtk+ webkitgtk gnome-keyring libnotify poppler libsoup libappindicator zathura telegram-desktop libx11 xorg-server.
<apteryx>now pushed
<dissent>i'm getting the upgrade both or remove one from the profile reponse.
<ngz>Ooohh. OK. I understand.
<jpoiret>dissent: when did you guix pull? I had a problem with python2-gobject
<jpoiret>but it's now fixed on master
<dissent>jpoiret: this started happening last night.
<ngz>apteryx: I made the very same change in `make-autoloads', in fact we were talking about two different changes.
<jpoiret>you should try guix pull'ing again
<jpoiret>thankfully, we have rollbacks :)
<apteryx>ngz: oh, you are Nicolas!
<apteryx>yes, I made this change looking at 'git log' and seeing you had fixed the same problem for another phase, thank you!
<podiki[m]>sneek: later tell @CarDio I saw you asked about haskell-gi, actually I packaged it (working!) but isn't in guix just yet
<sneek>Will do.
<ngz>apteryx: Unfortunately, my fix was incomplete. Thanks for fixing the fix ;)
<apteryx>hehe, team work!
<dissent>jpoiret: i have been... 2 new commits just came in though. yes I exercised some rollbacks today. excellent feature. renders btrfs redundant, no?
<unmatched-paren>hi guix!
<unmatched-paren>i'm back at my computer now, so i can reconfigure to the new merge :D
<unmatched-paren>see you in the promised land :P
<ngz>apteryx: I think emacs-xyz.scm is now ready for a massive re-styling!
<jpoiret>dissent: do you know what exactly fails?
<apteryx>ngz: hehe! it's a good timing if you want to do it (it has to rebuild them all anyway)
<apteryx>do others sometimes see: "guix package: error: got unexpected path `/gnu/store/some-path`" ? during substitution?
<apteryx>retrying usually works, so it seems load/network related
<nckx>Morning Guix!
<apteryx>civodul: when you have a chance, could you save your work and retry: "35560 normal Ludovic Courtès GNOME Shell 3.28 crashes and suspends to RAM (!) after ejecting removable media". That's a ridiculous one.
<rekado_>apteryx: fixing this will break my workflow
<civodul>apteryx: i think the bug is gone
<civodul>i haven't seen it since then (on my partner's laptop)
<nckx>What was the cause?
<civodul>no idea!
<civodul>that was a looong time ago
*nckx had never seen it.
<jpoiret>dissent: looks like deluge is broken
<podiki[m]>with the hit or miss of suspend to ram, maybe that was the only way to do it consistently for someone :)
<apteryx>all these 'guix pull' bugs leave me clueless. what should we do about them?
<rekado_>close them if they are not actionable
<rekado_>do you have an example?
<efraim>Let's tell people to try again instead of telling them to open a btig report
<apteryx>52145 is one, but this one got stale so the action is easy (close)
<jpoiret>it wants to propagate `librsvg` instead of gtk+'s `librsvg-bootstrap` or `librsvg-2.40`, so it's bound to cause problems
<florhizome[m]>guix pull has become very slow for me somehow
<rekado_>florhizome[m]: what’s it do?
<nckx>Maybe you're building more of it locally? (It does a remarkable amount of work for a ‘mere pull’.)
<dissent>jpoiret: i see. i removed deluge and the issue is now with with bpytop.
<florhizome[m]><dissent> "jpoiret: i have been... 2 new..." <- I don’t think they are redundant ;) there might be cases where you prefer one over the other, though.
<jpoiret>dissent: now, that one doesn't build at all, could you post the build log in a paste?
<dissent>I remove bpytop and another issue is with fontmanger.
<dissent>sure thing.
<unmatched-paren>looks like the new master will be slightly more difficult to get to than i thought :/
<unmatched-paren>pygtk failed to build
<dissent>jpoiret: the build fail for bpytop: and the fail log for fontmanger:
<podiki[m]>pygtk was supposed to be fixed? (right before the ci crash) and worked for me at that point at least
<unmatched-paren>oh, i'd guix pulled yesterday before the ci crash, so i'll pull again
<unmatched-paren>Inconsistency detected by dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
<unmatched-paren>when i guix pull
<unmatched-paren>i'll try using an old version of guix in my profile maybe?
<apteryx>which package?
<jpoiret>dissent: fontmanager will be easy to fix, however bpytop has a problem with python's sanity-check phase, which I don't know the intricacies of
<jpoiret>could anyone pitch in? I'll fix fontmanager
<apteryx>I can take a look
<unmatched-paren>pulling from an old guix in the store worked
<unmatched-paren>now i'll just reconfigure...
<apteryx>not prime estate though: No dependents other than itself: bpytop@1.0.67
<AwesomeAdam54321>Yay, I managed to set up GNU Shepherd as a working init system on a foreign distro
<apteryx>as the foreign system init system?
<dissent>that sounds... like a project.
<AwesomeAdam54321>dissent: Yeah, and it was fun
<unmatched-paren>that sounds like exactly the kind of thing i wouldn't have dared doing before guix and its rollbacks
<AwesomeAdam54321>apteryx: It's not set up as the default one yet on boot, but yes
<apteryx>pretty cool!
<apteryx>seems the python sanity-check phase gets broken by guix styled python packages
<dissent>apteryx: oh well, back to htop :)
<apteryx>so to unbreak bpython you'd have to unstyle it
<civodul>apteryx: could you collect issues of that sort (Python & Emacs)?
<apteryx>making python-build-system label agnostic is going to cause a mass rebuild. We can batch these changes and try them in the version-1.4.0 branch
<civodul>i'm surprised because the CI evaluations yesterday didn't show anything bad
<apteryx>Emacs is now OK
<unmatched-paren>why's /gnu/store/--8<--guix-packages-base.drv taking so long to build when i pull?
<rekado_>unmatched-paren: it compiles all of gnu/packages/*.scm
<unmatched-paren>it's still at 0%
<rekado_>if you’re unlucky you’ll have to do this locally
<rekado_>usually, though, will finish building this before you have to
<apteryx>civodul: perhaps I spoke too soon; investigating about that bpytop failure
<rekado_>and then “guix pull” just downloads the compiled stuff
<unmatched-paren>makes sense
<unmatched-paren>okay, it's rocketed up now
<apteryx>the script got called like: "python" "/gnu/store/" "/gnu/store/0irzla32qarhqja1zsbyjhan8qbm6h9w-bpytop-1.0.67/lib/python3.9/site-packages" failed with status 2
<apteryx>and failed because: error: unrecognized arguments: /gnu/store/0irzla32qarhqja1zsbyjhan8qbm6h9w-bpytop-1.0.67/lib/python3.9/site-packages
<unmatched-paren>also did someone try to update gnome to 41?
<apteryx>that is odd
<jpoiret>dissent: I just sent a fix for fontmanager, but it's not pushed yet. It did build, and seemed to work when I launched it, but I didn't test anything else
<jpoiret>i'll look at deluge
<lfam>That's weird unmatched-paren
<lfam>I wonder where that package comes from
<unmatched-paren> looks like it; see line 8647
<lfam>I see unmatched-paren
<nckx>unmatched-paren: ‘Try’? They should even have succeeded.
<lfam>Ah, I thought we were on 40.0
<nckx>It's a spotty 41 IIUC.
<lfam>Unfortunately it failed to build
<unmatched-paren>"I thought we were on 40.0" <- me too
<nckx>A mutt of 41 & (possibly mostly) 40.
<lfam>builder for `/gnu/store/3zv14c2bzqfx35qlrhrmzx8cl8z0gw8n-webkitgtk-with-libsoup2-2.34.1.drv' failed with exit code 1
<nckx>raghavgururajan will know more.
<apteryx>about bpytop I guess it does some tricks to use argv[0] and then doesn't like that it's invoked through
<apteryx>I don't see how this could be something new; was it working on c-u-f before yesterday?
<podiki[m]>i've gotta run, but looks like the CI hasn't built anything since the crash last night?
<podiki[m]>(last guix commit is from right before, the pygtk one, according to the frontend)
<nckx>lfam: That's not reproducible then. What's the error?
<podiki[m]>(and now timing out on the ci frontend)
<apteryx>civodul: nevermind about what I wrote earlier with sanity-check; no issues there :-0
<unmatched-paren>"building profile with 2 packages" ???
<lfam>Click the raw log
<lfam>"%exception #<&invoke-error program: "make" arguments: ("-j" "24" "-j" "24") exit-status: 2 term-signal: #f stop-signal: #f> "
<unmatched-paren>it might be because i salvaged a guix 1.3.0 out the store to get around the dynamic linker errors on the latest guix?
<rekado_>unmatched-paren: “guix pull” has its own profile
<unmatched-paren>ah, k
<rekado_>it’s at ~/.config/guix/current
<nckx>Error copying file (if different) from "/tmp/guix-build-webkitgtk-with-libsoup2-2.34.1.drv-0/webkitgtk-2.34.1/Source/JavaScriptCore/Scripts/wkbuiltins/" to "/tmp/guix-build-webkitgtk-with-libsoup2-2.34.1.drv-0/build/JavaScriptCore/Scripts/".
<nckx>OK, didn't know if you'd seen it.
<lfam>I did after I pasted the incorrect line :)
<lfam>Anyways, it's weird. There is a substitute for this derivation
<nckx>I know!
*apteryx drops the investigation on bpytop -> something to do with wrapper script / arg manipulation I guess
<nckx>I'm glad I'm not the only one who didn't grok that lfam.
<unmatched-paren>lxde has failed too, right before gnome
<nckx>That one's a real error, at least: launchtaskbar.c:71:10: fatal error: gdk-pixbuf-xlib/gdk-pixbuf-xlib.h: No such file or directory
<jpoiret>dissent: any other failures you're aware of? I've just sent a patch fixing the deluge build as well.
<jpoiret>oh no, they left
<jpoiret>back to my own packages then
<NicholasvonKlitz>Is there any quick way to spin up an ad-hoc impure build system, say `cargo-build-system`, where all programs necessary to hack in that environment are there, but instead of dependencies coming from guix, they are pulled in from the language's native package manager, say `cargo` and
<unmatched-paren>this is weird
<unmatched-paren>was there any change to the package since '24 hours ago'?
<jpoiret>NicholasvonKlitz: isn't just cargo sufficient for that task?
<unmatched-paren>oh, it's a dependency issue... lessee
<lfam>Are there any timestamps on those failed builds?
<NicholasvonKlitz>similar to `guix shell` but without the needing to manually specify all the packages necessary to build an average c++ or rust project
<unmatched-paren>lfam: there are no timestamps -.o.-
<unmatched-paren>(on the failed ones)
<unmatched-paren>gnome-control-centre is failing, it seems
<unmatched-paren>..which, in turn, has failed because of network-manager-applet...
<unmatched-paren>...which failed because of libappindicator...
<nckx>Yeah, it ends in python2-pygtk
<unmatched-paren>ah :)
<nckx>I got the same error building it on my laptop yesterday.
<jpoiret>mhmmmm, 4 CVEs for XOrg today
<nckx>I could work around it by dropping pdfarranger.
<unmatched-paren>python is far more widespread than i thought, huh
<NicholasvonKlitz>jpoiret: It might be a cargo-guix specific bug, but when I try to build outside of a cargo-build-system and a crate depends on gcc, I always just get `error: linker `cc` not found` even when gcc-toolchain is install, which leads me to believe environment variables are not set properly
<nckx>It holding GNOME hostage is a problem.
<jpoiret>uhm, i reported the python2-pygtk failure yesterday, and when I guix pulled a couple of hours ago and rebuilt, it was working
<unmatched-paren>aha, the latest gnome-41 build failed because of sushi
<nckx>NicholasvonKlitz: gcc-toolchain doesn't provide a ‘cc’ symlink. Does cargo respect $CC?
<nckx>You can set it to gcc then
<unmatched-paren>what even is sushi
<unmatched-paren>anyway, i've reonfigured now; see you in the promised land (for real this time!)
<NicholasvonKlitz>nckx: I'll give it a try
<nckx>unmatched-paren: See the ‘raw’ in your last URL? That's sushi.
*nckx apologises profusely, got 2h of sleep.
<jpoiret>this is morphing into c-u-f sprint v2
<unmatched-paren>i survived!
<unmatche1-paren>ok whut
<unmatche1-paren>guix upgrade crashed gnome
<NicholasvonKlitz>nckx: that solves it. I think it could be a productivity boost if there could be a pure profile that includes rust, cargo, pkg-config, openssl, etc. by default with environment variables properly set
<NicholasvonKlitz>* pkg-config, openssl, gcc-toolchain, etc. by
<NicholasvonKlitz>* pkg-config, openssl, gcc-toolchain, etc. by, * properly set. So you could just do something like `guix shell rust-app` and start working on most packages.
<nckx>Possibly! I don't hack in rust so it's better if you propose all details directly to bug-guix at gnu dot org 😉
<unmatched-paren>ok, maybe it's an extension issue; i'll upgrade on the vt and remove my extensions
<nckx>Or maybe guix-devel at gnu dot org instead, NicholasvonKlitz. Even if wishlist bugs are acceptable it's more of a discussion IMO.
<apteryx>NicholasvonKlitz: that wouldn't be very Guixy though; pulling extra deps just to be able to build C things will not please everyone
<unmatched-paren>gnome likes to spontaneously crash when it doesn't like an extension
<apteryx>when building purely Rust things doesn't require them
<unmatched-paren>ohno, upgrade is pulling in firefox source, i have a bad feeling that it'll try to rebuild icecat :|
<apteryx>for the linker thing, perhaps it could be improved by explicitly using 'linker' in cargo.toml, something I discovered on the 'wip-cross-built-rust' branch or similarly named
<unmatched-paren>ok... i'll C-c that and just kill the extensions -.o.-
<nckx>I still have 12 rusts to bootstrap.
<apteryx>the first one (1.40) takes 1 h 30, the others about 10 minutes each on a fast machine.
<apteryx>but... how did we trigger a rust rebuild?
<NicholasvonKlitz>does cargo-build-system include gcc by default?
<lfam>Maybe we never built it?
<apteryx>NicholasvonKlitz: I'm not sure how exactly, but it seems it does implicitly
<lfam>Or like, maybe Rust was garbage collected
<nckx>That would be the cherry.
<apteryx>I still have it here it seems
<apteryx>on current master
<nckx>berlin has that.
<apteryx>how do you trigger rust builds?
<unmatched-paren>okay, gnome is still misbehaving, i'll try guix upgrade --do-not-upgrade=icecat and just settle for epiphany for a bit
<unmatched-paren>the only reason i use icecat at all is librejs
<nckx>If you took my ‘I'm still bootstrapping rust’ to mean ‘it's missing on berlin’, I apologise, that is not the case. I build my own packages.
<apteryx>ah! so you had not built c-u-f yet, right? it shouldn't have changed
<nckx>Indeed, not on this machine.
<unmatched-paren>it probably does need upgrading; when i tried to `guix install gnome-shell-extensions` to get the new GUI, it complained about cairo and told me to update it
<unmatched-paren>oh great, it's building a couple of rust packages
<unmatched-paren>this'll take a while...
<nckx>Rust packages (not compilers) can be quite zippy.
<unmatched-paren>`patch-cargo-checksums` seems to take a while usually
<unmatched-paren>it's rebuilding `bat`, it seems
<unmatched-paren>ah, alacritty too
<podiki[m]>CI (at least frontend) to me not showing builds after last night (pygtk commit)
<podiki[m]>#54345 for guix → 94836b2
<lfam>Yeah, it seems that Cuirass is paused on CI
<zimoun>I have machine running old CentOS (argh dam daily job!) with 2.6 modified kernel. Do you think it is possible to somehow “guix pack linux-libre” and unpack ? Tweaking some conf files?
<jpoiret>lfam: sorry for the half baked patch. Looks like the only kept reference is an auto-added GI_TYPELIB_PATH in the wrapper launcher for the python script
<lfam>zimoun: At least one thing will not work, or will need to be adjusted. The kernel config option CONFIG_MODPROBE_PATH="/run/current-system/profile/bin/modprobe"
<lfam>zimoun: I don't know if it does anything while building, or if it can be changed after building and before booting
<lfam>jpoiret: No need to be sorry, it's what review is for
<jpoiret>i'll look into how to remove it
<lfam>I'm not very familiar with GI / gobject-introspection. Do you know what is the right thing to do here?
<jpoiret>I just think that the crams all known GI repositories in the wrapper, so I think it will be safe to remove
<lil>Hello! Please share commit with builded telega, with current commit guix build php
<lfam>Alright. Can you test the resulting deluge package, jpoiret? I'm not so familiar with deluge either
<jpoiret>me neither. The last one looked okay though, but I didn't test the torrenting part since I only touched UI-related stuff.
<jpoiret>but I can test the basic functionality, sure
<lfam>I just decided to look more closely at your patch because I know we are trying to phase out the C librsvg
<zimoun>lfam, thanks.
<lfam>zimoun: I know that Debian has kernel building scripts built in to the kernel source code. Like, you can do `make bindeb-pkg`, and install what it creates. Maybe there is something similar for RPM?
<unmatched-paren>ok, i've upgraded. let's see if gnome stops complaining.
<lfam>I sometimes take the Guix kernel config and build Debian kernels with it. I have to adjust MODPROBE_PATH and change the compression algorithm used by switching from MODULE_COMPRESS_GZIP to MODULE_COMPRESS_XZ
<luis-felipe>Hi, anyone else getting this errors when recofiguring the system?
<sneek>Welcome back luis-felipe, you have 1 message!
<sneek>luis-felipe, nckx says: Thank you for making it.
<luis-felipe>guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.
<luis-felipe>substitution of /gnu/store/13wxi7vjnvyk9xzqav3pls3vignqz2k1-rust-1.54.0 failed
<luis-felipe>guix system: error: corrupt input while restoring archive from #<closed: file 7ff7915452a0>
<lfam>luis-felipe: Hm... does the error happen again if you run the command again?
<unmatched-paren>ok, gnome's working! :D
<luis-felipe>lfam: Yes, I've run it twice
<unmatched-paren>gnome-shell-extensions-app is crashing and apparently is written in javascript, which means extra pain :)
<jpoiret>javascript? do you mean GJS, the Gtk abomination layer over JS?
<lfam>luis-felipe: Can you run your command again, but with --dry-run, and then find the .drv file that corresponds to rust-1.54.0?
<lfam>And share that filename
<unmatched-paren>jpoiret: gjs, yes
<luis-felipe>lfam: Yes, let me check...
<unmatched-paren>javascript is for the web,
<unmatched-paren>people should stop trying to force-feed everything with it
<unmatched-paren>see also: electron
<unmatched-paren>even on its intended platform, js is really overused tbh
<zimoun>lfam, thanks. I will give a look. :-)
<jpoiret>is string-prefix? standard guile, an srfi, or rnrs?
<nckx>It does not require any module imports.
<ngz>Gah. emacs-guix: 1, me: 0. I couldn't restyle it completely.
<luis-felipe>lfam: Running reconfigure with --dry-run, I don't see rust-1.54.0 in the output (
<lfam>Alright :/
<unmatched-paren>i just noticed that i'm still on gnome xorg... is there a way to change it now? (there's still no gnome wayland option in gdm)
<unmatched-paren>wasn't wayland support for gdm one of the main changes in old c-u-f
<jpoiret>unmatched-paren: you need to have wayland? #t in your gdm configuration
<unmatched-paren>ok, i'll do that, thanks
<unmatched-paren>after adding wayland? #t to my config, reconfiguring, and logging back in, i'm still in xorg
<apteryx>jpoiret: standard guile
<unmatched-paren>do i need to do something in gnome's config too?
<jpoiret>is there any way to use (guix search-paths) from the build side?
<jpoiret>I get "no code for module (guix search-paths)"
<apteryx>no, it'll probably pull the world unless it's in the (guix build ...) prefix
<jpoiret>there's a comment in it saying that some function is here because it should be used in build side code
<jpoiret>but well
<apteryx>ah, perhaps I'm mistaken then
<apteryx>ah yes, it's used in like every build system, so it should be safe
<unmatched-paren>the manual doesn't seem to have anything about gnome wayland yet
<jpoiret>heh, I wanted to use string-tokenize*, but I'll just use string-split, it will work properly
<jpoiret>unmatched-paren: the devel manual does talk about GDM wayland
<jpoiret>but there's nothing about wayland gnome, because there isn't anything specific to it iirc
<apteryx>ngz: by the way, you could do the whole module at once for package style changes
<unmatched-paren>wayland? is set to #t, but gdm still launches gnome-xorg
<ngz>If I make a mistake, it is easier to revert this way, isn't it?
<apteryx>I'm saying this mainly looking at the 'git log' story; I don't think we want 2000 commits for 'guix style 'changes :-)
*apteryx deleted core-updates-frozen
<minikN>Hello, when making a change to doc/guix.texi. How can I build the docs so that I can view the change (preferably as html)?
<lfam>`make doc/guix.html`
<lfam>Similary `make doc/`
<minikN>Thank you!
<ss2>lfam: thanks for the fix! Was too late to answer last night.
<lfam>No worries
<unmatched-paren>should the gnome wayland session's Exec look like this: "Exec=/gnu/store/b0fifkclg2vvq4y1grkp22qzrmha46js-gnome-session-40.1/bin/gnome-session"?
<unmatched-paren>hm, looks like both the xsession and the wayland-session have the exact same Exec line
<unmatched-paren>since the session is in the store i can't change it...
<unmatched-paren>i'm not even sure how to launch it with wl
<unmatched-paren>there's no --wayland option for gnome-session or gnome-shell...
<unmatched-paren>looks like you do --session gnome-wayland in the gnome-session command
<unmatched-paren>i'll try that on the tty
<NicholasvonKlitz>I'm trying to package gtk4-rs on c-u-f, but I'm getting errors from guile I'm having trouble understanding
<NicholasvonKlitz>I'm sure it's a simple issue. Does anyone have any ideas?
<nckx>NicholasvonKlitz: Share your package.
<lfam>"Wrong type (expecting pair): #<package graphene@1.10.6 gnu/packages/gtk.scm"
<lfam>It's unusual to see the package@version syntax in this context, right?
<lfam>I thought that @version syntax was only for the user interface
<nckx>lfam: It's how package objects are pretty-printed.
<nckx>scheme@(guix-user)> graphene
<nckx>$1 = #<package graphene@1.10.6 gnu/packages/gtk.scm:2395 7a95c22e9790>
<NicholasvonKlitz>nckx: whoops. I fixed it. Sorry for the false alarm haha
<lfam>Rubber duck debugging
<NicholasvonKlitz>accidentally defined graphene a second time
*nckx ・゜゜・。。・゜゜\_o< QUACK!
<florhizome[m]>Hm my sddm and enlightenment still don’t work
<florhizome[m]>I thought it was bc I was using different wayland/wayland-protocols packages but now these are updated
<unmatched-paren>aww, --session just moaned about systemd not existing
<unmatched-paren>ah, looks like --session uses $GLOBAL_DATA/gnome-session/sessions/... instead of xsessions/wlsessions
<florhizome[m]>What’s the difference between having wayland-protocols in native inputs and in normal inputs ? I normally put them in native, but these packages don’t ...
<lfam>native-inputs are dependencies that are only used while building
<unmatched-paren>so basically the gnome wayland .desktop file is wrong
<lfam>"The distinction between native-inputs and inputs is necessary when considering cross-compilation. When cross-compiling, dependencies listed in inputs are built for the target architecture; conversely, dependencies listed in native-inputs are built for the architecture of the build machine.
<lfam>native-inputs is typically used to list tools needed at build time, but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or Bison."
<lfam>I don't know anything about wayland so I don't know if it's right or wrong
<florhizome[m]>wayland-protos definitely has functionality that is especially used at buildtime like wayland scanner and
<lfam>Note that the distinction only matters for cross-compilation
<unmatched-paren>the .desktop files of the x session and the wayland session look _exactly_ the same
<unmatched-paren>except for names
<unmatched-paren>so -.o.-
<lfam>Nothing will break if you put a dependency in the wrong category but are not cross-compiling
<florhizome[m]>But probably also some libraries
<florhizome[m]>Both sddm and enlightenment fail to find their wayland server.
<florhizome[m]>So basically there should be no libraries that are not propagated inputs or packages themselves?
<lfam>Not sure what you are asking
<lfam>Everything in Guix is a package
<lfam>I think we just need to find some common terminology :)
<florhizome[m]>Actually: All files are either from directly installed packages or propagated inputs
<jpoiret>unmatched-paren: gnome-session --wayland on a tty should pseudo-work iirc
<jpoiret>but I'm not even sure. GDM should work for sure, that's what I mostly tested
<jpoiret>ehm, no, gnome-shell --wayland rather, sorry
<jpoiret>florhizome[m]: what exactly is not working? I could help debug it
<acrow>Hmmm... I don't understand why git clone <guix.git>; ./bootstrap && ./configure ends with cannot find libgcrypt. guile-gcrypt as well as libgcrypt are in my profile?
<jpoiret>did you just install them?
<acrow>Fresh, very fresh.
<jpoiret>try logging out then logging in
<acrow>Ah. That, I had not done.
<nckx>I got that when [I deduced that] my guile-gcrypt was older than my guix.
<nckx>Upgrading everything made it work, at least.
<acrow>Well, no luck so far. I've started a new shell under a tmux session and also logged into another terminal session but each returned the same error. I guess I'll need to duck out to allow a complete system restart. Just a few minutes.
<florhizome[m]><jpoiret> "florhizome: what exactly is..." <- sddm is just not starting (i’m left on the ttyand just login from there...) and enlightenment as well. Can send you logs.
<florhizome[m]>but I need to eat sth first :D
<roptat>civodul, first sentence "it's occasionally necessary if are to keep"
<roptat>civodul, "Packaging in Guix are" -> Packages
*lfam learns about the `last` command
*nckx AFK.
<roptat>civodul, and a repetition: "to allow build-side code to allow build-side code"
<roptat>civodul, not sure what get at means: "to get at an input’s file name"
<acrow>The problem persisted across a full system reboot.
<ss2>I'm getting a “Git error: unable to parse OID - too long” while trying to reconfigure.
<apteryx>acrow: perhaps try 'rm guile' and ./configure again
<lfam>ss2: Can you tell what it's doing? Is it trying to build a package?
<roptat>civodul, "we can take advantage of gexps in package definitions will still supporting the common idiom" -> while?
<ss2>lfam: I'm not so sure yet. The host, I got them on two independant hosts. It could do with my declarations. Investigating this now.
<ss2>They both built their profiles, then exited.
<lfam>Hm, I don't know
<lfam>Even google doesn't help
<lfam>It sounds like an incorrectly specific package definition, where the Git commit hash is too long
<lfam>I mean, incorrectly specified
<ss2>reconfigure with vanilla config is fine. Need to do some house cleaning. :)
<ss2>copy pasta for beginners. The hash is missing a character.
<jpoiret>lfam: oh no, i just went down the systemd hole
<jpoiret> looks like they even want to control your partitioning scheme
<jpoiret>or even
<jpoiret>alas, i'll stop and go test sddm instead
<acrow>apteryx: :) I'll re-read the docs and try again from the top.
<unmatche1-paren>jpoiret: shouldn't gdm with wayland enabled launch gnome-shell with --wayland by default?
<jpoiret>well, gnome-{session,shell} work in convoluted ways
<unmatche1-paren>agh, someone got my nick again
<KE0VVT>Did I read c-u-f is done?!
<unmatche1-paren>yep :D
<jpoiret>you can enable debug? #t in the gdm configuration and look at /var/log/gdm/greeter.log or /var/log/debug
***unmatched-paren is now known as Guest4770
<jpoiret>you'll see what is happening (i don't guarantee understanding it though. I don't)
***unmatche1-paren is now known as unmatched-paren
<unmatched-paren>ok, i'll have a look
<unmatched-paren>since the last gnome fiasco a while ago back on 3 i turned that on before, so i'll just less the logs
<ss2>If I recall right, enabling debuggin in gdm will log to ~/.cache/gdm/session.log too.
<unmatched-paren>there are no errors in the gdm log
<jpoiret>among all the ways gnome-shell/session can detect what kind of session it should run, I think XDG_SESSION_TYPE=wayland is the most obvious one
<unmatched-paren>i'll try it on the tty again later, but right now i'm building icecat in the background and i don't want to lose my place
<unmatched-paren>how long does icecat usually take to build? on an average 4-core laptop?
<unmatched-paren>i'm not sure checking the ci's timestamps will give me a time representative of a laptop :P
<lilyp>I'd say anything between 0.5 and 2.
<f1refly>is theres something special I need to do to get my clipboard working? I'm running herbstluftwm, but copy/paste doesn't even work when piping things to xclip
<lilyp>btw. I love how our new backtraces look :)
<tex_milan1>how to know if some package is available on substitute server? I want to update, but it always wants to build nss with takes very long time (doing some tests).
<unmatched-paren>tex_milan1: use `guix weather`
<unmatched-paren>how do i enable the mozilla location services?
<jpoiret>there are two consecutive documentations for sddm-configuration in the manual
<jpoiret>florhizome[m]: at least it's not my fault, only worked on GDM :) I'm starting a barebones sddm vm
<tex_milan1>i am using sddm and it works nicely
<tex_milan1>the first section in documentation is correct
<jpoiret>did you guix pull & reconfigure since yesterday?
<tex_milan1>yes, just a minute ago. not restarted yet
<tex_milan1>got like 50new packages and 64updated. is this the merge of f-c-u?
<tex_milan1>(from guix pull --news)
<jpoiret>sddm starts as expected on a guix system vm for me florhizome[m]
<jpoiret>I have to say that it looks pretty nice
<tex_milan1>can you try to switch back to gdm?
<tex_milan1>for me switching once from gdm to sddm just broke gdm. going back results in black screen, gdb seems running but display is black and unrespositive
<jpoiret>can you even have multiple DMs running at the same time?
<jpoiret>this surely isn't supported
<tex_milan1>not using them both, just reconfiguring it form sddm to gdm broke gdm...
<jpoiret>hmmm, should be expected, kind of, since they have the same shepherd service name
<tex_milan1>like once you try sddm you cannot go back to gdm
<jpoiret>gdm with gnome 41 looks nice
<jpoiret>but yes, pulling the whole gnome-shell tree is annoying
<jpoiret>so sddm works for me, sway won't launch but that's because by default it won't launch on a software_renderer backend
<lilyp>thanks libglvnd
<jpoiret>it's in a VM so it's expected
<jpoiret>i looked up how to use hardware accel under qemu, but it looked annoying and I could just start sway with a flag anyways
<ison>Does anyone have pipewire working? It seems the latest version is missing the "pipewire-media-session" binary. It existed prior to this update and was working. I thought it was required unless you have an alternative like WirePlumber, but there is no wireplumber for guix yet as far as I know.
<jpoiret>ison: I am literally writing the patch cover letter for such a patchset
<jpoiret>includes pipewire update to 0.3.41 and wireplumber
<ison>jpoiret: Ah ok, good to hear. Thank you.
<jpoiret>what will you use it for?
<jpoiret>my motivation was to get screen sharing to work properly on wlroots-based compositors
<ison>I have no specific need. Just testing it. I still have pulseaudio installed so for now I'm just falling back to that.
<jpoiret>we're a long way from supporting pipewire out of the box though
<jpoiret>you will need to launch it manually
<vdv>is pulling or reconfiguring faster with the c-u-f merge?
<jpoiret>I don't think there should be any noticeable difference
<vdv>or does c-u-f just contain package updates?
<unmatched-paren>why do you ask?
<unmatched-paren>there's package updates and a couple of improvements to guix itself
<jpoiret>well, package updates, service updates, patches and the like
<unmatched-paren>like `guix style`, which is a new command to style-check your package definitions
<unmatched-paren>and yeah, service updates
<unmatched-paren>as far as i know, no performance improvements
<ngz>I hereby declare emacs-xyz.scm as (almost) new-style compatible.
<raghavgururajan>The check phase of python-precis-i18n fails on master
<podiki[m]>glibc got an ld cache per package, that might be faster
<podiki[m]>or at least less disk searching for libraries
<KE0VVT>Backing up.
<kwjc>Hello guix!
<phodina[m]>I'm trying to add Rust package to rust-apps.scm. But the package requires gcc-toolchain as an native-input.
<phodina[m]>Adding commencement module to satify the import causes strange guile errors with unbound variables.
<phodina[m]>I've tried to add just the use-module statement and I still get the errors. Is it possible there is some sort of circular dependency created?
<the_tubular>Is this known : /builder for `/gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv' failed to produce output path `/gnu/store/v5yajfs2y28wl3np4v4y6pr9lwgyadd9-guix-package-cache'
<the_tubular>build of /gnu/store/dvzk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv failed ?
<jpoiret>the_tubular: are you using other channels?
<the_tubular>No, only officials
<podiki[m]>(I've hit that too, but think it was from outside channel with some conflicting package or something)
<the_tubular>I planned to create my own channel, but I haven't done it yet
<the_tubular>What else could be causing this ?
<unmatched-paren>...aaaand icecat has built!
<unmatched-paren>that took
<the_tubular>View build log at '/var/log/guix/drvs/dv/zk7gwy7syz8y80pb8xf36lb45plf12-guix-package-cache.drv.bz2
<the_tubular>This is not a log file ...?
<unmatched-paren>you'll need to bunzip2 it
<Brandong[m]>use `bzcat`
<the_tubular>Got it
<unmatched-paren>then less the resulting file
<the_tubular>Why is it compressing log files ?
<podiki[m]>or bzless
<unmatched-paren>oh, bzless is a thing?
<unmatched-paren>i thought it was just bzcat
<podiki[m]>probably because they are kept in the store and text compresses nicely?
<podiki[m]>(you can view old build logs which is handy)
<podiki[m]>bzless I have on guix at least
<podiki[m]>from bzip2 package (a default?)
<Brandong[m]>But I am also seeing the same. guix-package-cache log shows:
<Brandong[m]>(repl-version 0 1 1)
<Brandong[m]>Generating package cache for '/gnu/store/xl3q58vzsakzwpr28ajc3cmhl2iycn6z-profile'...
<Brandong[m]>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (modify-phases)) (value #f))
<podiki[m]>bzless is handy
<podiki[m]>Brandong: yeah, that looks like something referring to a package that doesn't exist (anymore)
<KE0VVT>Anybody use RDE?
<raghavgururajan>Holy Crap! Calibre broke. The ebooks are rendering weird. No texts, only images.
<phodina[m]>> <> Hi,... (full message at
<nckx>Doesn't that (above) mean that modify-phases itself is undefined?
<Brandong[m]><podiki[m]> "Brandong: yeah, that looks..." <- As in a package in my profile? I only have the official channel enabled. Is there a smart way for me to figure out what package causes the problem?
<jpoiret>the recent emacs-xyz.scm commit seems to have broken it
<jpoiret>i'm running make in a local checkout and it's giving me warnings
<jpoiret>hmmmm, the arguments field of emacs-shroud is borked
<jpoiret>only uses (list ) instead of quoting the whole contents
<nckx>That would explain Brandong[m] error nicely.
<nckx>Since mod-pha isn't defined on the host side.
<jpoiret>looks like `guix style` just trampled all over it
<jpoiret>uhm, 88097dfba765bacb809edae7639fc3ed2dead297 as a whole looks borked
<jpoiret>it transformed all (arguments `(#:things ...)) into (arguments (list ...))
<apteryx>I reproduce the problems reported above
<civodul>roptat: thanks for reporting all the typos in the blog post, looks like there's no shortage of them
<roptat>civodul, haven't finished reading, I'm too tired
<apteryx>jpoiret: seems to be at only 2 places (2 packages); lines 1313 ad 12272
<apteryx>shouldn't be too hard to fix without a revert
<jpoiret>oh. i didn't realize the others were using g-exps
<dissent>jpoiret: went out for the afternoon. attempted to pull and got this
<apteryx>guix style will finally force us into proper G-Exp understanding ;-)
<jpoiret>yes, others are having the same issue as well
<jpoiret>a very recent commit introduced this, people are on it as we speak
<phodina[m]>What is the syntax to specify different output of a package in the new input syntax?
<jpoiret>just (list `(,thepackage "lib"))
<apteryx>I'm looking at emacs-shroud; how are we supposed to use (assoc-ref emacs:%standard-phases 'expand-load-path) in the #:phases arguments?
<apteryx>the emacs: prefix is bound via the #:modules argument
<apteryx>civodul: any pro tip? ^ :-)
<jpoiret>aha, do #:modules directly translate to a (use-modules for the gexp) as well as a with-imported-modules outside of it or not?
<nckx>I don't mind, but I wonder why (list `(,foo "bar")) instead of (list (list foo "bar")) ?
<jpoiret>emacs-shroud works for me by just adding #~ apteryx, so i guess the prefix does work that way :)
<jpoiret>nckx: how would scare non-guilers without a quasiquote otherwise?
<nckx>That'll work.
<nckx>At least it doesn't invite typing ("foo", bar) anymore.
<apteryx>that would have clearly wrong, as it should have been ("foo" ,foo)
<nckx>That's clearly bogus.
<jpoiret>list("foo", foo) you mean?
<nckx>How will we document which package contains libuuid, FOR‌ THE CHILDREN?
<nckx>{"foo", foo}
<nckx>["foo", foo] actually works, that's horrible.
<nckx>(use-modules (break racket brackets))
<nckx>src/vdagent/x11-randr.c:985:21: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations]
<nckx>Breaking guix system vm gnu/system/examples/vm-image.tmpl
<nckx>Anyone already claimed that bug?
<apteryx>I think not!
<jpoiret>i see 'xrandr.c', all yours