linux-libc-dev and libc6-dev do not agree who owns fsconfig_command
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glibc (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
libvirt (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Right now in kinetic-proposed builds are failing due to both sets of headers defining fsconfig_command.
(kinetic-
libc6-dev:
Installed: 2.36-0ubuntu1
Candidate: 2.36-0ubuntu1
Version table:
*** 2.36-0ubuntu1 500
500 http://
100 /var/lib/
2.35-0ubuntu3 500
500 http://
linux-libc-dev:
Installed: 5.19.0-15.15
Candidate: 5.19.0-15.15
Version table:
*** 5.19.0-15.15 500
500 http://
100 /var/lib/
5.15.0-27.28 500
500 http://
Actually also with "just the kernel" from proposed this happens as in the past only:
linux-
included that struct.
File ownership
$ dpkg -S /usr/include/
libc6-dev:amd64: /usr/include/
linux-libc-
Example error from building libvirt:
In file included from /usr/include/
/usr/include/
95 | enum fsconfig_command {
| ^~~~~~~~~~~~~~~~
In file included from ../../src/
/usr/include/
189 | enum fsconfig_command
| ^~~~~~~~~~~~~~~~
Repro-test:
$ cat test.c
# include <sys/mount.h>
# include <linux/fs.h>
#include <stdio.h>
int main() {
printf("Hello %d", FSCONFIG_SET_FLAG);
return 0;
}
gcc test.c -o /dev/null
In file included from /usr/include/
/usr/include/
95 | enum fsconfig_command {
| ^~~~~~~~~~~~~~~~
In file included from test.c:1:
/usr/include/
189 | enum fsconfig_command
| ^~~~~~~~~~~~~~~~
/usr/include/
96 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
/usr/include/
191 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
/usr/include/
97 | FSCONFIG_SET_STRING = 1, /* Set parameter, supplying a string value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
193 | FSCONFIG_SET_STRING = 1, /* Set parameter, supplying a string value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
98 | FSCONFIG_SET_BINARY = 2, /* Set parameter, supplying a binary blob value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
195 | FSCONFIG_SET_BINARY = 2, /* Set parameter, supplying a binary blob value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
99 | FSCONFIG_SET_PATH = 3, /* Set parameter, supplying an object by path */
| ^~~~~~~~~~~~~~~~~
/usr/include/
197 | FSCONFIG_SET_PATH = 3, /* Set parameter, supplying an object by path */
| ^~~~~~~~~~~~~~~~~
/usr/include/
100 | FSCONFIG_
| ^~~~~~~
/usr/include/
199 | FSCONFIG_
| ^~~~~~~
/usr/include/
101 | FSCONFIG_SET_FD = 5, /* Set parameter, supplying an object by fd */
| ^~~~~~~~~~~~~~~
/usr/include/
201 | FSCONFIG_SET_FD = 5, /* Set parameter, supplying an object by fd */
| ^~~~~~~~~~~~~~~
/usr/include/
102 | FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
203 | FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/
103 | FSCONFIG_
| ^~~~~~~
/usr/include/
205 | FSCONFIG_
| ^~~~~~~
/usr/include/
129 | struct mount_attr {
| ^~~~~~~~~~
/usr/include/
161 | struct mount_attr
| ^~~~~~~~~~
tags: | removed: update-excuse |
And something on arm64 already forces this, despite only being in -proposed.
For example if someone tries
linux-libc-dev (<5.19.0-1),
to avoid this FTBFS for now that works on all other architectures (right now), but on arm64 gives me:
Missing build dependencies: linux-libc-dev (<= 5.19.0-1)
So while both still exist:
linux-libc-dev | 5.15.0-27.28 | kinetic | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
linux-libc-dev | 5.19.0-15.15 | kinetic-proposed | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
Probably some other dependency makes this non-avoidable for now.