Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update request: tracker-miners 3.5.1 #228639

Closed
1 task done
bobby285271 opened this issue Apr 28, 2023 · 7 comments · Fixed by #253627
Closed
1 task done

Update request: tracker-miners 3.5.1 #228639

bobby285271 opened this issue Apr 28, 2023 · 7 comments · Fixed by #253627

Comments

@bobby285271
Copy link
Member

  • Package name: tracker-miners
  • Latest released version: 3.5.1
  • Current version on the unstable channel: 3.5.0

The package update itself is trivial, but I got stuck at addressing tracker-miners!449. There is now a BTRFS_IOC_INO_LOOKUP ioctl check in meson.build that runs:

#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/btrfs.h>

int main (int argc, char *argv[]) {
    struct btrfs_ioctl_ino_lookup_args args = { 0, };
    int fd = open ("/", O_RDONLY);
    int ret = ioctl (fd, BTRFS_IOC_INO_LOOKUP, &args);
    return (ret < 0 && errno != ENOTTY) ? 1 : 0;
}

The program seems to build fine, but does not exit with 0:

Checking if "BTRFS_IOC_INO_LOOKUP ioctl is available" runs: NO (1)

This makes the Btrfs subvolume feature disabled:

Feature Support:
    BTRFS subvolumes:                       false

I am not sure where to get start to enable this since in tracker-miners#267 they decide this will be a hard check on next major bump (well, it should be possible to opt-out but it should be possible to have it enabled I guess).

@jtojnar 🙈


Note for maintainers: Please tag this issue in your PR.

@jtojnar
Copy link
Contributor

jtojnar commented Apr 28, 2023

I am getting BTRFS subvolumes: true, even though I do not use BTRFS so I assume this depends on the kernel version of the builder? (I am using linuxPackages_latest.) That does not really sound like a good idea since users can use completely different kernel version than Hydra.

Maybe it should be an feature and the check performed only when it is auto. Though I am not sure what the consequences are when incorrectly configured is used. Maybe it will need to be a runtime check instead?

@bobby285271
Copy link
Member Author

bobby285271 commented Apr 28, 2023

I saved the program as a separate test.c and compiled & ran with gcc test.c && ./a.out as root user and it exits with 1 for me as well. uname -a says I am on 6.3.0. I use btrfs so btrfs subvolume list / as root runs fine for me (if that matters).

Hmmm then this is weird since it sounds like BTRFS_IOC_INO_LOOKUP is introduced very early (is this the correct place to check such info?). But later I found in Fedora rawhide's build log the BTRFS subvolumes feature is disabled as well 🤔

Edit: Looks like the fedora link is broken, here is a new one

@jtojnar
Copy link
Contributor

jtojnar commented Apr 28, 2023

Apparently, it falls back to success since I do not use BTRFS: -1 25 Inappropriate ioctl for device (both inside and outside the sandbox)

Modified test.c
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/ioctl.h>
#include <linux/btrfs.h>

int main (int argc, char *argv[]) {
    struct btrfs_ioctl_ino_lookup_args args = { 0, };
    int fd = open ("/", O_RDONLY);
    int ret = ioctl (fd, BTRFS_IOC_INO_LOOKUP, &args);
    printf("%d %d %s\n", ret, errno, strerror(errno));
    return (ret < 0 && errno != ENOTTY) ? 1 : 0;
}

So that does not really sound like a good test.

Edit: I asked upstream.

@bobby285271
Copy link
Member Author

bobby285271 commented Apr 28, 2023

Hmmm now I wonder if their original idea is to check whether the code compiles, probably knowing BTRFS_IOC_INO_LOOKUP is there is already enough? (I assume they are not supporting < 2.6.34 kernels then I expect all linux should have it?)

It looks like they already has some run-time check.

@jtojnar
Copy link
Contributor

jtojnar commented Apr 28, 2023

Could you try running the modified test.c in build sandbox to find out why specifically it fails for you?

@bobby285271
Copy link
Member Author

This is using nix-build and putting gcc test.c && ./a.out in buildPhase:

building '/nix/store/rk7zkgkx6mw8rv1v00ik65kpvhcy7d0r-test.drv'...
unpacking sources
unpacking source archive /nix/store/0bsbg9ypb9wj12kfpw51dxz2m3vs14im-ci-cd-demo
source root is ci-cd-demo
patching sources
configuring
no configure script, doing nothing
building
-1 1 Operation not permitted
error: builder for '/nix/store/rk7zkgkx6mw8rv1v00ik65kpvhcy7d0r-test.drv' failed with exit code 1;

This is not in builder sandbox and run gcc test.c && ./a.out as root:

-1 2 No such file or directory

@jtojnar
Copy link
Contributor

jtojnar commented Sep 3, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants