<awb99>I am trying to define some cron jobs and then add them later to a system config. <awb99>Is there a way how I can actually add them to sheppard manually? <awb99>so I could test my script before updating the system ? <vagrantc>a more targeted question would be easier to start answering :) <vagrantc>wild guess would be there are no substitutes? <calnombl>sorry :p won't compile, and no substitutes are available so I take it it's a general problem *vagrantc raises an eyebrow at a reproducible builds issue... *jgart jgart raises both eyebrows... <jgart>all the deps for the package are building with --check --rounds=3 <jgart>except for the package itself <jgart>I'm currently calling the package tz <jgart>should I choose a longer variable name for it <jgart>This is unrelated to the above <vagrantc>well, the --rounds= argument is partly to check if it's deterministic/reproducible <vagrantc>you could compare the results with diffoscope to see why <jgart>vagrantc, I would compare the 3 builds against each other? <vagrantc>diffoscope can only compare two at a time, but sure <vagrantc>if they're different in a ... similar way, e.g. they embed a precise timestamp or something, then you might have to figure out how to patch it and submit it upstream and/or patch in guix <jgart>diffoscope /gnu/store/6hihvinvgxky9k8hij5qr032c5qwzxqv-tz-0.5.drv /gnu/store/different-hash-for-tz.drv <kozo[m]>Hey all, does anyone have a working sway config? Thanks <jgart>I haven't used diffoscope yet. Should I be passing a flag to it? <vagrantc>oh, the actualy derivation is unreproducible? that seems odd <jgart>vagrantc, where did you determine that from? <vagrantc>yeah, you want to compare the outputs, not the .drv <vagrantc>i'm not 100% sure where it puts the other outputs from other rounds <vagrantc>obviously, it can't be at the same path ... maybe there are flags to keep the outputs? <vagrantc>i don't have a guix handy at the moment, or i'd prod a little further... <awb99>I am trying to update a package definition: <vagrantc>yeah, you can run diffoscope on the two outputs, the one with -check appended to it <awb99>I only need to change this package definition from UNZIP to UN TAR.GZ <vagrantc>jgart: you can run it without arguments, and it'll spit out a diff to the screen <awb99>The old package babashka was compressed with zip, the new version uses tar.gz <vagrantc>jgart: though sometimes if there are lots of differences, you might want to save it to a file <jgart>with alacritty it's not too bad but maybe I'll pipe to tee if it's too big <jgart>vagrantc, what should I be looking for in the output of diffoscope? <vagrantc>jgart: anything you can make sense out of :) <vagrantc>jgart: diffoscope tries to render in as human-readable format is possible, but obviously when you're dealing with raw binaries, there's only so much diffoscope can be clever about <vagrantc>diffoscope /gnu/store/f3glswn3dfs87v4840b85xwx8pb276mv-tz-0.5 /gnu/store/f3glswn3dfs87v4840b85xwx8pb276mv-tz-0.5-check <vagrantc>jgart: you compared a directory against a file, and it told you :) <vagrantc>i don't know how reproducible go packages are in general <jgart>I'm trying to make sense of it but yeah. not sure in this case <jgart>looks like the hex values are different for some reason <jgart>do people still want guile-zenity packaged? <jgart>I have a package for it that I made today <jgart>but it built successfully for me <vagrantc>jgart: well, at least three somewhat arbitrary go packages in Debian are reproducible ... not sure if debian patches the golang compiler to do anything special ... <vagrantc>jgart: so it might be something go tz is doing specifically... <jgart>do you think the developer might be aware of that? <jgart>not sure where to start on making tz a reproducible build <jgart>it's quite a small package: 6 source files of go <jgart>the deps are all reproducible <vagrantc>jgart: i would only be able to wildly speculate ... check their bug tracker? <jgart>checked the bug tracker but nothing regarding reproducible issues <vagrantc>maybe they're generating some sort of build-id at build time and embedding it? something sort of like that <jgart>I'm going to read through the source code for anything that might stand out <jgart>or maybe some environment variable is being set with the timezone in a non reproducible way, not sure... <vagrantc>jgart: good luck, i'll be curious if you find anything! :) <jgart>I'll be sending a patch to upstream for the deps tonight <jgart>bubbletea should be a native-input <vagrantc>it *shouldn't* embed the results of the test in the output, if it does so <vagrantc>jgart: could patch out the test and see if it becomes reproducible :) <vagrantc>depends on if disabling tests still disables building the tests, but easy to try :) <vagrantc>you could also look for signs of it in the output directory, not sure what's in there <vagrantc>a software dealing with timezones wouldn't surprise me if somehow a timestamp got embedded in there :) <iskarian>our go packages in general are reproducible so I wonder if it's something tz in particular is doing <jgart>still fails even with tests disabled <jgart>guix build: error: derivation `/gnu/store/bc2f5v6phz9g1cfvmsd58dpb79yqza3c-tz-0.5.drv' may not be deterministic: output `/gnu/store/wximn0kvhd7wz11qgz4007xsxbbcia3b-tz-0.5' differs <vagrantc>jgart: still might be worth submitting, and noting that it's a known issue <vagrantc>jgart: that might rope in more people to help :) <jgart>oh didn't realize someone tried it already <jgart>it looks like the deps never got merged though <jgart>bubbletea seems to be a useful package <jgart>and mention the issue with tz <iskarian>Yeah, I wouldn't worry about it; and unfortunately it looks like they didn't find anything helpful w.r.t. this issue <iskarian>is it just the .note.go.buildid that is different? <vagrantc>so frustrating to have such a "small" diff <iskarian>okay, it looks like the actionid half of the buildid is different but the content portion is the same <jgart>I'm reading through the earlier tz thread <iskarian>usually that means that a different build command was used to build the output, but that's obviously not true in this case <jgart>It's too bad they didn't merge the deps <vagrantc>jgart: might be worth entirely removing the test that has the Now calls in it <jgart>I guess it was too much work to decouple them or just nobody did it <vagrantc>jgart: even with tests disabled, it might build them and embed them somehow <jgart>vagrantc, I removed *all* the tests <vagrantc>jgart: ah, not just disabling the calling of the tests... <jgart>let me take a look at the check phase output <vagrantc>removing the tests will produce a different /gnu/store/HASH... <vagrantc>jgart: so you've re-run diffoscope on the new directories? <vagrantc>just to see if it gets the same *kind* of problem ***califax- is now known as califax
<iskarian>There *is* a call to Now() in zone.go, which could cause the built "zone.go" to have a different content id, which would then cause the built "main.go" to have a different action id <jgart>was the diffoscope output helpful at all? <iskarian>same as the old; it's the actionID part of Go's buildid that differs <iskarian>ah, jgart, can you try building with the argument `#:go ,go-1.17'? <iskarian>the build id generation did change, maybe it was fixed? <jgart>iskarian, ok I'll try that now <jgart>iskarian, with tests disabled still? <jgart>built successfully. not to try --rounds=3 --check <jgart>bringing back the tests now... <iskarian>Wow, kinda surprised that worked! It's usually never that easy :) <vagrantc>love it when things get fixed on the toolchain level <vagrantc>if all the other go modules are built with whatever the default go is, will that cause issues? <jgart>Ok, tests work with --rounds=3 <jgart>iskarian and vagrantc can I add you as co-authors? <jgart>I can look in the logs for what you commit as? <iskarian>vagrantc, yep, reusing them is in the pipeline :) there's a preliminary bit in #50493 for re-using cached artifacts <jgart>I started working on these packages with Gábor Boskovits at the guix packaging meetup today <vagrantc>jgart: vagrant@reproducible-builds.org would be appropriate mention :) <jgart>we were pairing over jitsi and tmate on a Guix System VPS <iskarian>jgart, you all did the work! Don't discredit yourselves :) If you want an argument: feedback on the ML doesn't (usually) count as co-authoring, so I don't see how this would be different <vagrantc>all i did was tell you how and what to diffoscope... :) <vagrantc>yeah, i don't feel like a co-author, but if you want to put a thanks out in the body of the bug report or something, that's appropriate to be thankful for the people who helped you :) <vagrantc>is there some sort of Thanks: ... header people use in commits? that might make sense <jgart>we're not discrediting ourselves, we're just adding everyone involved ;) <vagrantc>it was something to do while i waited for guile to compile on Debian, testing for reproducibility issues :) <vagrantc>which, parallelism and guile ... really seems to be an issue. <vagrantc>but the performance of always building guile itself, and projects that are built with guile, in non-parallel ... hrm. maybe i should bring this issue up with guixy folks <iskarian>I do recall at least one issue in the tracker about compiling .go files with parallelism <vagrantc>yeah, parallelism can cause reproducibility issues in a variety of ways ... but *many* things can be built with parallelism ... guile does not appear to be one of them <vagrantc>guix itself isn't reproducible unless you disable parallelism <iskarian>I wonder if there's an actual overview of the work that would be necessary to fix that <jgart>Is anyone interested in guix having more vim plugins? <vagrantc>well, i'm about to file a bug report about it, at least <jgart>It has vim script and common lisp code ***b_ is now known as brendyn
<jgart>don't think there is an example in guix yet for a package like vlime <iskarian>somehow b2 is getting an extra reference to psyntax.scm <iskarian>jgart, unfortunately, I've no clue; I wouldn't even know how to package a plain vim or CL package :) <jgart>plain vim is with the copy-build-system <jgart>a plain vim package is quite simple, actually <jgart>just involves copying a few files to a directory <jgart>no tests are usually involved <jgart>it would be nice to atleast get vim-surround and vim-commentary in <jgart>I have a package sitting for them. I'll send soon ;) <vagrantc>iskarian: yes, it's not great. and anything built with guile potentially has this issue, although some packages trigger it more than others <vagrantc>iskarian: i *think* it's more likely in packages that include a lot of modules <vagrantc>e.g. the more modules you have, the more likely parallelism will actually trigger differences <iskarian>vagrantc, have you tested it with parallelism on but optimization off? <iskarian>It would be interesting to see if it's slipping in because of nondeterministic optimization <vagrantc>not even sure how to turn the optimization off with guile ... i package some guile stuff and use guix but really i don't know my way around guile all that much :) <iskarian>hmm, I don't think it's related to the generated symbols, but there's definitely some more issues there <zacchae[m]>I'm trying to search for a guix package to compile c++ code, but guix seems to treat searches as regular expressions, so searchging g++ or c++ doesn't help <zacchae[m]>anyone know the name of a c++ compiler, or how to search for one? <apteryx>interesting, I have that 'import' command from imagemagick that hangs my system for a while when invoked <apteryx>zacchae[m]: you probably want 'gcc-toolchain' <brendyn>Anyone know of any free software for tracking what you eat and estimating the nutrient content of everything? ***b_ is now known as brendyn
<brendyn>I thought --rounds does not do anything without --check, but the manual does not state to use --check <brendyn>Does it include a database of food and its content, or do i have to enter that all my self? <jgart>hmm not sure, I was just curious and did a quick search on github for the first thing that showed up regarding cli nutrient apps ;) <brendyn>How should I send 234 patches? In a zip file? <PurpleSym>brendyn: Might be better to put them into a separate branch. What are they about? <brendyn>PurpleSym, I don't have privilege of being a comitter. I can put them on my own notabug.org though. <PurpleSym>brendyn: Hm, I’m not familiar, but I could create a wip-kde-updates. Not sure whether someone can grant to push permissions to a specific branch. <brendyn>But it's ok, ill start by linking to my branch and reviewers can email me with what they want. <Soheil[m]>(I need a non-free settings for temporary work…) <Soheil[m]>After the "reconfigure" command, the computer stops while building "webkitgtk" and there is no other way but to kill the computer! <efraim>Soheil[m]: please don't discuss non-free software in this channel <efraim>It specifically targets compiling and icecat for killing when I run out of RAM <efraim>also, what commit are you on? I can force building webkitgtk on bayfront <efraim>it looks like webkitgtk is already built on bayfront for that commit <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, you have 2 messages! <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 ***Kimapr[ii] is now known as Kimapr[i]
<attila_lendvai>i wish recursive-import was written in a way that it keeps retrying until everything gets processed... it's pretty useless on a flaky internet. <attila_lendvai>and it's written in a complicated enough way that i can't easily patch it to behave that way <attila_lendvai>if i want to avoid putting github links here, then which endorsed alternative would you recommend? sr.ht? <roptat>I mean, you can post github links here <Noisytoot>you can post github links here, but sr.ht is better anyway <attila_lendvai>roptat, well, i got some snarky comments for that before... but i'll ignore that for now then. <dstolfa>attila_lendvai: i'm not sure why someone would be giving you snarky comments about linking to github. please do ignore them. <attila_lendvai>it's ok, in a way i can understand this attitude. but i'm pragmatic in stuff where i can just push the git repo somewhere else any moment when github becomes annoying enough... <roptat>well no, that's not acceptable, that kind of attitude tends to shut people down and push them away from guix <roptat>sure, we're not gonna recommend an unethical platform to host your projects, but really we shouldn't give you snarky comments because you chose that platform anyway <attila_lendvai>roptat, i have a thick skin. among other places, i developed it in the common lisp community... :) <roptat>well, I hope we can stop doing that to people, everyone doesn't have your thick skin :) <roptat>it's something that's been pushing me away from GNU for a long time. In fact, I still don't want to interact with GNU outside of guix because of this kind of behavior <nckx><please do ignore them>++ <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/** <futurile>should be a question in there I guess: what is the error trying to tell me, anyone know how to fix it? <roptat>futurile, it's just a warning, so as annoying as it is, you can always ignore it <roptat>but from a clean checkout, it shouldn't happen <nckx>(If you want to [politely] do more than ignore them that's fine too, but it shouldn't be up to you have to do so.) <singpolyma>futurile: i usually delete the compiled file when I get that 🤷♂️ <roptat>maybe you have guix in your user profile, or a GUILE_LOAD_COMPILED_PATH with a read-only version of what you're building? <roptat>it might go away in a --pure environment <futurile>OK, I'll play around. It's probably because I'm still quite confused about environment, so must be polluting somehow <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 <attila_lendvai>r7rs-swank is unfortunately rather basic, missing a lot of functionality <awb99>When I use multiple channels, what happens when two channels define a package with the same name? <awb99>Can I query which are the packages from which channel? <roptat>awb99, I don't think so, if two packages have the same name, on the cli guix will simply choose the highest version <roptat>(although, from the code, as long as you import only one of the modules, two packages with the same variable (scheme) name will not conflict, so you can choose which one to depend on) <podiki[m]>is there some examples or guide to how to now do things with %build-inputs (eg wrapping) with the new inputs style? <podiki[m]>i didn't see anything in the "invoking guix style" or running guix style <podiki[m]>I need to use gexps with #+pkgname, is that right? <awb99>I am asking with the package conflicts, because it might be, that over time one of the channels defines a package that I have defined myself. <awb99>And then it might happen, that over time the other channel takes over. <awb99>And I would never be able to find out that that happens. <awb99>I have a problem splitting my code for a system config into multiple modules. I am confused by use-service-modules use-package-modules and use-modules <awb99>Do I have to include services that I define myself with use-service-modules ? <nckx>Define where? (use-service-modules x y …) is just syntactic sugar for (use-modules (gnu services x) (gnu services y) …) <awb99>so in my services module, I just do #:export (myservice-cron) or I do define-public myservice-cron <awb99>in case I want to use a fully configured cron service in another file whcih defines the system ? <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). ***Exa is now known as Exagone313
***Exagone313 is now known as Exa
<awb99>My idea is this: I make a private git repo. <awb99>In there I add a folder for guile modules. <awb99>Then I call the various guix commands, and just pass on my guile modules folder. <awb99>Is a channel better for this? <nckx>Ah! Can't say, never really got into the whole -L workflow. <nckx>I can only say channels let you do this too, but I don't know if they're ‘better’ per se. <nckx>Sorry if I misunderstood. <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>But a ‘make’ is usually the answer. <awb99>I get this error in using guix repl: ;;; note: source file /home/florian/repo/myLinux/distros/guix/modules/awb99/services/cron.scm <awb99>;;; newer than compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.5/home/florian/repo/myLinux/distros/guix/modules/awb99/services/cron.scm.go <nckx>> Ah! Can't say, never really got into the whole -L workflow. <thorwil>ok, so that’s not it. guix graph does fail at the end with: "guix graph: error: fport_write: Broken pipe" <awb99>Can I force clearing up the guile compile cache? <nckx>Well, I'm useless today. <thorwil>sheesh, of course there’s no `dot` here! <thorwil>guix graph text output is actually good enough <nckx>awb99: …no error? You can rm -rf ~/.cache/guile if the message bothers you though. <nckx>For more advanced cache management tools than ‘rm’, see ‘Compilation’ in the Guile manual. <nckx>Specifically GUILE_AUTO_COMPILE. <awb99>thanks @nckx the removing of the cache with rm did work :-) <thorwil>`/gnu/store: find -iname "*lilv*"` lists several items, starting with "./5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10" <thorwil>at the same time `guix gc -D lilv` says `lilv' is not in the store <efraim>`guix gc -D` takes a full store path <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 😛). <nckx>sneek: later tell lfam: Really hoping the answer isn't ‘First, download Debian…’. <thorwil>efraim: ah, with /gnu/store in front, even. well, that gets me to: "guix gc: error: cannot delete path `/gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10' since it is still alive" <nckx>Did you delete old profile generations? <nckx>Running ‘guix remove foo’ just creates a new profile without foo, the old one is still kept until you delete it. <thorwil>i was just about looking up what --delete-generations really means, when i saw the -D option <awb99>can someone tell me the meaning of #~ for example: #~(job "5 3 * * *" ;Vixie cron syntax <awb99>; "guix gc --optimize -d 2m && guix gc -F 300G && guix pull") <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. <nckx>It's conceptually similar to quoting. <nckx>thorwil: Hm, it does. Only for the current user, not others, and also not for the system. Did you have any lilv users in the latter(s)? <thorwil>even `guix gc -d 1d` did not get rid of lilv <thorwil>single user system. never installed anything as anyone but plain user <efraim>thorwil: try `sudo -E guix gc --verify=repair,contents /gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10' <thorwil>efraim: error: extraneous arguments: /gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10 <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. <awb99>is there a reason why you export %substitute-urls (so with a trailing %) <efraim>Only so it stands out to me as a variable <awb99>Is it wise to use so many substitute servers? <awb99>I am sorry. I will copy everythgn I find in your profile that makes sense to see if it works on my system :-) <efraim>it doesn't normally slow me down although I do most of my building --without-sustitutes ***yewscion is now known as yewscion_
<awb99>@efraim: you ar managing ssh keys in guix? Where will it get the private keys from? So you could ssh into servers with uing private keys, depending on the hotname? <efraim>I manage my ssh keys by hand. The guix publish keys I generate on each machine <awb99>ah. so the config is that you can SSH into the different machines. <raghavgururajan>Folks, any idea on this warning "guix system: warning: mapped-device '/dev/sda1' may not be mounted by the bootloader." during system reconfigure? <maximed>The warning is issued by operating-system-bootloader-crypto-devices <maximed>Using /dev/sda1 is somewhat fragile w.r.t. adding/deleting partitions, inserting extra disks ... <maximed>Or maybe GRUB doesn't understand /dev/sda1 <nckx>I get that error too but have never had trouble booting. This is not legal advice. <awb99>how can I add multiple channels to guix sd? I did use guix pull --channels=./app/channels.scm but this seems to get overwritten from time to time. <nckx>awb99: (Guix System) What gets overwritten? <nckx>raghavgururajan: Nope, and it's a VPS, not my laptop. <awb99> guix pull --channels=./app/channels.scm <awb99>when I later want to install packages from this channels, it cannot find them. <nckx>The file app/channels.scm gets overwritten? <nckx>So you run guix pull --channels=some/channels.scm && guix install a-package-in-one-of-them and it's not found? <nckx>You didn't run another ‘guix pull’ removing the custom channels in the mean time? <GNUHacker>I'm installing Guix system by first time. Ill leave GNU Trisquel <nckx>Hi GNUHacker. Good luck! Although you don't have to choose, you can have both 😉 <nckx>Then it's expected that you won't have your --channels from the previous run. <awb99>I thought guix pull just gets the last updates from all channels. <nckx>But --channels doesn't add the file to some pile of channels in the sky^Wcloud. <awb99>but for me, it looses the channel defs <nckx>It says ‘pull from these channels’. But only that time. <awb99>how can I add the channels, so that they will be saved? <nckx>The default location that *is* used every time (if you don't pass explicit --channels) is ~/.config/guix/channels.scm. <awb99>so channels are completely user specific then. <nckx>It's just a scheme file, so it could in theory contain any crazy executable code you want, but in practice it's just a list. <nckx>I don't think there's a way to add default/bootstrap channels to the system/bootstrap Guix in your operating-system, but I haven't looked hard either. <thorwil>efraim: it apears that like all other earlier repair attempts, `sudo -E guix gc --verify=repair,contents` fetches and downloads stuff, but does not actually change anything <thorwil>as the problem with an empty lilv persists and running `sudo -E guix gc --verify=repair,contents` again leads to the same output and busywork <nckx>thorwil: From which substitute server? <nckx>/gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10 on ci.guix.gnu.org has, like, stuff in it. <nckx>Does the repair catch that particular directory? What does it say about it? Does it mention how it tries to fix it (if so)? <thorwil>path `/gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10' was modified! expected hash `65dcc0e546d1adf9d1f368bd90fbf1c6eb97c6dc45559a2d5e6142e4acbeb094', got `76ca5d9c255f5f98b4e9527512d96f726b501974d37fc3b3bc3b31ca3c4510d6' <thorwil>fetching path `/gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10'... <thorwil> lilv-0.24.10 73KiB 1.2MiB/s 00:00 [##################] 100.0% <nckx>The file at that URL contains all the expected files. <thorwil>it certainly downloads *stuff*. but it looks like it’s thrown away afterwards <thorwil>as the same command 2 times in a row has the same output <nckx>You should report this as a bug. <nckx>I only searched the bug tracker for lv2 . <nckx>I should have, y'know, searched for lilv. <nckx>I wonder if everyone who reads it is just flummoxed. <thorwil>actually, i hit guix-help with it and Leo Famulari created a ticket <thorwil>yeah, i guess it’s a case of this-just.doesn’t make sense <nckx>I gotta go (actually had to leave 5mins ago but this was weird enough to keep me :) Sorry, and good luck… <thorwil>i see how my ssd may have eaten those files, but that repair fails and that it doesn’t seem possible to remove all dependents to then have lilb garbage collected is ... majorly frustrating <civodul>i was going to ask what makes thorwil think that what's downloaded is thrown away <civodul>we should really come up with a testing strategy for --verify <podiki[m]>I just switched to core-updates-frozen and time zone is wrong... Still set the same as before but date shows just UTC time <civodul>podiki[m]: you mean you reconfigured Guix System on that branch? <podiki[m]>Yeah pulled and reconfigured all went pretty well (one failure in python package I submitted bug) <podiki[m]>Did all my other packages too, went fine (I have to fix one custom one though) <podiki[m]>Still have /etc/timezone set as before didn't change system config for that. What else should I check? <civodul>podiki[m]: are you running the "new" 'date' command? <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> libc.so.6 => /gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/lib/libc.so.6 (0x00007efeed00c000) <podiki-irc> /gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/lib/ld-linux-x86-64.so.2 (0x00007efeed1d0000) <podiki-irc>the first line was /run/current-system/profile/bin/date: <civodul>podiki-irc: so that's the new one hmm <raingloom>any idea why my emacs has no coq-mode ? i see no emacs-coq-mode package, so i assume it's either part of proof-general or emacs itself. <civodul>cbaines: yeah, like you write, i *think* the preexisting output is kept <podiki-irc>yes I'm confused...there were some updates on timezone in the installer and the file ending in a newline, but don't see how that would come into play here <raingloom>(there are so many coq packages, including proof-general, it seems unlikely that coq-mode would be missing.) <civodul>podiki[m]: hmm i can observe this timezone problem even in a VM <podiki-irc>sure. I take it's a core-updates-frozen branch problem? or did you try on a different branch too? <podiki-irc>I'll put what I put in this chat roughly, anything else helpful? <podiki-irc>I was otherwise going to report core-updates-frozen working well for me, other than a python package and some kde ones not having subs (but built fine locally) <civodul>good that the rest works for you :-) <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 <civodul>(unless you happen to leave on a timezone that's UTC with no DST, if such a thing exists) <vagrantc>yeah, not sure sane timezones really exist <podiki-irc>speaking of the core-updates-frozen world rebuild, is there a time frame for that? or waiting until closer to a merge to master? <civodul>but it's good that we're having more testing before that <lfam>I could add a tzdata update to the "rebuild the world" push <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 😛). <sneek>lfam, nckx says: Really hoping the answer isn't ‘First, download Debian…’. <lfam>sneek: later tell nckx: I use `make oldconfig` with the config of the previous kernel series <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, lfam says: I use `make oldconfig` with the config of the previous kernel series <lfam>Yeah, my workstation is debian <nckx>It's not a result of using Debian's kernel .config as base, got it. <lfam>And I'm pretty sure that GCC is not actually used <lfam>But I'm not sure what `make oldconfig` actually runs <civodul>lfam: a tzdata update is always welcome :-) <civodul>though did you mean tzdata-for-tests? <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 <lfam>Can you clarify what is changed in the latter difference, nckx? <nckx>I'm guessing that CONFIG_LOGO_LIBRE_CLUT224=y means it wasn't generated on a -libre source tree, either. Not that there's anything wrong with that. <lfam>Are you saying it breaks the build? What do you mean that you "had to work around" something? <nckx>No! Just selectively commit to avoid unintentional noise, nothing more. <nckx>There's no functional problem. I just had questions and now seems like as good a time as any to learn how you do things before you don't. <lfam>Hm, I'm not sure about CONFIG_LOGO_LIBRE_CLUT224 <lfam>I wonder what's the most efficient way to search the actual code changes of the Git repo <nckx>Well, since that's a symbol added by the -libre patches, I thought it meant you ran make *config on a vanilla tree. <lfam>Yeah probably, although I'm curious about the older kernel series like 4.9 <lfam>I don't think I made significant changes to those old ones <nckx>4.4 has it, newer don't. <nckx>Maybe when you took over from Mark? <lfam>IIUC correctly, the only time I changed e.g. the 4.9 configs is in commit 12763e4d3a90d113da85f5c9d116889982021a8f <lfam>Anyways, I can start doing this on Guix System. I did it on Debian and sometimes I do it with Linux, sometimes with linux-libre <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 <lfam>It would be nice to talk about it as a distro <vagrantc>i'm game to discuss kernel configuration :) <lfam>So, what should we change? How should we do things? Do you have any pet concerns? <vagrantc>my biggest suggestion is to stop maintaining the kernel configs, and instead maintain lists of desired CONFIG_* and undesired CONFIG_* <vagrantc>e.g. kind of how the various linux-libre-*generic packages are maintained, but adding a way to remove features (e.g. things linux-libre doesn't support) <podiki-irc>unrelated to kernel but on this time zone libc issue. would setting $TZ workaround most of this issue as a stopgap (wanting to stay on core-updates-frozen). <vagrantc>the current kernel configs are a lot of boilerplate configuration... reducing that to two lists and having 'make oldconfig' sort out the rest ... <lfam>vagrantc: So, mostly taking the defaults? <lfam>podiki-irc: The issue being that the wrong time zone is being used? <nckx>vagrantc: Relative to what? Upstream defconfig? <podiki-irc>lfam yes, the bug is libc doesn't look for time zone info in the right place. besides time display, I think I'm running into other issues that may be related (not sure though) <nckx>I've often (but idly) wondered how much effort even goes into that, or what the rules are. <vagrantc>it's at least maintained by someone else :) <lfam>podiki-irc: I think that $TZ will work in a lot of cases. It depends on if the applications looks there <nckx>OK, so it is deliberately maintained by a competent human? <nckx>That wasn't always clear. <lfam>I can't really say if the base of the configs matches upstream defaults. Since I only took over recently, the core of the kernel configurations had already been chosen by mhw <vagrantc>well, people add things to it and remove things from it when changes happen <lfam>I think that for newer features, we are often choosing what would be the default. Except in the case of hardware support; we enable support for a lot more than the default <vagrantc>debian's configs have a base config, and then per-architecture overlays on top of that <lfam>I guess that's a "distro-y" thing to do. And maybe we go too far (something I noticed compared to Debian) <lfam>vagrantc: So, like, USB is enabled across the board in one place <lfam>That sort of thing makes sense <vagrantc>and if there's some oddball architecture that doesn't support USB, you disable it for that architecture <lfam>Something I like about the status quo is that it's really easy to "look things up". Like, if I have a question about how the build is configured, I can quickly consult authoritative source <vagrantc>and then uses various things on top ... maybe "make silentoldconfig" or something <vagrantc>lfam: but the config in guix git may not match what the package ends up building with ... <lfam>There are already a few overrides in the Scheme <lfam>Is that what you're referring to? <vagrantc>i'd suggest leveraging that even more, basically <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?