[05:02] <bandali> hey lissyx, i dispatched builds here (the 3 most recent ones, on the top): https://launchpad.net/~bandali/+snap/firefox-snap-core22-preview
[05:02] <bandali> with this commit: https://git.launchpad.net/~bandali/+git/firefox-snap/commit/?id=a947d4c11ba9dee8595e67e33e33514a073edbea
[05:02] -ubottu:#ubuntu-desktop- Commit a947d4c in ~bandali/+git/firefox-snap "Use LLVM 15.0.6 and build debug symbols on ARM as well core22-preview"
[06:44] <lissyx> bandali, armhf failure but it seems unrelated to the infra
[07:39] <seb128> goood morning desktopers!
[07:42] <lissyx> hello
[07:42] <lissyx> seb128, do you think you can merge https://github.com/canonical/firefox-snap/pull/18 ? this way I can get rid of my local patch
[07:42] -ubottu:#ubuntu-desktop- Pull 18 in canonical/firefox-snap "Perform debug-symbols actually after firefox" [Open]
[07:55] <seb128> lissyx, hey. upload_symbols.py requires to be online no? Are we confident that doing that in the build step is not going to hit the online timeout?
[07:56] <lissyx> seb128, well, previously we had debug-symbols.pull running after complete firefox build, right?
[07:56] <lissyx> seb128, we would now have debug-symbols.build running after complete firefox build
[07:57] <lissyx> on launchpad we dont upload the symbols, only on github actions
[07:57] <lissyx> I dont think there's a cutoff on github actions?
[07:57] <lissyx> so we should be fine
[07:57] <seb128> right, not cutoff on github
[07:57] <seb128> ah, on launchpad we only publish the artifact and you have your collector job right?
[08:04] <seb128> lissyx, it's a bit of a nitpick but could you perhaps reference in the commit message to the snapcraft issue to explain the change?
[08:05] <seb128> otherwise the why is probably going to be lost and nobody will remember in a year when we look at the history
[08:07] <lissyx> done
[08:10] <seb128> lissyx, thanks, merged
[08:18] <seb128> lissyx, builds are started with the change on https://launchpad.net/~mozilla-snaps/+snap/firefox-snap-core22 
[08:18] <lissyx> perfect
[08:18] <lissyx> i've confirmed our changes to the taskcluster job to collect debug symbols is sound
[08:18] <seb128> great
[08:19] <lissyx> gerard-majax
[08:19] <lissyx> https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=symbol&selectedTaskRun=e8u1nTrbR5uRVCI9NB8D_g.0
[08:19] <lissyx> gerard-majax
[08:19] <lissyx> https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=symbol&selectedTaskRun=OOd1VWXJT4e4JqumejH3_g.0
[08:19] <lissyx> see "artifacts and debugging" tab in the panel at the bottom
[11:59] <lissyx> seb128, nightly debug snap working here :p
[12:03] <lissyx> seb128, and your core22 branch finished
[12:04] <seb128> lissyx, right, https://launchpad.net/~mozilla-snaps/+snap/firefox-snap-core22/+build/2145952 has a debug attached so it looks good
[12:04] <lissyx> seb128, can we just make sure we bump the version number?
[12:04] <lissyx> so we are collecting debug symbols for sure
[12:04] <lissyx> (on our side)
[12:08] <bandali> good morning
[12:08] <bandali> lissyx, re armhf failure: right. oddly enough i seem to remember failures on both armhf and arm64 when i last tried to build with llvm 15 there
[12:09] <bandali> any idea what might be the issue? my first thought to workaround it would be keep armhf's llvm back on 14 but of course that's not really sustainable
[12:09] <lissyx> seb128, bandali, there's an event today 1645 with my daughter's wednesday activity center, so i dont think I can attendss
[12:09] <lissyx> bandali, testing with 16 ?
[12:10] <lissyx> our builds are on clang 16 already
[12:11] <bandali> lissyx, ack re meeting. and as for 16, sure.
[12:11] <bandali> thanks actually i was about to ask what version you currently mainly use in your infra :)
[12:13] <seb128> lissyx, k, let's skip the meeting again
[12:14] <seb128> lissyx, what do you mean by 'bump the version number'? you mean the version string of the snap?
[12:14] <lissyx> yes
[12:14] <lissyx> 114.0.2-1 is already published right?
[12:15] <seb128> right, but the version string is only a cosmetic thing for users, it doesn't really have meaning for snapd
[12:15] <seb128> the store/snapd only work on revision numbers to know what to update
[12:16] <lissyx> we use the version string for not reprocessing already processed symbols versions
[12:19] <seb128> so the build from this morning is what got imported on your side since the previous build didn't have debug attached?
[12:19] <seb128> if so can we just promote that build to the main channel?
[12:21] <lissyx> we process from the launchpad api
[12:28] <seb128> lissyx, sorry but I'm unclear what that mean in context of my question. We only had one build with the version string 114.0.2-1 and a .debug attachment, so technically that version hasn't be re-used and there should be no issue?
[12:28] <seb128> or if your script being confused by the fact that it isn't the first build even if the previous one didn't have a .debug attached?
[12:29] <lissyx> yes, the later
[12:29] <seb128> ah, shame that we didn't notice that this morning before triggering the builds :/
[12:30] <seb128> bandali, we can just bump the version to 114.0.2-2 and trigger rebuilds right?
[12:30] <lissyx> this file holds the list of things we processed: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/e8u1nTrbR5uRVCI9NB8D_g/runs/0/artifacts/public/build/SHA256SUMS.zip
[12:31] <seb128> lissyx, that file includes
[12:31] <seb128> firefox_114.0.2-1_amd64.debug,142743596
[12:31] <lissyx> yes
[12:32] <lissyx> that's the bug we had: we dont know (well we know because it was broken on core22) whetehr thiss is stable/core22
[12:32] <bandali> seb128, yes i believe so. would you like me to bump `core22` to 114.0.2-2?
[12:32] <lissyx> the way we were searching content via the api made us blind to various branches and so we could pick stable or core22 depending on the output ordering
[12:33] <seb128> oh, I see
[12:33] <seb128> what you are asking is not to bump the revision and rebuild
[12:33] <seb128> it's to have different version string from the core20 and core22 builds
[12:34] <seb128> at least until we retire core20 and make core22 the only version
[12:35] <bandali> oh?
[12:36] <lissyx> seb128, no just bumping
[12:36] <lissyx> seb128, we now consider the package name and not just the filename
[12:36] <lissyx> so bumping version should be enough
[12:37] <lissyx> firefox-snap-core22,firefox_114.0.2-1_amd64.snap,256483328
[12:37] <lissyx> firefox-snap-core22,firefox_114.0.2-1_amd64.debug,
[12:37] <lissyx> vs 
[12:37] <lissyx> firefox-snap-stable,firefox_114.0.2-1_amd64.snap,256360448
[12:37] <lissyx> firefox-snap-stable,firefox_114.0.2-1_amd64.debug,142743596
[12:38] <seb128> ah
[12:38] <seb128> bandali, k, right, so can we get that string bumped to 114.0.2-1build1 or something for core22 and a rebuild?
[12:44] <bandali> seb128, ok sure, as long as 114.0.2-1build1 is a valid version string as far as tooling on our side or mozilla is concerned :)
[12:44] <seb128> use -2 :p
[12:44] <seb128> in doubt...
[12:45] <bandali> hmm
[12:55] <lissyx> it should be fine on our side
[13:34] <bandali> ack. i'll try with -1build1 first, and if there are any issues on your end please ping me and i'll bump to a simple -2
[14:16] <bandali> ugh, adding the 'build1' results in failure because that info is used to look up things in the right place in ftp.mozilla.org
[14:17] <bandali> which means bumping to '2' wouldn't work either, since there's no 'build2' in https://ftp.mozilla.org/pub/firefox/candidates/114.0.2-candidates/
[14:18] <bandali> looks like i'll have to use the ugly workaround of pushing a temporary commit to `core22` to force using `build1` (and not `build1build1`), and i'll drop the commit later in the next force push to core22
[14:18] <bandali> cc seb128 lissyx
[14:23] <seb128> bandali, ack
[14:52] <KGB-2> gnome-settings-daemon Simon McVittie 406785 * commented merge request !15 * https://deb.li/32pz4