| === 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 | ||
| 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" | 05:02 | |
| lissyx | bandali, armhf failure but it seems unrelated to the infra | 06:44 |
| seb128 | goood morning desktopers! | 07:39 |
| 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:42 | |
| 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:55 |
| 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:56 |
| 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? | 07:57 |
| 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:04 |
| seb128 | otherwise the why is probably going to be lost and nobody will remember in a year when we look at the history | 08:05 |
| lissyx | done | 08:07 |
| seb128 | lissyx, thanks, merged | 08:10 |
| 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:18 |
| 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 | 08:19 |
| === schopin_ is now known as schopin | ||
| lissyx | seb128, nightly debug snap working here :p | 11:59 |
| lissyx | seb128, and your core22 branch finished | 12:03 |
| 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:04 |
| 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:08 |
| 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:09 |
| lissyx | our builds are on clang 16 already | 12:10 |
| 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:11 |
| seb128 | lissyx, k, let's skip the meeting again | 12:13 |
| 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:14 |
| 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:15 |
| lissyx | we use the version string for not reprocessing already processed symbols versions | 12:16 |
| 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:19 |
| lissyx | we process from the launchpad api | 12:21 |
| 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:28 |
| lissyx | yes, the later | 12:29 |
| seb128 | ah, shame that we didn't notice that this morning before triggering the builds :/ | 12:29 |
| 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:30 |
| seb128 | lissyx, that file includes | 12:31 |
| seb128 | firefox_114.0.2-1_amd64.debug,142743596 | 12:31 |
| lissyx | yes | 12:31 |
| 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:32 |
| 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:33 |
| seb128 | at least until we retire core20 and make core22 the only version | 12:34 |
| bandali | oh? | 12:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:44 |
| bandali | hmm | 12:45 |
| lissyx | it should be fine on our side | 12:55 |
| 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 | 13:34 |
| 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:16 |
| 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:17 |
| 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:18 |
| seb128 | bandali, ack | 14:23 |
| KGB-2 | gnome-settings-daemon Simon McVittie 406785 * commented merge request !15 * https://deb.li/32pz4 | 14:52 |
| === JanC is now known as Guest9671 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!