IRC channel logs


back to list of logs

<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"
<alezost>ACTION is also --> Zzz.
<paron_remote>what waiiiiit
<paron_remote>how do you chang eyour default profile to anything else....?
***Digitteknohippie is now known as Digit
<civodul>Hello Guix!
<karhunguixi>civodul, are you, or do know who, is giving this talk?
<karhunguixi>it doesn't have a speaker connected to it
<civodul>it's me!
<civodul>but i think i did add a speaker to it
<karhunguixi>it doesn't show for me at least
<civodul>yeah, weird
<civodul>i think i fixed it once
<civodul>in Penta i'm marked as speaker
<civodul>i've switch the "role state" to confirmed, let's see
<civodul>karhunguixi: that did it, thanks for the heads-up!
<karhunguixi>yes nice, i see it to :)
<karhunguixi>the page hasn't taken it yet, but maybe it will later
<efraim>what happened to core updates?
<efraim>it looks like i686 failed
<civodul>efraim: yes:
<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>seems to be 'fts'
<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
<civodul>ah wait
<civodul>with this patch:
<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.
<rekado>it's just three tests.
<civodul>the message doesn't sound related to the X server, though
<civodul>i'd interpret it as: libGL tried to dlopen and failed
<civodul>(but i known nothing about libGL)
<rekado>well, the tests do need an X server. "swrast" is for software rendering.
<rekado>mesa provides /lib/dri/
<rekado>and I have added mesa to the inputs.
<civodul>the 2nd patch at looks interesting
<karhunguixi>civodul, just fyi, your name now shows up for that talk on the volunteers page as well
<civodul>cool, thanks for checking
<civodul>karhunguixi: are you part of the FOSDEM org?
<karhunguixi>no, i'm just volunteering
<civodul>so we'll meet there!
<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>ACTION pushes docker-compose patches
<davexunit>now we just need Docker ;)
<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>it will provide a means of transition
<davexunit>much like having pip, bundler, and npm in guix do.
<efraim>i have go, haven't started go-build-service yet
<karhunguixi>efraim, nice! :)
<davexunit>yeah I have no idea how people build Go applications
<davexunit>I'm guess they don't use regular Makefiles
<davexunit>because they are too cool
<efraim>there's a goroot
<karhunguixi>"go install" or "go build" is what you use
<efraim>then goroot/bin, goroot/src, goroot/lib?
<efraim>all the sources of every project ever goes in (for example) $GOROOT/source/
<davexunit>is $GOROOT a real env var?
<davexunit>like GUILE_LOAD_PATH?
<davexunit>to load libraries and such?
<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
<karhunguixi>$GOPATH is where your workspace lies
<efraim>karhunguixi has it better than me
<davexunit>what's a workspace?
<efraim>I was going to use and as references
<davexunit>the root of the source tree?
<karhunguixi>in $GOPATH you have src/ bin/ and pkg/
<davexunit>since everything is statically linked, how do you use libraries?
<davexunit>do the equivalent of .a files get installed somewhere?
<davexunit>for the go linker to use?
<karhunguixi>you grab the source and build it
<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/
<davexunit>I'm worried that the "Go way" is to bundle the source code of all dependencies, rather than do something sane.
<sneek>I'll keep that in mind.
<davexunit>karhunguixi: I was afraid of this.
<karhunguixi>then when you build your executable ends up in bin/
<davexunit>this further confirms that Go is a complete joke.
<davexunit>so the norm is to just bundle all dependencies?
<davexunit>is there even a way to not do that?
<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>I'm talking about the source tarball
<davexunit>does Go software bundle all of the dependencies in the source tarball?
<davexunit>if so, this poses a really bad problem for us.
<karhunguixi>i don't know about this
<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>efraim: we do not do this
<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.
<efraim>i know
<davexunit>python projects also doesn't bundle the source code of their dependencies
<davexunit>which it seems Go does
<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> see Godeps/_workspace/src/
<efraim>bundled source, recent commit is "update dependencies"
<davexunit>we should see what other distros have done about this.
<davexunit>this is really really bad.
<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 after 9.7MB transfered from: From
<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
<efraim>so it wouldn't help for this
<piyo>;-) oops.
<mark_weaver>efraim: s/hydra/savannah/
<mark_weaver>but yeah
<efraim>er, yeah
<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(""), 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.
<piyo>Okay retrying now.
<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.
<civodul>ACTION tries
<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>works for me™
<civodul>piyo: could you paste the whole output of 'guix pull'?
<civodul>damn, this thing is fast
<civodul>thanks taylan :-)
<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"
<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("")
<efraim>import {,}
<davexunit>civodul: the new build? I'm very excited about the much faster build. thanks taylan
<rekado>I don't see anything special in here:
<mark_weaver>civodul: what do you make of this?
<civodul>davexunit: 'guix pull', but the new build is the same
<karhunguixi>taylan, i don't think this is correct.
<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 :-)
<civodul>but you could do better ;-)
<mark_weaver>heh, okay :)
<karhunguixi>taylan, i'll test it when i get Go installed here
<karhunguixi>taylan, but it sounds weird for sure
<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
<davexunit>so much more readable
<rekado>me too
<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.
<davexunit>OpenSSH client CVE
<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.
<mark_weaver>ACTION looks
<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>piyo: that's good!
<karhunguixi>taylan, i guess you were talking about goimports.
<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)
<karhunguixi>taylan, ok
<taylan>either a simple strategy of defining source objects and using them as inputs to go packages should work, from what I can tell.
<taylan>either way*
<saml>if you want to open source your Go library/application that does a lot of import "" .. 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 ( 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
<mark_weaver>davexunit: openssh update pushed
<davexunit>mark_weaver: you're fast!
<mark_weaver>so are you :)
<davexunit>(I read too much Hacker News)
<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.
<mark_weaver>bah, I blindly copied the CVE number from <>, and didn't notice that they made a typo (0216 instead of 2016)
<davexunit>so probably origins
<davexunit>mark_weaver: :(
<mark_weaver>oh well, no fixing commit logs
<davexunit>yeah, it's okay.
<taylan>oh right, source fields tend to contain origin objects
<davexunit>what's done is done.
<saml>guix is Go linux?
<davexunit>I can't parse that question
<saml>thought it was guile linux
<taylan>saml: nah, we just package all the things
<davexunit>saml: efraim here has created a Go package.
<davexunit>now we're debating about how we can package software written in Go
<saml>the Go compiler?
<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 build farm provides the results of these builds.
<davexunit>saml: yes, we've realized this.
<saml>oh i see
<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.
<mark_weaver>that typo has been propagated to other places as well, e.g.
<saml>yah that is one way to have the project re-buildable (by different developers)
<davexunit>taylan: oh?
<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?
<davexunit>I'm missing something.
<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' 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
<davexunit>to fetch that stuff
<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?
<davexunit>I'm having a hard time understanding.
<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
<saml>sure why not?
<davexunit>that's terrible.
<davexunit>this happens in Node.js, too
<saml>maybe i'm wrong
<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
<davexunit>and paying no mind to it, apparently.
<saml>probably i'm wrong.. at least java this isn't possible, i think. class loader can load only single version of class
<davexunit>saml: but in Go it is possible?
<saml>i think so.. cause it's not runtime linking.
<saml>but i didn't test. don't listen to me on this
<davexunit>I'm curious.
<davexunit>that article better have a picture of the Go gopher
<davexunit>or better yet, the Node.js logo
<saml>i guess myapp could be loading /usr/lib/ while myapp2 is loading /usr/lib/
<saml>but in case of statically linked Go, myapp contains myapp2 contains
<rekado>(I'm so glad that this is done much more nicely, for the most part, with Guix & Nix.)
<saml>and depends on and myapp also depends on . in the end myapp contain both and
<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
<NiAsterisk>rekado: awesome, thanks for fixing glade3 :)
<davexunit>karhunguixi: okay, that's different than I what I thought was happening.
<davexunit>that would require essentially a work
<davexunit>you can't literally use two conflicting versions of a library
<karhunguixi>no, because you refer to a dependency by the projects name
<davexunit>karhunguixi: okay, thanks. that helps.
<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>rekado, davexunit: regarding Python stuff:
<davexunit>civodul: am I missing context?
<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
<civodul>except when using nix-shell
<davexunit>I was going to say, the guix equivalent of the OPs commands should work just fine
<civodul>yes, i think so
<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
<davexunit>I can't C-c a lot of things
<davexunit>guix commands, make, etc.
<bavier>hmmm, ok
<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>just a '^C'
<bavier>ah, there we go, hit it at just the right time
<paron_remote>good news, everyone!
<davexunit>paron_remote: Stripe is switching to GuixSD? ;)
<paron_remote>davexunit: ha
<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
<davexunit>paron_remote: ah! regression, ahoy!
<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: haha
<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...
<paron_remote>davexunit: ahhhh
<paron_remote>davexunit: do I have to :)
<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>yeah maybe
<paron_remote>also, I'm surprised to notice that procmail is not packaged!
<paron_remote>guess I'd better package it
<davexunit>please do :)
<paron_remote>davexunit: I'm glad civodul gave the appropriate troll so I didn't have to
<paron_remote>"Cool, I’m glad you’re bringing Docker to Guix! ;-)"
<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
<paron_remote>. o O (Meanwhile I should update that bug!)
<aeva>paron_remote the date thing or the gl slowness?
<aeva>and either way, I would love to see your new config!
<paron_remote>aeva: the date thing
<aeva>well, butts. still want though :)
<paron_remote>aeva: so it's a pretty hacky config
<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>again, has to do with my quick-hack version of things
<paron_remote>aeva: but hey, you can step out of 1969 into the modern era again!
<aeva>:O! I can ssl! :O
<bavier>anyone here know offhand about the Mozilla Public License 1.0 and its freedom status?
<paron_remote> it's free
<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
<paron_remote>I meant
<paron_remote>you said 1.0
<paron_remote>yeah I've never seen 1.0 in real life :)
<paron_remote>where is that?
<bavier>the 1.0 specification is in the source
<mark_weaver>bavier: I see many references to MPL v1 in and they seem to indicate that it's a GPL-incompatible free software license.
<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
<mark_weaver>e.g. says "This is essentially the same as the Mozilla Public License version 1: a free software license incompatible with the GNU GPL."
<mark_weaver>and MPL v1.1 is listed:
<mark_weaver>over 2000 failed builds on core-updates, due to automake failures: