AppImage build fails

Question

AppImage build fails

Frenzie opened this issue 6 years ago · 9 comments

@NiLuJe I assume it's probably related to some of your recent changes. :-P

https://gitlab.com/koreader/nightly-builds/-/jobs/95161017

appimagetool: error while loading shared libraries: libcairo.so.2: cannot open shared object file: No such file or directory

Answer 1 · 2018-09-08T06:02:04.000Z

PS I now manually added the both of us under Project → Settings → Integrations → Pipelines emails so these things shouldn't fly under the radar in the future anymore.

By default GitLab only tells you about pipelines you triggered yourself.

Answer 2 · 2018-09-08T13:01:30.000Z

Huh. Nothing we build should pull in Cairo :?

…

On Sat, Sep 8, 2018, 08:02 Frans de Jonge ***@***.***> wrote: PS I now manually added the both of us under Project → Settings → Integrations → Pipelines emails so these things shouldn't fly under the radar in the future anymore. By default GitLab only tells you about pipelines you triggered yourself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#730 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG1ZuMkuzDhOT-3OzyuIRbQYIBsV8nmks5uY11cgaJpZM4Wfu0F> .

Answer 3 · 2018-09-08T13:41:54.000Z

That just looks like a missing runtime dep for AppImageKit in the build env to me... Why it popped up just now while it's pretty much depended on Cairo forever beats me, though.

…

On Sat, Sep 8, 2018, 15:01 NiLuJe ***@***.***> wrote: Huh. Nothing we build should pull in Cairo :? On Sat, Sep 8, 2018, 08:02 Frans de Jonge ***@***.***> wrote: > PS I now manually added the both of us under Project → Settings → > Integrations → Pipelines emails so these things shouldn't fly under the > radar in the future anymore. > > By default GitLab only tells you about pipelines you triggered yourself. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#730 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAG1ZuMkuzDhOT-3OzyuIRbQYIBsV8nmks5uY11cgaJpZM4Wfu0F> > . >

Answer 4 · 2018-09-08T15:32:48.000Z

Well, not exactly "forever", but circa end of January 2017.

Answer 5 · 2018-09-08T16:32:34.000Z

Oh you're right, I only glanced at it since I was focused on other things and didn't realize it was after the build process.

The simple fix might be to switch to the 1.0 release? I don't really feel like updating the Docker image for something simple like that atm, lol.

https://github.com/koreader/koreader/blob/2eabf1dfac0b95de7208308c0d71b22af8efb113/Makefile#L48

Answer 6 · 2018-09-08T16:40:50.000Z

To be perfectly fair, I did break AppImage recently ^^. But that was fixed in #722

(That was after having broken Ubuntu Touch & fixed it in #721 :D).

Answer 7 · 2018-09-08T16:42:06.000Z

I just figured Cairo was a dep for MuPDF or something; I don't really know what the command-line AppImageKit tool would even need that for.

Answer 8 · 2018-09-08T16:42:43.000Z

Yeah, switching back to the latest release should do the job.

The culprit appears to be the libappimage related commits (AppImage/AppImageKit@310bcd0), because that appears to be where the cairo dep comes from.

Answer 9 · 2018-09-08T16:48:01.000Z

Don't cross the streams! :D