<rekado>the name “GuixSD” was a compromise. I thought the name “GSD” (for GNU System Distribution) nicely mirrored “BSD”, but some people (I want to say rms, but maybe there were more) thought it might be misunderstood as a jab against BSD.
<rekado>this came after just “GNU System” was rejected.
<rekado>and I think with “Guix System” we’re pretty close to where we wanted to be initially
<nckx>I wasn't involved in the GuixSD naming but it's obviously aquired some (wholly undeserved) patina as ‘the beloved original name’ when actually, no, nobody involved loved it that much, and I'm also glad it's buried.
<rekado>“GuixSD” always seemed a little weird to me; once past the odd pronunciation of “Guix” (already a phonetic obstacle) you had to abruptly stop on an “x” and switch to acronym mode with “SD”. What a bumpy phonetic ride!
<elevenkb>It's in the /gnu/store/*-xkeyboard-config-2.34/share/X11/xkb/rules/evdev.lst
<nckx>Sure. It's a wholly valid layout & life decision, did not mean to imply otherwise.
<nckx>Problem is I don't see any obvious mistakes, so at straws we grasp.
<elevenkb>nckx: oh to joys and sorrows of the path towards GNUrvana.
<elevenkb>Let me switch to sway actually (which is where I eventually want to end up).
<nckx>Reason I asked ‘where’ above is because there are still cases where it's ‘expected’ (=unfixed) for GRUB not to load your layout, but a DE/WM/compositor with the full power of XKB behind it definitely should.
<elevenkb>How long should it take to run your first guix pull (on a 15Mbps connection)?
<nckx>Minutes. But that's the answer for subsequent guix pulls on many machines. It is not very optimizised.
<nckx>elevenkb: (Yes, this is really how long it took to test) When I change nothing else but "us" "norman" → "be" "nodeadkeys" the layout changes, so it's definitely the culprit, even if it shouldn't™ be.
<roptat>nckx, the first guix pull needs to clone the git repo, which can take a bit longer than subsequent pulls if you do them frequently
<nckx>It also has to authenticate ‘all’ commits, I know. But people often expect apt-like times, or network-bound ones, and I wanted to frame expectations.
<elevenkb>nckx: (with-teary-eyed-smile "thanks for letting me know")
<gabber>i am unable to (cross-) compile a Guix image for arm architecture (kernel module not found "ahci"). which seems odd since ahci is an intel specific thing? i tried the following command: `guix system --target=arm-linux-gnueabihf image ~/src/guix/gnu/system/examples/beaglebone-black.tmpl` (the path leads to the example in the guix source tree). what am i missing/doing wrong?
<test1234[m]>Is there a way that can reduce disk usage as much as possible, best like the first install usage? I try guix gc, but this can’t reach my goal.
<nckx>civodul: Intuitively I'd say so. I don't think there's any logic in how we currently configure kernels. That's not criticism; I've just asked a few times now and ‘nobody’ seems to have a reasoning for what goes where.
<nckx>Like %default-extra-linux-options implies some kind of layering or consistency that just isn't there, because it's thrown on top of ancient (and very magic, possibly cargo-culted) .configs that differ wildly and undocumentedly by architecture.
<civodul>apteryx: what does /proc/sys/kernel/yama/ptrace_scope say?
<nckx>This sounds more negative than intended so I'll stop. I'm just trying to express the depth of my confusion, nothing more :)
<nckx>My blind spot is Linux on non-x86, but I don't think that can cover this.
<tricon>nckx: i feel ya. i'd quite like to get into ARM/RISC-V archs; but at this moment, i feel more inclined to hack on x64 Hurd than work with other archs at that level. of course, there's so much work to do on x86 Hurd as-is.
<nckx>Oh, always nice to meet a Hurd contributor in the wild.
<nckx>Although I guess this channel is next-door to the zoo. Still.
<tricon>nckx: not one quite yet! but it's on my radar.
<tricon>microkernels are exciting. need to read up on the latest approaches, though, as there's an oft-speculated performance hit with them. curious where/how practical those complaints are in modern times.
<apteryx>my emacs has started throwing the error: Invalid handler in ‘file-name-handler-alist’ when I visit /tmp. Any clue?
<user_>podiki[m]: yes I have a corruptd file, I cant fix it yet
<jackhill>I have had repair repeatedly download the same substittue though. Is that part of the same shortcoming (I thought it was understood which is why I haven't created a report)?
<nckx>That's actually the behaviour I was ‘expecting’. It's a bug, but it's not strictly the same bug, IIUC.
<rekado>abrenon: when a process declares an input and no connected process provides this input it is said to be a free input. “guix workflow” will abort and ask the user to provide that input (if there is no matching file)
<user_>13:26 < nckx> user_: There's a horrible thing we could try: downloading that file from Savannah, remounting your store read-write, and copying it there by hand…
<abrenon>ooohhh I see so there's no argument passing from workflow to processes, they help themselves directly
<user_>I was thiknig something lik this but I dont know exactly how to do this.. I will need to try this at night
<user_>Im at work for now, can really crash my computr if soemthing goes very bad
<abrenon>I think I was viewing workflows as "main" functions a little too much
<nckx>user_: It won't, but totally agree we shouldn't invite risk in unnecessarily.
<rekado>abrenon: yes, a workflow is how processes are connected to one another (and properties that apply to this collection of processes, such as cache keys). Everything we want is really in the processes, including inputs.
<rekado>abrenon: I think there might be value in being more explicit about inputs and outputs of a workflow, but I can’t think of a good reason to make this declaration redundant.
<rekado>that said: I’d be happy to discuss the merits of different strategies for the GWL over at #guix-hpc or on email@example.com. The basic premise was “what if we didn’t bring Guix to workflows, but instead bring the workflows to Guix?”; pretty much everything else is negotiable.
<abrenon>no I don't think there'd be much added value either, but the overall syntax might deserve an example in the documentation
<abrenon>I didn't want to hijack #guix into #guix-hpc, I was initially hoping I was just being slow getting the syntax and a one-line answer would solve my problems : )
<elevenkb>I can't launch any terminals, tried ansi-term in emacs, gnome-terminal, the Xfce terminal (in both GNOME) and Xfce
<henrytill>hi, new user here, installed guix as a package manager on debian testing, followed manual for locales and whatnot, installed guile and am getting "guile: warning: failed to install locale" when i run it
<vagrantc>but when you "guix show" something with @code or @acronym, it isn't displaying the full length
<vagrantc>henrytill: have you logged out and back in again?
<henrytill>yep, debian testing, logged in and out (several times)
<nckx>henrytill: If so, check LANG. By default I think it uses the then-nonstandard C.UTF-8 locale, which didn't exist when that glibc was released. It was added in a later version but that's not the one Guix uses less.
<vagrantc>henrytill: what locale is running on your debian system?
<nckx>Try upgrading it, or even better, *all* packages in your profile at once.
<henrytill>oh yes i forgot to upgrade my locales after guix pulling!
<nckx>Yeah, this is a mildly annoying property of glibc locales.
<nckx>It's mentioned in the manual near GUIX_LOCPATH I believe.
<henrytill>yes, in fact, i context-switched and forgot to do it
<Luchadoritos>Hey Guix! I need to install TensorFlow with version newer than 2.7.0 (currently Guix has 1.9.0). I've been having trouble with an error system-error "mkstemp " "~A" ("No such file or directory") (2) after running "guix build tensorflow --with-latest=tensorflow" similarly if I replace with-latest with --with-commit. Any hints on what I can do?
<vagrantc>i'm not terribly invested, other than making guix lint output less noise and more signal.
<rekado>Luchadoritos: it is not at all trivial to build a newer Tensorflow
<rekado>you will not be able to build anything newer than 1.9.0 with the package definition we have.
<rekado>I have some WIP for Tensorflow 1.15.5, but I don’t think I’ll return to work on it.
<rekado>we really need to package bazel and all its Java dependencies; then patch the Tensorflow build system to allow for system libraries to be used instead of having bazel download them all from the internet.
<Luchadoritos>rekado: I see. Thank you very much for your input. I'll find some (inelegant) way to do my work.
<rekado>if you find any way towards a newer Tensorflow in Guix I’d be happy to help
<rekado>I’ve lost most of my teeth while chewing on this problem for the past years.
<Luchadoritos>I looked through the IRC+issues history. It seems that Bazel is not bootstrappable? I don't know the system well enough but I'm willing to spend time in this during the weekend
<Luchadoritos>I didn't look to see if these packages were freedom respecting btw. Forgive me if I say something out of line
<rekado>bazel is free software and it should be possible to build it all from source
<rekado>it just has a lot of Java packages as inputs, and we can’t just take the pre-built jars
<Luchadoritos>Nice! Time for me to learn about build systems. I have a waays to go on this front.
<rekado>we don’t have a whole lot of Java packages in Guix because building them completely from source is often really tedious