Change:
insync = callPackage ../applications/networking/insync { }; <del> insync-v3 = libsForQt5.callPackage ../applications/networking/insync/v3.nix { }; </del> libstrangle = callPackage ../tools/X11/libstrangle { stdenv = stdenv_32bit; };

Discussion:
Steps to reproduce the behavior: -shell -p insync-v3 Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(sylvanus): nixpkgs:
Hi! I created an overlay and my installation worked. But Insync doesn't start yet using . Using after start I receive
FYI: I made build and insync-v3 run again, but I need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!

insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this?

insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github.

To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.