IRC channel logs

2019-09-12.log

back to list of logs

<rekado_>montxero: the daemon takes this option.
<rekado_>montxero: the manual mentions this option in the section on Substitutes. Can’t miss it :)
<montxero>how can I set it up so that I do not have to do it all the time, my goal is to be able to upgrade packages without rebuilding the world
<rekado_>just pass the option to the daemon.
<montxero>rekado_: I have played around with that a lot.
<montxero>can you just show me a snippet?
<rekado_>I can’t when I don’t know what substitute servers you want to use. It’s also in the manual, though, so I don’t see how I can help here.
<rekado_>gotta go
*rekado_ –> zzzZ
<montxero>I understand this can seem exasparating, but humour me a moment please. here's my .guixrc https://pastebin.com/dpzFZGcT
<nckx>…what even is a .guixrc? Everything that rekado_ says is true. Anyway, here's the relevant snippet from my configuration: <http://paste.debian.net/1100175/>. If you use %base-services or equivalent (which is likely), I suspect you'll have to use modify-services too, dunno.
<nckx>montxero: ☝
<montxero>nckx: I am using guix in a forigen distro, (essentially as a package manager). The purpose of the guixrc is to have a place where I can manage things like path modifications when certain packages are installed
<montxero>nckx: "guix-daemon --build-users-group=guix-build --substitute-urls "https://ci.guix.info https//:berlin.guixsd.org https//:mirror.hydra.gnu.org"
<nckx>montxero: On a foreign distro you'll have to edit your foreign guix-daemon service (probably /etc/systemd/system/guix-something). You can just add --substitute-urls='…' there. I can assure you: that works.
<nckx>Hm. I don't know how fussy guix-daemon is about ‘=’ vs. ’ ’.
<montxero>nckx: For me, it just freezes up `# guix-daemon --build-users-group=build --substitute-urls=the-urls` just sits freezes up
<montxero>will restart the computer and try agian
<nckx>montxero: Is that with inverted commas? It definitely shouldn't freeze, whatever the case.
<montxero>perhaps I should install a fresh copy of guix, I am on 0.15.0
<montxero>nckx: delimiting the shell command from prose
<nckx>montxero: For completely unrelated reasons that would be advisable.
<nckx>montxero: No, I meant using "them like this" in your service file. 🙂
<montxero>nckx: before I ripout the entire guix and install anew, is there a graceful way to upgrade guix to the lattest version?
<nckx>montxero: Yesss… but it was only introduced after 0.15.0.
<montxero>nckx: hahahahaha... no worries mate. I shall rip this one out then... I better create a manifiest of the packages I use
<nckx>montxero: By complete coincidence, someone just posted their experiences with that. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37374
<nckx>Two days ago I'd've said ‘it's worth a try’, but it apparently isn't ;-)
<nckx>(It has a happy ending: this shouldn't happen again in future.)
<montxero>that's good to hear
*nckx → FKA
<nckx>Er, *AFK.
<nckx>'s Much 's I like miss Twigs.
<joshuaBPMan>Hey guix! Thanks for making such a sweet OS!
<guix>You're welcome!
<sneek>guix, you have 2 messages.
<sneek>guix, user_trisquel says: test
<sneek>guix, user_trisquel says: test
<joshuaBPMan>hmmm. iptables is curious.
<montxero>I'm back! thanks nckx I am up and running now with no issues
<montxero>rekado: thanks as well
<nckx>montxero: Wonderful!
<gnu_srs1>quiliro: I know a lot about Hurd, what did make you believe the opposite?
<rekado>montxero: there are three problems: mirror.hydra.gnu.org no longer exists; berlin.guixsd.org and ci.guix.info are now just ci.guix.gnu.org (which is the default); you wrote “https//:” instead of “https://”.
<rekado>montxero: I’d also recommend against setting all these environment variables.
<sirmacik1>hey guix!
***paroneayea is now known as dustyweb
<roptat>hi guix!
<civodul>Hello Guix!
<gnu_srs1>(23:55:18) rekado_: gnu_srs1: you get the Guix source code, change it, compile it, and then use that changed variant of Guix to do stuff (e.g. building the Hurd bootstrap binaries).
<gnu_srs1>I still don't know how to download, build and install a package within Guix. And then to replace the already running Guix with the new one.
<gnu_srs1>I know perfectly well how to do such stuff outside Guix ;)
<civodul>hello gnu_srs1!
<civodul>gnu_srs1: did you take a look at https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html ?
<gnu_srs1>civodul: I've read the whole manual already. Time to read it again. I have not reached the threshold where things are easy yet.
<rekado>gnu_srs1: downloading/building packages happens later. Do you have a copy of the Guix source tree yet?
<rekado>If you want to change the Hurd port you’ll need it.
<numerobis>Hi #guix! I get an error when installing hypre-openmpi, see http://paste.debian.net/1100233/ . I have three questions related to this: 1) Is there a way to fix this bug? 2) Is there a website where a list of packages that do not currently build is maintained? 3) For a given package, how do I check whether substitutes are available? (I think someone here told me how to do this before, but I forgot, sorry)
<gnu_srs1>I have it on a Debian GNU/Hurd image, but here I'd need it within the Guix image on Linux gnu 5.2.9-gnu #1 SMP 1 x86_64 GNU/Linux
<roptat>numerobis, for 3, you can try to use guix weather
<rekado>numerobis: 1) yes! xy.sty is provided by the texlive-xypic package, which would need to be part of the build environment; 2) ci.guix.gnu.org lists all builds
<roptat>for 2, there is https://ci.guix.gnu.org
<rekado>gnu_srs1: what do you mean by “Guix image”?
<numerobis>roptat,rekado: thank you very much, that's super useful!
<rekado>gnu_srs1: you should get the sources on your GNU/Linux development machine, because that’s what you would use to cross-build the Hurd binaries.
<gnu_srs1>It would be too clumsy to download the Guix source code on a Debian GNU/Linux image, change it there and import into the Guix image.
<rekado>I don’t know what you mean by “image” here.
<gnu_srs1>Guix image = The pre-built one at guix-system-vm-image-1.0.1.x86_64-linux.xz
<rekado>let’s go back one step
<rekado>the bootstrap binaries for the Hurd that are cross-built on a GNU+Linux machine with Guix don’t work.
<rekado>the way they are built is with Guix.
<gnu_srs1>I'm running that image, and used it to build the cross-built tarballs
<rekado>hold up a moment
<rekado>we need to change the way these bootstrap binaries are built.
<rekado>so we need to change the code that is running on the GNU+Linux development machine.
<rekado>at that point there’s no VM image or anything.
<rekado>let’s say you have a Debian GNU+Linux machine on which you develop things
<rekado>on that machine you’ll get the Guix sources with git.
<sirmacik1>I need a little guile help. How can I use (htmlprag) in my scripts? I've installed guile-lib and put (use-modules (htmlprag)) in the code but guile still cannot find it :/
<rekado>gnu_srs1: you then compile that copy of Guix, make changes as needed (that’s the big part), and then use that Guix to build new bootstrap binaries for the Hurd.
<rekado>sirmacik1: did you also install “guile” via Guix?
<sirmacik1>yes, I use GuixOS
<rekado>sirmacik1: if you didn’t you would have to set the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH variables manually.
<sirmacik1>other modules installed this way work (like haunt)
<gnu_srs1>rekado: guix build --target=i586-pc-gnu bootstrap-tarballs
<rekado>make sure that these variables are in fact set and point to directories containing the guile-lib outputs.
<rekado>gnu_srs1: use “./pre-inst-env guix build …” from your modified git checkout of Guix.
<rekado>sirmacik1: oh. Perhaps there’s a bug then, and the files end up in a different directory that’s not on the GUILE_LOAD_PATH…?
<rekado>numerobis: I’m trying to fix the hypre problem now.
<gnu_srs1>So I should use an ordinary e.g. Debian Linux image to build the bootstrap-tarballs?? I thought the guix environment was self-contained.
<rekado>numerobis: I see that texlive-*-xypic packages are among the inputs already, so I’m not sure what’s wrong here.
<rekado>gnu_srs1: I don’t follow.
<rekado>gnu_srs1: the bootstrap binaries are cross-built.
<rekado>once built they are independent of the host system that built it.
<numerobis>rekado: thanks! I will let you know if I can track the origin of the error.
<gnu_srs1>In the pre-installed guix image: guix-system-vm-image-1.0.1.x86_64-linux.xz I did rebuild the cross-tarballs: guix build --target=i586-pc-gnu bootstrap-tarballs
*civodul * rekado looks like Shiva today :-)
<sirmacik1>rekado: how can I chack what files were installed by package?
<rekado>numerobis: I bet the problem is in the texlive-xypic package that I wrote to replace the old texlive-*-xypic variants. It’s probably missing files.
<rekado>sirmacik1: “guix build the-package” returns a directory.
<rekado>gnu_srs1: yes, but as I wrote before: the bootstrap tarballs for the Hurd appear to be broken.
<rekado>gnu_srs1: so we need to make changes to Guix in order to change how they are built.
<rekado>gnu_srs1: exactly what those changes are — I don’t know.
<rekado>gnu_srs1: one of the suggested changes is to build Guile 2.0 instead of Guile 2.2.
<sirmacik1>so it looks like GUILE_LOAD_PATH is set only to /run/current-system/.*
<sirmacik1>and package files are not symlinked there
<rekado>sirmacik1: is “guile” installed into your personal profile?
<rekado>sirmacik1: Guix sets up environment variables automatically when a package that “manages” the environment variable is installed into a profile. In the case of GUILE_LOAD_PATH that’s the “guile” package.
<sirmacik1>no, just with sudo
<rekado>sirmacik1: oh, well that would just install the package for the “root” user.
<gnu_srs1>rekado: Yes, but I thought I could do that _within_ the Guix environment (in the prebuilt image as the guest user)
<sirmacik1>I've installed guile-lib as user and as root
<rekado>from Guix’s perspective the root user is just a regular old user.
<roptat>sirmacik1, you need guile, not guile-lib
<rekado>sirmacik1: please do “guix install guile guile-lib” with your user account.
<sirmacik1>so guile-lib should be installed via config.scm and reconfigure to be available for everybody?
<roptat>mh... yes, sorry I got confused
<rekado>gnu_srs1: it doesn’t really matter where you do this as long as you use that modified Guix to build the new bootstrap binaries. It doesn’t matter if you do this in a VM or on another system.
<roptat>sirmacik1, guix package will install only for the current user (root or regular user), guix system installs for everybody at once
*rekado swings 100 arms
<rekado>numerobis: the problem is indeed with the texlive-xypic package.
<gnu_srs1>rekado: Still, how to: guix download guix; cd /to_guix source code; hack on; make, make install, etc??
<roptat>don't use make install
<rekado>gnu_srs1: please open the “contributing” section in the manual
<roptat>you should rather use ./pre-inst-env
<numerobis>rekado: thanks! But in the definition of hypre, the inputs are texlive-generic-xypic and texlive-fonts-xypic, and not texlive-xypic, right?
<rekado>gnu_srs1: the first item there is 14.1 Building from Git
<rekado>take it from there.
<roptat>and it's best to get the source code from git, so you can send a patch
<gnu_srs1>guix package only speaks about search, install, remove, etc
<roptat>make and send a patch, rather
<rekado>numerobis: that’s right. texlive-xypic is new, texlive-*-xypic are old and are both pointing to texlive-xypic
<rekado>numerobis: so hypre is already using texlive-xypic (just via a detour)
<roptat>gnu_srs1, you should use git, but you can get the source code of a package with "guix package -S the-package"
<numerobis>rekado: ah I see, thanks for the clarification
<roptat>gnu_srs1, "guix download" takes a file, puts it in the store and prints its base32 sha256 hash
<rekado>roptat: this is all correct, but I think it might be a little confusing here as the goal is to build Guix from source first.
<roptat>yes, that's why I said "you should use git"
<rekado>:)
<gnu_srs1>package -S = --switch-generation, doesn't seem to be usable?
<roptat>no, -s is for swatch-generation, but -S is for --sources
<rekado>“guix build -S”
<rekado>but you don’t need it here.
<rekado>please just follow the “building from git” section in the manual
<roptat>oh I'm really sorry, I'm completely off today :/
<gnu_srs1>I was referring to guix package -s/-S
<roptat>yeah, I meant "guix build -S"
<roptat>not guix package
<rekado>numerobis: a fix for texlive-xypic and thus hypre is coming up in a few minutes
<roptat>and you're right about guix package of course :)
<numerobis>rekado: that's quick, thanks! :) Will it be available after a guix pull?
<rekado>once I push it, yes.
<rekado>(don’t pull yet)
<numerobis>rekado: Amazing!
<gnu_srs1>Seems like I have to do the changes within the Debian Linux environment then, either a real box or a VM image ;)
<rekado>gnu_srs1: correct.
<civodul>anyone here remembers why IceCat fails to determine the configured timezone?
<civodul>i think Someone had an explanation, but i can't find it
<gnu_srs1>The path to build Guix from source is a little hairy, many dependent packages are not available in Debian. But it should be somewhat less work
<gnu_srs1>than within Hurd (which I've already done)
<rekado>gnu_srs1: you can use “guix environment guix” to enter an environment containing all development dependencies for hacking on Guix.
<rekado>that is also mentioned in the Contributing section of the manual, which I strongly recommend.
<gnu_srs1>Maybe I should start creating Debian packages for Guix and dependencies...
<civodul>oh wait, we don't have /etc/timezone, maybe that's the thing
<rekado>civodul: I only remember something about GNOME and timezones, something about a convention to use /etc/timezone
<rekado>gnu_srs1: vagrantc has already worked on that, but you don’t really need it to hack on Guix when you already have Guix.
<rekado>numerobis: it’s fixed in commit 8b35c8cd61; you can now pull.
<gnu_srs1>I don't have Guix built and installed in any amd64 box or image. Is there one somewhere?
<civodul>rekado: i created /etc/timezone, but that doesn't seem to help for icecat
<civodul>namely "new Date().getTimezoneOffset();" still returns 0
<sirmacik1>rekado: roptat thanks for help!
<raingloom>is "at" packaged anywhere? seems like a basic thing to have but i couldn't find it anywhere with `guix search`
<rekado>we’re a bit behind on updating matplotlib. The LTS is 2.2.4 (we have 2.2.3), but the latest stable release is 3.1.1.
<numerobis>rekado: the package now builds without errors, many thanks for your help! :)
<rekado>numerobis: excellent! Glad I could help. Thanks for the report!
*rekado updates matplotlib
<apteryx>rekado:I think the python-pathpy should be named python-path.py instead
<sneek>apteryx, you have 1 message.
<sneek>apteryx, leungbk says: the update to python-jedi 0.15.1 is not compatible with Guix's current of python-language-server, which expects python-jedi < 0.15. Please review my patch for python-language-server. Thanks.
<civodul>i may have a fix for icecat's tz issue, in icu4c
<civodul>funny thing: we use zimbra at work and in icecat it thinks i live in UTC
<civodul>so if i don't pay attention, i go two meetings two hours ahead of time
<civodul>*to
<wingo>yay
<civodul>oh you experienced it too?
<wingo>i think i have seen incorrect times in riot
<civodul>heh
<wingo>relatedly: https://github.com/Codiad/Codiad/issues/903
<civodul>you can recognize a Guix user in that they don't know what time it is
<civodul>oh, that copy/paste thing rings a bell
<civodul>i think shift-insert doesn't work in IceCat, which may be the same as this bug report
<civodul>we should fix it
<ng0>you won't be late though.
<civodul>yeah it could be worse ;-)
<wingo>if you have to work with shared google docs it is good to know that a copy/paste fix is very easy
<wingo>better of course if copy/paste events were enabled from the beginning but i don't know why they were turned off, perhaps for a good reason
<civodul>yeah, dunno
<apteryx>civodul: this is because of tracking protection is enabled
<apteryx>if you disable this, you'll see the actual time
<apteryx>I had the same problem (we use zimbra at work too!)
<apteryx>(in retrospect I think this was in Mattermost, not Zimbra -- I don't remember if it applied to Zimbra also)
<apteryx>rekado:pathpy is another thing, so it's confusing
<apteryx>and guix import pypi pathpy import that wrong thing; path.py imports the correct package.
<rekado>apteryx: it should be called python-path-py
<bgardner>Good morning guix, I'm trying to set up an apache instance with a virtualhost definition. I'm following the docs but getting errors. I think the issue is that for httpd-virtualhost entries it says "These should be added to the extra-config for the httpd-service." but I may be doing the "adding" wrong. Can anyone point me to a sample configuration block?
<apteryx>rekado: our packaging guideline only mentions to transform underscore to hyphens, not dots... can't we use python-path.py, given that Scheme doesn't restrict us to do so?
<apteryx>but I don't feel strongly; I just think that's it neat if we can stick to upstream names when it's feasible.
<roptat>we already have lots of go-github.com-* packages :)
<rekado>lots of matplotlib tests fail because of insignificant differences in the generated PNGs :-/
<civodul>apteryx: oh really? how did you disable that?
<civodul>(my icu4c patch didn't help, indeed)
<apteryx>civodul: about:config
<apteryx>then search for tracking
<apteryx>civodul: I think it must be the preference privacy.trackingprotection.enabled
<apteryx>you can try toggling it to false
<apteryx>(type about:config in the URL bar)
<civodul>privacy.trackingprotection.enabled = false here
<civodul>are you using icecat on a foreign distro?
<apteryx>civodul: ah, sorry, the pref is named "enabled", so set it to false :-P
<mbakke>oof, I just read Marks recent announcement :/
<apteryx>civodul: that said, mine is currently set to true and I don't seem to have any issue in Mattermost... weird.
<efraim>I think I figured out the long way to building rust binaries with linking rust libraries, still can't get libraries to link to libraries, might have to propagate them if I go that route
<apteryx>mbakke: indeed :-(
<mbakke>efraim: wooow, nice progress :)
<mbakke>does cargo do the right thing if multiple versions of the same library is available?
<mbakke>(I haven't tried using cargo-build-system yet)
<civodul>apteryx: it *is* set to false :-)
<apteryx>civodul: ah, sorry, I was wrong, the setting is "resistFingerprinting", you must disable it, see: https://mattermost.atlassian.net/browse/MM-9765~
<civodul>howdy mbakke!
<apteryx>err, https://mattermost.atlassian.net/browse/MM-9765
<apteryx>mine is set to: privacy.resistFingerprinting;false
<apteryx>IceCat defaults are pretty safe -- which is surprising sometimes coming from mainstream browsers ;-)
<civodul>hmm "new Date().getTimezoneOffset()" still returns 0
<civodul>or do i have to restart it?
<apteryx>perhaps; on mine it outputs: -540
<apteryx>I get from this that the offset is in minutes
<efraim>mbakke: it does, but for working on it I've stripped the randomish metadata string and I figure I should replace it with the version
<efraim>unfortunately for now I'm basically running "cargo build --verbose @buildflags" and then copying the actual rustc command strings
<civodul>apteryx: is it on a foreign distro?
<civodul>oh after restarting it works, yay!
<civodul>but...
<civodul>it's terrible that one has to disable "resistFingerprinting" altogether just for that
<apteryx>civodul: nope, Guix System
<apteryx>I don't have any foreign distro install at hand anymore, currently.
<civodul>congrats ;-)
<mbakke>efraim: right, heh :)
<apteryx>civodul: indeed :-/
<apteryx>civodul: if you find a more fine grain setting to leak just our timezone, let me know :-)
<joshuaBPMan>morning guix!
<efraim>can a foo.so link to a bar.so?
<efraim>anyone remember what exit code 127 is?
<efraim>s/exit code/exit-status
<iyzsong>127: command not found
<efraim>iyzsong: thanks
<efraim>I knew it was going to be something simple. the file wasn't in the path, so instead of (invoke "test-file") I needed (invoke "./test-file")
<Minall>Hello guix!
<nckx>Hullo Minall, #guix.
<Minall>nckx: Kiel vi fartas!
<Minall>?
<vagrantc>is guix able to download guile-json 3.2.0 ? https://download.savannah.gnu.org/releases/guile-json/ lists it, but downloading it 404s
<vagrantc>also only 3.1.0 is in git from upstream...
<roptat>it works for me
<roptat>both the tarball and the signature
<apteryx>rekado:is it just me, or python-pytest-shutil is broken on master?
<vagrantc>roptat: huh. maybe i'm consistantly getting a broken mirror
<vagrantc>yup. using tor it works fine because it picks a different mirror
<rekado>apteryx: I don’t know. I’m really not the right person to talk to about Python in Guix.
<apteryx>rekado: OK! Sorry for the bother.
<rekado>no worries. Just managing expectations :)
<rekado>I’m pretty ignorant when it comes to the state of Python in Guix.
<apteryx>hehe
<apteryx>useful: https://ci.guix.gnu.org/search?query=python-pytest-shutil
<apteryx>(answer: yeah, pretty much broken everywhere :-)
<apteryx>the interesting twist is I can't find any reference to importlib_metadata in python-pytest-shutil sources, yet it fails looking for it (probably through a propagated dep -- something else must be broken).
<civodul>efraim: 127 is usually (but not necessarily) "file not found"
<civodul>vagrantc: note that download.savannah.gnu.org redirects to a nearby mirror, so it's not deterministic
<civodul>you could try "torsocks wget ..."
<vagrantc>civodul: that's what i did :)
<civodul>heh, we all have the same power tricks :-)
<vagrantc>bigsearcher.com seems to be the broken mirror
<civodul>didn't guix try something else then?
*vagrantc didn't try with guix
<vagrantc>first mistake
<civodul>ah so another trick is "guix download mirror://savannah/guile-json/..."
*vagrantc is without guix for a few days
<efraim>I have a nice simple patch to strip the store hash out of the guix-vendor directory during cargo-build-system builds, looks much nicer and easier to see which crates are there
<efraim>patch-cargo-checksums: generate-checksums for guix-vendor/rust-ndarray-0.12.1.tar.gz
<vagrantc>efraim: regarding the architecture-specific inputs for diffoscope; i gave it a shot but couldn't make it work correctly and didn't have a chance to ask for help; feel free to update it
<efraim>vagrantc: ok. I'll probably just copy from mesa
<efraim>that's the one I remember where it is
<vagrantc>efraim: and now i know how, but don't have the ability to test for a few
<efraim>ok
<vagrantc>well, only because you pointed to an example i could maybe steal :)
<apteryx>OK, found the culprit: grep -rin importlib_metadata /gnu/store/j67rzvp32lc7j6sdivm62i20ch48ysvi-profile/lib/python3.7/site-packages/* --> /gnu/store/j67rzvp32lc7j6sdivm62i20ch48ysvi-profile/lib/python3.7/site-packages/path.py-11.5.0-py3.7.egg-info/requires.txt:1:importlib_metadata>=0.5
<quiliro>every time i reconfigure since about a week, I have this message at the end:
<quiliro>guix system: bootloader successfully installed on '/dev/sda'
<quiliro>shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?).
<quiliro>I know the bootloader message is good
<quiliro>just put it to establish context
<quiliro>and the other message is the last one I get
<vagrantc>i've been seeing that too
<efraim>Maybe I can cheat with rust, make all the libraries install libfoo.so and then link dynamically
<efraim>-C prefer-dynamic keeps on linking with the compiler which I'd rather not do unless I can link to precompiled crates too
<nckx>Minall: Mi fartas bone. Dankon 🙂
<joshuaBPMan>Hey guix, does anyone here use mako, sway, and notify-send? mako cannot seem to connect to dbus...
<joshuaBPMan>Failed to connect to user bus: No such file or directory
<rekado>joshuaBPMan: how are you starting your session?
<joshuaBPMan>rekado: via the console...I do not use gdm or light dm
<joshuaBPMan>aka sway is the first pretty graphical screen that I see on my laptop
<joshuaBPMan>unless you consider grub to be a pretty graphical screen :)
<rekado>joshuaBPMan: the display manager usually also starts a dbus session / user bus; since you’re not using a display manager you get this error.
<joshuaBPMan>rekado: ahhh.
<joshuaBPMan>ps -e | grep shows dbus...
<joshuaBPMan>rekado: do you know if gdm lets you run sway?
<joshuaBPMan>I suppose I can reconfigure and find out.
<vagrantc>i've used sway with sddm
<joshuaBPMan>vagrantc: thanks.
<joshuaBPMan>vagrantc: may I ask why you use sddm?
<vagrantc>because it worked with sway
<joshuaBPMan>ok. makes sense.
<chrislck_>nick chrislck
***chrislck_ is now known as chrislck
<joshuaBP`>hmmm, I'm having trouble configuring sddm...
<joshuaBP`>I'm using dvorak...and I'm getting an error
<joshuaBP`>wrong type to apply...It doesn't like my keyboard-layout...
<rekado>joshuaBP`: “wrong type to apply” means that you’re using something as a procedure which is not actually a procedure.
<joshuaBP`>rekado: hmmm. ok.
<joshuaBP`>I'll take a look...
<joshuaBP`>I am still at a loss. It seems to be trying to use my keyboard layout that I set for my console...
<joshuaBP`>and it is not liking that I am trying to sway caps. but I guess I am still doing something silly, because I'm still getting the wrong type to apply error.
<rekado>can you show your config
<rekado>?
<Sewni>How should package configuration be handled with guix? The web of bash/ini/dsl configuration files would be 'state' right?
<nckx>Sewni: User configuration files are [currently] out of Guix's scope. There is roptat's https://framagit.org/tyreunom/guix-home-manager, which is a work-in-progress/experiment (not sure 🙂) to that end, though.
<sneek>Got it.
<nckx>sneek: I think we both know that's not true.
<nckx>sneek: botsnack, silly bot.
<sneek>:)
<Sewni>Oh okay, I'll check that out - thanks. Does x/wayland/compositor configuration count as 'user' configuration?
<nckx>Sewni: Not when launched from a display manager system service.
<nckx>By user configuration I mean everything under $HOME.
<Sewni>Right. So the idea is that all configuration should be done through operating-system services?
<nckx>There are configuration files in /etc that Guix System doesn't handle yet, but those are within its scope.
<nckx>Sewni: That's the ideal 🙂
<Sewni>Sweet, that keeps things simple. Cheers :)
<nckx>It's not that clean in practice; many packages (CUPS is a good example of both) either store ‘state’ (like timestamps!) that should be in /var in /etc, and/or treat settings in /etc as mutable through their UI, neither of which jive well with Guix's model.
<nckx>It's simple if you ignore the complications 😛
<nckx>sneek: What are user configuration files?
<nckx>Sigh.
<Sewni>Hm?
<Sewni>Oh
<nckx>Sewni: Not clear?
<Sewni>I didnt realise you were using the bot :P
<nckx>‘Attempting fruitlessly’ anyway.
<nckx>sneek: What is user configuration files?
<quiliro>I have a problem with my locales since a week ago when I did guix pull and guix upgrade...I have done them a moment ago. The problem persists.
<efraim>ng0: using 'crate build --verbose' i was able to copy and hand-craft a rust package to use a previous package's .rlib and run the tests, but I don't think it's sustainable unless I can figure out how to point it to a list of directories.
<efraim>these were the two posts I looked at most heavily this time: https://rust-lang.github.io/rfcs/0404-change-prefer-dynamic.html https://github.com/rust-lang/cargo/issues/4538#issuecomment-332368705
<ng0>cool, thanks!
<sirmacik1>any chance that singularity package will be updated to some modern version? Looks like 2.x is EOL or at least depreciated
<Formbi>couldn't Guix home manager lock only directories of managed programs?
<Formbi>and how would it be possible to play around with configurations of things like Emacs?
<quiliro>Formbi: you cannot change ~/.emacs.d ?
<Formbi>I don't use it
<quiliro>Formbi: what do you use?
<Formbi>but from the description I think it's not a very good idea
<Formbi>I use Emacs, but not Guix home manager
<Formbi>couldn't config definitions include directories used by a given program to store configs?
<quiliro>Formbi: what is the Guix home manager?
<rekado>sirmacik1: I don’t know of anyone working on upgrading Singularity. Do you happen to be familiar with Singularity?
<quiliro>never heard about it
<kmicu>Formbi: if someone wants to go fully reproducible then there’s nothing wrong with locking everything. In that case we edit config in the same way as we edit Guix System’s config.
<rekado>quiliro: see above in the logs ;)
<Formbi>kmicu: I think that should be only an option
<kmicu>Then we lose reproducibility. It’s a trade‑off.
<Formbi>quiliro: https://framagit.org/tyreunom/guix-home-manager
<Formbi>we have reproducibility where we can
<Formbi>what's the point of locking everything when not everything has a GHM interface?
<g_bor[m]>Formbi: currently guix home manager works the other way around. You can make exceptions by creating a symlink to a writrable locations for programs that need them.
<Formbi>I know
<Formbi>and I think it's a big overkill
<kmicu>Formbi: roptat (guix-home-manager’s creator) had some ideas for escape hatches. In my mind partial reproducibility is like being partially pregnant.
<Formbi>why should someone make a shitload of symlinks to configs of unmanaged programs?
<kmicu>To have a rock-solid eternal, immutable, reproducible environment.
<Formbi>you can have a full reproducibility in one place and not in the other
<Formbi>and you can have things like Emacs config on git
<kmicu>Not really, my Emacs touches to many places.
<kmicu>home-manager is opt-in so there’s no issue I think.
<g_bor[m]><Formbi "why should someone make a shitlo"> Formbi: guix home manager is implemented along the lines of that philosopy. It is not the only way to do this, it is one way. I believe the semantics you are after could also be implemented by some other software. Wdyt?
<Formbi>but when you opt in, you have to make a lot of exceptions?
<Formbi>couldn't there be just a switch to enable the opposite way?
<kmicu>Yes. It’s the same way as opting in into Guix.
<vagrantc>feel free to implement? :)
<Formbi>I'd love to if i had the skills and time :(
<Formbi>kmicu: but Guix doesn't lock the entire disk
<kmicu>Formbi: all store is read only.
<Formbi>and you can use things like flatpak just fine
<Formbi>store, not /
<g_bor[m]>Formbi: that highly depends on the usecase. When I use users for some classic privilege separation of servers, then I don't need too much exceptions.
<Formbi>g_bor[m]: yeah, but I'm thinking about PCs
<kmicu>Cuz Guix added exceptions. What is not in store is not managed by Guix.
<Formbi>and that's a good approach
<Formbi>so why should it lock things it has no idea about?
<kmicu>To easily catch mutable things.
<kmicu>Otherwise is a complex whack‑a‑mole game.
<Formbi>directories used for configs could just be included in a program config definition
<kmicu>Then some rouge application could easily overwrite my configs. That’s why I prefer total lockdown.
<Formbi>how would it do it if they were locked?
<g_bor[m]>Formbi: one way would be to add an overlay on top, and either keep it permanent or clean it up on reboot.
<g_bor[m]>It would still have some drawbacks.
<kmicu>When everything is read‑only then there’s no issue. If we only choose what is read‑only then we need to monitor all places where configs are sourced. That’s a lot of work.
<Formbi>but if you had things managed by GHM, you wouldn't have problems
<Formbi>and people who use unmanaged things would have to struggle a bit anyway
*rekado sees GHM and thinks “GNU Hacker’s Meeting”
<kmicu>Some programs source code from multiple places. Partially managing only some things with guix-home-manager doesn’t prevent broken rollbacks.
<Formbi>rekado: is there such a thing?
<Formbi>kmicu: but if they do, their definitions should include those multiple places
<kmicu>In the same way a broken gnupg config can make your Guix System unbootable. And every entry from rollback will be borken cuz Guix does not manage ~/.gnupg/
<kmicu>They should but there’s nothing to guarantee all places are included.
<kmicu>Making everything read-only is like a type-system—it forces us to handle all cases. We can be sure everything is being handled.
<Formbi>if everything is locked and someone sets an exception, you have nothing to guarantee either
<kmicu>Then I have an explicit message about that.
<Formbi>hmm, you have a point here
<Formbi>but I still think users should be givem a bit od flexibility if they want
<Formbi>given*
<kmicu>I recommend creating an issue on https://framagit.org/tyreunom/guix-home-manager/issues Documenting your use‑case is the best first step.
<rekado>Formbi: why certainly! This year’s GHM only just concluded.
<Formbi>ah, ok
<Formbi>I didn't know (or remember) that it's called like that
<rekado>Formbi: it’s a very small annual meeting / conference.
<bandali>wishlist for guix in 2019: lvm support
<quiliro>i cannot see https://framagit.org/tyreunom with librejs activated
<rekado>bandali: boot from LVM, right? Mounting LVM partitions works already, doesn’t it?
<bandali>rekado, yeah, the former indeed
<rekado>I wonder exactly what’s missing here.
<rekado>is this just something the initrd needs to be able to cope with?
*rekado has spent the past day looking at the early boot for PXE stuff
<bandali>i have no clue…
<bandali>any thoughts, civodul?
<rekado>I’d love to know what happens right now when attempting to boot into a system that sits on an LVM partition.
<rekado>I guess that the root file system cannot be found.
<bandali>likely so
<rekado>in that case I’d like to see what other distros’ initrds are doing to support booting off of an LVM partition.
<rekado>perhaps we only need statically built LVM utils or something like that in the initrd, and then use them.
<civodul>i guess the initrd needs to load some LVM module and to do some LVM syscalls?
<civodul>which amounts to say very little, but that's how much i know on this topic :-)
<civodul>rekado: how far did you go with PXE?
<civodul>i suppose that too requires changes to the initrd
<rekahsoft>+1 for booting from partitions managed by LVM
<civodul>LVM is sooo 2009 though ;-)
<civodul>i'm being told btrfs subvolumes are the future
<civodul>maybe the present, even
<rekahsoft>NixOs has `nixos-generate-config`, however I have not seen a similar facility for guix. Furthermore, how do folks keep abstract away hardware details/configuration with guix so that a config can be easily applied across machines?
<rekahsoft>Also thanks to Formbi for pointing out Guix Home Manager (GHM as he abbreviated it). Looks pretty fresh still. Would love to see something like this get into guix/guixsd.
<kmicu>not only maybe but for sure it is
<rekahsoft>It would be really nice to have Shepard user services along with this
<rekahsoft>kmicu: Gotta start somewhere :)
*kmicu was referring to btrfs. guix-home-manager is immutable and invincible already.
<rekahsoft>oops. My mistake kmicu. btrfs is great, however my preferred setup is LUKS + LVM where within LVM I have a root and swap partition. The root partition is btrfs and split in subvolumes. I can't yet do this with Guix, but am still working on switching over my main system.
<rekado>civodul: my PXE setup is confusing.
<rekado>but I managed to get to a failed boot.
<rekado>the initrd probably needs changes, but I’m not sure how to proceed.
<rekado>my next test is going to be to provide the root file system via NFS and pass nfsroot to the kernel.
<rekado>that should be sufficient
<rekado>it’s a little more work for the admin to provide an NFS server and to place the installer’s rootfs in a directory there
<rekado>so I don’t really like that
<rekado>but the kernel does support nfs roots (and nothing else really), so it’s the easiest option for us, I think
<rekado>however, in order to test this I need to set up an NFS server
<rekado>and this reminds me that Guix System doesn’t have an NFS service yet — but I have patches to add it.
<rekado>I just never submitted it because writing system tests for this is tricky.
<rekado>we can’t use the usual system tests infrastructure because NFS doesn’t work on top of a file system overlay
<rekado>so the system tests would have to involve full blown VMs.
<rekado>and that’s a little annoying to set up.
<rekado>(and my NFS service does not support NFS protocol 4.1+)
*rekado wonders if the mandb hook could be sped up
<quiliro>rekado: i notice you always retire in what would be a little less than an hour...is it later on your local time zone? here it is 16h08 (UTC-5)
<quiliro>s/later/late/
<rekado>/me’s habits are being monitored
<rekado>it’s 23:13 where I am.
*rekahsoft hopes rekado is right and the mandb hook could be faster 🤞
<rekado>I haven’t looked at it yet, but I hope somebody with a better understanding of performance will.
<erudition>Probably a silly question, but assuming "the mandb hook" is what I think it is, could something like that be done asynchronously?
<rekado>erudition: what would that look like?
<rekado>the mandb is part of the profile
<rekado>so before we can return and say “here’s the profile, go use it” we need to wait for the mandb to be created.
*rekado looks at the mandb hook
<erudition>I as someone using apt all the time I often have to wait for all the "triggers" to run, after the package had been already installed, before I can get control back and run another command. Is there a similar thing when installing guix packages? Because I kinda assumed that's what you were talking about
<rekado>whenever a package is installed (or removed) Guix builds a new profile generation.
<rekado>when all packages have been built and the union directory has been assembled the profile hooks are executed.
<erudition>Of course, if the very next command I run is "man <thing I just installed>" then the page might be missing, but otherwise I feel like it could be non-blocking
<rekado>and they add stuff to the profile generation.
<erudition>rekado: hmm, yeah I guess that model kinda means everything must be totally blocking
<erudition>Oh well, nevermind then
<rekado>doing stuff like this asynchronously would mean that the profile contents would differ depending on when you look at them.
<rekado>it’s a little ironic that generating the db takes so long.
<rekado>the point is to speed up “man”.
<erudition>Hmm, I guess the profile contents could be kept isomorphic though, and only start blocking if the parts not yet filled in are accessed
<rekado>that sounds hella complicated
<rekado>because you’d need kernel support to see what parts are accessed
<erudition>Yeah I agree. Or you could queue up generation-making commands for when the next Gen is available
<rekado>and some part of Guix would always need to be running to fulfill the promise
<erudition>Oh i just assumed you could make the read call take a while to come back, like it's a slow network drive or something
<erudition>But that's probably a hack
<civodul>rekado: a failed boot is a good start :-)
<civodul>the initrd side of things should be doable
<civodul>re man-db, there's a patch to parallelize it
<civodul>it got blocked on details but we should pick it up
*civodul -> zZz
<civodul>night!