Change:
wayland xdg-utils ]; <ins> in stdenv.mkDerivation { version = "7.15.13"; pname = "feishu"; src = sources.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); nativeBuildInputs = [ autoPatchelfHook makeShellWrapper dpkg ]; buildInputs = [ gtk3 # for autopatchelf alsa-lib cups curl libXdamage libXtst libdrm libgcrypt libpulseaudio libxshmfence mesa nspr nss ]; </ins> dontUnpack = true; installPhase = ''

Discussion:
Steps to reproduce the behavior: Looks like previous URL is now invalid / offline: https://sf3- and new URL has a signature / expiration date: https://lf6-ug- <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yes, they changed the download link, and what's worse is that the and are dynamically generated. To generate a new link, we first need to access , which returns a json that contains the download link. But since this link is impure, we cannot really use that. Unless the original link is restored, I'm afraid there's no viable solution to this issue.
If upstream's CDN decides that people can only have a temporary link to their resources, there's nothing we can really do. Maybe tell people to download the .deb themselves and add that to the Nix store, à la .
I don't think is sufficient. The current download server only provides the latest version of , which means the hash will change with each update, causing the package to break.
Perhaps one of you could reach out to them. I tried, but I think they didn't understand what I meant and kept asking me to go to their website and click on the Linux download icon....
They replied me this: Is it of any use? (the mybucket on the url looks sus)
It would be of great use. But the link doesn't to work for me, seems to be an internal address.
Domain's unknown on my end. Might be internal or exclusive to China
Well yeah I also cant download it... I told them and they sent be back to their download page.. hard to talk with them.. meanwhile I found this: https://sf3- https://sf3- These links are working...
I do speak Chinese, so if you're encountering some language difficulties, I can provide some language aid :D Those links do seem to be working but they look kinda sketchy. Where do they even come from and, more crucially, the hash in the download link seems to be different for each artifact so we have to hunt them down for every update.

Not very maintainer-friendly if you ask me
Oh I found the secret sause! if you take the original link from here: and replace the domain: https://lf9-ug- with https://sf3- It works o/
IIIIIInteresting! That means we can easily automate the update logic into an update script and put that in ! Huzzah!
Looks like x8664-linux is platform 10 and aarch64-linux is platform 12. If we ever decide to support this on macOS, x8664-darwin is platform 6 and aarch64-darwin is platform 9. Still, upon further examination the "new" links are exactly the same format as the old ones... does that mean upstream just make their old binaries unavailable? That's a bit problematic...
This seems to work pretty well:
It gives 404 to me without the
Oops! Try instead :sweat_smile: Yes, sed is very hard to read but it's a lot simpler than doing it in jq
Welp, I tried to package the most recent version but I'm completely slumped by this mysterious SIGTRAP deep inside the code itself. is a vendored dependency and it's completely devoid of any debug symbols, which makes this very annoying to debug. The fact that getting GDB to work with two layers of wrappers is also very annoying and I'm feeling like I need some outside help. Any insights?
Could you please test my latest PR? I've been unable to reproduce the error you're experiencing. Additionally, it would be greatly appreciated if someone could verify the ARM build to ensure it's working as expected.