snapcraft.yaml: build on 22.04

[valentindavid]

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 78.92%. Comparing base (5fa9b1b) to head (e6d7dc1). Report is 9 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #13370      +/-   ##
==========================================
+ Coverage   78.90%   78.92%   +0.01%     
==========================================
  Files        1043     1043              
  Lines      134350   134431      +81     
==========================================
+ Hits       106013   106099      +86     
+ Misses      21723    21720       -3     
+ Partials     6614     6612       -2     

Flag	Coverage Δ
unittests	78.92% <100.00%> (+0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[valentindavid]

@bboozzoo

That's orthogonal to this branch, but perhaps we should think about reorganizing tests a little now. We have a workflow which builds the snapd snap from the branch. Perhaps instead of having the tests repack the snapd snap again in prepare, we could simply download that artifact and use it for running the test suite. This would be closer to how the snapd snap is used in practice.

I have https://github.com/snapcore/snapd/pull/13517 for now to test with a proper snapd snap instead of the repacked snap. But yes, having a CI artifact we download from the tests would be great.

[zyga]

The resulting snap ships a broken symlink to the dynamic linker:

zyga@ciri:~/Canonical/snapd/squashfs-root/lib$ ll
total 12
drwxr-xr-x 3 zyga zyga 4096 kwi  3 12:45 ./
drwxr-xr-x 7 zyga zyga 4096 kwi  3 12:45 ../
lrwxrwxrwx 1 zyga zyga   39 sty  2 13:22 ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-linux-aarch64.so.1
drwxr-xr-x 3 zyga zyga 4096 kwi  3 12:45 systemd/

[zyga]

Looking at the binaries I see they request the following dynamic linker:

      [Requesting program interpreter: /snap/snapd/current/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1]

How is that going to work on, say, Fedora, where /snap is not present? Do we always invoke them with the dynamic linker? Could we use $ORIGIN for that (I don't know if $ORIGIN is respected for this path.

[valentindavid]

How is that going to work on, say, Fedora, where /snap is not present? Do we always invoke them with the dynamic linker?

You need to have at least a symlink. I think we should not enable re-execution if /snap does not exist.

Could we use $ORIGIN for that (I don't know if $ORIGIN is respected for this path.

$ORIGIN is something handled by the dynamic linker itself, not the kernel. So you can use it in the path to the interpreter, since the interpreter has to be loaded.

[zyga]

How is that going to work on, say, Fedora, where /snap is not present? Do we always invoke them with the dynamic linker?

You need to have at least a symlink. I think we should not enable re-execution if /snap does not exist.

Thanks, I think this makes sense.

Could we use $ORIGIN for that (I don't know if $ORIGIN is respected for this path.

$ORIGIN is something handled by the dynamic linker itself, not the kernel. So you can use it in the path to the interpreter, since the interpreter has to be loaded.

Right, sadly this is not something that the Kernel supports so well.

[valentindavid]

zyga@ciri:~/Canonical/snapd/squashfs-root/lib$ ll
[...]
lrwxrwxrwx 1 zyga zyga   39 sty  2 13:22 ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-linux-aarch64.so.1

That link should not exist at all. It just happen not to be there when there is lib64, but I forgot when it does not exist. I will remove it.

[valentindavid]

zyga@ciri:~/Canonical/snapd/squashfs-root/lib$ ll
[...]
lrwxrwxrwx 1 zyga zyga   39 sty  2 13:22 ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-linux-aarch64.so.1

That link should not exist at all. It just happen not to be there when there is lib64, but I forgot when it does not exist. I will remove it.

It should be fixed.

[valentindavid]

+1 on merge but perhaps -1 on merge for 2.63 unless we absolutely have to.

We are waiting on releases from bases anyway, so we should not merge it right now.

[valentindavid]

Ah! Nobody saw it. Oops. But I was building glibc unpatched. I have just fixed it.