| jamesh | cjwatson: weird. That's one part of the snapcraft.yaml we haven't changed in years | 00:48 |
|---|---|---|
| cjwatson | jamesh: hm, I can look harder tomorrow. I guess it could also be the `base: bare` bit, but the `build-base` should win ... | 01:15 |
| jamesh | cjwatson: I'll definitely give the architectures thing a try, so I can rule that out for your tomorrow | 01:16 |
| cjwatson | jamesh: is it possible that you used to create builds using the snap.requestBuild API though? That doesn't go through arch parsing | 01:17 |
| cjwatson | jamesh: (but is deprecated for various reasons, e.g. it can't detect the base properly) | 01:17 |
| jamesh | cjwatson: the recipe hasn't built automatically in response to the last push, or by using the manual "request builds" link on the website | 01:18 |
| cjwatson | jamesh: so it could be that this never worked but that the way you were requesting builds dodged the problem | 01:18 |
| jamesh | cjwatson: I'm pretty sure we had automatic builds working before | 01:19 |
| cjwatson | jamesh: we might have refactored how those worked at some point, but I'd need to dig into git history | 01:19 |
| jamesh | cjwatson: if updating that bit of the snapcraft.yaml fixes things, I'll be happy. Thanks for looking into it | 01:20 |
| cjwatson | jamesh: broadly we've been moving more towards async build requesting that parses snapcraft.yaml properly, as it became clear that our initial approach wasn't sustainable | 01:21 |
| jamesh | cjwatson: updating the architectures line does indeed seem to have got things unstuck. Thanks! | 02:10 |
| jamesh | cristiangsp: Colin helped track down the build failure for my snap. I had "architectures: [all]" in the snapcraft.yaml, which used to work but now seems to result in no builds being spawned by the build request. | 07:26 |
| cristiangsp | jamesh let me take a look again to the logs so see if now we can see the issue there | 07:46 |
| cristiangsp | when did you request a build? | 07:46 |
| cristiangsp | oh I see it now | 07:48 |
| cristiangsp | in the logs | 07:48 |
| cristiangsp | actually I see builds being successful, so I think we are good and you were trying to update me. Thanks! | 07:52 |
| jamesh | cristiangsp: yeah. I updated the snapcraft.yaml, and it started building again | 07:54 |
| cristiangsp | jamesh: perfect! | 07:54 |
| jamesh | cristiangsp: I hadn't actually touched this part of the snapcraft.yaml since the last builds in April, so I was mostly focusing on the aspects I had changed. | 07:55 |
| krisives | Is there a way in a Launchpad recipe to pull from the latest tag, similar to how {latest-tag} is used in the deb version part? | 16:34 |
| cjwatson | I don't believe so | 16:36 |
| cjwatson | Recipes were built mainly for ongoing CI sorts of applications, really | 16:36 |
| cjwatson | You can always have a branch that exists just for the purpose of hanging a recipe off, and push the latest tag to that each time you want to bump it | 16:37 |
| krisives | Yeah that's kind of what I do now, but the problem is that I'm also packaging software other people make and I try not to impose on them much | 16:48 |
| cjwatson | I'm afraid that's the best we can offer at the moment. You can make the branch yourself in your own repository - it doesn't have to involve imposing on them | 17:22 |
| krisives | Do you think a change to `git-build-recipe` that allowed `{latest-tag}` in the context of the git-ref would be accepted? | 18:08 |
| cjwatson | krisives: I don't think a change to git-build-recipe alone would be sufficient. It would need changes in the dispatch logic in Launchpad (in fact that would be where most of the change would have to go), and the definition of "latest tag" is considerably more difficult than it is in the context of generating a version string - for a version string, what it means is the latest tag found in the ... | 18:24 |
| cjwatson | ... direct ancestry of the branch that the recipe is based on, whereas for dispatch it's more like ... latest tag anywhere? But what if the repository is one that makes tags for purposes other than releases? It gets kind of complicated | 18:24 |
| cjwatson | krisives: In other words, I'm not sure this proposed solution is the right one. | 18:24 |
| krisives | {latest-tag} doesn't do version semantic style comparison to find the latest? | 18:25 |
| cjwatson | krisives: It might possibly be more sensible to define it as a flag on the recipe that causes LP to only dispatch builds when there's a tag, but still to follow a particular branch so that it doesn't e.g. get confused by a tag off on an old branch somewhere. | 18:25 |
| krisives | eg. if I tag `0.0.2` and then tag as `0.0.1` is `0.0.1` the {latest-tag} ? | 18:26 |
| cjwatson | {latest-tag} is generated using the output of "git describe --tags --abbrev=0 <commit that's been checked out>" | 18:26 |
| cjwatson | Which is specifically to do with the ancestry of the commit that's been checked out - it's not a meaningful concept in isolation from that | 18:27 |
| krisives | Thanks | 18:27 |
| cjwatson | Better argument against "latest tag anywhere": let's say you have a recipe for something like Python (the interpreter itself). There are relatively frequent releases, with corresponding tags, for 3.6.x, 3.7.x, 3.8.x, and 3.9.x. The "latest tag" in purely time-based terms might be any one of those; the "latest tag" by version comparison (which is not a universally-agreed concept) would be ... | 18:30 |
| cjwatson | ... something in the 3.9.x series. But you might very well want to have separate recipes corresponding to the latest release of Python 3.6, 3.7, 3.8, and 3.9 (perhaps with slightly different build options etc.). For that, you need to be thinking of the latest tag found along the history of a particular branch, rather than the latest tag in the repository. | 18:30 |
| cjwatson | So I think, if we were doing this, the patch would need to be mainly to Launchpad itself: the recipe would still be talking about the 3.6 branch of Python, but we'd want a flag that says "only dispatch a build when a commit on this branch is tagged" or similar. | 18:32 |
| krisives | Yeah, plus if someone goes back and does a tag to fix an older point release it will have problems | 18:32 |
| cjwatson | And LP would need to dispatch the recipe modified in such a way that it points to that particular tag, I guess. It's certainly possible that some kind of change to git-build-recipe might need to be involved | 18:33 |
| krisives | What does the +Z and +i mode thing mean? or is that specific to me running a bouncer? | 20:01 |
| tuxifreund | krisives: https://libera.chat/guides/usermodes :) | 20:23 |
| tuxifreund | nothing bouncer specific | 20:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!