mtkclient: Init at 2.0.1/HEAD

[shymega]

This PR adds mtkclient at v2.0.1, but the src is at the latest Git HEAD, due to needing a release after v2.0.1 to fix pyproject.toml.

It's not ideal, but once a new release is made, I'll push a PR to bump the version and src tag/hash.

mtkclient is a set of Python tools to work with the preloader/boot ROM on certain Mediatek devices.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[shomykohai]

Small note on the fact HEAD is being used instead of the release for whoever will review this PR

The tagged release in the repo (v2.0.1.freeze) is currently half broken and is too old to be used on modern chipsets (which takes up the majority of the use cases for this tool).
HEAD (which is what this PR uses in fact) is what everyone suggests using until a new release is available, even on other distributions.

[shymega]

Thanks @shomykohai, I will keep this is at HEAD for the moment, and we can bump if there's significant changes. Ideally we'd prefer a tag.

[timschumi]

fwiw, duplicate of #432318

[shymega]

fwiw, duplicate of #432318

Perhaps we could merge the two together? I note yours doesn't install udev rules, or have distinct propagatedBuildInputs/buildInputs, which may affect mtkclient.

I think both MRs add something, but working together to merge them both would be beneficial.

[timschumi]

Perhaps we could merge the two together? I note yours doesn't install udev rules, or have distinct propagatedBuildInputs/buildInputs, which may affect mtkclient.

I'll pull in the udev stuff, although 50-android.rules is going to be obsolete once systemd 258 lands (which might very well be before mtkclient gets merged given the existing timeline).

As for the propagatedBuildInputs stuff, that sounds kind of excessive. Is there anything that actually breaks if all the Python dependencies are not propagated?

[shymega]

Perhaps we could merge the two together? I note yours doesn't install udev rules, or have distinct propagatedBuildInputs/buildInputs, which may affect mtkclient.

I'll pull in the udev stuff, although 50-android.rules is going to be obsolete once systemd 258 lands (which might very well be before mtkclient gets merged given the existing timeline).

It might be different to upstream 50-android.rules, it's worth running a diff between the two to verify.

As for the propagatedBuildInputs stuff, that sounds kind of excessive. Is there anything that actually breaks if all the Python dependencies are not propagated?

Some dependencies are runtime dependencies, so probably best to check all the commands mtkclient exposes (I'll check your PR, see if it exposes all binaries as defined in pyproject) don't require X, Y dependency.

[shymega]

@timschumi The only things I think your package could benefit from would be:

• https://github.com/NixOS/nixpkgs/pull/447819/files#diff-1d9f1d23cf9379d636139e702e421a184f4b215ef941276a6875464b02e15a46R23-R26
  (these are build dependencies of mtkclient, as defined on their README)
• https://github.com/NixOS/nixpkgs/pull/447819/files#diff-1d9f1d23cf9379d636139e702e421a184f4b215ef941276a6875464b02e15a46R50
  So that legacy references to mtkclient still work.

Other than that, I think we can close my package as a dupe of yours, and I'll update the Flake I created as a PR for mtkclient once yours is merged and backported.

[timschumi]

I don't want to make it appear that I'm shutting down everything you suggest, but...

It might be different to upstream 50-android.rules, it's worth running a diff between the two to verify.

Good call. Diffed it to the most recent 51-android.rules at the time of update, the only downstream addition (weirdly enough) was the SuzyQable, which is from the ChromiumOS project (so there shouldn't be any relation to any MTK SoC).

In any case, the new upstream system rules match the required devices by their interface IDs, so they no longer require a static list of vendor and device IDs at all.

these are build dependencies of mtkclient, as defined on their README

Those are build dependencies for the python packages when installed via pip, I don't think they apply to our packaging situation for the following reasons:

• fuse gets propagated by fusepy, so adding fuse to our build inputs is a no-op since we already depend on fusepy
• libusb1 isn't explicitly declared as a dependency to pyusb, but its path gets patched into the default search path of the pyusb library loader

So that legacy references to mtkclient still work.

Did that command alias actually ever exist? As far as I can tell the script has always been called mtk, back to the initial v1.4 release.

[shymega]

I don't want to make it appear that I'm shutting down everything you suggest, but...

No worries - this is all part of collaboration.

It might be different to upstream 50-android.rules, it's worth running a diff between the two to verify.

Good call. Diffed it to the most recent 51-android.rules at the time of update, the only downstream addition (weirdly enough) was the SuzyQable, which is from the ChromiumOS project (so there shouldn't be any relation to any MTK SoC).

Ah, so that's all good, then.

In any case, the new upstream system rules match the required devices by their interface IDs, so they no longer require a static list of vendor and device IDs at all.

Sounds good, but maybe we should keep the udev rules until this version of systemd has been in unstable, 25.05, and the upcoming 25.11 for a few weeks?

these are build dependencies of mtkclient, as defined on their README

Those are build dependencies for the python packages when installed via pip, I don't think they apply to our packaging situation for the following reasons:

* `fuse` gets propagated by `fusepy`, so adding `fuse` to our build inputs is a no-op since we already depend on 

fusepy

Ack, that's OK.

* `libusb1` isn't explicitly declared as a dependency to `pyusb`, but its path gets patched into the default search path of the `pyusb` library loader

Right, that's OK.

Think we can disregard my points about build deps, then.

So that legacy references to mtkclient still work.

Did that command alias actually ever exist? As far as I can tell the script has always been called mtk, back to the initial v1.4 release.

Hm, maybe I was remembering wrong. Let's ignore the mtkclient alias then.

[shymega]

I am going to close this PR in favor of #432318.