In file included from _dist/src/github.com/lxc/lxd/shared/idmap/shift_linux.go:45:
./../../lxd/include/syscall_wrappers.h:19:19: error: conflicting types for 'close_range'; have 'int(unsigned int, unsigned int, unsigned int)'
19 | static inline int close_range(unsigned int fd, unsigned int max_fd, unsigned int flags)
In file included from /usr/include/unistd.h:1205,
This is an unstable amd64 chroot image at a tinderbox (==build bot)
 x86_64-pc-linux-gnu-11.2.0 *
clang version 12.0.1
Thread model: posix
Available Ruby profiles:
 ruby26 (with Rubygems)
 ruby30 (with Rubygems) *
Available Rust versions:
 rust-bin-1.54.0 *
The following VMs are available for generation-2:
*) AdoptOpenJDK JRE 8.292_p10 [openjdk-jre-bin-8]
Available Java Virtual Machines:
 openjdk-jre-bin-8 system-vm
The Glorious Glasgow Haskell Compilation System, version 8.10.4
HEAD of ::gentoo
Author: Repository mirror & CI <firstname.lastname@example.org>
Date: Sun Aug 8 21:21:50 2021 +0000
2021-08-08 21:21:49 UTC
emerge -qpvO app-emulation/lxd
[ebuild N ] app-emulation/lxd-4.0.7 USE="ipv6 nls -apparmor -verify-sig"
Created attachment 731671 [details]
Created attachment 731674 [details]
Created attachment 731677 [details]
Created attachment 731680 [details]
Created attachment 731683 [details]
Created attachment 731686 [details]
Patch from upstream master: https://github.com/lxc/lxd/commit/9a128f32fc277dd0c07bc85c71dc25d123f8a831.
Not clear if anybody has backported it but it should be simple from a glance. Let me know if you need help/turns out not to be!
Thanks, I do have few questions:
1. How close we are to unmasking glibc-2.34? lxd-4.0.7 was just released so I expect a next one will be months away. Then again they usually make a quicker release for big fixes like this. I do see the tracker bug is about ~20 done.
2: Will there be some runtime issues if you compile lxd-4.0.7 with glibc-2.33, then update to glibc-2.34 without recompiling? I.e., does this require a revbump?
(In reply to Joonas Niilola from comment #8)
> Thanks, I do have few questions:
> 1. How close we are to unmasking glibc-2.34? lxd-4.0.7 was just released so
> I expect a next one will be months away. Then again they usually make a
> quicker release for big fixes like this. I do see the tracker bug is about
> ~20 done.
Not very close, although trying to get stuff w/ patches done so we can focus on the ones where upstream is quiet / bugs need reporting.
It'll be a good while.
> 2: Will there be some runtime issues if you compile lxd-4.0.7 with
> glibc-2.33, then update to glibc-2.34 without recompiling? I.e., does this
> require a revbump?
No, all good there!
The bug has been closed via the following commit(s):
Author: Florian Schmaus <email@example.com>
AuthorDate: 2021-09-24 07:49:57 +0000
Commit: Florian Schmaus <firstname.lastname@example.org>
CommitDate: 2021-09-24 08:06:15 +0000
app-emulation/lxd: backport syscall_wrappers patch, use --syslog
This backports the lxd patch to avoid conflicts with glibc's
close_range(). Also use --syslog instead of
--logfile=/var/log/lxd/lxd.log in lxd's systemd service, so that lxd's
log messages are not logged to a file, but instead to the service's
The ebuild also no longer uses a dedicated apparmor service
file (files/lxd-4.0.0_apparmor.service), but instead patches the
existing service file if apparmor is used. This avoids maintaining two
systemd service files.
Also drop the unused autotools eclass.
Signed-off-by: Florian Schmaus <email@example.com>
app-emulation/lxd/files/lxd-4.0.7-r1.service | 20 +++
...appers-don-t-conflict-with-glibc-provided.patch | 58 +++++++
app-emulation/lxd/lxd-4.0.7-r1.ebuild | 170 +++++++++++++++++++++
3 files changed, 248 insertions(+)