IRC channel logs
2018-07-05.log
back to list of logs
<balduin>hello I downloaded the qemu image, which works fine. However, what credentials are used for the login? <happy_gnu[m]>jul 04 20:03:28 chimichanga systemd[16105]: guix-daemon.service: Failed at step EXEC spawning /var/guix/profiles/per-user/root/guix-profile/bi> <happy_gnu[m]>bug#29787: guix-daemon does not work with SELinux enabled <happy_gnu[m]>SELinux/Tutorials/Creating your own policy module file - Gentoo Wiki <divansantana_>hi all. Doing a fresh install after getting a new laptop. Should I custom build an iso, or can I use the 0.14 iso and then apply a workaround to install? <divansantana_>because afaik there is a bug with guix system command not found with the standard iso for the moment. <g_bor[m]>divansantana_: That is strange... I've installed using 0.14 without problems a few days ago... <g_bor[m]>Did you get this problem during installation, or after? <divansantana_>g_bor[m]: ok cool. Ill try now. I just read something about it on the mailist list. <roptat>divansantana_: the issue is after you run guix pull once, you have run it twice the first time <roptat>(that's only for 0.14.0 to current guix though) <divansantana_>so to speed up a new laptop install do I do this. Boot iso on new laptop. Import my pub key from old laptop `guix archive --authorize < /tmp/signing-key.pub` <divansantana_>Then run this guix archive --export -r $(readlink -f /var/guix/profiles/system/profile/) | ssh root@10.4.235.81 guix archive --import <roptat>you need the same guix and the same configuration for that to work <roptat>otherwise, you will send packages that may not be used <roptat>but some of them may still be used, so that will speed things up a bit <roptat>maybe you can run guix publish on your old laptop, add its key, and use it as the first source for substitutes? <divansantana_>roptat: hmm. Wouldn't the destination system import the packages even if they not used. Then it would clean the unused one after a guix gc? <divansantana_>I plan on doing a guix pull on new system after that then a guix system init my.scm which has all the details in. <roptat>divansantana_: ok, then your plan sounds good <roptat>as long as you have enough RAM I guess <divansantana_>I often see my eth connection connect at 10Mbps. Could this be a guixsd thing? <roptat>it's pretty well supported in my experience <divansantana_>could be the hardware. Will see if happens on new one. An unplug replug fixes it sometimes. <roptat>I've seen that happen with old cables <divansantana_>roptat: so my idea failed. No space on usb boot drive. Whoops. lol <nckx>My r8169 (’RTL8101/2/6E PCI Express Fast Ethernet controller’) prints missing firmware errors under linux-libre but still shows up as an interface. I've never actually plugged a cable into this laptop... <nckx>If it's ‘often’ and not ‘always’ I agree that it's more likely to be a bad cable. <nckx>(Then again, some hardware does strange unpredictable things when deprived of its secret sausage.) <nckx>ACTION groans. guix: system: command not found, but from ./pre-inst-env. What nckx do? <rekado>nckx: when using pre-inst-env make sure that guile-sqlite3 is available in the current environment. <rekado>nckx: pre-inst-env assumes that all runtime dependencies of Guix are available in the current environment; it does not set up that environment. <rekado>you can avoid problems by using pre-inst-env inside an environment created with “guix environment guix” <jlicht>the guile-sqlite3 thing really seems to have bothered quite a lot of people <nckx>Oh. I've literally never done that in years, but I guess I was just being lucky. <rekado>jlicht: it should not bother people who use “guix pull” <rekado>people using “pre-inst-env” (we assumed) would be able to check the dependency updates. <rekado>but yeah, this prompted us to conclude that the project should have a low-volume announce mailing list. <rekado>we can’t expect all developers (new and old) to read all emails on guix-devel. <jlicht>using guix from a git checkout works too well, so people who don't know what they are doing (e.g. me) just assume it always works once you have it set up the first time ;) <rekado>it actually never fully worked this way, which is something I had to remind myself of recently :) <rekado>e.g. gnutls or guile-json are also needed at runtime and “pre-inst-env” didn’t set those up either. <nckx>rekado: Good point. I probably set those up years ago and forgot that I had. <jonsger>jlicht: I hope guix doesnt add new dependcies as fast as in the last time :P <rekado>ACTION does not know how to dance <jlicht>jonsger: there is still one I would like to add in the near future ;) <nckx>I'd like to carefully point out that I'm pretty sure the whole saga looked *horrible* from the outside and to (potential) new users, even though no one did anything wrong. <jonsger>jlicht: I usually have to package them for opensuse because Guile is not widely used... <rekado>the string “beta” is not wide enough to reliably hide things like this behind it. <nckx>Ehm. Turns out I already ‘guix package -i guile-sqlite3’ yesterday... <rekado>do you also have “guile” itself in your profile to benefit from the automatic search path magic? <nckx>‘info guix’ gives me an English manual with French links (‘*note Invoquer guix system::’) <nckx>rekado: Probably not, then. <rekado>nckx: I think so. roptat probably knows more about this. <nckx>Now ‘~/guix/pre-inst-env guix environment --ad-hoc guile guile-sqlite3 -- ~/guix/pre-inst-env guix system vm /etc/guix/system.scm’ does... nothing. No output, save 2 deprecation warnings. <nckx>Usually I see a stupid typo in the command as soon as I paste it. Hm. Still waiting for that superpower to kick in. <nckx>Regardless, silence is never the right choice. <snape>nckx: shouldn't you use 'guix environment guix' to have all guix dependencies? <rekado>nckx: but I also encountered silence when I did not expect it (turned out that a use-modules clause was missing); it’s possible that’s due to a recent regression :-/ <nckx>snape: Again, I've never had to before, but who knows at this point. I *bootstrap and build* my git-guix in an environment, but I've never needed one to *run* it. <nckx>ACTION is trying that now. Collision warnings scream by. <nckx>Nope. Same (non-)result ☹ <rekado>nckx: could you maybe share the configuration file? <rekado>then I could try to reproduce it. <nckx>(The ‘Again’ above was not meant to sound annoyed. I am, but not at anyone here.) <snape>nckx: so you installed guile-sqlite3? Can you check it's in your GUILE_LOAD_PATH? <nckx>rekado: I'll share it if there's no other way, but ‘~/guix/pre-inst-env guix environment guix --ad-hoc guile guile-sqlite3 -- ~/guix/pre-inst-env guix system vm ./gnu/system/examples/bare-bones.tmpl’ does the same thing. <nckx>λ echo $GUILE_LOAD_PATH → /run/current-system/profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2 <rekado>okay, I’ll try to reproduce this now <ng0>is someone working on a fix for gnucash's testsuite? <snape>nckx: you need to ls $GUILE_LOAD_PATH/sqlite3.scm <nckx>Inside the env: ‘guix env 3c1… guile-sqlite3 &c λ echo $GUILE_LOAD_PATH → /gnu/store/3c1l7mkrlcscwijx76gkkj604z6kqly8-profile/share/guile/site/2.2:/home/nckx/guix:/home/nckx/guix:/run/current-system/profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2’ <rekado>ng0: is there a bug report about it? <roptat>re info bug, I don't know how it happens <rekado>ng0: it’s better to have one and discuss things there. <snape>nckx: guile -c "(use-modules (sqlite3))" <nckx>^ Everything before λ is just my fancy-butt $PS1. <ng0>then it seems like very often people do not report bugs. I can report bugs, but currently I do not have the capacity to fix them. <nckx>I'm expecting rekado to come back saying ‘works for me’, TBH, but not looking forward to it ☹ <rekado>ng0: yes, often people don’t report bugs, but it is not a good position to be in. <ng0>I think today I have time to report a couple of open bugs I know about <rekado>ng0: by asking about a bug on IRC you only reach very few people and things are easily forgotten; it’s best to have a bug report where the work is tracked. <rekado>nckx: I’ll try my best not to say “works for me” :) <ng0>I know you do this for the public record, because I know that you know that I'm not here since just yesterday. <rekado>nckx: can you tell me which commit you’re on just to be sure? <nckx>rekado: ac3accd44b8dc1e0be0cc484d180d6ae8a1ac97e <rekado>nckx: I’ve been meaning to ask you about your updates to R packages. Are you using them or do you update these R packages ad-hoc? <snape>nckx: does your .bashrc change your environment? (export...) If it does, that's the kind of thing that would break 'guix environment' <rekado>snape, nckx: or a seemingly innocuous “source” <rekado>nckx: I need to build linux first; there does not seem to be a substitute for it. <nckx>ACTION ran guix environment guix -- sh -c "make -j clean; ./bootstrap && ./configure --sysconfdir=/etc --localstatedir=/var && make -j`nproc`" <nckx>Now I get: failed to create path for auto-compiled file "./gnu/system/examples/bare-bones.tmpl" <rekado>./pre-inst-env guix environment --pure guix --ad-hoc coreutils <nckx>Yeah, maybe I should --pure too. <rekado>it’s building linux now, so I assume that this is more than the command did for you <snape>--pure won't help against .bashrc mistakes, whereas '-C' will <nckx>Oh look now my manual's French but I don't even care. <nckx>ACTION spawne le conteneur. <nckx>rekado: This is also my substitute server, so it should have ‘substitutes’ in the store for ‘everything’. <wigust->Will the manual in French be reversed to English before new release? :-) <roptat>I'd like to understand how it does that <roptat>the French manual should be guix.fr <roptat>the English manual is still in "info '(guix)'" somehow <roptat>but I'd like it fixed by the next release... <nckx>roptat: info know but just don't care: λ info -w guix → /home/nckx/.config/guix/current/share/info/guix.fr.info <nckx>Does it... *shudders* does it strip everything to the right of the first ‘.’? <roptat>maybe, or maybe it has something to do with the translation itself (maybe a node is called guix in both cases?) <roptat>ludo talked about creating a separate dir.fr file for French translations <nckx>Oh. guix environnement -C fou... → In procedure public-lookup: Module named (system repl debug) does not exist <nckx>That's just my last command above with -C added. I've never used containers before. Am I doing it wrong? <rekado>does this work for you? ./pre-inst-env guix environment -C guix --ad-hoc coreutils -- sh -c "id" <nckx>rekado: Yes: uid=0(nckx) gid=0 groups=0,65534 <nckx>Or at least I assume that's ‘work’. <rekado>yes, that’s equivalent to “work” ;) <rekado>to be sure that nothing is horribly wrong with the environment, could you please check the output of “env” in the container? <rekado>(just replace "id" with "env" in the above command) <rekado>GUILE_LOAD_COMPILED_PATH and GUILE_LOAD_PATH should only refer to /gnu/store/…-profile <nckx>Unless you mean GUILE_LOAD_COMPILED_PATH must be a singleton, which I doubt you mean. <rekado>nckx: even better, it makes all directories (except parts of /gnu/store and the current working directory disappear). <nckx>rekado: Great! That's what I assumed. <rekado>you can explore the container environment by leaving off the “--” part and poke around in /home/nckx <nckx>rekado: Just a mo'. I'm running the command that I think caused the ‘repl debug’ error to check. <roptat>I think I understand why "info guix" gives the French manual <roptat>that's because a node in @direntry is called Guix in both French and English manuals, and info somehow picks the French one first <roptat>same with "info 'guix environment'" for instance <rekado>can we just rename it to “Guix (French)” or similar? <roptat>maybe, I don't know how to test it? <nckx>Aargh, or maybe the opposite, I can't tell what's good or bad news anymore. <nckx>I'm quite sure that ‘guix environment -C --pure guix --ad-hoc coreutils -- sh -c "make -j clean; ./bootstrap && ./configure --sysconfdir=/etc --localstatedir=/var && make -j`nproc`"’ failed with the ‘repl debug’ error. Now it doesn't. <rekado>roptat: oh, I see. *Any* direntry that is named the same in both files would randomly be mapped to either one of the manuals? <rekado>nckx: you know, it’s possible that this is due to the Guile thread safety problem. <rekado>the environment gives us Guile 2.2.3, which does *not* have the recent fixes. <rekado>(they are in 2.2.4 only, which is used by “guix pull” automatically) <rekado>seeing this odd repl debug message *sometimes* is one of the symptoms of this bug in Guile < 2.2.4. <rekado>it’s worse when using more cores. <nckx>rekado: I have 4, but maybe I got lucky. OK, so: unrelated bug. And the command above completed successfully, so now I have a fresh Guix. OK. Where was I... <rekado>the question is if “guix system vm” also hangs without output in the pure/container environment. <nckx>But I'm starting to see dancing ‘-- ~/guix/pre-inst-envs’ when I close my eyes so the right magic invocation might be missing from that list. <nckx>ACTION is packing for a month-long cycling trip at the same time just to ensure that both endeavours have the maximum chance of something going wrong. <rekado>I rarely ever use the “--” thing; can you also reproduce these errors when running these commands interactively in a containerized shell session? <nckx>rekado: guix environment -C --pure guix --ad-hoc coreutils <RET> ~/guix/pre-inst-env guix system vm ./gnu/system/examples/bare-bones.tmpl → the same result, yes. <rekado>I’m slower, but I hope I’ll be able to reproduce this soon. <nckx>Sorry. I'm not usually this clueless but, like you, I have literally nothing to latch onto. <nckx>git-guix was always the safe choice ☹ <rekado>okay, looks like you need to also mount /var and /gnu in the container to do useful things <rekado>./pre-inst-env guix environment -C guix --share=/var=/var --share=/gnu=/gnu --ad-hoc coreutils <rekado>with that I can run ./pre-inst-env guix build hello successfully <rekado>./pre-inst-env guix system vm ./gnu/system/examples/bare-bones.tmpl does things, but it’s waiting for some other builds on my machine to be completed. <nckx>guix environment: error: mount: mount "/gnu" on "/tmp/guix-directory.Z3PRz5//gnu": Invalid argument <rekado>is the command the same as mine? <nckx> /tmp is not a tmpfs or anything. <rekado>In my case: tmpfs on /tmp type tmpfs (rw,nosuid,nodev) <nckx>In mine: /dev/md0 on / type btrfs (rw,relatime,compress=zlib:3,space_cache,subvolid=5,subvol=/) <rekado>ACTION will be right back in a few mins <nckx>ACTION unmounts /tmp again in case anything would like to read its tempfiles in the meantime. <nckx>Thanks for all your help, rekado. <nckx>Whenever I grumble that ‘most non-masochists would have given up 3 steps ago and rightly so’, I remember that they would also find a bunch of friendly Guixers ready to help. <nckx>‘mount: … Invalid argument’ is usually a hint to look in dmesg, but my logs are barren. <nckx>I don't know if you have scrollback, but thanks for your work on the (possible) GC bug. <civodul>i don't have scrollback, more bugs reported or just congratulations? :-) <jlicht> cachix seems really exciting! Is it also available to self-host or something similar though? <nckx>jlicht: +1, with the obvious ‘so how do you handle transitive trust, or just trust for that matter’ questions. <jlicht>using cachix would already be nice for my own subtitutes; I have multiple machines and a pressing lack of time and means to set up an always-online cache of substitutes ;-) <civodul>if they're on the same LAN they could run 'guix publish' <jlicht>so in that sense, for personal use it would already make sense (and I make the possibly unwarranted assumption that you trust your own builds) <nckx>Hehe. I was just typing ‘plus I'd rather see Guix do its own decentralised coolness, but as usual, that's a way out and cachix exists now.’ <jlicht>How hard would it be to make something like it? It seems a bit like it would take most of `guix publish' + something that accepts binaries (so part of guix copy?) <jlicht>too bad, I'd rather have a paid SaaS project + the ability to self host when required, than the model where free software projects are allowed to use some proprietary service for free <nckx>jlicht: For personal use, I'm already perfectly happy with my home servers cum build farm running guix publish. <civodul>nckx: there's no license, so it's de-facto proprietary, but hopefully it's an "omission" <nckx>Once offloading works, I should be content. <nckx>civodul: What is, though? Did you find a server-side repository? <nckx>There's no other meaningful repository under that name. <nckx>civodul: Looks like a machine-readable API spec to me, but I am not a Haskelleer. <jlicht>+1 to what nckx said; that, or writing web servers in haskell can be done in very very few lines of code :) <jlicht>heh, I was just writing up a similar message there <nckx>Mine was probably sloppy and incomplete :-) Glad someone else is lurking there since I'm on and off right now. <nckx>civodul: Hehe. Exactly why I added some disclaimers to my statement. <civodul>imagine when we'll all be pushing and pulling texlive to cachix! <jlicht>I get a pavlovian craving for coffee when I read "<guix-store-hash>-texlive" somewhere <jlicht>civodul: I imagine the "In the future there might be some limits" will come sooner than expected if we do that XD <rekado>I could need some help in getting rid of texlive in inputs. <ng0>ACTION has to try again if eduroam cuts off texlive <ng0>apparently I've build it yesterday <ng0>now I need to reproduce it some day.. would be too bad if it's really eduroam or just the lower floors in university.. the speed in that network is really good <jlicht>rekado: What would you need help with? <rekado>hmm, “help” sounds like I would do things and others assist, but what I actually meant is: I would be happy if others could pick any of the few remaining packages that use the big texlive package and try to figure out how to make them build with a texlive-union instead. <rekado>I made some progress with python-numpy, for example, but ultimately failed because texlive-union doesn’t quite do the right thing in terms of configuration. <rekado>once the problems with texlive-union are fixed we could be confident that a texlive profile hook would work. <rekado>(adding a profile hook is the last step towards removing the need for the big texlive package) <rekado>jlicht: if you would like to take a look at that I could gladly share some stashed away changes. <jlicht>rekado: I might have some lost moments this weekend to have look at it <ng0>ah, the texlive receiving graft from build server error is reproducible in my home network. <ng0>so I just won't offload it <nckx>civodul: My mail server's DC has been having network trouble and I just saw your own ‘color=auto’ fix. I pushed a very similar patch to master last night. But I can't find yours... <rekado>happy_gnu[m]: could you give this a try? <nckx>Oh. It's not on master. Hm. <civodul>efraim: i'll be using your OverDrive quite intensely over the next couple of days, just so you know ;-) <happy_gnu[m]>The problem is that systemd reports that it failed to load it. But I know is related to selinux, because if I set it to permissive Guix starts properly, and Guix also runs when I run the daemon manually as root <happy_gnu[m]>I was able to do guix pull and install locales, emacs and racket. They also keep working after Selinux is changed back to restrictive and computer is rebooted <happy_gnu[m]>So as a work around I was thinking on just disable selinux temporarily or running the daemon manually <rekado>happy_gnu[m]: have you been able to get more info from sealert? <rekado>in permissive mode SELinux reports on what accesses were blocked. <rekado>did you load the policy that we provide with Guix? <happy_gnu[m]>rekado: awesome! I didn't know that. Give me an hour and I'll be back to send you the logs <rekado>the policy should be sufficient to start the daemon, but it is known that it doesn’t cover the case of running a shell wrapper around Guix. <rekado>(because that has a different name and needs to be made explicit in the rule) <rekado>the actual policy file is generated when you compile Guix. <rekado>actually, doing “./bootstrap && ./configure …” would be sufficient. <rekado>files ending on “.in” are “input” files <rekado>I don’t think the policy file is installed in the binary installation, but I haven’t checked this yet <efraim>civodul: no problem, let me know if it goes down, I don't always notice if the light is off <nckx>rekado: That file doesn't look like it refers to any specific store paths, correct? (Just the store directory.) <rekado>I explained the tradeoff in the email that contained the patch. <nckx>That's before my buffer I'm afraid (DC, network, blah blah). <nckx>So happy_gnu[m] should be able to just download and use that file? Rad. <rekado>yes. We should distribute it as part of the binary installation / what “guix pull” provides. <civodul>efraim: sure! BTW, did you try to "guix build -s armhf-linux" on it? <civodul>ACTION pushes updated NEWS to version-0.15.0 <civodul>please speak up if you think something important is missing! <rekado>happy_gnu[m]: can you share the relevant parts of the sealert output? <rekado>ACTION goes afk for a few hours but will check the logs later <happy_gnu[m]>type=AVC msg=audit(1530804140.367:228): avc: denied { read } for pid=7540 comm="(x-daemon)" name="guix-profile" dev="dm-1" ino=1845836 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=lnk_file permissive=0 <happy_gnu[m]>audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=guix-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' <happy_gnu[m]>guix-daemon.service: Failed to execute command: Permission denied <happy_gnu[m]>systemd[7540]: guix-daemon.service: Failed at step EXEC spawning /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon: Permission denied <happy_gnu[m]>systemd[1]: guix-daemon.service: Main process exited, code=exited, status=203/EXEC <happy_gnu[m]>systemd[1]: guix-daemon.service: Failed with result 'exit-code'. <janneke>on version-0.15.0, i did: ./pre-inst-env guix system --system=i686-linux disk-image --file-system-type=iso9660 gnu/system/install.scm <janneke>when trying to guix system init that, linux gets rebuilt <janneke>that proved too much for my poor old thinkpad <janneke>should i "just" wait...or do you have other tips? <janneke>is there an easy way to trigger the exact rebuild on another, substitutes machine? <civodul>efraim: the OverDrive seems to be off, could you take a look? :-) <rekado>janneke: I think it’s possible to “guix copy” the derivation to the other machine and run “guix build /path/to/derivation”. <rekado>happy_gnu[m]: the message says that there is no way to get from the context init_t to the context user_tmp_t, which is the context for a link file. <rekado>that’s because /var/guix/profile/per-user/root/guix-profile/bin/guix-daemon is used, which is a link. <rekado>init_t is the context in which system services are running. <rekado>i.e. the process spawned by guix-daemon.service <rekado>we label only individual profile directories, not their children <rekado> (filecon "/var/guix/profiles(/.*)?" any (system_u object_r guix_profiles_t (low low))) <rekado>we allow init_t processes to transition to guix_daemon_t, and a process in guix_daemon_t can access a bunch of files with certain types, but user_tmp_t is not part of the set (and it shouldn’t). <rekado>the solution, I think, is to add a file label rule to give *all* files under /var/guix/profiles the type “guix_profiles_t”. <rekado>happy_gnu[m]: you could try a command to relabel all files in /var/guix/profiles/.* <rekado>I think you can do this as root: chcon -R -t guix_profiles_t /var/guix/profiles <rekado>this changes the type of all files under /var/guix/profiles to guix_profiles_t <rekado>(this is not permanent and can be reset with restorecon) <rekado>after running this command and restarting the daemon you should no longer get this error. <rekado>could you please give this a try? <efraim>civodul: just saw your message, looks like its up afterall, building gcc <civodul>efraim: i get "Connection refused"; could it be that sshd died? <efraim>Looks like it should be up, but it also looks like the reverse ssh session resets about every 5 minutes <divansantana_>doing a fresh install. If the uefi grub part of the install fails but the rest works, how can I go about redoing the grub install without redoing the full install? <rekado>(is guix system init idempotent again?) <vagrantc>there was a recent commit claiming to fix init idempotency <rekado>divansantana: in that case you should be able to run guix system init again. It would not have to download the same things again. <divansantana_>rekado: ok. I did try that but I still don't see my guixsd install in uefi boot options. Trying a fresh install with it correctly mounted to /mnt/boot/efi first time round <civodul>bad news is that aarch64 substitutes have vanished from berlin.guixsd.org, presumably because they were not used <civodul>my backup idea was to build everything over qemu, but that's going to be just too much <rekado>happy_gnu[m]: no rush, I’ll go offline now. I hope this will get you farther!