snap build discrepancy

[tom-seddon]

Regarding #538 - looks like the snap build has a slightly different setup. It'd be nice if I could build this way too - even if I don't know enough about the snap mechanism to fix any difficult problems, I could at least be alerted to this sort of basic compile error.

[tom-seddon]

Regarding trying to reproduce locally: comparing the log to my desktop PC, desktop PC has the same gcc/g++ version: gcc 13.3. So nothing obvious there.

Not sure how to check the exact C++ stdlib or libc version, but the C++ headers come from /usr/include/c++/13/ (same as the log). Looking up the limits.h and std_algo.h line numbers referred to in the error messages, it looks like those lines do match, at least.

No warning about include_next from my own builds though, so that does suggest there must be at least some differences in the setup.

[tom-seddon]

If doing the full snap build process: maybe use an Ubuntu VM using vagrant?

[popey]

I am using lxd containers to build locally on my laptop. So, clone https://github.com/popey/b2-snap, and then:

cd b2-snap
snapcraft --use-lxd

Now, this presupposes you have LXD installed and configured, which isn't for everyone :).

Alternatively, you can use snapcraft remote-build, which pushes the local codebase to Launchpad.net and starts the build within the Launchpad build farm. You need a launchpad.net account (via Ubuntu SSO) for this, but it's free and not limited. This has the added benefit that the build farm has machines (and VMs) for every supported architecture, so you can check if it's building for all of them simultaneously.

The builds of B2 that end up in the store are built in Launchpad, but via a slightly different avenue. My b2-snap GitHub repo is hooked up to the snapcraft backend. There's a button in that web UI that enables me to start a build in the farm without having to have snapcraft installed locally.

Another option is to spin up a blank transactional container or VM running Ubuntu 24.04 (for core24 snaps) and install snapcraft inside it then run snapcraft in destructive mode, which means it won't spin up a VM or container (given you're already in an assumed ephemeral container/vm), but will build right there and then on that "machine". This isn't ideal, because who knows what's in that machine before you started the build, that might taint it, but if you know what you're doing, it's fine, and takes away one level of automatic abstraction.

Oh, also, you could have a GitHub action that builds the snap, given the runners are often Ubuntu, it's easy enough to stand up the bits to start the build whenever the repo changes, just like you would outside of snap. There is such a workflow right here: https://github.com/popey/b2-snap/blob/master/.github/workflows/test-snap-can-build.yml and here's the most recent run: https://github.com/popey/b2-snap/actions/runs/19212321403/job/54916405747

Finally, I'd be happy to add you as a 'collaborator' on the snapcraft store. You could then trigger builds, release b2, and maintain all the stuff I see there. Or, hand it over to you completely, or add a PR to this repo, and have you keep it, entirely up to you. I appreciate that your time is precious, and this may not be a priority. I just want to make it clear that I am happy to do whatever it takes to ensure your visibility and maintainership of this project is smooth.

If you did want me to invite you to be a collaborator, you'd need a Launchpad / Ubuntu SSO account, and let me know the email address, so I can send the invite.

[tom-seddon]

I've got myself set up to build the snap locally now, and did a bit of poking around. Looks like this is just the result of the headers being arranged a bit differently inside the container.

Without the explicit include, the include chain for the accidental include of limits in the local build case on my PC is something like SDL_stdinc.h -> /usr/include/c++/math.h -> /usr/include/c++/13/cmath -> /usr/include/c++/13/bits/specfun.h -> limits.

In the b2 snap container on the other hand, SDL_stdinc.h picks up /snap/gnome-46-2404-sdk/current/usr/include/math.h - so it'll be all C stuff.

[tom-seddon]

Regarding the include_next warning, I think that is due to some of the extra include paths being specified with -I rather than -isystem, meaning it's benign. I'll sleep on the idea of having the option to disable this warning so that the snap build can end up clean.

[tom-seddon]

For the snap build process in general: I don't really want to take on full responsibility for it, because it isn't something I use myself. But I do want it to work (and stay working...), and it would be nice if it could track the b2 release schedule. The stable/edge distinction could map neatly to the GitHub release/prerelease concept, and so the snaps could be generated on the same schedule. I moved b2 over to using GitHub Actions a while ago (new releases created on push to master; new prereleases created on push to wip/master) - so in principle maybe it could all be integrated? With the b2-snap repo being a submodule, perhaps?

[tom-seddon]

While I'm thinking about the snap build process:

• latest wip/master bumps the gtk requirement to gtk-4, so that will need addressing somehow, at some point
• looks like the build version ends up as local_build, as usual for a build built using the ordinary build process. But an explicit name could be specified, so the version could match the stated snap version (i.e., git date/time/hash) - and the mechanism for this is already kind of in place, as it's used for the GitHub releases. But it is currently a bit specific to the release creation script, so it'll need some tweaking