<ng0>was it core-updates or core-updates-next I should rebase on? <ng0>or at least the last gnupg update i sent was on this branch <ng0>gpg-2.1.14 changes the test suite from bash to scheme programs. cool <ng0>would be much nicer if it was just scheme (actually i haven't checked yet) and they did not include their own scheme interpreter <ng0>maybe it can be tricked and it is really just something we already have .. but I'll package it with the gpgscm first <ng0>on signed commits.. makes it sense for developers without push access to sign the commits when they get re-signed again by those with push access (or maybe I misunderstand signed commits) <ng0>seems like the interview with that one magazine has some positive effect :) <ng0>did you just connect, civodul? Maybe you can answer the question I had on signed commits <ng0>on signed commits.. makes it sense for developers without push access to sign the commits when they get re-signed again by those with push access (or maybe I misunderstand signed commits) ***avph_ is now known as avph
<ng0>without hydra, test-building gnupg is as slow as on gentoo <ng0>or does someone know if we have something which understands tinyscheme? <ng0>maybe it's not exactly tinyscheme, i'm looking at related commits if they change it over time <ng0>it looks like gupg modifies it a bit <ng0>from the logs at least <ng0>so we should just leave it be for now <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>or even better yet, if pushing back to tinyscheme upstream would happen <ng0>last release of tinyscheme was 2013 <ng0>maybe someone subscribed to one of the gnupg lists could ask about this? <ng0>I'd have to re-subscribe, I think announce is read only <ng0>the test suite of gnupg moved to scheme, based on tinyscheme with some changes according to commit messages <ng0>i'm doing gnupg2.1.14+libgcrypt-1.7.2 right now <ng0>it should just work with the bundled one, but i know we don't prefer bundles <ng0>where is e41e39451f0d409e628e09196596f3e41f37d2bd from? core-updates or core-updates-next? when rebasing master on core-updates-next this breaks it <ng0>something in guix/utils.scm <ng0>in ediff, buffer A is the more recent version of the file, right? ***lumidify_ is now known as lumidify
<ng0>or is it B, and A is what is asking to get merged in? <ng0>I try to solve a conflict with core-updates-next <ng0>To be more specific: did a commit in core-updates-next remove something in (define-syntax current-source-directory) or did it add something, or recently in master? <civodul>sneek: later tell lfam nice work on the sourceforge story\\ <ng0>do we have an short statement on bundled dependencies somewhere? <ng0>i can't come up with one to append to an issue I split up <ng0>I'll just link to something <civodul>ng0: we don't have an official statement, but it'd be a good idea, i guess <ng0>should I open a Guix bug so that we do not forget to include/formulate an statement on why bundling is bad? <adfeno>ng0: Personally, I think it's a good suggestion. Although I do not participate actively on Guix. <ng0>bug-guix@ or guix-bug@ ? <ng0>ah got it in my autocomplete <vlegoll>ng0: why didn't you just do PRs ? looks like you spent more time reporting a bug than it would take to just fix it (the oneliner shebang thing in bitmessage)... <ng0>because i know that pull request accepting can take a painful long time at pybitmessage <vlegoll>And I think creating a bug to remember to write something in the doc about bundling is fine <ng0>and most of my fixes are just too trivial + I did sent in a patch to one of the maintainers months ago via email and it never got through <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 <ng0>and their docs are not helping either <ng0>good job, corporation. <ng0>it "fixed" the intendation <ng0>i found the answer to a previous question I had. core-updates-next extends what was there in the conflicting file <kristofer>when I try to use jack, I have a problem with realtime priority, rtprio, I guess the kernel isn't built with such support. <lfam>kristofer: You should talk to rekado. He uses GuixSD for making music and I believe he uses JACK <sneek>Welcome back lfam, you have 1 message. <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>some merge problems to fix <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? <ng0>i have done it that way before <lfam>I'm talking about rebasing the master branch, like this: `git checkout master && git rebase core-updates`. We can't do that <ng0>i think that's exactly what i have done last time for the patches for core-updates(-next) <lfam>I would expect that action to break the history of your copy of the master branch, requiring you to delete it and re-create it from Savannah's copy. <ng0>should I work directly on the core-update branches then and not rebased from master <lfam>When you say "rebased from master", what do you mean? To me, that means this: `git checkout core-updates && git rebase master` <ng0>exactly the other way around <ng0>i work on local master which equals to origin/master <ng0>here it is origin/master, fresh checked out <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? <lfam>bombastus: The 0.10.0 installer? <lfam>The filesystem, is it mounted correctly? It's ext4, right? <lfam>What is the value of $PATH? <lfam>And, what is in the directories pointed to by $PATH? Is there anything there? <ng0>grr. i think lst time it worked better because at first i did core-updates and then after requested i did on the same branch a rebase on -next <bombastus>path is '/root/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin' <bombastus>and there are symlinks in /run/current-system/profile/bin/ before i run 'herd start cow-store' <bombastus>Does it make a difference if the file system mounted on /mnt is encrypted? <lfam>I don't think it should, as long as you've decrypted it properly <lfam>The commands you are trying to run, do they exist in /run/current-system/profile/bin? <lfam>Oh wait, the target root filesystem? Unfortunately, we don't support encrypted root filesystem's, yet. Help wanted :) <lfam>So, it won't work. I don't know whether or not that would cause the issue you originally reported <bombastus>what is the 'herd start cow-store /mnt' command doing? is there documentation somewhere? <lfam>I think it's just documented where implemented, aside from the sentences in the installation instructions. <lfam>On my GuixSD system, the relevant code is easily accessible at '~/.config/guix/latest/gnu/system/install.scm'. I'm not sure whether or not /root/.config will exist in the installer <lfam>But, the code should exist on the system <lfam>Worst case, you can find it with `echo /gnu/store/*guix-latest` <bombastus>lfam: just cloned the git repo and grepped for it :) <lfam>I haven't heard of problems at this stage before, so I think it's probably caused by your encrypted root filesystem. If not, please file a bug :) <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 <nee`>Okay the error message is pretty clear './template-test: line 30: datefudge: command not found' 'You need datefudge to run this test' <civodul>i wonder why we don't systematically get this failure <nee`>I'll send the file to guix-devel <nee`>Ah no wait I mixed that up. That was the message for a skipped test that was listed below the actual failed test <rekado>kristofer: for real-time priority you don’t need kernel support. <rekado>kristofer: you need a patch that I’ve prepared a long time ago but that I failed to submit/push. <rekado>(I think it was even reviewed but I forgot about it) <rekado>that’s all I need to use JACK in real-time mode. <rekado>let me check the patch and its review; maybe it was okay to push it. <rekado>kristofer: looks like the patch itself was okay, but I still need to document the changes in the manual. <rekado>with that patch you can do this: <rekado> (pam-limits-service (plain-file "limits.conf" " <rekado>in the “services” field of your system configuration. <rekado>your account should be a member of the “realtime” group (and the group should be created via the “groups” field). <rekado>That’s enough to make JACK run in real-time mode. <jmd`>Building from current git master ... <jmd`>ERROR: In procedure delete: <ng0>what's libgcrypt-1.5.4 needed for in the process of building gnupg? <ng0>maybe it wasn't gnupg and it still needs some dependencies untoil gnupg gets build <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