Continuous integration testing

[anko]

Continuous integration testing

[anko]

And then I went on an epic odyssey of dealing with dumb build details on the travis-smoketest branch.

Angry notes I took on this arduous journey

• I had the webkit package wrong, so I changed it.

• That one was wrong too. I realised I need a webkit2gtk package and Travis doesn't have those, so I added a PPA that provides it.

• Then turns out various gdk_ functions aren't imported. (Why not? They work no problem on my Arch and Void boxes. I don't understand. But whatever, I added an explicit #include <gdk/gdk.h>, since docs confirm that's where those live.)

• Same error wtf. No complaints about the #include <gdk/gdk.h>, so it must have found it, but for some reason gdk_display_get_n_monitors etc still aren't available?

• So I added #include <gdk/gdkmonitor.h>, which should contain all of the things it's not seeing. None of the documentation mentions this, but I found some GTK internals (through Googling everything I could think of) that import it this way. It's annoyingly extraneous on my Arch machine, but it works...

  At this point I noted that I'll have to consider at the end whether I've created a maintenance nightmare greater than the one I'm supposed to be fixing. 🤔

• Excusemewhat, there's no <gdk/gdkmonitor.h>? That explains multiple problems I've been having, but why? It's right there in the libgtk-3-dev filelist, and it's certainly there on every install that I've seen. But not on the Travis test server. 🤷‍♂️ I can't find any other package that might provide it instead—everything just says it's in libgtk-3-dev. But as demonstrated, it's not.

---

At this point I decided to give up.

Part of me wants to throw my laptop off a bridge and become a farmer.

[anko]

OK mystery solved.

I found this solus-project/budgie-desktop#862 (comment):

What GTK version ubuntu 16.10 have? GdkMonitor is 3.22 only thing, AFAIK.

It seems indeed GdkMonitor was added in GNOME/gtk@8372448 for 3.22.

And Ubuntu trusty has:

3.10.8-0ubuntu1.4

So the functions we're using don't exist in the version of GTK available on the Ubuntu that Travis defaults to, and that's why stuff is missing! 🎉

---

Travis only supports up to Ubuntu xenial with a flag, but even that has only GTK 3.18. The earliest Ubuntu version that has GTK 3.22 is bionic, which Travis doesn't support yet.

There are ways of hacking around it to add a newer Ubuntu's apt source and install something from it, but it sounds fragile, and this branch is already a glass shop as-is.

Keeping closed.

(Wake me when Travis updates to Ubuntu bionic. 💤)

[anko]

Wake me when Travis updates to Ubuntu bionic. 💤

Wakey wakey! The future is here. Travis has Bionic now.

[anko]

The adventure continues. Here is the tale of da9e694...8e294e1:

After some fighting with Travis to get it to pick up the webkit PPA (because we need the package libwebkit2gtk-4.0-dev, but it's not whitelisted by Travis), I figured out that the PPA doesn't actually have a distribution for Ubuntu Bionic, which is why the build can't find it. Argh.

But turns out we don't even need the PPA anymore. The reason for having to get the package via a PPA was because it wasn't on Travis' package safelist. But the safelist only applies to the old Docker container architecture they were using. And we're on a proper sudo: require container architecture already, so the safelist filter doesn't apply, and all the packages are just available! 😮

So after /usr/bin/enving the bash path to accommodate for where Ubuntu likes to put it, the test actually ran for the first time! 🎈

And the result is a fail. Turns out the composite extension is not enabled in the virtual framebuffer, so the window had no transparency, and so the pixel colour didn't match. It works on my local machine, and the Xvfb line does specifically ask to enable composite, but I'm clearly missing something. I'll get around to debugging that Soon™.

[anko]

I changed the Xvfb flag to capitalise Composite to the way that it wanted, so Xvfb is now happy, but Metacity still thinks the extension is missing, so it won't start in compositing mode. 💫

Mysteriously, the test continues working perfectly on my own machine. Adding to the mystery, replacing metacity with compton has the opposite problem: compton starts without complaint inside Xvfb, and reports to Hudkit that compositing is enabled, but the test fails!

[anko]

compton starts without complaint inside Xvfb, and reports to Hudkit that compositing is enabled, but doesn't actually provide any compositing

I was wrong. I checked in Xephyr, and apparently compton was just setting the X root window background to grey for some reason. That's easily fixed with a hsetroot. Which is nice, because the test now works with compton, which is a lighter dependency than metacity.

However, in Travis-land, compton still didn't see the composite extension. This stumped me, so I did some reading, and found a forum thread from 2008 where Rémi Cardona says (emphasis mine)—

As far as Xvfb is concerned, I stepped line by line through CompositeExtensionInit in composite/compext.c and found that Xvfb defaults to 8bit PseudoColor

Forcing Xvfb with "-screen 0 1280x1024x24" allowed Composite to work correctly.

Checking man Xvfb on my system reveals it already defaults to "1280x1024x24" nowadays. However, Ubuntu bionic's Xvfb man page says it defaults to "1280x1024x8". That would explain why it worked on my machine but didn't on Travis.

Either way, I added a flag to override that dumb default in 9cad2c8 and—

✨ —it works! ✨

---

Instead of squashing this mess, I think I'll just yolomerge the branch --no-ff, so the commits stick around for future reference. Dear future maintainer, you're welcome.