<bavier1>sneek: later tell civodul yes, I've done quite a bit of work trying to get 'refresh -l' to be more reliable in the face of implicit inputs. Handling dynamically created packages (e.g. with package-with-python2) then became a critical issue. I haven't yet gotten a solution that's fast or accurate enough for my taste. ***chipb_ is now known as chipb
<chipb>I was playing around with using guix with a non-standard store/state location, as I won't generally have root access some machines I'd like to use it on. <chipb>I figure...hey, just build it with distro libs, overriding state and store locations with configure flags, then use this binary to guix package -i guix. <chipb>but the guix package definition hardcodes the configure flags to the standard location. failure. <chipb>I can hack it easily enough myself, but I'm unsure if this would be considered a bug as far as guix is concerned. <chipb>does anyone know of a rationale behind hardcoding store and state location rather than inheriting the values from the guix that's building the derivation? <mark_weaver>chipb: interesting question. can you email bug-guix@gnu.org about it? <mark_weaver>however, I should mention a few things: (1) if you use a different store location, you'll have to build everything yourself, which is quite a lot of stuff. <mark_weaver>(since guix builds everything using its own toolchain, and uses *nothing* from the host system except the kernel, you have to start by building all of that stuff) <chipb>yeah, I'll go ahead and type an email up. wanted a simple irc smoke test first. :-) <mark_weaver>(2) running guix-daemon as non-root is not well-tested, and I would guess that a lot of our packages don't build properly outside of an isolated build environment, because some configure scripts look for things in standard places like /usr, and if it picks up any of that things will fail badly. <mark_weaver>(3) the absolute pathname of the store needs to be very short, because otherwise you will run into problems because of the limited length of shebang strings in linux (the kernel) <mark_weaver>e.g. many scripts will contain a shebang of the form #!/gnu/store/.../bin/foo <mark_weaver>and linux (the kernel) has a rather small limit on the maximum length of that string. <chipb>I had planned on running the daemon as root on one machine, actually. the plan is to sanely manage a fairly up-to-date tools directory shared via NFS without having to futz with building every little dependency. <mark_weaver>I should also warn you that there are major performance issues associated with guix-daemon accessing /gnu/store via NFS. <chipb>that's...not surprising, I suppose. <mark_weaver>the operations involve a lot of stat calls that turn out to be synchronous round-trip operations over NFS. <mark_weaver>or something like that, I confess I don't know the full details. <chipb>I might just bind-mount a local "NFS" directory to build. <chipb>mark_weaver: eesh. the shebang line limit is 127: #define BINPRM_BUF_SIZE 128 <phant0mas>for some reason libcrt_nonshared.a is not included in the glibc-2.19 bootstrap-tarball... <phant0mas>while libmachuser.so.1 does exist, gnu-make-boot-0 configure fails with /conftest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory <mark_weaver>phant0mas: does the hurd have anything analogous to 'strace'? <mark_weaver>ordinarily I would look to see what files it is looking for. <mark_weaver>my guess is that libmachuser.so.1 might depend on another library that can't be found, due to a missing rpath <mark_weaver>so, pcre has several published security flaws, but the fixes are not trivial and are only available in their subversion repo. <mark_weaver>actually, I guess the problems only arise when the regexps themselves are from an untrusted source, so I'm not super worried about, but it would be good to fix them anyway. <mark_weaver>so, I just tried to update our pcre recipe to check out the source from subversion, but that doesn't work because subversion depends on pcre :-( <mark_weaver>so, now my options include: (1) maintain an older buggy pcre package, build a special subversion against that one, and then use that subversion in this case <mark_weaver>or (2) import a 100 kilobyte patch with the changes since the last release. <chipb>er...wtf does svn use pcre for? <chipb>svn grep or somesuch, I suppose? <amz3>there is no trunk tarball? <mark_weaver>ah, I see. subversion uses swig to general perl bindings, and swig uses pcre <mark_weaver>so I can just make a subversion without swig. should be simple enough.