PupNet-Deploy - something to share!

[kuiperzone]

I've been asking a lot questions recently because I've been working on a project of my own. Thank you for all the help!

If I may, I'd like to share:

https://github.com/kuiperzone/PupNet-Deploy

It's cross-platform deployment utility that targets dotnet applications. PupNet makes it easy, for example, to package dotnet apps as AppImage, and AppImage is my preferred format.

[probonopd]

Wow @kuiperzone, this will be very useful indeed. Thanks for sharing.

Personally I think the world needs more cross-platform solutions.

Is there any chance you could add the various packages including the AppImage to https://github.com/kuiperzone/PupNet-HelloWorld/releases? I'd like to test the AppImage of a GUI application packaged with your tools.

Thank you very much for all the hard work you've been putting in.

[probonopd]

This will be very interesting indeed. Thanks for keeping us posted!

[kuiperzone]

Installation packages now added to release. See:

https://github.com/kuiperzone/PupNet-HelloWorld/releases/tag/v1.0.0

[probonopd]

This is the message I get when I try to double click the AppImage on my "somewhat unusual" system.

The good thing is: It definitely shows signs of life, as that message seems to be coming from .net. And indeed, running it on the command line gives:

Users-Laptop% uname -a
FreeBSD Users-Laptop 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64

Users-Laptop% runappimage ~/Downloads/HelloWorld.x86_64.AppImage
AppRun                                  zone.kuiper.helloworld.desktop
usr                                     zone.kuiper.helloworld.svg
zone.kuiper.helloworld.appdata.xml
HelloWorld
Version: 3.2.1.0
Build: RELEASE

Args: 
GetCurrentDirectory: /tmp/appimage.r7K6P5iY
AppDomain.CurrentDomain.BaseDirectory: /tmp/appimage.r7K6P5iY/usr/bin/
Assembly.GetEntryAssembly().Location: /tmp/appimage.r7K6P5iY/usr/bin/HelloWorld.dll

Packaged subdir exists: True
Packaged subdir/file.test exists: True
If the above is 'True', it indicates the PostPublish build script was run during the build

CUSTOM_FLAG NOT defined
pupnet was NOT called with: --property DefineConstants=CUSTOM_FLAG


Press any key to finish

So I guess we can count that as a success: PupNet-Deploy made AppImage is running on FreeBSD based helloSystem.

[kuiperzone]

Can you launch it from the command line, rather than double clicking from a file manager?

It's the very last line of the program that's causing a problem which is only in there for Windows. So I could tweak and remove it.

BTW -- your FreeBSD project looks interesting. How does it fair with device compatibility? Say, like a printer or scanner or camera?

[probonopd]

Can you launch it from the command line, rather than double clicking from a file manager?

Yes, then it gives the messge above (ends with "Press any key to finish").

BTW -- your FreeBSD project looks interesting. How does it fair with device compatibility? Say, like a printer or scanner or camera?

I have all of the above working, but I do tend to specifically pick my hardware for compatibility.

[kuiperzone]

Updated so you shouldn't see the error:

https://github.com/kuiperzone/PupNet-HelloWorld/releases/tag/v1.0.1

However, there shouldn't have been a problem anyway, although it wasn't down to any bug in the code. I'm not sure what FreeBSD means in terms of compatibility with Linux apps? I know that you use it as a test bed for the AppImage catalogue and I've previously had a .NET app accepted into it.

[probonopd]

Now I see when running on the command line:

usr                                     zone.kuiper.helloworld.svg
zone.kuiper.helloworld.appdata.xml
HelloWorld
Version: 1.0.1.0
Build: RELEASE

Args: 
GetCurrentDirectory: /tmp/appimage.dzhP7SYx
AppDomain.CurrentDomain.BaseDirectory: /tmp/appimage.dzhP7SYx/usr/bin/
Assembly.GetEntryAssembly().Location: /tmp/appimage.dzhP7SYx/usr/bin/HelloWorld.dll

Packaged subdir exists: True
Packaged subdir/file.test exists: True
If the above is 'True', it indicates the PostPublish build script was run during the build

CUSTOM_FLAG NOT defined
pupnet was NOT called with: --property DefineConstants=CUSTOM_FLAG

Is this how it should be?

Do you have a GUI app for testing?

I'm not sure what FreeBSD means in terms of compatibility with Linux apps?

FreeBSD has a Linux compatibility layer called the "Linuxulator", and I am using it together with a small Debian runtime to run AppImages. At this point, this is more my personal experimentation than anything.

I know that you use it as a test bed for the AppImage catalogue and I've previously had a .NET app accepted into it.

Actually, appimage.github.io (currently) tests AppImages on the latest still-supported LTS release of Ubuntu.

