*Digit wishes he was smarter, and/or guix total knowledge and understanding was installable in pill form, and/or he had the joyous graceful unimpeded love of learning it... and/or whatever other way to become one with the guix, rather than just an admiring bystander. ... maybe someone will "ubuntu-fy" it, n Digit wont need to know or be smart.
<reepca>hm, odd that the live system won't boot. There should be ways of recovering the system in the event of the root password being forgotten. Looking online it looks like the usual advice is to modify the grub boot options when booting so that it just starts a root shell, then use passwd to reset the password from there.
<quiliro>by adding 'single' at the end of the kehnel line, <<<<right<<<
<quiliro>and this would be a great opportunity to fix this problem
<quiliro>it is probably the same one on both machines
***Digitteknohippie is now known as Digit
<nckx>quiliro: There are several possible causes; one ‘interesting’ one is if both drives happen to contain the same unicode.pf2 file (see /boot/grub/grub.cfg for how this file is in fact used to determine the root drive!). There are many other ways to confuse GRUB.
<nckx>It's happened to me before even loading normal.mod (and hence grub.cfg), which means something can go wrong even before any Guix code kicks in.
*oldosfan manages to break guile installation somehow
<roptat>idnull, look for anything that uses the trivial-build-system then
<truby>I'm very close to having a fix for clang not finding C++ standard library headers, now the last header it can't find is <linux/errno.h>.. any idea where this header lives?
<truby>I assume I'm just missing a propagated-inputs dependency (so that this header actually gets put in the cpath)?
<mbakke>truby: that file comes from "linux-libre-headers", which should already be available (propagated from glibc)
<efraim>civodul: in %bootstrap-coreutils&co, the 'let' in the snippet, that's not actually needed, right? it seems to me it could just be 'begin'
<truby>interesting, if I ls the glibc include directory there's no linux folder in there
<truby>nor in the include directory for my profile
<mbakke>truby: there should be an entry for linux-libre-headers on CPATH or C_INCLUDE_PATH
<truby>those both seem to just be set to the profile include path
<mbakke>right, I guess you'll have to explicitly add glibc or linux-libre-headers to the profile to get it in that case
<truby>perhaps clang needs a dependency on gcc-toolchain as a whole, rather than just gcc
<truby>because on linux clang does assume you have a fully functioning gcc toolchain + as + ld + libstdc++ etc
<truby>(at least, by default. You can build a clang that doesn't have a dependency on any of these but it's usually not what you want, and almost definitely not what you'd want a clang package to do in this case)
<mbakke>truby: it would be nice to have a "make-clang-toolchain" procedure that takes care of all that stuff :-)
<truby>yeah, I was going to look at that next :) because I'd like to write a procedure where you can select each combination of things clang supports (i.e. which stdlib you want, which compiler runtime you want, which linker you want etc etc)
<truby>but first, I want to just get it finding the headers correctly in the configuration the clang package already builds!
<quiliro>Why would Guix System use GrUB entries from the hard disk when booting from USB? I have another machine right now with the same problem. When you boot from an older generation, existing user passwords do not work any more.
<truby>mbakke: I think the only way of making this work is to turn clang-from-llvm into make-clang-toolchain, because you need to patch the clang sources based on which toolchain options are being passed to you
<truby>otherwise it can't find the standard library headers (either for libstdc++ or libc++)
<truby>in the case of libstdc++ it looks for them in /path/to/crt0/../include/c++, and in the case of libc++ it looks for them in /path/to/clang/../include/c++
<truby>so we need to patch it to look for them in the actual path to the gcc or libc++ version you've asked for
<truby>(it already did the same so it can find libc correctly before I touched it)
<mbakke>truby: for libcxx, would it make sense to create a union of clang and libc++ in "make-clang-toolchain"? then "../include/c++" should work.
<truby>it uses the resolved path to clang, i.e. after hopping through every symlink
<truby>so unions don't help I think because they're symlink based right?
<mbakke>truby: unions are indeed based on symlinks
<truby>so I think there's no (easy?) way around just shoving in the direct path into the relevant place in clang. I mean, it's a pretty safe change
<mbakke>truby: patching in absolute references is fairly commonplace in Guix :-)
<truby>I noticed :-). I haven't done the patch for libc++ yet but it'll be very similar to the one I've added for libstdc++.
<truby>Before I start messing around with trying to write make-clang-toolchain should I put my current patch that just makes clang work the way it is expected to somewhere for review? it's pretty uncontroversial (I hope!) so might be better to get that added separately before I start rearranging the world heh
<truby>am I right in thinking the default gcc for building packages is 5.5? or am I getting the wrong compiler from somewhere...
<iv-so>truby: you can override gcc toolchain through native inputs
<truby>ok, it's not super important for llvm atm, llvm 9 released this week does still build with gcc 5, but this will be the last release that does :-) is there a reason a newer gcc isn't used by default? just out of curiosity
<idnull>also, today (while I was trying to get New Moon working), crazy idea came to my mind: one can extract git tags and create new packages from those tags (I wanted it because there is no sqlite >=3.27 and Moon needs it else you can only have bundled one)
<idnull>also I'm too lazy to manually edit package version and sha :-)
<idnull>maybe I'm missing unstable repo somwhere. f.e. I need gcc-9.2 in order to test gdc and program in D
<quiliro>it was caused by booting with an older grub entry
<refpga`>Hello, I'm trying to set up a keyboard layout using the following snippet: http://ix.io/1X4l but I get the following error: 102:55: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "mac" model: #f options: ("ctrl:swapcaps")>
<Parra>hello guys, I have one question, is it possible to install guix cmake-build-system dependencies before I install a package written by me that uses it?
<Parra>I've think about installing a dummy package before, but.. not sure if it's the best way of doing it
<lprndn>Parra: what do you mean by installing cmake-build-system?
<idnull>can anyone tell me why if i press ctrl+<- i see ;5D how can I fix this?
<Parra>lprndn: when I install my package from file, in a fresh guix install, it takes so long because it needs to download all build dependencies like cmake
<Parra>I want to know what dependencies are, in order to install them before for caching
<Parra>I'm using cmake-build-system but I don't know how to install its dependencies
<lprndn>Parra: Sorry if i'm beside the point but the store already act as a cache as long as you don't `guix gc`. If guix downloads cmake it's only because cmake package itself changed since the last time.
<sneek>rain, nckx says: It's always helpful to include the actual error message in addition to your code: after downloading & building your package, Guix said: Wrong number of arguments to #<procedure assoc-ref (_ _)>
<sneek>rain, nckx says: which 1) is suspiciously relevant for a Scheme error message, what's going on!? and 2) immediately made the obviously wrong ‘(assoc-ref inputs "clang" "/lib"))’ obvious.
<sneek>rain, nckx says: Then (after much crunching) I get ‘mkdir: cannot create directory ‘/lib’: Permission denied’, which is a new & exciting but unrelated error 🙂
<rain>nckx, re:QtCreator, I figured it out in the end, QtCreator installs cleanly now. I'm still not totally used to reading Scheme and not having a type checker, which is how I missed the assoc-ref issue.
<lprndn>Parra: I would rather say that as long as you *don't* guix pull it actually shouldn't download anything twice. Do you workd from guix sources?
<refpga>Everytime I do a system reconfigure with or without guix pull, it downloads and compiles icecat. I don't know why.
<refpga>I mean, I did put it in the packages list...
<davidl>probably related to bug#37506 I am also having the issue that when having a (branch "master") in the .guix-channel for a dependency channel I get some error stacktrace when guix pulling. Im sorry that Im not able to provide more details on how to reproduce it at the moment.