btrfs-progs: update to 5.11

[folliehiyuki]

General

• This is a new package and it conforms to the quality requirements

Have the results of the proposed changes been tested?

• I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
• I generally don't use the affected packages but briefly tested this PR

Taken over and closes #28153
Why do we disable Python bindings for libbtrfsutil?
I gave up half way through cherry-picking tests to disable :) Most of them fail without mount command from util-linux.
Welcome other for battle test.

[folliehiyuki]

Have run on my machine without problems for 2 days.
Basic commands work as expected, so does snapshotting.
I still don't know what to do with the failed tests.
And should I re-enable the Python bindings?

[ericonr]

And should I re-enable the Python bindings?

It might have cross issues, but maybe not. It was done in 0b78c86, idk why.

I still don't know what to do with the failed tests.

Either try removing the failing ones, or we can look into adding more tools to chroot-util-linux, maybe...

[folliehiyuki]

Either try removing the failing ones

That will be tough. I have only tried with 2/3 of the tests but already had to disable 20 of them. Doing more will clutter the template file.

It might have cross issues, but maybe not. It was done in 0b78c86, idk why.

I will try cross building with Python binding enabled to see what goes wrong.

[folliehiyuki]

1 more question: btrfs can convert reiserfs disk into btrfs. Seeing that the file system is old, etc. it is currently disabled in build.
Is it worth enabling? It will bring reiserfsprogs into the dependencies, but maybe someone might need it

[ericonr]

Does it end up dynamically linked against the library from reiserfsprogs? If so, I'd be mostly against adding it, or at most make it a build option.

[folliehiyuki]

Yes it links in runtime. I will go with the build option

[folliehiyuki]

You're right. Cross build fails with Python.
Should I use build option for it? At least x86_64 people will know that it exists and they might want to use it.

[ericonr]

Should I use build option for it? At least x86_64 people will know that it exists and they might want to use it.

I'd rather wait for a request, unless you want to use them yourself?

[folliehiyuki]

I don't intend to use it so will disable Python bindings for now.
There is probably nothing I can do with the tests right now, so ready to be merged.

[ologantr]

@folliehiyuki I think that here it is the case to completely disable tests with make_check=no as the majority of them require mount(8) which is not shipped with chroot-util-linux.
Other than that, I have tested this and it works like a charm.
Maybe this PR should be renamed to btrfs-progs: update to 5.12.1

[folliehiyuki]

@ologantr Thanks for testing it. I also have run it locally since starting the PR with no issue.
I think @ericonr said something about adding functionalities to chroot-util-linux (that way we probably can pass the tests).

Maybe this PR should be renamed to btrfs-progs: update to 5.12.1

The commit message change is enough.

[ologantr]

@folliehiyuki I have just spoken with @ericonr and he said that he probably won't have time to add functionalities to chroot-util-linux for a long while. For the time being it's best to disable tests altogether.

[folliehiyuki]

Alright I disabled the tests and left a comment.