<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 <Petter>jje: Sounds like your parentheses are unbalanced. <jje>oh dear now the question is where <jje>i will investigate some more. <sneek>Welcome back lfam, you have 1 message. <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>I'll read it later tonight :) <Petter>Ok, I'll get some sleep now. Bye! ***Guest28039 is now known as sturm
***Piece_Maker is now known as Acou_Bass
<lfam>buenouanq: GuixSD won't ever change files in your home directory. If you delete a user, their home directory will still be there. If you roll-back, your home directory will be untouched <lfam>If you want to try treating your home directory as something that can be atomically snapshotted and rolled-back, you should try a filesystem that supports atomic snapshots <buenouanq>What about non home dir things? Or is the GuixSD way adamant about users never touching things that aren't their home dir directly? ***bmpvieira_ is now known as bmpvieira
<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 <efraim>shepard and vim-full disapeared for armhf <efraim>no, scratch that, vim disapeared, vim-full is still there in evaluation 109386 <efraim>i see it now in aborted, thought it'd still show up in new <efraim>it looks like the 1.9.x branch of subversion isn't a dev branch <efraim>thats one of the great things with guix, keeping 1.8 is no big deal :) <thomasd>is there a variable that will give you the directory of the unpacked source during a build phase? <civodul>thomasd: phases run from that directory, so just (getcwd) <thomasd>civodul: for cmake, I think the build phase switches <thomasd>(to ../build) but I managed to avoid the problem by moving the phase to -before 'configure <civodul>thomasd: ah right, in that case you're kinda screwed i'm afraid <civodul>well, you have to compute it by your own means <civodul>which sucks, we should fix it in core-updates <thomasd>another question I came up with: is there a convenient way to substitute variables in a patch? <thomasd>I'd like to patch a source file, hard-coding the store path of an input package into the code <thomasd>currently, I do it using "substitute*", but that feels a bit brittle, because applying this substitution to a future version might cause silent breakage? <jmd>Under the marionette the rpcdaemon doesn't start. How can I find out what its problem is. <jmd>It works perfectly in a "normal" system. <civodul>thomasd: i guess i'd need to see the use case, dunno <civodul>jmd: hopefully it writes to syslog or something no? <thomasd>civodul: ok, I'll submit my patch shortly, and ask on the mailing list. <jmd>I've never actually found out how syslog works in guix. <rekado>thomasd: another way is to use an actual patch <rekado>thomasd: but we usually reserve this to more serious changes <thomasd>rekado: yes, but in a patch, you can't add a variable (like a store path), I believe? <rekado>it's on my list to change substitute* such that it returns #f if the substitution failed <thomasd>a workaround I thought of, is patching to add "GUIX_PLACEHOLDER{N}" in the appropriate place, and then substituting the placeholders with subsitute* :) <civodul>you could have @SUBSTITUTEME@ in the appropriate place and substitute that <jmd>That doesn't say to where syslog streams its messages. I presume it is /var/log/messages ? <civodul>that says it depends on the config file :-) <civodul>and the default is to put many things in /var/log/messages <jmd>Anyway it seems that rcpbind doesn't do a lot of logging. <efraim>wow the subversion tests take forever <civodul>jmd: what you could do is make sure it logs as much as possible <civodul>and also try running the faulty config in 'guix system vm' <jmd>I'll try that. Thanks. <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 <wingo>all run-time lookup variables <wingo>but we don't yet, so lookup is quadratic <rekado>aren't rpaths embedded in the binary? <rekado>and I thought they are full paths to actual libraries <wingo>they are paths to directories in which to find libraries afaiu <wingo>so for libs A B and C in dirs dA dB and dC, dA:dB:dC get set as the rpath in the library <wingo>and looking for A then takes 1 step, looking for B takes 2, looking for C takes 3, and so on <roelj>I thought the absolute path to dependent libraries were embedded in the binaries, so that way no lookup would be needed.. <roelj>Hm, indeed. It looks them up <roelj>Also, in the binary it links only with the library filename, and it also includes the search paths to look for them. <roelj>It would be cool if it didn't have to do lookups though. <thomasd>is there a way to update field of a (guix record), like (set-field record ...)? <thomasd>I'm trying to add a patch to the (source) of an inherited package, but failing <efraim>Check out some of the replacement packages, some take the source and add a patch <thomasd>efraim: thanks. again it turns out to be much easier than I thought <rekado>thomasd: see gcc-arm-none-eabi-6 in (gnu packages embedded) as an example <rekado>this package overrides only the "patches" field of the origin expression in the package's "source" field <thomasd>rekado, civodul, efraim: thanks, I got it working :-) <jmd>How does shepherd know if a daemon is running or not? <jmd>(if no pid file was given) <civodul>jmd: it does fork+exec and knows it's running until it gets a SIGCHLD for that PID <jmd>Does SIGCHLD happen if the child crashes? <jmd>Could it be that either flock or unix domain sockets are not available in a VM? <ng0>okay, I can not figure out easily how to use an older kernel, and I've spent some time searching now. I think it's because of what you use which makes it difficult to search for keywords <ng0>is it simply in (kerne) and then linux-libre@4.4 or something like that? <roelj>Is there an equivalent for 'install-file', but then for copying a directory? <roelj>ng0: If you copy-paste the entire version string for the kernel package you want to use, it should work linux@<entire-version-string> <iyzsong>roelj: yes, it's: mkdir-p + copy-recursively <ng0>oh, so it's always the entire string, not for example 4.4 <roelj>ng0: Do you have multiple linux-libre packages with version 4.4.X? <roelj>'guix package -i linux-libre@4.4' installs linux-libre 4.4.34 here. <roelj>Same for 'guix package -i python@2' <ng0>I'd rather like to find out why everything above 4.8.10 is bad for that computer, but it's not so important. <ng0>4.4.36 is unbound for me, but that's the only linux-libre in 4.4 i find <ng0>and for package modules I use linux already <roelj>ng0: Oh, is this in a OS declaration file? <ng0>weird. someone replied to my tlsdate patch but I did not get the email this morning <roelj>Then use the variable name of the exact linux-libre package. <ng0>so (kernel linux-libre@4.4.36) ? <ng0>seems to works.. thanks :) <ng0>ah, now i got the email <roelj>rekado: Looking at the days that are available, it seems to be a showcase for the various architectures QEMU supports. <rekado>wasn't there a boot to guile qemu image somewhere? <roelj>Oh, people can suggest images :) <jmd>What provides /etc/netconfig in GuixSD ? <jmd>So where did mine come from? I didn't create manually. <roelj>find /gnu/store -name "netconfig" ? <jmd>libtirpc it would seem <civodul>rekado: boot-to-guile is called "GuixSD" nowadays :-) <jmd>But it's not a symlink. What puts it in /etc ? <civodul>jmd: you could check 'guix system extension-graph', but it seems that nothing puts it there <jmd>I will remove it and reboot. See if if comes back. <civodul>janneke: maybe you could write an article for the Guix blog about MinGW cross-compilation? what it does, how it works, how it compare to GUB, what you intend to do with it, etc. <civodul>jmd: but it won't disappear automaticall <jmd>No. But it might reappear automaticaly if some service is putting it there. <civodul>if it were put there by a service, it would be a symlink to /etc/static/netconfig <civodul>which in turn would be a symlink to /gnu/store/... <jmd>Actually that's what I thought ... <jmd>But I have a lot of other things in /etc/ which were created by services and are not symlinks. <jmd>Is there some option to de-symlink them? <jmd`>Maybe I did manually create /etc/netconfig (but I don't remember doing so). <ng0>that's more of an #guile question, but what's needed for (system*) to accept a "." as valid? like in (let ((system* "." "torsocks" "on")) <ng0>or is this even possible? I assume it's a bash centric thing where I need to go another path in guile <janneke>i also wrote a bit for the manual...but that needs some review+changes <janneke>i'll send a version of that to -devel <civodul>janneke: for the blog, you can send me a patch against guix-artwork.git (which contains the web site) <jmd`>I see you were the original packager for libtirpc <jmd`>Should we not substitute "/etc/netconfig" with (string-append %output "/etc/netconfig") ?? <jmd`>Hmm. There are lots of places. <jmd`>Probably everywhere it occurs. <jmd`>But particularly tirpc/netconfig.h <Petter>In a package definition, how to remove a directory and everything in it? (rmdir) is uncomfortable with the task. (Directory not empty) <jmd`>Petter: delete-file-recursively ***ifur_ is now known as ifur
<Petter>Hm, (getcwd) gives me *.drv-0 everytime I build (with -K). At the end it says, "keeping build directory *.drv-10" <civodul>Petter: the directory inside the build environment always has the same name: /tmp/guix-build-foo.drv-0 <civodul>however, outside the environment, it has a name that can be different <Petter>Aha, so I'm looking at something that's not a problem then. <civodul>for debugging purposes you should rm -rf previous build leftovers so that both names match <avoine>what are the risk of adding a cron job that do guix pull + guix package -u daily? <civodul>avoine: they should be limited since you can always roll back <civodul>but depending on your workflow, it might still be disrupting if everything's updated daily <avoine>I would like to reduce the time of the download/build <avoine>is there a download+build command but without adding the package to the profile? <avoine>maybe I could just add a dummy profile <Petter>Success!! I've removed one of the bundled dependencies of syncthing, packaged it, and syncthing builds with this now! :) <davidl>I finished installation with full disk encryption now and it works but there are some stuff which doesn't work as expected but I guess thats normal. <davidl>for example if I change user in a terminal I cant use regular bash commands like 'ls'. <jmd>davidl: Why can you use it? <jmd>perhaps the PATH is not right. <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>that said, 'propagated-inputs' exists for cases where conservative scanning isn't enough <thomasd>so text strings in binary files as well <civodul>like when a .h file #includes another .h file <thomasd>hmm, I need to figure some stuff out. I wish building these KDE things didn't take so long :-) <davidl>jmd: $HOME is correct when checked from a root terminal with "sudo -Hiu <username> env | grep HOME" <jmd>davidl: and is "ls" in $HOME/.guix-profile/bin ? <davidl>jdm: it's empty except one installed program. <jmd>davidl: So that's why the command is not found. <jmd>What do you mean by HOME is "correct" ? <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>" <jmd>davidl: And does your PATH point to a directory which contains "ls" ? <rekado>davidl: did you override the PATH? <rekado>it would not be okay to set PATH to ~/.guix-profile/bin alone <davidl>jmd: yes, the /run/current-system/profile/bin has "ls" but I guess that doesnt change when I login from a terminal, only when I change session. <davidl>rekado: no I haven't done anything to the PATH in my config.scm file. <rekado>davidl: and in your shell configs? (e.g. bashrc) <jmd>and does is /run/current-system/profile/bin in your PATH? <jmd>davidl: (incidently, "ls" is not a bash command) <davidl>jmd: yes, both for the root user and user1 <jmd>davidl: Yet when you type "ls" you get an error? <davidl>jmd: it says "bash: ls: command not found" <jmd>ok. What if you type /run/current-system/profile/bin/ls <jmd>What about "which ls" ? <jmd>/run/current-system/profile/bin/which ls <jmd>What does it tell you? !!!! <davidl>outputs "no ls in (/bin:/usr/bin) <rekado>davidl: what does "echo $PATH" show? <davidl>so, I guess logging in from terminal gives me $PATH=/bin:/usr/bin <rekado>is this a fresh installation with an existing home directory? <davidl>wheras checking it from root gives me all the other PATHs <rekado>or is the home directory fresh too/ <jmi2k>Can GuixSD be called 'rolling release'? AFAIK there is a version number, but the system is purely determined by its packages <jmd>jmi2k: Good question. <davidl>home directory os HOME=/home/user1 <rekado>davidl: this doesn't answer my question. <jmd>I think the releases are really just milestones. <jmd>davidl: Yeah. I did ask you before. What is the value of your PATH ? <iyzsong>yeah.. when change user, you need 'su -l xxx' or 'sudo -iu xxx' :-/ <davexunit>knowing how to inspect and debug environment variable issues is a pre-requisite for using guix, I would say. <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? <jmi2k>Nice! One more pro to the list :D <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. <rekado>davidl: "su -l" or "sudo -E" only keep the current environment, which as you say is correct for root. <davidl>rekado: ok. it does change the /root/.guix-profile... to /user1/.guix-profile when "su -l" so it subtitutes the environment or keeps it is basically the same <davidl>thanks for everyone's help here. <jmi2k>How can I force guix to rebuild a package? I'm trying a recipe, but when I want to build it it just prints the path /gnu/store/... I want to see the output of the build <davexunit>jmi2k: guix won't rebuild things that have been built already. <davexunit>use the --log-file flag if you want to see the log of the build <roelj>jmi2k: Use guix build --check <jmi2k>roelj: thanks! It was exactly was I was looking for. <davexunit>--check is for testing if the build is reproducible <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 <davexunit>--check will test if 2 builds on your machine produce the same result <roelj>davexunit: This --log-file options is great! It even shows whether something had been built locally, or remotely. <davexunit>'guix challenge' will test if what you built on your machine is the same as what is available elsewhere. <davexunit>which reveals not only non-determinism, but could reveal tampering. <roelj>Is there also a command that gives an overview of what has been substituted and what has been built locally? <davexunit>no, but it should be easy enough to write given that we have all the necessary tools. <jmd>davexunit: Ok. thanks. (the manual needs to be more explicity about this). <davexunit>roelj: would you want to see this information at the derivation level or the package level? <roelj>davexunit: Derivation-level. And also only what's in my current profile generation (so that would be package level). <davexunit>so there's really several possible tools there <davexunit>I don't know what you'd do with such information <roelj>davexunit: First, smile at the possibility ;) After that, it could be useful information when a build service had been tampered with. <jmi2k>If I want to make a patch, in the commit message, should I put the module name or the package name? The file is called text-editors.scm and the package vis <jmi2k>I'm trying to upload my first patch, but I'm having some difficulties <davexunit>read the commit log for other package additions <jmi2k>Ok, so something like: gnu: Add vis <davexunit>* gnu/packages/text-editors.scm (vis): New variable <jmi2k>Where? In the commit message? <jmi2k>Ok, I can see it in the git log <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? <rekado>koenvg: maybe check the output of "dmesg" <davexunit>you have a thinkpad, so you almost certainly have an intel wireless chip <davexunit>all intel wireless chips require nonfree firmware <koenvg>yeah I have an intel wireless chip <rekado>also note that with the Lenovo BIOS you cannot boot after replacing the wireless card <davexunit>I flashed a hacked BIOS on my x220 that allowed me to replace the intel chip with an atheros one. <davexunit>it's a bit sketchy, but now I can run a fully free OS. <koenvg>so maybe for now the easiest way to try out guix is to use on a different distribution than GuixSD? I don't think I'm ready to hack my BIOS yet ;) <rekado>koenvg: there are wireless USB thingies <ng0>there are also tiny wifi usb cards <rekado>the ones ThinkPenguin sells will work with Linux libre. <davexunit>I didn't want a usb wireless chip so I did the BIOS hack. <ng0>i have found no way to stuff my 11db antennas into the laptop yet so I replaced the card in the laptop (and the bios) <davexunit>koenvg: yeah if wireless is a dealbreaker and you don't have the means/ambition to use another wireless device, then GuixSD won't be a good fit. <jmi2k>davexunit: Should I include the change in gnu/local.mk too in the commit message? <koenvg>davexunit: I can see that, I think I'll stick to a different distribution for now than. I'll give it a shot when I get around to building my own desktop or something <rekado>koenvg: you *can* use Guix as a package manager on other distributions <koenvg>rekado: I read that, I am excited to try it out! <rekado>you'll just miss out on system configuration <jmi2k>davexunit: someone on the mailing list told me that I had to add the file to local.mk <davexunit>yeah, that gives you a way to experiment without leaving the comfort of your daily-driver OS. <rekado>also, Guix on a foreign distro requires a little more setup <davexunit>jmi2k: oh it's a new file? then yes, mention that. <rekado>(e.g. setting environment variables that GuixSD would set on your behalf) <rekado>jmi2k: if it's a new file the commit message also changes <rekado>* gnu/packages/teh-file.scm: New file. <koenvg>alright, I'm sure I'll figure out. Thanks again for the advice! <jmi2k>I think I'm going to abuse git commit --amend a bit today :) <thomasd>would it be possible to also scan for UTF-16 strings when determining store references? e.g. Qt's QStringLiteral is UTF-16 <jmi2k>I think I finally got it. Let's see if after three failed attempts to submit my patch, they get accepted. <efraim>is there anything special I need to do on the offload machine to get it to start recieving and building? <efraim>I'm getting a lot of: process 28090 acquired build slot '/var/guix/offload/192.168.1.221/0' <efraim>and guix offload test /etc/guix/machines.scm passes <jmd>How do I get the configuration back from a service? <civodul>efraim: the "acquired build slot" thing is normal, it has to do with 'parallel-builds' <civodul>but are you saying that it never goes beyond that? <efraim>i let it sit and print for about 3 minutes on a build that should be about 50 seconds <efraim>load on other machine doesn't go up <civodul>$ file /gnu/store/9f6yjg09sj6vx8s3nfp15i52ppv0fcyi-guile-2.0.13/bin/guile.exe <civodul>/gnu/store/9f6yjg09sj6vx8s3nfp15i52ppv0fcyi-guile-2.0.13/bin/guile.exe: PE32 executable (console) Intel 80386, for MS Windows <civodul>efraim: so it prints that in a loop? <civodul>but is there already another build offloaded to that machine? <civodul>try adding a 'parallel-builds' field maybe? <efraim>i'll try adding the parallel-builds field <civodul>here you see that it repeats things until one of the machine has a load lower than 2 <efraim>i'll try changing the speed from 0.5 to something >1 <efraim>it doesn't show as being tmpfs from df -h, ext4 like the rest of / ***kelsoo1 is now known as kelsoo