IRC channel logs

2021-09-26.log

back to list of logs

<awb99> https://textbin.net/bkxl6vpquk
<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 ?
<podiki[m]>this might be useful: https://guix.gnu.org/blog/2020/gnu-shepherd-user-services/
<calnombl>what's up with sbcl on arm64?
<calnombl> /aarch64
<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
<jgart>hi!
<jgart>has anyone come across this error before? https://paste.sr.ht/~jgart/99583c33249dc7acd35763f9023efc1ec9f8fcd8
*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>it's this little fella here: https://github.com/oz/tz
<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>nix calls it tz https://github.com/NixOS/nixpkgs/blob/nixos-21.05/pkgs/tools/misc/tz/default.nix#L17
<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>so
<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?
<jgart>what line in the paste?
<jgart>oh yes, last line?
<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?
<jgart>here's the pkg in question: https://paste.sr.ht/~jgart/a742f8875cf58987ed010140d1924039750a8346
<jgart>oh you mean like -K
<jgart>output with -K https://paste.sr.ht/~jgart/417d85bf675cf109c8c5c523171658673e188f2c
<vagrantc>i don't have a guix handy at the moment, or i'd prod a little further...
<jgart>ah ok
<jgart>no worries
<awb99>I am trying to update a package definition:
<awb99> https://github.com/giuliano108/guix-packages/blob/master/packages/babashka.scm
<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
<awb99>any ideas?
<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 :)
<jgart>ok cool
<jgart>let me take a look
<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
<jgart> https://paste.sr.ht/~jgart/3a42f5b0f782d272d92a6181f33533f889e23c11
<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 :)
<jgart>hahaha
<jgart>doing the right thing now
<jgart>one sec
<jgart> https://paste.sr.ht/~jgart/31aa3c9ef0bd1dbc8ac6d07166b5ca16d1db09cc
<vagrantc>jgart: hrm. nothing immediately obvious
<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>in .note.go.buildid
<jgart>do people still want guile-zenity packaged?
<jgart>I have a package for it that I made today
<jgart>it's 5 years old
<jgart>the release, that is
<jgart>and latest commit
<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
<jgart>I tested those
<vagrantc>jgart: i would only be able to wildly speculate ... check their bug tracker?
<vagrantc>jgart: and/or report a bug
<jgart>checked the bug tracker but nothing regarding reproducible issues
<jgart>mostly feature request ;)
<jgart>* requests
<jgart>or bugs of features
<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...
<jgart>I'm speculating now
*jgart jgart reads tz
<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>and I'll probably add it to this pre-release channel for convenience: https://git.sr.ht/~whereiseveryone/guixrus
<jgart>oh I found one problem
<jgart>bubbletea should be a native-input
<jgart>vagrantc, could it be that the test runs a current time command? https://github.com/oz/tz/blob/main/config_test.go#L55
<jgart>time.Now()
<jgart>or that shouldn't matter
<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 :)
<jgart>so disable tests?
<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>hi! I heard go
<jgart>you heard right!
<iskarian>our go packages in general are reproducible so I wonder if it's something tz in particular is doing
<jgart>hmm
<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
<jgart>same mess
<iskarian>You might be interested to know there was an attempt at packaging tz at https://issues.guix.gnu.org/48364
<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 an upgrade to termenv
<jgart>I'll send those nonetheless
<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
<vagrantc>tz sounds like a useful tool, too :)
<iskarian>is it just the .note.go.buildid that is different?
<vagrantc>jgart: the entirety of the diffoscope output is in your paste: https://paste.sr.ht/~jgart/31aa3c9ef0bd1dbc8ac6d07166b5ca16d1db09cc ?
<jgart>yup
<vagrantc>so frustrating to have such a "small" diff
<vagrantc>and still have no idea what it is...
<jgart>haha yea
<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
<jgart>the someone else submitted
<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
<jgart>doing that now
<vagrantc>there are lots of time.now calls: https://github.com/oz/tz/blob/main/main.go#L97
<jgart> https://paste.sr.ht/~jgart/c8c2c8928c54b611e1257b60caac3306b4686cff
<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
<vagrantc>but hopefully those are just at runtime
<iskarian>They should be, AFAIK
<jgart>was the diffoscope output helpful at all?
<jgart>the new output, that is
<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?
<iskarian>Yeah, just to be safe
<jgart>ok
<jgart>got it
<jgart>it's building
<jgart>built successfully. not to try --rounds=3 --check
<jgart>s/not/now
<jgart>--rounds work :)
<jgart>bringing back the tests now...
<iskarian>Wow, kinda surprised that worked! It's usually never that easy :)
<vagrantc>oh, interesting :)
<jgart>yup, that did it
*vagrantc claps
<jgart>let's see if tests like it
<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?
<iskarian>Nope, build artifacts aren't reused
<vagrantc>e.g. tz's various inputs
<vagrantc>ah, both ... good and bad. :)
<jgart>Ok, tests work with --rounds=3
<jgart>good work folks!
<jgart>I'm send this over :)
<jgart>s/I'm/I'll
<jgart>iskarian and vagrantc can I add you as co-authors?
<jgart>for helping out
<jgart>I can look in the logs for what you commit as?
<vagrantc>jgart: i didn't much author anything :)
<iskarian>vagrantc, yep, reusing them is in the pipeline :) there's a preliminary bit in #50493 for re-using cached artifacts
<jgart>but ya'll made it happen
<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
<jgart>great!
<jgart>will do
<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.
<iskarian>parallelism and anything, to be honest
<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>can be built reproducibly, that is
<iskarian>compiling .scm -> .go files*
<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>how would you go about packaging this? https://github.com/vlime/vlime
<jgart>It has vim script and common lisp code
<vagrantc> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/guile-3.0.html ... it often seems to embed references to .scm files in more-or-less arbitrary order
***b_ is now known as brendyn
<jgart>don't think there is an example in guix yet for a package like vlime
<iskarian>vagrantc, wow, that's pretty messy
<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?
<vagrantc>iskarian: i have not
<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>Should be -O0 IIRC
<vagrantc>ah, standard compiler stuff
<vagrantc>maybe related to https://issues.guix.gnu.org/issue/20272
*vagrantc waves
<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'
<zacchae[m]>thanks
<brendyn>Anyone know of any free software for tracking what you eat and estimating the nutrient content of everything?
<RRRRedEye[m]>brendyn: emacs, lol.
***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
<jgart>brendyn, https://github.com/aquilax/hranoprovod-cli
<brendyn>thanks i will look
<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.
<brendyn>KDE updates
<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>I don't think that is possible
<PurpleSym>*not familiar with KDE
<brendyn>But it's ok, ill start by linking to my branch and reviewers can email me with what they want.
<Soheil[m]>Is this config ok to install Nvidia?
<Soheil[m]>(I need a non-free settings for temporary work…)
<Soheil[m]> https://paste.debian.net/1213271/
<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>as far as webkitgtk, I have this snippet to use earlyoom on my machine https://git.sr.ht/~efraim/guix-config/tree/master/item/3900XT.scm#L125
<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
<futurile>hi all
<paul_j>Good morning!
<efraim>hello!
<Soheil[m]>efraim: Thank you ❤️
<Soheil[m]>guix:85a16c0
<Soheil[m]>nonguix:daa5894
<efraim>it looks like webkitgtk is already built on bayfront for that commit
<attila_lendvai>good morning guixers
<attila_lendvai>sneek: later tell dhruvin i have submitted my patch to git-authenticate: http://issues.guix.gnu.org/50814
<sneek>Will do.
<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
<raghavgururajan>Hello Guix!
***Kimapr[ii] is now known as Kimapr[i]
<roptat>hi guix!
<roptat>could someone restart the build of classpath on berlin? it failed because of "cannot build missing derivation": https://ci.guix.gnu.org/build/850636/log/raw
<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>hm, github is fine?
<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.
<roptat>sorry about that :/
<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... :)
<nckx>Hullo Guix.
<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/**
<attila_lendvai>thanks for the kind words! will do.
<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
<slyfox>i'm using https://issues.guix.gnu.org/48434 patch locally to always load expected source files from ./pre-inst-env
<futurile>OK, I'll play around. It's probably because I'm still quite confused about environment, so must be polluting somehow
<attila_lendvai>so, there's apparently a Slime backend for guile... somewhat functional even (no sldb, nor threads): https://github.com/ecraven/r7rs-swank is anyone using it?
<podiki[m]>that sounds cool, I like slime
<Noisytoot>Why not use Geiser?
<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>i may as well write the sldb interface to "fix" 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>What's the difference?
<nckx>Both should work.
<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>thanks @nckx
<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.
<thorwil>those are in my local package path
<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>😛
<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 :-)
<nckx>Zweet.
<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 😛).
<sneek>Will do.
<nckx>sneek: later tell lfam: Really hoping the answer isn't ‘First, download Debian…’.
<sneek>Got it.
<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)?
*nckx AFK.
<thorwil>even `guix gc -d 1d` did not get rid of lilv
<thorwil>single user system. never installed anything as anyone but plain user
<thorwil>BBL
<awb99>thanks @nckx
<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.
<efraim> https://git.sr.ht/~efraim/guix-config/tree/master/item/3900XT.scm
<awb99>thanks @efraim
<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
<efraim>substitutes*
***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>Use a UUID
<maximed>The warning is issued by operating-system-bootloader-crypto-devices
<raghavgururajan>Ah yes, I was using uuid. Wanted to try "/dev/sda1".
<raghavgururajan>Cool, I still stay with uuid.
<maximed>Using /dev/sda1 is somewhat fragile w.r.t. adding/deleting partitions, inserting extra disks ...
<maximed>I presume that's the reasoning
<maximed>Or maybe GRUB doesn't understand /dev/sda1
<raghavgururajan>Makes sense.
<nckx>I get that error too but have never had trouble booting. This is not legal advice.
<nckx>*warning
<raghavgururajan>I see.
<raghavgururajan>nckx: Is that before or after you corebooted you device?
<raghavgururajan>Actually. that shoudn't make a difference. Never mind!
<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.
<GNUHacker>Installing Guix system by first time :)
<awb99>yes
<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>then I see 3 channels.
<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 😉
<GNUHacker>:P
<awb99>yes I did run guix pull
<nckx>Then it's expected that you won't have your --channels from the previous run.
<awb99>aha
<awb99>I thought guix pull just gets the last updates from all channels.
<nckx>Yes.
<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
<awb99>ahhh
<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.
<nckx>awb99: ☝ answer :)
<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>Well, so is Guix.
<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.
<awb99>cool.
<awb99>many thanks @nckx
<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.
<thorwil> https://ci.guix.gnu.org
<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)?
<nckx>I find this very odd.
<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>Downloading https://ci.guix.gnu.org/nar/lzip/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.
<nckx>o_O
<thorwil>it certainly downloads *stuff*. but it looks like it’s thrown away afterwards
<nckx>Must be.
<thorwil>as the same command 2 times in a row has the same output
<nckx>You should report this as a bug.
<thorwil>happened weeks ago
<nckx>No response?
<nckx>I only searched the bug tracker for lv2 .
<nckx>I should have, y'know, searched for lilv.
<nckx>No response :(
<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> (http://issues.guix.gnu.org/49811 for the IRC logs)
<nckx>civodul: Any ideas?
<nckx>I gotta go (actually had to leave 5mins ago but this was weird enough to keep me :) Sorry, and good luck…
<nckx>)
<nckx>o/
<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
<thorwil>nckx: heh, thanks"
<thorwil>gotta run myself
<civodul>nckx: not really :-)
<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>what does "date --version" say?
<podiki[m]>8.32
<civodul>or rather, "ldd $(type -P date)"
<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> linux-vdso.so.1 (0x00007ffd391fb000)
<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.)
<cbaines>civodul, cool, thanks
<civodul>podiki[m]: hmm i can observe this timezone problem even in a VM
<civodul>could you report it?
<podiki-irc>sure. I take it's a core-updates-frozen branch problem? or did you try on a different branch too?
<civodul>oh crap
<podiki-irc>I'll put what I put in this chat roughly, anything else helpful?
<civodul>podiki-irc: i'll report it :-)
<civodul>we have a problem
<podiki-irc>okay!
<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>podiki[m]: https://issues.guix.gnu.org/50830
<civodul>thanks a lot for bringing it up!
<civodul>good that the rest works for you :-)
<podiki-irc>happy to help!
<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>not good!
<civodul>(unless you happen to leave on a timezone that's UTC with no DST, if such a thing exists)
<civodul>*to live
<podiki-irc>at least I'm only 4 hours off
<vagrantc>yeah, not sure sane timezones really exist
<civodul>:-)
<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>that's something we need to discuss
<civodul>the sooner the better IMO
<civodul>but it's good that we're having more testing before that
<civodul>as you just showed :-)
<lfam>I could add a tzdata update to the "rebuild the world" push
<sneek>lfam, you have 2 messages!
<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>Okay.
<nckx>lfam: But on Debian?
<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>OK.
<nckx>It's not a result of using Debian's kernel .config as base, got it.
<lfam>No
<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>Uh, yes!
<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>I see nckx
<lfam>Can you clarify what is changed in the latter difference, nckx?
<nckx>I'm not quite sure what you mean, but here's the full diff of ‘side effect’ changes I had to git commit -p around: <https://paste.debian.net/hidden/36de79d5/>
<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.
<lfam>Yeah
<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>Honestly lfam
<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
<nckx>Right.
<lfam>It would be nice to talk about it as a distro
<vagrantc>i'm game to discuss kernel configuration :)
<vagrantc>and i wear a few relevent hats
<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?
<vagrantc>nckx: yup
<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
<vagrantc>lfam: and yes :)
<nckx>OK, so it is deliberately maintained by a competent human?
<nckx>That wasn't always clear.
<nckx>Ahum.
<nckx>:)
<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
<nckx>Most distro kernels do.
<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>right
<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>It's true
<lfam>There are already a few overrides in the Scheme
<lfam>Is that what you're referring to?
<vagrantc>yeah
<lfam>Right
<vagrantc>i'd suggest leveraging that even more, basically
<lfam>Yeah
<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?