[kuiperzone]

Is this how it should be?

It's not an error. Rather it is a feature test. The app is merely detecting a flag that may (or not in this case) be passed from the command line during the build process. It allows apps to be released with polymorphic behaviour which is defined at "package build time".

The AppImage demo was built with:

pupnet -k appimage

To pass a "CUSTOM_FLAG" (the C# equivalent of a #define):

pupnet -k appimage --property DefineConstants=CUSTOM_FLAG

I'll release a GUI demo shortly.

[kuiperzone]

Q. Is there much call for arm64 AppImages?

If I provide a GUI demo built for Arm, can you test it and ensure that it runs for me?

[probonopd]

Sure, I'd run it on a Raspberry Pi with Raspberry Pi OS.

[kuiperzone]

There's aarch64 AppImage here: https://github.com/kuiperzone/PupNet-HelloWorld/releases/tag/v1.0.1

[probonopd]

As you can see when you run file ... on your "aarch64" file, the AppImage runtime is a x86_64 binary. Hence it can't run on an ARM 64-bit machine.

[probonopd]

As soon as you embed an actual aarch64 AppImage runtime, e.g., the one from https://github.com/AppImage/type2-runtime/releases/tag/continuous, then it works:

[kuiperzone]

Thank you for the reply. But...

As you can see when you run file ... on your "aarch64" file, the AppImage runtime is a x86_64 binary.
and
As soon as you embed an actual aarch64 AppImage runtime

I don't know what this means? How does one embed an aarch64 runtime?

I followed the procedure for building an AppDir, and populating usr/bin with a dotnet build for linux-arm64.

I then set the environment variable:

ARCH = arm_aarch64

According to https://discourse.appimage.org/t/how-to-package-for-aarch64/2088

and ran the following to call appimagetool and build the package:

./appimagetool-x86_64.AppImage "/tmp/KuiperZone.PupNet/zone.kuiper.helloworld-linux-arm64-Release-AppImage/AppDir" "/mnt/DEVEL-1T/DOTNET/GITHUB/PupNet-HelloWorld/Deploy/bin/HelloWorld.aarch64.AppImage"

If you could be so kind as to tell me what I need to do to create a runnable arm64 AppImage, it would be much appreciated.

Andy

PS. My working assumption here is that it is possible build an arm64 AppImage on an x64 box? Is this valid?

[probonopd]

Sure @kuiperzone. An AppImage consists of two parts: a compressed filesystem image ("disk image"), and a small application that mounts that image when the AppImage is executed ("the runtime").

If you would like to make an AppImage that can run on aarch64 machines, then both the contents of the image and the runtime must both be aarch64.

What AppImageKit's appimagetool does is basically append (copy) the filesystem image to the end of the runtime. The combined file is the AppImage.

It appears that setting ARCH=aarch64 results in AppImageKit's appimagetool using the aarch64 architecture for the filename, but it doesn't result in another runtime being embedded into the AppImage.

For that, one needs to tell appimagetool to use an aarch64 runtime by using ARCH=aarch64 appimagetool --runtime-file=./runtime-aarch64, which was downloaded before from e.g., https://github.com/AppImage/AppImageKit/releases/download/continuous/runtime-aarch64.

This way, an aarch64 runtime gets embedded into the AppImage.
This is not necessary if the host system itself is aarch64, because then appimagetool comes with and uses that runtime by default.

The same is also true the other way around (e.g., an ARM user trying to make an AppImage for Intel).

Hope this makes sense.

[probonopd]

The differing CPU arch conventions are very confusing.

Couldn't agree more. I don't get why people can't even agree on things like names for architectures. In any case, the most common name for 64 bit ARM seems to be aarch64, and it is what we are using.

I'm guessing that PupNet will have to carry multiple runtimes with it so, for example, it will be possible to build an Arm64 image on a x64 machine out of the box?

Exactly.

When can we expect an update to "appimagetool"? Will there be any breaking changes?

Nothing planned from my side at this time.

And on the subject of confusing arch conventions, the following AppImage is for 32-bit intel CPUs? Is this correct?

i686 is 32 bit Intel, yes.

[probonopd]

Follow up. You asked about a GUI app created with PupNet deploy. See here: https://github.com/kuiperzone/AvantGarde/releases/tag/v1.1.0

Out of sheer curiosity, I ran it on helloSystem. Seems to run into some unhandled exception there?

[probonopd]

On Ubuntu LTS, getting

AppImage/appimage.github.io#3133

[kuiperzone]

Follow up. You asked about a GUI app created with PupNet deploy. See here: https://github.com/kuiperzone/AvantGarde/releases/tag/v1.1.0

Out of sheer curiosity, I ran it on helloSystem. Seems to run into some unhandled exception there?

Would have been nice if it ran, but I'm sure if I submitted a bug report to the Avalonia team, they would tell me that Avalonia is not supported on FreeBSD.

Looks OK on Ubuntu.

I'll produce an update to PupNet shortly so that it can create an Arm64 build.

[kuiperzone]

Found these in connection with Avalonia on FreeBSD. Not possible at moment by looks of it, but may be in the future.

fsprojects/Avalonia.FuncUI#280
AvaloniaUI/Avalonia#6990

[kuiperzone]

Hi @probonopd ,

Just a little interim follow up. I'm in the process of updating PupNet, and think it would be good to have a record on the web for this.

You wrote previously (above) that I should set: ARCH=aarch64.

This is incorrect, or at least it doesn't work. Rather, the last poster seems to be correct here: https://discourse.appimage.org/t/how-to-package-for-aarch64/2088

Must set:

ARCH=arm_aarch64 (for arm64*)

and

ARCH=arm (not armhf for arm (32))

(*) Why the developer felt the need to invent yet another convention for arm64/aarch64, I've no idea? Was it you? :)

Moreover, given that I am now explicitly specifying the runtime and the output filename, not sure why I need to supply the arch? But it doesn't work unless I do so, as above.

[probonopd]

I have to admit that when it comes to architecture names, I am at least as confused as everyone else.

[kuiperzone]

Hi @probonopd

I have to admit that when it comes to architecture names, I am at least as confused as everyone else.

This is bothering me and has bothered me ever since I saw the previous discussion: https://discourse.appimage.org/t/how-to-package-for-aarch64/2088

I almost let this go, but feel I must ask. Sorry for being a PITA:

Your copyright is on appimagetool. You wrote it? How come you don't seem to know what it accepts for valid CPU architectures?

Or is it simply calling on some other third-party component somewhere?

[kuiperzone]

@probonopd

I've built a new HelloWorld.aarch64.AppImage file, plus a 32-bit armhf file. You can get them here:

https://github.com/kuiperzone/PupNet-HelloWorld/releases/tag/v1.0.1

This time, I've explicitly set the runtime, like so:

/opt/zone.kuiper.pupnet/appimagetool-x86_64.AppImage --runtime-file="/opt/zone.kuiper.pupnet/runtime-fuse2-armhf" "/tmp/KuiperZone.PupNet/zone.kuiper.helloworld-linux-arm-Release-AppImage/AppDir" "/mnt/DEVEL-1T/DOTNET/GITHUB/PupNet-HelloWorld/Deploy/bin/HelloWorld.armhf.AppImage"

It would be great to know if these work?

Cheers

[probonopd]

This is happens when I run the aarch64 one on Raspberry Pi OS:

user@raspberrypi:~ $ Downloads/HelloWorld.aarch64\ \(1\).AppImage 
HelloWorld
Version: 1.0.1.0
Build: RELEASE

Args: 
GetCurrentDirectory: /home/user
AppDomain.CurrentDomain.BaseDirectory: /tmp/.mount_HelloWaPIJei/usr/bin/
Assembly.GetEntryAssembly().Location: /tmp/.mount_HelloWaPIJei/usr/bin/HelloWorld.dll

Packaged subdir exists: True
Packaged subdir/file.test exists: True
If the above is 'True', it indicates the PostPublish build script was run during the build

CUSTOM_FLAG NOT defined
pupnet was NOT called with: --property DefineConstants=CUSTOM_FLAG

[kuiperzone]

Looks good!

[probonopd]

I am never sure whether what I see is an error message or whether it is the intended output of the application. But if you are happy, so am I :)

[kuiperzone]

Q. What if I added the ability to PupNet to convert RPM,deb, flatpacks to AppImage?

Would this be useful? Has it been thought about? Is it even possible?

Is there an existing converter? I know about Alien, but this only converts between deb and RPM, if I am correct.

I'm not saying I have the time to do this, but I might if I am at a loose end some time.

[probonopd]

It's an approach that tends to low-quality AppImages, since the original application author is usually not involved and people who don't know the inner workings of an application do the conversion, and then no one knows what to do if has bugs. So from my experience, that approach should not be promoted.

AppImage is a format designed to allow the original authors of applications to distribute their software directly to end users without any intermediaries. It also allows them to control all aspects of the software stack, so that they can support their application themselves. That's what it is for, and that's what it is best suitable for.

[kuiperzone]

I think you are quite correct on reflection.

[kuiperzone]

Dooh!

TheAssassin is going to tell me I should have done a search first! :)

https://appimage.github.io/deb2appimage/