<ng0>hey, efraim. I read there are some issues left with the mate patches? Maybe it's easier if you could throw me the issues here.
<ng0>cbaines: I think it's safe to say at this point that you mail never arrived at my postbox, or did you get a message that it couldn't be delivered? I still have hope that it's just "stuck" somewhere, but UK -> DE isn't that much of a distance
<ng0>maybe the sorting "machine" picked it out for themselves
<ng0>efraim: but the mate-icon-themes problems has to be older than my work, I didn't add it I think.
<cbaines>ng0, that's irritating. On the bright side, I have some more sticker sheets now, as I got some more printed before the GHM.
<ng0>Maybe I'll be at CCC congress (hope I can make it) or at Fosdem next year.
<ng0>The sorting "machine" in-joke is a bit annoying.. you really have no way to blame the Deutsche Post when the mail gets lost on the way unless there's an insurance on it and even then you could have problems. -.-
<efraim>I think there might be a scheme based reason that I don't remember
<ng0>I think I'll comment inline in the email, it's easier. the format works better than last time, I just have to move the code around and rebase with your changes. I think there are 1 or 2 patches which are individual contributions you made/found. Would you like to add them after "mate"?
<ng0>there's nothing to comment though… just the one or two patches you made which are not part of my patch set
<ng0>I prefer it when people get their name as authors
<efraim>I pushed a couple of the patches, I don't remember which ones would be mine though
<ng0>all in all looks good so far, now I just need to shove code around and build a system on this
<Steap>should all my glibc and gcc patches be removed as well?
<lfam>ACTION goes crazy trying to figure out the fine points of Golang package references
<lfam>They have a concept of "internal" packages that may not be referred to by packages under a different namespace. But they offer a mechanism to short-circuit that: vendoring (aka bundling). So package authors have created so-called internal packages separately from the packages that are supposed to use, presumably under the assumption that everyone will bundle them :(
<Steap>because ld seems to try to open crti.o from those places
<lfam>Go is generally a bad fit for our way of doing things. There is no concept of "versions", and not even a strong concept of a coherent software release. It's typical to cherry-pick parts of a given Go library suite
<lfam>I guess we'll see how we should adapt as we try adding more Go software
<lfam>I haven't seen any top-level build scripts in these library suites; you're expected to build each module individually as needed
<oriansj>if every module is built as individually needed, simply don't seperate them into seperate things.
<oriansj>statically compile the programs and the libraries into a single blob
<oriansj>it'll waste disk and probably make a build issue whenever a security bug needs to be fixed but it looks like go took the java route of bad system engineering
<lfam>I've considered that but it would require a substantial amount of extra logic on our side, and it's not "idiomatic" for Go.
<lfam>I think I may have to go back to the original plan, which is to create a symlink union of all the Go dependencies at build-time. Since the GOPATH variable can contain multiple entries, I'd hoped to avoid that, but the multiple entry GOPATH seems to be only partially supported in practice