IRC channel logs


back to list of logs

<paron_remote>I have pelican working
<paron_remote>submitted 3 relevant patches to the list
<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.
<sneek>Will do.
***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 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.
<mark_weaver>(I don't remember what it is exactly)
<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.
<mark_weaver>rekado can tell you a lot about this.
<mark_weaver>anyway, time for me to sleep. happy hacking!
<chipb>alrighty. good night.
<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>let's see what make-bootstrap copies
<phant0mas>yep it wasn't being copied
<phant0mas>while does exist, gnu-make-boot-0 configure fails with /conftest: error while loading shared libraries: cannot open shared object file: No such file or directory
<phant0mas>mark_weaver: any ideas?
<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.
<phant0mas>you are right, rpctrace it is
<mark_weaver>my guess is that might depend on another library that can't be found, due to a missing rpath
<mark_weaver>bah, this is a pain
<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>but pcre still hasn't made a new release.
<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> 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.
<paron_remote>hello #guix!