<Petter>Nevermind, just figured out (assoc-ref inputs) 8-)
<buenouanq>if I rollback in grub to the first or an early generation, what happens to all the files and things I've created since? Like, say in a later gen I added a user, what happens to their home dir?
<Petter>sneek: later tell lfam I've been playing with a super simple test case in Go. One program (theproject) with two libraries (liba and libb). It works! :) Let me know what you think, http://paste.lisp.org/display/333469
<sneek>lfam, Petter says: I've been playing with a super simple test case in Go. One program (theproject) with two libraries (liba and libb). It works! :) Let me know what you think, http://paste.lisp.org/display/333469
<Petter>If you're unable to recuperate, I'd suggest starting with the template again.
<lfam>buenouanq: You can do things in other directories. Are you thinking about anything in particular?
<lfam>One thing you must never do is modify files in /gnu/store. They are supposed to be immutable. /gnu/store should only be written to by the guix-daemon
<lfam>Certain files in /etc are written to by GuixSD, and you should probably let GuixSD manage them for you. /etc/passwd is one example. You should only do user management via the OS configuration file and `guix system reconfigure`
<bavier1>another law: A sufficiently complicated cmake build system will contain a poorly-specified and incomplete implementation of Guix
<rekado>I think wingo brought this up many moons ago, but I've been wondering the same: why is it that our applications search a lot of paths for libraries (as evidenced by strace) when they could know the exact location of the library files?
<wingo>we should be building paths in the store for each setting of an environment variable
<davidl>if I logout from the gnome-session and relogin with the user in question I can use it.
<jmd>I suppose that's becuase the profile is different. Is the $HOME correct?
<thomasd>How are the requisites in `guix gc --requisites' computed? I have some packages in 'inputs which are not needed at build time, only at run-time, and they don't show up in the list of requisites
<civodul>thomasd: at the end of a build, the daemon scans the resulting directory(ies) for references to other store items and records that as the set of "references" for that store item
<thomasd>so it uses actual RUNPATHS etc embedded in the files?
<civodul>yes, every single occurrence of /gnu/store/... found in the files
<civodul>it's "conservative scanning" in GC parlance
<thomasd>does that include paths in wrapper scripts?
<civodul>indeed, i wonder how long it takes to run this
<jmd>There was some 3D thing which did something similar. I can't remember what it was called though.
<davidl>jmd: well bash-commands work fine if I login as that user from the login screen, just not when I login from a root terminal. HOME being correct means it is set as normal "$HOME=/home/<username>"
<jmi2k>And guix can retrieve a new list of packages on its own (so if a package is added today, I can just guix pull and install it without waiting to the next version)?
<rekado>davidl: I'm guessing that your home directory contains files that were not installed by Guix. I also guess that there's a file ~/.bashrc. Does this file contain a line where the PATH environment variable is set?
<davidl>rekado: the .bashrc doesn't export any PATH info. And there's only standard files in the HOME directory, including a .guix-profile symlink.
<davidl>jmd: checking path from root terminal it's PATH=/home/user1/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin wheras logging into user1 and echo $PATH will show /bin:/usr/bin only.
<davidl>however, the correct (as seen from root) PATH works when logging in with su -l <username> as iyzsong explained.
<rekado>davidl: Guix doesn't use /usr/bin, so I think your PATH is set by some initialisation file of the target user.
<davexunit>I repeat, you do not need to rebuild anything to see the build log
<roelj>jmi2k: What davexunit says is correct. You can spare yourself an entire rebuild of the package.
<ng0>i think the computer which is slowly starting to fail, it's the graphics card. it doesn't explain why it hangs at the harddisk, but now with the older kernel I can#t even load Gnome. while awesome works
<jmd>davexunit: I thought "guix challenge" was for testing if its reproducible?
<jmi2k>davexunit: Yes, you are right, but I was building a tiny package and I could get it faster with --check. But I'll remember it for the rest :D
<koenvg>Hey! Maybe stupid question, but I was trying to install GuixSD on my laptop, but couldn't find my wireless interface. So "ip a" only listed the loopback and ethernet interfaces, while on my current distribution it also shows the wireless interface. Any idea what I'm doing wrong?
<davexunit>koenvg: it could be that your wireless chip isn't supported.
<jmi2k>Maybe the card isn't supported by GuixSD. What distro are you using now?
<koenvg>I'm using Arch right now, on a Thinkpad T440s
<davexunit>koenvg: if the chip requires non-free firmware, which is common, then it won't work in GuixSD.
<davexunit>Arch uses a kernel with firmware blobs in it, which is why your wireless chip works.
<koenvg>ahh, I see. How can I find out whether the chip is supported?