<ng0>would be great if they'd unbundle it, move it to an dedicated git, so that if more than 1 application uses tinyscheme we could have tinyscheme base and then all the tinyschemes which have their own altered sources
<ng0>"I'll do it." peter hopefully forgot i was on the side of the people he assumed to have an political discussion with when it was just blockhead vs reason.. but this is outside of code contribution, hopefully it does not affect what I do, as I gave up very early to discuss with peter about this.
<ng0>vlegoll: i'll just try and contrib the trivial things.. I created issues to close for now
<ng0>i have forgotten how to ssh clone with github... I'm used to much simpler systems I have myself
<sneek>lfam, civodul says: nice work on the sourceforge story\\
<kristofer>lfam, thanks! I have used jack/ardour/hydrogen/calf-plugins for years, but I just got a new audio interface and I can't figure out why it won't duplex
<lfam>Unfortunately, I haven't used JACK in a long time, and that was on OS X. But, I want to get back into music , and I want to use a GuixSD based audio workstation, and of course that will require JACK.
<ng0>rebasing on core-updates-next is not going well
<ng0>master on core-updates-next because I'm doing libgcrypt,gnupg,gpg-error updates
<lfam>IIUC, we can't rebase master on anything, because it causes the history to be rewritten. Instead we use merges. And yes, in my experience there are always some conflicts that require manual intervention, which can be hard
<ng0>i see. rebase origin/core-updates-next is not recommended?
<lfam>For generating patches, I think it's okay. And of course, if something goes wrong, you can always check out from origin/master again.
<ng0>git checkout master ; do some work, commit; rebase origin/core-updates-next is what i am doing now i think. I think, because i solved 3 things at the same time
<ng0>annoying. but it gives me practice with ediff
<bombastus>I'm following the guix manual trying to install guix from a usb drive. After I run 'herd start cow-store /mnt' I get the error: '/run/current-system/profile/bin/<command>: no such file or directory' whenever I try to invoke a command... I've tried changing my path to no avail and I haven't been able to find any documentation on the cow-store service. Any ideas whats going wrong?
<ng0>i have no idea if gnupg.scm has my name change in some of the core-updates branches, so I just leave out the name completely for now and add it once one of them introduced back a name if it happens. I'll also add that to an initial message before the set of patches I'll sent either today or tomorrow if I'm lucky
<ng0>updates: url to https, libgpg-error, libgcrypt, gnupg, libassuan.
<nee`>Hello, I did a guix pull and now gnutls fails the 'name-constraints' test when building. So, I can't get my work environment setup anymore. What can I do?
<civodul>nee`: could you send the details on guix-devel? in particular, run "guix build -K gnutls" and send the 'test-suite.log' file from /tmp/guix-build-gnutls*
<nee`>civodul: I can try that. Also nothing seems to happen unless I add --no-substitutes. Is the server down right now?
<ng0>we experienced issues at the server.. on guix-devel list archive there's more in "hydra.gnu.org down" or something
<ng0>disk failure or something.. mirror has still some substitutes
<nee`>The tests/test-suite.log doesn't even list the failed test. Unlike the console output it shows FAIL: 0. Also for me It is /tmp/nix-gnutls* and not guix. I installed the guix binary quite some time ago and only run 'guix pull' and 'guix package -u' to upgrade. Could it might be that my installation is not fully up-to-date?
<civodul>nee`: there may be several test-suite.log files
<civodul>if it's "nix-build-" instead of "guix-build-", it means you're running a relatively old guix-daemon
<ng0>openpgp/setup.scm:1:#!/usr/bin/env gpgscm ... okay. step 1: contact gnupg asking if they can not contribute to upstream their tinyscheme changes and step 1.1: work around this temporary. it's not just a version bump then :)
<ng0>regarding pybitmessage... i don't think i want to wait 2 version releases until i include it in guix.. i will try to fix what I had
<ng0>most of my bug reports have been assigned to v0.8.0
<ng0>they are now at v0.6.0, which took a very long time to get relased from the one before that
<ng0>well.. oh. there was 0.5.8, i did not know that. but before that there was 0.4.4 for a long time
<civodul>ng0: could you ping whoever did the initial pybitmessage on the list, explaining that?
<civodul>not everyone reads IRC so it's probably better this way
<ng0>sometimes I 'document' things for myself in irc logs. when I wait for builds to finish etc
<civodul>ng0: you'd better use a private IRC channel then ;-)
<ng0>how would i fix the shebangs for the tests of gnupg-2.1.14? they ship gpgscm, not external but in the source, and the shebangs are all #!/usr/bin/env gpgscm
<ng0>I wait for mailman of gnupg.org so that I can discuss about this bundled dependency. meanwhile, have 2 phases? have 1 new package where I can split just gpgscm off it?
<ng0>*2 phases .. 1 phase to copy the gpgscm to some path to be available
<ng0>okay nevermind the question, i found osmething useful in the log
<ng0>I'd like to have input of someone else. so GnuPG switched to this tinyscheme modification for their test suite. the test use "#!/usr/bin/env gpgscm" as their shebang. gpgscm is the binary which gets build from the tinyscheme modification. I would like to create a gpgscm package which inherits gnupg-2.2 and only builds the gpgscm folder.that's one way to do it, but this is a very critical software for guix, so I
<ng0>guess one of the solutions which sticks to doing it inside the same package function would be better