<marusich>I can continue to hack on something else while building stuff in another workspace... <lfam>marusich: Huge timesaver! <Apteryx_>marusich: watch for the GUILE_LOAD_PATH though ;) I got bit by that hard. <bavier1>Apteryx_: pre-inst-env should take care of that, no? <Apteryx_>it does. But then I have my Emacs/Geiser configured for ~/src/guix/, so there's friction there as well. <eric23>ezponia jchmrt Digit metaphysician <eric23> roptat s34n db48x contrapumpkin Exagone313 cehteh divansantana csprng lewo <eric23> dvn- andschwa kelsoo MinceR kristianpaul aravind <eric23>*** Users on #guix: Jackneilll dghubble jherrlin wingo reepca noordinaryspider <eric23> EuAndreh[m] mb[m]1 mray[m] gamba[m] M-geemili mekeor[m] espectalll <eric23> CharlieBrown wilo[m] itsfemme[m] nicorikken[m] taohansen happy_gnu[m] <eric23> clacke[m] Guest85319 Guest67041 jonjits[m] Sovereign_Bleak angelbeats[m] <eric23> thekyriarchy jonsger[m] Wysteriary[m] muhq[m] garlox[m] equalunique[m] <eric23> icen[m] cornu[m] richi235 oahong cyraxjoe buenouanq Tsutsukakushi Apteryx_ <db48x>looks like an accidental copy and paste <taohansen>how is tagging everyone in this channel an accidental copy and paste? <db48x>he might even use the same irc client as I do; it's formatted the same way <db48x>taohansen: on systems where both copy and paste are purely mouse operations (selecting some text automatically copies it, and middle clicking pastes it), simply fumbling for the mouse in the dark can result in a paste <marusich>Apteryx_, Oh, good point. I didn't think about that. <ng0>lfam, or anyone: the go build system is documented, but how does one start with this? git clone the go-url and calculathe the hash on it? <ng0>like for github.com/s-rah/onionscan I need at least 5 more go packages that are not in the standard lib <ng0>oh... captain obvious says tarballs <ng0>I thought there was something special about go <ng0>Am I doing this right? The tar ball unpacks a "jwt-go-1.3.0" folder, so: <ng0>+ `(#:import-path "github.com/dgrijalva/jwt-go" <ng0>+ #:unpack-path "github.com/dgrijalva/jwt-go/jwt-go-3.1.0")) <ng0>but still fails the build <ng0>can't load package: package github.com/dgrijalva/jwt-go: no Go files in /tmp/guix-build-go-github-com-dgrijalva-jwt-go-3.1.0.drv-0/src/github.com/dgrijalva/jwt-go <ng0>oh, some go packages don't even define it… I'll try without the arguments first <ng0>maybe the documentation of the go build system needs a note on what to do when the unpacked path of the tarball is not standard ***fusion809_ is now known as fusion809
<ng0>this is interesting news in transition to other forms of distribution, indeed <ng0>somewhere in the discussion archive I created about distribution choice discussions, I found something about creating a new nar format. Is this still planned? <brendyn>Very nice. Looking forward to ipfs/gnunet support ***pksadiq_ is now known as pksadiq
<Apteryx_>civodul: it's moving day today, and after that I'll be reconnected only Thursday. Apologies in advance for the delayed review of your 27284 patches. <davexunit>nice to see some analysis of reproducibility that's somewhat like what debian does <civodul>we should post an article about the great bootstrap work by rekado et al. eventually <dvn->Hey, i've been struggling trying to get guix to pull <dvn->I've followed the tutorial, and tried many things, but I still get this error: <dvn->warning: TLS 'SERVER NAME' extension not supported <dvn->ERROR: X.509 server certificate for 'git.savannah.gnu.org' does not match: CN=bzr.savannah.gnu.org <ng0>do we set a minimum required GnuTLS version and check for it in guix build? <ng0>maybe your GnuTLS is build somehow that it doesn't cope right with guix. otoh, some parts of the download were rewritten after 0.13 <ng0>how's that next release coming along? will we build another core-updates run before it? <bavier>vpath builds seem to be broken on current master <ng0>dvn-: maybe people are away, on holidays <ng0>can you tell me again what you tried so far and what you started with? <dvn->Honestly I don't remember, because it was about a month ago <dvn->I should just start over <dvn->I built guix from source, and it seemed to be working, until I tried the guix pull <ng0>oh. Guix on something, not GuixSD, right? <dvn->I can still install packages <ng0>does it help if I tell you the current versions guix environment guix (the package guix itself) has? <ng0>was there some kind of well-known bug in the 0.13 release that could cause this when building from source? <ng0>or just an old GnuTLS? <dvn->I believe I have gnutls 3.5.9 <ng0>I'd just reverse steps to the beginning start over and make notes <efraim>I normally use the binary install method and then run 'guix environment guix -- guix pull' <efraim>I find relying heavily on guix environment during installing and updating <mb[m]1>How can I ensure static-networking-service starts after openvswitch? <cbaines>mb[m]1, you'd need to tell shepherd that the static-networking-service requires openvswitch <cbaines>from looking at the service type, this looks to be configurable through the provision argument/field, does that help? <mb[m]1>cbaines: Thanks! Though the provision argument only sets the name, no? I expected to have to change (requirement ...). <cbaines>I agree with you though, if I've interpreted it correctly, it looks really odd indeed <mb[m]1>I extended the <static-networking> record to take a #:requirement parameter, but that didn't work :P <hooverville>hi all. I like the message when I do 'guix package -i something' that says like 'you haven't run guix pull in x days'. is there a way to get that message without running an install command? <cbaines>hooverville, I get it if I just run guix package , or guix package --dry-run <mb[m]1>Ah, it did work, I just had to update static-networking-service to pass it along. Patches incoming :) <hooverville>cbaines: ah, cool. didn't know you could run just guix package, thnx <efraim>ng0: how do you load your packaged vim modules in vim on guixsd? <ng0>via the run time path <lfam>ng0: Do you need help with the go-build-system? <ng0>I have a package which extracts to just a "normal" directory from github <ng0>and the go build fails because of this.. I assume <ng0>I haven't spent much time with it so far <lfam>ng0: I recommend seeing what Go itself does when you build this package. You could try `go install package-name` and inspect the directory that appears at ~/go <ng0>I tried some variations of the unpack path <ng0>I don't understand unpack-path in practice <lfam>Based on what Nix does, I think it should "just work" to clone the Git repo and use the go-build-system without setting #:unpack-path <ng0>from our documentation I mean <ng0>ah.. git. well I use the tarball <lfam>Try reading the code comments in 'guix/build/go-build-system.scm'. Unpack-paths are explained more fully there <lfam>In Go, it's very atypical to use a tarball. <lfam>They language's built-in package management system is based on Git checkouts <ng0>Like I said, I haven't spent much time with it so far. Okay, I thought it's typical to use a tarball when it exists <ng0>thanks, this already helps very much <lfam>In general, yes, but not for Go libraries <lfam>Please let me know how it goes. I'm interested in improving the documentation based on user feedback <lfam>Probably, some of the code comments in that source file could be moved into the documentation <lfam>When I wrote the comment, I was more interested in explaining why the go-build-system does what it does, and I didn't think so much about the documentation in the manual <rekado>hah, this is so old-school! I’m using Guile to talk to Debian’s Debbugs instance via SOAP. (Of course with SXML instead of XML.) <rekado>next step is to write an interpreter for wsdl specifications so that all remote procedures can be generated automatically. <lfam>rekado: Is there a way to view all pending patches with mumi? <rekado>mumi doesn’t really know anything about the status of patches <lfam>Perhaps not all pending patches, but a long list of patches ;) <rekado>it infers the status by sorting all messages and looking for state changes. <rekado>then I could fetch the current patch status for all bugs in regular intervals <rekado>less work would need to be done with mu then. <civodul>rekado: i suppose you could skip wsdl as a first step, no? <lfam>Well, it looks *great* in my browser. Bravo! <rekado>civodul: but that’s the coolest and most over-engineered part of SOAP! <rekado>I just put my test version on berlin <benny>as I was unable to get 0.13 guixsd to install on EFI in a VM I'm now using the VM image, but it lacks a config.scm, would I just write one based on for example desktop.scm? <rekado>hmm, just noticed that “date submitted” is all wrong. <rekado>anyway, it’s just a partial UI demo at this point