[06:16] <jibel> Good morning 
[06:38] <duflu> Morning jibel 
[06:41] <oSoMoN> good morning desktoppers
[06:57] <duflu> Hi oSoMoN 
[06:57] <oSoMoN> hey duflu 
[07:07] <didrocks> good morning
[07:13] <duflu> Hi didrocks 
[07:15] <didrocks> hey duflu 
[07:16] <oSoMoN> salut didrocks 
[07:16] <didrocks> salut oSoMoN 
[07:20] <seb128> goood morning desktopers!
[07:20] <didrocks> salut seb128 
[07:20] <duflu> Hi seb128 
[07:26] <oSoMoN> salut seb128 
[07:35] <seb128> hey didrocks, duflu, oSoMoN, how are you? had a nice weekend?
=== muktupavels_ is now known as muktupavels
[07:37] <didrocks> seb128: yeah, was nice, nothing really special, and you?
[07:38] <seb128> it was alright, nothing special either
[07:38] <duflu> seb128, not bad... until I snapped the keyboard cable on my favourite laptop. One that I had never opened before. Otherwise good.
[07:39] <seb128> :-( for the laptop
[07:39] <duflu> I have parts and new tools arrived today so wish me luck
[07:43] <ricotz> hello desktopers!
[07:47] <seb128> hey ricotz, how is it going? feeling better?
[07:48] <oSoMoN> seb128, very good long week-end, yes.
[07:48] <oSoMoN> hey ricotz 
[07:49] <duflu> Hi ricotz 
[07:50] <ricotz> seb128, hey, yeah, much better, symptoms are nearly gone :)
[07:50] <ricotz> oSoMoN, duflu, hi
[09:45] <lissyx> oSoMoN, seb128, so we can't access earlier versions of snaps from the store, what about the API ?
[09:46] <lissyx> I'm trying to use https://api.snapcraft.io/docs/info.html but it returns 404
[09:46] <oSoMoN> lissyx, afaik, one can access old revisions, but only if they are listed as a contributor to the snap
[09:46] <lissyx> which means I dont have access :)
[09:47] <oSoMoN> and I'm guessing the API would behave the same
[09:47] <lissyx> meh the endpoint is different between v1 and v2 
[09:50] <seb128> I'm unsure why they block access to old revision by default but that's a store question
[09:51] <lissyx> not being able to access older versions even from the API will make me basically unable to pull debug symbols
[09:51] <lissyx> I have not been able to find who is supposed to add me to the list of contributors ...
[09:56] <seb128> lissyx, oSoMoN and me have access to do that, but I think mkaply has been handling the mozilla side
[09:56] <seb128> we need at least to ask him before adding someone I think
[09:56] <lissyx> I also need to find how I can auth myself on the api
[10:00] <seb128> lissyx, you can use snap download --revision , unless you prefer to not depend on the snap cmd?
[10:01] <lissyx> well I was hoping to be able to use only the API
[10:01] <lissyx> since auth flow with snap CLI will be interactive
[10:02] <lissyx> seb128, also I would still need something to know those revisions number :/
[10:05] <oSoMoN> lissyx, once you're a collaborator to the snap, you have access to a web dashboard that lists all revisions, with details about the build
[10:06] <lissyx> right, but that's not really practical
[10:06] <seb128> what are you trying to do there?
[10:07] <lissyx> OH
[10:07] <lissyx> seb128, pulling symbols from snapstore once we have then in the snap?
[10:07] <lissyx> > The client must send the Snap-Device-Series and User-Agent mandatory headers. For the Snap-Device-Series header, the only supported value so far is '16'.
[10:07] <lissyx> looks like with this header set to 16 ... I get a full list?
[10:07] <lissyx> at least of the current ones
[10:07] <lissyx> not previous ones
[10:08] <seb128> lissyx, I've set up a meeting for tomorrow with launchpad people to try if we could do something to be able to export or upload the symbols as part of the build, I will let you know if there is anything coming out of it
[10:09] <lissyx> seb128, I'm afraid that until we can have proper handling of secrets, that's going to be complicated
[10:09] <seb128> lissyx, but if you get a snap revision, what do you need to match it with?
[10:10] <lissyx> seb128, sorry, I dont get your "match it with" ?
[10:10] <seb128> > <lissyx> seb128, also I would still need something to know those revisions number :/
[10:11] <seb128> I think I didn't understand what you meant there
[10:11] <lissyx> seb128, well you said "you could try snap download firefox --revision <ID>"
[10:11] <lissyx> I'd still need those IDs
[10:11] <seb128> ah, sorry
[10:11] <seb128>   latest/stable:    101.0.1-1    2022-06-09 (1443) 170MB -
[10:11] <seb128>   latest/candidate: 102.0-2      2022-06-25 (1492) 169MB -
[10:11] <seb128>   latest/beta:      102.0b9-1    2022-06-17 (1467) 169MB -
[10:11] <seb128> those are the number in parenthesis in the snap info output
[10:13] <seb128> lissyx, https://git.launchpad.net/ubuntu-desktop-versions/tree/snaps.py#n85 might be of use to you
[10:14] <lissyx> seb128, nice, thanks
[10:14] <lissyx> right now, it'd be awesome if I could get confirmation from someone knowledgeable of Snap Store that this API you linked (and I was already trying to use) will output me 
[10:14] <lissyx> **all** revisions
[10:14] <lissyx> and not just the current ones
[10:15] <seb128> https://api.snapcraft.io/docs/info.html
[10:16] <seb128> 'Get info from the snap and its released revisions.'
[10:16] <lissyx> yes
[10:16] <seb128> I'm unsure but I think 'released' means currently published
[10:16] <seb128> #snappy might be a better place for snap questions though
[10:16] <lissyx> already tried there
[10:17] <lissyx> ah no on #snapcraft
[10:29] <lissyx> ok if I can get all currently published revisions that's already a first sstep in the good direction
[11:29] <seb128> lissyx, in theory you don't need past revisions though if the system keep up with builds?
[11:30] <lissyx> seb128, what happens if we loose the history of the past builds and we need to rebuild it?
[11:31] <lissyx> e.g., something breaks pulling debug symbols, nobody notices for a few weeks, once it's fixed we loose debug info for revisions published in the meantime?
[11:31] <seb128> that can be a manual work from someone having contributor access to the snap
[11:32] <seb128> btw I emailed about give you contributor access, I will let you know if/when I get a reply
[11:32] <lissyx> having to rely on a manual process will only be cumbersome
[11:49] <lissyx> seb128, another case is if you publish several revisions between our runs, we wont have them
[11:53] <seb128> lissyx, k, taking one step back. Is the 'server might loose debug symbols already uploaded' a real usecase?
[11:54] <seb128> lissyx, if so it means we should discard a solution that upload the symbols to the service during the build without storing them somehow as well?
[11:54] <seb128> because if we do that we will not be able to re-upload things lost later on if needed
[11:55] <seb128> I was going to approach that issue asking the launchpad team about a way to get a secret, but that isn't enough then
[11:55] <lissyx> seb128, i'm not referring to the debug symbol here
[11:55] <lissyx> the debug symbol server
[11:56] <lissyx> I'm worrying what happens if for some reason the taskcluster scheduled task is not running / failing to pull data for some time
[11:56] <lissyx> which can happen if we run on a 24h schedule and you publish more than one revision in that interval for example
[11:56] <seb128> right
[11:57] <seb128> well, that's only an issue if we can't get the upload done from the snap build itself
[11:57] <lissyx> indeed
[11:57] <seb128> so I'm focussing on trying to resolve properly first
[11:57] <lissyx> that's why my PR adds support for uploading from GitHub Actions
[11:57] <seb128> right
[11:57] <seb128> well I wouldn't spend more time on plan B solution at this point
[11:57] <lissyx> if we can be sure we will have a proper solution in a timely manner for launchpad as well, I can live with that
[11:58] <seb128> as said earlier we have a meeting with launchpad people tomorrow so see what are our options
[11:58] <seb128> so I would suggest to wait for the outcome of that meeting
[11:58] <seb128> also there are several plan B options 
[11:59] <seb128> including setting up a job on our side to store the firefox snap past revisions $somewhere
[11:59] <seb128> I'm unclear why the store makes that private by default, I will ask them
[11:59] <seb128> but there is probably no risk storing those .snap if we need them
[12:00] <lissyx> well if it was private but accessible through the API it would not be a big deal as long as I find doc on how to auth :)
[12:00] <lissyx> (we need a solution on taskcluster to pull symbols from distros anyway, doing it for snap is the good canditate to push me to help my colleague and get that landed, it's not time lost)
[12:03] <jbicha> good morning
[12:08] <seb128> jbicha, hey, how are you?
[12:11] <jbicha> good :)
[12:17] <seb128> lissyx, I don't know about the auth but worth asking on #snappy or forum.snapcraft.io
[13:28] <ricotz> nteodosio, hey, great to see the poppler patch for libreoffice accepted, the 7.3.5~rc1 upload later this week will take care of the transition :)
[13:31] <nteodosio> hey ricotz, that's great news! Thank you for your help last week, much appreciated.
[14:23] <lissyx> seb128, yep I did on #snappy, but I was told it's not exposed at all it seems
[14:23] <lissyx> seb128, that being said, if you manage to get timeout  + secrets fixed on launchpad, it will likely not be such a big deal
[14:24] <lissyx> seb128, local snap I can extract and upload symbols, and online I can pull all from snap store: https://treeherder.mozilla.org/jobs?repo=try&revision=e5fcf7e9dec17134da939a82806719230b2cdd84
[14:24] <lissyx> seb128, now I just need to make sure I keep note of processed snaps, and we should be all good to have something that is ready
[14:25] <lissyx> seb128, and the counterpart https://github.com/canonical/firefox-snap/pull/3 should allow to publish directly from github actions, and package altogether the zip into the snap for the store
[14:25] <ubottu> Pull 3 in canonical/firefox-snap "Building debug symbols" [Open]
[14:48] <seb128> lissyx, great!
[18:35] <lissyx> seb128, https://treeherder.mozilla.org/jobs?repo=try&revision=8505ba516801c04126d3f26f577a536bca7a7735&selectedTaskRun=A6l2O451TBeuOpjtVjZeUQ.0 :)
[18:53] <KGB-2> gnome-control-center ubuntu/jammy e0e1f71 Jeremy Bicha * pushed 29 commits (first 5 follow) * https://deb.li/9yY1
[18:53] <KGB-2> gnome-control-center ubuntu/jammy 3c47db2 sicklylife po/ja.po * Update Japanese translation * https://deb.li/CWfc
[18:53] <KGB-0> gnome-control-center signed tags 1f7042c Jeremy Bicha ubuntu/1%41.7-0ubuntu0.22.04.1 * gnome-control-center Debian release 1:41.7-0ubuntu0.22.04.1 * https://deb.li/3sWON
[18:53] <KGB-2> gnome-control-center ubuntu/jammy 65c1c73 Yuri Chornoivan po/uk.po * Update Ukrainian translation * https://deb.li/3c13y
[18:54] <KGB-2> gnome-control-center ubuntu/jammy f338510 Bruce Cowan po/en_GB.po * Update British English translation * https://deb.li/6PBG
[18:54] <KGB-2> gnome-control-center ubuntu/jammy 7b0c55b Ian Douglas Scott panels/keyboard/cc-keyboard-shortcut-dialog.c * keyboard: Avoid segfault due to no "data" for `custom_shortcut_add_row` * https://deb.li/iwyKM
[18:54] <KGB-2> gnome-control-center ubuntu/jammy 34b5db1 Jeremy Bicha panels/wwan/gnome-wwan-panel.desktop.in.in * wwan: Remove duplicate line from .desktop * https://deb.li/KPMI
[18:54] <KGB-2> gnome-control-center signed tags 96382d7 Jeremy Bicha ubuntu/1%41.7-0ubuntu1 * gnome-control-center Debian release 1:41.7-0ubuntu1 * https://deb.li/3PyRA
[18:54] <KGB-2> gnome-control-center signed tags 5540495 Jeremy Bicha upstream/41.7 * Upstream version 41.7 * https://deb.li/s1je
[18:54] <KGB-0> gnome-control-center upstream/41.x fa37b59 Jeremy Bicha * pushed 23 commits (first 5 follow) * https://deb.li/36gv0
[18:54] <KGB-0> gnome-control-center upstream/41.x 15b8ebf Hugo Carvalho po/pt.po * Update Portuguese translation * https://deb.li/b34z
[18:54] <KGB-0> gnome-control-center upstream/41.x ff6ffbb Quentin PAGÈS po/oc.po * Update Occitan translation * https://deb.li/39Pzs
[18:54] <KGB-0> gnome-control-center upstream/41.x a66e785 Felipe Borges panels/info-overview/ cc-info-overview-panel.c cc-info-overview-panel.ui * info-overview: Allow changing "Device Name" by pressing "Enter" * https://deb.li/3xWDv
[18:54] <KGB-2> gnome-control-center pristine-tar 53c511d Jeremy Bicha gnome-control-center_41.7.orig.tar.xz.delta gnome-control-center_41.7.orig.tar.xz.id * pristine-tar data for gnome-control-center_41.7.orig.tar.xz * https://deb.li/3x10l
[18:54] <KGB-0> gnome-control-center upstream/41.x 82366a0 Kjartan Maraas po/nb.po * Update Norwegian Bokmål translation * https://deb.li/ilqsn
[18:55] <KGB-0> gnome-control-center upstream/41.x 00362a9 Kjartan Maraas po/nb.po * Update Norwegian Bokmål translation * https://deb.li/7Eg