<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 <montxero>rekado_: I have played around with that a lot. <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. <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. <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 <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>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.) <nckx>'s Much 's I like miss Twigs. <sneek>guix, user_trisquel says: test <sneek>guix, user_trisquel says: test <montxero>I'm back! thanks nckx I am up and running now with no issues <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. ***paroneayea is now known as dustyweb
<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 ;) <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 <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>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>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? <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: 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/.* <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. <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? <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>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?? <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 <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 <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" <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>please just follow the “building from git” section in the manual <roptat>oh I'm really sorry, I'm completely off today :/ <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? <gnu_srs1>Seems like I have to do the changes within the Debian Linux environment then, either a real box or a VM image ;) <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 <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 <wingo>i think i have seen incorrect times in riot <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 <ng0>you won't be late though. <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 <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: I think it must be the preference privacy.trackingprotection.enabled <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 <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) <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 <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>it's terrible that one has to disable "resistFingerprinting" altogether just for that <apteryx>I don't have any foreign distro install at hand anymore, currently. <apteryx>civodul: if you find a more fine grain setting to leak just our timezone, let me know :-) <efraim>anyone remember what exit code 127 is? <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") <vagrantc>also only 3.1.0 is in git from upstream... <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. <rekado>no worries. Just managing expectations :) <rekado>I’m pretty ignorant when it comes to the state of Python in Guix. <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>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 <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 <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>and the other message is the last one I get <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. ***chrislck_ is now known as chrislck
<joshuaBP`>hmmm, I'm having trouble configuring sddm... <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`>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. <Sewni>How should package configuration be handled with guix? The web of bash/ini/dsl configuration files would be 'state' right? <nckx>sneek: I think we both know that's not true. <nckx>sneek: botsnack, silly bot. <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? <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. <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>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? <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>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. <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. <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 <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>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. <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>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>but I still think users should be givem a bit od flexibility if they want <rekado>Formbi: why certainly! This year’s GHM only just concluded. <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 <rekado>bandali: boot from LVM, right? Mounting LVM partitions works already, doesn’t it? <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 <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. <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>i'm being told btrfs subvolumes are the future <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 *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>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>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) <rekado>/me’s habits are being monitored *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 <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. <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>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 <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