Package Details: xiaomi-adb-fastboot-tools 7.0.3-1

Git Clone URL: https://aur.archlinux.org/xiaomi-adb-fastboot-tools.git (read-only, click to copy)
Package Base: xiaomi-adb-fastboot-tools
Description: Simple tool for managing Xiaomi devices on desktop using ADB and Fastboot
Upstream URL: https://szaki.github.io/XiaomiADBFastbootTools/
Licenses: MIT
Submitter: pfm
Maintainer: theopouris
Last Packager: theopouris
Votes: 5
Popularity: 1.16
First Submitted: 2019-11-15 22:17
Last Updated: 2020-10-29 08:27

Latest Comments

archcid commented on 2020-11-07 19:29

cyclical update attempts

aur/xiaomi-adb-fastboot-tools 7.0.3-1 -> 7.0.3-1

theopouris commented on 2020-10-29 08:52

Hi krackpipe, I updated the dependencies so it picks only jre11, as the option ">=11" did not seem to work. I can see that you are using an older version of Java.

krackpipe commented on 2020-10-28 17:34

Thanks for maintaining this application. I noticed java version problems with compiling lately. No errors with downloading, with Gradle, or any initialization, but compiling fails java checks.

$ uname -r 
5.9.1-arch1-1
$ java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)
$ yay -S xiaomi-adb-fastboot-tools
[snip]
FAILURE: Build failed with an exception.

* What went wrong:
java.lang.UnsupportedClassVersionError: org/openjfx/gradle/JavaFXPlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
> org/openjfx/gradle/JavaFXPlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

dreieck commented on 2020-06-04 09:08

I had the same problem as @neitsab, having had to do a archlinux-java set ....

Maybe add a check in prepare() which invokes archlinux-java get and complains to the user if the result returns a non-fitting java version? Or is there a possibility to explicitly choose a modern enough java just to build the package (via environment variables or explicit call to a matching executable)?

dreieck commented on 2020-06-04 08:53

Ahoj,

this PKGBUILD does download stuff uring build() (see below). Thus must not happen. No internet connection can be assumed in build() and package().

Please make sure that everything needed to build the packagee gets downlooaded * via th source-array (this way also the user specified download agents in makepkg.conf can be honoured), or * as an exception in preparee().

Please update the PKGBUILD accordingly.

Thanks for maintaining!

==> Starting build()...

[...]

Starting a Gradle Daemon (subsequent builds will be faster)
<-------------> 0% CONFIGURING [26s]
> root project > Resolve files of :classpath > kotlin-annotation-processing-gradle-1.3.71.jar > 238 KB/432 KB downloaded
> root project > Resolve files of :classpath > kotlin-compiler-embeddable-1.3.71.jar > 78 KB/38.33 MB downloaded
> root project > Resolve files of :classpath > kotlin-android-extensions-1.3.71.jar > 174 KB/342 KB downloaded
> root project > Resolve files of :classpath > kotlin-gradle-plugin-1.3.71.jar > 622 KB/3.48 MB downloaded
[...]

neitsab commented on 2020-04-28 18:39

Hi pfm! I've been using pacaur for so long that I tend to forget that it is indeed an unsupported way of acquiring AUR packages. After checking it with plain makepkg I could verify that the PKGBUILD works flawlessly, so no need to change anything, thanks.

I hope at least that my comment and your answer will prove useful to someone else stumbling upon the same issue! Cheers.

pfm commented on 2020-04-11 08:45

Hi neitsab! All my AUR packages are built in a clean chroot environment. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot I do not test to build them with different AUR helpers such as pacaur or yay in a custom system environment. So I can avoid your java issues. For the gendesk issue: I try to stick to the wiki: https://wiki.archlinux.org/index.php/Desktop_entries#gendesk So I would like to leave gendesk in the prepare() function.

neitsab commented on 2020-04-05 22:25

Hi there! Using pacaur to install the package today, I got an error during prepare() because gendesk was required, but it isn't installed before a bit later in the process. That made me realize that makedepends are only guaranteed to be present during the build() step and not during prepare()...

So what I did was to edit the PKGBUILD to move the gendesk step within build(), before cd "$srcdir/$_pkgname-$pkgver" to avoid an error later during package(), and getting rid of the entire prepare() stage. I could then proceed to building, but there I got the following error:

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.UnsupportedClassVersionError: org/openjfx/gradle/JavaFXPlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0
> org/openjfx/gradle/JavaFXPlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0

This is because I had jre10-openjdk already installed and selected as the default java environment due to an old application I had never removed, so I had to run archlinux-java set java-13-openjdk (which is the one I had selected among the different providers offered) for the gradle build to succeed.

To summarize, I think the PKGBUILD should be modified to place the gendesk operation at the beginning of build() and making sure that a java environment ≥ 11 is indeed set using archlinux-java, otherwise the installation will fail.

About this second point, I was thinking maybe we can extract the set java env during prepare(), store it in a var then set it to ≥ 11 using the aforementioned command, and then restore it at the end so as not to mess the user environment? Or maybe just pause and echo something for the user to manually do it before building... The Arch packaging guidelines for Java don't touch upon that subject, and it is the first time I face it so I'm a bit at a loss about how to come at it ¯\(ツ)/¯ Another way would be to just pin a comment here saying "before building make sure your Java env is set to something ≥ 11", but that's not ideal either...

Btw, for some reasons using java-runtime>=11 in makedepends doesn't restrict the version of Java as expected: I was offered to install JDK 7, 8 and 10 besides 11 and current, as can be seen on this very page. Any idea how to fix that?

All the best.