<alezost>paron_remote: I don't use ~/.guix-profile as my default profile; and I set up my environment (in .bash_profile) by calling "guix package --search-paths --profile=.../my-profile" <paron_remote>how do you chang eyour default profile to anything else....? ***Digitteknohippie is now known as Digit
<civodul>but i think i did add a speaker to it <civodul>i've switch the "role state" to confirmed, let's see <civodul>karhunguixi: that did it, thanks for the heads-up! <civodul>i tried to reproduce it on my achine with --rounds=3, and all 3 rounds succeeded <civodul>it's not completely clear which test is failing <civodul>could someone try this from core-updates: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gawk-final)' -K --rounds=3 -s i686-linux <rekado>the new glade fails its three tests, all with errors like this: "libGL error: failed to load driver: swrast" <rekado>I'm starting Xvfb for the tests, but I assume that doesn't support gl software rendering. <civodul>the message doesn't sound related to the X server, though <civodul>i'd interpret it as: libGL tried to dlopen swras.so and failed <rekado>well, the tests do need an X server. "swrast" is for software rendering. <rekado>mesa provides /lib/dri/swrast_dri.so <rekado>and I have added mesa to the inputs. <karhunguixi>civodul, just fyi, your name now shows up for that talk on the volunteers page as well <civodul>karhunguixi: are you part of the FOSDEM org? <civodul>there's a GNU dinner on Friday, if you're interested <karhunguixi>Ah, that would have been great! But i've signed up for the buildup on Friday, and it lasts until 22:00. <davexunit>I hear that the Docker build system uses Docker. <davexunit>but I also hear that it's possible to build another way. I hope that is true. <mark_weaver>words I never expected to hear from him: <davexunit> now we just need Docker ;) <davexunit>much like having pip, bundler, and npm in guix do. <efraim>i have go, haven't started go-build-service yet <davexunit>yeah I have no idea how people build Go applications <efraim>then goroot/bin, goroot/src, goroot/lib? <efraim>all the sources of every project ever goes in (for example) $GOROOT/source/github.com/user/repo <davexunit>er, no, must not be because everyone just statically links everything because fuck it, right? <efraim>everything's statically linked, so its more of a workspace than a library spot <efraim>karhunguixi has it better than me <davexunit>since everything is statically linked, how do you use libraries? <davexunit>do the equivalent of .a files get installed somewhere? <davexunit>and then install the binary somewhere for software that uses it to link against? <davexunit>I'm wondering if it's roughly equivalent to .a files that gcc would produce. <karhunguixi>imported code goes in $GOPATH/src/github.com/user/project <davexunit>I'm worried that the "Go way" is to bundle the source code of all dependencies, rather than do something sane. <davexunit>this further confirms that Go is a complete joke. <davexunit>so the norm is to just bundle all dependencies? <davexunit>how will us Guix maintainers handle security updates? <karhunguixi>yes, all dependencies are included in the executable <davexunit>karhunguixi: I'm not talking about the executable <davexunit>does Go software bundle all of the dependencies in the source tarball? <davexunit>if so, this poses a really bad problem for us. <davexunit>because it means that there is no reasonable way for us to stay on top of security vulnerabilities. <efraim>i think it's like python that you say "i want that" and it's downloaded during the building <davexunit>downloading during building is the worst thing possible <davexunit>luckily, the python build system won't do this the way we've configured it. <davexunit>python projects also doesn't bundle the source code of their dependencies <davexunit>which is a *HUGE* maintenance burden for us. <davexunit>if true. maybe there's a way around this. I'm pretty ignorant here. <efraim>bundled source, recent commit is "update dependencies" <davexunit>we should see what other distros have done about this. <efraim>i'm still hoping we can treat it like a cross between python and a package with bundled sources <davexunit>we need to figure out if we can automatically remove the bundled libs <davexunit>and replace them with stuff we manage explicitly <davexunit>so that we can propagate, say, a security fix. <piyo>hello I'm getting this error after guix pull --verbose: guix pull: error: fport_fill_input: Connection reset by peer <piyo>this is on a raspberry pi 2, debian jessie. <mark_weaver>piyo: sounds like a network problem, or possibly that savannah is overloaded. I would try again. <efraim>is there a reason I wouldn't want to build with the most recent version of go? <piyo>Okay. It was like that 8 hours ago tho. <efraim>before I rip out all the python2 conversion stuff? <piyo>Also will adding --no-substitutes to my guix-daemon start help with this problem? <efraim>you need to hit hydra for guix pull <mark_weaver>piyo: I would try again now. if the problem persists, please let me know. <taylan>I'm being told the normal way to do things in Go is that when your code contains e.g. import("github.com/foo/bar"), the build toolchain fetches the sources for that transparently. (I guess Go folks don't normally care much about building software in a restricted environment, dunno.) <taylan>maybe we could create a "go-foo-src" package for each "go-foo" package, use such source packages as inputs to go packages, and arrange for the toolchain to use locally provided sources instead of fetching them. <taylan>(I just talked to my Go-using coworker a bit to reach this idea, not a Go expert at all.) <taylan>efraim: davexunit: AFAIU Godep is a non-standard dependency management tool for Go <efraim>after having compiled go itself, it looks like every package has its source bundled with it, so we just have to extract it into its location <efraim>and by that I mean that's the only thing go related I've ever compiled :) <efraim>taylan: oh good, don't need to worry about it quite yet <taylan>maybe we could simply remove any "Godeps" directories in the sources in our build recipe (maybe even as part of the go build system), and then do our own thing as usual. <rekado>have you checked what Nixpkgs is doing for Go packages? <efraim>only checked as far as building go itself <piyo>mark_weaver: I still get a problem: now it shows The following derivations will be built: <piyo>a whole lot of *.drv listings <piyo>then the same guix pull: fport_fill_input: Connection reset by peer. <mark_weaver>does anyone else see this? I never use "guix pull" myself. <mark_weaver>it could be caused by an intrusive firewall on your end. I've been behind firewalls that reset my TCP connections. <efraim>I guix pull sometimes, don't normally see too much .drv stuff <taylan>I only see /gnu/store/1ixqchvbwvndskds5farphlx5bvngsi1-guix-latest.drv ATM <efraim>did you add hydra's public key to /etc/guix/acl <civodul>piyo: could you paste the whole output of 'guix pull'? <davexunit>rekado: yeah, we need to look at what the Nix folks did. <karhunguixi>taylan, Go won't fetch sources transparently, you need to grab them explicitly, like "go get github.com/foo/bar" <davexunit>I'm not overly optimistic, given the other less-than-rigorous solutions we've seen <taylan>karhunguixi: I've been told the toolchain does this when building code that contains e.g. import("github.com/...") <efraim>import {github.com/user/project, github.com/user2/otherproject...} <davexunit>civodul: the new build? I'm very excited about the much faster build. thanks taylan <civodul>davexunit: 'guix pull', but the new build is the same <taylan>karhunguixi: maybe it was a miscommunication then, I didn't test it <civodul>mark_weaver: i blame civodul for not fixing this bug in the offload thing, and then pragmatically restart the build :-) <mark_weaver>usually when I've seen errors about .drv files not existing, I've found that a rebuild wouldn't fix it, but maybe this is a different case. <davexunit>rekado: as I read this file I am glad that we don't use bash for build scripts <mark_weaver>civodul: hmm, I just found three more builds with the same kind of error about a missing .drv file. this seems like a new problem to me. <mark_weaver>I've spent a lot of time restarting failed builds on hydra, but haven't come across this problem except when we've done a GC after an evaluation but before the builds were completed. <piyo>Okay for one thing I was routing http requests through Privoxy, which may have rewritten content (not good). Now that I am just rerouting through squid3 and I seem to be progressing with some guix pull halts. The current guix pull process seems to be downloading with no problems. <mark_weaver>davexunit: thanks for the heads-up. I'm updating the package now <piyo>I also have another foreign Guix on x86_64 and I did not encounter this problem even with Privoxy active. I need to whitelist hydra... probably. <taylan>karhunguixi: I think it was just a miscommunication with my coworker (he isn't around to ask ATM) <taylan>either a simple strategy of defining source objects and using them as inputs to go packages should work, from what I can tell. <saml>if you want to open source your Go library/application that does a lot of import "yourcompany.com/some/pkg" .. or change source hosting, you need to modify all your imports <saml>or instruct users to download your source at different directory <piyo>I looked at my Privoxy log and I don't see any lines regarding guix servers (gnu.org). I cannot yet confirm that it is the actual culprit but hey, I'm compiling .scm's now. <karhunguixi>davexunit, maybe saml here can help answer some of your Go questions <davexunit>taylan: I think a simple thing like that might work <davexunit>taylan: using packages that are just source code sounds like a good idea, then our Go build system could symlink the code into the correct place <taylan>davexunit: packages that are just source, or just source objects; I had forgotten that the latter can also appear in the inputs of packages <davexunit>taylan: yeah, either way. an origin object could work just as well. <taylan>oh right, source fields tend to contain origin objects <saml>thought it was guile linux <taylan>saml: nah, we just package all the things <davexunit>now we're debating about how we can package software written in Go <saml>you don't distribute binary packages? <karhunguixi>saml, Guix is a functional package manager, GuixSD is a distribution <saml>programs written in Go is statically linked single executable <davexunit>saml: a "package", in Guix terms, is a recipe for how to produce a binary from source code. Our hydra.gnu.org build farm provides the results of these builds. <saml>Go does not have agreed upon way of building projects, yet. <davexunit>the issue we're most concerned with right now is that Go projects seem to bundle all of the source code of their dependencies in their source trees <taylan>davexunit: AFAICT that's not the norm <davexunit>which is a) a huge security issue and 2) a huge duplication issue and thus a huge maintenance issue for us. <saml>yah that is one way to have the project re-buildable (by different developers) <taylan>the norm seems to be that your local directory hierarchy contains e.g. $workspace/src/my-app which is a git repo and then dependencies are put in $workspace/src/<dependency>, i.e. alongside the git repo that contains your app's source <davexunit>taylan: how is this different from bundling? <taylan>davexunit: the src/ directory isn't published, only src/my-app <taylan>well, presumably. it doesn't really talk about publishing/distribution on that page. <davexunit>taylan: how does one link against the compiled static objects of dependencies? <davexunit>this is the part I don't understand. with GCC and C, one would just use a search path for .a files and tell GCC to link against them. <rekado>fighting with a custom build system written by what appears to be an arrogant programmer (comments in the configure script call Fedora practices "retarded" and the like) <taylan>davexunit: I think one runs 'go get github.com/foo/bar' in the workspace, which creates $workspace/src/foo/bar, so one ultimately has the source code of the dependency in one's workspace <davexunit>taylan: okay, so we could create a 'go-get' origin download method <saml>what i personally doing is GOPATH="$workspace/src/project1/vendor:$workspace" so that project1 can have its own dependencies if it needs to use different version than $workspace/src/dependency1 <davexunit>saml: wait, a single executable can include different versions of the same library? <saml>Given, $workspace/src/project1, $workspace/src/project2@v1 and project1 depends on different version of project2, i put that in $workspace/src/project1/vendor/src/project2@v2 and prefix GOPATH with "$workspace/project1/vendor:$GOPATH" when i'm building project1 <davexunit>which leads to a single piece of software using N different versions of the same library <davexunit>what happens when a security vulnerability occurs? <davexunit>these developers are multiplying the surface area of vulnerable code <saml>probably i'm wrong.. at least java this isn't possible, i think. class loader can load only single version of com.google.Foo class <saml>i think so.. cause it's not runtime linking. <saml>but i didn't test. don't listen to me on this <davexunit>that article better have a picture of the Go gopher <saml>i guess myapp could be loading /usr/lib/libfoo.so.1 while myapp2 is loading /usr/lib/libfoo.so.2 <saml>but in case of statically linked Go, myapp contains libfoo.so.1 myapp2 contains libfoo.so.2 <rekado>(I'm so glad that this is done much more nicely, for the most part, with Guix & Nix.) <saml>and libfoo.so.1 depends on libbar.so.1 and myapp also depends on libbar.so.2 . in the end myapp contain both libbar.so.1 and libbar.so.2 <saml>i don't know. so complicated. i delete and give up <karhunguixi>in Go you usually share dependency sources, but if you really need it you can keep a specific version of a dependency in one project <davexunit>karhunguixi: does that mean that 2 versions of the same library cannot be linked into the same application? <karhunguixi>davexunit, as i understand it it should be possible, but you would need to give them different names <davexunit>karhunguixi: okay, that's different than I what I thought was happening. <davexunit>you can't literally use two conflicting versions of a library <karhunguixi>no, because you refer to a dependency by the projects name <HotLava>is the go compiler actually producing .elf files for the intermediate steps, or do they have their own file format? <karhunguixi>don't know. Someone in their channel said no to elf files, but was unable to elaborate further <civodul>davexunit: no, i didn't give any ;-) <civodul>it's about how Nix deals with Python libs, search paths, etc. <civodul>it seems that it doesn't provide much support <davexunit>I was going to say, the guix equivalent of the OPs commands should work just fine <davexunit>(provided you set PYTHONPATH, which 'guix package' will kindly tell you about) <HotLava>so it's a custom file format, only documented in cmd/internal/obj/objfile.go in case someone is interested <HotLava>and all symbols are versioned by default, so in theory it should be possible to link different versions of the same library together <bavier>davexunit: you mentioned a while back not being able to interrupt commands issued inside `guix environment --container`, do you recall what your fix was? <davexunit>bavier: I don't recall having a fix. I'm having trouble recalling that I mentioned this at all. :) <davexunit>I have trouble interrupting commands in general <bavier>I'm only seeing this in a guix container <davexunit>it's frustrating, but I have no idea where the problem lies. <davexunit>bavier: there's some terminal stuff that we're not setting, I think. <davexunit>bavier: when you C-c, do you see anything print out? <davexunit>I think I recall pressing TAB doing weird things <bavier>ah, there we go, hit it at just the right time <davexunit>paron_remote: Stripe is switching to GuixSD? ;) <paron_remote>davexunit: no, I verified that if I built the current system of guixsd with the older linux kernel <paron_remote>that I don't have the reading the hardware clock problem on my x220 <paron_remote>but at least it seems like we've narrowed to *what* now :) <davexunit>paron_remote: but please, do not forget why I personally sent you to Stripe for 3 months. :) <paron_remote>davexunit: I will be giving talks on Guix while here, at stripe and elsewhere.. <paron_remote>davexunit: speaking of, looking forward to hear how your guix talk goes <davexunit>paron_remote: I guess you can play the kernel bisect game now... <davexunit>paron_remote: I have to work on it a lot over the weekend <davexunit>paron_remote: maybe knowing it's a kernel issue is enough for the libreboot devs to figure it out. <paron_remote>also, I'm surprised to notice that procmail is not packaged! <paron_remote>davexunit: I'm glad civodul gave the appropriate troll so I didn't have to <paron_remote>aeva: btw I pinpointed the guixsd thing to being a kernel verison <paron_remote>I have a config file you could use if you want the latest guixsd but with keeping the old kernel about <aeva>paron_remote the date thing or the gl slowness? <aeva>and either way, I would love to see your new config! <aeva>well, butts. still want though :) <paron_remote>because I just copy-pasta'ed the 0.9.0 linux-libre definitions in there <paron_remote>there's a more efficient way to do a derived verison of a package <paron_remote>but this was fast and furious verifying that it was the kernel version :) <paron_remote>there are almost certainly more modules imported than necessary there too <paron_remote>aeva: but hey, you can step out of 1969 into the modern era again! <bavier>anyone here know offhand about the Mozilla Public License 1.0 and its freedom status? <bavier>I've already sent the developers a request to update the license, but in the meantime, it'd be nice to share the package definition <bavier>the 1.0 specification is in the source <bavier>mark_weaver: yes, but there's ambiquity in whether they're referring to 1.0 or 1.1, or both, since they only specifically mention 1.1