<davexunit>paroneayea: I've never used racket so I have no idea <paroneayea>davexunit: I think I'd like to try racket's db module so that I have a better sense of maybe what database support should maybe look like in guile, hence my desire to set it up <paroneayea>davexunit: maybe I'll try writing an ffi postgres thing for guile... <paroneayea>it's about time I try some ffi thing in guile :) <davexunit>bah, npm tries to download dependencies when installing <davexunit>which obviously cannot happen in the build container <paroneayea>davexunit: hey suggest symlinks as a possible solution for cycles, but circular symlinks, is that better?... <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>paroneayea: ah, I see. I have a local copy <davexunit>daviid: why would a ffi postgres wrapper not be a good idea? <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 <daviid>paroneayea: wc! just emailed you <davexunit>hmm for some reason guix deploy doesn't work for me at all. <davexunit>perhaps there was some abi breakage and I need to recompile some files <paroneayea>davexunit: I'm guessing a different issue than I reported to you? <davexunit>paroneayea: oh wait, this #:redir-ports thing <davexunit>paroneayea: if I can get this to work I want to see if I can write an nginx service quickly <davexunit>okay, got the VM version of my laptop config running <davexunit>paroneayea: I doubled the disk image size and it worked <davexunit>I'll add a #:disk-image-size keyword arg to local-vm <davexunit>paroneayea: I want a similar feature for containers when I get around to implementing the networking stuff. <davexunit>vm images default to 32MiB for no particular reason <adhoc>ACTION is looking forward to micro-services in containers on guix =) <codemac>ok golang package pretty much done. only issue left is that I am setting LD_LIBRARY_PATH for the tests it runs.. but not sure how best to fix that. <codemac>if anyone would like to give me some feedback before posting to guix-devel, would love it! <mark_weaver>this still shows a lot of the signs of having started out as a trivial-build-system package <mark_weaver>first of all, you have a lot of 'inputs' and 'native-inputs' that are implicitly included by the gnu-build-system <mark_weaver>it's easier to say which ones might need to stay: perl, linux-libre-headers, pcre, rc, and pkg-config. <mark_weaver>pcre and linux-libre-headers should be normal inputs, not native-inputs. <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>mark_weaver: thank you so much for the review! <sneek>codemac, you have 1 message. <codemac>mark_weaver: How do I make the result of the zero? test not ignored, just an `if` clause or something? <codemac>mark_weaver: also - go only has "all.bash" that does build + test all in one go that I can't seem to tease apart. I'll make an install phase though for the copy-file crap. <mark_weaver>codemac: you can write (unless (zero? (system* ...)) (error "all.bash failed")) <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 pcre is actually only used by a test, it's not linked against in the final result. <codemac>the ./all.bash does a lot of compile with XXX C libraries, run, see that it worked <codemac>do I misunderstand what native-inputs are for? <codemac>I thought of inputs as 'runtime deps' and native-inputs as 'build deps' <mark_weaver>well, the tests won't be done (and wouldn't work) in a cross-compilation anyway. <mark_weaver>suppose you are cross-compiling, and doing the compile on x86_64 and building software that will be run on armhf <mark_weaver>in that case, the 'inputs' will be made to run on armhf, and the 'native-inputs' will be made to run on 'x86_64'. <codemac>hm. that's a bad separation for the go build, they have "GOOS" and "GOARCH" env variables <codemac>you can change them and re-run all.bash & make.bash and it'll recompile things. <mark_weaver>bad separation, what do you mean? what would be a better separation? <adhoc>which armhf platform are you using ? <codemac>GOOS = operating system you're building the go toolchain for. <codemac>GOARCH = the architecture that operating system runs on <codemac>GOOS=darmin GOARCH=amd64, GOOS=linux GOARCH=arm, etc <mark_weaver>adhoc: well, I'm using a Novena laptop board, but the Guix armhf-linux port should run on any armv7 board with NEON. <mark_weaver>codemac: my guess is that it would take some extra work to get cross compilation working. <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. <adhoc>mark_weaver: is this the laptop by Bunnie? <codemac>I'll do my best to get this cleaned up more, still not sure what to do about libgcc_s.so never being correctly picked up by 6l <adhoc>wow, i'd kinda forgotten about them, how is it working out ? <mark_weaver>codemac: you'll have to find the place where libgcc_s.so is referenced and arrange for it to be loaded from its absolute pathname /gnu/store/... somehow. <mark_weaver>codemac: what architectures are supported? i686? armhf? mips64el? <mark_weaver>you can test the build on i686 by running "guix build --system=i686-linux -K go" <mark_weaver>note that will be done natively, not a cross-compilation. <mark_weaver>it will end up downloading i686 binaries for the entire toolchain and other programs needed during the build, and run the entire build in 32-bit mode. <mark_weaver>so it would be good for you to get it running on i686 as well, assuming that go supports it. <codemac>yeah, it supports lots, but I'm not sure they kept their mips port <mark_weaver>codemac: btw, you can find out the location of the dynamic linker using the 'glibc-dynamic-linker' procedure in (gnu packages bootstrap) <codemac>seems like arm, 386, and amd64 are all they really support <mark_weaver>when it's closer to being ready, I can test it on armhf <codemac>I have some arm hardware as well (raspberry pi, and an AArch64 board) <codemac>I should get guix up to speed eventually on that as well, but you'll probably be way faster on testing <mark_weaver>it should run on a beaglebone black, but it won't be practical to get it running on a BBB until we have an armhf build slave for hydra. <adhoc>mark_weaver: is r_pi a differen arm platform ? <mark_weaver>but I'm glad to report that it looks like we might have such a build slave soon. <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. <adhoc>i know, they took short cuts to get it out <adhoc>i got some to support my hacker space bulk order <adhoc>i'll hav eanother look though <adhoc>you can run GSD on the BBB ? <adhoc>so you either pay through the nose for postage or pay through the nose for a local supplier <mark_weaver>although again, it won't be practical until we have an armhf build slave for hydra, which should hopefully happen in the next few weeks. <adhoc>can a BBB be a build slave ? <adhoc>can we run armhf VMs on x86_64 ? <adhoc>i have the RAM, CPU and disk to run such a thing <adhoc>issue is how do I get access to it from th net <DusXMT>adhoc: In the "user networking" mode of qemu, you can forward TCP ports, and there's also a tunelled mode which makes it act like another machine <mark_weaver>I'm dubious of using a cross-architecture VM for a build slave though <DusXMT>It will be slow, because of no hardware acceleration, but with a powerful enough host, it shouldn't be that terrible <adhoc>DusXMT: yes, that sounds reasonable, but getting ports vissible to the net, is another challenge altogether ;) <adhoc>underlying hosts have more than enough grunt. <adhoc>i have 16core VMs with 16GB RAM as i386 and x86_64 running now <mark_weaver>feel free to play around, but I'd like to use native armv7 machines exclusively for the hydra build slaves anyway. <DusXMT>also, I don't think there's a unified boot interface for ARM devices <adhoc>and only for x86_64 and i686 <mark_weaver>we don't yet have GuixSD for armhf. currently, on armhf, we only have Guix itself, so it must run on top of an existing distro. <adhoc>ok then, roll a debian armhf .iso and roll the binary on to that ? <mark_weaver>we do have a binary-install tarball for armhf though. <mark_weaver>or wheezy, whatever, it doesn't matter. you'll have to do the entire bootstrap from source code, which is somewhat analogous to following the <mark_weaver>especially when emulating an armhf processor in software on intel. <adhoc>been a looooong time since i build a LFS box =) <adhoc>so the guix armhf builds everything from source ? <mark_weaver>at present, yes, since we don't yet have an armhf build slave for hydra (our build farm) <mark_weaver>so we cannot currently provide precompiled binaries. <mark_weaver>(except for the binary-installer, which only provides 'guix' itself) <mark_weaver>make sure to run "guix pull" before building anything. <adhoc>"libvirtError: unsupported configuration: this QEMU binary lacks hda support" <adhoc>there has to be another VM platform that supports it =) <adhoc>libvirtError: internal error: process exited while connecting to monitor: Error: Cirrus VGA not available <adhoc>hmm this could be a stretch =/ <codemac>is there a way to get the current directory during the check phase? is system pwd too silly? <mark_weaver>codemac: (getcwd) returns the absolute pathname as a string <tyrion-mx>Hello is there something lighter than xfce on guix to use on a really old netbook? <rekado->I'm having trouble using vpnc on GuixSD. Is our package known to work? <rekado->tyrion-mx: there is ratpoison, a window manager. <tyrion-mx>rekado-, don't you need also a desktop environment? <mark_weaver>tyrion-mx: what do you use on other distros on that machine? <mark_weaver>we have windowmaker, another window manager, and I guess we also have enlightenment, although I haven't used it <mark_weaver>ratpoison is very lightweight and works well on very old hardware <tyrion-mx>mark_weaver, I never used that machine recently <tyrion-mx>I think I would need some kind of menu to open apps <tyrion-mx>I don't know, something to avoid typing the whole command everytime <davexunit>in ratpoison you can configure keybindings to exec various programs <mark_weaver>it sounds like you want the comfort of a desktop environment, but that may be asking for a lot with your machine <mark_weaver>a bare window manager is probably going to feel very primitive to you, but with some effort they can be configured to avoid repetitive typing for things like launching programs <tyrion-mx>mark_weaver, yeah having a DE would be cool, but I don't think that netbook is going to handle it, so I will stick with a window manager as you guys suggested <tyrion-mx>guix does not currently support having the root partition encrypted right? <mark_weaver>we have an unusual initrd based on guile, and it doesn't yet have support for mounting an encrypted root partition <mark_weaver>several people have asked about that, and I'd like it too. so many things to do. <mark_weaver>since I run Libreboot, I actually have the possibility of encrypting *everything* on the hard drive, even the boot partition, since GRUB is burned into my firmware. <mark_weaver>which would be good, since hard disks has proprietary firmware in flash and can be infected by rootkits, so it would be good to not have to trust them at all. <tyrion-mx>umh I dind't even know that such a thing existed <tyrion-mx>cool, but I don't have time for that now, unfortunately <mark_weaver>well, the next time you buy a computer, please consider getting one that Libreboot runs on :) <francis7>(this is gluglug. it renamed to minifree) <francis7>I'll try to get the site to work in librejs some time this month <francis7>the JS files are all free, but it has that classic issue where they aren't tweaked properly for libreJS to recognize that, even with web labels (which I have: http://minifree.org/licenses/) <francis7>the old site automatically redirects to minifree.org <francis7>I also need to tweak that top menu, so that some of the links are placed in the footer <francis7>the framework that I'm using is a bit deficient, but it looks nice <francis7>I'll have to fork everything and maintain my own branch, with the desired changes <francis7>it didn't even support adding a logo (I added that functionality myself, so now there's a logo on the site) <francis7>the site works, though. I also added bank transfer payment option to the checkout, as an alternative to paypal. A few people have used that option already <francis7>the next task is to get rid of paypal entirely (use a different payment processor for cards) ***hopses is now known as hospes
<tyrion-mx>the installation says that I have to mount my install partition to /mnt <tyrion-mx>but if I have a separate boot partition should I mount it to to /mnt/boot ? <mark_weaver>tyrion-mx: I'm not sure that a separate boot partition will work currently. <mark_weaver>at present, our boot process makes some assumptions about things being on the root partition, and that definitely includes /var and maybe also /boot <tyrion-mx>and alsoa windows partition declared in my os.scm file <tyrion-mx>umh, maybe this is why I could not make it work <tyrion-mx>so everything declared in my os config file should be mounted at /mnt/location ? <mark_weaver>when you install the system, it will try to create your home directory and put some files in there. <mark_weaver>I don't think everything needs to be mounted, but home should be <mark_weaver>the windows partition definitely doesn't need to be, though. <tyrion-mx>do I have to run deco start cow-store /mnt/home ? <paroneayea>ACTION runs (deployment (name "test-deployment") (machines (list web-server db-server))) <paroneayea>the #<<deployment>> representation is 39437 chars long <paroneayea>guile structures by default printing recursive definitions of themselves <mark_weaver>paroneayea, davexunit: if the default record printer doesn't work well in that case, then perhaps there should be a custom record printer for that type <davexunit>mark_weaver: yeah, I've done that in the past for a few things. <mark_weaver>and I'm open to ideas on how to improve the default record printer, but will have to be mostly afk for a while now... <amz3>we can make default print draw graphs :) <amz3>GNU epsilon has thing like it does print only the adress of the datastructure if it was already printed (and has colors too) <mark_weaver>SRFI-38 provides 'write-with-shared-structure' that does that <mark_weaver>we've had that for a while, but I've not used it and I don't know how it deals with the general case of arbitrary user-defined data structures. <mark_weaver>but I have made a new implemented that should be fully general on the r7rs-wip branch <mark_weaver>although I haven't merged it because yet for various reasons, partly because I'm not satisfied with the efficiency of the implementation. <davexunit>mark_weaver: oh cool, didn't realize you had that in progress. <mark_weaver>I think I need to implement a much faster hash-table specialized for the particular pattern of usage here, namely pushes and pops in LIFO order (stack order) <davexunit>while on the subject, I think we should do something to limit how much of a bytevector gets printed. <davexunit>I've accidentally printed bytevectors representing the pixels of a large image file <davexunit>I just don't know exactly what the fix should be. <mark_weaver>I don't think we can change the default behavior, but we could make an option <mark_weaver>we already have 'truncated-print' in (ice-9 pretty-print) <davexunit>no? bummer. more than paroneayea and I have run into these neverending printing issues. <mark_weaver>we could perhaps change the default REPL printer, but not 'write'. <davexunit>where I sometimes live in fear of the printed representations of the objects I'm working with <mark_weaver>sure, we could ask on the ML if there are any objections to changing the default repl printer, <tyrion-mx>however when rebooting it says that it cannot mount the win partition <davexunit>the mount point is created before making the 'mount' syscall <davexunit>2 things: that file system probably shouldn't be mounted in the initrd <davexunit>why not just get a simple config to work so you have a base to work from? <davexunit>then each rebuild will take barely any time and you can do roll-backs when things break <mark_weaver>that's a good point, we should probably recommend that in general <mark_weaver>once you have at least one working config, then you can always roll back to it and fix things up. <mark_weaver>but before you have the first working config, it's rather painful to fix things. <mark_weaver>tyrion-mx: so you get stuck in the initrd guile prompt? <davexunit>unless you have a special disk image with *all* the needed packages ready to go <davexunit>mount-file-system in (gnu build file-systems) calls 'mkdir-p' on the mount point, but maybe that's being used in the initrd? <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 <davexunit>mark_weaver: thanks, I wasn't aware that different code was used here. <davexunit>tyrion-mx: sorry, I was wrong about not needing to create the directory for the mount point! <mark_weaver>davexunit: ultimately it depends on the value of the 'create-mount-point?' field of the file-system record, which also defaults to #false <paroneayea>I'm trying to test this redir-ports patch I made to wip-deploy, but I seem to be struggling <mark_weaver>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>you could also create the empty directory from the guile prompt in the initrd, for that matter. <mark_weaver>but I don't remember the details of where the root filesystem will be mounted at that point <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. <paroneayea>this is something I'm launching with "guix deploy spawn" <davexunit>paroneayea: you should see the list of built derivations when you run that <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. <paroneayea>[ 0.000000] Command line: console=ttyS0 --load=/gnu/store/1phlnxrvxz2k72qp36n55mll5446yy2p-linux-vm-loader <davexunit>to know for sure, do some debug printing in the 'boot' action for local-vm <davexunit>(lambda (script) (pk 'vm-script script) ...) <davexunit>that should get you the file name of the script that is executed <sneek>tyrion-mx, you have 1 message. <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