Package Details: vesc_tool-git 3.00.r287.b0632c4.r287.b0632c4.r287.b0632c4-1

Git Clone URL: (read-only, click to copy)
Package Base: vesc_tool-git
Description: VESC ESC graphical configuration tool
Upstream URL:
Licenses: GPL3
Conflicts: vesc-tool
Submitter: Kezi
Maintainer: Kezi (bionade24)
Last Packager: bionade24
Votes: 1
Popularity: 0.031251
First Submitted: 2018-08-27 22:50
Last Updated: 2021-06-11 13:09

Latest Comments

1 2 Next › Last »

niraami commented on 2021-06-12 17:00

@bionade24 The reason behind my error a few months back is a flawed pkgver() function, as it returns the pkgver variable + the git information (r287.b0632c4)... that is already in that variable - essentially duplicating it. I've noticed that after installing the package (through yay or manually) the PKGBUILD gets updated. Here is the diff:

diff --git a/PKGBUILD b/PKGBUILD
index 3a0eaf4..3f3f06b 100644
@@ -1,5 +1,5 @@
 pkgdesc="VESC ESC graphical configuration tool"
 arch=('i686' 'x86_64' 'aarch64' 'armv7h' 'armv6h')

So, if you don't reload the pkgbuild during installation, this issue will not arise (which I guess Yay does for some reason). Also using the --editmenu to edit the PKGBUILD /w Yay and removing the "${pkgver}" from pkgver() solves the issue.
I can see that this is not an issue only affecting me, as, in the latest commit, you've changed the pkgver to 3.00.r287.b0632c4.r287.b0632c4.r287.b0632c4-1. I find that kind of hilarious as it also changed the name of the package on AUR.

Also, dunno if this is helpful, but the commit that introduced this issue was: 163d11d0e029.
The offending line is: printf "${pkgver}.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

My recommendation is, if you want to also keep the program version included in the name & the pkgbuild, use a separate variable for it (like gitver=3.00). Though it is unfortunate that the github maintainers still don't tag the versions on GitHub.

I hope my formatting is done right, otherwise I might edit this comment a few times.

DarioP commented on 2021-06-11 13:45

Thank you for your very prompt action, I was able to successfully build the package.

I did not look into the building system, but I agree that everything that can be fixed upstream should be done there, without custom fixes and patches ;)

bionade24 commented on 2021-06-11 13:13

@DarioP: The linkers errors are fixed now.

It still would probably better to patch the upstream .pro file instead of provding a derived one, probably doing that.

DarioP commented on 2021-06-11 08:19

Anyone getting the same linker errors as I do:

/usr/bin/ld: mainwindow.o: in function `MainWindow::on_actionLoadMeters_triggered()':
mainwindow.cpp:(.text+0x8267): undefined reference to `QmlUi::startCustomGui(VescInterface*)'
/usr/bin/ld: mainwindow.cpp:(.text+0x8289): undefined reference to `QmlUi::reloadCustomGui(QString)'
/usr/bin/ld: mainwindow.o: in function `MainWindow::on_actionCloseCustomGUI_triggered()':
mainwindow.cpp:(.text+0x82e6): undefined reference to `QmlUi::stopCustomGui()'
/usr/bin/ld: mainwindow.o: in function `MainWindow::~MainWindow()':
mainwindow.cpp:(.text+0xc609): undefined reference to `vtable for QmlUi'
/usr/bin/ld: mainwindow.o: in function `MainWindow::MainWindow(QWidget*)':
mainwindow.cpp:(.text+0xc8c5): undefined reference to `QmlUi::QmlUi(QObject*)'
/usr/bin/ld: mainwindow.o: in function `MainWindow::MainWindow(QWidget*) [clone .cold]':
mainwindow.cpp:(.text.unlikely+0x170e): undefined reference to `vtable for QmlUi'
/usr/bin/ld: vescinterface.o: in function `QtPrivate::QFunctorSlotObject<VescInterface::VescInterface(QObject*)::{lambda(QByteArray&)#5}, 1, QtPrivate::List<QByteArray&>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*)':
vescinterface.cpp:(.text+0x838): undefined reference to `UdpServerSimple::packet()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::udpServerStart(int)':
vescinterface.cpp:(.text+0x4085): undefined reference to `UdpServerSimple::startServer(int, QHostAddress)'
/usr/bin/ld: vescinterface.cpp:(.text+0x40d1): undefined reference to `UdpServerSimple::errorString()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::udpServerStop()':
vescinterface.cpp:(.text+0x41a6): undefined reference to `UdpServerSimple::stopServer()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::udpServerIsRunning()':
vescinterface.cpp:(.text+0x41b6): undefined reference to `UdpServerSimple::isServerRunning()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::udpServerIsClientConnected()':
vescinterface.cpp:(.text+0x41c6): undefined reference to `UdpServerSimple::isClientConnected()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::udpServerClientIp()':
vescinterface.cpp:(.text+0x41ef): undefined reference to `UdpServerSimple::getConnectedClientIp()'
/usr/bin/ld: vescinterface.o: in function `VescInterface::VescInterface(QObject*)':
vescinterface.cpp:(.text+0xdbdf): undefined reference to `UdpServerSimple::UdpServerSimple(QObject*)'
/usr/bin/ld: vescinterface.cpp:(.text+0xdbf8): undefined reference to `UdpServerSimple::setUsePacket(bool)'
/usr/bin/ld: vescinterface.cpp:(.text+0xdc02): undefined reference to `UdpServerSimple::packet()'

bionade24 commented on 2021-01-11 08:16

@niraami: I can't reproduce your issue, seems like caused by your dirty build environment. Please use a clean chroot/container.

bionade24 commented on 2020-11-25 13:47

This package works with 5.15. It's not a -bin package, so it's not precompiled. You can build it yourself, but you don't need to, of course.

albfan commented on 2020-11-25 08:53

Look at the build script for linux.

For current 2.06 Seems it needs to use exactly Qt 5.12 and build with some precise steps:

You can download for free precompiled version on their site. You have to create a login and make a 0€ order. Then you can download by email.

bionade24 commented on 2020-04-08 19:15

@caleb: You mean releases? There aren't any official releases, this is why a git version makes sense. There is a version configured in the .pro file, but to let pacman work better I'll let the automatic git version tagging. So you need to update yourself, you can e. g. do this with a cronjob or pacman hook. Rest of the issues should be fixed, too.

alerque commented on 2020-03-21 11:57

Per Arch packaging recommendations, please don't include definitions for empty values, e.g. remove groups=() and the others like it. Are there really no upstream version markers from which to number commits from? Does the software not identify any itself with any version internally?

P.S. Thanks for adding @bionade24 as a co-maintainer.

bionade24 commented on 2020-03-20 20:13

Thanks for updating! Your PKGBUILD is still extremely hacky and doesn't build in a clean chroot. I'm working on a guidelines conforming version. Would be nice if you could add me as co-maintainer.