IRC channel logs


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]>I am having trouble with Guix in top of fedora
<happy_gnu[m]>It is working
<happy_gnu[m]>but systemd is not running it
<happy_gnu[m]>i have to start it manually
<happy_gnu[m]>Anyone had a similar problem before?
<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]>guix-profile/bin/guix-daemon: Permission denied
<happy_gnu[m]>seems like SELinux is stopping Guix
<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
<happy_gnu[m]>semodule -i "$module".cil
<happy_gnu[m]>it didn't work :/
<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]>Hello guix!
<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.
<divansantana_>let me see and revert back.
<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_>roptat: cool
<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/`
<divansantana_>Then run this guix archive --export -r $(readlink -f /var/guix/profiles/system/profile/) | ssh root@ guix archive --import
<divansantana_>then do the install on the new system?
<divansantana_>Hopefully. Would be cool and speed things up a lot.
<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
<jlicht>hello folks
<roptat>as long as you have enough RAM I guess
<divansantana_>roptat: that I do. 16G.
<roptat>cool :)
<divansantana_>I often see my eth connection connect at 10Mbps. Could this be a guixsd thing?
<divansantana_>We don't need nonfree drivers for ethernet do we?
<roptat>I don't think so
<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.
<divansantana_>makes sense
<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.
<rekado> |
<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.
<rekado>nckx: I agree.
<nckx>Phew :-)
<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.
<nckx>^ re info: known bug?
<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: hmm, that’s odd.
<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>sure :)
<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’
<snape>well not exactly
<snape>but you see what I mean :)
<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>snape: Gives no error.
<snape>nckx: :/ so you have it
<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.
<ng0>I know.
<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: thanks!
<rekado>ACTION runs “make” …
<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
<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>I did this:
<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
<nckx>ACTION --pures.
<snape>--pure won't help against .bashrc mistakes, whereas '-C' will
<nckx>ACTION ^Cs.
<nckx>Oh look now my manual's French but I don't even care.
<nckx>ACTION spawne le conteneur.
<snape>ACTION laughs
<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
<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/
<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 file for French translations
<roptat>that should solve the issue
<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>I don’t think so.
<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
<rekado>okay, good.
<nckx>Or at least I assume that's ‘work’.
<rekado>yes, that’s equivalent to “work” ;)
<nckx>Conts r weird.
<rekado>ACTION nods
<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>I think so:
<nckx>Unless you mean GUILE_LOAD_COMPILED_PATH must be a singleton, which I doubt you mean.
<rekado>no, this is excellent
<rekado>nckx: even better, it makes all directories (except parts of /gnu/store and the current working directory disappear).
<rekado>*) 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
<rekado>“exit” to leave it.
<nckx>rekado: Just a mo'. I'm running the command that I think caused the ‘repl debug’ error to check.
<rekado>awesome, thank you
<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>system vm
<rekado>the question is if “guix system vm” also hangs without output in the pure/container environment.
<rekado>sorry, the internet changed me.
<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?
<rekado>ACTION stumbles in the dark
<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>okay, thanks
<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 ☹
<nckx>I've been spoilt.
<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>I’ll try the vm command now
<nckx>So'll I.
<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.
<nckx>Yes, copy-pasted.
<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=/)
<nckx>Let's mount /tmp.
<rekado>ACTION will be right back in a few mins
<nckx>...same thing. Wat.
<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>ACTION cheers up a bit.
<civodul>Hello Guix!
<jlicht>hey civodul
<nckx>\\o civodul
<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? :-)
<civodul>i take congratulations ;-)
<nckx>^ :-)
<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.
<civodul>and centralization issues, too
<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.’
<nckx>* -a
<civodul>yup :-)
<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?)
<nckx>jlicht: I don't think it's ‘open source’: Or if it is, it's not very... open about it.
<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> is just an API client.
<nckx>There's no other meaningful repository under that name.
<civodul>nckx: is the server side, i think
<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 :)
<nckx>I've asked in #cachix.
<jlicht>heh, I was just writing up a similar message there
<civodul>don't underestimate Haskell ;-)
<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>la la la
<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
<happy_gnu[m]>I am having trouble to start guix at boot
<happy_gnu[m]>because of SELinux
<happy_gnu[m]>ACTION sent a long message: < >
<ng0>ah, the texlive receiving graft from build server error is reproducible in my home network.
<ng0>so I just won't offload it
<rekado>happy_gnu[m]: as I wrote here we probably need to change the policy:
<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.
<happy_gnu[m]>rekado: hi
<happy_gnu[m]>thanks for helping me
<happy_gnu[m]>is this the one I should try?
<happy_gnu[m]>Re: [PATCH] Add SELinux policy for guix-daemon.
<rekado>sorry, I don’t understand.
<rekado>what is the error you get?
<happy_gnu[m]>well I just install it
<happy_gnu[m]>on fedora 28
<civodul>nckx: mine is on version-0.15.0
<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>we can add those to the policy.
<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
<happy_gnu[m]>I tried but
<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)
<happy_gnu[m]>there is no guix-daemon.cil
<rekado>that’s the *template*
<rekado>the actual policy file is generated when you compile Guix.
<rekado>actually, doing “./bootstrap && ./configure …” would be sufficient.
<happy_gnu[m]>so I tried doing semodule -i
<happy_gnu[m]>but it gave me a few errors
<rekado>no, that won’t work
<rekado>files ending on “.in” are “input” files
<happy_gnu[m]>rekado: but I used the binary
<rekado>they need to be processed first
<rekado>I don’t think the policy file is installed in the binary installation, but I haven’t checked this yet
<happy_gnu[m]>Should I compile guix then?
<happy_gnu[m]>then later I'll try to compile guix
<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.)
<nckx> has my copy.
<rekado>that’s right.
<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.
<nckx>ACTION → out o/
<civodul>efraim: sure! BTW, did you try to "guix build -s armhf-linux" on it?
<happy_gnu[m]>nckx: thanks!
<happy_gnu[m]>i had to go out but I'll try it in 10 minutes!
<civodul>ACTION pushes updated NEWS to version-0.15.0
<civodul>please speak up if you think something important is missing!
<happy_gnu[m]>rekado: nckx seems like it didn't work :(
<happy_gnu[m]>selinux is awful :/
<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>the alternative is offloading.
<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>let me check the policy
<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>civodul: I can check
<efraim>Looks like it should be up, but it also looks like the reverse ssh session resets about every 5 minutes
<efraim>I also realized I ssh'd into it
<civodul>efraim: still the same here :-/
<civodul>oh wait
<civodul>it works now, thanks efraim!
<civodul>do you know what happened
<divansantana_>hi all
<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.
<civodul>efraim: it's down 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
<divansantana_>hopefully it works now.
<divansantana_>rekado: good to know, thanks.
<civodul>bad news is that aarch64 substitutes have vanished from, 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
<happy_gnu[m]>> could you please give this a try?
<rekado>happy_gnu[m]: no rush, I’ll go offline now. I hope this will get you farther!
<rekado>ACTION –> zzzZ