Etcher: [Request] etcher flatpak via flathub

[Tids]

Hi.
It would be nice to have a flatpak of etcher available on flathub. So it would be included in many linux distros by default (and even more, when KDE discover also shipps flatpak support with the next release). That way we could just install it, without googling around how to get it.
++you dont have to care about the base OS, since it would be always the same runtime on all systems.

[lurch]

Do the current AppImages not work properly for you?
We're currently using electron-builder to create our Etcher packages (including AppImages, debs and rpms), and that doesn't yet support creating flatpaks.

Last time I looked (which was admittedly quite a while ago) flatpaks were supported on fewer distros than AppImages. (e.g. flatpak is only for Ubuntu 16.04 and newer whereas our AppImages work on Ubuntu 12.04 and newer)
Also, it looks like flatpaks require you to install the flatpak command first, whereas AppImages "just run" with no other packages needing to be installed? *shrug*

[Tids]

Do the current AppImages not work properly for you?

I dont know if it works. Thing is that appimages are hard to manage. You need to download them from somewhere and do all that stuff manually. I really dont want to start with that. It seems that they also dont provide delta-updates or an updating service. And I dont want to download the whole "pack" just because there is a security update in some of its libs, or they simply dont ship security updates because of that reason.. So I would keep the AUR instead of appimages (and AUR is already a pain to use).

Yes flatpak requires the flatpak command and (if you want to) a graphical frontend. It also requires Internet

[lurch]

Well I guess different people want different things - some people find the "download a single file and run it" approach much easier.

We'll consider adding flatpaks if / when electron-builder supports them.

[Tids]

Thanks :)

[Pointedstick]

AppImages work fine for me, but I too would like to see a Flatpak package on Flathub because of the same reason as @Tids: AppImage packages are a pain in the butt to manage on Linux. The usage model ("download from random website, put it wherever you want, double-click to open") is totally different from the typical Linux approach and doesn't integrate well with existing tools, workflows, or user expectations. Linux users are _heavily_ discouraged from downloading and running binaries from the Internet, in favor of using their package manager or graphical app store. Also the AppImage format is inherently un-user-friendly in that the user has to manually make the package executable first, which is an advanced task (even though it seems easy to people like us) that most regular users will fail at.

[lurch]

in favor of using their package manager

Just as an FYI, we do provide .deb and .rpm packages https://github.com/resin-io/etcher#debian-and-ubuntu-based-package-repository-gnulinux-x86x64
(but this obviously doesn't cover the plethora of different packaging formats that various Linux distros use)

Also the AppImage format is inherently un-user-friendly in that the user has to manually make the package executable first, which is an advanced task (even though it seems easy to people like us) that most regular users will fail at.

That's why we distribute our Etcher AppImage files inside zipfiles - when the user extracts the AppImage from the zip, the executable bit is preserved (already set) :slightly_smiling_face:

[HoboPrimate]

My comment on a duplicate issue:

I believe flatpaking eletron apps is still a work in progress, but doing it would give the user advantages, such as peace of mind of it being sandboxed and allow them to update etcher easily. It would also make etcher be more discoverable if hosted on flathub.org.

Consider this just a small wish, as the appimage version seems to works fine!

[ghost]

I can't make AppImages work no matter what I do, a flatpak image would be nice, BUT....
Being able to build-from-source is always more preferable. Its a shame electron isn't supported by Void MUSL.
I hear that flatpak/appimages/etc aren't very good because of the different runtime libraries, but I don't know much about that.

[kenny-w1]

Hey guys, I found this on github, I wonder if this would help get etcher on flatpak? If electron is there then it should work.. right?
https://github.com/endlessm/electron-installer-flatpak

I find flatpak to be far more convenient, I can just update all my flatpak apps with a single command, I prefer it to be that way.

[kenny-w1]

Flatpak on twitter posted this, about electron:
https://twitter.com/flatpakapps/status/887729426372415489
(direct link to what they posted)
http://blog.manuq.com.ar/posts/building-electron-apps-offline-for-flathub/

@lurch @jhermsmeier what do you guys think?

[dietrichstats]

That's why we distribute our Etcher AppImage files inside zipfiles - when the user extracts the AppImage from the zip, the executable bit is preserved (already set) slightly_smiling_face

@lurch Exactly that is one of the reasons why it is not very intuitive, since every many developers that use AppImage "try" to make their use easier and with that they break with the expected mode. I've even seen installation script associated with an AppImage.

AppImage is an excellent portable format, in the sense of portable Windows applications, but lacking integration with the most popular software stores in Linux makes it a problem, as even users unfamiliar with Linux will understand the dynamics of a software stores. On the other hand, I consider it a mistake that integrated GPG signatures or appimaged are optional stuff.

[lurch]

integration with the most popular software stores in Linux

https://github.com/resin-io/etcher#debian-and-ubuntu-based-package-repository-gnulinux-x86x64
https://github.com/resin-io/etcher#redhat-rhel-and-fedora-based-package-repository-gnulinux-x86x64

Can't please all the people all the time...

[dietrichstats]

https://github.com/resin-io/etcher#debian-and-ubuntu-based-package-repository-gnulinux-x86x64
https://github.com/resin-io/etcher#redhat-rhel-and-fedora-based-package-repository-gnulinux-x86x64

Can't please all the people all the time..

Dude, that was not necessary. You know well that I was talking about the AppImage package...

[lurch]

Sorry, didn't mean to cause any offence. (I couldn't tell from your comment if you were already aware that Etcher is already packaged in deb and rpm repos)

