snap: switch to base core20

[gares]

This happens to fix missing icons in CoqIDE

[MSoegtropIMC]

Does the "core" selection has an effect on which versions of Ubuntu the snap runs?

In one of your commits on the mathcomp school I have seen an explicit request for adwaita - can you leave a few words on the different methods? Should we maybe do both (switch core +gtk and explicitly request adwaita?)

[gares]

Adding the package explicitly did have no effect. My guess is that the package is already in the core or in the extension, so it is not added to the image.

I could not find any info on there requirements implied by the choice of the base. In some sense I think it is orthogonal, it a file system image, you can run core20 on a fedora. There might be some nasty dependency on gnome on system stuff, but I checked and gnome-3-38 works on ubuntu 16.04, so I guess we are safe:
https://snapcraft.io/install/gnome-3-38-2004/ubuntu

I sincerely don't know why this change fixes the problem. So please double test it on your computer.
I'm wondering if we can do something like https://unix.stackexchange.com/questions/365268/how-do-i-take-a-screen-shot-of-my-xvfb-buffer and upload the screenshot as an artifact of the smoke test job.

[MSoegtropIMC]

I see, thanks! I am btw. quite sure that it did work fine on my computer (running Ubuntu 20.04 LTS) when I last tested it, but I am not sure if I tested it via the alias or via putting the executable into the path, probably the latter.

[MSoegtropIMC]

I guess this makes a difference in terms of if ti picks up a system provoded adwaita. GTK apss likely have a lot of heuristics to find stuff and it is far from clear to me how this works together with the snap file system especially when executables are not called via the alias.

[MSoegtropIMC]

But of course the snap should provide adwaita, and this is what should be picked up by CoqIDE.

[gares]

I do call coq-prover.coqide in all my tests.
I tried to figure out how to see the real file system the app runs in, eg trying to open a file from CoqIDE and see if I could open /usr/share/icons/ and I could not even open /usr/ so I'm not so sure how to debug these kind of issues.

[MSoegtropIMC]

I guess from a snap point of view it is a hack / stretch, but I actually prefer to put the snap image bin folder into my path and call the commands this way - with the patched I did to ocamlfind this works fine (as far as I tested it).

But indeed I should also test the aliases.

I am unsure what to recommend to users. Did you try mapping the bin folder into your PATH?

[gares]

Hum, /snap/bin is in your path by default, and aliases coqide -> coq-prover.coqide are the supposed way to run things,
there should also be a .desktop file which is read by the gnome-shell so that you can start CoqIDE from the GUI.

Looking inside /snap/xx/... is not how it is supposed to be used, IMO. If it works fine, but I don't think we should recommend it.

[MSoegtropIMC]

I meant looking into /snap/xx. For running coqide going via the snap link works reasonably well. I am not so sure about console usage of the coq ecosystem.

[MSoegtropIMC]

@gares : I restarted the snap job since it failed CI - if it fails again we need to look into it.

[MSoegtropIMC]

@gares : it failed again in the same way. So I there seem to be interactions between the snap base version and the host OS version. But strangely it is also Ubuntu 20 (20.04 LTS)

Any thought what I can do about this? I can't merge it if it kills CI.

[gares]

I did not see the failure because it is in a plugin I did not build.
It just seems one needs to install libstdc++SOMETHING-dev (eg SOMETHING=-10). Maybe it used to be there in the old image but not in the new one.

[gares]

if I'm right, then it should be a depext of z3 I guess

[gares]

I was wrong, the library is there... (ABI version 6). So I don't get why it is not found...

[MSoegtropIMC]

I will do some local tests today or tomorrow.

[gares]

Apparently on my Ubuntu stdc++6 is there for compat reasons, but you can't link against it, that is the .so symlink is only available from ABI 7 to 10:

libstdc++-10-dev: /usr/lib/gcc/x86_64-linux-gnu/10/libstdc++.so
libstdc++-7-dev: /usr/lib/gcc/x86_64-linux-gnu/7/libstdc++.so
libstdc++-8-dev: /usr/lib/gcc/x86_64-linux-gnu/8/libstdc++.so
libstdc++-9-dev: /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.so

I've pushed a commit with 7

[MSoegtropIMC]

@gares : can you please rebase this PR to main latest?

[MSoegtropIMC]

Hmm - still does not pass. I guess I should have a look with local builds.

[MSoegtropIMC]

@gares : do you remember which plugin build required libstdc++-7-dev?

[gares]

Z3