<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.
<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>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>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
<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>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.