New package: uutils-0.0.24

[caughtquick]

Testing the changes

• I tested the changes in this PR: briefly

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, (x86_64 glibc)

This PR closes #47445

[caughtquick]

This built fine on my x86_64 glibc PC, not sure why it's not building now

[oreo639]

Those are test failures. Run them locally and see if they succeed.
Sometimes test failures are because of bugs in the application other times, test failures are because some functions aren't supported when run in the container. Some tests rely on other software running before the tests are started, for example, some packages have tests that rely on having a desktop running.

The way to resolve the test failure depends on why it is failing.

[caughtquick]

In regards to x86_64-glibc, the package built fine, should I be checking x86_64-musl and i686-glibc locally (crossbuilds?)?

[oreo639]

In regards to x86_64-glibc, the package built fine

You need to do ./xbps-src pkg -Q uutils or ./xbps-src check uutils in order to run the tests.

The test failures do appear to be related to the chroot type and running locally (defaults to uunshare) does give completely different failures to CI (uses ethereal).

It may require make_check=no.

should I be checking x86_64-musl and i686-glibc locally (crossbuilds?)?

Those are not cross builds, they are native builds. (-a i686 is cross and -A i686 is native)
You can't run tests when cross compiling.

[ahesford]

This package is misnamed. Normally it should be coreutils, which obviously conflicts, so maybe uutils-coreutils is a better choice.

I find the documentation very opaque, either because it's missing critical information or because I'm looking for critical information on a phone. The documentation I did find says that "uutils includes a multi-call binary from which the utils can be invoked", but does not say that uutils is comprised of a multi-call binary. This makes it sound like the multi-call binary is an optional component of a package that also provides individual commands.

Please confirm that the single executable installed by this package is the multi-call executable and can (should) be run similarly to busybox. In particular, I want to ensure that running /usr/bin/coreutils won't "helpfully" do something destructive like unpack a bunch of commands or make a bunch of symlinks that would interfere with the system coreutils package.

[caughtquick]

Running 'coreutils' does not do anything destructive, it just prompts you to run the command you want, for example 'coreutils ls' or 'coreutils bat'. It does not appear to conflict with the GNU coreutils installed by default on the system. In regards to the name change, I'll make that now.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.