<myglc2x>I had to move a HD to a different slot ... now guix won't boot my raided array because, I think, /dev/sdb1 is now /dev/sdc1 :-( <Apteryx>do we now have a /bin/sh? Or did I added that myself a long time ago? <Apteryx>looks like we now have /bin/sh on GuixSD. I deleted it, and everything fails now. <Apteryx>arg. I've got a test failure only in the Guix build environment. I've tried in a pure environment as well as container, and it passes. The error is: (file-error "Searching for program" "No such file or directory" "/bin/sh") <pkill9>you could try just finding a bash package in the store and re-adding a symlink to that <Apteryx>it's sorted out for my profile, but that failing I'm trying to understand happens on the build side. It's only for a specific package. <Apteryx>which I've updated and enabled the tests. <Apteryx>Works fine everywhere but doesn't pass with 'guix build'. <Apteryx> ;; FIXME: Normally we'd run the "test" target but for some reason the <Apteryx> ;; test-deferred target fails only in the Guix build environment with <Apteryx> ;; the error: (file-error "Searching for program" "No such file or <Apteryx>hmm. Not what I expected to paste ;) <Apteryx>atw: I ended up using: ./pre-inst-env guix build -K --fallback $(guix package -A emacs- | cut -f1) as suggested by efram. <soundtoxin>What package do I want to install for python? I added 'python' to my config and rebuilt, but the python command doesn't work still. <soundtoxin>I tried searching for python and python2, but there are way too many results. <rekado>soundtoxin: the “python” package only provides “python3”. <rekado>soundtoxin: if you must have a “python” executable even though you’re using Python 3 (upstream doesn’t provide one), then you need to install “python-wrapper”. <soundtoxin>rekado: Oh, no, that's fine. I didn't know I had to type python3. Thanks. <g_bor>I have found something really interesting in java-jeromq. <g_bor>It seems, that the tests only fail when sending short messages. <g_bor>I've contacted upstream, if they have an idea what is going on here... <g_bor>Actual error is timeout, and raising the timeout value does not help, so it seems like there is a hang... <g_bor>I've also seen this test suit completely freeze. <pkill9>out of interest is there a Guix equivalent to nixops? <mbakke>Adding a newer cmake as a native-input won't override the one used by cmake-build-system. <ng0>pkill9: yes. no. kind of. <ng0>work in progress'ish <ng0>there's a branch. and discussions <ng0>hg0 is like the HGich.T version of my initialism :) <ng0>efraim: how's the pine64 device? I'm thinking or ordering 2 later this year to replace 2 computers which are essentially just for music and videos. you haven't arrived at the point where a minimal desktop is building, right? <efraim>ng0: I can't talk much now, the wifi isn't free, i currently have u-boot built and it boots grub, I think right now the boot process fails since it can't find the device tree for the board while booting, but I haven't been able to investigate it enough <efraim>the odroid-c2 needs blobs for the flashing of the u-boot <efraim>but overall i have a good feeling about the pine64 ***pkill9_ is now known as pkill9
<dieggsy>huh, guix download is telling me "Wrong type to apply: #<syntax-transformer uri?>" - anyone else seeing this? <lfam>dieggsy: Can you share the command you ran? And the result of `guix --version`? <dieggsy>lfam: sure, gimme a sec. I just pulled like an hour ago so it should be fairly recent <dieggsy>lfam: it's with guix download [any link here] <dieggsy>i hadn't noticed the "failed to install locale" error, honestly <lfam>The locale error (it's really just a warning) should not matter <lfam>I'm doing `guix pull` to try to reproduce <lfam>How about if you try `guix download path/to/local/file`? <dieggsy>lfam: i'm doing another guix pull right now too <lfam>I don't think anything has changed in the last hour or so that would affect this <einarelen>Evening people, I'm trying to install guix on a fresh fedora 27 machine and I'm running into a bit of trouble. Particularly, the systemd daemon fails to exec every time. The error in the log simply says /var/guix/....../guix-daemon: permission denied <einarelen>Running the daemon on its own as root goes fine <lfam>einarelen: And you are sure it's the exact same path being executed? <einarelen> Checked with readlink, its definitely the same <lfam>The systemd service file, is it the one we distribute? <ng0>before GuixSD system init it should be enough precaution to copy the ssh pubkey to /mnt/root/.ssh/authorized_keys .. and set the password of root before running init? I'm installing SD right now from a rescue system. My experience tells me this should be enough, but maybe I'm missing something <lfam>einarelen: I wonder if Fedora is using some extra security features like SELinux that need to be made aware of Guix? <lfam>ng0: Enough precaution for what? You are wondering how to install the new system and have it secure against remote login from the first boot? <einarelen>I'm pretty sure they use SELinux, I have never configured anything about it. Ill check it out <lfam>I know rekado has been doing some work to make Guix work properly with SELinux, but I don't know how to use it <ng0>lfam: I can live with a couple of seconds of login attempts. I know how to secure the system afterwards. <ng0>what I'm not sure about right now is if the passwd entry of root is kept <ng0>didn't take notes on that in the previous installation precedures <ng0>I know that accounts not used are removed from passwd table at init time <ng0>since we can update password usually also manually, I assume that the pre-init and post-init state for root should be the same <lfam>I think that setting passwords in the installer won't affect the installed system <ng0>I'm not in the installer though <ng0>this is a Debian based rescue system <ng0>oh. I just answered my own question <ng0>_rescue system_ ... changes won't affect the state on disk <ng0>grmph. so ssh key it is <ng0>I should've used the sysadmin module <ng0>hm. crap. users are created on first boot <ng0>so if I insert a .ssh folder with a file with content in the now empty folders, are they deleted on first boot? <ng0>my experience is that it just works, but if I lock myself out on first boot, that would be unfortunate <lfam>dieggsy: I updated both root and my user to the latest Git commit, and restarted the guix-daemon. `guix download` is working fine for me <dieggsy>lfam: huh. welp. any ideas on how to debug this then? <lfam>I would strace the guix-daemon. Something like `strace -f -p $PID 2>&1 | tee log` <lfam>See what it's doing when it fails <ng0>which module defines the activation of users after init? <ng0>I'm positive that it is gnu/system/shadow <ng0>ah what the hell. it'a VM server. I can try again if I lock myself out. <lfam>ng0: Look in gnu/build/activation.scm <ng0>apparently /dev/sda1 as I created it on the disk.. doesn't exist anymore. <ng0>i hate the grub console.. <ng0>will it be enough to follow the standard procedure or does GuixSD need some special line passed on th econsole? <ng0>have we ever written somewhere about using grub rescue with GuixSD? <ng0>fun times. live for the thrill. <ng0>extra fun as this is before the first activation <ng0>hm.. reading the grub config file in boot should help <ng0>I think I got it. another semi-useful skill learned. <ng0>LABEL=rootfs used to work <ng0>is there something I must do differently with nvm disks? <ng0>there's a /dev/lightnvm <ng0>I formated /dev/sda in the rescue system before <adfeno>Hm.... OK, so it appears to be different than what I tought. <ng0>I think I'll boot another system and look at what the layout is like <ng0>I'll write an email tomorrow about this setup. <ng0>partition number was wrong <ng0>how hard can it be to get the GuixSD ISO on Hetzner choice of systems you can mount <ng0>did anyone try and contact them about this? <ng0>it's not so difficult with our manual tools, but the iso would've safed a couple of minutes <lfam>Hey dieggsy, any news about that issue? <dieggsy>lfam: i haven't tried debugging just yet. your suggestion was to basically kill running guix-daemon and try strace guix-daemon? or something like that? <lfam>You could also attach to a running guix-daemon and pass it's PID to the -p argument of strace <lfam>No rush or anything like that :) <dieggsy>lfam: damn. how do i even restart guix-daemon actually <lfam>What distro are you using? <dieggsy>lfam: i forget where the executable actually is <lfam>It's in root's profile, easily executed as `/root/.guix-profile/bin/guix-daemon` <lfam>I wonder which types of remote URL fail. You said all of them, but I wonder if it fails with FTP, HTTP, and also HTTPS <pkill9>i like to be extra-pure, and use the /var/guix/profiles/per-user/<user>/guix-profile path whenever referring to something within a guix profile <ng0>so I've done the init again, with /dev/sda2 now as it shouöd've been. grub is on /dev/sda <rekado>you shouldn’t use device nodes like that <ng0>first boot adfterwards is still complaining about the dev/sda2 not being found <lfam>pkill9: Yes, that's really the best path, but for debugging the /root/.guix-profile a less overwhelming to read <ng0>even with using LABEL=rootfs in the grub rescue it wasn't found <ng0>I'll try with labels now <dieggsy>lfam: i think all the urls i've tried so far are https <lfam>dieggsy: I think you forgot to pass the --build-users-group argument when you ran the guix-daemon by hand <lfam>Can you make another trace? :) <dieggsy>lfam: excuse by noobishness any other arguments i should be aware of before i try again <lfam>I would just copy the ExecStart argument from the systemd service file (probably found at /etc/systemd/system/guix-daemon.service) <dieggsy>lfam: that gets me a cannot bind to socket: address already in use. guix-daemon is not running tho <lfam>Are you doing it as root? <lfam>That error message could be improved... <lfam>dieggsy: Based on the versions of the libraries it's using in the trace, it looks like the guix-daemon is kinda old. It's possible that it's old enough that there is some incompatibility between recent Guix clients (what you `guix pull`-ed) and the old guix-daemon. I would update the guix-daemon by doing `guix pull && guix package --upgrade .` as root. No need to pull again if you've pulled as root recently <dieggsy>lfam: i usually guix pull as my user, should i regularly pull as root to? <lfam>It's per-user so, in general, yes <dieggsy>i'm _betting_ that's the problem, lol <lfam>Yeah, it's what I would try, anyways :) <dieggsy>lfam: unrelatedly, is there any way to speed up the compilation step of guix pull? heh <lfam>Sorry, not currently :) It makes us all want faster computers <lfam>We know it's an issue and the Guile developers are slowly but surely improving things <lfam>By the way, if multiple users do `guix pull` based on the same Git commit, then Guix should only need to do the expensive compilation once, reusing the build for the other users. You can specify a commit with `guix pull --commit=...` <rekado>Ludo has a branch that splits up the work that’s done by guix pull, which should make this quite a bit faster. <dieggsy>good to hear it's not just me i suppose :) <lfam>We are all doing some chores once in a while ;) <pkill9>rekado: how does it split it up? So that it gets compiled using multiple CPU cores? <rekado>split up into separate derivations <pkill9>so would you need to specify which parts of teh config you want to compile? <rekado>it will allow some parts of the compilation to be substituted <dieggsy>lfam: your suggestions seemed to do the trick. thanks for the help+info <ng0>same issue with label instead of dev, even after reformating <ng0>well not same, but similar <ng0>now: "waiting for partition 'my-root' to appear" times out <ng0>partitition /dev/sda2 is formated as ext4 with label my-root and listed in the config wit hthis label <rekado>ng0: does it need a special kernel module? <ng0>it's an nvme server at hetzner cloud. I thought we had the nvme module in the initrd <ng0>also internal disk.. I'll just list the loaded modules, see if anything comes up <ng0>we do have nvme in the initrd of the 0.14.0, right? <ng0>I'll continue tomorrow <forester>Hi. Excuse me. I am interesting what GUIX abbreviation means? And if I would install guix on my linuxmint (if it possible to do) then what could it to do? And what is the GuixSD package postfix (.deb or .rpm)? <ng0>yes, Guix can be installed on top of other systems. And the Guix package manager has no postfix for packages like .deb or .rpm per se. There's more, but I'll go to bed now. Others can answer the rest