IRC channel logs
2023-02-13.log
back to list of logs
<lechner>Hi, what's the purpose of /gnu/store/.links please? <lechner>Hi, with staging to be merged shortly, would someone please be so kind to review #58658 ? It's a prerequisite for adding gocryptfs via #58768 <old> Anybody working on debuginfod? <KarlJoad>Is there a way to further add to PATH using Guix home? <Zambyte>KarlJoad: there is a home-environment-variables-service-type that can be used to add environment variables. You can use that to set a value for your PATH. <KarlJoad>Zambyte: I am using that, but do not quite get the syntax to add to PATH. Is it the same syntax for the value as usual? Meaning '(("PATH" . "/something/new/to/add/bin:$PATH"))? <Zambyte>KarlJoad: your ~/.profile should have `. $HOME_ENVIRONMENT/setup-environment` in it and that file should have an export statement with your PATH value at the bottom <KarlJoad>My .guix-home/setup-environment does not export PATH, but the .guix-home/profile:q <KarlJoad>But .guix-home/profile/etc/profile does export PATH. <KarlJoad>I am "manually" editing PATH because I am installing a program through Nix that Guix is not aware of otherwise. <Zambyte>Have you sourced that file or started a new shell? <KarlJoad>Yes, .guix-home/profile/etc/profile is properly sourced in a new shell. This is a imperatively-installed program through Nix. (nix-env -i is what I used). It is like guix install. So I just need to source $HOME/.nix-profile/bin too. <apteryx>phew... seeing some light at the end of the icecat/icedove language packs <jackhill>sneek: later tell civodul I haven't forgotten about the GnuTLS stuff! I hope I'll get a chance to return to it Monday evening UTC-5 <apoorv569[m]><gabber> "apoorv569: don't use the -E..." <- I'm using -E because I'm using files in my user's home dir under ~/.config/guix/ <apoorv569[m]><nckx> "I use a similar system with (add..." <- Yea.. Its been 2 days I haven't been able to use my laptop now.. I guess should have first setup a working config in a VM or something before nuking my main laptop.. <apoorv569[m]>But do so to force my self to learn something I do enjoy it though but as time passes somethings gets annoying as well.. <apoorv569[m]>The channel definitions have this make-channel-introduction thing with a hash of some sort.. What is this? a commit hash? <Arjanhehim[m]>apoorv569: the commit hash of the first trusted commit to bootstrap the authorisation <apoorv569[m]>So its not like that packages are pinned to this commit right? <efraim>has anyone else run into problems building syncthing on tmpfs? <efraim>or more rather running the test suite? <apoorv569[m]>Hmm.. So create a container with emulate-fhs option to get a regular file system hierarchy... <apoorv569[m]>But would that container be persistent? Or do I have to install rustup in that env everytime? <attila_lendvai>is there a reason that i'm not aware of for shepherd using a locally defined pipe2 instead of guile's open-pipe* ? <attila_lendvai>i want to set up a two-way communication with a service using its stdout, and using pipe2 results in one-way streams <attila_lendvai>ACTION realizes that he's neck deep in posix internals that he always tried to avoid... <jonsger>apoorv569[m]: the rustup installation will be "persistent" in that shared folder. But you may need to run the shell command for using the rustup rustc tool. Just try it out :) <PotentialUser-28>Hi! Finally for guix on my system. Been wondering something though. Does anyone know what the reason is that there is no offline installation possible? <attila_lendvai>to answer my own question, shepherd needs to mess with signals between fork and exec, and the guile popen API doesn't accommodate for that. i either learn everything about fork/exec/pipes or do my ultimate goal in some other way... :/ <gabber>attila_lendvai: what do you need to learn, exactly? maybe we can help you (: <attila_lendvai>gabber, that's appreciated, thanks! the trouble is that i'm reluctant to learn it all. i know enough that this territory is a convoluted mess full of traps and heisenbugs, and my change to shepherd is already extensive enough that it won't be accepted... and turning the simple log capture logic of fork+exec-command into a two-way stdio piping solution will probably delay patch review indefinitely... let alone possibly <gabber>so.. if i may ask: what's the goal, in the end? <attila_lendvai>all i need is a two-way pipe that guile's open-pipe* sets up nicely in my test script, but is completely different when run in schepherd <gabber>there's other means of creating IPC.... <attila_lendvai>gabber, i want shepherd to run a service process with which i want to have a two-way communication stream to its stdin/stdout, driven by a user provided fiber (without stderr being mixed in that shepherd currently does) <attila_lendvai>gabber, all this works, except when i introduced a #:merge-error-into-log? and turned it off, then all of a sudden the shepherd side of the pipe becomes an input stream, and i have no clue why, or how it works when i don't disable the merging of stderr into the pipe <attila_lendvai>gabber, hrm... do you think it would make sense to ask the people writing the service for an option to set up the IPC on a custom file, as opposed to stdin/stdout? that would probably sidestep my entire issue with shepherd... <gabber>i don't know! usually (at least in a shell context) one can easily re-route a single stream to a file (i.e. `guix build foo 2> error.log` routes stderr to the file error.log). but i'm not sure how that would/could be accomplished in your context <attila_lendvai>currently there's a shell script that talks to the process, but i was hoping to rewrite it in scheme, because ideally the service code should be able to instruct this process to do stuff without restarting it... and communicating the required data to an already launched shell script is just yet another can of worms... <gabber>ACTION afk, will have a look later <attila_lendvai>hrm, there's that mkfifo magic in that script... maybe i can wire my fiber on that stdin and stdout files... <jpoiret>attila_lendvai: are you using guile 3.0.9? have you looked into the new spawn procedure? <jpoiret>I don't know if shepherd uses the latest guile <jpoiret>oh, you're using the built-in inetd constructor? that probably won't work then <jpoiret>maybe shepherd could be partially rewritten to take advantage of spawn instead of forking, although I'm not sure whether that's possible with inetd-constructor <attila_lendvai>jpoiret, i'm calling fork+exec-command from my service script. maybe i can avoid that, but i'm using the #:user, #:group args, and spawn doesn't accommodate for that <attila_lendvai>jpoiret, just to be sure: i'm not using the inetd constructor, but another part of the same machinery <jpoiret>right. you could consider using a shim for the user and group args instead <attila_lendvai>also, shepherd makes sure to deal with some "precious-signals". not sure spawn does that. <jpoiret>ie. it should do the right thing without you having to care about signals and stuff <attila_lendvai>jpoiret, with 'shim' you mean a shell script as program for spawn? <jpoiret>a gexp that just exec's after doing some basic setup <attila_lendvai>jpoiret, err, hrm... i kinda get it, but not sure how scheme in the gexp turns into a shell script for spawn. do you have any examples for such magic? <jpoiret>well, depends on where your code lives. If it's in some guix configuration of a service, you can just do #~(blablabla (something #$(program-file "myshim.scm" #~(setuid ...)))) <attila_lendvai>jpoiret, wow! it gets serialized into some inline scheme code with a shell shebang like #!/path/guile --no-auto-compile -e main -s ? <jpoiret>that's how the shepherd service configuration files are computed IIRC <attila_lendvai>jpoiret, i'm not sure that works... the shepherd service code is already inside a #~(...) and this would be a nested scheme form calling spawn. is the gexp compiler smart enough to handle such nesting? <attila_lendvai>i.e. this is already inside the start gexp of a shepherd service <jpoiret>yes, as long as you do #$(program-file "nnn.scm" $~(...)) <jpoiret>otherwise yes, it would just splice the contents of the inner gexp <jpoiret>because program-file records are lowered differently from bare g-exp <jonsger>apteryx: kudoz for working on icedove :) <haugh>Hello friends. I'm interested in how the reproducible system layer affects CI design. My hypothesis is that it lowers the cost of shadow deployment. Does anyone know any resources or notable projects that reflect the paradigm shift? <haugh>multiple version tiers running against a forked data stream <haugh>as opposed to e.g. blue/green or canary deployment <jpoiret>haugh: i don't think reproducibility impacts CI in the way you're describing <jpoiret>if something changes, you still have to test it, and builds being reproducible won't help in any way here <haugh>jpoiret, the ability to nearly instantly reset a filesystem to a known working state changes what I want to do when tests fail <gnucode>hey guix people, just out of curiosity, why has guix moved "hosts-file" into a service? <gnucode>I'm happy to migrate to the new syntax. I'm just curious. <gnucode>attila_lendvai can you say that explanation again without using the word composibility? I think you are saying that the guix developers wanted services to be able to modify the hosts-file ? <attila_lendvai>gnucode, guix services have a means to join multiple instances. it's an infrastructure that allows adding several pieces of the hosts file into one. but i'm just guessing, didn't look at the code <gnucode>attila_lendvai: hmmm. that's interesting. <attila_lendvai>gnucode, think of random services generating bits'n'pieces of hosts files that end up as one /etc/hosts <gnucode>attila_lendvai ok. That is super cool! <janneke>hmm, it seems that texinfo-all-menus-update hasn't been run in a while <attila_lendvai>guile's kill doesn't return anything. how can i test from guile if a pid is alive? <gnucode>janneke: are you saying that the guix's manual generates the table of contents and menus? <apteryx>I think they're saying that it's outdated per texinfo-all-menus-update <Guest3913>I am running $guix package -u and I see guix being continuously downgraded.. what might be wrong? <apteryx>you have installed guix in your profile <apteryx>so everytime you upgrade, guix from your profile installs the guix it knows about, which is older <Guest3913>ok.. so there shouldn't be guix in profile but .config/guix/current should be in the path, right? <janneke>apteryx: right, i had to revert /many/ other changes after generating the necessary menus <old>I'm trying to package a linux modules (lttng-modules) and I get: build of /gnu/store/p46y7x3dqha5yabfmxzzj2dkgbrhx0pk-linux-libre-6.1.10-guix.tar.xz.drv failed <old>Looking at the log: guix perform-download: error: /gnu/store/p46y7x3dqha5yabfmxzzj2dkgbrhx0pk-linux-libre-6.1.10-guix.tar.xz.drv is not a fixed-output derivation <old>What's causing this? <old>I know that lttng-modules is not reproductible yet and I'm unable to fix this for now, but I would like to load the module even though <mroh>old: if this error is reproducible with a small example, please file bug-report. <attila_lendvai>old, maybe you're doing the wrong thing wrt how you're pointing to the kernel sources. but it's out of my league to help beyond instilling this doubt. <old>Everything was working before linux 6 <old>Adding the pack to the list of kernel-loadable-modules <old>I will try with a earliy version of Linux <attila_lendvai>old, oh, i see. i remember hearing some chatter about this topic recently... something may have changed around the infrastructure <old>oh well same thing with 5.15 <old>again derivation of tgz of linux is not a fixed-point <old>and yet I can build the kernel fine <old>oh and I can build lttng-modules in the guix tree `./pre-inst-env guix build lttng-modules' works fine <old>But I can't use it has loadable module! <old>that would mean that the hash is empty if I get this error <old>which I don't quite understand <lechner>Hi, is a patch to the knot-service-type a 'guix-patch' or a 'bug-guix'? <futurile>Has anyone used patman for patch creation in git? I used it today for the first time, it was pretty good. <lilyp>lechner: patches go to guix-patches unless they're in direct reply to a bug <lilyp>is anyone working on gnome 44 atm? how's the state on c-u? <jpoiret>futurile: some people have been pushing towards it, although I haven't used it myself <jpoiret>one thing I don't like is that rerolls don't stay in the same thread <lilyp>lechner: the api freeze for 44 was two days ago, we're heading for a release <lilyp>yes, we completely skipped a gnome release (again) <lechner>lilyp / was that message truly meant for me <lilyp>oh, sorry, it was for unmatched-paren <mirai>our xdg-mime-database is rather old <futurile>jpoiret: ah interesting. I can see you can specify a series-version, but guess there's some interaction with patch send-email. Haven't explored enough yet :-) <apteryx>yay! managed to get icecat/icedove honor the system locale <Kolev>unmatched-paren: Are you ) on the mailing lists? <lechner>Hi, how may a program discover the Guix machine type of the running system (as named in guix/packages.scm) please? <jpoiret>any program or a Guile program using guix? <lechner>is that accessible via the 'guix' executable? i have had some recompile experiences with trying to run Guix code directly <haugh>lechner, I would like to know more about your experiences programming with guix modules <lechner>haugh / Hi, i am probably pulling a newer Guile version with 'guile-3.0' <haugh>lechner, got any public code I can read? I want to use guix records and monads in my own stuff, but I'm not sure how to approach guix as an application dependency <lechner>haugh / after getting tired of recompile messages, i simply rely on Guix being present nearly everywhere. I now use (open-pipe* OPEN_READ "guix" "hash" "--serializer=nar" absolute) <lechner>haugh / please let me know when you find out more :) <jpoiret>the following works for me `echo "(begin (use-modules (guix config)) (format #t %system))" | guix repl -q -- /dev/stdin` <jpoiret>although I don't think it's considered public api <jpoiret>i see you're using the guix executable, wouldn't it be better to properly depend on Guix itself? <jpoiret>or run your script through `guix repl -- myscript.scm` <haugh>jpoiret, how does one "properly depend on Guix itself?" Is there a native input? <lechner>jpoiret / probably. i am currently running everything by hand. could (or should) %system perhaps be added to guix system describe? <jpoiret>your best bet is `guix repl -- something.scm` <jpoiret>lechner: the system is known to guix itself, it's not specific to the system generation <lechner>jpoiret / yeah, that's probably better. not everyone uses 'system' either. it just had a bunch of similar info already <Guest63>virt-manager does not report network and cpu usage. I use qemu///sesion conncetion. I installed virt-manager through Guix as of package manager. <Guest63>I included spice via "(spice-vdagent-service)" but I get upon running "guix system reconfigure config.scm"; guix system: error: spice-vdagentd requires dbus-system which is not provided by any service