=== cpaelzer_ is now known as cpaelzer
[06:04] <oSoMoN> good morning desktoppers
[06:13] <duflu> Morning oSoMoN 
[06:14] <oSoMoN> hey duflu 
[06:42] <bittin> morning
[06:48] <duflu> Hi bittin 
[07:06] <didrocks> good morning
[07:10] <ricotz> good morning desktopers!
[07:12] <seb128> goood morning desktopers
[07:14] <didrocks> hey ricotz, seb128 
[07:15] <seb128> lut ricotz, en forme ?
[07:17] <lissyx> oSoMoN, hello
[07:17] <duflu> Morning didrocks, ricotz, seb128, lissyx 
[07:18] <lissyx> oSoMoN, I pingued you a bit, but there's one kinda more important
[07:18] <seb128> duflu, hey, how are you?
[07:18] <seb128> lut lissyx, oSoMoN 
[07:18] <lissyx> oSoMoN, https://bugzilla.mozilla.org/show_bug.cgi?id=1766901#c14
[07:18] <ubottu> Mozilla bug 1766901 in Toolkit "Scrape symbols from Ubuntu snap builds" [S1, New]
[07:18] <duflu> seb128, pretty good. How are you coping?
[07:18] <seb128> duflu, doing alright!
[07:19] <lissyx> oSoMoN, trying to abuse snapcraft by adding a task depending on firefox, and so we could upload symbol during its override-pull
[07:19] <lissyx> oSoMoN, however I dont know how much this can really work on launchpad infra
[07:19] <lissyx> seb128, hello
[07:22] <didrocks> hey duflu 
[07:47] <oSoMoN> good morning bittin, didrocks, ricotz, seb128, lissyx 
[07:47] <oSoMoN> lissyx, let me take a closer look
[07:49] <seb128> oSoMoN, lissyx, uploading the symbols will require internet access at the end of the build right?
[07:50] <lissyx> seb128, I assume "override-pull" will be allowed to perform network operations
[07:50] <lissyx> but I dont know you infra, so I dont know if it's valid
[07:51] <seb128> sounds logical yes
[07:54] <oSoMoN> lissyx, the problem isn't in which step the network accesses are done, it's "when" in absolute time. The launchpad builders have a hardcoded timeout after which network accesses are denied, so if the build takes too long, network accesses will fail after a while
[07:54] <oSoMoN> but it's worth trying anyway
[07:58] <lissyx> hm
[08:00] <oSoMoN> lissyx, I like your idea of building the debug symbols, uploading them to the Mozilla servers, and then discarding them in the final snap. I don't know what's the current value of the launchpad timeout for network accesses these days (I'll inquire), but it might be doable. amd64 builds typically take between 2 and 3 hours, maybe the timeout is high enough to allow this approach?
[08:01] <lissyx> I'm going to put my changes on github
[08:01] <lissyx> you can try
[08:01] <lissyx> it works locally
[08:02] <seb128> if not we should try to talk to the launchpad team to see what options we could have
[08:02] <lissyx> oSoMoN, here: https://github.com/canonical/firefox-snap/pull/1
[08:02] <ubottu> Pull 1 in canonical/firefox-snap "WIP - Adding debug symbols" [Open]
[08:03] <lissyx> I'm off to some sport
[08:07] <seb128> oSoMoN, lissyx, https://bugs.launchpad.net/launchpad/+bug/1885164 states 120 minutes timeout
[08:07] <ubottu> Launchpad bug 1885164 in Rutabaga "snap builds: network access timeout" [High, Triaged]
[08:07] <seb128> ah, they bumped to 3 hours according to Colin
[08:10] <oSoMoN> so that would work for amd64 builds, presumably
[08:11] <seb128> right, the recent builds were finished under 3 hours
[08:13] <oSoMoN> lissyx, why is your PR targetting the nightly branch?
[08:14] <oSoMoN> lissyx, and what would be the mechanism to upload build symbols to the Mozilla servers, is there some sort of API for that?
[08:21] <oSoMoN> from my perspective, it would be best to upload the symbols at the end of the build, rather than keeping them in the final snap, because it would potentially result in a significant increase of the snap's size
[10:22] <lissyx> oSoMoN, that's nightly because this is what I was working on
[10:22] <lissyx> oSoMoN, I agree we should avoid keeping the zip file inside the snap
[10:22] <oSoMoN> lissyx, but debug symbols would be most useful for stable and beta builds, right?
[10:22] <lissyx> they are useful for all builds
[10:23] <lissyx> it's just a WIP to see if we could do it
[10:23] <lissyx> and we have mach uploadsymbols to do the upload to socorro
[10:27] <lissyx> oSoMoN, uploading might require some credentials, and since it seems we cannot pass env variabes from |snap run snapcraft| CLI to the build itself, I am not sure how this can be addressed
[10:28] <oSoMoN> lissyx, I just checked in a local build and mach doesn't seem to know of the uploadsymbols command
[10:29] <lissyx> ah no it's not directly in mach
[10:30] <lissyx> https://firefox-source-docs.mozilla.org/crash-reporting/uploading_symbol.html
[10:30] <lissyx> and 
[10:30] <lissyx> https://firefox-source-docs.mozilla.org/setup/building_with_debug_symbols.html
[10:31] <lissyx> the upload itself is not super complicated
[10:31] <lissyx> https://searchfox.org/mozilla-central/source/toolkit/crashreporter/tools/upload_symbols.py
[10:32] <lissyx> (and you could even directly reuse the script I guess)
[11:09] <lissyx> looks like I can extract the debug symbols zip file by copying it to $SNAPCRAFT_PROJECT_DIR/ ?
[11:36] <lissyx> oSoMoN, according to |snap info firefox|, today's nightly on snap store is 180MB, my local build of a snap with debug symbols enabled is 173MB
[11:43] <oSoMoN> lissyx, what's the compression of your local build? by default the firefox snap uses lzo for better decompression performance, at the expense of total size. Could it be that somehow your build is using the default compression, which is optimized for size?
[11:43] <lissyx> I have not changed that
[11:43] <lissyx> so it should be lzo as well
[11:44] <lissyx> when I say "with debug symbols", it means with the binary not strippped
[11:44] <lissyx> but I have removed the zip file from the snap, obviously
[11:50] <jbicha> good morning
[12:12] <nteodosio> hey jbicha, good morning!
[12:41] <seb128> jbicha, hey, how are you? had a nice time away from the keyboard?
[12:42] <seb128> lissyx, weird that unstripped is smaller, is that the same firefox version?
[12:44] <jbicha> hi, yes, nice break
[12:44] <seb128> great!
[12:49] <lissyx> seb128, should be
[12:49] <seb128> weird, snap aside what's the binary size difference stripped vs unstripped?
[12:52] <lissyx> no idea
[12:52] <lissyx> I'm in a meeting
[12:52] <lissyx> I'll look later
[12:52] <lissyx> (it's a complicated day)
[13:08] <KGB-0> gnome-bluetooth3 signed tags 2519364 Jeremy Bicha upstream/42.1 * Upstream version 42.1 * https://deb.li/ixkNg
[13:08] <KGB-0> gnome-bluetooth3 pristine-tar 3ca827a Jeremy Bicha gnome-bluetooth3_42.1.orig.tar.xz.delta gnome-bluetooth3_42.1.orig.tar.xz.id * pristine-tar data for gnome-bluetooth3_42.1.orig.tar.xz * https://deb.li/ip9kd
[13:08] <KGB-2> gnome-bluetooth3 upstream/latest a6a53a1 Jeremy Bicha * pushed 9 commits (first 5 follow) * https://deb.li/uhb7
[13:08] <KGB-2> gnome-bluetooth3 upstream/latest caedae9 Rūdolfs Mazurs po/lv.po * Update Latvian translation * https://deb.li/3jT9h
[13:08] <KGB-2> gnome-bluetooth3 upstream/latest 8517795 Nathan Follens po/nl.po * Update Dutch translation * https://deb.li/Y9S2
[13:08] <KGB-2> gnome-bluetooth3 upstream/latest 20bc1c0 Jordi Mas po/ca.po * Update Catalan translation * https://deb.li/3AkXC
[13:08] <KGB-2> gnome-bluetooth3 upstream/latest 2b01a94 Fabio Tomat po/fur.po * Update Friulian translation * https://deb.li/FUHU
[13:09] <KGB-2> gnome-bluetooth3 upstream/latest 2c53d6b Ngọc Quân Trần po/vi.po * Update Vietnamese translation * https://deb.li/3dd5F
[13:09] <seb128> jbicha, could you review https://salsa.debian.org/gnome-team/gnome-text-editor/-/merge_requests/1 ?
[13:09] <ubottu> Merge 1 in gnome-team/gnome-text-editor "Update to 42.2" [Opened]
[13:09] <seb128> I didn't get to it yesterday and today doesn't seem it will be better
[13:21] <jbicha> sure
[13:22] <lissyx> seb128, oSoMoN, still a hack, no token bundled but a local build would upload successfully to staging :) https://github.com/lissyx/firefox-snap/commit/abd316f6c41371c455db10021488b1d867996cea
[13:22] <ubottu> Commit abd316f in lissyx/firefox-snap "WIP - Adding debug symbols"
[13:23] <seb128> jbicha, thanks
[13:23] <seb128> lissyx, great!
[13:24] <lissyx> now it's just a matter of how to store those creds (I saw some apitokens with gpg ?) and if it can hold in your infra :)
[13:26] <seb128> being able to store a private key or taken is sadly a feature missing from launchpad today :/ 
[13:26] <seb128> https://bugs.launchpad.net/launchpad/+bug/1933825
[13:26] <ubottu> Launchpad bug 1933825 in Launchpad itself "Feature request: store private API keys or secrets for use at build time by public recipes" [Undecided, New]
[13:30] <lissyx> :/
[13:31] <lissyx> seb128, maybe it is fine if the file is not committed?
[13:31] <lissyx> I dont know your workflow
[13:31] <lissyx> GitHub Actions can have some secrets as much as I remember from using it
[13:31] <lissyx> so beta/stable and esr might live without the token being stored?
[13:33] <oSoMoN> yes, github actions can have secrets, but launchpad doesn't have a similar feature yet
[13:37] <lissyx> I'd be interested if you can verify this is working on launchpad
[13:51] <seb128> if the build is reproducible I guess we could do another build on github not uploaded to the store just to collect the debug informations
[13:51] <lissyx> from #snappy I got that launchpad builds would not guarantee that :/
[13:51] <seb128> :-(
[13:52] <seb128> brb, need to drop to change location but I will read the backlog in case there is anything more for me to reply to
[13:52] <lissyx> that was my idea at first, adding a taskcluster task that would just pull your firefox-snap and build with debug and upload
[14:52] <KGB-2> evolution signed tags 254ff6b Jeremy Bicha ubuntu/3.44.2-0ubuntu2 * evolution Debian release 3.44.2-0ubuntu2 * https://deb.li/KOCI
[15:15] <KGB-2> gnome-text-editor pristine-tar a6b4eed Nathan Pratta Teodosio gnome-text-editor_42.2.orig.tar.xz.delta gnome-text-editor_42.2.orig.tar.xz.id * pristine-tar data for gnome-text-editor_42.2.orig.tar.xz * https://deb.li/3YbSC
[15:24] <KGB-2> gnome-text-editor signed tags ee589bd Jeremy Bicha ubuntu/42.2-0ubuntu1 * gnome-text-editor Debian release 42.2-0ubuntu1 * https://deb.li/XAgI
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy 6537d62 Jeremy Bicha * pushed 32 commits (first 5 follow) * https://deb.li/iU2IA
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy 1fd2400 Christian Hergert .gitlab-ci.yml * .gitlab-ci.yml: disable macos builder for now * https://deb.li/qAkM
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy 5fac051 Christian Hergert src/editor-utils.c * utils: fix inconsistent line-ending(s) use * https://deb.li/3V21j
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy b846c02 Christian Hergert src/editor-search-bar.ui * searchbar: fix warning from GtkBuilder * https://deb.li/tAQF
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy 9692034 Piotr Drąg po/pl.po * Update Polish translation * https://deb.li/3E291
[15:25] <KGB-2> gnome-text-editor ubuntu/jammy d41e983 Pawan Chitrakar po/ne.po * Update Nepali translation * https://deb.li/ynSd
[15:50] <KBar> Hello, everyone! I know it's late for this, but the 22.04 release rocks! My favorite release since 16.04. It's been a long time, but now I feel like I have come back home after a long journey. Fantastic experience. Brilliant job by every single one of us. From the bottom of my heart, thank you!
[16:01] <Maik> KBar: i feel exactly the same way. :)
[18:06] <seb128> KBar, thanks!
[18:06] <seb128> & Maik!
=== rs20090 is now known as rs2009
=== KGB-0_ is now known as KGB-0
=== sarnold_ is now known as sarnold
[21:25] <diddledani> might be of interest to desktoppers: https://youtu.be/OrMjQtPxo5Y (still processing. will be available in ~10 mintues)
[21:26] <diddledani> it's an investigation into using Intel binaries using Rosetta from macOS inside an Ubuntu 22.04 VM!