Call for testing: Snapcraft 4.0

snapcraft
33

I would like to know more about this use case for SNAPCRAFT_PART_SRC to be available during prime.

That said, SNAPCRAFT_PROJECT_DIR should be exported for stage and prime.

34

The part that uses this downloads some scripts that are run while priming to do some checks and generate metadata, it needs the env var to access the scripts.

I only see these env vars for base core 20 (no SNAPCRAFT_PROJECT_DIR either):

SNAPCRAFT_BUILD_INFO
SNAPCRAFT_BUILD_ENVIRONMENT
SNAPCRAFT_INTERPRETER

(well, and the first two is probably me exporting them)

35

4.0.2 is now on candidate with bug fixes, some of which were reported by you whom we thank for testing 4.0.

This point release might interest the following:

As LP: #1876260 is part of it.

2 Likes
36

I see the SNAPCRAFT_* variables back, thanks!

37

4.0.3 is now on candidate with bug fixes, some of which were reported by you whom we thank for testing 4.0.

This might be the last point release before promoting to stable

2 Likes
38

Need to bump multipass version once https://github.com/canonical/multipass/pull/1559 is merged to make snapcraft usable on Fedora.

See Docker images are broken for stage-packages

39

package-repositories should accept an HTTPS URL to fetch the key. It is common for third-party repositories to include a download path for the key instead of uploading to a keyserver.

2 Likes
40

Some issue were found which drove us to release Snapcraft 4.0.4 which is now on candidate.

41

I’m working on porting tdesktop to core20 and I have problems with dav1d:
image
If I set LD_LIBRARY_PATH manually - it works: https://github.com/ilya-fedin/tdesktop/blob/7aac2f7e4e0faffd2a342f16f0780ea26f0ce038/snap/snapcraft.yaml#L69-L70
Also, prefix isn’t set automatically anymore and all packages are installing in /usr/local by default, is this intended?

42

We will look into the issue of library paths.
As for prefix, that is indeed dropped for core20 (IIRC we did state it in the release notes, if not, I apologize). This brings some consistency across plugins with their defaults where for previous bases they were not.

43

Snapcraft is no on stable

1 Like
44

Thanks! Probably quite offtopic, but is there any chance that qtwayland private headers would be in ubuntu repositories (like qtbase5-private-dev, but for qtwayland)? It is quite weird to build an own copy of qtwayland just to get these headers. There are no such problems with flatpak.

45

I ran into some problems with the snapcore/action-build@v1 Github action once 4.0 was published to stable: I had been running sudo snapcraft, which it now complains about.

I’ve published a new release of the action that should fix those compatibility problems, now invoking Snapcraft as the CI user, after making sure they’re in the lxd group.

1 Like
46

I had a similar error today in my travis CI build for the cmake snap. The sudo snapcraft --lxd command is now rejected and the build fails. It’s not clear what the right way to deal with this is from the error message. If it is going to require adding the user to a group, that’s an extra hurdle that everyone is going to have to figure out for their specific CI setup.

47

Here’s the relevant change I made to the action:

The main changes are:

  1. add the CI user to the lxd group (see the usermod call).
  2. invoke Snapcraft with sg lxd -c snapcraft

I needed to use sg because I still have the user’s original set of groups.

1 Like
48

Looks like sg lxd -c snapcraft --use-lxd still doesn’t work. It does seem to work if you set the SNAPCRAFT_BUILD_ENVIRONMENT environment variable to lxd and drop the --use-lxd command line option. This seems like a regression.

49

You can also do

sg lxd -c 'snapcraft --use-lxd'

since sg doesn’t understand options to the command, you have to quote the options.

1 Like
50

The reason we implemented the sudo guard is because there is a constant stream of bug reports due to permission errors from folks (mis-)using sudo. Would it make sense to could skip this check if there is some common thread to support these cases (non-interactive tty?). Just a thought…

51

You will need to quote the part after -c. This is is basically an argument passed to /bin/sh -c .

The reason I used sudo in the GH action was because it was the path of least resistance to give Snapcraft access to LXD. The file permission issues are not so apparent because the VM the job is running in will be discarded soon after.

Running without sudo was a bit more involved, since we can’t just “log out and back in again” after adding ourselves to the lxd group. Granted it turned out not to be too difficult to get working, so maybe the sudo check will end up helping more than it hurts.

3 Likes
52

Given the commentary in this thread, it looks like more people are hitting the sudo error message. I guess the most common sequence of events is something along the lines of:

  1. User tries to run snapcraft
  2. User gets a “permission denied” error when Snapcraft can’t talk to Multipass or LXD
  3. User tries to fix it by running sudo snapcraft
  4. User gets a new error telling them not to use sudo

There’s two things to address hee:

  • at (2), the user needs guidance about how to gain access to Multipass/LXD the correct way. This should probably include (a) checking current credentials with os.getegid() / os.getgroups() along with checking what the credentials for a new login will be via grp.getgrnam().
  • users might still get to (4) if they adopted a sudo snapcraft workflow while using Snapcraft 3.x. We can’t as easily check current credentials in this state, but should be able to check whether the user needs to add themselves to the appropriate group.
1 Like