IRC channel logs
2025-02-19.log
back to list of logs
<vhns>Does guix-emacs not have a command to reconfigure the system/home according to the current file? <Rutherther>civodul: why was /etc/environment made in such a way that it only sets variables and is exported only later in /etc/profile as opposed to exporting right away? <civodul>Rutherther: /etc/environment is not a shell script, it’s a list of VAR=VALUE lines, interpreted by pam_environment.so IIRC <Rutherther>civodul: hm. It might be interpreted by pam_environment.so as well, I am not sure of that, but it definitely is sourced and exported in /etc/profile <civodul>Rutherther: yes, because it can also be interpreted as if it were a shell script <Rutherther>but if it is interpreted by pam_environment.so, I don't understand why it would be in /etc/profile as well <Rutherther>the reason I am asking is that because currently as it's written, you cannot change the variables set before in /etc/profile, namely MANPATH, INFOPATH, XDG_DATA_DIRS, XDG_CONFIG_DIRS, XCURSOR_PATH, and probably also what is set from system profile's etc/profile <civodul>there’s actually a comment in /etc/profile explaining why it’s sourced and when :-) <Rutherther>because it 1. sources it as bash variables, 2. exports by names of the variables. That means for already existing environment variables, it doesn't do anytihng else <civodul>the “. /etc/environment” bit is an ‘if’ that’s probably never reached, though <Rutherther>oh right, I didn't read it thoroughly and thought is only checks if /etc/environment exists, my bad then <olafes>What happened to the bootloader subsystem rewrite idea? There was a lot of work put into it but now it seems abandoned. For example this patch series #73202 <futurile>olafes: I guess they just ran out of steam; feel free to ping it and ask them if there's a way you can help (maybe testing!?) <lechner>olafes / I still have hope but someone with commit rights has to develop the courage to touch that part of Guix <lechner>civodul / Hi, is there an easy fix for #76339 <lechner>civodul / such as adding user-processes to the service prerequisites? <anticomputer>hrm, so I noticed that, somewhat intermittently, on system reboot shepherd will respawn my containerd service, which then sits there indefinitely causing the reboot to hang, is this is a known problem? I'm just using (service containerd-service-type) in my OS services list <dariqq>lechner: Patch the services to depend on user-processes. Problem is figuring out which services need it . For a workaround herd stop the service manually before shutdwon <Rutherther>anticomputer: see the link to issue sent just minutes before your question :) <lechner>dariqq / why doesn't someone with commit rights make that change right now? <civodul>lechner: yes, adding ‘user-processes’ to ‘requirement’ <anticomputer>ok if I'm reading the above right I should just make user-processes service a requirement for any service that is lacking it and causing respawn reboot hangs yea? <dariqq>lechner: not sure what you mean. If your service is spawning a daemon then it should depend on userprocesses . My hope is that this is only a problem when a service has an empty requirement (because it would depend on user processes transitively) <dariqq>but i dont know how how to figure this out for every service available in guix <Rutherther>fnat: probably a theme with icons, along with XDG_DATA_DIRS set to the share folder of the profile <fnat>Rutherther: Ha! Thanks, let me try that. <fnat>Do you mean .local/share? <anticomputer>the containerd-shepherd-service spawns a daemon and does have an empty requirement it seems <fnat>Np, I'll try something along those lines. <dariqq>lechner: Also for rspamd you can fix it for yourself in the meantime because rspamd-configuration exposes it shepherd-requirements field <dariqq>ACTION wishes it were easier to customize a service definition <mra>planning to attempt a Guix install tonight. wish me luck :P <mra>seems like 55231 won't be merged for a while yet, so I'm going to try hacking a ZFS system together by myself <fnat>Hm, adding adwaita-icon-theme and sharing ~/.local/share didn't do it. It still crashes on Ctrl-s. Same Gtk error from what I can tell. <fnat>Ha, but I missed the bit about XDG_DATA_DIRS, trying that now. <Rutherther>fnat: if it won't help, I am kind of out of ideas. But generally I would also recommend sharing dbus env vars + the dbus socket. Browsers can utilize it for various things, like file picker, screensharing etc., it's used very commonly by flatpak's containers for example <dariqq>Rutherther: Ouch 2017. Some common things that would be great are extra shepherd-requirements, extra daemon args, extra daemon environment variables, service autostart, ... . Currently you need to be lucky that the *-configuration exposes that setting which is not ideal <Rutherther>dariqq: what I sent allows for any extra changes, so it would become trivial to make functions that will modify the shepherd service of given (system/home) service, making autostart #f, etc ... <fnat>Rutherther: Ok, thanks. Setting the XDG env var didn't seem to fix it unfortunately. Although launching IceCat from the CLI (instead of directly from Guix Shell with '--') has given me a longer log, not sure why. <fnat>I'll try exposing some more env vars, e.g. dbus related as you suggest. <dariqq>Rutherther: may workaround currently is a function that inherits a service type and can exchange arbitrary service-extensions with something else but it feels like a hack to get around the limitations of the current system <Rutherther>dariqq: the problem with that is that if the service is not a leaf service, others won't extend it properly <fnat>Rutherther: The socket, as in '--expose=/var/run/dbus'? <dariqq>Rutherther: yeah it is not ideal, for my use case it is working. I really like the service-extension mechanism from a design perspective but it can feel a bit limiting if the service configuration does not expose a setting I'd like to tweak <Rutherther>fnat: that is the system socket, I am not sure if that one is important, don't forget about the session one though (see DBUS_SESSION_BUS_ADDRESS for location) <fnat>Hm, I don't have that env I'm afraid? <Rutherther>fnat: then it likely means you aren't running session dbus at all <salaz>hey folks, i updated emacs thru guix last night and now magit is not able to pull from github due to a CAfile error -> server certificate verification failed. CAfile: none CRLfile: none <salaz>has anybody else also encountered this error ? <fnat>Rutherther: Ok, np, I'll keep on experimenting with various flags and env vars, ty. <lechner>dariqq / the service definitions in Guix are defective. that's where they should be fixed. i maintain several piece of equipment and cannot make (and later undo) such basic changes. I already do too much to get Guix working, as a user <salaz>Rutherther: worked like a charm, ty <salaz>Rutherther: yes, somehow it worked before even though I evidently didn't have nss-certs installed <salaz>one of this world's mysteries I suppose :) <salaz>Rutherther: ah i know exactly why it's worked all this time without nss-certs. it's because i had only been using magit on an ssh-authenticated connection, not https <aure844>Hello. I have notice that the making a guix system vm out of system/examples/vm-image.tpl logs the user in xfce automatically but creates a window that covers the whole screen with "Unnamed Window" (then the xfce panel covers the window title bar...). Is this intentional? <futurile>aure844: don't think it's "intentional", but yeah I've seen something similar <aure844>any idea what the cause could be? Is it guix-specific or can happen in other OSs? <lechner>anticomputer / Guix is the best thing that happened to operating systems in a very long time <vhns>is there a way to list currently used substitutes in guix? <Rutherther>vhns: indirectly, by looking at the arguments of running guix daemon process, ie "ps aux | grep guix-daemon", see the --substitute-urls argument <anticomputer>is running your own local build cache / substitute server a thing folks commonly do? I have a 60TB NAS on my LAN and seems like it'd make sense to just introduce a local repo guix channel that follows upstream as well as a local substitute server <anticomputer>lechner: yes very much enjoying being forced to actually understand my compute stack bottom to top ... also with a LISP background it's just so much more pleasant to work in a Scheme vs the Nix language <civodul>anticomputer: hi! running ‘guix publish’ is easy (and discoverable on the LAN); setting up a build farm for a channel, for instance with Cuirass, is a bit more involved but doable <civodul>i have ‘guix publish --advertise’ on my laptop, pretty cool <civodul>vhns: ‘guix weather hello’ will check the currently configured substitute servers <lechner>anticomputer / i also use 'guix publish' with great enjoyment! <vagrantc>so, i am wondering if the info files generated and shipped with "make dist" ... should have the copyright headers translated ... <vagrantc>or, more than copyright, the license headers. <chipb>is...it common to build info files for make dist? <lechner>anticomputer / just cross-publish all local equipment <vagrantc>lechner: i do not understand your question <vagrantc>it is a complicated problem, as obviously there is no universally accepted language ... but i suspect there are languages (for better or worse) that are more widely recognized across jurisdictions (e.g. english) <vagrantc>also, there are huge differences between what "make dist" generates and the commit it was generated from, above and beyond the auto0generated files ... e.g. missing files e.g. po/doc/po4a.cfg | 32 - <vagrantc>lechner: i am talking about the license declarations in, say, doc/guix.de.info <civodul>vagrantc: these three missing files sound like a bug <civodul>it also means that these two test series are never run <lechner>vagrantc / is there any English text in doc/guix.de.info? <vagrantc>lechner: but there is a section which is, with my limited german, clearly the standard license declaration translated <lechner>vagrantc / i think that's just a reference to the license <vagrantc>not sure it would be valid in, say, the United States <vagrantc>so it would be a copyright violation to ship it <civodul>vagrantc: d’oh! i’m glad you’re doing this work! <lechner>vagrantc / it only covers the translation "document" for one <civodul>vagrantc: this packages needs love, as we say :-) <vagrantc>trying to put a little of the grind work in that is not nearly so fun <lechner>vagrantc / also, i type "1" for English all the time <anticomputer>lechner: ah cool so they just advertise each others build caches to prevent outside fetching as much as possible yes? <lechner>anticomputer / with ipv4, it's automatic <vagrantc>lechner: yes, and in jurisdictions where german is not a legally recognized language, i am not sure i have permission to distribute the file under the terms of the GFDL-1.3+ (with no invariants, ..., etc.) <vagrantc>lechner: it is also distributing content derived from other people's content that is clearly licensed under the GFDL-1.3+ in english ... and failed to comply with the terms of the GFDL-1.3+... maybe? <vagrantc>i am not asserting that is true, so much as it might be? <lechner>vagrantc / it's just a reference to the license. nothing more. if needed, you could ask the translation people to provide it. they will cut and paste <vagrantc>i only noticed because in reviewing the copyright/licensing tools did not correctly identify all the various translated files <vagrantc>so my question is ... should they use a standard license header in english ... or is translating it legit <lechner>vagrantc / moreover, while jurors may distrust foreign language docs in general, will they do so if the original was in English? <lechner>vagrantc / i see as a bigger problem that the receiver claims ignorance based on the fact that they didn't speak (or read) English. After all, that's why they were using the translation file in the first place! <vagrantc>lechner: ok, now for each of the other countries in the world? <vagrantc>and even in the US, i do not want to have to get a legally certified translation of the translated content in order to ship those files ... that really kills the benefits of free software <vagrantc>one of the main goals of free software is to remove needing to get legal counsel to review weather i can share a file or not... <vagrantc>lechner: so i guess your first link convinced me that it is a bad idea. <anticomputer>lechner: with the guix publish --advertise avahi model, how does the configuration work? you only add the local peer's authorized key but do not need to add it to the substitute url list manually? or the advertising is simply for availability and you still manually add the local substitute server url to the config? <dstolfa>vagrantc: one might then pose the question: why would it only be in english? should the license be shipped in literally every language? <dstolfa>english isn't really special in any way, and the concerns you bring up could just as well be brought up in any other country <mra>finally got an installation image built. phew <mra>install attempt time! <anticomputer>lechner: ah just checked your conf, seems like the latter case, just introduce the signing key and LAN advertising takes care of the rest, nice <vagrantc>dstolfa: though that does not solve the problem... <dstolfa>vagrantc: yeah, i agree that it doesn't i'm just a bit at a loss as to how to actually solve it :D <vagrantc>dstolfa: although, in that it is a derivative of the english original, with the english header ... it is debateable weather it is actually meeting the compliance under license to make derivative works ... <vagrantc>so in that sense, in this particular case, english may be "special" <dstolfa>well, yeah, but judges aren't really known for their consistency anywhere in the world <dstolfa>which is probably the core of the issue