(Installation) Create native Linux distributions (rpm etc) about irscrutinizer HOT 19 CLOSED

If you mean Ubuntu, it's actually deb based ;-)

from irscrutinizer.

Why not an AppImage that runs on all distros?

from irscrutinizer.

Why not an AppImage that runs on all distros?

This is really interesting. I would be very happy to see a test of this.

from irscrutinizer.

An AppImage can be found at
https://bintray.com/probono/AppImages/IrScrutinizer/view#files

It has been created using https://github.com/probonopd/AppImages/blob/master/recipes/irscrutinizer/Recipe

from irscrutinizer.

Very cool!!

There are some problems though: Most things using the java.awt.Desktop appears broken, like invoking the browser both on local files (Help->Program Documentation) and external URLS (Help -> Project home page). Related, I have a problem with bundling of JVM; possibly it would be a good idea to have one version with and one version without JVM.

The Maven build builds an appdir directory for Mac, it would be a better idea to start from this.

Will get back on this issue; my experiences with Fedora packing were not entirely positive... I really like the approach.

from irscrutinizer.

Just discovered a more fundamental problem:

(To reproduce: remove the props file $(HOME)/.config/IrScrutinizer/properties.xml and start twice.)
IrScrutinizer is not made for changing location of its configuration files.

from irscrutinizer.

What can I do regarding that?

from irscrutinizer.

After considerable struggling (see the commit), the two problems remains, both show-stoppers:

• relocation
• Browser invocations through java.awt.Desktop is broken, both for http-URLs and for local files.

from irscrutinizer.

Is it possible to change the code so that IrpProtocols.ini is referred to in relative rather than absolute terms?

from irscrutinizer.

#100.

from irscrutinizer.

Used feature branch: appimage.

Status:

• relocation problem is solved.
• Java desktop still non-operational. Also using xdg-open fails.
• Due to different locations of lock directory, need to prefer the system's RXTX, Done:
  e97b62e

from irscrutinizer.

Solved! Test image

from irscrutinizer.

On a stock Ubuntu 16.04, I get /tmp/.mount_M1US8m/usr/bin/irscrutinizer: 5: /tmp/.mount_M1US8m/usr/bin/irscrutinizer: java: not found.

After sudo apt install default-jre I get:

/home/me/Downloads/IrScrutinizer-1.1.4snapshot-x86_32.64.AppImage /tmp/.mount_RfWmDz/usr/bin/irscrutinizer.wrapper
Property File /home/me/.config/IrScrutinizer/properties.xml not found, using builtin defaults.
[Warning] exportformats.xml:890:40: Include operation failed, reverting to fallback. Resource error reading file as XML (href='myexportformats.xml'). Reason: /tmp/.mount_RfWmDz/usr/share/irscrutinizer/myexportformats.xml (No such file or directory)

but it runs.

from irscrutinizer.

These messages are neither errors nor specific to the AppImage version.

Property File /home/me/.config/IrScrutinizer/properties.xml not found, using builtin defaults.

Means exactly what it sounds like, will not appear the second time (because then the parameters from the first session has been saved).

[Warning] exportformats.xml:890:40: Include operation failed, reverting to fallback. Resource error reading file as XML (href='myexportformats.xml'). Reason: /tmp/.mount_RfWmDz/usr/share/irscrutinizer/myexportformats.xml (No such file or directory)

See end of exportformats,xml. Unfortunately, despite of the <fallback/> element (blessing the non-existence of the to-be included file), this pesky warning remains, I might comment it out...

@probonopd : Any thoughts of the feasibility of a multi-platform appimage? Everything except for some appimage components are multiplatform...

from irscrutinizer.

Re. multiplatform please see AppImage/AppImageKit#130

from irscrutinizer.

Thanx, but my idea was one appimage that runs on several architectures (x86_64, i686, arm...). The quoted thead is about an AppImageKit that generates different Appimages, all of which run on exactly one architecture. Or did I misunderstand?

BTW, thanx for your support in the past!

from irscrutinizer.

Indeed. Having the same AppImage run on multiple architectures would require either FatELF coming into kernels, or we'd have to switch back to using a script in the header of the AppImage rather than a binary, which creates its whole own set of problems (editors trying to open AppImages and then crashing being the most obvious one). So I don't see a pragmatical way to make it happen anytime soon. Also, it could add bloat in many situations since we would have to ship the architecture-dependent contents of the AppImage for each architecture.

from irscrutinizer.

Ok, "90%" of the current Linux users are likely using x86_64 architectures anyhow...

Mainly for documentation: Many (most) current Linux distros requires the current user to be in the group "lock" for RXTX (and thus serial and "usb-serial" devices) to work, see this The Fedora rpm simply prohibits the user from running the program, which is of course unacceptable -- in particular for the user who do not care about serial access anyhow. Since there are so many unknowns here -- not only if the user needs it or not, but also the very locking mechanism used -- I think it is better not to address this problem at all. RXTX is sceduled for replacement (#20) anyhow.

from irscrutinizer.

Merged into the main branch, including CI travis integration!

Although "only" x86_64 is presently supported, I am closing this. If anyone wants to contribute x86_32 or ARM appimage builds, feel free to do so.

Again, much thanx to probonopd!

from irscrutinizer.