<daviid>paroneayea: guile-sqlite3 is using the ffi, and needs love :) it was on gitorious alias, don't know if it's accessible right now. i think, if i may say so, that postres is not a good idea, because it exists and it would be a huge task, really hude. also, guile-dbi is nice, but linas would like to find another nmaintainer I think. anyway, my 2c
<paroneayea>daviid: I emailed wingo because I wanted to try guile-sqlite3 and it's down
<daviid>davexunit: well, if it just to learn what guile db should look like, then i don't think iy's a good idea, no, imo. besides, the existing binding [although we know some folks related problem] is really in an advanced stage, no way to compete, and i really think we should concentrate our efforts [like offering support to guile-pg would be a much better idea]
<davexunit>guile-pg is written in C and difficult to hack
<daviid>paroneayea: yes, but where? i don't have any. actually i wanted to ask a savannah non gnu, but didn't want to walk on andy's feet ...
<davexunit>seems like wasted effort if someone can quickly create an ffi version
<paroneayea>daviid: maybe just make your own repo clone on notabug or somewhere?
<daviid>paroneayea: i really would like this authorized by wingo or he does it. but in the mean time, if you send me your email, i can mail a bzip [very small project
<mark_weaver>the other inputs and native-inputs should be removed
<mark_weaver>you should *not* remove the strip, validate-documentation-location, delete-info-dir-file, or compress-documentation phases
<mark_weaver>rather than adding a new phase that does everything, you should 'replace' the build, install, and maybe check phases to do those jobs.
<mark_weaver>within the phase procedures, instead of using %build-inputs and %outputs, you should accept those as arguments to the phase procedure itself, by writing (lambda* (#:key inputs outputs #:allow-other-keys) ...) instead of (lambda _ ...)
<mark_weaver>there should not be "usr" anywhere. it should be <output>/lib/go instead of <output>/usr/lib/go
<mark_weaver>instead of repeatedly doing (assoc-ref %outputs "out"), which incidentally should now become (assoc-ref outputs "out"), you should just bind a variable 'out' to that, and then use 'out' in the multiple places where it is used.
<mark_weaver>you should wrap lines so that they are less than 80 columns
<mark_weaver>the comments that begin with ";; # " should instead begin with ";; "
<mark_weaver>the "Disable the hostname test" comment seems obviously incorrect
<mark_weaver>in (zero? (system* "bash" "./all.bash")), the result of that 'zero?' test is ignored as you have it now, whereas you should ensure that if a non-zero result is returned, an error will be signalled.
<mark_weaver>phase procedures need to return a boolean value indicating whether the phase succeeded. the value that gets returned from your phase procedure is the result of 'symlink', which is unspecified.
<mark_weaver>and as you note, the LD_LIBRARY_PATH solution is not sufficient.
<codemac>also, go doesn't use the same symbol layout that gcc does, so tools like 'strip' don't really work. I'll see if I can leave the phases in there, but compress docs, deleting info dirs, and stripping will probably all just fail or be no-ops
<mark_weaver>it's okay for the tests to be done together with the build. in that case, remove the check phase and replace the 'build' phase.
<codemac>is there a "replace" directive in modify-phases?
<codemac>and bad separation I just mean that go's build is very very weird, and you can't run tests without re-running make. So it's very difficult to have 1 build file that builds + tests for multiple architectures correctly, as switching on and off tests may be difficult
<mark_weaver>but even if you got cross-compilation working, presumably the test suite can't be run at all in that case.
<mark_weaver>also, the raspberry pi has a fatal flaw: it can't run at all without a huge blob of proprietary software for the GPU, because the thing actually boots via its GPU. the GPU boots first and then sets up the arm processor from there. very weird.
<mark_weaver>tyrion-mx: if the problem is really just the lack of that directory, then you should be able to just create that directory from another system (e.g. the USB installer) and then try booting again from the HD.
<mark_weaver>davexunit: the relevant code is 'file-system-service' in gnu/services/base.scm
<mark_weaver>the code does *not* create the mount point unless the 'create-mount-point?' keyword argument is passed and is true. it defaults to #f
<mark_weaver>those services are in turn created by 'other-file-system-services' in gnu/system.scm
<paroneayea>I'm not being successful with my netcat tests...
<paroneayea>but I'd love to verify if the gexp expansion even worked
<paroneayea>if I can find out where that derivation is written, maybe that would help...
<mark_weaver>sneek: later tell tyrion-mx: you should be able to fix it by simply creating that mount point as an empty directory from another system, e.g. from the USB installer or another OS. no need to reinstall.
<mark_weaver>sneek_: later tell tyrion-mx: you should be able to fix it by simply creating that mount point as an empty directory from another system, e.g. from the USB installer or another OS. no need to reinstall.
<sneek>tyrion-mx, mark_weaver says: you should be able to fix it by simply creating that mount point as an empty directory from another system, e.g. from the USB installer or another OS. no need to reinstall.
<tyrion-mx>the error was there again, but I just doing ,q worked
<tyrion-mx>not I don't know what it is the password of my user :D
<tyrion-mx>I only specified the username in the os confi