* btrfs-progs 6.1 broke the build for multiple applications
@ 2023-01-03 0:11 Neal Gompa
2023-01-03 11:39 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: Neal Gompa @ 2023-01-03 0:11 UTC (permalink / raw)
To: Btrfs BTRFS; +Cc: David Sterba, Josef Bacik, Qu Wenruo
Hey all,
It looks like btrfs-progs v6.1 broke the build for multiple
applications in Fedora.
Notably, it broke:
* btrfs-assistant
* buildah
* cri-o
* podman
* skopeo
* containerd
* moby/docker
* snapper
* source-to-image
The bug report is here: https://bugzilla.redhat.com/2157606
It looks like this change broke everything:
https://github.com/kdave/btrfs-progs/commit/03451430de7cd2fad18b0f01745545758bc975a5
--
Neal Gompa (FAS: ngompa)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs-progs 6.1 broke the build for multiple applications
2023-01-03 0:11 btrfs-progs 6.1 broke the build for multiple applications Neal Gompa
@ 2023-01-03 11:39 ` David Sterba
2023-01-03 12:02 ` Qu Wenruo
0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2023-01-03 11:39 UTC (permalink / raw)
To: Neal Gompa; +Cc: Btrfs BTRFS, David Sterba, Josef Bacik, Qu Wenruo
On Mon, Jan 02, 2023 at 07:11:57PM -0500, Neal Gompa wrote:
> Hey all,
>
> It looks like btrfs-progs v6.1 broke the build for multiple
> applications in Fedora.
>
> Notably, it broke:
>
> * btrfs-assistant
> * buildah
> * cri-o
> * podman
> * skopeo
> * containerd
> * moby/docker
> * snapper
> * source-to-image
>
> The bug report is here: https://bugzilla.redhat.com/2157606
>
> It looks like this change broke everything:
> https://github.com/kdave/btrfs-progs/commit/03451430de7cd2fad18b0f01745545758bc975a5
On no that's bad, I'm going to do a bugfix release today.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs-progs 6.1 broke the build for multiple applications
2023-01-03 11:39 ` David Sterba
@ 2023-01-03 12:02 ` Qu Wenruo
2023-01-03 12:06 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: Qu Wenruo @ 2023-01-03 12:02 UTC (permalink / raw)
To: dsterba, Neal Gompa; +Cc: Btrfs BTRFS, Josef Bacik, Qu Wenruo
On 2023/1/3 19:39, David Sterba wrote:
> On Mon, Jan 02, 2023 at 07:11:57PM -0500, Neal Gompa wrote:
>> Hey all,
>>
>> It looks like btrfs-progs v6.1 broke the build for multiple
>> applications in Fedora.
>>
>> Notably, it broke:
>>
>> * btrfs-assistant
>> * buildah
>> * cri-o
>> * podman
>> * skopeo
>> * containerd
>> * moby/docker
>> * snapper
>> * source-to-image
>>
>> The bug report is here: https://bugzilla.redhat.com/2157606
>>
>> It looks like this change broke everything:
>> https://github.com/kdave/btrfs-progs/commit/03451430de7cd2fad18b0f01745545758bc975a5
>
> On no that's bad, I'm going to do a bugfix release today.
I'm a little confused, why would those projects relying on the ioctl.h
from progs?
Shouldn't those things got exported through kernel uapi?
Thanks,
Qu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs-progs 6.1 broke the build for multiple applications
2023-01-03 12:02 ` Qu Wenruo
@ 2023-01-03 12:06 ` David Sterba
2023-01-03 18:00 ` Bjorn Neergaard
0 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2023-01-03 12:06 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, Neal Gompa, Btrfs BTRFS, Josef Bacik, Qu Wenruo
On Tue, Jan 03, 2023 at 08:02:27PM +0800, Qu Wenruo wrote:
>
>
> On 2023/1/3 19:39, David Sterba wrote:
> > On Mon, Jan 02, 2023 at 07:11:57PM -0500, Neal Gompa wrote:
> >> Hey all,
> >>
> >> It looks like btrfs-progs v6.1 broke the build for multiple
> >> applications in Fedora.
> >>
> >> Notably, it broke:
> >>
> >> * btrfs-assistant
> >> * buildah
> >> * cri-o
> >> * podman
> >> * skopeo
> >> * containerd
> >> * moby/docker
> >> * snapper
> >> * source-to-image
> >>
> >> The bug report is here: https://bugzilla.redhat.com/2157606
> >>
> >> It looks like this change broke everything:
> >> https://github.com/kdave/btrfs-progs/commit/03451430de7cd2fad18b0f01745545758bc975a5
> >
> > On no that's bad, I'm going to do a bugfix release today.
>
> I'm a little confused, why would those projects relying on the ioctl.h
> from progs?
Because they're probably using the legacy libbtrfs and headers from
/usr/bin/btrfs/*.h, it'll take time before all could be switched to
libbtrfsutil.
> Shouldn't those things got exported through kernel uapi?
The kernel UAPI reflects what the installed and possibly running kernel
API is providing, interfaces that can be used at run time. But the build
can be against any newer version even with functionality not implemented
by the kernel. Think LTS stable releases vs updated btrfs-progs.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs-progs 6.1 broke the build for multiple applications
2023-01-03 12:06 ` David Sterba
@ 2023-01-03 18:00 ` Bjorn Neergaard
2023-01-04 17:23 ` Bjorn Neergaard
0 siblings, 1 reply; 6+ messages in thread
From: Bjorn Neergaard @ 2023-01-03 18:00 UTC (permalink / raw)
To: dsterba, Neal Gompa, Qu Wenruo; +Cc: Btrfs BTRFS, Josef Bacik, Qu Wenruo
Hey all,
Just wanted to chime in here from a Moby (Docker) standpoint:
On 2023/1/3 19:39, David Sterba wrote:
> On no that's bad, I'm going to do a bugfix release today.
For what it's worth, if we need to have a flag day, this is probably the
time to do it. The projects in the container ecosystem are reacting by
moving to libbtrfsutils or adding a define, so the damage is mostly done
(there at least), and I would suggest that distros can carry patches if
they need to use newer btrfs-progs with older tool versions.
Or, at the very least, this seems advantageous from a btrfs-progs
maintainers standpoint, and should be scheduled to be re-implemented in
a future release. Perhaps it could be gated behind a personality define
until it is made the default?
On 1/3/23 5:06 AM, David Sterba wrote:
> On Tue, Jan 03, 2023 at 08:02:27PM +0800, Qu Wenruo wrote:
>> I'm a little confused, why would those projects relying on the ioctl.h
>> from progs?
> Because they're probably using the legacy libbtrfs and headers from
> /usr/bin/btrfs/*.h, it'll take time before all could be switched to
> libbtrfsutil.
For older Moby branches, we're looking at using libbtrfsutils going forward.
>> Shouldn't those things got exported through kernel uapi?
>
> The kernel UAPI reflects what the installed and possibly running kernel
> API is providing, interfaces that can be used at run time. But the build
> can be against any newer version even with functionality not implemented
> by the kernel. Think LTS stable releases vs updated btrfs-progs.
Going forward in Moby, we're planning to depend on the uAPI, until there
is something we need that is not widely available. Currently, only EL
7's 3.10-series kernel does not include the structures we need in the
uAPI headers; as such right now it seems reasonable to depend on the
kernel headers instead of an additional userspace library.
This is largely because RHEL 7 deprecated Btrfs support, and while it's
supported in Oracle Linux 7, that is only with the UEK, which will have
an updated uAPI. Interested vendors (e.g. Mirantis)/users can still
build for a 3.10 kernel with Btrfs by providing their own headers.
Bjorn
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs-progs 6.1 broke the build for multiple applications
2023-01-03 18:00 ` Bjorn Neergaard
@ 2023-01-04 17:23 ` Bjorn Neergaard
0 siblings, 0 replies; 6+ messages in thread
From: Bjorn Neergaard @ 2023-01-04 17:23 UTC (permalink / raw)
To: dsterba, Neal Gompa, Qu Wenruo; +Cc: Btrfs BTRFS, Josef Bacik, Qu Wenruo
> For older Moby branches, we're looking at using libbtrfsutils going
> forward.
As a slight update, it turns out this is not viable, as only btrfsutil.h
is packaged by distros packaging libbtrfsutil -- we had not realized
that the GPL-derived headers present in the libbtrfsutil subproject are
not distributed.
Bjorn
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-04 17:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-03 0:11 btrfs-progs 6.1 broke the build for multiple applications Neal Gompa
2023-01-03 11:39 ` David Sterba
2023-01-03 12:02 ` Qu Wenruo
2023-01-03 12:06 ` David Sterba
2023-01-03 18:00 ` Bjorn Neergaard
2023-01-04 17:23 ` Bjorn Neergaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).