=== JanC is now known as Guest3568 === JanC_ is now known as JanC === JanC is now known as Guest7998 === JanC_ is now known as JanC === JanC_ is now known as JanC [05:02] 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] 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] bandali, armhf failure but it seems unrelated to the infra [07:39] goood morning desktopers! [07:42] hello [07:42] 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] 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] seb128, well, previously we had debug-symbols.pull running after complete firefox build, right? [07:56] seb128, we would now have debug-symbols.build running after complete firefox build [07:57] on launchpad we dont upload the symbols, only on github actions [07:57] I dont think there's a cutoff on github actions? [07:57] so we should be fine [07:57] right, not cutoff on github [07:57] ah, on launchpad we only publish the artifact and you have your collector job right? [08:04] 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] otherwise the why is probably going to be lost and nobody will remember in a year when we look at the history [08:07] done [08:10] lissyx, thanks, merged [08:18] lissyx, builds are started with the change on https://launchpad.net/~mozilla-snaps/+snap/firefox-snap-core22 [08:18] perfect [08:18] i've confirmed our changes to the taskcluster job to collect debug symbols is sound [08:18] great [08:19] gerard-majax [08:19] https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=symbol&selectedTaskRun=e8u1nTrbR5uRVCI9NB8D_g.0 [08:19] gerard-majax [08:19] https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=symbol&selectedTaskRun=OOd1VWXJT4e4JqumejH3_g.0 [08:19] see "artifacts and debugging" tab in the panel at the bottom === schopin_ is now known as schopin [11:59] seb128, nightly debug snap working here :p [12:03] seb128, and your core22 branch finished [12:04] lissyx, right, https://launchpad.net/~mozilla-snaps/+snap/firefox-snap-core22/+build/2145952 has a debug attached so it looks good [12:04] seb128, can we just make sure we bump the version number? [12:04] so we are collecting debug symbols for sure [12:04] (on our side) [12:08] good morning [12:08] 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] 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] seb128, bandali, there's an event today 1645 with my daughter's wednesday activity center, so i dont think I can attendss [12:09] bandali, testing with 16 ? [12:10] our builds are on clang 16 already [12:11] lissyx, ack re meeting. and as for 16, sure. [12:11] thanks actually i was about to ask what version you currently mainly use in your infra :) [12:13] lissyx, k, let's skip the meeting again [12:14] lissyx, what do you mean by 'bump the version number'? you mean the version string of the snap? [12:14] yes [12:14] 114.0.2-1 is already published right? [12:15] right, but the version string is only a cosmetic thing for users, it doesn't really have meaning for snapd [12:15] the store/snapd only work on revision numbers to know what to update [12:16] we use the version string for not reprocessing already processed symbols versions [12:19] so the build from this morning is what got imported on your side since the previous build didn't have debug attached? [12:19] if so can we just promote that build to the main channel? [12:21] we process from the launchpad api [12:28] 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] 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] yes, the later [12:29] ah, shame that we didn't notice that this morning before triggering the builds :/ [12:30] bandali, we can just bump the version to 114.0.2-2 and trigger rebuilds right? [12:30] 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] lissyx, that file includes [12:31] firefox_114.0.2-1_amd64.debug,142743596 [12:31] yes [12:32] 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] seb128, yes i believe so. would you like me to bump `core22` to 114.0.2-2? [12:32] 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] oh, I see [12:33] what you are asking is not to bump the revision and rebuild [12:33] it's to have different version string from the core20 and core22 builds [12:34] at least until we retire core20 and make core22 the only version [12:35] oh? [12:36] seb128, no just bumping [12:36] seb128, we now consider the package name and not just the filename [12:36] so bumping version should be enough [12:37] firefox-snap-core22,firefox_114.0.2-1_amd64.snap,256483328 [12:37] firefox-snap-core22,firefox_114.0.2-1_amd64.debug, [12:37] vs [12:37] firefox-snap-stable,firefox_114.0.2-1_amd64.snap,256360448 [12:37] firefox-snap-stable,firefox_114.0.2-1_amd64.debug,142743596 [12:38] ah [12:38] bandali, k, right, so can we get that string bumped to 114.0.2-1build1 or something for core22 and a rebuild? [12:44] 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] use -2 :p [12:44] in doubt... [12:45] hmm [12:55] it should be fine on our side [13:34] 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] 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] 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] 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] cc seb128 lissyx [14:23] bandali, ack [14:52] gnome-settings-daemon Simon McVittie 406785 * commented merge request !15 * https://deb.li/32pz4 === JanC is now known as Guest9671