Support of arm64 (#563)

[sbernhard]

No description provided.

[probonopd]

Thank you very much @sbernhard. What did you test it with?

[sbernhard]

I have build the pkg2appimage on a arm64 system. Then I tried to build a app from the default recipes folder. Unfortunately, I can not remember. I want to continue with this next week.
Luckily, I saw this: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/
Therefore I extended this PR to build pkg2appimage directly on github for arm64 and x86_64.
I guess, if you would approve this PR, then the github actions would start and we can easily proceed. I would the continue with more testing of course.

[probonopd]

Indeed, that's great news.
Strangely it doesn't seem to be working yet. Maybe it's already overloaded?

[sbernhard]

ah, it was just a issue how to construct to build on arm vs amd64. now it works. Thanks for the approval.

[sbernhard]

Would it be somehow possible to add a "test" step directly after the build? like, use the created pkg2appimage to create a simple recipe and then run it?

[probonopd]

Yes, I think that would be a good idea. Use the generated AppImage to make another AppImage using a simple recipe.

We should do it in dogfeeding.sh which is based on the idea of "eating our own dogfood".

[probonopd]

Hm. Seems like using the short git hash as the version is not working yet (was broken already before this PR). Can you spot what is going wrong?

[sbernhard]

Hm. Seems like using the short git hash as the version is not working yet (was broken already before this PR). Can you spot what is going wrong?

Is it about setting the TRAVIS_BUILD_NUMBER?
See my last commit.

[sbernhard]

Yes, I think that would be a good idea. Use the generated AppImage to make another AppImage using a simple recipe.

We should do it in dogfeeding.sh which is based on the idea of "eating our own dogfood".

I added it as a seperate test in the github action. Addtionally, I added neovim as a very simple AppImage which can be easily tested.

[probonopd]

Travis is long history. We should remove all mentions of TRAVIS_BUILD_NUMBER and replace it by VERSION.

[sbernhard]

Just saw, that you throw away the travis stuff @probonopd. Therefore, I have removed the VERSION / git commits from this PR - I hope this was correct? Thought this was the changes you did with the other PR you have already merged today.

I have rebased this PR and adapted it again. I guess, the test shoud now run - or, at least one step further :)

[probonopd]

Looks like that neovim is too new?

[sbernhard]

Hmm, lets try to use ubuntu focal instead of noble.

[sbernhard]

I hope it works now @probonopd

[sbernhard]

can you start the github pipeline again, please @probonopd

[probonopd]

What is lua being used for?

[sbernhard]

What is lua being used for?

Something in neovim requires lua-luv

[probonopd]

Let's remove neovim then. The debian packager "hello" should do?

[sbernhard]

@probonopd yes, shell script would also somehow work - but this would be a new story somehow and I thought, it's easier to have quick test of a somehow up-to-date package.

I changed the neovim recipe again. hope that it works now. actually, I would be much easier, if this PR approval to run the pipeline would not be necessary. (sorry for this hassle)

[probonopd]

Can't we use

https://packages.debian.org/unstable/hello

instead of neovim? I don't feel comfortable drawing in new dependencies.

[sbernhard]

@probonopd Yes, I have changed this.