[jhermsmeier]

Thanks for all the info @Tids, @kenny-w1 – I think it's time to reevaluate our packaging choices and mechanisms. That'll likely take some time though, and the fragmentation among packaging schemes for Linux isn't helping.

[lurch]

Obligatory XKCD: https://xkcd.com/927/ :grinning:

[ghisvail]

I intend to give it a go (packaging io.resin.etcher as a Flatpak and distributing it via flathub).

[jviotti]

Let's close this for now. Happy to take contributions

[Jacalz]

Is there any news regarding this? I would absolutely love seeing Etcher on FlatHub and it would (in my opinion) be best if the core team took this on and updated it themselves. I don't mind if a user make makes the initial thing, but I think it would be best for the team to have it as a thing in their release process to update FlatHub too in order to make sure that it always is updated. 🙂

[thundron]

No news yet, we currently have no plans to take etcher on flathub; if anyone feels like doing this, please do as that will be more than welcome, we also have people maintaining the aur package for Arch Linux and adding yet another package type feels a bit too crowded imho. We already have AppImages and we would like that to stay the main cross-distro package when people need it, but again we're more than happy to take contributions if anyone feels like creating and maintaining a new package type!

[ghisvail]

I am on it as we speak :-)

Le mar. 14 mai 2019 à 09:54, Lorenzo Alberto Maria Ambrosi <
[email protected]> a écrit :

No news yet, we currently have no plans to take etcher on flathub; if
anyone feels like doing this, please do as that will be more than welcome,
we also have people maintaining the aur package for Arch Linux and adding
yet another package type feels a bit too crowded imho. We already have
AppImages and we would like that to stay the main cross-distro package
when people need it, but again we're more than happy to take contributions
if anyone feels like creating and maintaining a new package type!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/balena-io/etcher/issues/2019?email_source=notifications&email_token=AAO7U32QF2EGJAMZPDCAIB3PVJV2PA5CNFSM4EPKQC52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVKSUTY#issuecomment-492120655,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAO7U32YNSQP7WIN74RT2Z3PVJV2PANCNFSM4EPKQC5Q
.

[thundron]

@ghisvail If you need any help just ask!

[A6GibKm]

I can also help with the creation of the flatpak manifesto.

[ghisvail]

I have adapted the current Flatpak template for Electron apps but stumble upon the following issue when building etcher:

npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t ssh://[email protected]/resin-io/node-usb.git
npm ERR! 
npm ERR! ssh: Could not resolve hostname github.com: Temporary failure in name resolution
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128

npm ERR! A complete log of this run can be found in:
npm ERR!     /run/build/etcher/flatpak-node/npm-cache/_logs/2019-08-12T11_24_55_334Z-debug.log
Error: module etcher: Le processus fils s’est terminé avec le code 1

Looks like part of the build system still references the old path to the node-usb fork at github.com/resin-io/node-usb.git, instead of github.com/balinea-io/node-usb.git.

Besides, the build system should probably be using an https url for node-usb instead of the git+ssh protocol.

[lurch]

@ghisvail Looks like https://github.com/balena-io-modules/node-raspberrypi-usbboot/blob/master/package.json#L31 might be to blame?
ping @zvin

[A6GibKm]

@ghisvail, could you share you progress? Try applying a .patch for that url, e.g. https://github.com/flathub/org.gnu.emacs.

[ghisvail]

could you share you progress?

I can't get etcher to build offline with the error reported above.

Try applying a .patch for that url

node-raspberrypi-usbboot gets pulled from npm so it's not as straightforward to patch as the main code base. I'd prefer the issue be fixed upstream instead of adding complexity to the Flatpak build system.

[zvin]

@ghisvail this should be fixed in v1.5.55

[mario-g98]

No news yet, we currently have no plans to take etcher on flathub; if anyone feels like doing this, please do as that will be more than welcome, we also have people maintaining the aur package for Arch Linux and adding yet another package type feels a bit too crowded imho. We already have AppImages and we would like that to stay the main cross-distro package when people need it, but again we're more than happy to take contributions if anyone feels like creating _and_ maintaining a new package type!

I don't see why you aren't releasing a flathub version. AppImage is almost useless as nobody likes going to a website and downloading a file in order to install/update software. Flatpak is being used more and more and it's supported by all main distros, so by releasing a flatpak version you have everybody covered.

[ghisvail]

AppImage is almost useless as nobody likes going to a website and downloading a file in order to install/update software.

Go tell that to anyone using a Mac. Different formats for different use cases.

so by releasing a flatpak version you have everybody covered

It is also the case for AppImage. Enabling AppImage and snap artefacts from an Electron project is one declaration away in a file. Flatpak is yet to have this level of integration and is therefore more work to maintain comparatively.

Next time you approach upstream developers with a similar request, please use a different angle and a different set of arguments.

[x80486]

Hey folks, I started this Flatpak adventure here, but there is no way Yarn can pull unbzip2-stream from etcher-sdk (https://github.com/balena-io-modules/etcher-sdk/blob/master/package.json#L71).

Is it possible for you to change unbzip2-stream into a usual version range within etcher-sdk?

[x80486]

In the meantime, building the Flatpak from .deb files _almost_ work – while not optimal, it will let you use the Flatpak application in rolling releases, since the AppImage rarely runs without installing another gazillion on dangling dependencies :rofl:

I'm currently getting an error (in the Chrome console) after finally providing libusb:

error Error: Unable to find pkexec or kdesudo.
    at test (/app/balenaEtcher/re…prompt/index.js:205)
    at /app/balenaEtcher/re…prompt/index.js:212
    at FSReqCallback.oncomplete (fs.js:165)

...any clues?

If someone wants to take over this one, I can finally send it to Flathub, try to get it done over there...and I can help from time to time, but I cannot be the (main) maintainer for this one :wink:

[thundron]

It's the package we use to elevate the flashing process, you need that as well

[x80486]

There is some conversation going on the Draft Pull Request that I created in Flathub; it would be nice if some developer(s) can clear that out to see if there is anything that can be done to get this going, otherwise we just call it a day 😎

[lurch]

AFAICT this is the conversation that @x80486 is referring to :stuck_out_tongue_winking_eye:

[thundron]

Thanks @lurch !
I gave an answer there, but to recap - this seems to be blocked with the current state of flatpak. Closing, hopefully there will be a chance to do it in the future with more flexibility