<taohansen>i guess i'd just like if i didn't have to take a day off to debug my system every time i do an update but then again i am running a 0.14 point release so if i wanted stable hah, well, what was i expecting
<rekado_>so if it’s a regression that’s where Id’ look.
<taohansen>rolled back a generation and back to tear-free nirvana. i'm just going to hold off on updates for a while. Guix devs, please let me know if i can furnish you with some logs or otherwise be helpful.
<thomassgn>so for some reason guix does not provide some files necessary for x86_64 in grub; on a machine with 64bit cpu and the running kernel is 64bit. it can't find /gnu/store/...-grub-2.02/lib/grub/x86_64-efi/ and the file modinfo.sh in it; I can't find it either, I mean it is not there, checked both on the live pen and the system I'm installing to. this is the SD btw.
<taohansen>wigust_: yeah your manifest declarations match mine exactly. i can only guess it's because you're running a different derivation of guix
<wigust_>taohansen: System was build from adedbe95d4896c86c26b2b3ad8408e49f52e9796
<wigust_>taohansen: Maybe you could pull it with "guix pull --commit=adedbe95d4896c86c26b2b3ad8408e49f52e9796" and check if it works for you. I don't know why you don't get the same generated xserver.conf, sorry.
<thomassgn>well, the only thing in /gnu/store/...-grub-2.02/lib/grub/ is i386-pc and grub errors out on guix system init. i.e. bootloader will not install
<wigust_>taohansen: Then you could build a system and check if desired xserver.conf was produced with "guix system build" (could do it as regular user).
<taohansen>wigust_: this is something i'll have to do when i have more time available to me.
<ng0>Wouldn't it be easier to create yasnippet-guix and let our emacs-build-system handle the installation instead of by hand from the source checkout in its etc folder?
<ng0>I mean, I would certainly prefer it to symlinking this from one git into another git (my emacs.d in my config git)
<rekado>ng0: I fail to see how that’s easier than customizing a single variable.
<rekado>there is no code to be installed at all, so the emacs-build-system would not be the right thing to use anyway.
<ng0>I don't know much about yasnippet. I just thought it would simply work, after adding a hook in init.el for a mode. so you are supposed to provide custom directories anyway?
<ng0>When I just need to do "mvn -Dmaven.test.skip=true package" for a package - I am building jdee-server - would it be alright to just use this as a command in a phase? We do not have a maven build system yet
<pkill9>rekado: it still tries to build everything. Do the prebuilt substitutes depend on a particular kernel? `uname -r` outputs 4.4.88. I don't know much about building software, sorry if I'm ignorant :P
<ofosos>I spent the day yak-shaving: some test in pycurl wants libcurl to support http2, so I'm adding that to get virtaal to run
<ofosos>I don't think it's entirely unreasonable to expect curl to support http/2
<rekado>pkill9: by default Guix derives what to build from its sources. Then it asks the substitute servers if they have already built the things. If they haven’t it will proceed to build things from source.
<rekado>this means that availability of packages also depends on *your* version of Guix.
<efraim>951 packages have curl as an input, with a total of 2536 packages that would have to be rebuilt as a result of those 951
<efraim>it seems lookingglass uses ?mmintrin.h in its sources, I'm going to limit it to intel only
<ofosos>Hmm, is there an easy way, how I can teach the python build system to call `make check' for the check phase?
<rekado>ofosos: for a single package just replace the check phase.
<g_bor>rekado: Regarding the issue with java-asm, it is fine by me if we have a java-asm-bootstrap with tests disabled, but it seems that the asm tests for version 5.2 donn't work because we have a dependency we cannot compile with the current jdk.
<g_bor>rekado: I think I will check, if the situation improves if we upgrade java-asm to version 6.
<rekado>is there a reason to keep the old version?
<g_bor>rekado: I don't know 65 packages depend on it. I think if we do this in parallel with changing the default java, it is fine, but I don't know if we should upgrade this on master... I don't think so.
<rekado>yes, this should be done on the jdk update branch
<castilma>how can i add a file and directory to /etc?
<castilma>i tried (simple-service 'my-X-config etc-service-type`(("X11/xorg.conf.d/52-quirk.conf" ,(plain-file "52-quirk" "content")))), but this fails with symlink error: file does not exist.
<castilma>if I remove the leading directorys, it works
<cbaines>castilma, you could tweak the gexp to produce a directory, rather that the file, but an easier way to do this would probably be to use the extra-special-file procedure, which uses the special-files-service-type
<cbaines>The special-files-service-type handles creating the necessary directories, so the above approach you're taking should work
<pkill9>what's the typical way you permantently add a substitute url? would you add it to the guix-daemon startup script?
<pkill9>after installing `glibc-locales` and setting $GUIX_LOCPATH, I no longer get the message from Guix about locales, but I still get this error: `substitute: guile: warning: failed to install locale`
<pkill9>and this error: `substitute: guile: warning: failed to install locale`
<pkill9>oops, sorry, I meant: `substitute: warning: failed to install locale: Invalid argument`
<lfam>pkill9: GUIX_LOCPATH needs to be set in at least two places to avoid those warnings (they are only warnings, btw). It needs to be set in the environment where you run Guix, so something like ~/.bash_profile. It also needs to be set in the environment where you run the guix-daemon. For me, that's in the systemd service file I use to run guix-daemon