feature request: arm support
Please post a description of what you want. linuxdeploy can be built on ARM machines and runs there just fine.
provide arm binary
linuxdeploy cannot be built on ARM machines:
https://github.com/linuxdeploy/linuxdeploy/pull/112 :
--2019-12-14 11:08:46-- https://github.com/linuxdeploy/linuxdeploy-plugin-appimage/releases/download/continuous/linuxdeploy-plugin-appimage-armhf.AppImage
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 404 Not Found
2019-12-14 11:08:46 ERROR 404: Not Found.
https://github.com/linuxdeploy/linuxdeploy-plugin-appimage/pull/10 :
--2019-12-14 11:04:01-- https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-armhf.AppImage
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 404 Not Found
2019-12-14 11:04:01 ERROR 404: Not Found.
Is there any way to move forwards with the existing PRs? AppImage support on ARM would be super useful for our use case.
These PRs can not be merged because these PRs fails because these PRs have not been merged
Those PRs cannot be merged because the author is unresponsive, they go way too far and are mostly undocumented.
I don’t think those straightforward PRs need documentation
They are not really straightforward to me. You have changed file names, locations, all for no reason, etc. The central build script is gone completely, which is unacceptable, since it's been used to locally test/simulate CI builds, etc. etc. They are anything but straightforward, this is a false claim.
You have not got in touch beforehand and now this is a slight mess. I would've wanted to keep e.g., the main build script, it could've been modified to support ARM cross-builds, too. I maintain a certain style of CI setup across all the repositories I maintain, and your changes break with that. I have not had time to read through all changes and provide feedback on what changes need to be done in order to make the PRs ready-for-merge.
The circular dependency that breaks the CI is the least issue. It's not that I would tend to merge your PRs if that could be fixed today.
The least thing I want to do is offend you in any way, but I have to be very economical with my time since December. I am not happy with this situation, but since I have not been able to invest very much time in linuxdeploy, I barely get to work on other projects. ARM support would be nice to have, sure. If you're interested in fixing this, I might allocate some time later today to go through your changes again.
In general, sending huge PRs for issues for which you have not even posted a description which then just remove and rename things is not a good idea, @zaoqi. It's really better to first talk to each other.
I would be willing to fix and test any issues that come up
PR has been reviewed. There's a few changes required in order to be able to merge it, mainly adding some checks, changing a few names and restoring the central build script. Then it's merge-able.
The circular dependency with the AppImage plugin can be fixed by having me build the linuxdeploy-plugin-appimage AppImages locally once, then uploading them to GitHub and having Travis rebuild them then again. I know this is rather cumbersome, but I have been requested to bundle the AppImage plugin into linuxdeploy, which creates this dependency, unfortunately. Whenever you add builds, you have to sort this mess out then.
I see that build uses https://github.com/uraimo/run-on-arch-action
I haven't tried that one yet. I thought the way to go would be the docker/setup-qemu-action. With that one, I believe you'd need a single Dockerfile:
- Dockerfile
- FROM ubuntu:bionic
- Install Dependencies for linuxdeploy
The workflow to create the docker images (amd64, arm64, ...) from the single Dockerfile would be something like this example
Then the workflow to create the AppImages would be something like
-
matrix
- arch: [amd64], [arm64] [...]
-
container: linuxdeploy-build-environment-${{ matrix.arch }}:bionic
-
steps
-
checkout
-
build linuxdeploy
-
upload release/artifact
I'm not sure if that would be a lot simpler than how it's done in the PR. Though I see in the PR, the dependencies would have be downloaded each time.
Closing in favor of #175.