IRC channel logs


back to list of logs

<gabber>does a file-like object have a path? if so, how can i access that?
<unmatched-paren>gabber: the path is returned when it's ungexped
<unmatched-paren>that's the whole point of a file-like :)
<unmatched-paren>csepp: Your wish is my command :P
<csepp>unmatched-paren: thankssss! UwU
<csepp>is that attachment borked or is that just mumi being weird again?
<gnou_liber>I have two other questions: The first: How do I uninstall the Network Manager applet? The second: How do I change the sound server from pulseaudio to pipewire? All this in the Guix system.
<unmatched-paren>csepp: I'll add magit stuff tomorrow; it's late here.
<lechner>Hi, for packaging, do we start with Git revision 0 or 1, please?
<z4kz>just wanted to say that I noticed `apt install guix` seems to be available by default on debian and ubuntu, which is kind of cool
<lechner>z4kz: applause goes to vagrantc!
<lechner>Hi, do we ever encode dates as part of Git package versions?
<vagrantc>i've sometimes used a format roughly like guix describe ... which is not exactly date-based
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, itd_ says: Thanks. :) (Not sure if it is still true, but: "Debbugs claims to provide a per-bug subscription feature [...] However, this feature doesn't work [...]" )
<vagrantc>heh, that felt like a while ago ... guess i use /me too much
<rabajaj>Hello folks, I am looking for builds logs or guix package, to see whether the last few builds were reproducible or not. Any help would be appreciated.
<vagrantc>rabajaj: not sure about getting older versions, but this at least gives the current known status:
<vagrantc>rabajaj: and you can look at older commits ... somewhere
<vagrantc>i tend to get a little lost navigating
<rabajaj>I got this link but it give me 504 gateway time out, is it just me?
<vagrantc>good reminder to look at the current status, haven't checked myself in a while
<vagrantc>sometimes it is slow
<vagrantc>and some days better than others ... :/
<rabajaj>maybe I should try reaching to the website tomorrow :P
<rabajaj>there it is
<rabajaj>thanks vagrantc++
*vagrantc is happy to see folks poking at reproducibility in guix :)
<lechner>vagrantc: thanks!
<vagrantc>lechner: oops, i meant git describe :)
<vagrantc>but i think guix describe is similar, actually
<vagrantc>lechner: strictly speaking, i think that is a bit outside the convention
<vagrantc>normally it's just oldversion-guixrevision-githash i think ...
<vagrantc>$ git describe
<vagrantc>though i'd use something like 1.3.0+26190-e61660c78f
<vagrantc>the "g" just seems some weird thing git adds
<lechner>vagrantc: i have the same affliction; i read 'git'!
<vagrantc>the most important thing is the version always increments ...
<vagrantc>git describe *technically* might not increment, but it seems remarkably unlikely
<vagrantc>resetting git history or in some cases weird hiustory rewrites
<lechner>vagrantc: thanks! with your encouragement i changed it from something the Golang importer produced to the standard for Golang package in Guix, I think
<lechner>Hi, from a reproducibility perspective, is this output more desirable than the intended one? gocryptfs [GitVersion not set - please compile using ./build.bash]; go-fuse [GitVersionFuse not set - please compile using ./build.bash]; 0000-00-00 go1.17.11 linux/amd64
<brendyn>phodina[m], i saw you are packaing lutris. did you have any success with that?
<brendyn>no for some reason `guix search lutris` is hanging with no output. strange
<brendyn>should be no results but it wont return to terminal
<podiki[m]>hrm, looks like has an expired certificate
<podiki[m]>ah, was recently renewed, just needed to clear some cache
<civodul>Hello Guix!
<Lumine>Good morning #guix
<Lumine>There's an ancient poem which says: "I need coffee."
<efraim>cbaines: mrust commit worked with qemu for aarch64, testing to see if I can build rust-1.55 using the qemu-ed rust-bootstrap. also testing Mark's reduced requirements rust-bootstrap patch, so far looks great
<efraim>I've also queued a patch for guix-staging to unpack rust crates far less verbosely
<ennoausberlin>efraim: Can you elaborate a little how the rust build chain works. If I try to install ripgrep or fd-find it will try to build multiple rust versions in advance and finally fails after hours (on aarch64). Does your commit improves this situation? Can it be improved?
<efraim>ennoausberlin: due to an oversight rust currently doesn't build on aarch64. If everything works then we'll push a new version of the rust bootstrap chain to the build farm for it to build out and then merge that into master.
<efraim>the initial rust in the chain, rust-bootstrap, is built with a different project called mrustc, which implements enough of rust to get rust-1.54 bootstrapped so it can build itself, and we continue on from there.
<ennoausberlin>efraim: So this process is unavoidable to bootstrap the current rust reproducible. I understand. I would happily test it on my Pi400 and the pinebook pro as soon as everything is merged.
***Dynom_ is now known as Guest8917
***wielaard is now known as mjw
<rekado_>trying to build ghc@4 with not only an older gcc 2.95.3 but also with the bootstrap glibc, but I’m getting this error when running a tool: Inconsistency detected by dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
<rekado_>does this mean that I somehow have different versions of libc at play here
<civodul>uh, no idea
<unmatched-paren>nckhexen: to confirm; there's absolutely no reason why someone would want to ``guix install guix'', right? zimoun seems to think there might be
<efraim>can you set implicit-inputs to #false?
<efraim>rekado_: ^
<zimoun>unmatched-paren, yes. To use the Guile library. :-)
<unmatched-paren>zimoun: couldn't you just ``guix shell guix'' then?
<zimoun>I agree that it is a bad idea to install the package guix in the profile. But if it is so bad, why expose it with define-public and just not define it. Therefore, my point is to replace the error by a warning.
<zimoun>A BIG warning :-)
<civodul>or just hide it?
<civodul>(i didn't follow the discussion tho)
<pkill9>zimoun: so people can get a development environment for guix
<zimoun>pkill9: ah yes, for sure. :-) In that case, turn off the installation part :-)
<zimoun>My point considering the patch in question is just to replace the error by a BIG warning.
<civodul>i read here that the 'staging' merge caused regressions for aarch64; are there more details in a bug report or in a thread somewhere?
<nckhexen>zimoun: Why, if it's a bad idea?
<sneek>nckhexen, you have 1 message!
<sneek>nckhexen, lechner says: Will you please share your visual Emacs lambda mod? Thanks!
<nckhexen>When my fsck isn't taking 10+ minutes and my / not probably hosed, sure.
<nckhexen>Has anyone actually hibernated a Guix System with swap on LUKS now?
<nckhexen>(Those two messages not related, or at least not in the worrying direction.)
<zimoun>nckhexen: I do not understand the question. It is about bug#58583 where I think a BIG warning is better than raise a total error.
<pkill9>nckx: does hibermation work on non LUKS systems?
<nckhexen>zimoun: Yes. The question was why?
<zimoun>why what?
<nckhexen>pkill9: I never power off, maybe once a month to update my kernel.
<nckhexen>Why a warning.
<zimoun>because sometimes it is useful to have the package guix considered as a Guile library in a profile.
<nckhexen>pkill9: Meaning I hibernate several times a day. ;-)
<zimoun>otherwise the correct fix is to remove the installation part of the package guix and provide a warning message, and not an ad-hoc error raising.
<pkill9>somedayi want to make a script that collects all logs into one place
<pkill9>even application.logs, it will be beautiful
<nckhexen>zimoun: You still didn't say why you think it is correct. Could you give a concrete example of why you'd install the older packaged as a library? Maybe we can detect that.
<nckhexen>*packaged guik
<zimoun>for testing, for debbuging, for easing extensions writing, etc.
<nckhexen>E.g. a 'library' (:lib?) variant without /bin/guix. Sorry, obviously on phone.
<zimoun>Well, I will not spend hours on that. :-) I will be annoyed if installing guix in a profile raises an error. I can live with it and I will find a way. I also consider the raise of an error is at the wrong level because it is an quick ad-hoc.
<nckhexen>What hours?
<zimoun>:-) I mean discuss a length… as we are doing right now ;-)
<nckhexen>If you don't want to discuss it, that's fine, but it's reasonable to ask for clarification of the statements you did make.
<zimoun>I mean, I ask to be a warning, not an error. Please clarify why an error is more reasonable than a warning in the bug tracker. :-)
<nckhexen>It's not fair to demand what you refuse.
<zimoun>I am not refusing to do it. I am refusing to do it here and right now. I miss the point. The bug tracker is not the appropriate place to discuss patches.
<zimoun>Moreover the patch submission is motivated by «It's a wee bit of a hack, but after some discussion on IRC, we seemed to come to the conclusion that this would be the best thing to do» so I can be in a position to ask references to these IRC discussions. ;-)
<jonsger>civodul: it seems that rust@1.54.0 no longer build on aarch64. Can't link to the bug report
<antipode>civodul,others: /me tries out to rewriting mkdir-p/perms with openat etc.
<civodul>jonsger: ok, thanks
<civodul>antipode: neat
<jonsger>cant find a built of it for aarch64 on CI
<zamfofex>Hello, Guix! I’m planning to submit a patch to update Minetest and MineClone 2 (and perhaps eventually to introduce MineClone 5), but I have a few questions. It seems ‘irrlicht-for-minetest’, ‘minetest’ and ‘minestest-data’ are all closely related in version number (e.g. Minetest versions seem to require specific versions of their Irrlicht fork). Should I update all of them in a single commit?
<zamfofex>Also, regarding MineClone 5 (a fork of MineClone 2), would it be sensible to name it ‘minetest-mineclone5’, even though MineClone 2 doesn’t have the “2” in its package name?
<mirai>in a 'shepherd-service', what user runs the code in the 'start' and 'stop' fields?
<mirai>I'd like to know how does a shepherd-service selects the user-account to run the process (nginx runs under the 'nginx' user, mpd as 'mpd' user and so on)
<lechner>nckhexen: Is this a no, for root?
<nckhexen>What's 'a no'?
<nckhexen>zimoun: Discussing patches on #guix is perfectly appropriate. You aren't obligated to respond here & now, or even at all, but please be kind when you do.
<nckhexen>lechner: IIRC guix removed valid ~ root when using --root, here.
<nckhexen>Here being the system I can't currently use 🙂
<nckhexen>I don't think that should ever happen.
<nckhexen>I understand lilyp's point but I think it's subtly missing yours (or I am!): .cache *wasn't* deleted, the links are not dead, and profile roots can be placed anywhere in ~, not only in .cache.
<nckhexen>I'll have to verify that on a System but does it make sense?
<lechner>nckhexen: i am not sure. lilyp may not be missing my point; rather i'm missing hers
<lechner>good luck on your recovery
<lechner>Hi, what is the remedy for this when building Guix, please? ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <package>>: record ABI mismatch; recompilation needed
<lechner>It's in error: failed to load 'gnu/packages/texinfo.scm
<unmatched-paren>lechner: make clean-g o
<ekaitz>lechner: I make clean and recompile everything but it might be too much
<unmatched-paren>mako clean-go && make -j$(nproc)
<nckhexen>lechner: Yes, it's possible I am too. And thanks!
<lechner>ekaitz: too late
<lechner>unmatched-paren: thanks!
<zimoun>nckhexen, unmatched-paren: about the patch #58583, I do not have a strong opinion. As I said, «I would prefer a warning». If you consider that error is a better choice, then that’s fine. :-)
<nckhexen>lechner: Just to finish the story: fsck had been looping for over an hour, so I gave up & reset the machine, mentally preparing to reinstall, and... it booted without errors?? Ah, bcachefs.
<zimoun>nckhexen: I wrote «The bug tracker is not the appropriate place to discuss patches.» where there is a “typo“. It was a rhetorical question (withtout the question form, neither the question mark?). Argh! :-) I am fine that discussions about patch happen on #guix. The most important is that patches are included. Just to note that it could help to follow the high volume if a reference to #guix log
<zimoun>is provided when necessary in patch discussions from the bug tracker.
<lechner>nckhexen: that is very long; is this on a journaling file system?
<zimoun>Last, I am sorry if I appeared not kind. Maybe, something had been lost in translation.
<lechner>zimoun: you are fine
<lechner>nckhexen: except for stupid things like untarring something in root, i have never had a hosed filesystem
<unmatched-paren>zimoun: i would have tried to get a log link, but the log search doesn't work, and I couldn't remember when the discussion was :)
<lechner>nckhexen: good to hear things are working now!
<nckhexen>zimoun: If you weren't angry above, I misinterpreted your tone, and sorry for that.
<lechner>Hi should I be seeing no code for module (semver ranges) when building Guix?
<nckhexen><zimoun: Just to note...> Oh I completely agree.
<nckhexen>lechner: Yes, but I think it was just a loop (either on disc or bug in the code). I don't think it would ever have finished. But I'll never know!
<zamfofex>Hmm, this doesn’t seem like a good thing. Thankfully I had seen someone making the same kind of mistake before, so I don’t feel as embarassed. (Though I still feel embarassed!)
<nckhexen>lechner: It was 'hosed' as in I/O errors, not just as in oops I oopsed all my files.
<nckhexen>zamfofex: Thah person was also far from the first :)
<zamfofex>Now, which kind of encantation am I supposed to cast upon ‘git send-email’ to prevent that from happening in the future? 😅
<nckhexen>(See my mail for how to 'fix' this when it happens.)
<nckhexen>zamfofex: I'm not even sure what happened.
<nckhexen>Did you follow the dance in 'submitting patches'?
<zamfofex>I tried my best to, at least. Clearly I wasn’t thorough enough in it.
<nckhexen>Did it involve waiting for a bug number before invoking git send-email -3? Otherwise, that's what (didn't) happen(ed).
<zamfofex>I don’t understanding what “waiting for a bug number” means, so I don’t think so.
<nckhexen> ?
<zamfofex>Is there anything specific that I need to do to achieve that? I was hoping it’d be done automatically.
<zamfofex>The command I ran (in full) was: EDITOR=nano git send-email --cover-letter --annotate origin
<nckhexen>I thought it would be explained in a bit more detail.
<unmatched-paren>zamfofex: have a look at this patch:
<unmatched-paren>it expands upon "Sending a Patch Series" and should make things a wee bit clearer
<nckhexen>Heh, I was going to use that thread as example.
<nckhexen>(Implicit LGTM: given.)
<zamfofex>Oughtn’t it have been sufficient to mark each email as a reply to the previous one, without needing information about the issue number?
<zamfofex>s/have been/to have been/
<nckhexen>Nitpick: should we provide an example .git/config (setting format.useAutoBase, setting the default address, etc.) instead or in addition? It's declarative.
<nckhexen>zamfofex: Sure. It isn't.
<unmatched-paren>zamfofex: more advanced patch interfaces do that
<unmatched-paren>(such as, and probably a few others)
<unmatched-paren>but debbugs doesn't
<nckhexen>Debbugs, meet zamfofex. zamfofex, meet debbugs. Speak slowly and don't use big words.
<zamfofex>I see! I was caught in *debbugs succ*, then, I guess. 😅 Fair enough, I suppose.
<zamfofex>I feel like there should be a way to automate this process, though. It feels inconvenient to have to open my email client to check the issue number. I want to just use ‘git send-email’ directly without having to go through ‘git format-patch’.
<unmatched-paren>zamfofex: i don't think there is a way, unfortunately
<zamfofex>I suppose the best way to automate it would be for debbugs to accept reply emails properly, huh? 🤔
<zamfofex>I think it wouldn’t be unreasonable if it were common practice for multiple patches to be sent in the same email, actually, now that i think about it. Though I suppose it just isn’t common practice.
<mirai>I'm trying to write a service manifest, is there a better way of expressing this? (
<nckhexen>zamfofex: It's not that you're wrong about any of this—you're not—but Guix doesn't operate that Debbugs instance & there's not a tonne of enthusiasm to self-host one IMO. So we live with what the GNU giveth.
<mirai>I've looked at the match module though I have no idea how to properly use it here
<zamfofex>nckhexen: That is fair enough, of course. And I suppose sending multiple patches/commits in a single email is not feasible because it goes against common practice, is that right?
<nckhexen>It's tolerated, but I think a solid majority of Guixers prefer separate mails (I do, but it's not a preference I can defend at length, I just do :).
<nckhexen>Probably disappointing answer. Sorz.
<nckhexen>You won't be yelled at if you do, but someone might innocently ask you why.
<zamfofex>I understand. Is there some practical advantage of it? E.g. perhaps tooling makes it easier to deal with in order to merge patches, or is it a matter of aesthetics, so to say?
<apteryx>do we have a java application that runs as CLI that has a lot of java inputs (run time dependencies) ?
<unmatched-paren>zamfofex: pretty sure it makes it usable with ``git am''
<unmatched-paren>not sure whether am can handle a single email with many patches
<zamfofex>I see. Thank you for bearing with me and answering my questions, I really appreciate it! One last thing: Do I have to do anything regarding my patches for them to ba validly acceptable (e.g. resending them) or is it fine as is this time?
<nckhexen>If you mean wld and friends: no need to resend. I already merged them, even if the Web UI does a poor job at reflecting that <>.
*nckhexen also a heavy emacs (mu4e) + ‘git am’ user that works better with separate mails, but then my routine assumes them, so it might be somewhat circular.
<unmatched-paren>sneek: later tell gabber: the home-emacs-service-type patchset open in my inbox right now is yours, right?
<unmatched-paren>sneek: later tell gabber: i think it might be best to use file-likes for init and early-init
<unmatched-paren>sneek: later tell gabber: also, how about adding a (native-compile? ...) field to emacs-configuration which, if enabled, builds the packages with the emacs-minimal input rewritten to whatever package is in the (emacs ...) field of emacs-configuration?
<unmatched-paren>sneek: botsnack 4 u
<mroh>r.i.p. powerpc64le
<unmatched-paren>mroh: huh?
<civodul>yeah i don't get it
<unmatched-paren>it's not dead, it's sleeping!
<efraim>sneek: later tell ennoausberlin if you want to test the rust patches then you can try 'guix time-machine --branch=staging -- build ripgrep'
<sneek>Got it.
<efraim>sneek: botsnack
<mroh>d641115e20973731555b586985fa81fbe293aeca on berlin.
<efraim> if anyone wants to follow the rust patches for staging for x86_64
<efraim> is probably the one on aarch64
*civodul sent release progress update
<unmatched-paren>zimoun: v2 of "Sending a Patch Set" expansion sent with your suggested changes :)
<unmatched-paren>zamfofex: by the way, you should use --base=auto with git send-email/format-patch to make it easier to merge
<unmatched-paren>(I only recently learned this, so it's not in v1 of that patch)
<apteryx>idea tested: Class-Path can refer to other .jar via a file:/// absolute file path
<pkill9>what's the best way to use custom tools in your guix home i wonder
<ae_chep>"custom tool"?
<pkill9>I'm making a sandboxing wrapper which takes a packages and returns a wrapper that runs it's binaries in a sandbox
<pkill9>and I want to add those wrappers in my guix home ocnfiguration
<unmatched-paren>pkill9: you could probably write it as a Guix extension
<unmatched-paren>and then simply write a package for it
<pkill9>so basically as an additional channel?
<unmatched-paren>well, you can write packages in your home.scm
<unmatched-paren>no need for them to be in a channel
<tricon>pkill9: you could put it at a path and modify your `$GUIX_PACKAGE_PATH' instead of using a channel.
<pkill9>I don't want the sandboxing tool to be in home.scm
<pkill9>I want to keep it in a separate repository
<pkill9>the situation I'm thinking of is if I run `guix home recofnigure` without having pulled any additional channels
<unmatched-paren>pkill9: sure, you can write a package in your home.scm that pulls from that repo with git-fetch
<pkill9>since I manage channels *in* home.scm
<unmatched-paren>to write a guix extension, you put a module in guix/extensions/*.scm
<pkill9>what do you mean pulls from that repo
<unmatched-paren>this module should define a command (with ``(guix scripts)'''s ``define-command'') called ``guix-*''
<pkill9>I think that would be a good place for it yes
<unmatched-paren>and then the module should be installed in #$output/share/guix/extensions
<unmatched-paren>this will be picked up by the implicit GUIX_EXTENSIONS_PATH search path
<unmatched-paren>and then ``guix foo'' will run the ``define-command''ed command
<unmatched-paren>see the ``gwl'' package for an example of a guix extension
<unmatched-paren>unfortunately guix extensions aren't documented yet, last i checked
<pkill9>what i want is to be able to run `guix home reconfigure` without having previously run anything and have it pull my wrapper script and use that if it hasn't already been downloaded/installed
<unmatched-paren>pkill9: that's what defining a package inside your home config will do
<ae_chep>if "guix environment" is deprecated, why does the manual online refer to "guix environment"?
<unmatched-paren>ae_chep: where?
<unmatched-paren>it shouldn't
<unmatched-paren>hmm, are you looking at the release manual by any chance? :)
<ae_chep>unmatched-paren: > development . Is it the release one?
<unmatched-paren>ae_chep: that's the devel one, so it shouldn't refer to guix environment
<ae_chep>curl | grep "guix environment" should be the answer then
<unmatched-paren>manual/en/guix.html is the release manual
<unmatched-paren>manual/devel/en/guix.html is the devel manual
<ae_chep>that solves it. Thanks
<ae_chep>I just can't get anywhere using `info` so I end up relying on the web doc
<unmatched-paren>yeah, it seems like using that command with devel only shows up results in the "Invoking guix environment" section
<unmatched-paren>ae_chep: try ``pinfo''
<ae_chep>I mean as a documentation-viewing program I struggle a lot with it
<unmatched-paren>yes, ``pinfo'' is an alternative browser
<ae_chep>pinfo may be better. I'll test it. Thank you
<unmatched-paren>that uses vi-like keybindings
<superkamiguru>I have been trying to figure out using a 9p filesystem in a Guix system config, but am a bit stuck at the moment. Does anyone have a good sense of how gnu/system/vm.scm is able to use "9p" as the filesystem type?
<bdju>any other sway / wl-clipboard users here? suddenly I can't seem to copy any text to primary or clipboard. pretty big show-stopper... I did run updates yesterday but I thought things were working until pretty recently.
<unmatched-paren>bdju: they're working for me
<bdju>thanks for confirming
<bdju>I have over 220 days of uptime so maybe a sway restart or reboot would fix it, but I fear something else will break if I do that, hehe.
<bdju>I did kill a bunch of wl-copy processes and close qutebrowser, both things have helped resolve a similar issues with clipboard weirdness in the past
<unmatched-paren> i the only person who just shuts down when they're finished using the computer? :)
<unmatched-paren>everyone seems to have loads of uptime
<bdju>sometimes you have stuff you want always running, or it's hard to get everything to restore exactly how you want after a reboot so you put it off
<unmatched-paren>this is bizarre: i tried doing a home-emacs-service-type and it still isn't creating the socket right
<unmatched-paren>i wonder if it's just that emacs isn't loading my plugins properly...
<unmatched-paren>which is odd, as i definitely set EMACSLOADPATH and EMACSNATIVELOADPATH in #:environment-variables
<lechner>Hi, for a Golang executable with and import path ending in /v2, our Go build system produces an executable named 'v2'.
<unmatched-paren>lechner: Oh, that's weird.
<unmatched-paren>I thought Go executables were named for their .../cmd/FOO path.
<unmatched-paren>Not the end of the import path.
<lechner>i dropped the /v2 but i don't think that's quite the golang convention
<unmatched-paren>dropping /v2 could be annoying if /v1 is packaged
<lechner>even for executables?
<unmatched-paren>Oh, wait, never mind.
<lechner>still seems like a bug, doesn't it?
<unmatched-paren>or maybe a bug in go itself...?
<unmatched-paren>can you point me to the repo? I'll download it and try to go build it
<lechner>unmatched-paren: just this recipe please add /v2 in gocryptfs #:import-path
<lechner>unfortunately, i am not enough of a go pro if the pun is permitted
<florhizome[m]>I‘m getting a tls error when reconfiguring, what could this be about 🤔
<lechner>florhizome[m]: what's the error, please?
<unmatched-paren>florhizome[m]: tls errors are usually transient network errors
<florhizome[m]>Ok just worked
<unmatched-paren>yeah, the networking errors usually don't make much sense
<unmatched-paren>i would send a patch but i have no idea how i'd catch and diagnose the error
<jonsger>any idea why this does not build? I did in analogue to the haxe package, where this move does work. The error message is a bit confusing
<jonsger>Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages gnome)) #f))'.
<unmatched-paren>jonsger: sorry, no idea
<unmatched-paren>i've seen that error before, but it seems to just mean something weird is going on
<lilyp>nckhexen, lechner: My point is that guix should not delete any of the "precious" roots, since it still holds a reference in /var/guix
<lilyp>"precious" being those outside of ~/.cache – though if you manually manage your roots, it may drop one of those
<lilyp>i.e. guix package --profile=~/.somewhere will be collected
<lilyp>another reason for my multiple profiles suggestion
<zamfofex>jonsger: I just came across that exact error message while preparing my velox patches! In my case, it turned out that I had written ‘@items’ instead of ‘@item’ in the package’s description.
<ennoausberlin>Hi. I installed emacs-magit into guix home. It has git as dependency and installs it in my profile, too. This way it shadows the git from the underlying distribution and I am unable to clone/pull from my gitlab, because of missing server certificate. How can I tell the guix git to use the same certs as the original git?
<sneek>Welcome back ennoausberlin, you have 1 message!
<sneek>ennoausberlin, efraim says: if you want to test the rust patches then you can try 'guix time-machine --branch=staging -- build ripgrep'
<unmatched-paren>ennoausberlin: Hmm. Magit shouldn't be propagating git.
<unmatched-paren>ennoausberlin: yep, it doesn't propagate it.
<unmatched-paren>Can you do ``command -v guix''?
<ennoausberlin>unmatched-paren: command -v guix or command -v git?
<unmatched-paren>ennoausberlin: guix
<unmatched-paren>Okay, that's fine.
<unmatched-paren>Can you do ``guix edit emacs-magit'' and paste the ``emacs-magit'' package into
<ennoausberlin>git is "/home/enno/.guix-home/profile/bin/git"
<unmatched-paren>that's also fine
<jonsger>zamfofex: I don't changed stuff like this
<unmatched-paren>lechner: well, ``go build'' in a guix shell with gocryptfs seems to spit out a ``gocryptfs'' binary just fine... very odd.
<lechner>unmatched-paren: did you add the /v2?
<unmatched-paren>the go.mod lists /v2
<unmatched-paren>so i'm pretty sure it'd use that as the import path
<unmatched-paren>ennoausberlin: yup, see, git isn't propagated hee
<unmatched-paren>do you have nss-certs installed system-wide?
<ennoausberlin>unmatched-paren: Just a moment
<lechner>unmatched-paren: i meant our package spec, like this
<lechner>unmatched-paren: that produces 'bin/v2'
<ennoausberlin69>unmatched-paren: I did not install nss-certs. Can it coexists with the existing debian certs?
<unmatched-paren>ennoausberlin: Oh, you're on a foreign distro...
<unmatched-paren>maybe try a ``guix shell emacs emacs-magit nss-certs'' and see if it works
<ennoausberlin69>unmatched-paren: Yes. Debain 11 aarch64
<lechner>lilyp nckhexen: i think i am too new to follow. as far as i can tell, all my user roots are being collected because my home folder is inaccessible to the daemon
<unmatched-paren>lechner: yes, i know
<unmatched-paren>but it doesn't appear to be a go bug, since ``go build'' spits out ``gocryptfs'' as expected
<lechner>unmatched-paren: i see
<ennoausberlin69>unmatched-paren: No does not work either
<unmatched-paren>then, i'm not sure what to do, sorry
<unmatched-paren>what's the error you get from magit?
<unmatched-paren>ennoausberlin69: hmm, wait, is your normal ``git'' command installed from debian?
<unmatched-paren>if so, maybe try ``guix shell git'' and try using git in there
<lechner>you are a detective!
<ennoausberlin69>I have one git in /usr/bin/git and one in my home profile. I don't even know how to remove the home profile one.
<unmatched-paren>ennoausberlin69: Okay, and using ``git'' normally works?
<lilyp>lechner: try doing the following: first create some profile (using guix pull or whatever), then unmount the volume, then do sudo guix gc --roots
<ennoausberlin69>I did not try magit it all, just git from shell. And there the home profiles git is used, because its earlier in the path I guess
<unmatched-paren>ennoausberlin69: oh
<lilyp>it should still list a per-user profile in /var/guix
<unmatched-paren>ennoausberlin69: okay, so, what error do you get from git?
<ennoausberlin69>I try to convert my doom emacs config in a guixy one. I probably do some mistakes during this experiment.
<ennoausberlin69>fatal: unable to access '': server certificate verification failed. CAfile: none CRLfile: none
<unmatched-paren>ennoausberlin69: try doing the same with /usr/bin/git, maybe
<rekado_>efraim: I did set implicit-inputs to #f; I think the problem is due to the fact that gcc 2.95.3 is built with the latest glibc, so I suppose I can’t just use an old glibc.
<ennoausberlin69>unmatched-paren: with the /usr/bin/git it works, but shouldn't it work with the guix one as well?
<unmatched-paren>sorry, i'm not sure how to proceed here
<lechner>lilyp: i'm not familiar with the layout in /var/guix. are you saying that i misinterpreted what happened to me?
<ennoausberlin69>unmatched-paren: never mind. It is not a big deal, I was just curious what the problem is.
<lechner>ennoausberlin69: somehow your Guix Git cannot find the certificates either from Debian or from Guix, but am not familiar with your type of mixed setup
<efraim>I don't have the time for the previous run, but rust on staging took 197 minutes from rust-bootstrap to rust-1.60 on x86_64
***mark_ is now known as mjw
<apteryx>it'd be nice to have #:extra-modules instead of having to find and repeat the whole base modules every time
<apteryx>e.g., "#:extra-modules '((ice-9 match))" because I don't care/want to mess with the build system default ones.
<unmatched-paren>apteryx: yes, that would be nice
<rekado_>apteryx: +1
<unmatched-paren>apteryx: maybe #:modules should just append to the default modules instead of adding a new #:extra-modules
<unmatched-paren>lamp140: hi!
<apteryx>unmatched-paren: or #:modules will naturally be deprecated/forgotten over time
<gnucode>hey guix!
<unmatched-paren>gnucode: evening!
<apteryx>it seems extra-modules might conveys better what it does
<apteryx>but both are possible
<apteryx>if we change the meaning of #:modules, we could simply remove duplicates (and warn/report it)
<unmatched-paren>i think the %foo-build-system-modules should be treated as an implementation detail, though, so i don't think it should mention the fact that the modules are in fact additional
<apteryx>I agree
<lamp140>Can anyone look at the config.scm of my system?
<lamp140>I want the services httpd, mysql and php-fpm. My goal is to build a nextcloud cloud on my server using Gix.
<unmatched-paren>lamp140: sure
<lamp140>I made a configuration following the manual, but I do not find Mariadb for NextCloud to connect.
<lamp140>In addition, NextCloud's Wizard installer complains that it is not writing permission to make the installation.
<unmatched-paren>i think we'll need a nextcloud-service-type for nextcloud to work with a system.scm setup
<lamp140>my config.scm
<unmatched-paren>lamp140: by the way, i think you can replace (list (specification->package ...) (specification->package ...) ...) with (specifications->packages (list ...))
<lamp140>unmatched-paren: It would be very value
<unmatched-paren>hmm, sorry, i don't really know how to make sense of this; i haven't ever done any web server things
<lamp140>unmatched-paren: good idea
<lamp140>Is there any place with a collection of Gix system system configurations?
<unmatched-paren>here's mine: but i'm not sure whether there's an actual collection of system configs
<lechner>lamp140: someone here has FPM working with Apache. unfortunately, I use Nginx and am still chewing on it
<lechner>unmatched-paren: our go build system uses this invocation 'go install' with the import path. i'd like to try that. how did you crete your shell earlier, please?
<lechner>sory poor speller
<unmatched-paren>lechner: just ``guix shell go openssl pkg-config gcc-toolchain''
<unmatched-paren>and i did ``go build'', not ``go install''
<unmatched-paren>you might want to set the install destdir to ./tmp or something, i gues
<alsopodiki>a headsup that seems the matrix bridge has fallen down (not receiving/sending messages for several hours, other than a stray one or two)
<lechner>unmatched-paren: yeah i thought about that
<lechner>unmatched-paren: how did you get the source?
<unmatched-paren>lechner: just git cloned it...
<unmatched-paren>lechner: i think you'll want to set GOBIN
<podiki[m]>...hello? has the matrix bridge lost connection?
<unmatched-paren>i can still hear you ;)
<lamp140>lechner: I think it's working for me. I managed to run the <? Php
<lamp140> phpinfo ();
<faust45>hi guix!
<unmatched-paren>faust45: good evening!
<alsopodiki>oh wow, that message (about matrix bridge) is form a while ago, maybe it is just super slow....
<faust45>do any one here using nyxt browser? i just got a err on build 3-pre2 release
<alsopodiki>(at least that message went through from before, but still not receiving on matrix end)
<lamp140>lechner: Do you have NGINX with FPM?
<nckhexen>florhizome[m]: unmatched-paren: But Matrix doesn't see your reply, and messages from Matrix aren't making it here.
<unmatched-paren>i see.
<lamp140>The Matrix Bridge also fell to me
<nckhexen>podiki[m]: You can keep an eye on <>.
<nckhexen>lamp140: Did you at least see the ‘not sure if you are receiving this, but seems the matrix bridge is having problems’ on the Matrix end?
<unmatched-paren>faust45: it starts for me with the default setting
<faust45>unmatched-paren: i just trying to build from source tag 3pre-2 and got err
<lamp140>nckhexen: The last message I received by the Matrix is on October 13
<lamp140>I use the Syphon Client App
<nckhexen>I checked Syphon, it shows the same as here, podiki[m]'s message (above) from 17m ago.
<nckhexen>I mentioned it in #matrix, I think that's all we can do (and don't hold your breath).
<florhizome[m]><florhizome[m]> "I‘m getting a tls error when..." <- Not a problem anymore!
<florhizome[m]>Does anyone else have the problem that icecat forgets any configuration after upgrades?
<podiki[m]>...I think I'm back (matrix bridge seemed to be unresponsive for a while, reconnected)
<lamp140>Does anyone here have NextCloud installed on a Guix server and can help me with the configuration?
<podiki[m]>florhizome: not sure if you are receiving this, but seems the matrix bridge is having problems
<lechner>lamp140: I would like to get a Wordpress site up and running, but got busy and ended up with this untested code, which i got from someone. It was also at the very beginning of my exposure to Guix, so some parts---especially the absolute path in the include directive---would have to be examined.
<nckhexen>jonsger: The error message is ‘Wrong type (expecting string): #<procedure version ()>’, not that GNOME thing that shows up for everything. And VERSION is indeed missing.
<nckhexen>sneek: later tell jonsger: (file-name (string-append "thunderbird-" version "-checkout")) ; <-- here
<lechner>lamp140: in april a user named tricon reported having Wordpress up and running
<dlowe>I love guix. Except when I go to upgrade and it starts building a web browser from source.
<dlowe>But otherwise I love guix.
<unmatched-paren>dlowe: well, you can use --do-not-upgrade if you're using guix upgrade :)
<bdju>se I
<nckhexen>Our Gentoo emulation layer remains controversial.
<bdju>so I've rebooted and can't boot now, pre-mouet actions failed
<bdju>phone typing, sorry
<dlowe>unmatched-paren: okay, that's a useful tip, thank you
<unmatched-paren>nckhexen: [PATCH RFC] scripts: package: Rename --no-substitutes to --emulate-gentoo.
<lamp140>dlowe: 26 / 5.000
<lamp140>Resultados de tradução
<lamp140>sharing costs
<dlowe>I wish cwebbers --no-build flag could have gotten more traction
<lamp140>dlowe: sory
<lamp140>dlowe: sharing costs
<lamp140>lechner: thanks
<nckhexen>bdju: That can be only one of two things (well, or, in theory, both):
<dlowe>lamp140: kind of. except building from scratch only benefits me
<bdju>I am asked fde passphrase for my two drives and then after entering them I see ice-9/boot-9.scm:1685:16: In procedure raise-exception: pre-mount actions failed, then put into guile prompt
<nckhexen>Ah, that one.
<lechner>lamp140: and also back then a user named maximed alerted me to php-fpm being available in Guix when i could not find it, but i am not sure they were using it
<unmatched-paren>lechner: maximed is now antipode, btw
<bdju>I did a few months ago change out the second drive and modify my config.scm accordingly. perhaps put something in wrong. not sure
<nckhexen>Assuming you are 100% certain your passphrase (and keyboard layout!) is correct, bdju, how did you encrypt this disc? I don't think Guix supports all latest options.
<lechner>unmatched-paren: i knew it!
<bdju>layout and passphrase seem good
<nckhexen>Not promising, but there are modes that work with Guix. I meant, using which software.
<nckhexen>The installer?
<bdju>uh, this worked in the live system just hours ago
<bdju>I my root drive was set up in the installer, this second drive is just for storage and was set up separately
<nckhexen>Hm. Isn't there more output than that?
<nckhexen>(Than ‘pre-mount actions failed’.)
<bdju>I wish it would boot the system if this secondary drive is the only hang-up...
<nckhexen>It won't. There is no notion of an ‘optional’ mount yet.
<lamp140>lechner: I think PHP-FPM is working with Apache. I have to better understand how to configure PHP.ini to adjust according to the demands of NextCloud.
<nckhexen>bdju: Can you reconfigure without the secondary drive in file-systems?
<nckhexen>I'm not sure how to debug this remotely (I'm not convinced I can TBH), but it will be near impossible without a booting system.
<bdju>not sure how I can
*nckhexen last used LUKS2 when it was still called LUKS1.
<nckx`>This doesn't make any sense. I'm here, using You're here, not using florhizome[m] is speaking in #guix, using, and not appearing here. I don't get it.
<bdju>I didn't change anything recently, just hadn't rebooted in 228 days, so not sure which generation if any would work
<lechner>bdju nckhexen: i do not use LUKS (and am not yet learned in the Early Guile shell) but I have used these disks to recover from an occasional oddity
<bdju>also I had a previoes secondady drive with luks, dunno if it can boot with the drive gone if I use the old config
<nckx`>…and this message is going to be forwarded to #guix a day late and make even less sense. Oops :)
<nckhexen>There it is 😒
<nckhexen>bdju: If this *exact* LUKS container ever worked with Guix, the problem isn't what I thought it was, and I'm not sure what's going on.
<nckhexen>lechner: Thanks! It was my go-to rescue system before I started making my own. I used it once since, to install Guix System on a VPS with limited ISO options.
<bdju>nckhexen: here is my config change, and then I had it manually mounted in the live system but had never rebooted
<nckhexen>So it is a new LUKS container?
<bdju>I don't know LUKS well
<bdju>had old 1TB storage HDD woth LUKS, replaced with 2TB with LUKS (made fresh), rsynced files over
<nckhexen>If so, the newer cryptsetup could have (and likely would have) silently used newer defaults. Still, I don't understand why you could open it using Guix's cryptsetup on the live system.
<nckhexen>Right, so it's not the same drive.
<nckhexen>(Unlike, say, if you'd dd'd the whole shebang over to a new physical drive.)
<bdju>right, considered that but didn't do it
<podiki[m]>and I got your message here via matrix
<alsopodiki>sorry all for the delayed matrix spam; this is very confusing
<podiki[m]>(wow this is very confusing, especially for whenever/whoever sees this message with different context)
<nckhexen>alsopodiki: Just now? Then the delay isn't across the bridge, but within Matrix.
<nckhexen>bdju: This is grasping at straws, but from a Guix live system, could you try to cryptsetup open the new drive, but using $(guix build cryptsetup-static)/sbin/cryptsetup instead?
<nckhexen>I just want to make sure the cryptsetup in the initrd should be able to open it.
<bdju> I get this at grub btw, but passphrase should be fine
<bdju>booting a generation from august 2nd and it's looking better so far
<nckhexen>Right. That's expected if you use a too-recent LUKS(2) version. I forget the exact options/algos you can't use, but GRUB simply doesn't support them yet.
<nckhexen>bdju: 🤞
<bdju>hm okay
<alsopodiki>nckhexen no I saw your matrix message on matrix I think right away, but the response was delayed in coming through to libera
<nckhexen>I'm not even sure if that's a Guix GRUB problem or just a general GRUB thing. Last I checked (a while back), it was the latter.
<nckhexen>alsopodiki: Gotcha.
<bdju>so if I can get to a working system I should just not have it deal with this drive at all?
<alsopodiki>but irc->matrix doesn't seem to be working; so it is like last time but with an extra delay from matrix->irc for fun
<nckhexen>bdju: Well, to start, yes. Debugging this from within the initrd would be hell.
<bdju>okay sway started. I can use a real keyboard again
<bdju>the old generation seems good
<nckhexen>bdju: Presumably because it doesn't try to mount the new drive at all?
<bdju>right, yeah, I picked the first one before my git commit date where I changed the config for the new drive
<bdju>well, actually, it was weird. it definitely asked about a second drive and I put in the phrase and it didn't complain, but it maybe thought it was the old one. idk
<nckhexen>alsopodiki: I wasn't aware of a ‘last time’ :-/ Let's move further messages on this topic to #guix-offtopic though.
<nckhexen>bdju: … I don't either.
<bdju>actually it totally mounted the drive fine it looks like. I actually can ls the dir
<alsopodiki>nckhexen I'm not on the offtopic and don't want to proliferate my messaging confusion right now. the bridge had to be restarted by matrix in the recent past due to only one way bridging. anyway, I'll just hang tight!
<bdju>old and new drive have same passphrase but possibly different luks settings from when I made them. I don't know
<nckhexen>But it mounted the new drive?
<unmatched-paren> Odd. This is the output of (print load-path #'external-debugging-output) and the same for native-comp-eln-load-path.
<nckhexen>alsopodiki: Okido.
<unmatched-paren>Here, I have removed the sexp that drops init.el in its place in ~/.config.
<bdju>how can I check which config.scm is being used right now? since the file I normally edit isn't what I booted with right now
<unmatched-paren>Yet, when I readd it, it still fails to (require 'gcmh).
<nckhexen>bdju: ‘guix system describe’ should print it, depending on the age.
<unmatched-paren>Even though the gcmh package's share/emacs/site-lisp path is in there.
<unmatched-paren>What could be going on?
<nckhexen>That feature is incomplete in that in won't track submodules, but you don't seem to be using those here.
<nckhexen>bdju: ☝
<bdju>oh the config it returned already shows the old drive commented out and the new one's setting put in. hm.
<unmatched-paren>Here's gnu/home/services/emacs.scm so far:
<unmatched-paren>(side note: anyone know how I might define ``serialize-list-of-file-likes'', so that i can remove ``/no-serialization''?)
<nckhexen>bdju: wat. Actually, double check that it's printing the *booted* system and not the *latest* system.
<bdju>well I just opened this in nvim: configuration file: /gnu/store/g76q2z59bqrkxfisv6fjw3wvw02q4kz7-configuration.scm
<bdju>Generation 29 Aug 02 2022 22:33:26
<nckhexen>Right, but the output will also give a generation number & date.
<unmatched-paren>/share/emacs/site-lisp is the correct path, right? Not /share/emacs/site-lisp/XXXX?
<nckhexen>bdju: More straw-grasping: does ‘guix time-machine --commit=$guix_commit_from_guix_system_describe -- show cryptsetup’ show a version of cryptsetup different from 2.3.7?
<bdju>trying now
<civodul>hmm since when does ant-bootstrap depend on (guix build syscalls)?
<civodul>apparently cded3a759356ff66b7df668bcdbdfa0daf96f4c5 is from 2018
<civodul>so that means we rebuild all of Java every time we modify syscalls.scm? o_O
<civodul>i had never noticed
<bdju>okay got the output back... version 2.3.7 it says
<civodul>that's "just" 659 packages
<nckhexen>bdju: So no bump that could have caused a regression in cryptsetup itself. Damn.
<gabber>is it possible to pass an ENVVAR to a guix (home) container?
<sneek>gabber, you have 3 messages!
<sneek>gabber, unmatched-paren says: the home-emacs-service-type patchset open in my inbox right now is yours, right?
<sneek>gabber, unmatched-paren says: i think it might be best to use file-likes for init and early-init
<sneek>gabber, unmatched-paren says: also, how about adding a (native-compile? ...) field to emacs-configuration which, if enabled, builds the packages with the emacs-minimal input rewritten to whatever package is in the (emacs ...) field of emacs-configuration?
<unmatched-paren>gabber: i'm also giving home-emacs-service-type another shot now
<unmatched-paren> <- it looks like this so far
<unmatched-paren>unfortunately it's failing to (require 'gcmh) even though gcmh's site-lisp path is in the load-path....
<nckhexen>bdju: I'm afraid I have to go, but if you report this as a bug, could you report <> as a separate bug? There should be *some* error message to indicate what failed.
*nckhexen o/
<unmatched-paren>bye :)
<cwebber>BTW, if you're looking for a job that uses Guile and Guix
<cwebber> we're hirin' :)
<nckhexen>bdju: unmatched-paren Thanks. My attempts to blame this on anything but Guix have failed, so I'll take another look at the initrd code later.
<nckhexen>> United States only (poop)
<gabber>unmatched-paren: with inbox you meant messages here on IRC?
<gabber>i've hacked all night and came pretty far
<unmatched-paren>gabber: nope, there's been a home-emacs-service-type sent in
<unmatched-paren>but it doesn't handle emacs --fg-daemon
<cwebber>yeah unfortunately we're not set up yet to do non-US employees. I hope that changes. right now it's just two of us dealing with all the admin stuff, etc. we're also hiring for an admin position that also uses some tech'y stuff part time, if you know someone who's a good fit for that, btw ;)
<unmatched-paren>and it tries to do what rde does for init and early-init
<gabber>have a look at this:
<unmatched-paren>i also think it's definitely possible to make any home-emacs-service-type load the packages provided *without* adding them to the profile
<unmatched-paren>which i am attempting to do like this:
<unmatched-paren>it's working, but it's also not working?
<civodul>cwebber: exciting!
<unmatched-paren>when i print the load-path and native-comp-eln-load-path, they look good
<gabber>yes, i think i managed that. or do you mean without a home-profile-service-type extension?
<unmatched-paren>gabber: yeah, without home-profile-service-type
<cwebber>here's the admin position
<cwebber>civodul: yes it's nice to finally have it up there!
<gabber>i guess that's doable but i'm not sure if that's the nice way to go
<unmatched-paren>gabber: i think it is; best not to pollute the profile if possible
<unmatched-paren>problem is, when i remove this comment here, it fails to (require) my packages
<unmatched-paren>even though they're all in the load-path
<gabber>they are in EMACSLOADPATH, no?
<unmatched-paren>gabber: would you like to collaborate on one attempt at this? seems more productive than doing them seperately :)
<gabber>for me the changeset i'm working on now would at least improve the look of my home-configuration -- since the emacs-packages go with the service
<unmatched-paren>these prints print a correct-looking list of /gnu/store/...-emacs-blah-.../share/emacs/site-lisp
<unmatched-paren>yet require doesn't work...
<alsopodiki>cwebber oh very nice! funny was just talking to my brother about if there are jobs with Guix specifically...
<gabber>unmatched-paren: sure :) it would be an honor
<gabber>aha, you don't like the $HOME/.guix-home/profile/share/... path?
<unmatched-paren>gabber: what do you mean by that?
<unmatched-paren>oh, that
<unmatched-paren>i see it now
<unmatched-paren>...i have to admit, that makes me queasy
<civodul>cwebber: woow, Spritely's scaling up, nice!
<unmatched-paren>cwebber: awesome! :D
<gabber>why queasy?
<unmatched-paren>gabber: it just seems a wee bit unclean and unGuixy
<gabber>a good bunch of symlinks chained together seems to unguixy to you?
<unmatched-paren>i don't think we should be hardcoding paths like that
<gabber>i like the sense of tidiness that ~/.guix-home brings. everything's there -- without having to get my hands dirty to find the right /gnu/store path
<unmatched-paren>ah, no, i don't mean ~/.guix-home itself
<unmatched-paren>i mean the use of that path in (emacs-configuration-files)
<gabber>unmatched-paren: it's my first attempt at writing a (home-) service; i'm sure there's a couple of things not completely right the way i did them
<unmatched-paren>sure :)
<unmatched-paren>alright, so i just noticed i was accidentally using --daemon instead of --fg-daemon (i'd switched to see if it would solve the problem, but it didn't, and i forgot to switch back), but it doesn't solve anything :(
<alsopodiki>cwebber would you mind any direct emails about spirtely/that position or should it go through official channels listed there? (and sorry for the offtopic, last message I swear!)
<gabber>am i right that (guix-emacs-autoload-packages) is supposed to (require 'package) for each package in the profile?
<cwebber>alsopodiki: please send it to the email listed there :)
<unmatched-paren>gabber: i'm not sure, but i do know that much of emacs-guix is outdated and doesn't work anymore
<gnucode>howdy guix!
<unmatched-paren>gnucode: heya! evening! :)
<gnucode>unmatched-paren I have been playing with your guix config.
<gnucode>trying to use seatd
<gnucode>haven't done it yet...
<unmatched-paren>nice to know it's useful to others :)
<unmatched-paren>gnucode: fyi, polkit doesn't support seatd yet
<unmatched-paren>so things like upower and network-manager won't work
<gabber>unmatched-paren: it works in my current emacs setup with just the profile's load path and that one line (all packages are loaded) but it doesn't in my containerized home for some reason (which crashes emacs' init process) -- otherwise my code works. i'll give your code a closer look later. feel free to merge the two if you feel like it ;)
<unmatched-paren>gabber: interesting re container, maybe there's some other service emacs depends on that isn't available outside the container
<lechner>unmatched-paren: i was unable to reproduce the /v2 behavior with 'go install' in 'guix shell'. it installs a properly named executable into GOBIN
<unmatched-paren>lechner: oh, that's very odd
<lechner>unmatched-paren: i went through the code, but there is a lot going on with gexp and calls like this
<unmatched-paren>lechner: hmm, yes, i don't really understand the store monad myself yet
<gabber>according to section 2.6.5 it should just work™
<efraim>cwebber: using the guix.scm in guile-goblins I was able to compile it on riscv64-linux just now
<gnucode>unmatched-paren: yup. I don't use upower or networkmanager
<unmatched-paren>gnucode: cool. i struggled with lack of networkmanager for a while until i found out that connman could replace it
<lechner>unmatched-paren: can i find the log for this anywhere? /gnu/store/6nr4bdqgjx98diy1y3520w2vn4k8wh0l-gocryptfs-2.3
<unmatched-paren>lechner: for the build?
<unmatched-paren>i don't think it's preserved if the build succeeded
<cwebber>efraim: WHOA
<unmatched-paren>but you could add an (exit #f) phase after 'install to manually induce a failure
<lechner>unmatched-paren: can i just collect that product?
<unmatched-paren>lechner: ?
<unmatched-paren>oh, gc the output, you mean?
<lechner>sorry, new to guix
<unmatched-paren>your next ``guix gc'' will pick it up anyway
<unmatched-paren>unless it's installed...
<lechner>yes, and delete my user roots as well
<unmatched-paren>or used as an input by anything that is installed
<lechner>i may require something more specific
<unmatched-paren>i think you can also ``guix gc /gnu/store/...''
<lechner>do i need -D?
<unmatched-paren>but i've never done that, so i'm not sure if it works
<lechner>unmatched-paren: it worked, but the rebuild resulted in this brief log. what happened, please?
<unmatched-paren>Haha what.
<rekado_>a graft happened
<rekado_>you’ve built a graft derivation, not the derivation that builds the thing to be grafted
<lechner>rekado_: thanks!
<lechner>unmatched-paren: okay, another gc later i found this in the log cp $WORK/b001/exe/a.out /gnu/store/3ps0jm97dfir6zdm4v841gmc441vr0wm-gocryptfs-2.3/bin/v2
<unmatched-paren>lechner: hmm, that's a command, not a guile copy-file call
<unmatched-paren>so somehow, somewhere, that's being done by something other than guix...
<unmatched-paren>i think?
<z4kz>hello #guix
<unmatched-paren>z4kz: good evening! :)
<vivien>Hi, suppose I have a user name and a password, what is the correct way to check whether this identifies a user on the system?
<z4kz>I'm trying to understand if guix can do anything like container orchestration or work with those tools, like k8s.
<vivien>I would prefer a solution in scheme, but invoking a program is OK
<unmatched-paren>vivien: i think parsing /etc/passwd?
<vivien>I have read that I could use sudo, but it does not accept passwords in stdin
<unmatched-paren>vivien: ``(getpwnam ...)'' is a thing i think
<unmatched-paren>e.g. (getpwnam "paren") will return an object that can be taken apart with the passwd:* procedures
<vivien>(did my message go through?)
<unmatched-paren>vivien: yes
<unmatched-paren>oh, right, they can't hear me...
<vivien>I was saying, /etc/passwd does not contain the password, and getpwnam does not get me a password
<vivien>It just gives me "x"
*unmatched-paren opens a ``guile''
<vivien>There’s /etc/shadow, but it is not readable by a standard user
<unmatched-paren>ah, same for me
<vivien>(not "use sudo", but rather "use su")
<rekado_>z4kz: for container orchestration I use the Shepherd with “guix system container”.
<rekado_>it’s not something that works out of the box
<z4kz>oh cool
<lechner>vivien: if you were a program, the standard way would be PAM
<vivien>People are not programs though, because some of them are non-binary
<unmatched-paren>Some programs are too; they're scripts ;)
<vivien>Oh right
<vivien>So how would I use PAM?
<vivien>Guile is especially fluid with this regard, because it is both scripts and binaries
<vivien>Maybe I can build an ad-hoc FFI for guile?
<unmatched-paren>Hmm, I was half-expecting there to be a guile-pam library available, but apparently not.
<vivien>Maybe the interface is so simple that it’s not necessary?
<lechner>vivien: i have an FFI
<vivien>Or maybe the "block after a failed login" feature makes it too complex to bind
<rekado_>vivien: PAM does not tell you if user and password are valid. It tells you whether a user is permitted to authenticate for a specific pam service.
<lechner>one a non-Guix system, i might look at the return status of su - -c /bin/true
<rekado_>note that PAM can simply deny a user even if the password is fine.
<rekado_>you wouldn’t use PAM to just check if a user can be authenticated
<vivien>I would like to check the password to emit an authorization code
<vivien>(for a web thing)
<vivien>lechner, is this guile-pam project published?
<lechner>vivien: actually, you can't use PAM. you will need to use a setuid executable
<vivien>That looks scary
<vivien>It means that if I do the things incorrectly someone could just brute-force my passwords
<rekado_>vivien: I don’t understand the intended architecture, so I don’t dare make any recommendations.
<lechner>vivien: the ffi is good, but replacing Linux-PAM with Guile is in the works
<lechner>vivien: no, it's not scary. a regular user cannot see or compare the system's credentials
<lechner>just like su or sudo
<vivien>Yeah but su and sudo have security features in place, such as wait for a few seconds if the authentication fails
<vivien>I will have to implement that myself
<lechner>vivien: why do you wish to check but not consummate>
<vivien>I don’t understand what consumate means here
<unmatched-paren>"consume", maybe?
<vivien>I basically want to have a web server, that has access to a key pair. When a user provides a valid user name and password, the web server signs an authorization code.
<civodul>lechner: guile-pam, looks fun!
<lechner>vivien: this works locally via exit status $? su - -c "/bin/sh -c true"
<vivien>I don’t understand either sorry I’m stupid
<lechner>with consummate i meant actually taking on the privileges about which you seek to inquire
<unmatched-paren>oh dear. i've just received an email from aerc-devel titled "aerc 0.13.0".
<jackhill>hmmm, `guix shell wget nss-certs -- wget` reports that my ssl cert is not trusted and doesn't have a know issuer, but an online certificate checking site thinks it's fine and gives it a good grade. Is something wrong with my site, or with our nss-certs package?
<rekado_>unmatched-paren: have your patches not been merged yet?
<rekado_>unmatched-paren: what’s the hold up?
<jackhill>it should be a lets-encrypt certificate
<unmatched-paren>well, looks like i'll have to send in another patchset :P
<unmatched-paren>rekado_: raghavgururajan was injured, apparently, so they couldn't review it
<unmatched-paren>rather, won't be able to until they're better
<unmatched-paren>i think
<unmatched-paren>Sooo, v13 coming right up :)
<gnucode>unmatched-paren how is raghavgururajan ? He was injured?
<vivien>lechner, how should I parse these words "via exit status $? su - …"? If I run the system command: su - -c "/bin/sh -c true", it tries to authenticate as root and does not accept the password from its stdin
<unmatched-paren>gnucode: > I met with a motorcycle accident and my left arm is nonfunctional as of now. So, I'll merge your aerc patched once I recover. -- in #whereiseveryone
<lechner>vivien: whoops, i only tried it in the shell and assumed any calling program could gain control over that stdin
<unmatched-paren>Well, 0.13.0 looks to have some nice improvements, so I'll just get that sorted in a moment :)
<vivien>Maybe I should just quit trying and request users to have a valid client certificate
<gnucode>unmatched-paren man that's a bummer!
<rekado_>vivien: is it necessary that users have a local system account?
<jackhill>hmmm, debian's wget seems happy with my cert, so probably a Guix problem?
<vivien>rekado_, that looks better to me because every user has the same password for every service on the system
<rekado_>jackhill: you need to set env vars
<lechner>civodul: yeah, i have been obsessed with simplifying PAM for years. at one point, i considered Dhall. then Guile kissed me. with your authority, you could even lend a hand. the FFI via nyacc requires pkg-config files that linux-pam, unbelievably, did not ship until recently. unfortunately, they are defective in Guix, but fixed by the open
<lechner>vivien: kerberos?
<vivien>I don’t know that
<singpolyma>If I ever get around to a dhall guile language it's still an option ;)
<jackhill>rekado_: and the SSL_CERT_DIR has a bunch in it, but for some reason /etc/ssl/certs/ca-certificates.crt is only 99 bytes long‽
<jackhill>this is on an existing Guix System that has just been pulled/reconfigured over the months. I don't recall previous problems
<lechner>civodul: yay!
<nckhexen>jackhill: Does it look corrupted? (It's a text file, it should have matched BEGIN/END CERTIFICATE pairs.)
<jackhill>nckhexen: no, it looks fine, and it's actaully 245079. The symlink just has the small size :)
<lechner>vivien: My preferred way for multi-service (or multi-site) authentication would be to keep user credentials in Kerberos, which can be queried
<rekado_>jackhill: FWIW on my Guix System wget downloads the index.html without complaint.
<jackhill>rekado_: have you pulled recently?
<nckhexen>Works here too in a --pure environment.
<rekado_>vivien: kerberos is perhaps a little complicated. It uses renewable tickets that are issued upon successful authentication. It’s not easy to set up.
<rekado_>jackhill: a week ago
<jackhill>ok, I'll do some more testing. It works for me on some older systems, but not on some recently upgraded ones.
<unmatched-paren>rekado_: could you perhaps have a look at my v13 patches once they're sent?
<nckhexen>./pre-inst-env. At most a few hours old.
<rekado_>vivien: for multi-site auth LDAP is … “popular”. Credentials are verified by attempting to bind to LDAP.
<lechner>rekado_: in my experience, LDAP is much harder to set up than Kerberos. i also think it is less secure, although more powerful
<lechner>although most people, myself included, use both together
<rekado_>we have an LDAP service for Guix… I think
<unmatched-paren>rekado_: be aware that the patchset is 40 go packages, so if you'd rather not review some horror like that, I understand :)
<rekado_>unmatched-paren: oh…
<rekado_>unmatched-paren: any chance we could merge part of the patches if they look fine?
<rekado_>package additions are usually easy
<unmatched-paren>they're almost all package additions, except for about 3, i think
<unmatched-paren>one adds a package *and* exports a utility from (guix build-system go)
<unmatched-paren>another renames go-golang-org-colorful to go-github-com-lucasb-eyer-go-colorful
<unmatched-paren>no idea why it was named the former in the first place
<vivien>I’m a bit lost to be honest
<vivien>That’s a bit more complex than what I was expecting
<rekado_>LDAP is used as a directory where you can store user account info. In corporate environments there’s often a central directory that can be queried instead of duplicating account info on each system.
<rekado_>if you had a directory like that you could also use it to verify user credentials. nslcd is how you could make your operating system query the directory for user accounts (instead of having /etc/shadow, /etc/passwd, etc).
<rekado_>kerberos is often used with ldap, but it is optional and can also be used with other services; it’s a ticketing services that hands out signed tokens that a service can use to do work on behalf of a previously authenticated user, and to renew authentication without the user’s input.
<rekado_>none of these things are needed if all you want is check if a username / password combination is valid according to /etc/{shadow,passwd}.
<vivien>The problem is, I don’t want to parse /etc/shadow, because I would have to run as root, and I would have to enforce limits to authentications myself
<rekado_>vivien: don’t bother parsing these files
<gnucode>unmatched-paren when I try to enable (service seatd-service-type) I am getting an error that
<gnucode>guix system: error: supplementary group 'seatd' of user 'joshua' is undeclared
<gnucode>do I need to create a system group called seatd?
<unmatched-paren>gnucode: you need to use ``seat'' as the group, not ``seatd''
<rekado_>a simple way is: install pamtester; then let your application run “pamtester su <username> authenticate” and feed it the password
<rekado_>vivien: ^^
<rekado_>instead of “su” you can create a custom PAM service that implements additional or different checks
<vivien>I get: pamtester: Authentication service cannot retrieve authentication info
<gnucode>ok I'm about to reboot into seatd....
<unmatched-paren>gnucode: good luck :)
<rekado_>vivien: must be a configuration issue on Guix System; on RHEL this works fine as a regular user, but on Guix System you need to be root…
<gnucode>unmatched-paren so I just rebooted, and when I try to run dbus-run-session sway --> I get XDG_RUNTIME_DIR is not set in the environment...
<unmatched-paren>gnucode: That's handled by greetd
<unmatched-paren>so you'll need to set it up with an agreety on each tty
<unmatched-paren>like how i did it, except replacing wlgreet with agreety
<unmatched-paren>look at the guix manual, basically
<gnucode>unmatched-paren it possible to still set up "automatic login to virtual console" with seatd?
<gnucode>ok will take another look at the manual
<unmatched-paren>i think you can do autologin with greetd...
<unmatched-paren>oh, wait, i think it's possible but not implemented in our greetd service yet
<gnucode>I suppose that I will find out...
<gnucode>unmatched-paren well I am pretty sure that automatic login to virtual console has been broken for a while anyway.
<rekado_>vivien: if you’re okay with a little bit of yuck, you could run pamtester as a root service.
<gnucode>I haven't been able to get it to work for me in a at least 6 months.
<rekado_>(on RHEL sss is pretty much the moral equivalent of running a root service that does PAM auth)