<gabber>does a file-like object have a path? if so, how can i access that? <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. <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>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! <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: and you can look at older commits ... somewhere <vagrantc>i tend to get a little lost navigating data.guix.gnu.org <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 <rabajaj>maybe I should try reaching to the website tomorrow :P *vagrantc is happy to see folks poking at reproducibility in guix :) <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>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 logs.guix.gnu.org has an expired certificate <podiki[m]>ah, was recently renewed, just needed to clear some cache <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 ld.so: 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 <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? <zimoun>unmatched-paren, yes. To use the Guile library. :-) <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. <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? <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>pkill9: I never power off, maybe once a month to update my kernel. <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. <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. <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. <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) <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 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>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 <ekaitz>lechner: I make clean and recompile everything but it might be too much <nckhexen>lechner: Yes, it's possible I am too. And 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>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! <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. <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 --to=guix-patches@gnu.org --cover-letter --annotate origin <nckhexen>I thought it would be explained in a bit more detail. <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. <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? <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>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’. <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. <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>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) ? <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 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? <efraim>sneek: later tell ennoausberlin if you want to test the rust patches then you can try 'guix time-machine --branch=staging -- build ripgrep' <mroh>d641115e20973731555b586985fa81fbe293aeca on berlin. *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 <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 <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 <pkill9>so basically as an additional 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 <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"? <ae_chep>unmatched-paren: guix.gnu.org/manual > 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>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 <ae_chep>I mean as a documentation-viewing program I struggle a lot with it <ae_chep>pinfo may be better. I'll test it. Thank you <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. <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>...am i the only person who just shuts down when they're finished using the computer? :) <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'. <lechner>i dropped the /v2 but i don't think that's quite the golang convention <unmatched-paren>can you point me to the repo? I'll download it and try to go build it <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>i would send a patch but i have no idea how i'd catch and diagnose the error <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>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>Can you do ``guix edit emacs-magit'' and paste the ``emacs-magit'' package into paste.debian.net? <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? <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>maybe try a ``guix shell emacs emacs-magit nss-certs'' and see if it works <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>but it doesn't appear to be a go bug, since ``go build'' spits out ``gocryptfs'' as expected <unmatched-paren>ennoausberlin69: hmm, wait, is your normal ``git'' command installed from debian? <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. <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 <lilyp>it should still list a per-user profile in /var/guix <ennoausberlin69>I try to convert my doom emacs config in a guixy one. I probably do some mistakes during this experiment. <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? <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: maybe #:modules should just append to the default modules instead of adding a new #:extra-modules <apteryx>unmatched-paren: or #:modules will naturally be deprecated/forgotten over time <apteryx>it seems extra-modules might conveys better what it does <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 <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. <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 <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>Is there any place with a collection of Gix system system configurations? <lechner>lamp140: someone here has FPM working with Apache. unfortunately, I use Nginx and am still chewing on it <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? <podiki[m]>...hello? has the matrix bridge lost connection? <lamp140>lechner: I think it's working for me. I managed to run the <? Php <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. <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? <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 <nckhexen>I checked Syphon, it shows the same as element.io 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. https://paste.debian.net/1257760/ <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. <unmatched-paren>dlowe: well, you can use --do-not-upgrade if you're using guix upgrade :) <nckhexen>Our Gentoo emulation layer remains controversial. <bdju>so I've rebooted and can't boot now, pre-mouet actions failed <dlowe>unmatched-paren: okay, that's a useful tip, thank you <unmatched-paren>nckhexen: [PATCH RFC] scripts: package: Rename --no-substitutes to --emulate-gentoo. <dlowe>I wish cwebbers --no-build flag could have gotten more traction <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 <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 <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. <bdju>layout and passphrase seem good <nckhexen>Not promising, but there are modes that work with Guix. I meant, using which software. <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 <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. *nckhexen last used LUKS2 when it was still called LUKS1. <nckx`>This doesn't make any sense. I'm here, using matrix.org. You're here, not using matrix.org. florhizome[m] is speaking in #guix, using matrix.org, 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 <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>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>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>(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 <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>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. <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. <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. <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 <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 <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. <nckhexen>That feature is incomplete in that in won't track submodules, but you don't seem to be using those here. <bdju>oh the config it returned already shows the old drive commented out and the new one's setting put in. hm. <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? <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 <bdju>okay got the output back... version 2.3.7 it says <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>unfortunately it's failing to (require 'gcmh) even though gcmh's site-lisp path is in the load-path.... <cwebber>BTW, if you're looking for a job that uses Guile and Guix <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. <gabber>unmatched-paren: with inbox you meant messages here on IRC? <gabber>i've hacked all night and came pretty far <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>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>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? <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: 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 <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? <civodul>cwebber: woow, Spritely's scaling up, nice! <gabber>a good bunch of symlinks chained together seems to unguixy to you? <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 <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>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>unmatched-paren I have been playing with your guix config. <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: 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>but you could add an (exit #f) phase after 'install to manually induce a failure <lechner>unmatched-paren: can i just collect that product? <lechner>yes, and delete my user roots as well <lechner>i may require something more specific <rekado_>you’ve built a graft derivation, not the derivation that builds the thing to be grafted <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>so somehow, somewhere, that's being done by something other than guix... <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 <vivien>I have read that I could use sudo, but it does not accept passwords in stdin <unmatched-paren>e.g. (getpwnam "paren") will return an object that can be taken apart with the passwd:* procedures <vivien>I was saying, /etc/passwd does not contain the password, and getpwnam does not get me a password *unmatched-paren opens a ``guile'' <vivien>There’s /etc/shadow, but it is not readable by a standard user <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 <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 <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? <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>lechner, is this guile-pam project published? <lechner>vivien: actually, you can't use PAM. you will need to use a setuid executable <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: no, it's not scary. a regular user cannot see or compare the system's credentials <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 <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. <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 https://jackhill.us` 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? <unmatched-paren>rekado_: raghavgururajan was injured, apparently, so they couldn't review it <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 <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 https://debbugs.gnu.org/55762 <singpolyma>If I ever get around to a dhall guile language it's still an option ;) <jackhill>this is on an existing Guix System that has just been pulled/reconfigured over the months. I don't recall previous problems <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. <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. <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: any chance we could merge part of the patches if they look fine? <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 <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? <rekado_>a simple way is: install pamtester; then let your application run “pamtester su <username> authenticate” and feed it the password <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.... <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... <gnucode>unmatched-paren hmmmm...is it possible to still set up "automatic login to virtual console" with seatd? <gnucode>ok will take another look at the manual <unmatched-paren>oh, wait, i think it's possible but not implemented in our greetd service yet <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) 
