Companion Linux: build AppImage

[raphaelcoeffic]

No description provided.

[pfeerick]

Well, I think that's that issue put to rest! 😁 Was in a VM for now, but had access to real transmitter, and was able to both read from and write to it. Just need the simulators now! :)

[raphaelcoeffic]

Well, I think that's that issue put to rest! 😁 Was in a VM for now, but had access to real transmitter, and was able to both read from and write to it. Just need the simulators now! :)

Dfu-util isn’t missing? I’d bet the dependencies are not packaged…

[pfeerick]

You'd win that bet... it's looking for the system installed dfu-util... I hadn't tried dfu-read as that's what Flasher is for! 😛

[raphaelcoeffic]

@pfeerick no clue which consequences it has, but there is no way to copy the udev rules from within an AppImage... (see AppImageCommunity/pkg2appimage#200)

[pfeerick]

I wouldn't worry about that so much in this first instance - and I'm not surprised, to do anything udev related you'd need root/admin privileges since you're messing around with system rules. In this case, the rules in /companion/targets/linux are simply setting permissions, so that the owner-group-users all have read and write access, meaning Companion doesn't need to be run as a admin user to access the taranis or usbasp.

Worst case scenario, we come up with a shell script the user runs on their system, which is able to detect the difference between debian/arch/suse systems, run the appropriate package manager commands to install dfu-utils for that distro, and apply any udev rules necessary. The likelihood is you won't have to hand-hold Linux users that much (else they shouldn't be using Linux in the first place!) - just tell them they need to install dfu-util (if they can't figure it out from the error message), and

[raphaelcoeffic]

I wouldn't worry about that so much in this first instance - and I'm not surprised, to do anything udev related you'd need root/admin privileges since you're messing around with system rules. In this case, the rules in /companion/targets/linux are simply setting permissions, so that the owner-group-users all have read and write access, meaning Companion doesn't need to be run as a admin user to access the taranis or usbasp.

Worst case scenario, we come up with a shell script the user runs on their system, which is able to detect the difference between debian/arch/suse systems, run the appropriate package manager commands to install dfu-utils for that distro, and apply any udev rules necessary. The likelihood is you won't have to hand-hold Linux users that much (else they shouldn't be using Linux in the first place!) - just tell them they need to install dfu-util (if they can't figure it out from the error message), and

dfu-util needs to be installed in the AppImage, otherwise it cannot be executed from Companion. Imagine a AppImage as a sort of a sandbox ;-)

[pfeerick]

No, not quite... AppImages aren't sandboxes (like a virtual machine)... it's a self-contained packaged that can also access host resources and files... i.e. I just did an apt install dfu-util on the host OS (Ubuntu), and now instead of an error, I can flash the firmware...

All that bundling dfu-util does is 1) ensure it's actually present and 2) because it's bundled, you have certainly as to the version available.

[pfeerick]

Regardless, this package is working fine for me on Windows and Linux (Ubuntu), and seems to be able to read and write to the radio properly in both cases. Simulators also both run for both.

[raphaelcoeffic]

@pfeerick by the way, I assume that the code for windows is basically trying to do the same thing with some strange Win32 API:

  char name[MAX_PATH];
  GetModuleFileName(NULL, name, MAX_PATH);
  QString path(name);
  path.truncate(path.lastIndexOf('\\'));
  dir.setPath(path);

I think we should try to get rid of this at the same time. Is that something you could try out?

[pfeerick]

I think Risto has identified the dfu-utils problems to be a combination of host-install path issues and a underlying bug in companion which has been since fixed.

I haven't had any issues with this when trying it on Linux - either in a VM or on actual hardware.