I tried reaching out to the software owners at OASIS but the email address provided for queries about sgml-docbook returned an undeliverable mail message.
My questions are:
I have been trying different solutions to this for the past 3 days. No one else has reported such an issue. From the dependency tree it seems that sgml-docbook is a dependency of util-linux. Should this not be affecting everyone?
This dependency has not changed in the last 3 days (since my last flake update). Why is it being required to be rebuilt?
I fixed my issue locally by overriding the url to point to the file offered by voidlinux: Index of /ISOEnts-1986/
Hashes are different so not sure if this is something that would be accepted upstream or not. I’ll add that to my list of questions!
Whats the normal nixpkgs approach to dead links, can a non-hash-matching alternative be provided if the build still passes? (Caveat, I don’t know what was in the original zip but nothing looks out of the ordinary in the voidlinux version to my untrained eye)
I have been trying different solutions to this for the past 3 days. No one else has reported such an issue. From the dependency tree it seems that sgml-docbook is a dependency of util-linux. Should this not be affecting everyone?
This dependency has not changed in the last 3 days (since my last flake update). Why is it being required to be rebuilt?
I suspect that both of these are answered by binary cache substitutions on nixos/linux being a lot more robust than on macos (which I presume you are using?). Hydra built it successfully and everything in its dependency tree hasn’t changed on the linux platforms since then.
Im not using macos but yes - i had my caches misconfigured so i wasnt pulling from the binary cache.
That being said though, it seems this is a direct dependency of utils-linux. Its against the spirit of nixos if we cant built a system from bootstrap without an implicit hard requirement on a binary cache. Then again, the ISOEnts file being hosted in some arbitrary place probably falls in the same category too.
Should I upstream the url change to the voidlinux archive host instead?
It does sound like oasis isn’t responsive, and that’d be the right thing to do if the de-facto source changed - have other distros run into the same issue?
Yes, it is definitely a problem of nixpkgs if you can not properly bootstrap from zero without using the cache. The problem here is, there are basically no tests ensuring this, as that would be quite expensive… Each staging merge is already “struggling” over the resource usage involved. At least it feels a bit like that.
The correct source (matching hash) is available from Wayback Machine.
You can workaround the issue without modifying your nixpkgs by running nix-prefetch-url https://web.archive.org/web/20250220122223/http://xml.coverpages.org/ISOEnts.zip, and then it won’t try to download it from the down host because it will already be in the store.
I’ve done this with npm deps that liked blipping in and out of existence in the past. If you want to tie it to a specific project so you can more easily remember what and why you should eventually delete a gcroot, you can do something like: