<Apteryx>quiliro, adfeno: IIRC you cannot currently have both python2 and python3 in the same profile. Installing Python3 is seen as an "update" to Python2... Which is true in a very strict sense, but not very useful in practice where Python2 and Python3 are both still in (con)current use.
<lfam>quiliro: I created a new bug about your mozjs build failure. It's not related to the original bug report which I had closed
<quiliro>lfam: perhaps it is not a problem with mozjs
<lfam>The 2nd problem is not really specific to `guix system reconfigure`. It's a problem with building the mozjs package. Building the mozjs package happens when you run `guix system reconfigure` because your system uses mozjs
<Apteryx>Hmm... I'm fixing guile-lib ATM and hitting gnutls-error (this is a recurrent theme it seems). One way I can trigger this is by running "guix lint".
<lfam>Apteryx: Is gnutls-guile (from the gnutls package) available in your environment? Does the error go away with `guix environment --ad-hoc gnutls`?
<Apteryx>lfam: Good guess! I experienced the error in "guix environment guix". Just to be sure I re-ran "guix lint guile-lib" in my normal profile (not environment), and I get the same error. I'm using GuixSD.
<lfam>By good guess, do you mean that you can fix the issue by adding gnutls to your environment?
<Apteryx>No, I meant it could have well been this, but helas it doesn't seem to be...
<jmd>I think you're right, but that's an internal detail. Batman is a bgp implementation I think.
<ng0>i'm not sure (anymore) about the technical details of freifunk.
<ng0>some years ago I looked into it, then störerhaftung was still a thing, and now that störerhaftung law is almost gone, and we're about to switch the ISP contract I can offer freifunk
<ng0>I'm just trying several guixsd server scenarios out at the moment, so I can document them.
<jmd>How about giving us a talk about it at GHM this year?
<ng0>I'd rather talk about my blend of GuixSD, as I was asked about it often.. but I think GHM falls into a bad time. I'd like to go, but university starts around that time iirc, and currently I'm trying to figure out financing, legal details, etc.
<adfeno>Note: I told about radio regulations in Brazil because I thought that Freifunk was similar to Netsukuku, because I vaguely saw messages similar to "connecting to each node", so I assumed it was through radio signals.
<ng0>at the end of 2016 iirc a temporary success was made and only parts of störerhaftung still apply
<ng0>well it is radio.. but the 2.4GHz frequency iirc
<balduin>how do I define the license of a package as mit?
<ng0>there is no MIT :) it could be expat.. or some other commonly mistaken license
<ng0>it's a very common used mistake by developers
<adfeno>It used either Expat license, or the X11 License.
<adfeno>The later one only has a trademark notice at the bottom that says that theX11 license is just a license, and doesn't imply that the licensed work itself is from X11 project. While the Expat license has no such last paragraph.
<rekado>I use debbugs with mu4e. Needed to patch debbugs-gnu.el.
<rekado>I prefer using debbugs over just working with the mails directly.
<ng0>adfeno: in some domains (cities/communes) there's a big overlap of amateur / citizenband radio operators and the freifunk meshnetworking community. One example was Göttingen, where when the CB community discovered freifunk increased the community by 50% or something
<rekado>I consider unsubscribing from guix-patches. I’d just access the reports via debbugs then.
<ng0>this rewriting, as written in the bug, doesn't work out for gitolite-admin though
<ng0>my idea is that a gitolite service would have a user "git" and that it would have the major group "git-daemon" (or be part of "git-daemon" in addition to "git"), making /srv/git accessible to this, and that user "git" would have a guix-profile where perl is available
<Apteryx>sneek: Later, tell gnu_guix: About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug bug it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead.
<adfeno>gnu_guix has no registry in NickServ, so we cannot use MemoServ to send memos to him/she.
<Apteryx>sneek: later tell gnu_guix, About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug about it but it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead.
<Apteryx>Actually, the only thing confusing about the python-test branch was that master was "merged" into it rather than rebased, so we get noise commits such as "Merge branch 'master' into python-tests". No big deal, but please "git pull --rebase" instead of "git pull (--merge)" in the future to prevent that.
<jmd>When is that madman civodul going to pop up again?
<efraim>If we rebase then all the commits have to be signed again
<alezost>mekeor: re "M-x guix-system-generations" error: if "M-x guix-version" tells "Emacs-Guix 0.2.2", you need to update it to 0.3
<adfeno>I asked how nekoc and nekoml relate to it in terms of dependency.
<adfeno>And yes, when writting the email, I remembered that the GPL has an exception for "mere aggregations".
<lfam>Apteryx: I agree with efraim. We should not rebase unless there are only a few commits. It's important to preserve the signatures
<lfam>The signatures are the only thing that tells us who pushed the commit to the central repo. If we start rewriting signatures between branches on a large scale, it will become confusing to know who pushed what code.
<Apteryx>efraim: OK, thanks for reminding me that signatures are lost when rebasing.
<Apteryx>lfam: Right. I had not considered signatures. Thanks for reminding me about it.
<lfam>I agree that merge commits can be confusing, to say the least
<adfeno>I just have an idea on what can be causing people not to be updating their copy of guix-daemon.
<lfam>There was no reason to embed the /gnu/store path regardless of whether or not the service manager allowed symlinked service files
<adfeno>Also, the same might happen (outdated guix-daemon) if the user who install Guix-daemon mistakenly copies the service file instead of symlinking.
<lfam>The service file should always execute the guix-daemon in root's profile.
<adfeno>As a correction: It only happens with COPIED service files,.
<lfam>Then, it doesn't matter if the file is a symlink or not
<adfeno>Apteryx: I'll double-check if I'm really running guix-daemon htrough Upstart. But I'm pretty sure I am.
<Apteryx>adfeno: Haha, what I tried actually was this: copied service files to /etc/init/guix-daemon.init or something like this. Then I tried rewriwing the /gnu/store absolute uri in the file to point to a symlink in /var/guix/profile/... or something like this. And this was failing using upstart. Maybe using an actual symlink for the service file itself is supported, I'm not sure.
<Apteryx>I would have think I would have tried that as well; I don't remember for sure but it's been some time.
<Apteryx>lfam: Would the service file copying to the right place be automated? If not, we'll still have users who won't know/bother manually copying there.
<lfam>Apteryx: It's a documented installation step in the manual. If they don't copy (or link) the file into place, then they aren't going to use Guix at all :)
<Apteryx>I'm thinking it's not easy to get this automated since you can't rely be sure about the system (unless it's guixSD).
<adfeno>lfam: I do agree that we must change "/gnu/store" references in service file to "/root/.guix-profile/" references instead.
<lfam>I prefer '/var/guix/profiles/per-user/root' instead of '/root/.guix-profile', because it avoids looking in a protected directory, which may or may not work
<Apteryx>lfam: OK. I thought we were considering the "guix-daemon" update issue. I think the file itself keeps a hard coded reference to the guix-daemon location. And changing this reference to a symlink might not work on upstart (IIRC).
<adfeno>My upstart service is working, updated guix-daemon because the service file is symlinked
<adfeno>(I have done the symlink per the Guix installation documentation).
<lfam>Please test using a version of upstart that is widely deployed. The reason we had a problem with systemd is that we didn't test against "stable" distros like Debian Jessie, so we didn't notice that support for symlinked service files was not yet common
<Apteryx>Currently, this laptop is configured using a guix-daemon.conf file which was *copied* to /etc/init/guix-daemon.conf (I think this follows the manual).
<lfam>We tested on things like Debian unstable, which have the latest systemd
<Apteryx>lfam: When using "guix build --check --no-grafts python2-urwid", I get: some outputs of '/gnu/store/d3nn0j....jn2-python2-urwid-1.3.1.drv' are not valid, so checking is not possible. What does this mean?
<lfam>Apteryx: You have to build once before you can --check it
<lfam>Apteryx: I disagree that it's a very high standard :) We do much less testing than distros like Debian and Red Hat
<ng0>and there's no form like for packages I've seen in fedora
<ng0>they have standardized package inclusion procedures I think
<Apteryx>I guess we're just sloppy at work then ;) Most of the burden of test is put on the submitter/continuous integration tests. The review process itself is focused on the actual code changes, not testing.