Some issue were found which drove us to release Snapcraft 4.0.4 which is now on candidate.
I’m working on porting tdesktop to core20 and I have problems with dav1d:
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?
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.
Snapcraft is no on stable
1 Like
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.
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
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.
Here’s the relevant change I made to the action:
The main changes are:
- add the CI user to the
lxdgroup (see the usermod call). - 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
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.
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
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…
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
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:
- User tries to run
snapcraft - User gets a “permission denied” error when Snapcraft can’t talk to Multipass or LXD
- User tries to fix it by running
sudo snapcraft - 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 viagrp.getgrnam(). - users might still get to (4) if they adopted a
sudo snapcraftworkflow 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
Sorry for not testing/reporting this earlier: the chromium snap fails to build with snapcraft 4.0.4 on the Launchpad builders.
This is because Launchpad sets up a proxy to allow the build to access the internet for a limited amount of time, and chromium takes a very long time to build (typically 8+ hours on amd64, and much longer on other architectures).
chromium’s snapcraft.yaml uses part ordering (the after keyword) to make sure that all the parts that need to fetch data/packages from the internet do so before actually building chromium. Not all the parts are specified in this ordering because not all of them actually stage packages.
But it appears that even for the parts that don’t stage packages, the new major version of snapcraft now runs apt-get update regardless, thus failing if the part is built after building chromium, because the proxy has been revoked. See this failed build for details.
I can probably work around the problem by specifying all the parts in the ordering dance, however I’d like to understand whether this new behaviour is intentional, or a regression.
I will look into this
This might fix the problem:
https://github.com/snapcore/snapcraft/pull/3170
Can you use an alternate snapcraft branch to test chromium with this?
As I’m observing the problem in the launchpad build infrastructure, I’ll need that fix published in the store in a dedicated channel.
Ok, just saw that the fix is a bit more than this, working on that, by default all our PRs that originate from snapcore/snapcraft get a branch on edge with the following pattern -> latest/edge/pr-XXXX, this one would be on latest/edge/pr-3170
Excellent, please ping me (either here or IRC) when the fix is ready, and I’ll trigger a build of the chromium snap with it.