Hmm, not sure why ofborg complains about this, works locally, though perhaps there is a more portable way to refer to libc?

attribute 'dev' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/eval-1-lassulus.ewr1.nix.ci/pkgs/development/libraries/attr/default.nix:32:13

I'd prefer a shim that complains, like what gentoo uses:

https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-apps/attr/files/xattr-shim.h?id=077738eb8a9905827e615ddb1ac2e788337b1291

I don't know much about the change but either it's wrong and should be reverted or it's "right" and non-compliant programs should have their usage flagged or rejected, depending on the reasons for the change. Yes there are grays between but that's why I suggest the gentler shim/warning approach :).

This also avoids propagating the libc dep, although I'm not sure that is ever useful here O:).

I'd prefer a shim that complains, like what gentoo uses:

Right, that's cleaner. I added shim inline.

Duh, it's part of the stdenv, that explains why stdenv.cc.libc.dev didn't work (and why fetchpatch didn't work, that stymied me quite a while when writing this 😆)

I don't know much about the change but either it's wrong and should be reverted or it's "right" and non-compliant programs should have their usage flagged or rejected

Upstream's reasoning (which sounds sane to me, at least since we haven't really seen tons of failures)

Remove <attr/xattr.h> and the syscall wrappers
The xattr syscalls are provided by glibc since ages, so there is no need to use
the indirect system call "syscall" anymore. This removes the need for the
<attr/xattr.h> header; use <sys/xattr.h> instead.

http://git.savannah.nongnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38

The syscall wrappers have been partially reverted, which I included as a patch.

Thanks for info and updates, generally LGTM!

Just a thought: is the list over on #53716 complete? Maybe it's not worth plumbing the shim/symlink over, and we should instead patch/update the packages in question?

Said a different way: How do we avoid this becoming a permanent workaround? The patch will presumably be noticed when it doesn't apply on next version bump, but not sure how to handle the compatibility header. I suppose it doesn't really hurt anyone/anything .....

Just a thought: is the list over on #53716 complete?

No, just random stuff I found while I was looking for something else, though it shouldn't be a huge amount. Full build log search on hydra would be awesome...

... a while later

Scrambled together some shell scripts and got a full list of x86_64-linux packages who's build log contains attr/xattr.h: No such file or directory:

nixpkgs.aide.x86_64-linux
nixpkgs.bcachefs-tools.x86_64-linux
nixpkgs.diod.x86_64-linux
nixpkgs.haskellPackages.xattr.x86_64-linux
nixpkgs.mhddfs.x86_64-linux
nixpkgs.smbnetfs.x86_64-linux

(edit: removed duplicates)

That's not really a lot, so I agree, it's probably better to fix those instead.

Removed the shim entirely, better to just fix the few packages which fails (close to complete list at #53716, I count 7 remaining failures).

Not sure if the patch is important (though it's upstream, so probably won't hurt). The main motivation from upstream:

Switch back to syscall() for the *xattr system calls. The current
mechanism of forwarding those calls to glibc breaks libraries like
libfakeroot (fakeroot) and libasan (the gcc address sanitizer; gcc
-fsanitize=address).

full commit