<civodul>to check this hypothesis, you should strace the thing that segfaults
<rekado_>there is no segfault. Looks like it's loading Guix pam modules as it should, but this means that the authentication defaults on this system simply fail as the required modules cannot be found.
<rekado_>(as they are not available in the Guix pam)
<rekado_>so I need to try to replicate authentication against ldap without the sssd modules
<rekado_>...or try to hack around with LD_PRELOAD to use the system pam for everything, or use a pam helper that was linked with the system's pam.
<rekado_>so far ABI mismatch is the biggest inconvenience of using Guix on a foreign distro.
<rekado_>I wonder if there's something we can do about this.
<ng0>whoever is working on torbrowser for guix, 6.0 was released yesterday which is based on firefox 45.1.1esr .. I started to work on it for gentoo, maybe it turns out to just work and not need the load of patches the 38.0esr needed
<efraim>does it get patched over time with the patches firefox-esr gets?
<ng0>Ihave to look at it myself. torbrowser ships patches. gentoo provided patches too and then we also sourced another bunch of patches. if you take the vanilla torbrowser only from torproject itself there is no problem
<ng0>as torbrowser tracks esr, it gets the patches esr gets
<rekado_>I like to keep as little as possible on the server, so I only ever copy the compiled artifacts.
<ng0>possibly i should strip the /static/pub/ from it
<ng0>no one cloning the www wants to have all the pub data
<ng0>i'm subscribed to the oss-security list.. should I forward to guix-devel when I notice a package we have, or just directly submit the fixes? I'm still temporarily without guix or guixsd, but I'll either get a new machine for it or use the desktop computer.. or vm..
<civodul>rekado_: re ABI mismatch, i think there's nothing we can do
<ng0>longterm what I plan for guixsd I need an extra laptop.. or more than 1.. concetration on other things
<civodul>rekado_: but there aren't so many problematic cases AFAIK (anything apart from NSS and PAM?)
<civodul>fun: nix-daemon has removed the substituter mechanism, which is now built in the C++ code base
<rekado_>we have similar issues (but less severe) with languages such as R or Python that cannot load modules with native parts linked to system libs.
<rekado_>mixing R libs is fine as long as no native components are involved.
<rekado_>this means that using Guix R one cannot use the "install.packages()" mechanism as these libs could just crash.
<civodul>but yeah, there are other problems like gfortran
<civodul>ACTION pushes a bunch of nix-daemon backports
<jlicht>How does guix calculate sha256 for directories?
<civodul>jlicht: it's the hash of the "nar" serialization of the directory
<civodul>where "nar" (Nix archive) is an archive format as manipulated by 'guix archive'
<civodul>however, you shouldn't have to worry about how it's computed :-)
<jlicht>Let me rephrase in that case: How can I let guix calculate the sha256 of a git checkout, with the .git folder removed? I'm trying to extend `guix download` with git support to make npm-import somehow usable
<jlicht>civodul: but thanks anyways for the proper explanation :-)
<jlicht>and it actually turned out to be just a simple calll to git-fetch in (guix build git), the hash calculation logic from (guix scripts hash) and of course some plumbing in-between to make it work with guix download
<civodul>jlicht: you could do something akin to 'download-to-store', but using 'git-fetch' instead of 'url-fetch'
<jlicht>civodul: exactly what I did. Then I needed to change some things, as guix download expected to deal with a single file everywhere.
<jlicht> ... although I just thought about the `(setenv "GIT_SSL_NO_VERIFY" "true")` in git-fetch. This is an issue, as we do not know the hash yet.
<civodul>yes, but again, authenticating the Git server does not help
<civodul>it's the code that needs to be authenticated
<civodul>well, if you trust GitHub Inc, authenticating github.com still helps
<efraim>I added .tgz to the github updater, fixed the backtrace I was getting
<lfam>Can an upstream source distribution be distributed under the lgpl2.0 but contain some gpl (no version specified) components?
<adfeno>lfam: I guess distributions are "aggregations" under the GPL.
<adfeno>See the latest version of the GPL and the FAQ regarding the licenses.
<adfeno>Optionally, I'm uder a similar situation... And I have emailled the people related to answering licensing questions. I'm still waiting for the answer. Although I'll probably email them again (just in case that the email got lost in transit).
<mark_weaver>(although it should be noted that if there's an entire directory in a profile that contains only files from a single package, then the directory itself is made a symlink instead of the individual files)
<mark_weaver>(the symlinks are made as high up in the directory tree as possible)
<efraim>my first thought when I learned how it worked was "its like stow! but for everything!"
<jlicht>janneke, davexunit: I had a cursory glance at this issue: it seems that our build of npm 6.0 installs a _copy_ of the npm script in `/gnu/store/abcabd-node-6.0/bin/npm`, whereas in 5.10 and earlier, this script is a symlink to the npm script at /gnu/store/abcabd-node-5.10/lib/node_modules/npm/bin/npm-cli.js
<jlicht>I checked, and this npm-cli.js script does indeed work with node 6
<ifur>decided to drop that package for now, it has something called gpt bundled, which is the grid packaging tool released in 2004 where the configure script is in another subdri, so "source/gpt/packaging_tools/configure :)