Debian and Rolling: Package AppImageLauncher

[star-buck]

If not packages by upstream (Manjaro or Debian Testing), we need our own packages and include it in next isos default: https://github.com/TheAssassin/AppImageLauncher

@ScarlettGatelyClark : upstream always prefered

[shadeslayer]

Doing packages for AppImageLauncher is going to be tricky, it does not use a conventional build system and embeds a copy of appimagekit in it's sources. We need to ask the maintainer to fix the build system before we proceed, otherwise we'll end up in the same mess as Ring KDE in the past.

[NuLogicSystems]

Already packaged and in the Netrunner repository for Rolling. Now binfmts compatible via the upstream systemd-binmfts pacman hook. I only needed to add one pacman hook of our own to remove the appimage binmft on uninstall.

[shadeslayer]

@NuLogicSystems PKGBUILD's are far more lenient when it comes to building things. Debian for eg. does not allow network access during builds. It also frowns upon embedded source copies. Which is why I think it makes sense to talk with upstream about cleaning up their build system before proceeding with this.

[star-buck]

Sure we can ask, go ahead.

[NuLogicSystems]

@shadeslayer, Assasins cmake already packages this for you. All you need to do is pull the correct continuous build's deb file: https://github.com/TheAssassin/AppImageLauncher/releases

Arch/Manjaro was the only thing that needed external packaging.

[shadeslayer]

@NuLogicSystems Debian doesn't accept random deb's. They only accept sources that can be built on their infrastructure against their archives.

[NuLogicSystems]

Assasin is using travis to build both deb and/or rpm's. I'm pretty sure travis is building the deb packages on debian. Why would cmake have this functionality, if debian doesn't accept the packages it produces?

[shadeslayer]

Yes, the deb's are built on Travis using cpack. I guess the reason behind cpack's existence is to make deployment for Developers easier. However, like I said before, Debian does not accept binary upload's, only source uploads, and then rebuilds the source on their infrastructure against their archive. This infrastructure is subtly different than the setup on Travis ( I don't know how Travis does builds, but debian for eg. uses chroot's ). In order for AppImageLauncher to be accepted in Debian, it needs to release a source tarball that complies with Debian's archive policy.

[NuLogicSystems]

Oh, you mean for the upstream Debian repositories. My bad, I was thinking for your Netrunner Debian repositories. PS: their is a source.tar.xz there as well, this includes even the external (appimage) sources.

[star-buck]

We need this in extras, not debian upstream for this package. On May 8, 2018 17:29, "Rohan Garg" notifications@github.com wrote:

Yes, the deb's are built on Travis using cpack. I guess the reason behind cpack's existence is to make deployment for Developers easier. However, like I said before, Debian does not accept binary upload's, only source uploads, and then rebuilds the source on their infrastructure against their archive. This infrastructure is subtly different than the setup on Travis ( I don't know how Travis does builds, but debian for eg. uses chroot's ). In order for AppImageLauncher to be accepted in Debian, it needs to release a source tarball that complies with Debian's archive policy in order for it to be accepted.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/blue-systems/netrunner-releases/issues/31#issuecomment-387443018, or mute the thread https://github.com/notifications/unsubscribe-auth/AAzRhu22bScrpIX_kPBJBkxyLxUosxU8ks5twbnTgaJpZM4TsV5c .

[shadeslayer]

The original ticket says Debian testing upstream, which is why I made the above comments.

However, our CI has similar requirements anyway, we've been down the path of git submodules before with Ring KDE and it led to a absolute mess. We should aid AIL to fix their build system and then package appimagekit and AIL.

[star-buck]

Okay, please go ahead.

[ScarlettGatelyMoore]

I was looking into starting appimagekit to get a head start on this, unfortunately the packaging has been claimed in debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854902 So if I were to package it, it couldn't be put in debian archives.

[shadeslayer]

That is merely a ITP, a year old one at that. I think if you package it, Debian would be open to having it in their archives.

[ScarlettGatelyMoore]

Yeah, being a good collaborator and all, I have sent a query to the ITP. I will start on it anyway. Though, heads up, I tried helping probono on this back in my appimage days and ran into issues with him embedding network calls. Hopefully he has resolved that.

[ScarlettGatelyMoore]

UPDATE: While I did make some progress with the Appimagekit-continuous pre release, there are still 2 of 6 external packages brought in with git submodules/ git clones. When I get back from vacation I will try to work with probono to get these worked out. The previous packager also ran into these problems and gave up. Obviously he was happy to hand it over..

[ScarlettGatelyMoore]

Hi, @shadeslayer I thought I saw in your meeting notes you packaged this?

[shadeslayer]

Only via cpack as a workaround for now. We need a proper package for this in the long term

[ScarlettGatelyMoore]

ack

[star-buck]

@NuLogicSystems : do we ship this in rolling?

[NuLogicSystems]

It's "maintained" upstream Manjaro by philm, but yes, it's shipped on the ISO.

[ScarlettGatelyMoore]

There seems to be 2 issues on this - see my notes on https://github.com/blue-systems/netrunner-releases/issues/68