<attila_lendvai>what's the deal with using local define's instead of let's? e.g. in git-authenticate.scm. is that something out of the ordinary waiting to be evened out, or is that part of the style guide? or was that used for minimizing the line-diff of a change?
<yoctocell>attila_lendvai: I usually do it to save on vertical space; otherwise, you will quickly reach 80 chars
<sneek>yoctocell, civodul says: i just realized that "git tag xyz" is non-interactive
<sneek>yoctocell, PurpleSym says: It seems the cabal importer does not support the elif statement. Is that correct? I’m trying to import lukko from stackage, but it fails with Syntax error: unexpected token : elif (at line 91, column 2)
<yoctocell>PurpleSym: looking at (guix import cabal), I don't think it supports `elif' expressions
<brendyn>hmm, just the 'install phase of rust-1.52 alone has taken over an hour
<brendyn>i think it is compiling during that phase
<futurile>I keep getting errors about "source file xxxx being newer than compiled xxxx". I'm building guix from source (I did make clean; bootstrap; make) and just can't seem to clear it. It all seems to be things in lib/guile/3.0/site-ccache/**
<attila_lendvai>Noisytoot, i already know slime, including its internals. and for me geiser didn't yield enough value/time for now. i may try again later, if the slime path is also riddled with obstacles.
<attila_lendvai>my primary issue is that guile backtraces are useless. they are full of '...', and i can't easily change that
<nckx>If this is about a custom channel, you can certainly have (awb services foo) export a custom service and use it in (services …). Either use a name that should never clash (like awbs-cron-service-type), or get creative with #:hide (although that's still fragile IMO).
<nckx>Or use (@ (awb services foo) foo-service-type).
<thorwil>hi! since my `lilv` store item remains empty and nothing else succeeded in fixing it, i figured i could remove all packages that depend on it, collect garbage and finally get a new, good `lilv`
<thorwil>i already went through my manifest to remove everything lv2-related that i know of. cleaned up. lilv is still in the store
<thorwil>figured `guix graph lilv | dot -Tpdf > dag.pdf` might help, but with that, i get: guix graph: warning: failed to load '(distrho-ports-lv2)': In procedure abi-check: #<record-type <package>>: record ABI mismatch; recompilation needed
<thorwil>same repeated with eq10q and invada-studio-plugins-lv2
<thorwil>guess i need `--type=reverse-package`, but same errors
<nckx>That message isn't related to the command; it means your local git checkout needs recompilation.
<nckx>Since I don't have any of those packages I'm not sure what you're working from.
<nckx>sneek: later ask lfam: ‘Linux/x86 5.14.0 Kernel Configuration’ (no -gnu) and ‘CONFIG_CC_VERSION_TEXT="gcc (Debian 8.3.0-6) 8.3.0"’ make me wonder how you generate Guix kernel .configs, and how I can best approximate that with a minimal diff (e.g., I get a free GCC cyclometric complexity plugin on Guix 😛).
<thorwil>so far, i assumed without further options, --delete-generations should only leave the current generation
<nckx>awb99: It means ‘[begin a] gexp’, short for G-Expression, which is hard to explain in one sentence (well, I find it hard to do). I suggest reading ‘G-Expressions’ in the Guix manual, then asking more specific questions you might have. But as a user, you'll usually just see and write #~(blah blah #$package blah #$another-package blah) and might get away with not quite understanding it yet.
<efraim>that's unfortunate. then try running it without the store path. It'll check the store for broken packages
<thorwil>efraim: it’s already doing that and finding even more issues than i was aware of
<thorwil>efraim: this could be the ticket. thank you!
<awb99>I am using now guix for almost a year as a package manager. Now I have finally moved to guix sd. And I am totally lost. I am working for 4 days to get my desktop machine configured to how I had it in manjaro. Could someone post their configs here? I am googling everything, and I have a really hard time to find examples.
<civodul>(since it's the same coreutils version on both branches)
<cbaines>I'm trying to read the guix-daemon code, but haven't quite worked it out yet. What happens if you build a derivation with two outputs, one in the store, and one not in the store. Assuming the build succeeds, will the output that was in the store be the result of the build, or what was there before?
<cbaines>(my guess is the former, the existing output won't be replaced with the output from the build)
<podiki-irc>so that means many things that go through libc for time will just be using UTC then? (I know sometimes widely incorrect time leads to some problems in security checks or something like that)
<civodul>yes, every application is going to use UTC
<sneek>lfam, nckx says: ‘Linux/x86 5.14.0 Kernel Configuration’ (no -gnu) and ‘CONFIG_CC_VERSION_TEXT="gcc (Debian 8.3.0-6) 8.3.0"’ make me wonder how you generate Guix kernel .configs, and how I can best approximate that with a minimal diff (e.g., I get a free GCC cyclometric complexity plugin on Guix 😛).
<lfam>Although both packages are eligible for core-updates
<nckx>Not used, but it causes differences like CONFIG_CC_CAN_LINK_STATIC=y (n on Guix) and CONFIG_GCC_PLUGINS/CONFIG_GCC_PLUGIN_STACKLEAK (y on Guix). Like you I'm almost certain it doesn't matter. I don't use linux-libre and my kernel explicitly makes oldconfig so I don't have to wonder, but still…
<lfam>'tzdata' does not rebuild Rust, however. So it's still much less expensive
<nckx>please do whatever will keep you willing to maintain this the longest :-) I'd think doing this with guix build --source + guix environment would be easiest, but if you prefer the current method that's fine.
<nckx>I thought the .config was trying to tell me more than it apparently is, nothing more.
<lfam>I'm digging around in the history to try to learn about CLUT224
<lfam>The Git UI is not amazing for kernel configs
<nckx>I thought it meant I wasn't following the Process.
<lfam>It looks like CLUT224 was turned off in commit 75b314a615e7f1a62483046eb1d569ed88fd8530, which added 4.5
<lfam>The process is somewhat ad-hoc. I mean, I think the task of making the kernel configs is pretty ad-hoc. It asks a few hundred questions and I do some simple research on them and have some habits about what to enable
<lfam>It's interesting to compare to e.g. Debian, which I did recently for some reason I don't remember
<vagrantc>one of the things attracting me to guix was how easy it was to make kernel variants ... and while in general it's good to try and have a limited set per architecture, it is useful to have some builds that are just slightly modified defconfig builds
<lfam>How about the situation where you change one option, and it causes `make config` to ask other questions to be presented to you? Like, would we just always take the default answers to those questions? Do we want to have some tool for displaying them?