These are the channel logs matching your query syncthing
| 2025-10-15 | [15:54:30] <efraim> try the syncthing service |
| 2025-10-13 | [19:24:56] <gabber> gabber: i think syncthing would be what you're looking for |
| 2025-08-26 | [16:12:30] <unwox> but is it possible to run user home services without login in though? if for example i wanted to run home-syncthing-service-type under a certain non-root user on a server? |
| 2025-06-08 | [20:45:33] <podiki> anyone else use syncthing-gtk? seems it is broken (again) with a librsvg issue, same as in https://issues.guix.gnu.org/52673 but don't see the cause now (just one librsvg in gi_typelib_path) |
| 2025-06-08 | [20:52:13] <podiki> unclear if it works (but don't see the tray icon) or just hangs with "guix shell syncthing-gtk glib:bin --pure -- syncthing-gtk" |
| 2025-06-08 | [21:07:49] <podiki> yes (well just using the syncthing-gtk wrapper script GI_TYPELIB_PATH rather than how it adds to the env) |
| 2025-06-08 | [21:57:34] <podiki> "guix shell syncthing-gtk glib:bin dbus gdk-pixbuf --pure -- syncthing-gtk" gets me to same error (rsvg) in a pure shell, without dbus or gdk-pixbuf it hangs before that |
| 2025-06-04 | [03:40:55] <Tadhgmister> woot! I got my cross compiled guix deployed to my router and running syncthing and transmission! |
| 2025-06-04 | [04:21:39] <Tadhgmister> I now heed to push my changes to syncthing to allow it to be cross compiled for everyone |
| 2025-06-04 | [04:22:15] <Tadhgmister> *submit patch / pull request for changes to guix's syncthing package |
| 2025-05-23 | [21:57:29] <Tadhgmister> idk, syncthing gave a warning that it couldn't use ipv6 so I ran `ip addr` to see if I had an ipv6 address and my eyes just glossed over `inet6` thinking it was the mac address |
| 2025-05-02 | [18:47:30] <Tadhgmister> I am not understanding something about cross compiling go projects, when I try to cross compile syncthing it gives me an error that `go install` isn't allowed when `GOBIN` is set and the internet suggests I should just be using `go build` instead... but it looks like the go-build-system just sets `GOBIN` and runs `go install` so I don't see how |
| 2025-03-20 | [20:57:00] <attila_lendvai> re syncthing: i move the *.pem files, but what about ~/.config/syncthing/index-v0.14.0.db/ ? that sure sounds like something for ~/.local/state/ |
| 2025-03-14 | [20:54:08] <eikcaz> lfam: first thing I notice: generally, upgrading will automatically remove ~/.config/syncthing/config.xml because it is just another symlink managed by guix. It only won't work if ~/.config/syncthing/config.xml became a file for one of a few but very rare situations |
| 2025-03-13 | [03:27:06] <sneek> lfam, eikcaz says: I think I figured out the path with the least friction: if someone sets `config-file' then the service will just do (approxiately) "mv ~/.config/syncthing/config.xml ~/.config/syncthing/config.xml.bak", then the news entry can just explain that their device ID might change and how to get it back (and maybe a similar note in the docs for users that used ~/.config for unrelated reasons). |
| 2025-03-12 | [01:26:06] <eikcaz> lfam: btw I think my email made upgrading sound harder than it is. 99% of the time the only thing that will happen is their device ID changes exactly once. Moving things from ~/.config/syncthing to ~/.local/state/syncthing will prevent the ID change. Otherwise, steps to fix are obvious (guix complains about mispelled record name). |
| 2025-03-12 | [19:30:06] <eikcaz> sneek: later tell lfam: I think I figured out the path with the least friction: if someone sets `config-file' then the service will just do (approxiately) "mv ~/.config/syncthing/config.xml ~/.config/syncthing/config.xml.bak", then the news entry can just explain that their device ID might change and how to get it back (and maybe a similar note in the docs for users that used ~/.config for unrelated reasons). |
| 2025-03-12 | [20:52:58] <acrow> I'm trying to understand some unexpected guix behaviors. I'm running a guix system serving syncthing. So system installs the syncthing package. I've found that the syncthing service has a problem in the newest version. So, I want to keep the old (still in /gnu/store) version. |
| 2025-03-12 | [20:54:24] <acrow> I put the old package def of syncthing at the top of my config.scm and reconfigure. But the newest version continues to appear. I'm puzzled. |
| 2025-03-12 | [20:56:44] <acrow> I'm afraid to restart the syncthing-<user> service because I believe it will use the newer problematic version. |
| 2025-03-12 | [21:09:18] <acrow> syncthing package that was visible to the operating-system. Not so? |
| 2025-03-12 | [21:11:30] <Rutherther> acrow: no, not at all, that is not how guile works. The service uses the syncthing in syncthing-configuration-syncthing. |
| 2025-03-12 | [21:13:08] <Rutherther> acrow: so just set the syncthing field in your syncthing-configuration to your package and you're fine |
| 2025-03-12 | [21:14:14] <acrow> Rutherther: So, I'm looking at the syncthing-configuration (service). All I need to do is add (syncthing syncthing) to my configuration to get it to pick up the older package? Hmm, giving it a try. |
| 2025-03-12 | [21:14:34] <Rutherther> acrow: no, not at all, that is not how guile works. The service uses the syncthing in syncthing-configuration-syncthing. |
| 2025-03-12 | [21:16:08] <acrow> ACTION looks around for syncthing-configuration-syncthing |
| 2025-03-12 | [21:19:16] <acrow> syncthing package to use the service, right? |
| 2025-03-12 | [21:27:21] <acrow> Oh, it's a file-like object so we will have to do something like (file-append syncthing-old "/bin/syncthing")... I think. |
| 2025-03-12 | [21:28:36] <Rutherther> acrow: this file append where? the syncthing field expect a package, not an executable file. It will do the appending by itself. |
| 2025-03-12 | [21:30:59] <podiki> acrow: all you do is add (syncthing <your-package>) to the configuration of the service |
| 2025-03-12 | [21:39:17] <acrow> Thanks people. Before I restart the service -- is there a way to verify what the 'future' executable path will be? herd status syncthing-<user> returns the old executable but it would be good practice to do a dry-run sorta thing. |
| 2025-03-11 | [19:36:56] <eikcaz> lfam: not sure if you saw my latest patch for the Syncthing service revamp. Since fixing the initial errors is backwards incompatible, I'd like to get the patch through sooner than later. |
| 2025-03-11 | [19:38:30] <eikcaz> (1) update record names if you used any of the few that changed and (2) move contents of ~/.config/syncthing to ~/.local/state/syncthing |
| 2025-03-11 | [19:39:06] <eikcaz> (2) is actually relevant to anyone with a particularly old syncthing install as well. I made a note of this in the guix.texi, and a meta-note in the latest patch annotation |
| 2025-03-11 | [19:39:32] <jA_cOp> I set up the syncthing home service three weeks ago and it's already using .local/state/syncthing, so I guess it strictly doesn't affect all users |
| 2025-03-11 | [19:48:22] <peanuts> "Subject: [PATCH v1] services: syncthing: Improve Syncthnig code standard compliance." https://issues.guix.gnu.org/76379 |
| 2025-03-11 | [20:11:05] <lfam> sneek: later tell eikcaz: I have to go afk for a while too, but my goal is land the syncthing patch tonight. If the patch submission doesn't contain instructions for the "upgrade", please send an email describing the process. I'll make it into a Guix news entry so that users can hopefully handle it themselves |
| 2025-03-11 | [22:23:06] <sneek> eikcaz, lfam says: I have to go afk for a while too, but my goal is land the syncthing patch tonight. If the patch submission doesn't contain instructions for the "upgrade", please send an email describing the process. I'll make it into a Guix news entry so that users can hopefully handle it themselves |
| 2025-03-10 | [21:12:55] <peanuts> "[PATCH] (home-)syncthing-service: added support for config serialization" https://issues.guix.gnu.org/75959 |
| 2025-03-10 | [21:12:56] <peanuts> "Subject: [PATCH v1] services: syncthing: Improve Syncthnig code standard compliance." https://issues.guix.gnu.org/76379 |
| 2025-03-01 | [00:52:44] <jA_cOp> There was an important fix for the syncthing package committed four days ago, how do I get it? I do `guix pull` and `guix home reconfigure ...`, and in my home config I'm using home-syncthing-service-type. But syncthing on my system is still not built with the patch. What am I missing? |
| 2025-03-01 | [00:54:45] <jA_cOp> If I run `syncthing --version` I get `... (go1.21.13 linux-amd64) ...` while the patch updates syncthing to build with Go 1.23: https://codeberg.org/guix/guix-mirror/commit/68cd38756b51d4abd8c796a5bcbbb9ea053eafde |
| 2025-02-27 | [16:12:14] <acrow> Yes, that's basically what I did with only the slight improve of ending with (car (lookup-inferior-packages inferior "syncthing")) but guix didn't like that. It will prefer a manifest of one package? I'll give it a try. |
| 2025-02-23 | [18:14:01] <acrow> Has anyone else seen their syncthing cluster fail on the upgrade to v1.29.2? Guix allowed me to roll-back to v1.28.1 and things are now ok, but syncthing upstream seems unaware of the problem. |
| 2025-02-14 | [07:49:29] <lfam> By nameserver, do you mean the Syncthing discovery servers? |
| 2025-02-14 | [07:50:27] <lfam> Syncthing calls the device lookup servers "discovery servers" |
| 2025-02-14 | [07:53:17] <eikcaz> looks like I called them nameservers early on, then switched to the correct "global discovery servers" in the actual syncthing-config-file documentation |
| 2025-02-14 | [07:54:41] <lfam> So I was copy editing the docs, and I found that I didn't understand something about the patch. When I originally read the code, I glossed over syncthing-folder-devices and assumed it was about finding devices that were implicitly defined in folder configurations. But it's like a special case of syncthing-device that adds the introduction info and an encryption-password? Did I get that right? |
| 2025-02-14 | [08:02:01] <lfam> I think I need to set up such a configuration in my non-Guix-managed Syncthing cluster and see what kind of config it generates to understand fully, but that seems to make sense |
| 2025-02-14 | [08:02:45] <eikcaz> I considered allowing a device to be listed as (device [encryption-password [introducer]]), which would eliminate syncthing-device-folder, but I was worried that that would be abusing lists. |
| 2025-02-14 | [08:03:06] <eikcaz> I would suggest peeking at one of your existing syncthing configurations |
| 2025-02-14 | [08:11:05] <eikcaz> syncthing-folder-device has just BARELY enough structure that it seems worthy of its own record. I think most peolpe won't use it, which is why I made it optional to use at all (so long as you want the defaults) |
| 2025-02-14 | [08:21:16] <eikcaz> ^reading the syncthing-folder-device section. If it's not clear to you, then maybe it is a bug in the documentation :3 |
| 2025-02-13 | [06:52:21] <nico_> I'm trying to install a Syncthing service for my user. I found `syncthing-service-type` in the manual, but to me it is unclear how to add services. I tried to /etc/config.scm, but that resulted in an error. Also I assume I can just add it on a user level isntead of a system level. Should I create a new services entry in the user config (I installed Guix System). An example would be helpful. Also, do I need to install syncthing as a package, o |
| 2025-02-13 | [07:27:12] <dcunit3d> nico_: you can either run syncthing as a system service or a guix home service. if you want it to run on the user level, you can either start it once you login (somehow, outside of guix, as an autostart entry or something) or you can add it to the user's home-environment |
| 2025-02-13 | [08:34:58] <flypaper-ultimat> nico_: (home-environment (services (cons* (service home-syncthing-service-type) %base-home-services))) |
| 2025-02-10 | [21:56:36] <mirai> eikcaz: in your syncthing service start section |
| 2025-02-08 | [03:26:02] <eikcaz> the home field of the syncthing-configuration does not do what the docs say it does |
| 2025-02-08 | [11:24:53] <nico_> That is insightful. I heard Flatpak is still an option? And appimage hopefully? So would I be able to run Syncthing for example? |
| 2025-02-08 | [11:37:16] <arjan> syncthing is also packaged and there are even service definitions available for it |
| 2025-02-08 | [11:41:03] <Rutherther> nico_: flatpak is an option. AppImages can be harder, they usually need fhs and are difficult to get running in a container. You can for sure run syncthing as that's already packaged in guix and has a service |
| 2025-02-07 | [03:50:11] <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 |
| 2025-02-07 | [03:53:41] <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... |
| 2025-02-07 | [03:54:37] <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. |
| 2025-02-07 | [04:06:06] <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? |
| 2025-02-07 | [04:06:15] <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> |
| 2025-02-07 | [04:06:42] <mange> Does syncthing need to write to its config directory? |
| 2025-02-07 | [04:11:10] <eikcaz> I suppose I could have a shepherd service that just chowns /etc/syncthing-<user>. |
| 2025-02-07 | [04:15:48] <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. |
| 2025-02-07 | [04:16:44] <eikcaz> Hmm. How do they manage ownership? The current syncthing service can handle multiple users with their own syncthings |
| 2025-02-07 | [04:18:58] <mange> It looks like the NixOS syncthing service only supports a single system-level instance. |
| 2025-02-07 | [04:31:47] <eikcaz> Alright, before launching syncthing, it chowns/chmods /etc/syncthing-<user> to that user 700. |
| 2025-02-07 | [05:44:00] <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! |
| 2025-02-07 | [20:40:53] <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 |
| 2025-02-07 | [21:37:37] <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! |
| 2025-02-07 | [21:37:37] <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 |
| 2025-02-07 | [21:41:29] <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. |
| 2025-02-07 | [21:43:53] <Rutherther> I think syncthing as a system service is usable if someone wants to sync with a 'server' |
| 2025-02-07 | [21:46:34] <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 |
| 2025-02-07 | [21:48:25] <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 |
| 2025-02-07 | [21:49:13] <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 |
| 2025-02-07 | [22:03:23] <lfam> Surf works okay for the Syncthing web UI |
| 2025-02-07 | [22:04:21] <mra> glad it works for the syncthing web ui |
| 2025-02-07 | [22:05:32] <lfam> Yeah, I just want to use it to test some Syncthing stuff |
| 2025-02-07 | [22:06:43] <lfam> But, it didn't work for Syncthing |
| 2025-02-07 | [22:21:50] <lfam> This is a free software program, and it runs Javascript to provide a user interface: https://github.com/syncthing/syncthing/ |
| 2025-02-07 | [22:26:52] <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. |
| 2025-02-07 | [22:28:21] <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. |
| 2025-02-07 | [22:28:21] <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. |
| 2025-02-07 | [22:35:37] <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. |
| 2025-02-07 | [22:50:42] <lfam> eikcaz: And "that's a good test" with the system-level syncthing service using the new config interface |
| 2025-02-06 | [00:57:12] <sneek> lfam, eikcaz says: No worry! Thanks for the offer to review #75959. Let me know if you have any other questions or concerns. Configuring Syncthing from Guix has been neat, so I hope to share that. |
| 2025-02-06 | [00:57:26] <peanuts> "[PATCH] (home-)syncthing-service: added support for config serialization" https://issues.guix.gnu.org/75959 |
| 2025-02-06 | [02:10:10] <lfam> I'm starting to write a configuration for a VM image to test your syncthing contributions |
| 2025-02-06 | [02:15:38] <eikcaz> I did something like: guix shell -D guix -CPW -- ./pre-inst-env guix home container --share=/home/zacchae/tmp/guix empty-config.scm -- cp /home/zacchae/.config/syncthing/config.xml /home/zacchae/tmp/guix/empty-config.xml |
| 2025-02-06 | [02:16:40] <eikcaz> also leaving the container running shows that syncthing does not clobber the config |
| 2025-02-06 | [02:17:55] <lfam> eikcaz: That's a neat way to test it, but I don't use Guix home and learning it would only slow this process down :) And I have plenty of experience with Guix VMs. I'll try using your code to add a device to my Syncthing cluster and see how it goes |
| 2025-02-06 | [21:01:54] <lfam> sneek: later tell eikcaz: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices |
| 2025-02-06 | [22:43:27] <eikcaz> lfam: I see, looks like it's a bug in the documentation. Replace (syncthing-config-file (folders ...)) with (syncthing-config-file (syncthing-config-file (folders ... ))) and make sure you add any missing closing parens at the end |
| 2025-02-06 | [22:43:27] <sneek> eikcaz, lfam says: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices |