rm: $directory: Directory not empty

When attempting to remove multiple directories containing many files and subdirectories (let's call them $bigdirectory1, $bigdirectory2 and $bigdirectory3), using the following command:
rm -frv $bigdirectory1 $bigdirectory2 $bigdirectory3

rm throws the following errors:
...
rm: $directory1: Directory not empty
rm: $directory2: Directory not empty
rm: $directory3: Directory not empty
rm: $directory4: Directory not empty
rm: $directory5: Directory not empty
rm: $directory6: Directory not empty
...

Where $directory1 to $directory6 are subdirectories in $bigdirectory1 to $bigdirectory3 that are left empty and require a rerun of the command:
rm -frv $bigdirectory1 $bigdirectory2 $bigdirectory3

to remove them completely.
(To recreate the issue just grab any Linux kernel tarball (e.g. version 5.5.5), extract the tarball and run rm -frv on the extracted directory and notice how it rm stops midway through the deletion and throws the Directory not empty error)
Could this be possibly related to the following lines in rm.c?
...
  // Intentionally fail non-recursive attempts to remove even an empty dir
  // (via wrong flags to unlinkat) because POSIX says to.
  if (dir && !(toys.optflags & (FLAG_r|FLAG_R))) goto skip;
...

I'm not reproducing this. What filesystem are you using?
$ git clone linux blah
Cloning into 'blah'...
done.
Checking out files: 100% (67321/67321), done.
$ toybox rm -rf blah
$ echo $?
0
$ ls -l blah
ls: cannot access 'blah': No such file or directory
I tried with specifically the 5.5.5 tarball and -frv and it still worked for me?
Rob

That's weird. I'm currently on XFS.

I just tried the following:

Downloaded the latest bison tarball from here.

Extracted it using bsdtar:

tar xvf bison-3.5.2.tar.xz -C .

and got a bison-3.5.2 directory.

I then tried to remove it using toybox's rm command:

rm -rf bison-3.5.2

and got the following:
rm: po: Directory not empty

so I ran tree on bison-3.5.2 and got:
bison-3.5.2/
`-- po
    `-- vi.po

1 directory, 1 file

and I had to rerun the rm command again to remove the directory completely.

I could not reproduce.
I extracted bison tarball with both bsdtar and gnu tar and ./toybox rm -rf on ubuntu with ext4 and both worked.
Then hooked up qemu archlinux installation with xfs partition and worked inside that too.
Perhaps still missing some information how to reproduce?

Hmmm, I'm building toybox against musl libc but I wasn't facing this issue before.
I just fetched Arch's version of toybox in the AUR and didn't encounter this issue.
So, here's what I'm using to build toybox:
I'm first modifying toybox's ls.c to prevent it from using the original long-iso time style, as it isn't compatible with some scripts like build-aux/mdate-sh which some packages (especially GNU ones use) (this step is necessary to provide shorter month names that some scripts require), using the following sed command:
  sed 's/%F/%b &/' \
    -i toys/posix/ls.c

I'm then copying my own toybox configuration file to toybox's source directory.
I'm then running (don't know if this step is necessary):
scripts/genconfig.sh

Followed by:
make

then installing toybox's utilities using:
  for i in $(./toybox); do
    ln -fsv toybox $some_path/$i
  done

I'm also using zlib-ng and libressl (instead of zlib and openssl to provide libz and libcrypto to toybox) (I wasn't facing this issue before even when using them).
The subdirectories left are consistent within the same directory. Could it be that my custom toybox's rm is attempting to remove the main directory before completely removing its subdirectories? Will it help to examine the subdirectories that are left and see if there's a pattern?

(comparing strace(1) output might point you in the right direction.)

Looks like that's the only way for now. I'll report my findings (if any).

