<apteryx>civodul: o/. About 'guix build -K' implicitly not offloading: is there a way from the command line to have it offload anyway? like, --no-offload=no ;-). I'm using an offloading machine to ease with debugging builds, but having to re-issue 'guix build /path/of/drv -K' on the offload target is a bit annoying :-)
<bavier`>nckx: in 31afa65 you undid some "overzealous substitution"; would you care to fix the resulting build failure? ;)
<g_bor[m]>I now have a working postfix package, just got down to write a service.
<g_bor[m]>I intend to include this in one series, as the package can't be used without the config file, as the path is embedded in the binary.
***apteryx is now known as Guest21047
***apteryx_ is now known as apteryx
<vagrantc>well, i managed to try to build guix by deleting all the patches in gnu/packages/patches, commenting out dist_patch_DATA in gnu/local.mk ... now i just need to patch search-patches to be a no-op ... and maybe my crazy idea of a patchless guix will work
<g_bor[m]>vagrantc: interesting. May I ask what the motivation of doing that is?
<vagrantc>g_bor[m]: gnu/packages/patches has ... unclear licensing ... it's pretty much the last hurdle to include in debian
<vagrantc>g_bor[m]: my goal was to produce a guix that could at least run guix pull
<vagrantc>many of them are just grabbed from upstream...
<g_bor[m]>I don't believe that would just work as is :-) But it would be really useful to identify a core set of packages, that are really needed. There is some invisible connection through implicit inputs...
<vagrantc>the other approach is to do what civodul did with the bootstrap binaries
<g_bor[m]>This reminds me that I have to be more careful when authoring self-standing patches.
<vagrantc>e.g. download them at runtime if not present
<vagrantc>but it seems we can even compile all the .go modules that reference the patches without them
<vagrantc>but a guix built from git ... shouldn't need any of the guix packages no? it should just use guile and guile libraries that it was compiled with?
<vagrantc>per-file is preferred, but not required if there's clear documentation
<vagrantc>alternately, if i could just build guix-daemon without the rest of guix ... that might also be a way to move forward
<nckx>ng0: Fine by me, although I'm not sure how authoritative (if that's the word) such a catch-all file would be. And if it were: we do already have COPYING at the top level.
*nckx off to see how Debian handles this for their own patches.
<ng0>just claiming one license for a patch which wasn't taken from upstream will make it harder to upstream it if the intention to do so arises when the original author is dead or otherwise incapable. guix is young enough to not have this case yet, but this is one problem i see with per-file licenses
<vagrantc>well, a catch-all for upstream licenses would be different for each random project pulled from, and *might* not be compatible with upstream if they're sloppy.
<vagrantc>it's mostly just a sheer numbers problem
<vagrantc>guile can't seem to make use of more than 8 cores when building guix
<ng0>ok, maybe a step back would be where does debian see the problem in the distributed source of guix? or are we talking about more than the distributed releases?
<ng0>since the way icecat or bash etc pull patches is different from the directory
<ng0>that's not arbitrary patches, it's clearly licensed upstream work
<vagrantc>the patch files are certainly licensed under some unknown license which is *presumably* but not verifyably consistant with the license of the project ... additionally debian gets a bit pedantic not just about license, but actual copyright holder needs to be documented
<vagrantc>ng0: clearly would be saying what license it is under and where it came from
<NieDzejkob>following commit a76a343082d61d5303b61a9e4cbde4ab8515a1e7 (currently on core-updates), the patches cmake-curl-certificates.patch and kodi-set-libcurl-ssl-parameters.patch shouldn't be necessary anymore. Could someone familiar with either cmake or kodi test that this is indeed the case?
<jonsger>nckx: don't forget to make the commit messages verbose, so we know what we did today in a year :P
<nckx>2.0 just dies at ‘Unhandled exception’ [freeze], debugging that would have been tedious and useless.
<nckx>jonsger: Yeah, I'm keeping a log but there's already a magical step :-/ The ‘Permission denied’ error I got above just suddenly went away. I think. I certainly don't know what I could have had to do with that.
<ng0>hm, i guess i should do the patch though.. i have a perfectly functional testcase i can reproduce
<ng0>it will be harder to come up with an arbitrary one
<nckx>ng0: Oh, interesting. Blocklists aren't something we should support at all IMO. I must admit I don't really understand what's happening, but that would probably become clear if you explain how you fix it up by hand.
<ng0>this is a Lenovo T60 which ran NetBSD 8.1 before that. NetBSD like I think every other *BSD has its own bootloader.
<civodul>they saw Guix as a tool that could help them have better provenance tracking than with Dockerfiles
<mjw>But for the lawyer the guix concepts are really nice. They are thinking about what it means to make sure to ship corresponding source code for everything we release (which RH does, it is a good company).
<mjw>I don't work on guix for the company though. I just happened to run into one of our lawyers the other day who was indeed pondering containers and products and making sure corresponding source code is always shipped.
<zimoun>mjw, civoldul: zack from SWH told me at FOSDEM that some people use the archive to claim copyright when some projects re-license the ugly way. It is unexpected, I guess, but could interest the good lawyers. :-)
<jonsger>ggaaattyp stands for "GNU Guix as an alternative to the Yocto project". Verbose naming as it's best :P
<zimoun>lewo: cool you are here. Did not know. :-)
<zimoun>lewo: I have tried to read the SWH bug tracker entry, but not able to follow.
<lewo>zimoun: ahah... that's really hard for me as well :/
<lewo>zimoun: but I should meet the SWH team next week. So, i think this will move faster on it soon.
<zimoun>lewo: cool! if you are in Paris and you want to drink a beer, feel free to contact me. ;-)
<lewo>To sumarize, i think all of their comments are addressed. So, it almost ready to be merged. On the NixOS side, since 1 week (WIP), we are exposing a sources.json file (which will be consumed by the SWH lister)
<lewo>zimoun: ah, that would be cool! But I'll not have enough time during my next visit
<zimoun>using the proposed format in the thread, right?
<azymohliad[m]>Hi all. New guix user here. Everytime I run guix it complains about locale (guile: warning: failed to install locale). Could anybody please help me to fix it? I'm on ArchLinux, I have `LANG=en_US.UTF-8` in my /etc/locale.conf.
<nckx>lispmacs[work]: There are two ‘languages’, regular Guile (the default) and ‘bournish’ which gives you a very basic ‘shell’. However, PATH isn't set and even if it were our initrd doesn't have (need) the coreutils/busybox that other distributions traditionally use to script the boot process. So IMO bournish is currently a neat PoC, not a useful tool. The Guile REPL can do anything the initrd needs to do. I sometimes use (mount …) & frie
<nckx>nds to rescue a wonky RAID system. There is no documentation for those procedures besides the docstrings in the code.
<lispmacs[work]>nckx: for inspecting the source of the boot guile, what package should I look at?
<lispmacs[work]>nckx: also, would guix developers want there to be something like a (help) command in the boot guile, if somebody took the trouble, our are they wanting to keep that out for size concerns?