bump(main/util-linux): 2.42.1

[TomJo2000]

Existing instances of hardcoded /bin/sh have been replaced by upstream with _PATH_BSHELL from #include <paths.h> which is /system/bin/sh on Android, we were previously replacing these with @TERMUX_PREFIX@/bin/sh.
Using /system/bin/sh should be fine here unless they're doing anything particularly funky with POSIX sh.

There are two remaining instances of /bin/sh being hardcoded (in setarch and pg), I have converted both of them to _PATH_BSHELL, and intend to report these to upstream as a bug/oversight.

copyfilerange is newly causing some issues.
We weren't previously building this, but it seems like the disabling logic for it isn't working quite right in the 2.42 configure script, so that'll probably be another bug report.
Thanks to @robertkirkman for helping me with figuring this out.

Robert also spotted and patched two other problems in shells.c and monitor_fanotify.c.
I have not regenerated Robert's patches with git diff so the patch headings vary slightly between patches, this is purely a cosmetic difference.

[fornwall]

Existing instances of hardcoded /bin/sh have been replaced by upstream with _PATH_BSHELL from #include <paths.h> which is /system/bin/sh on Android, we were previously replacing these with @TERMUX_PREFIX@/bin/sh.
Using /system/bin/sh should be fine here unless they're doing anything particularly funky with POSIX sh.

We actually do patch _PATH_BSHELL to be @TERMUX_PREFIX@/bin/sh: https://github.com/termux/termux-packages/blob/master/ndk-patches/29/paths.h.patch#L9

As you say it shouldn't be necessary for most use cases, but it's probably good for some edge cases and for consistency.

[robertkirkman]

Existing instances of hardcoded /bin/sh have been replaced by upstream with _PATH_BSHELL from #include <paths.h> which is /system/bin/sh on Android, we were previously replacing these with @TERMUX_PREFIX@/bin/sh.
Using /system/bin/sh should be fine here unless they're doing anything particularly funky with POSIX sh.

We actually do patch _PATH_BSHELL to be @TERMUX_PREFIX@/bin/sh: https://github.com/termux/termux-packages/blob/master/ndk-patches/29/paths.h.patch#L9

As you say it shouldn't be necessary for most use cases, but it's probably good for some edge cases and for consistency.

Thanks for showing that, I didn't know that before and I also assumed that _PATH_BSHELL would be /system/bin/sh because I was looking at a vanilla Android header.

This means that util-linux upstream adding a lot of new references to _PATH_BSHELL in its code in this update shouldn't actually have any effects on the instances of /bin/sh that were previously being patched to use Termux sh, so we can remove the patch hunks that conflict with those without replacing them with anything.

[TomJo2000]

Hi sorry for the delay on this I'm just getting back to this now.
We should be good on this PR, I've been running this on my device for the last month without issues.
I'll trigger a CI rerun and catch up the branch with master, if there's anything I've missed or forgotten here please let me know.

As mentioned above, standardizing to _PATH_BSHELL mostly just acts as a consistency thing and lets us hopefully cut down on future patch drift.

[robertkirkman]

I wrote the patch which replaces fanotify_init(), but unfortunately I can't entirely guarantee its stability. It could behave unexpectedly and I do not completely understand how to test it. If you are sure you already tested a command that runs fanotify_init(), that would probably be enough.

It's not that I used an LLM to make it, because I don't use LLMs. It is basically that I just guessed randomly at something that might work.

[TomJo2000]

The copyfilerange issue from 2.42(.0) seems to have been resolved by 2.42.1 so the changes to configure.patch are not needed anymore.

I'm still not clear on how we should go about verifying that the fanotify changes from Robert are working correctly on-device.

[robertkirkman]

I'm still not clear on how we should go about verifying that the fanotify changes from Robert are working correctly on-device.

I have already verified that they do not work correctly, and explained how I did so,

I have not finished making replacement changes yet

[robertkirkman]

The configure check seems to be for ac_cv_type_struct_fanotify_event_info_header,
so do I just set that to no?

you can try that sure, and then, i believe I can test the result afterward by building the test suite on-device. If the disablement was successful, then the test involving fanotify should fail to compile on-device, not only fail to run.

[robertkirkman]

The configure check seems to be for ac_cv_type_struct_fanotify_event_info_header,
so do I just set that to no?

you can try that sure, and then, i believe I can test the result afterward by building the test suite on-device. If the disablement was successful, then the test involving fanotify should fail to compile on-device, not only fail to run.

did not cause the test to fail to compile, but it sent the test into an ENOTSUP codepath that handles the error before it would reach bionic libc or the kernel and crash the program with Bad system call. That seems like the best outcome and your workaround should be used.

[TomJo2000]

One more thing that I just spotted last minute --disable-ctrlaltdel is not a flag known to the ./configure script.
It is known to the meson.build, but the autotools configure script doesn't appear to have flag to specifically disable building ctrlaltdelete.

This means ctrlaltdelete does end up being built and ends up in the package.
I think the easiest way to get rid of it would just be adding it, its shell completion and its manpage to the TERMUX_PKG_RM_AFTER_INSTALL list, similar what is already done for lsns.