I have a todo item to redo the rm/dirtree plumbing so it doesn't suffer from filehandle exhaustion when digging down more than ulimit -n directories (which defaults to 1024). It currently keeps an fd open to each parent directory as it traverses, and posix demands rm handle unlimited depth. (It's already doing better than PATH_MAX, but not yet unlimited.*)
But that would print error messages if not exit early. And other than that, I think it should work? (There's even a toyonly test in tests/rm.test for rm -rf being able to delete chmod 000 directories, which is toyonly because ubuntu's can't do it.)
Rob

because even if "for i in {1..1000}; do mkdir a; cd a; done" checked the depth each time, doing that twice in two directories and calling "mv ~/dir1/a ." can add an arbitrary depth below wherever we are now and can be repeated ad infinitum. So rm needs to cope.

This makes sense, I guess. Is there any way I can help you with testing that feature?
I'm currently testing different builds of my custom toybox configuration to see if that resolves the issue.

you could try setting ulimit -n very high, to confirm that this is the problem you're having.

I was thinking about that as ulimit -n shows 1024 , but then again why is Arch's version of toybox working with the 1024 ulimit.

No, I doubt that's the problem you're having. The limit isn't 1024 directories, it's a DEPTH of 1024 directories. a/a/a/a/a/a/a/a 1024 deep from the directory you started in. Nothing we're dealing with here should do that.
I just mentioned it as "my pending todo item for rm of a corner case I know it doesn't handle".

I went ahead and removed everything in the extracted bison directory except for the po subdirectory and tried an:
rm -fr bison-3.5.2

and still received:
rm: po: Directory not empty

So I went ahead and ran called strace beforehand (had to prepare the directory again):
strace rm -fr bison-3.5.2

and got the following:
execve("/toolchain/bin/rm", ["rm", "-fr", "bison-3.5.2"], 0x7ffccfc05810 /* 13 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7efdcd8fdd88) = 0
set_tid_address(0x7efdcd8fe35c)         = 43958
mprotect(0x7efdcd8fa000, 4096, PROT_READ) = 0
mprotect(0x437000, 4096, PROT_READ)     = 0
getuid()                                = 4036
geteuid()                               = 4036
umask(000)                              = 022
umask(022)                              = 000
unlink("bison-3.5.2")                   = -1 EISDIR (Is a directory)
lstat("bison-3.5.2", {st_mode=S_IFDIR|0755, st_size=77, ...}) = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
openat(AT_FDCWD, "bison-3.5.2", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=77, ...}) = 0
fcntl(3, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents64(3, /* 6 entries */, 2048)    = 184
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=77, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, "..", {st_mode=S_IFDIR|0755, st_size=48, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, ".tarball-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".tarball-version", 0)      = 0
newfstatat(3, "po", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
faccessat(3, "po", R_OK)                = 0
openat(3, "po", O_RDONLY|O_CLOEXEC)     = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(4, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
brk(NULL)                               = 0xf15000
brk(0xf16000)                           = 0xf16000
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
getdents64(4, /* 63 entries */, 2048)   = 2032
newfstatat(4, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "..", {st_mode=S_IFDIR|0755, st_size=53, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "bg.gmo", {st_mode=S_IFREG|0644, st_size=34223, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.gmo", 0)                = 0
newfstatat(4, "sr.po", {st_mode=S_IFREG|0644, st_size=47786, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.po", 0)                 = 0
newfstatat(4, "uk.po", {st_mode=S_IFREG|0644, st_size=54828, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.po", 0)                 = 0
newfstatat(4, "fr.po", {st_mode=S_IFREG|0644, st_size=45501, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.po", 0)                 = 0
newfstatat(4, "nl.po", {st_mode=S_IFREG|0644, st_size=44074, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.po", 0)                 = 0
newfstatat(4, "ca.gmo", {st_mode=S_IFREG|0644, st_size=13355, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.gmo", 0)                = 0
newfstatat(4, "zh_CN.po", {st_mode=S_IFREG|0644, st_size=39331, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.po", 0)              = 0
newfstatat(4, "sv.po", {st_mode=S_IFREG|0644, st_size=32870, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.po", 0)                 = 0
newfstatat(4, "tr.po", {st_mode=S_IFREG|0644, st_size=50449, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.po", 0)                 = 0
newfstatat(4, "zh_TW.po", {st_mode=S_IFREG|0644, st_size=36401, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.po", 0)              = 0
newfstatat(4, "pt_BR.po", {st_mode=S_IFREG|0644, st_size=45510, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.po", 0)              = 0
newfstatat(4, "eo.po", {st_mode=S_IFREG|0644, st_size=42820, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.po", 0)                 = 0
newfstatat(4, "ro.po", {st_mode=S_IFREG|0644, st_size=38114, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.po", 0)                 = 0
newfstatat(4, "nb.gmo", {st_mode=S_IFREG|0644, st_size=4435, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.gmo", 0)                = 0
newfstatat(4, "it.po", {st_mode=S_IFREG|0644, st_size=37830, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.po", 0)                 = 0
newfstatat(4, "es.po", {st_mode=S_IFREG|0644, st_size=53875, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.po", 0)                 = 0
newfstatat(4, "boldquot.sed", {st_mode=S_IFREG|0644, st_size=217, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "boldquot.sed", 0)          = 0
newfstatat(4, "uk.gmo", {st_mode=S_IFREG|0644, st_size=33669, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.gmo", 0)                = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1337, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)    = 0
newfstatat(4, "de.gmo", {st_mode=S_IFREG|0644, st_size=25072, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.gmo", 0)                = 0
newfstatat(4, "nb.po", {st_mode=S_IFREG|0644, st_size=36240, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.po", 0)                 = 0
newfstatat(4, "zh_TW.gmo", {st_mode=S_IFREG|0644, st_size=23021, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.gmo", 0)             = 0
newfstatat(4, "insert-header.sin", {st_mode=S_IFREG|0644, st_size=672, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "insert-header.sin", 0)     = 0
newfstatat(4, "it.gmo", {st_mode=S_IFREG|0644, st_size=4491, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.gmo", 0)                = 0
newfstatat(4, "pt.gmo", {st_mode=S_IFREG|0644, st_size=24891, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.gmo", 0)                = 0
newfstatat(4, "hr.gmo", {st_mode=S_IFREG|0644, st_size=12174, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.gmo", 0)                = 0
newfstatat(4, "ca.po", {st_mode=S_IFREG|0644, st_size=40551, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.po", 0)                 = 0
newfstatat(4, "et.gmo", {st_mode=S_IFREG|0644, st_size=24533, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.gmo", 0)                = 0
newfstatat(4, "id.gmo", {st_mode=S_IFREG|0644, st_size=7222, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.gmo", 0)                = 0
newfstatat(4, "ga.po", {st_mode=S_IFREG|0644, st_size=48464, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.po", 0)                 = 0
newfstatat(4, "de.po", {st_mode=S_IFREG|0644, st_size=47580, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.po", 0)                 = 0
newfstatat(4, "stamp-po", {st_mode=S_IFREG|0644, st_size=10, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "stamp-po", 0)              = 0
newfstatat(4, "zh_CN.gmo", {st_mode=S_IFREG|0644, st_size=12396, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.gmo", 0)             = 0
newfstatat(4, "ro.gmo", {st_mode=S_IFREG|0644, st_size=4623, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.gmo", 0)                = 0
newfstatat(4, "quot.sed", {st_mode=S_IFREG|0644, st_size=153, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "quot.sed", 0)              = 0
newfstatat(4, "Makevars", {st_mode=S_IFREG|0644, st_size=2673, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makevars", 0)              = 0
newfstatat(4, "es.gmo", {st_mode=S_IFREG|0644, st_size=13559, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.gmo", 0)                = 0
newfstatat(4, "da.po", {st_mode=S_IFREG|0644, st_size=40557, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.po", 0)                 = 0
newfstatat(4, "fi.gmo", {st_mode=S_IFREG|0644, st_size=13944, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.gmo", 0)                = 0
newfstatat(4, "da.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.gmo", 0)                = 0
newfstatat(4, "sr.gmo", {st_mode=S_IFREG|0644, st_size=16972, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.gmo", 0)                = 0
newfstatat(4, "ga.gmo", {st_mode=S_IFREG|0644, st_size=14588, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.gmo", 0)                = 0
newfstatat(4, "fr.gmo", {st_mode=S_IFREG|0644, st_size=26195, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.gmo", 0)                = 0
newfstatat(4, "ru.gmo", {st_mode=S_IFREG|0644, st_size=9101, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.gmo", 0)                = 0
newfstatat(4, "bg.po", {st_mode=S_IFREG|0644, st_size=42525, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.po", 0)                 = 0
newfstatat(4, "ja.po", {st_mode=S_IFREG|0644, st_size=35228, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.po", 0)                 = 0
newfstatat(4, "ja.gmo", {st_mode=S_IFREG|0644, st_size=27050, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.gmo", 0)                = 0
newfstatat(4, "pt_BR.gmo", {st_mode=S_IFREG|0644, st_size=25411, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.gmo", 0)             = 0
newfstatat(4, "id.po", {st_mode=S_IFREG|0644, st_size=38766, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.po", 0)                 = 0
newfstatat(4, "eo.gmo", {st_mode=S_IFREG|0644, st_size=24540, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.gmo", 0)                = 0
newfstatat(4, "pl.gmo", {st_mode=S_IFREG|0644, st_size=13928, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.gmo", 0)                = 0
newfstatat(4, "POTFILES.in", {st_mode=S_IFREG|0644, st_size=273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "POTFILES.in", 0)           = 0
newfstatat(4, "el.gmo", {st_mode=S_IFREG|0644, st_size=19754, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.gmo", 0)                = 0
newfstatat(4, "Makefile.in.in", {st_mode=S_IFREG|0644, st_size=17259, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makefile.in.in", 0)        = 0
newfstatat(4, "sv.gmo", {st_mode=S_IFREG|0644, st_size=24693, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.gmo", 0)                = 0
newfstatat(4, "bison.pot", {st_mode=S_IFREG|0644, st_size=21834, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bison.pot", 0)             = 0
newfstatat(4, "et.po", {st_mode=S_IFREG|0644, st_size=32585, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.po", 0)                 = 0
newfstatat(4, "nl.gmo", {st_mode=S_IFREG|0644, st_size=15710, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.gmo", 0)                = 0
newfstatat(4, "remove-potcdate.sin", {st_mode=S_IFREG|0644, st_size=432, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "remove-potcdate.sin", 0)   = 0
newfstatat(4, "el.po", {st_mode=S_IFREG|0644, st_size=42168, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.po", 0)                 = 0
newfstatat(4, "vi.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.gmo", 0)                = 0
getdents64(4, /* 11 entries */, 2048)   = 360
newfstatat(4, "pl.po", {st_mode=S_IFREG|0644, st_size=47620, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.po", 0)                 = 0
newfstatat(4, "LINGUAS", {st_mode=S_IFREG|0644, st_size=99, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "LINGUAS", 0)               = 0
newfstatat(4, "Rules-quot", {st_mode=S_IFREG|0644, st_size=2146, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Rules-quot", 0)            = 0
newfstatat(4, "pt.po", {st_mode=S_IFREG|0644, st_size=41751, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.po", 0)                 = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1203, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)        = 0
newfstatat(4, "tr.gmo", {st_mode=S_IFREG|0644, st_size=14273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.gmo", 0)                = 0
newfstatat(4, "ru.po", {st_mode=S_IFREG|0644, st_size=55696, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.po", 0)                 = 0
newfstatat(4, "ms.gmo", {st_mode=S_IFREG|0644, st_size=11884, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.gmo", 0)                = 0
newfstatat(4, "hr.po", {st_mode=S_IFREG|0644, st_size=49773, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.po", 0)                 = 0
newfstatat(4, "ms.po", {st_mode=S_IFREG|0644, st_size=37517, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.po", 0)                 = 0
newfstatat(4, "fi.po", {st_mode=S_IFREG|0644, st_size=44199, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.po", 0)                 = 0
getdents64(4, /* 0 entries */, 2048)    = 0
faccessat(3, "po", R_OK)                = 0
unlinkat(3, "po", AT_REMOVEDIR)         = -1 ENOTEMPTY (Directory not empty)
writev(2, [{iov_base="rm: ", iov_len=4}, {iov_base=NULL, iov_len=0}], 2rm: ) = 4
writev(2, [{iov_base="po", iov_len=2}, {iov_base=NULL, iov_len=0}], 2po) = 2
writev(2, [{iov_base=": Directory not empty", iov_len=21}, {iov_base=NULL, iov_len=0}], 2: Directory not empty) = 21
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
close(4)                                = 0
newfstatat(3, ".version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".version", 0)              = 0
newfstatat(3, ".prev-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".prev-version", 0)         = 0
getdents64(3, /* 0 entries */, 2048)    = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
unlinkat(AT_FDCWD, "bison-3.5.2", AT_REMOVEDIR) = -1 ENOTEMPTY (Directory not empty)
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

and compared it with Arch's AUR toybox rm:
execve("/usr/bin/toybox", ["/usr/bin/toybox", "rm", "-fr", "bison-3.5.2"], 0x7ffdcf089cc8 /* 13 vars */) = 0
brk(NULL)                               = 0x55d7d7aff000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff4ab57350) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=361283, ...}) = 0
mmap(NULL, 361283, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3b7e17f000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\22\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=43272, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3b7e17d000
mmap(NULL, 233816, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3b7e143000
mprotect(0x7f3b7e144000, 36864, PROT_NONE) = 0
mmap(0x7f3b7e144000, 24576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f3b7e144000
mmap(0x7f3b7e14a000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f3b7e14a000
mmap(0x7f3b7e14d000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x7f3b7e14d000
mmap(0x7f3b7e14f000, 184664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3b7e14f000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`q\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0<EMAIL_ADDRESS>784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\22\344\22\321\223\216\303\377yu\37\16\205\363\33\305"..., 68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2145592, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0<EMAIL_ADDRESS>784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\22\344\22\321\223\216\303\377yu\37\16\205\363\33\305"..., 68, 880) = 68
mmap(NULL, 1856312, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3b7df7d000
mmap(0x7f3b7dfa2000, 1359872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f3b7dfa2000
mmap(0x7f3b7e0ee000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x171000) = 0x7f3b7e0ee000
mmap(0x7f3b7e139000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7f3b7e139000
mmap(0x7f3b7e13f000, 13112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3b7e13f000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3b7df7a000
arch_prctl(ARCH_SET_FS, 0x7f3b7df7a740) = 0
mprotect(0x7f3b7e139000, 12288, PROT_READ) = 0
mprotect(0x7f3b7e14d000, 4096, PROT_READ) = 0
mprotect(0x55d7d5c3a000, 8192, PROT_READ) = 0
mprotect(0x7f3b7e203000, 4096, PROT_READ) = 0
munmap(0x7f3b7e17f000, 361283)          = 0
getuid()                                = 4036
geteuid()                               = 4036
brk(NULL)                               = 0x55d7d7aff000
brk(0x55d7d7b20000)                     = 0x55d7d7b20000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3041392, ...}) = 0
mmap(NULL, 3041392, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3b7dc93000
close(3)                                = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2998, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2998
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
umask(000)                              = 022
umask(022)                              = 000
getuid()                                = 4036
geteuid()                               = 4036
umask(000)                              = 022
umask(022)                              = 000
unlink("bison-3.5.2")                   = -1 EISDIR (Is a directory)
newfstatat(AT_FDCWD, "bison-3.5.2", {st_mode=S_IFDIR|0755, st_size=77, ...}, AT_SYMLINK_NOFOLLOW) = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
openat(AT_FDCWD, "bison-3.5.2", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=77, ...}) = 0
fcntl(3, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents64(3, /* 6 entries */, 32768)   = 184
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=77, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, "..", {st_mode=S_IFDIR|0755, st_size=48, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, ".tarball-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".tarball-version", 0)      = 0
newfstatat(3, "po", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
faccessat(3, "po", R_OK)                = 0
openat(3, "po", O_RDONLY|O_CLOEXEC)     = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(4, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
getdents64(4, /* 75 entries */, 32768)  = 2424
newfstatat(4, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "..", {st_mode=S_IFDIR|0755, st_size=53, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "bg.gmo", {st_mode=S_IFREG|0644, st_size=34223, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.gmo", 0)                = 0
newfstatat(4, "sr.po", {st_mode=S_IFREG|0644, st_size=47786, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.po", 0)                 = 0
newfstatat(4, "uk.po", {st_mode=S_IFREG|0644, st_size=54828, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.po", 0)                 = 0
newfstatat(4, "fr.po", {st_mode=S_IFREG|0644, st_size=45501, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.po", 0)                 = 0
newfstatat(4, "nl.po", {st_mode=S_IFREG|0644, st_size=44074, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.po", 0)                 = 0
newfstatat(4, "ca.gmo", {st_mode=S_IFREG|0644, st_size=13355, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.gmo", 0)                = 0
newfstatat(4, "zh_CN.po", {st_mode=S_IFREG|0644, st_size=39331, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.po", 0)              = 0
newfstatat(4, "sv.po", {st_mode=S_IFREG|0644, st_size=32870, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.po", 0)                 = 0
newfstatat(4, "tr.po", {st_mode=S_IFREG|0644, st_size=50449, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.po", 0)                 = 0
newfstatat(4, "zh_TW.po", {st_mode=S_IFREG|0644, st_size=36401, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.po", 0)              = 0
newfstatat(4, "pt_BR.po", {st_mode=S_IFREG|0644, st_size=45510, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.po", 0)              = 0
newfstatat(4, "eo.po", {st_mode=S_IFREG|0644, st_size=42820, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.po", 0)                 = 0
newfstatat(4, "ro.po", {st_mode=S_IFREG|0644, st_size=38114, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.po", 0)                 = 0
newfstatat(4, "nb.gmo", {st_mode=S_IFREG|0644, st_size=4435, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.gmo", 0)                = 0
newfstatat(4, "it.po", {st_mode=S_IFREG|0644, st_size=37830, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.po", 0)                 = 0
newfstatat(4, "es.po", {st_mode=S_IFREG|0644, st_size=53875, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.po", 0)                 = 0
newfstatat(4, "boldquot.sed", {st_mode=S_IFREG|0644, st_size=217, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "boldquot.sed", 0)          = 0
newfstatat(4, "uk.gmo", {st_mode=S_IFREG|0644, st_size=33669, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.gmo", 0)                = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1337, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)    = 0
newfstatat(4, "de.gmo", {st_mode=S_IFREG|0644, st_size=25072, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.gmo", 0)                = 0
newfstatat(4, "nb.po", {st_mode=S_IFREG|0644, st_size=36240, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.po", 0)                 = 0
newfstatat(4, "zh_TW.gmo", {st_mode=S_IFREG|0644, st_size=23021, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.gmo", 0)             = 0
newfstatat(4, "insert-header.sin", {st_mode=S_IFREG|0644, st_size=672, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "insert-header.sin", 0)     = 0
newfstatat(4, "it.gmo", {st_mode=S_IFREG|0644, st_size=4491, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.gmo", 0)                = 0
newfstatat(4, "pt.gmo", {st_mode=S_IFREG|0644, st_size=24891, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.gmo", 0)                = 0
newfstatat(4, "hr.gmo", {st_mode=S_IFREG|0644, st_size=12174, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.gmo", 0)                = 0
newfstatat(4, "ca.po", {st_mode=S_IFREG|0644, st_size=40551, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.po", 0)                 = 0
newfstatat(4, "et.gmo", {st_mode=S_IFREG|0644, st_size=24533, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.gmo", 0)                = 0
newfstatat(4, "id.gmo", {st_mode=S_IFREG|0644, st_size=7222, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.gmo", 0)                = 0
newfstatat(4, "ga.po", {st_mode=S_IFREG|0644, st_size=48464, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.po", 0)                 = 0
newfstatat(4, "de.po", {st_mode=S_IFREG|0644, st_size=47580, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.po", 0)                 = 0
newfstatat(4, "stamp-po", {st_mode=S_IFREG|0644, st_size=10, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "stamp-po", 0)              = 0
newfstatat(4, "zh_CN.gmo", {st_mode=S_IFREG|0644, st_size=12396, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.gmo", 0)             = 0
newfstatat(4, "ro.gmo", {st_mode=S_IFREG|0644, st_size=4623, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.gmo", 0)                = 0
newfstatat(4, "quot.sed", {st_mode=S_IFREG|0644, st_size=153, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "quot.sed", 0)              = 0
newfstatat(4, "Makevars", {st_mode=S_IFREG|0644, st_size=2673, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makevars", 0)              = 0
newfstatat(4, "es.gmo", {st_mode=S_IFREG|0644, st_size=13559, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.gmo", 0)                = 0
newfstatat(4, "da.po", {st_mode=S_IFREG|0644, st_size=40557, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.po", 0)                 = 0
newfstatat(4, "fi.gmo", {st_mode=S_IFREG|0644, st_size=13944, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.gmo", 0)                = 0
newfstatat(4, "da.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.gmo", 0)                = 0
newfstatat(4, "sr.gmo", {st_mode=S_IFREG|0644, st_size=16972, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.gmo", 0)                = 0
newfstatat(4, "ga.gmo", {st_mode=S_IFREG|0644, st_size=14588, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.gmo", 0)                = 0
newfstatat(4, "fr.gmo", {st_mode=S_IFREG|0644, st_size=26195, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.gmo", 0)                = 0
newfstatat(4, "ru.gmo", {st_mode=S_IFREG|0644, st_size=9101, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.gmo", 0)                = 0
newfstatat(4, "bg.po", {st_mode=S_IFREG|0644, st_size=42525, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.po", 0)                 = 0
newfstatat(4, "ja.po", {st_mode=S_IFREG|0644, st_size=35228, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.po", 0)                 = 0
newfstatat(4, "ja.gmo", {st_mode=S_IFREG|0644, st_size=27050, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.gmo", 0)                = 0
newfstatat(4, "pt_BR.gmo", {st_mode=S_IFREG|0644, st_size=25411, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.gmo", 0)             = 0
newfstatat(4, "id.po", {st_mode=S_IFREG|0644, st_size=38766, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.po", 0)                 = 0
newfstatat(4, "eo.gmo", {st_mode=S_IFREG|0644, st_size=24540, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.gmo", 0)                = 0
newfstatat(4, "pl.gmo", {st_mode=S_IFREG|0644, st_size=13928, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.gmo", 0)                = 0
newfstatat(4, "POTFILES.in", {st_mode=S_IFREG|0644, st_size=273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "POTFILES.in", 0)           = 0
newfstatat(4, "el.gmo", {st_mode=S_IFREG|0644, st_size=19754, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.gmo", 0)                = 0
newfstatat(4, "Makefile.in.in", {st_mode=S_IFREG|0644, st_size=17259, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makefile.in.in", 0)        = 0
newfstatat(4, "sv.gmo", {st_mode=S_IFREG|0644, st_size=24693, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.gmo", 0)                = 0
newfstatat(4, "bison.pot", {st_mode=S_IFREG|0644, st_size=21834, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bison.pot", 0)             = 0
newfstatat(4, "et.po", {st_mode=S_IFREG|0644, st_size=32585, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.po", 0)                 = 0
newfstatat(4, "nl.gmo", {st_mode=S_IFREG|0644, st_size=15710, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.gmo", 0)                = 0
newfstatat(4, "remove-potcdate.sin", {st_mode=S_IFREG|0644, st_size=432, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "remove-potcdate.sin", 0)   = 0
newfstatat(4, "el.po", {st_mode=S_IFREG|0644, st_size=42168, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.po", 0)                 = 0
newfstatat(4, "vi.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.gmo", 0)                = 0
newfstatat(4, "vi.po", {st_mode=S_IFREG|0644, st_size=45531, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.po", 0)                 = 0
newfstatat(4, "pl.po", {st_mode=S_IFREG|0644, st_size=47620, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.po", 0)                 = 0
newfstatat(4, "LINGUAS", {st_mode=S_IFREG|0644, st_size=99, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "LINGUAS", 0)               = 0
newfstatat(4, "Rules-quot", {st_mode=S_IFREG|0644, st_size=2146, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Rules-quot", 0)            = 0
newfstatat(4, "pt.po", {st_mode=S_IFREG|0644, st_size=41751, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.po", 0)                 = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1203, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)        = 0
newfstatat(4, "tr.gmo", {st_mode=S_IFREG|0644, st_size=14273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.gmo", 0)                = 0
newfstatat(4, "ru.po", {st_mode=S_IFREG|0644, st_size=55696, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.po", 0)                 = 0
newfstatat(4, "ms.gmo", {st_mode=S_IFREG|0644, st_size=11884, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.gmo", 0)                = 0
newfstatat(4, "hr.po", {st_mode=S_IFREG|0644, st_size=49773, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.po", 0)                 = 0
newfstatat(4, "ms.po", {st_mode=S_IFREG|0644, st_size=37517, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.po", 0)                 = 0
newfstatat(4, "fi.po", {st_mode=S_IFREG|0644, st_size=44199, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.po", 0)                 = 0
getdents64(4, /* 0 entries */, 32768)   = 0
faccessat(3, "po", R_OK)                = 0
unlinkat(3, "po", AT_REMOVEDIR)         = 0
close(4)                                = 0
newfstatat(3, ".version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".version", 0)              = 0
newfstatat(3, ".prev-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".prev-version", 0)         = 0
getdents64(3, /* 0 entries */, 32768)   = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
unlinkat(AT_FDCWD, "bison-3.5.2", AT_REMOVEDIR) = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

What could possibly be the problem?

offhand, it looks like they're built with two different c libraries? (even ignoring that your binary appears to be static rather than dynamic.) can you reproduce this if you rebuild with the same libc.so that the Arch binary is using?

The first binary is mine, it's built against musl libc, and the second one is Arch's and it's build against Glibc.
My binary should be dynamic, why is it showing as static?

if you look at the start of the strace, there's no sign of it loading any shared libraries. file(1) will confirm/deny. i'd assume that it's glibc vs musl that's more important than static vs dynamic though.

Toybox read 63 dentries and successfully deleted them, then read 11 more dentries and successfully deleted them (for a total of 74), then was told the directory wasn't empty.
getdents64(4, /* 63 entries /, 2048)   = 2032
...
newfstatat(4, "vi.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.gmo", 0)                = 0
getdents64(4, / 11 entries */, 2048)   = 360
newfstatat(4, "pl.po", {st_mode=S_IFREG|0644, st_size=47620, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.po", 0)                 = 0
The other one read the directory with a bigger buffer and got all dentries at once, and got an extra entry (vi.po) that would be in the gap between the first and second readlink above:
getdents64(3, /* 6 entries */, 32768)   = 184
...
unlinkat(4, "vi.gmo", 0)                = 0
newfstatat(4, "vi.po", {st_mode=S_IFREG|0644, st_size=45531, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.po", 0)                 = 0
newfstatat(4, "pl.po", {st_mode=S_IFREG|0644, st_size=47620, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.po", 0)                 = 0
The thing is, toybox isn't calling getdents64() directly, it's calling the libc functions fdopendir(fd) and readdir(), so the difference in buffer size is a libc implementation detail, not something toybox asked for.
It looks like there's an off-by-one error in your kernel (possibly the xfs driver) resulting in two getdents64() into a 2048 byte buffer skipping an entry in between. According to strace(), we made the requests consecutively, didn't seek in between, and got results with a missing entry between the two calls.
Given that struct linux_dirent is variable length (ends with a null terminated string, these days with an extra field after that because hacktensions) there's no possible "supplied buffer size expected to be an even number of records"  issue; this seems like a straightforward bug.
(The first getdents64(2048) returned 2032, so had 16 bytes left at the end. vi.po with a null terminator is 6 bytes, two longs are 8 bytes on a 32 bit system and 16 bytes on a 64 bit system, plus short is 2 bytes, so on 32 bits that exactly fits... except there's an extra char d_type at the end since linux 2.6.4 (see man getdents64) so even on 32 bits that's not gonna fit in the remaining space.)

Ahem, that first line of the second quoted hunk should be:
getdents64(4, /* 75 entries */, 32768)  = 2424
75 entries instead of 74 entries. (I cut and pasted the one for fd 3, which is reading the enclosing directory.)

Hmm it could be related to musl, because if it were related to the filesystem XFS then how is the version from the AUR working.

One is reading directory entries into a 2k buffer, the other is reading into a 32k buffer. If it's dropping an entry between buffers each time, you need a directory with 16x as many entries in it to see the bug with the other version.
63+11 != 75 is not toybox's problem. And it's not the libc either. The libc is just triggering it. What the kernel returned seems to be wrong.

I see.
Should I close the issue as it's not toybox's problem, or should I leave it open until I resolve it somehow?

Up to you. I'm interested in hearing where the bug actually was, but it's looking like it's an xfs issue.
You could try mounting a tmpfs instance and extracting/removing the same files out of that to see if the behavior changes.

I can confirm that this problem disappeared when I mounted a tmpfs instance, copied the bison-3.5.2 source files directory there and attempted to delete it.
Here's strace's of the working command:
execve("/toolchain/bin/rm", ["rm", "-fr", "bison-3.5.2"], 0x7fff5e26e790 /* 14 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7f523eebad88) = 0
set_tid_address(0x7f523eebb35c)         = 1004224
mprotect(0x7f523eeb7000, 4096, PROT_READ) = 0
mprotect(0x424000, 4096, PROT_READ)     = 0
getuid()                                = 4036
geteuid()                               = 4036
umask(000)                              = 022
umask(022)                              = 000
unlink("bison-3.5.2")                   = -1 EISDIR (Is a directory)
lstat("bison-3.5.2", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
openat(AT_FDCWD, "bison-3.5.2", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
fcntl(3, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
getdents64(3, /* 6 entries */, 2048)    = 184
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=120, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, "..", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=60, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(3, ".prev-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".prev-version", 0)         = 0
newfstatat(3, ".version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".version", 0)              = 0
newfstatat(3, "po", {st_mode=S_IFDIR|0755, st_size=1500, ...}, AT_SYMLINK_NOFOLLOW) = 0
faccessat(3, "po", R_OK)                = 0
openat(3, "po", O_RDONLY|O_CLOEXEC)     = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=1500, ...}) = 0
fcntl(4, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
brk(NULL)                               = 0x1565000
brk(0x1566000)                          = 0x1566000
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
getdents64(4, /* 63 entries */, 2048)   = 2040
newfstatat(4, ".", {st_mode=S_IFDIR|0755, st_size=1500, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "..", {st_mode=S_IFDIR|0755, st_size=80, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(4, "fi.po", {st_mode=S_IFREG|0644, st_size=44199, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.po", 0)                 = 0
newfstatat(4, "ms.po", {st_mode=S_IFREG|0644, st_size=37517, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.po", 0)                 = 0
newfstatat(4, "hr.po", {st_mode=S_IFREG|0644, st_size=49773, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.po", 0)                 = 0
newfstatat(4, "ms.gmo", {st_mode=S_IFREG|0644, st_size=11884, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ms.gmo", 0)                = 0
newfstatat(4, "ru.po", {st_mode=S_IFREG|0644, st_size=55696, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.po", 0)                 = 0
newfstatat(4, "tr.gmo", {st_mode=S_IFREG|0644, st_size=14273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.gmo", 0)                = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1203, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)        = 0
newfstatat(4, "pt.po", {st_mode=S_IFREG|0644, st_size=41751, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.po", 0)                 = 0
newfstatat(4, "Rules-quot", {st_mode=S_IFREG|0644, st_size=2146, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Rules-quot", 0)            = 0
newfstatat(4, "LINGUAS", {st_mode=S_IFREG|0644, st_size=99, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "LINGUAS", 0)               = 0
newfstatat(4, "pl.po", {st_mode=S_IFREG|0644, st_size=47620, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.po", 0)                 = 0
newfstatat(4, "vi.po", {st_mode=S_IFREG|0644, st_size=45531, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.po", 0)                 = 0
newfstatat(4, "vi.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "vi.gmo", 0)                = 0
newfstatat(4, "el.po", {st_mode=S_IFREG|0644, st_size=42168, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.po", 0)                 = 0
newfstatat(4, "remove-potcdate.sin", {st_mode=S_IFREG|0644, st_size=432, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "remove-potcdate.sin", 0)   = 0
newfstatat(4, "nl.gmo", {st_mode=S_IFREG|0644, st_size=15710, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.gmo", 0)                = 0
newfstatat(4, "et.po", {st_mode=S_IFREG|0644, st_size=32585, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.po", 0)                 = 0
newfstatat(4, "bison.pot", {st_mode=S_IFREG|0644, st_size=21834, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bison.pot", 0)             = 0
newfstatat(4, "sv.gmo", {st_mode=S_IFREG|0644, st_size=24693, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.gmo", 0)                = 0
newfstatat(4, "Makefile.in.in", {st_mode=S_IFREG|0644, st_size=17259, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makefile.in.in", 0)        = 0
newfstatat(4, "el.gmo", {st_mode=S_IFREG|0644, st_size=19754, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "el.gmo", 0)                = 0
newfstatat(4, "POTFILES.in", {st_mode=S_IFREG|0644, st_size=273, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "POTFILES.in", 0)           = 0
newfstatat(4, "pl.gmo", {st_mode=S_IFREG|0644, st_size=13928, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pl.gmo", 0)                = 0
newfstatat(4, "eo.gmo", {st_mode=S_IFREG|0644, st_size=24540, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.gmo", 0)                = 0
newfstatat(4, "id.po", {st_mode=S_IFREG|0644, st_size=38766, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.po", 0)                 = 0
newfstatat(4, "pt_BR.gmo", {st_mode=S_IFREG|0644, st_size=25411, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.gmo", 0)             = 0
newfstatat(4, "ja.gmo", {st_mode=S_IFREG|0644, st_size=27050, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.gmo", 0)                = 0
newfstatat(4, "ja.po", {st_mode=S_IFREG|0644, st_size=35228, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ja.po", 0)                 = 0
newfstatat(4, "bg.po", {st_mode=S_IFREG|0644, st_size=42525, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.po", 0)                 = 0
newfstatat(4, "ru.gmo", {st_mode=S_IFREG|0644, st_size=9101, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ru.gmo", 0)                = 0
newfstatat(4, "fr.gmo", {st_mode=S_IFREG|0644, st_size=26195, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.gmo", 0)                = 0
newfstatat(4, "ga.gmo", {st_mode=S_IFREG|0644, st_size=14588, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.gmo", 0)                = 0
newfstatat(4, "sr.gmo", {st_mode=S_IFREG|0644, st_size=16972, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.gmo", 0)                = 0
newfstatat(4, "da.gmo", {st_mode=S_IFREG|0644, st_size=15235, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.gmo", 0)                = 0
newfstatat(4, "fi.gmo", {st_mode=S_IFREG|0644, st_size=13944, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fi.gmo", 0)                = 0
newfstatat(4, "da.po", {st_mode=S_IFREG|0644, st_size=40557, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "da.po", 0)                 = 0
newfstatat(4, "es.gmo", {st_mode=S_IFREG|0644, st_size=13559, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.gmo", 0)                = 0
newfstatat(4, "Makevars", {st_mode=S_IFREG|0644, st_size=2673, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "Makevars", 0)              = 0
newfstatat(4, "quot.sed", {st_mode=S_IFREG|0644, st_size=153, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "quot.sed", 0)              = 0
newfstatat(4, "ro.gmo", {st_mode=S_IFREG|0644, st_size=4623, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.gmo", 0)                = 0
newfstatat(4, "zh_CN.gmo", {st_mode=S_IFREG|0644, st_size=12396, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.gmo", 0)             = 0
newfstatat(4, "stamp-po", {st_mode=S_IFREG|0644, st_size=10, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "stamp-po", 0)              = 0
newfstatat(4, "de.po", {st_mode=S_IFREG|0644, st_size=47580, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.po", 0)                 = 0
newfstatat(4, "ga.po", {st_mode=S_IFREG|0644, st_size=48464, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ga.po", 0)                 = 0
newfstatat(4, "id.gmo", {st_mode=S_IFREG|0644, st_size=7222, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "id.gmo", 0)                = 0
newfstatat(4, "et.gmo", {st_mode=S_IFREG|0644, st_size=24533, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "et.gmo", 0)                = 0
newfstatat(4, "ca.po", {st_mode=S_IFREG|0644, st_size=40551, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.po", 0)                 = 0
newfstatat(4, "hr.gmo", {st_mode=S_IFREG|0644, st_size=12174, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "hr.gmo", 0)                = 0
newfstatat(4, "pt.gmo", {st_mode=S_IFREG|0644, st_size=24891, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt.gmo", 0)                = 0
newfstatat(4, "it.gmo", {st_mode=S_IFREG|0644, st_size=4491, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.gmo", 0)                = 0
newfstatat(4, "insert-header.sin", {st_mode=S_IFREG|0644, st_size=672, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "insert-header.sin", 0)     = 0
newfstatat(4, "zh_TW.gmo", {st_mode=S_IFREG|0644, st_size=23021, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.gmo", 0)             = 0
newfstatat(4, "nb.po", {st_mode=S_IFREG|0644, st_size=36240, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.po", 0)                 = 0
newfstatat(4, "de.gmo", {st_mode=S_IFREG|0644, st_size=25072, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "de.gmo", 0)                = 0
newfstatat(4<EMAIL_ADDRESS>{st_mode=S_IFREG|0644, st_size=1337, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4<EMAIL_ADDRESS>0)    = 0
newfstatat(4, "uk.gmo", {st_mode=S_IFREG|0644, st_size=33669, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.gmo", 0)                = 0
newfstatat(4, "boldquot.sed", {st_mode=S_IFREG|0644, st_size=217, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "boldquot.sed", 0)          = 0
newfstatat(4, "es.po", {st_mode=S_IFREG|0644, st_size=53875, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "es.po", 0)                 = 0
newfstatat(4, "it.po", {st_mode=S_IFREG|0644, st_size=37830, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "it.po", 0)                 = 0
newfstatat(4, "nb.gmo", {st_mode=S_IFREG|0644, st_size=4435, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nb.gmo", 0)                = 0
newfstatat(4, "ro.po", {st_mode=S_IFREG|0644, st_size=38114, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ro.po", 0)                 = 0
getdents64(4, /* 12 entries */, 2048)   = 384
newfstatat(4, "eo.po", {st_mode=S_IFREG|0644, st_size=42820, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "eo.po", 0)                 = 0
newfstatat(4, "pt_BR.po", {st_mode=S_IFREG|0644, st_size=45510, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "pt_BR.po", 0)              = 0
newfstatat(4, "zh_TW.po", {st_mode=S_IFREG|0644, st_size=36401, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_TW.po", 0)              = 0
newfstatat(4, "tr.po", {st_mode=S_IFREG|0644, st_size=50449, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "tr.po", 0)                 = 0
newfstatat(4, "sv.po", {st_mode=S_IFREG|0644, st_size=32870, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sv.po", 0)                 = 0
newfstatat(4, "zh_CN.po", {st_mode=S_IFREG|0644, st_size=39331, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "zh_CN.po", 0)              = 0
newfstatat(4, "ca.gmo", {st_mode=S_IFREG|0644, st_size=13355, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "ca.gmo", 0)                = 0
newfstatat(4, "nl.po", {st_mode=S_IFREG|0644, st_size=44074, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "nl.po", 0)                 = 0
newfstatat(4, "fr.po", {st_mode=S_IFREG|0644, st_size=45501, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "fr.po", 0)                 = 0
newfstatat(4, "uk.po", {st_mode=S_IFREG|0644, st_size=54828, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "uk.po", 0)                 = 0
newfstatat(4, "sr.po", {st_mode=S_IFREG|0644, st_size=47786, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "sr.po", 0)                 = 0
newfstatat(4, "bg.gmo", {st_mode=S_IFREG|0644, st_size=34223, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(4, "bg.gmo", 0)                = 0
getdents64(4, /* 0 entries */, 2048)    = 0
faccessat(3, "po", R_OK)                = 0
unlinkat(3, "po", AT_REMOVEDIR)         = 0
close(4)                                = 0
newfstatat(3, ".tarball-version", {st_mode=S_IFREG|0644, st_size=6, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(3, ".tarball-version", 0)      = 0
getdents64(3, /* 0 entries */, 2048)    = 0
faccessat(AT_FDCWD, "bison-3.5.2", R_OK) = 0
unlinkat(AT_FDCWD, "bison-3.5.2", AT_REMOVEDIR) = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

63+12=75. Everything's sorted differently so vi.po is part of the first 63, but it's there.
I dunno if this fixed the issue or just hid it. The other thing to try is make a directory big enough the other rm fails. (if 2k gives you 63 entries, 32k would give you about 1000 entries, so a directory with 2000 entries in it would presumably fail for the other thing? You can mkdir sub;for i in {1..8000}; do touch sub/$i; done and then try to rm -rf sub?
Also, it seems like ls would have a similar problem? It's directory read dropping an entry that's the problem. Less obvious to spot since it's not an error, but it would be wrong output...
Rob

I ran the command you gave me:
mkdir sub;for i in {1..8000}; do touch sub/$i; done

and I didn't encounter the error on both XFS and tmpfs.
Here's the strace output for running rm -fr sub on XFS:
https://gist.github.com/firasuke/8902e10a06f4881902d4932573a05d12
and here's the strace output for running rm -fr sub on tmpfs:
https://gist.github.com/firasuke/1f267935e5976ff03ab9ef733fd7977b

Hmmm, smells like a corner case in the xfs hashing algorithm that creating files in-order with mostly the same name length isn't triggering. Hmmm.
At this point, my own debugging efforts would involve trying to reproduce this under qemu with a kernel I built myself (it's why I have scripts/mkroot.sh and similar), and then if I did get it to reproduce I'd stick printk() calls into the kernel to track down what was going on and why.
But you might also want to see if it happens on ext2, ext4, and vfat, and if it only happens on xfs, hand it off the bug report (with reproduction sequence) to the xfs developers. (If it reproduces on more than one filesystem it's probably a VFS issue and then you'd check what patches your distro is applying because vfs issues seldom go undetected for long, EVERYBODY traverses those codepaths...)
I also did "git log --no-merges fs/xfs" in the linux source and there are some bugfixes like "xfs: fix memory corruption during remote attr value buffer invalidation", but this is a pretty active codebase with a lot of churn, and not one I'm familiar with. Bit of a time commitment to actually try to understand...

Ok, so I've prepared a release of the chroot environment tools I'm using for glaucus, and it contains the toybox binary I used above.
To reproduce the issue on a XFS system, grab a copy of the chroot release:
wget https://github.com/glaucuslinux/chroot/releases/download/01032020/chroot-01032020.tar.xz

Then extract the downloaded archive into an empty directory
tar xvf chroot-01032020.tar.xz -C $empty_dir

Now extract the version of bison you've downloaded above (3.5.2) to a directory of your choice:
tar xvf bison-3.5.2.tar.xz -C $another_dir

Now use the rm commanded provided by the chroot archive above (no need to chroot):
LD_LIBRARY_PATH=$empty_dir/toolchain/lib ./$empty_lib/toolchain/bin/rm -frv $/another_dir/bison-3.5.2

And see if that reproduces the error on XFS.

(i think you want to send that to the XFS maintainers. it's not a toybox bug.)

I understand, but why is Arch's version of toybox is working fine with XFS?

because it's using a different libc that uses a different buffer size for reading directory entries.

I see. I'll keep this issue open until I resolve it somehow.
Thanks for your time.

Ok, after some experiments, it seems that this issue isn't related to toybox and that XFS is the culprit.
From what I've seen, it looks like this is a common problem for XFS partitions, and running xfs_repair on the XFS partition (and ensuring that the hardware isn't faulty) solves this problem.

After further testing, it seems that the issue still persists on some XFS partitions even after running xfs_repair.
This is only happening when using musl libc, and doesn't happen with glibc.
So it has to be a problem with either musl or the kernel itself (version 5.5 specifically).
The musl variant of Alpine Linux had this issue as well with busybox rm:
https://github.com/docker-library/busybox/issues/77
I'm reopening this issue until a correct solution is found, thanks for your time.

Because musl uses a smaller buffer size, so it hits the off-by-one missed entry in the xfs directory read implementation more often. It is still an XFS bug. Contact the XFS developers.

Ok, looks like a bug report is already open from both Fedora and Alpine Linux, starting from Linux version 5.5.
I downgraded to the latest LTS version 5.4.30 and this issue disappeared.
Closing this issue now, thanks for all your time and effort!


How to hide menu button in default layout?

Given the following Vue template:
<template>
    <media-player
        :src="src"
        playsinline
    >
        <media-provider />

        <media-video-layout />
    </media-player>
</template>

... how to entirely remove the following button?

I feel like there isn't much room for flexibility/composability at the moment, unless I missed relevant sections in the docs which describe how to achieve this. Thank you!

Hey Damian! This is not really an issue, please open questions in discussions or Discord :) You can hide it using CSS or you can opt to create your own layout (see our examples). There's tons of flexibility in our library, but unfortunately we don't have slots for our Web Component library yet like we do for React (add/replace existing content in our layout).
.vds-settings-menu {
  display: none;
}

Also note our menus don't render anything when not open so there's no performance issue for leaving it.


Duplicate "add" function in the docs.

Just a trivial change. The second, duplicated add should actually be a sub.

Thanks!


Skip sqlite3 production warning in Rails 7.2

Sqlite3 Production Warning is being removed: https://github.com/rails/rails/commit/6b446bee63c401364d193920f3426af0bfe75650

https://github.com/oldmoe/litestack/pull/106

Already merged a similar PR


"Quick" Logging Improvements

Ahead of a full logging rework, there are a few quick things that we can improve that are on my to-do list:

Aura tracking: Logging on aura tracking should be made consistent - all instances of auras expiring should have an entry in the "sim" column, or at the very least the expiration should be made explicit in the text. Maybe adding a before/after number is best (e.g., "pyro applied to cryo (36.778 -> Expired)"?
Mod logging: All mod logging should be moved to the "Status" log, and possibly enabled by default. Also need to add logs for mod expiries. This includes enemy mods like VV.
Cooldowns: Cooldowns probably need to be shown on the default view... Somewhere... Maybe just stick in action?

Resolved by #201, and also changes to the gcsimresult repo.


Bug with already existed images preview

If you try to open already downloaded image in preview, only thumbnail appears, original image isn't loaded, if you switch to next\previous image and then go back then original image will be loaded properly. So this bug appears only when you opening preview window for already existed images.
100% repeatable.
win 7 64, 5.2.0

P.S.
heh, I'm feeling like I am professional software tester, so many bugreports)

heh, I'm feeling like I am professional software tester, so many bugreports)

Indeed, thanks! It's a great help to improve the program's quality :smile:

And something else.
hmm... I don't want to create a separate issue for so tiny problem, but I guess that mouse wheel scrolling is working... upside down.

And something else.
hmm... I don't want to create a separate issue for so tiny suggestion, but I guess it will be good Idea to start search via pressing enter key. Because in current grabber you only can do it with mouse.

You can already start the search by pressing enter from the search field though.

Oh, I see. I was confused with 1 seconds dealay between pressing the button and getting results.  Newermind then.

And something else.
hmm... I don't want to create a separate issue. Very needed function, especially for bugreports is ability to copy image md5 sum from details window. In current version when you need file md5, you should rewrite it manually or copy file name from temp folder. Both ways are terrible.

hmm... I don't want to create a separate issue

Even if it's only a one line issue, or only even a title, it's more convenient to have a separate issue. It's better for tracking, or people to follow them. And this way I can close one without closing the other (let's say I fix the original issue here but not your last suggestion, I can't close this issue since it contains both).

Very needed function, especially for bugreports is ability to copy image md5 sum from details window. In current version when you need file md5, you should rewrite it manually or copy file name from temp folder. Both ways are terrible.

Indeed, I'll make all those fields selectable by mouse in 5.2.1. :+1:

Thanks.
I have a question about Github. Can I theoretically open my issues, closed by you?
P.S.
Looks like I posted  all bugs and suggestions that I had, except two related with merge results and image position displaying. So you almost can relax)

I have a question about Github. Can I theoretically open my issues, closed by you?

No you can't. But you can either create a new issue and reference the old one using #ISSUE_ID, or simply comment on the closed issue and I'll re-open it if necessary.

Looks like I posted all bugs and suggestions that I had, except two related with merge results and image position displaying. So you almost can relax)

🎉

BTW I hope you don't take wrongly when sometimes I don't comment on your issues and directly fix them, it just means it's already clear and no questions are needed, and all I could say would be "Indeed, will be fixed in next release" or something. :smile:

Yes, I understand that, I just look, marked my issue or not and everything becomes clear)


ensuring test ng is optional for schema validation

for projects already using junit, adding testng as a dependency (via com.ebay.nst library) is inconvenient and may interfere with existing tests.
this PR changes the SchemaValidatorUtil.java class making it so the testng package is optional, allowing schema validations to happen even when org.testng is excluded from com.ebay.nst.

retest


add Loot Bibliotheca

Added Loot Bibliotheca (for Adventurers) into the resource list.
Loot Bibliotheca graphs approved community projects together so adventurers can see their progress in the Loot verse.
https://loot-bibliotheca-client.vercel.app/

Thank for the PR! Could you please update the description so that it fits on one line like the others?

All fixed now!

Can you also drop the trailing period? Sorry, just going for consistency. :)

fixed now!

Appreciate the changes :)! Merged.

Thank you!
On Wed, 8 Sep 2021, 8:57 am Anish Agnihotri, @.***>
wrote:

Appreciate the changes :)! Merged.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lootproject/website/pull/34#issuecomment-914679116,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF2VQSOM5QBXAOO7QOEVFT3UA2KHHANCNFSM5DN6IGTQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Support for max_automatic_token_associations at contract.deploy()

As a user I'd like to be able to set the property for max automatic token associations somewhere within the deploy() method of a contract.
Reference for max_automatic_token_associations:
This property is supported both for accounts and contracts, but the documentation is not yet updated so I am linking the cryptocreate page for reference instead.
This is where the property should be populated. I am referencing it as a starting point.

Lets add support for this by utilising the customData property that we already have for transactions


Gradle 8+ breaks actionable "useJUnitPlatform" calls

When using Gradle 8+ (like 8.0.2), changing the useJUnitPlatform call from () to {} produces an error.
For example, this block of code will not work:
subprojects {
    tasks.withType<Test>().configureEach {
        useJUnitPlatform {
            includeEngines("spek")
        }
    }
}

The value for task ':redacted' property 'testFrameworkProperty' is final and cannot be changed any further.

However, this one will work fine:
subprojects {
    tasks.withType<Test>().configureEach {
        useJUnitPlatform()
    }
}

To demonstrate this, I’ve made a trivial change at detekt/detekt#5906. As you can see, CI steps there fail.
I suspect this happens because the actionable call sets options as a separate step, as such mutating options twice. The overarching issue was described at #18606 but this one seems to be an oversight.

Sorry that you're having trouble with Gradle!
Did it work in previous versions of gradle? If yes, which ones? If no, then it might be expected behavior.

@ov7a, yes, 7+ work fine with both variants. We’ve started to experience this when attempting an upgrade from 7+ to 8+.

Could you specify the exact 7.x version, please? Does it work for a version between 7.3 (inclusive) and 7.6 (inclusive)?

@ov7a, correct, all 7+ versions work. We keep up with all releases, the last one working was 7.6.1, all versions before it as well.

Thank you for a fast reply and for providing a valid reproducer.
The issue is in the backlog of the relevant team and is prioritized by them.


version solving failed.

Because every version of flutter_test from sdk depends on crypto 2.1.3 and every version of ravepay depends on crypto ^2.1.4, flutter_test from sdk is incompatible with ravepay.
So, because fast_gas depends on both ravepay ^0.0.1+2 and flutter_test any from sdk, version solving failed.
pub get failed (1; So, because fast_gas depends on both ravepay ^0.0.1+2 and flutter_test any from sdk, version solving failed.)

Hey @danedyy
I just went through the changelogs. I am guessing a dependency_override would do the trick for this one.
https://dart.dev/tools/pub/dependencies#dependency-overrides

Hey @danedyy
Is this till an issue?


The special treatment of sm2_id shouldn't be necessary

Because of #11242, I had a closer look at how the SM2 ID is being set, and why.  It's a bit of a hack, really, and it shouldn't be necessary to give it this special treatment...  it should be something settable with EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() alongside any other key operation control, i.e. after EVP_DigestSignInit() and other similar functions.
By consequence, the apps shouldn't need separate -sm2-id options, they should able to specify the SM2 ID, with options such as -sigopt sm2id:ABC or -sigopt hexsm2id:414243.
I suspect that the major driving force behind this special treatment is this:
https://github.com/openssl/openssl/blob/99a16e0459e5089c2cfb92ee775f1221a51b8d05/crypto/evp/m_sigver.c#L249-L254
In other words, the call of digest_custom in EVP_DigestSignInit() forces everyone to have special knowledge about SM2 IDs (which makes it hard to have it as a configurable option among others).
This call could be moved to the corresponding Update (and Final in case Update wasn't called first) functions, and be subject of a flag set in the EVP_PKEY_CTX so it's only called once.
The above isn't very tricky at all.  openssl verify and X509_verify() are, however, because they don't touch keys, at least directly, so calling EVP_PKEY_CTX_ctrl() isn't the first thing that comes to mind.  An idea would be to have a similar mechanism to set optional data, something like X509_STORE_CTX_ctrl() and X509_STORE_CTX_ctrl_str(), and then have a X509_verify_ctx() that takes an extra X509_STORE_CTX * argument that it can pilfer data from.
Do note that with provider side implementations, there is no early processing support à la digest_custom, and I would rather see that it doesn't get added either.  This will force "early processing" to happen as part of the update (or final if no update was called) calls.

Note: I did play with this a bit for a couple of hours last weekend, so there is an upcoming experimental PR.

(some famously heard me say "I have a branch" during a vid-call this morning...  this is what I was talking about, with some cleanup)


Duplication of recent commands

@joshbduncan, calling Recent Commands from Recent Commands looks fun =) But it's better to make an exception so it doesn't add itself to the list =)

@creold, this is fixed in the latest push. Please note that the command "Recent Commands" is in your preferences file, so it will still show until it cycles through the list (which could take a while). You can just run the "Clear Recent Commands" command your preferences file will be updated correctly.


feat: pre-pull images and sideload them into the cluster

Pull docker images (in parallel) and sideload them into the Kind cluster, before installing the helm chart.
In my testing, when starting from a clean machine (after running docker system prune --all), the first install takes ~10 minutes, and the next install takes ~2 minutes

@colesnodgrass the latest commit adds some code to avoid reloading images that already exist on the node. Could you take a fresh look please?


Task - New image - add depicted object radial annotator for each image

Add a second radial annotator, this for the depicted object, below the image annotator.  This will let folks drop additional images onto, say, a collection object.

The dropzone here its use to create image objects, not depictions

Seems like we might need an Image radial akin to our Otu radial?  Options for using that Image quickly
Image -> Modal -> Here's the depictions -> add another image to this object ...

This is now accessible from Radial object -> Depictions slice


Move EUM-server to separate repo

This change is

Needs changes relating to EUM-server from https://github.com/inspectIT/inspectit-ocelot/pull/1375 as well


decoder: pull patch pending upstream inclusion for -fno-common toolch…

…ains
Without the change build fails on staging as:
ld: decoder.o:(.bss.usageScreen+0x0): multiple definition of
  `usageScreen'; errors.o:(.bss.usageScreen+0x0): first defined here

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 180820 run on x86_64-linux 1

1 package built:

decoder

Should probably target staging?

Yeah, I'd prefer master update to avoid possible conflicts with future changes against master. Like possible package version updates.


allow setting the timestamp for jars, sort entries by name

To allow making builds more reproducible/deterministic.
The changes in this PR are safe because the behavior doesn't change until the calling code switches to the new functions.
(This is a rebase of #58, but it appears github doesn't let you reopen PR's against deleted branches, and also doesn't let you retarget closed PR's...)

To validate this pull request against other sbt modules, please visit this link.

A validation involving this pull request is in progress...

The validator has checked the following projects, tested using dbuild, projects built on top of each other.

Project
Reference
Commit

sbt
develop
sbt/sbt@08c7fd1b8f69d9f8d6704131811f10787eb016d0

zinc
develop
sbt/zinc@37665fc007614ec7261588fde914bc477a1b0907

io
pull/279/head
sbt/io@605d9084966ddff1769d5adc7cc3d8658ed660d7

librarymanagement
develop
sbt/librarymanagement@574be6fb792e5dca0c7ff3668902776148584eaf

util
develop
sbt/util@098796cdff7305a4aaadea9fdbba7fb6c23ff3ed

:x: The result is: FAILED
(restart)

A validation involving this pull request is in progress...

The validator has checked the following projects, tested using dbuild, projects built on top of each other.

Project
Reference
Commit

sbt
develop
sbt/sbt@08c7fd1b8f69d9f8d6704131811f10787eb016d0

zinc
develop
sbt/zinc@37665fc007614ec7261588fde914bc477a1b0907

io
pull/279/head
sbt/io@605d9084966ddff1769d5adc7cc3d8658ed660d7

librarymanagement
develop
sbt/librarymanagement@574be6fb792e5dca0c7ff3668902776148584eaf

util
develop
sbt/util@098796cdff7305a4aaadea9fdbba7fb6c23ff3ed

:white_check_mark: The result is: SUCCESS
(restart)


Fix ondemand test.

#1208  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rohinb2 and the rest of your teammates on  Graphite

Merge activity

Aug 28, 10:06 AM EDT: @rohinb2 started a stack merge that includes this pull request via Graphite.


Add some examples to docs?

Hi,
first of all I think you have done an excellent job at creating a Python version of the Solana CLI!
I have seen the SPL client  it seems to require a lot of arguments to initialize but I don't really know where to get them from.  I think what this library is missing are some examples within the docs, for instance, how could we replicate the following Solana CLI actions using solana-py:
spl-token create-token
spl-token create-account <TOKEN>
spl-token mint <TOKEN> 100

@peterschwarzdev found a pretty good example of minting an NFT here:
https://qiita.com/teto_btc/items/2c4ae1a870f387100e73

garbage tier docs


ColumnarBatch not loaded as Arrow ColumnarBatch when vanilla C2R is used

@JkSelf Would you please help me check if this solves the issue?


The keyboard shortcuts panel toggle button is not displayed in Chrome

react-dates version
e.g<EMAIL_ADDRESS>Describe the bug
The keyboard shortcuts panel toggle button (right bottom corner triangle with question mark) is not displayed in Chrome. It is displayed in Firefox. It's completely missing in the DOM in Chrome and pressing the question mark also doesn't open the info panel.
Desktop (please complete the following information):

OS: Windows 10
Browser: Chrome 75.0.3770.100

Is the issue reproducible in Storybook?
Yes. In every story.
Additional context
I have hybrid notebook with touch screen and external display. If you try to detect something as if the device is touch or not this might be an important information. (And your solution not working correctly in that case.)
I suggest making the button appear only when focused and hide it visually in other cases. You should rather use approach similar to sr-only-focusable in Bootstrap 4. Hiding the button via any JS condition is not necessary and won't cover all the cases. It can be in the DOM all the time, like the skip links etc. This is a common and correct approach.

I believe this has been fixed, I'm not able to reproduce.  Can you please try updating to the latest version?  I'm going to close this but please reopen if it's still an issue.


Ok 48 remove movie from list

Jira Link:
Jira Link
Context
Users can now remove movies from lists from their account page
Changes

Changed movie tile so that if it is in the profile page it has an X button which deletes that movie from the users list
Refactored code from movieTile, profileMovieList, and users page so that it calls it from the firebase file
Added User and ListedMovie types
Changed Movie tile styling so info appears on hover of the whole card (not just the link)
Changed profile page so that movies update when a movie is removed
Added an api call which adds dummy list data to the test user

Before and After UI (Required for UI-Impacting PRs)
Before:

After:

Can you tell me why the package-lock.json file seems to have lost 15 thousand lines?

Can you tell me why the package-lock.json file seems to have lost 15 thousand lines?

I am not sure why so many lines got removed, it happened when I tried updating firebase in our project because the functions we had available did not match the current documentation but it had no effect in the end. Everything still works but now we are using the most recent version.


Failed to work with Crossover 21.2

ik its not created to work on MacOS but still, i tried to run it via a Virtualization Wine Software called CrossOver, and it gave the Error shown below

tell me if it can be fixed by a few tweaks so that i can run it on my mac or not.
Kudos to ur Efforts 🎊

Hi Anuj, thanks for providing your feedback.
I believe it should run on the wine software, but while selecting the exe
file make sure to select the initial one and see if everything is getting
extracted correctly, and if that doesn't work then you can try to run it on
a virtual machine.
As we are getting a filenotfound error so that maybe due to all files not
getting extracted properly or you're just running a single exe file and its
path or other dependencies can't be used.
On Mon, Aug 15, 2022, 1:35 PM Anuj Rawat @.***> wrote:

ik its not created to work on MacOS but still, i tried to run it via a
Virtualization Wine Software called CrossOver, and it gave the Error shown
below
[image: image]
https://user-images.githubusercontent.com/37796611/184598433-45ee5c18-2b89-4708-a870-c9245d45f677.png
tell me if it can be fixed by a few tweaks so that i can run it on my mac
or not.
Kudos to ur Efforts 🎊
—
Reply to this email directly, view it on GitHub
https://github.com/AdityaDargan/JEE-MAINS-RESULT-FINDER/issues/4, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AW57VMPM53T4ZHBSKVPZPELVZH23DANCNFSM56RN5AZQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Sorry, i cant make sure that setup extracted each and every dependency or not, but i made sure the setup finished without throwing any error.
Wine is a Headache, will have to use VM 😵💫..
Thanks for reply

Yeah install it on a vm and do let me know if it works.
Thank you
On Mon, Aug 15, 2022, 7:21 PM Anuj Rawat @.***> wrote:

Sorry, i cant make sure that setup extracted each and every dependency or
not, but i made sure the setup finished without throwing any error.
Wine is a Headache, will have to use VM 😵💫..
Thanks for reply
—
Reply to this email directly, view it on GitHub
https://github.com/AdityaDargan/JEE-MAINS-RESULT-FINDER/issues/4#issuecomment-1215038069,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW57VMOLCFBCY2RZOCZ3HWTVZJDPTANCNFSM56RN5AZQ
.
You are receiving this because you commented.Message ID:
@.***>


E2e add lace build artifact reuse

re-add checking/downloading of build artifact
enable canceling a running job
remove artifact check/download form CI as all artifacts are deleted on rerun so it's useless

Downloading artifact is done manually instead of download plugin which has problems finding the artifact.
Will try to use download plugin eventually but that's a different job later.
Cancelled job example

Allure Report
allure-report-publisher generated test report!

processReports: ❌ test report for d247ef31

passed
failed
skipped
flaky
total
result

Total
30
2
0
0
32
❌

remove artifact check/download form CI as all artifacts are deleted on rerun so it's useless

Does this depend on what you rerun? if you rerun e2e tests, artifact build on earlier stage is not rerun, or is it?

remove artifact check/download form CI as all artifacts are deleted on rerun so it's useless

Does this depend on what you rerun? if you rerun e2e tests, artifact build on earlier stage is not rerun, or is it?

For e2e runs we run job again, not rerun. In this case build will be downloaded instead of build again. For CI we can't run workflow manually so we can retry which will not have artifacts from previous attempt so looking for one is pointless. In CI however with new split approach we do not need to rerun whole job if some smoke tests fail, we can just rerun particular failed smoke tests runner and then preceding build step is not run again so we reuse it.


Please add you adapter to our repository

We saw your adapter and if it is ready please request that it is added to the repository. With this it becomes available for all users. Please consult https://github.com/ioBroker/ioBroker.repositories#add-a-new-adapter-to-the-latest-repository and the following sections for more details.
If you need help, contact us in the forum https://forum.iobroker.net/ or in the developer chat https://github.com/iobroker-community-adapters/info .
Thank you for your support.

[ ] Your github repository must have name "ioBroker.". B is capital in "ioBroker", but in the package.json the name must be low case, because npm does not allow upper case letters. Your repository must have "topics". Add these with Manage topics.
[ ] Do not use in the title the words "ioBroker" or "Adapter". It is clear anyway, that it is adapter for ioBroker.
[ ] title in io-package.json (common) is simple short name of adapter in english. titleLang is object that consist short names in many languages. Lang ist not german Länge, but english LANGuages.
[ ] Adapter needs to have a README.md with description, detail information and changelog. English is mandatory. Other languages are welcome. See Example of README.md.
[ ] In README.md, there must be a link to the device or the manufacturer's website. Devices must have a photo. Services do not require a photo, but are still welcome.
[ ] Adapter must have a predefined license.
[ ] Please remove www, widgets and docs directories (admin/tab_m.html, admin/custom_m.html) if not used.
[ ] Adapter needs to have at least Adapter basic testing (installing, running) using Travis-CI (optionally and Appveyor). More information in Forum from apollon77 (Just take from other adapters the samples)
[ ] Define one of the types in io-package.json.
[ ] Define one of the connection types (if applied) in io-package.json.
[ ] All states must have according valid roles (and not just "state")
[ ] Include "author" in io-package.json and "authors" in io-package.json. See here.
[ ] Adapter needs to be available as package on npm. See How to publish on npm
[ ] iobroker organisation must be added as owner to npm package. Why and how to do that.
[ ] Add your adapter into the list (first latest and after that into stable, when tested). Examples of entries you can find here.
[ ] No new adapters will be accepted to repo without admin3 Configuration dialog. Admin2 dialog is optional!
[ ] Check and Follow the Coding best practices listed below
[ ] Forum thread with question to test the adapter.
[ ] Some feedback on forum.
[ ] Important Discovery function! If device can be found automatically (USB, IP) it must be implemented in discovery adapter.

[ ] Your github repository must have name "ioBroker.". B is capital in "ioBroker", but in the package.json the name must be low case, because npm does not allow upper case letters. Your repository must have "topics". Add these with Manage topics.
[ ] Do not use in the title the words "ioBroker" or "Adapter". It is clear anyway, that it is adapter for ioBroker.
[ ] title in io-package.json (common) is simple short name of adapter in english. titleLang is object that consist short names in many languages. Lang ist not german Länge, but english LANGuages.
[ ] Adapter needs to have a README.md with description, detail information and changelog. English is mandatory. Other languages are welcome. See Example of README.md.
[ ] In README.md, there must be a link to the device or the manufacturer's website. Devices must have a photo. Services do not require a photo, but are still welcome.
[ ] Adapter must have a predefined license.
[ ] Please remove www, widgets and docs directories (admin/tab_m.html, admin/custom_m.html) if not used.
[ ] Adapter needs to have at least Adapter basic testing (installing, running) using Travis-CI (optionally and Appveyor). More information in Forum from apollon77 (Just take from other adapters the samples)
[ ] Define one of the types in io-package.json.
[ ] Define one of the connection types (if applied) in io-package.json.
[ ] All states must have according valid roles (and not just "state")
[ ] Include "author" in io-package.json and "authors" in io-package.json. See here.
[ ] Adapter needs to be available as package on npm. See How to publish on npm
[ ] iobroker organisation must be added as owner to npm package. Why and how to do that.
[ ] Add your adapter into the list (first latest and after that into stable, when tested). Examples of entries you can find here.
[ ] No new adapters will be accepted to repo without admin3 Configuration dialog. Admin2 dialog is optional!
[ ] Check and Follow the Coding best practices listed below
[ ] Forum thread with question to test the adapter.
[ ] Some feedback on forum.
[ ] Important Discovery function! If device can be found automatically (USB, IP) it must be implemented in discovery adapter.

Has to be fixed

[ ] Please at least use ioBroker Translator to provided more languages than German and English, e.g. https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/io-package.json#L69

[ ] The referenced docs are non-existing, better specify your readme https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/io-package.json#L75

[ ] The docs are only templates, please at least add them to .npmignore otherwise they will be downloaded at every installation w/o providing any relevant content

Should be fixed

[ ]  I would recommend you to migrate testing from travis/appveyor to GH actions, which is a lot faster and of course integrated

[ ]  adapter startup unit test is now deprecated, so you can remove https://github.com/marvingrieger/ioBroker.haassohn/blob/master/test/unit.js and https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/package.json#L42 except you will define your own unit tests in the near future

[ ] You should really avoid using var like https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/main.js#L16 and everywhere else in your code. Modern javascript has const and let, for such patterns I can really recommend you the eslint module which takes care of this

[ ] module.parent is deprecated https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/main.js#L487, better check module === require.main

[ ] you have a very complex adapter disabling handling in your code, you can simply call adapter.terminate this will stop the execution without disabling the adapter, which is pretty much what you do in your code

Has to be fixed

[ ] Please at least use ioBroker Translator to provided more languages than German and English, e.g. https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/io-package.json#L69

[ ] The referenced docs are non-existing, better specify your readme https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/io-package.json#L75

[ ] The docs are only templates, please at least add them to .npmignore otherwise they will be downloaded at every installation w/o providing any relevant content

Should be fixed

[ ]  I would recommend you to migrate testing from travis/appveyor to GH actions, which is a lot faster and of course integrated

[ ]  adapter startup unit test is now deprecated, so you can remove https://github.com/marvingrieger/ioBroker.haassohn/blob/master/test/unit.js and https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/package.json#L42 except you will define your own unit tests in the near future

[ ] You should really avoid using var like https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/main.js#L16 and everywhere else in your code. Modern javascript has const and let, for such patterns I can really recommend you the eslint module which takes care of this

[ ] module.parent is deprecated https://github.com/marvingrieger/ioBroker.haassohn/blob/c3dfc6c00485e27594ad94de982e6d9826221990/main.js#L487, better check module === require.main

[ ] you have a very complex adapter disabling handling in your code, you can simply call adapter.terminate this will stop the execution without disabling the adapter, which is pretty much what you do in your code

Adapter is now added

Adapter is now added


Command "avanzu:admin:initialize" is not defined.

Command not working:
php bin/console avanzu:admin:initialize
Command "avanzu:admin:initialize" is not defined.
Did you mean one of these?
avanzu:admin:build-assets
avanzu:admin:compact-vendor
avanzu:admin:fetch-vendor

Describe the new feature briefly.
If you consider or have knowledge submit a Pull Request.

Debug info

Component
Version

Symfony version : 3.4

AdminThemeBundle : dev-master

Operating System : Windows

This seems a duplicate of https://github.com/avanzu/AdminThemeBundle/issues/213 and future fix on PR #216
Closing as duplicate. Reopen or comment if you thinks otherwise. Thanks for your report!


Files aren't hidden on mobile

Files in the default file explorer plugin currently are not hidden on mobile, Android

Can't replicate - Likely forgot to toggle option in settings


Merge poland_pl with poland_en, fixing #20

there is a link to the Ukrainian language version in #2 (https://www.gov.pl/web/udsc/ukraina---ua), could this be easily integrated here? or else we can make a new issue for it

@clarejor I'll look into that just now


fix: allow for lora_qunatize_dtype to be null

There is a bug currently where lora_quantize_dtype under the training config cannot take on
values of null. The valid range of values for this field are either "nf4" or null,
however; the CLI only permits nf4 as valid input - ensuring that all models
will be quantize during training. This commit fixes that bug so now the valid
values will be "nf4" or null
Signed-off-by: Oleg S<EMAIL_ADDRESS>

Checklist:

[x] Commit Message Formatting: Commit titles and messages follow guidelines in the
conventional commits.
[ ] Changelog updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

Thanks @RobotSail!
Is there a unit/functional test that can validate this to be sure?


Add support for asyncio.Future

In its current state, doubles's and_return_future only returns concurrent.futures.Future or tornado.concurrent.Future.
def _get_future():
    try:
        from concurrent.futures import Future
    except ImportError:
        try:
            from tornado.concurrent import Future
        except ImportError:
            raise ImportError(
                'Error Importing Future, Could not find concurrent.futures or tornado.concurrent',
            )
    return Future()

To make it work with asyncio, I had to manually patch _get_future:
from asyncio import Future
from typing import Any

import doubles

def fix_doubles_future() -> None:
    def _get_future() -> Future[Any]:
        return Future()

    doubles.allowance._get_future = _get_future

fix_doubles_future()

There should be a way to configure this globally or on a per-call basis.
Btw, I'd be happy to implement the fix but it seems this repository is not maintained anymore: https://github.com/uber/doubles/issues/145

@charlax hi charlax i just ran into this as well, should we fork this repo?

@charlax @jmaliksi I hope all is well!
I was already thinking of forking this because I ran into some other issues (see #148).
I will get a new fork up and published, any thoughts on the name?

Oh hey friends!
For sure, let's fork! doubles is awesome.

doubles....2

@charlax @jmaliksi dobles has been launched.  It is just at feature parity now, I'll work on improving all the async stuff this week.

Oooooh nice thanks Todd!
On Sun, Oct 29, 2023 at 4:40 PM Todd Sifleet @.***>
wrote:

@charlax https://github.com/charlax @jmaliksi
https://github.com/jmaliksi dobles
https://github.com/smartfastlabs/dobles has been launched. It is just
at feature parity now, I'll work on improving all the async stuff this week.
—
Reply to this email directly, view it on GitHub
https://github.com/uber/doubles/issues/146#issuecomment-1784219255, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA5NNNWMCB5ZAZM4YPXQALYB25KPAVCNFSM5OEIMLT2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGQZDCOJSGU2Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


Desktop Turn overwriting camera X-Rotation even in full XR mode

The movement_desktop_turn.gd scripts physics_movement() method is resetting the player body camera X-rotation to 0 even when XR is actively being driven by a headset.
https://github.com/GodotVR/godot-xr-tools/blob/7c6d455b7d6f4b05e4874cab4d53912270a3d84b/addons/godot-xr-tools/desktop-support/movement_desktop_turn.gd#L87-L95
When not in desktop mode the desktop movement providers should do nothing.

@pietru2004 Could you look into this?

Last time I checkedit wasnn't doing anything when xr was active(headset active). Gona check again...

If you set  clear_cam_x_when_body_not_active to false there ahould be no problems, also I think problem that surreal6 has is related to vr headset he had connected to pc.

Yes, real XR mode can be fixed by overriding the default 'true' value of that value to be false, but that means the user has to explicitly disable a portion of the desktop behavior to get XR mode functioning correctly.
I'm still not clear why the desktop code is doing anything when the user isn't in desktop mode.

Hi there, this seems to be the bug I was experimenting with the desktop function and the gaze pointer. I can confirm the problem

hm... If I recall correctly the clear_cam_x_when_body_not_active was made for sitting and was meant only for desktop so the if statement should probably be altered. The clear_mouse_move_when_body_not_active is supposed to clear any mouse movement if player is not in desktop mode


A problem with Display Icons

the problem is that it is enabled, but showing ordinary vanilla minecraft creatures, what do I need to do to fix it?

#673


Multi Range Slider

I put together some css to allow two sliders to sit on top of one another, for a min-max effect.
I thought it might be useful for other people here, and maybe inspire an option to the slider component -- not exactly sure how i'd make it generally useful though.
Might it be worthwhile to have a tips and tricks wiki for things that aren't quite components yet?

https://gist.github.com/Conaws/7ffd9077592e309e7db4d1eb72cd3418

Would be happy to take a PR for a component like this, which included appropriate demo code on the slider demo page.


Testing bug reporter compatibility

Submitted By: Myself
Feedback Type: Bug
Core: 0.7.9
System: dnd5e v1.2.4
Module Version: scene-packer v1.0.5
Description:
I just opened the module and chose the Post Bug option.

Thanks


Stack ordering with float elements

Hi,
Thanks for the amazing work you did!
The image in the following link is not rendered in screenshot example.
As per my debug, the element containing the text is rendered on top of the image. The image has float:right.
http://www.camoni.co.il/index.php?idr=400&p=210948
Is it a limitation?
Regards

Another site with similar issue: http://www.iab.net/

Fixed in 1.0.0