IRC channel logs
2025-02-07.log
back to list of logs
<lfam>I'm not extracting from anything. I'm generating a VM from an example config.scm <eikcaz>root starts out with password set to empty string, so you can always log in to root until you set a password (or disable the password) <lfam>I see. Or just create my user with an empty string <lfam>That's what I needed to know <lfam>Also see that image generation got way slower than it used to be. I guess <lfam>I guess I am in for a penny, in for a pound <lfam>Like I said, I wanted to work as a user, and I thought it would be easy <mra>bah, borked the bootloader on my testing install <mra>i think I'm close to getting at least somewhat functional root on zfs. i can get the zfs kernel module loaded in this initramfs, at which point it should just be a matter of specifying the disk as usual if you use a zfs pool with a legacy mountpoint <mra>I might be missing something, but it seems like there's actually surprisingly little to be done to get a functional root on zfs system, at least without the bells and whistles. if the patch to enable loading out-of-tree kernel modules into the initramfs is merged, the least straightforward part of installing a root on zfs system is just creating the installation medium <nikolar>oh are we getting root on zfs at some point <mra>nikolar: beats me, but i would like to make it a possibility. granted, I'm not experienced enough to be making any promises <nikolar>last i checked it seemed like very little was needed <nikolar>but same goes for me, so i didn't contribute <mra>I wouldn't be the first person to get a working guix system with root on zfs. it's doable. changes would just be needed to make it easier <mra>nikolar: iirc a couple things are needed. one of the big ones is a change to how initrd declarations work to make it possible to include the zfs kernel module in the initramfs <mra>someone wrote all of the code for that in 2022, so the work is done. I'm just going to see if I can get it merged <mra>thanks. I think that the licensing worries that may have prevented it from being merged the first time should all be wrinkled out? <mra>really oracle should just fix the license... <mra>but so goes it, I suppose <lfam>Did they get wrinkled out? <lfam>Or did Canonical just say "We dare you" to Oracle? <lfam>To be clear, I think the concerns are a bit overblown since Canonical only goes after money, so Guix wouldn't be a target. But still <lfam>I mean, Oracle only goes after money <nikolar>i think it's fine as long as zfs is distributed as dkms <mra>lfam: I think so. like, there is no chance of guix redistributing a compiled zfs here <mra>I think that the original concern was mainly over documentation. the concern effectively boiled down to the scenario: Bob builds an initrd with ZFS and `guix publish`es it, Alice tries to build an initrd with ZFS, and pulls Bob's built copy, so Bob commits a copyviol <lfam>The only entity that unwrinkle the situation is Oracle. Nobody is really interested in tangling with them <lfam>Lots of other entities have interpreted the situation in different ways, and tried different things. But it's definitely complicated and risky for anyone with money <mra>at any rate, introducing this change wouldn't make a copyviol any more possible. you could already build a Linux kernel with the ZFS module built in, and have the same problem I describe here <coyotes4ys>what is that option that i keep seeing people say to use with guix update <mra>lfam: i wrote an email discussing all of this on the guix-devel mailing list, if you're curious. it's probably more comprehensible than the gobbledegook I'm spouting here <lfam>Yes, I saw those! About substitutable, right? <lfam>I agree that "poisoning" things seems like a good way to stay safe, assuming it's really about compiled binaries vs source code <mra>lfam: partially. my point is basically that if we really want to be safe about copyviols, I think that a change would need to be make to derivations, so that when a derivation is declared, it can only be made substitutable if all of the derivations on which it depends are substitutable <mra>s/derivations/file-like objects, maybe? I'm not exactly sure what the difference is <lfam>Right, but the flip side is that the entire regime GPL interpretation is basically untested in the places where it matters: the courts <lfam>It almost always settles out of court, if it even gets to the point of a lawsuit being filed. <lfam>Not so easy to decide what to do, and previously nobody wanted to make a decision <lfam>It could be easier for us to decide now with the new GCD decision-making process <mra>I would argue that a decision has already tacitly been made. I can already write a Guix configuration which builds a custom Linux kernel which includes the ZFS kernel module. I'm not well-versed in the exact issues with CDDL/GPL conflicts, but my understanding is that distributing this would certainly be a copyviol. and, crucially, Linux kernels built with `make-linux-libre` or similar are marked as <lfam>The decision I'm referring to is "Should GNU Guix include this?" It's different from "Should mra do X?" <lfam>For what you just described, you would be the person violating copyright, not GNU Guix as an organization <mra>I agree. I'm not proposing any change that could cause GNU Guix as an organization to violate copyright. in fact, the original objections to 55231 being merged were entirely about individuals violating copyright, not GNU Guix the organization <mra>at least if I understood the concerns correctly <lfam>You probably do, since I think you read them recently and I didn't :) <lfam>I guess it was like, "We shouldn't make it too easy for an ignorant person to make themselves a target of Oracle." <mra>I absolutely agree that we shouldn't. Unfortunately, we already kind of do... <mra>modulo some debate about the meaning of "easy". I personally think that all of these scenarios are a bit contrived <mra>but I can understand wanting to avoid them on an organizational level <lfam>Yeah agreed about it being somewhat contrived. But it wouldn't be GNU if we didn't ascribe a very high level of importance to licensing :) <lfam>Like, if someone makes enough money with Guix and ZFS to get sued by Oracle... hooray! <mra>I absolutely agree! But if we really want to be fussy pedants about licensing, then I think that we would need "substitutable" to be poisoning to eliminate the possibility of distributing compiled binaries which mix GPL and CDDL code. <lfam>I think it's a good idea <mra>and at any rate, merging the changes to initrd in the meantime seems reasonable. I don't think that it makes the problem any worse <mra>nor any harder to solve <lfam>Or, something like "substitutable-poisoned?" because we already use this flag for packages where don't want to poison things <lfam>But that's a minor quibble <lfam>I think that pointing out when something doesn't make the problem any worse can be valuable in a discussion. Sometimes discussions can get hung up on the overall situation not being ideal, and changes that don't effect that aspect of it get blocked. But you still choose the status quo <coyotes4ys>thanks erbody for helps. my new guix system is starting to feel fully useful except i have yet to install an audio system. i am the user of a computer for the first time in my life! <coyotes4ys>this guix upgrade is downloading 4 gigs really slowly and it's a package i'm not sure i care about <apteryx>our way to search package by names is not efficient: guix search . | recsel -Pname -e 'name ~ "^alsa"' <apteryx>has to print the whole collection then pipe this to recsel <eikcaz>lfam: I saw your email. I really should have tested things with guix system not just guix home... Thanks for sticking through it thus far!! I'll update with a revised patch tonight (with --reroll-count this time). <eikcaz>Wait, are we not supposed to extend special-files-service-type? <eikcaz>nvm, mympd-service-type extends it (though that's the only one) <apteryx>any idea how I can delete a single key from the guix maintained ~/.config/guix/upstream/trustedkeys.kbx gpg keyring? <apteryx>found in (guix gnupg), it uses the --keyring argument <eikcaz>is there an easy way to ensure a service isn't run until AFTER skel has been applied to new users? <mange>It looks like the user account skeletons are applied at activation time, which I thought happened before starting Shepherd services. What behaviour are you seeing? I assume not that? <eikcaz>It's actually a special-files-service that I wanted to delay. I want to place a config at ~/.config/syncthing/config.xml, but that happens before skeletons are copied over, which then never happens because the home directory is non-empty <eikcaz>Honestly, Syncthing doesn't make sense as a system service in the first place. I upgraded the home service to work like I want, but now making the system work is becoming a headache... <mange>Okay, it looks like the skeletons are actually applied as part of the user-homes Shepherd service, whereas special-files-service happens at activation. <mange>Syncthing as a system service can make sense, though. On a multi-user machine you may want to configure it to sync even when you're not logged in. <eikcaz>That's a good point (in my headless setups, I have a service start a tmux and login as the user so my home services are always running) <eikcaz>Maybe I should just use a shepherd service instead of special-files service to copy the config from /gnu/store to the right place. Seems obtuse, but I don't see a simpler way. <mange>Yeah, I agree on both counts. A one shot service depending on the user-homes service should sequence things properly, I expect. <eikcaz>The other major downside is that the home service will diverge from the system service under the hood. The home service will use a home-files-service-type and shepherd service, and the system service will use two shepherd services. <mange>Another option could be to use the --config flag for syncthing to pass config directly? Then it doesn't need to live in a user's directory at all? <eikcaz>Another solution would have been to just make syncthing look for files at /etc/syncthing-<user>, but then I ran into the problem of permissions. I need /etc/syncthing-user to be owned by <user> <mange>Does syncthing need to write to its config directory? <eikcaz>Unfortunately, yes for the encryption keys. I could do that manually once as root, but the problem persits: only <user> should be able to read those keys. <eikcaz>I suppose I could have a shepherd service that just chowns /etc/syncthing-<user>. <mange>I'm looking at NixOS's syncthing service, and they use /var/lib/syncthing/.config/syncthing by default. Just if you're looking for prior art. <eikcaz>Hmm. How do they manage ownership? The current syncthing service can handle multiple users with their own syncthings <eikcaz>I'm trying to keep everything backwards compatible <mirai>eikcaz: I think the openssh service performs some copying within the service start section <mirai>you can put a lot of code within the start/stop section of the shepherd service, doesn't need to be only make-forkexec… <mange>It looks like the NixOS syncthing service only supports a single system-level instance. <eikcaz>mirai: having trouble finding documentation on this. <eikcaz>so I can do something like (start #~((system* ...) (make-forkexec...)))? <mirai>absolutely, though iirc you don't use system* <mirai>from memory, see networkmanager service and mympd/mpd service <mirai>those are examples of services with large (start …) bodies <mirai>nvm, networkmanager uses system*, yeah <mirai>I think shepherd shadows it though, it's not the regular system* <mirai>(or was it sleep that was shadowed, don't remember, there was a function that was a bad idea to be used within the bodies) <eikcaz>Alright, before launching syncthing, it chowns/chmods /etc/syncthing-<user> to that user 700. <mirai>nitpick, should that really be in /etc? why not in /var/lib ? <mirai>I dropped in mid-conversation so perhaps I'm lacking the context but /etc is generally for non "dynamic-ish" things <eikcaz>totally fair. I'll make that change. Thanks <eikcaz>I want to use the boolean value of 'config-file in a gexp, but #$config-file complains because it's a record. I could do #$(not (not config-file)), but that seems like a quick way to get my patch rejected. <mange>You could use #$(if config-file #t #f) to be explicit. <Dboh>gday all, there is someone here active for a quick question? <mange>I'd recommend just asking. :) No point asking for permission to ask. <eikcaz>sneek, later tell lfam, see my latest patch. When specifying a config as a system service, syncthing configuration is moved to /var/lib/syncthing-<user>, which fixes the bug. I only do so when a config is specified to keep things backwards compatible. Let me know if you have any issues, and thanks for all the help! <Dboh>Anyone know about bulk sms sender ? <mange>Does bulk sms have anything to do with Guix? <pranav>Hello. While defining package variants using inheritance, I'd like to modify the phases of the parent package using modify-phases (just as with %standard-phases) but I cannot seem to find an accessor for package arguments plist...or package phases. <pranav>How does modification of package arguments work when using package inheritance to define variants? <mirai>it showcases both use of package/inherit, substitute-keyword-arguments and modify-phases <pranav>mirai: Thanks. That seems very helpful. <apoorv569>i'm working on project (web app) for which I require to run postgresql DB and redis. ATM I use docker to run these 2 services. But I was wondering if it possible to run these 2 within a guix shell environment? <carloratm>apoorv569: I have the same question, trying to avoid Docker as much as possible. I am now using devbox (a nix wrapper) but I wonder if I'm curious if guix can do it! <mange>The short answer is "you can". The longer answer is "you have to do a lot of work to make it happen". The first way you can do it is to use "guix shell" to bring the binaries in and run them yourself. I used to do this with Postgres and it's a pain. The second way you can do it is to use a "guix system container" to instantiate an operating system with the things you want. I haven't tried this but it sounds complica <mange>I'm not aware of a way to do it that is directly integrated into "guix shell", but the idea has come up a few times before. <apoorv569>mange: But is it possible to run those guix system containers automatically when you load the guix shell environment? <apoorv569>I should be able to quickly write a small system container config to run postgres and red system services (both are available). <mange>Ehhhh, kind of. In principle you can run whatever code you want in your manifest file. It's pretty hacky, though. It's not a supported Guix feature. <mange>There's no way to say "start a shell, and stop the system when I leave the shell", for instance. <apoorv569>could write a script to automate it I guess. <mange>If you write it in Guile I'm sure people would love to have it in Guix proper. :) You're not the first person to ask about this, even just this week. <mange>... Unless you asked about it earlier this week. I can't actually remember who it was. <mange>Yeah, I mean, if you have Guile code to do something like this then there's no reason it couldn't become a "guix dev-shell" command or something. Or another field on a manifest that "guix shell" can instantiate. <apoorv569>well I'm not sure I can write a top notch script.. my lisp skills are I would say 4 out of 10. <carloratm>it should levereage process-compose, as devbox does. Could be an idea <jadzi>also faced the challenge about services for my dev env. My solution was to run a separate shepherd process (just for my project) and define (shepherd services) for it to load. A little bit of work to config nginx/postgres/php (or whatever) is needed, but still that worked for me fine. Shepherd is a nice tool for that i think and starting the whole os seems an overkill really <apoorv569>using shepherd for this kind of thing, is a little overkill in my opinion.. its a per project thing.. shepherd services doesn't make sense to me. <jadzi>yeah mb, but it can be viewed just like a docker launching several services <apoorv569>well I'm mainly trying to this right now is because docker-compose is broken in latest guix.. I have a issue opened as well for this. <apoorv569>I though maybe I can just use guix for this as well rather than waiting for a fix. <apoorv569>jadzi: Its ok, you can do as you like BTW, don't let me discourage you in any way. <apoorv569>perhaps there could be some benefit that I am not seeing ATM. <jadzi>apoorv569: yeah, some better explanation from my side would be also appreciatable, sorry. I mean a separate shepherd process (running only a signle project services, listening on a some local-to-project socket) can be a nice choice i think <apoorv569>jadzi: ah! like you define it once and start/stop for your project as needed.. hmm.. <apoorv569>but to edit these services you have to reconfigure your entire system. <jadzi>nope, i just need to modify a service definition and reload <apoorv569>can you modidy a shepherd service live? with out reconfiguring system? <jadzi>Sherpherd process here isn't a PID 1 . First i just run a new `shepherd -s <project/socket/path> -c <project/services.scm>` process with my local user. When i need modification, first i do `herd -s <project/socket/path> stop <my-service>`, modify definition, then `herd -s <project/socket/path> load root <project/services.scm>` to apply new definition, and then `herd -s <project/socket/path> start <my-service>` <apoorv569>ah! ok.. I thought you saying defining services in system/home config.. but you seem to be running them from command line manually. <jadzi>that's right, just starting a project shepherd inside guix shell which runs all needed configured services <apoorv569>do you have such a service definition right now? <apoorv569>interesting.. you are literally running commands using `(system`.. I was thinking more like defining a system container.. which basically is like a stripped down guix os config. <aure84>Hello. Anyone with experience using the `guix system vm` to generate VMs with custom configurations? <meaty>Has anyone here had their 'herd status' hang? mine is doing that, but only for non-sudo <meaty>Also is there an easy way to find which log file a service writes to? <meaty>I'm also having issues with sound underruns (i think), which is how I discovered 'herd status' stopped working <apoorv569>meaty: for home user, I think the default dir/file shepherd writes log to is ~/.local/state/shepherd/HERE <apoorv569>you can ofcourse change path for log file for each service you write your self.. surely there is a way modify existing service's log file location as well. <apteryx>hi! is commit bbc1735be26 not working as advertised? it seems i need to use the 'guix' package along guix extensions to have them discovered (to have the GUIX_EXTENSIONS_PATH env. var. set) <apteryx>e.g.: 'guix shell guix-modules -- guix module --help' doesn't work, but 'guix shell guix guix-modules -- guix module --help' does <apteryx>using guix in a profile is not advisable, so it'd be nice if it worked without having to do tAT <hanker>> e.g.: 'guix shell guix-modules -- guix module --help' doesn't work, but 'guix shell guix guix-modules -- guix module --help' does <hanker>you should probably add this one to your system profile? <hanker>i'm not sure it makes a lot of sense to use it in a shell <df>can I start a guix repl from geiser, or does that not even make sense? <df>I'm not entirely sure what guix repl does, does it start a guile repl with the guix modules loaded? <df>(guix repl --interactive that is) <apoorv569>geiser, in case for guile uses guile repl I think by default. <apoorv569>I think guix repl is just guile repl but with some modules added to the load path already <apoorv569>for your project, you can use .dir-locals and anything to geiser-guile-load-path var.. then you connect to use the default geiser repl and do ,m (YOUR MODULE) in the repl <apoorv569>to run this, sudo $(guix system container --network FILE_NAME.scm) <apoorv569>the only issue ATM I have is, I need have terminal running this in background.. <df>oh, I think I see the problem <df>my GUILE_LOAD_PATH in the shell contains the guix source, but within emacs it doesn't <df>that should be easy enough to sort out <apoorv569>found another issue.. stopping and starting container seems to remove everything.. <df>but you're running an external guile and connecting to it rather than starting it from geiser? <user_oreloznog>Since I installed Guix System in 2018, I wrote a post on debian-facile site. 24000 visits. Hope some people have been able to come here by reading this post :) <zamfofex>user_oreloznog: Very comfy‐looking place/community, I almost kinda wish I could know French so I could be a member of it! <zamfofex>It’s been a little more than a little while since I last partook in a forum‐based community. I have very fond memories of it. <user_oreloznog>zamfofex: thank you! I l have some looks on this #guix channel and I know you like the Hurd too! <zamfofex>Yes! I suppose this is different from most people, but to me, one of the biggest tying things about Guix and the Hurd are their communities. I initially grew interested for technical merits, but I think the community helps tie everything together more than anything. <user_oreloznog>zamfofex: Same here: I'm a happy end user of Guix System, nice enough my daily use, while following nice people's adventures here :) <apoorv569>sudo $(guix system container --network --share=/var/lib/postgresql --share=/var/lib/redis container.scm) is this wrong for presistent storage? <apoorv569>I loose all data when I stop and restart container again. <csantosb>Hi Guix ! I haven't found any info in docs related to yhetil.org, the service I'm using the most, so I sent a patch #76119 <Z572>civodul: I installed some base package updates to core-package-team. <apoorv569>why is the --share option not working for guix system container? <hanker>Can I set another environment variable in /etc/bashrc or /etc/profile? <hanker>Can I set another environment variable in /etc/bashrc or /etc/profile using the system configuration? <Rutherther>hanker: env vars should be set in profile, not bashrc. And yes, you can, the session-environment service type is for that <hanker>can I add lines to the system bashrc? <pranav>Hello, is there a way to use a custom cmake package for the cmake-build-system without relying on unexported symbols? <pranav>What is the preferred method for getting around minimum cmake version assertions in packages? <Rutherther>hanker: you can modify anything in /etc with your system config, though editing bashrc in etc is going to be trickier, as it's default file with hardcoded contents, you would have to modify the essensial-services, use operating-system-etc-service to get the default configuration, and replace bashrc inside it <Rutherther>pranav: like with most build systems, the cmake package is replaced via an argument, specifically #:cmake <pranav>Rutherther: Thanks, I got an idea for how to modify the build-system record now. <Rutherther>pranav: modifying build system record for this is excessive <pranav>I see. So you meant argument to the package? Let me try. <civodul>i started looking at the Gash bug, without success so far <hanker>> hanker: you can modify anything in /etc with your system config, though editing bashrc in etc is going to be trickier, as it's default file with hardcoded contents, you would have to modify the essensial-services, use operating-system-etc-service to get the default configuration, and replace bashrc inside it <hanker>it's just the PS1 and sourcing completions <hanker>i can use skeletons to make a .bashrc the default <Laurence>Hello all. The info pages say to add additional channels to ~/.config/guix/channels.scm. Is there a system-wide equivalent, or should add to config.scm? <civodul>cbaines: i “inadvertently” rebooted hydra-guix-124, which runs the Coordinator <civodul>i’ve been rebooting the build machines behind ci.guix by chunk <cbaines>civodul, are you sure, I think the uptime on that machine is 5 days <civodul>anyway, i’m paying more attention now :-) <civodul>perhaps we should change the host name on the Coordinator machines? <cbaines>maybe, although things are still in flux at the moment <cbaines>eventually it would be good to neaten things up, but I'd like to see things working more first <civodul>“working more”, what do you mean? :-) <civodul>the machine that went offline while we were in Brussels? <Rutherther>Laurence: default guix pull location is /etc/guix/channels.scm. About putting channels to config scm, I would avoid that, the guix derivation will have to be computed every reconfigure if you don't pin the channels, they will be updated as well. So it will slow your reconfiguration time significantly <cbaines>civodul, that, plus hydra-guix-124 hasn't built much yet and more general issues like build submission slowness <Laurence>@Rutherther, thank you. Understood re channels in config.scm. So, I can add /etc/guix/channels.scm, and it will be picked up without needing to add anything in config.scm to accomplish that? <Laurence>Rutherther: Sorry, used to @ing people in a different chat tool <Rutherther>Laurence: yes, exactly, guix pull will take that file, so every user that does guix pull and doesn't have their own files will use those channels <Laurence>Rutherther: With you. I just discovered the "guix-for-channels" section in the manual that seems to indicate alering the guix-configuration service in config.scm. The doc for the channels field of guix-configuration says: This is to facilitate migration from earlier versions, which allowed for in-place modifications to ‘/etc/guix/channels.scm’. <erik``>I think there is a problem with fontconfig. In ~guix shell fontconfig gcc-toolchain~, then ~readelf --all $GUIX_ENVIRONMENT/lib/libfontconfig.so~ complains that it fails to read the file's magic number. This is in contrast with other shared libraries. <Rutherther>erik: doesn't happen for me on guix that's old few hours, so could be nondeterministic build / disk corruption <hanker>How can I arrange a static v6 networking setup with DHCPv4 ? <Laurence>Can somebody please tell me why sometimes "guix pull" advises to set GUIX_PROFILE="/home/laurence/.guix-profile", and other times GUIX_PROFILE="/home/laurence/.config/guix/current" <Rutherther>Laurence: are you sure it's the case? the first case should be advised by guix install, the second one by guix pull <Laurence>Rutherther: I think you're right! I had originally put the one advised by guix install in my .profile, so it's loaded by default. How should I be handling those variables? <Rutherther>sneek: later tell Laurence, those variables should be set only for sourcing specific etc/profile in one of the guix profiles. They aren't important otherwise, and should be unset <nckx>ACTION wonders whether erik's .so was really filled with nonsense, or just empty. <nckx>sneek: Later tell Laurence To explicate Rutherther's excellent answer: these aren't suggestions to edit your start-up files, but suggestions to paste into your *currently running shells* if they have trouble finding new stuff. *Future shells* should find everything just fine, but Guix can't change running processes' environment. <eikcaz>Reading the FSDG, it seems like there is room to explain how to obtain a guix installation with nonfree firmware. My logic here is that someone with a working laptop already has those nonfree firmware blobs, so adding just that wifi firmware is no different than copying them over. I just wrote a draft of a preamble to some instructions which even quotes the relevant section of the FSDG. Any thoughts? <meaty>'herd status' hangs for me but 'sudo herd status' doesn't, could anyone help me out? <meaty>The home services *are* running, I just can't get their info <meaty>actually, 'herd status $service' works; it's just the summary that hangs <eikcaz>meaty: I've had this issue on my Librem 5, but I never got to the bottom of it <eikcaz>I assumed my issue had something to do with aarch64 vs x86_64 (EXACT same home environment runs on both), but I'm guessing you are running on x86 <meaty>actually, I've found that specifically 'herd status emacs' hangs, where 'emacs' is the emacs daemon service I made <meaty>but that didn't happen previously <meaty>was there a recent rewrite to that part? I could swear it used to not show recent messages <ieure>eikcaz, Another option in this space (and one I'd personally like to see) is to ship an installer which doesn't require an internet connection. <ieure>It's not a mutually exclusive option. <ieure>The combination of Guix not supporting WiFi drivers *and* requiring internet to install at all makes for a rough experience; and dropping the requirement of internet to install feels tractable. <meaty>yes, it seems that a recent change to shepherd has broken functionality; removing that emacs service makes 'herd status' finish. but even if the service was malformed, it shouldn't damage core functionality <meaty>I've narrowed it down: the hang happens when the log file isn't in an accessible place (e.g. a home service trying to log to /var/log) <eikcaz>meaty: home services usually log to ~/.local/var/log/ <eikcaz>oh wait, maybe that's no longer the case. My logs there haven't been modified since 2023... <eikcaz>looks like it's ~/.local/state/log now <eikcaz>I'm guessing that get's changed via (system->home-service-type ...)? <eikcaz>nvm, I don't know what I'm talking about <meati>there needs to be a big revision of how shepherd is configured, I think. it's too confusing to write services <eikcaz>sneek, later tell lfam, when testing the syncthing configuration, make sure there aren't two syncthing instances running on the same port. It might be fine for you since you are using guix system vm, but when I tested with guix system container, I had to disable my local syncthing because it was allocating that port <sneek>Welcome back lfam, you have 2 messages! <sneek>lfam, eikcaz says: see my latest patch. When specifying a config as a system service, syncthing configuration is moved to /var/lib/syncthing-<user>, which fixes the bug. I only do so when a config is specified to keep things backwards compatible. Let me know if you have any issues, and thanks for all the help! <sneek>lfam, eikcaz says: when testing the syncthing configuration, make sure there aren't two syncthing instances running on the same port. It might be fine for you since you are using guix system vm, but when I tested with guix system container, I had to disable my local syncthing because it was allocating that port <lfam>sneek: later tell eikcaz: Thanks, I'm testing it now! <lfam>sneek: later tell eikcaz: I also saw your message in the logs regarding "Syncthing doesn't make sense as a system service". It's up to you if you want to keep that functionality in the patch. I agree it's less of an obvious choice than using it as a home service, although it does have some utility IMO. Like I said, it's up to you. <Rutherther>I think syncthing as a system service is usable if someone wants to sync with a 'server' <lfam>Interesting, what do you mean by a 'server'? <Rutherther>a computer that is online most of the time and can also run other services. I used syncthing like that at one point. I sync from laptop to pc, but rarely had both online at the same time, so they instead sync to the running server computer. The server computer isn't used by any users, hence there needs to be sort of a system service. Syncthing even supports passwords to encrypt with, so this server doesn't have to know the contents <lfam>I see. I run a host like that, but I use a systemd user service for that <lfam>And I set up the system to enable "lingering" for my user, so my services start at boot regardless of whether I log in or not <lfam>Syncthing as a system service works for on Guix too, because I don't use Guix home, and I administer the computer, so it doesn't matter that I'd need privileges <lfam>And it's nice to have everything in a single file <lfam>I mean to write that it "works for me" <lfam>Also, I think that for many users of Syncthing, it's mostly "set and forget". It's not a tool that requires frequent reconfiguring <lfam>What's the smallest web browser in Guix that supports Javascript? <mra>lfam: maybe surf? it's not good, and the javascript support is probably quite minimal, but it is a very small web browser which supports javascript <lfam>Surf works okay for the Syncthing web UI <mra>oh, what is the browser for? i didn't read the chat logs <mra>glad it works for the syncthing web ui <lfam>Yeah, I just want to use it to test some Syncthing stuff <sleepydog>that reminds me I have a dillo package I've been meaning to submit <lfam>We have the new dillo now <lfam>But, it didn't work for Syncthing <coyotes4ys>don't use javascript! it's proprietary. be the user of your own computer! fsf.org <lfam>Amazing that something can be free software and running on my own computer and people will still call it "proprietary" <mra>going to embed a wasm program in my personal website to use peoples' gpus to mine bitcoin and open source it <lfam>Finally a way to monetize the river of traffic to our personal websites <luca>I mean, that's what hackint does :P <coyotes4ys>or has something changed? is javascript lib code shared now? <lfam>It's free software if it is distributed with a free software license. End of story. <coyotes4ys>you seem offended, i merely care for all people and am raising the alarm <coyotes4ys>not sure if you are, but if you are, it's nothing against you lfam (: <lfam>Yeah, it's offensive when people make baseless accusations <nckx>The choice of programming language does not make software (non)free. JS is not special. <lfam>Let's drop the subject. It's clear now that I was discussing free software. <mra>i just want to talk about my favourite linux distro/package manager smh <coyotes4ys>speaking is my right, speaking about libre software is my duty here <lfam>Okay, I'll clarify. You wrote "it's not free software if it's javascript, lfam". That suggests that I'm using this channel to discuss non-free software, which is against the channel rules. But, you were incorrect, I was talking about Syncthing, which is free software. <Altadil>coyotes4ys: I don’t think lfam was trying to silence you, merely offering to drop the subject to avoid a flamewar. :) <mra>i genuinely don't even understand what if any point is being made, and at any rate this seems unproductive <eikcaz>lfam: until guix-home-service-type includes the ability to run home-shepherd-service's at boot, the system syncthing service is the only (builtin) way to launch syncthing on boot. For that reason, I decided to keep supporting the non-home syncthing service even though the solution feels a bit icky. <sneek>eikcaz, you have 2 messages! <sneek>eikcaz, lfam says: Thanks, I'm testing it now! <sneek>eikcaz, lfam says: I also saw your message in the logs regarding "Syncthing doesn't make sense as a system service". It's up to you if you want to keep that functionality in the patch. I agree it's less of an obvious choice than using it as a home service, although it does have some utility IMO. Like I said, it's up to you. <coyotes4ys>i am reading what someone has linked on this right now. perhaps i'll answer your assertion of unproductiveness soon, mra. <nckx>I suggest we drop this unproductive subject and resist attempts to rekindle it. <mra>feel free to not respond to anything that i say <lfam>eikcaz: Okay, that makes sense. And I don't think it's too icky. I just think we'd both rather have a fully unprivileged way to manage this stuff. <mra>oh, interesting. there are very few instances of `#:substitutable? #f` in guix packages <mra>i wonder if zfs is actually the only significant instance... <nckx>Well, it should be an exceptional case… <nckx>So I rebooted my kursed kernel once and now my backspace key works fine and… my screen brightness keys don't work. Just sharing this in case it happened to anyone. Because I'm feeling pretty alone and confusled right now. <eikcaz>lfam: agreed. My solution is as simple system shepherd service that creates a root tmux in which I launch a login shell for each user in a list. That way, certain users have their home services launch correctly at boot. <nckx>mra: The only other examples I can remember are ‘this is cheaper to build locally than open a TCP connexion for it’ or ‘this is machine-specific and will never™ be substituted anyway’. <lfam>mra: The only use I can think of is texlivetexmf, where we just download a multi-gigabyte data file. No point in proxying that through the Guix servers <mra>oh, i wouldn't be suprised if it is the only case, it's just interesting if that is the case <lfam>mra: And that use case is why I think the "poisoning" idea should go into a new option, rather than substitutable? <eikcaz>Does anyone think a similar patch to guix-home-service-type (auto start certain users at boot) would get through a patch review? I'd be willing to work on that after the syncthing patch, but I'd want to know if there's a reason NOT to do this first. <lfam>I was referring to your tmux hack <mra>yeah, a quick check suggests that the three types of `#:substitutable? #f` are: very big file, weird cpu-specific sorcery for extremely fast math, and zfs <lfam>I'm not sure what is the state of the art in Guix user services. But I think we have logind, right? And logind can do `loginctl enable-linger $user`, which does what we want <lfam>"Back in the day", there was talk about of making that work for this use case. Not sure if it ever happened <mra>lfam: yeah, i wanted to look at this in the context of the poisoning idea. zfs is the only package that has this specific "poisoning" behaviour <mra>so it's not specifically tied to substitutable. it's kind of literally just a zfs thing insofar as i can tell <eikcaz>To extend the guix-home-service-type, I could imagine allowing an optional third entry which says weather or not to launch a tmux (or screen or whatever) for that user at boot. <lfam>Could just make a new option #:susbstitutable-transitive? <nckx>Has anyone proposed concrete semantics for this ‘poisoning’ (what a word…) yet? <lfam>eikcaz: Yeah, but I think we'd rather not use tmux / screen for this. Of course it's a useful hack but I don't think it would get through code review. But I say that not really knowing much about user services or Guix home <lfam>I'm just sure there's a better more "Guix-y" way <coyotes4ys>ok it's clear i misunderstood the javascript issue. sorry lfam. <lfam>Alright. We know it's complicated, but Javascript can be free. <coyotes4ys>i was assuming the obfuscript, as stallman calls it, is part and parcel of all js use <lfam>Trying to find a way forward for ZFS in Guix <eikcaz>lfam: I think "loginctl enable-linger" only prevents processes from being killed, not start a login process. In order for guix home to launch, you need to start a login shell. If we want the user to be able to access that shell, we need to wrap it in something like tmux or screen (supporting multiple should be trivial). Otherwise, a simple shepherd service that just runs "/bin/sh --login" as that user might do the trick <lfam>eikcaz: Hm, I think it does what we want. At least it does in conjunction with systemd user-defined services on Debian. <lfam>"At least" is doing a lot of work, I know <lfam>I'm not sure how it really works under the hood <mra>nckx: oh, yeah, this is just related to me trying to figure out how to get around some licensing concerns that people may have about allowing zfs to be built in to initrds <mra>i probably just need to wait for someone to review the patches that i submitted, but i haven't got much to do until the school semester starts anew, and thinking is a good time-waster <lfam>When does the semester start? <eikcaz>lfam: I'm guessing that enable-linger is working in conjunction with something else (systemd) that is actually launching the services, which makes sense if systemd does not creat a login session to launch user services normally. <lfam>Yeah... maybe we should copy it :) <mra>i'm a master's student in europe, for whatever that's worth. semesters are probably different elsewhere <lfam>eikcaz: And "that's a good test" with the system-level syncthing service using the new config interface <eikcaz>lfam: elogind-configuration seems to already set enable-linger to true. kill-user-processes? defaults to #f, which according to loginctl/logind.conf documentation is the same thing <lfam>I see, so there is indeed something extra happening with systemd <coyotes4ys>does anyone in here do without a taskbar? perhaps do you use openbox's middleiclick menu? <mra>it's a window manager written in elisp which uses emacs as a backend <coyotes4ys>i have everything on the middleclick i want, except for time, batt/power, and maybe one other thing