=== bdrung_ is now known as bdrung
=== guiverc is now known as guiverc_d
[08:32] <seb128> goood morning desktopers!
[09:02] <seb128> ricotz, hey, how are you?
[09:07] <ricotz> seb128, hey, I am fine, thanks, how are you?
[09:07] <seb128> ricotz, I'm alright thanks!
[09:08] <seb128> ricotz, so sorry to bother you again with that, but is the thunderbird issue purely a packaging one from our side or something upstream is doing differently which isn't working as well as before?
[09:08] <seb128> I would like to report that to them but I'm unsure to understand what I should ask them for exactly
[09:10] <ricotz> seb128, did you try the repack build yet?
[09:10] <seb128> ricotz, no, it was late yesterday evening and I had another SRU regression to resolve then I had no time left
[09:11] <seb128> I'm doing that now
[09:11] <ricotz> ok, will install it here now too
[09:21] <ricotz> seb128, hmm, looks like the l10n-central repos are still required and merged with comm-l10n in some way
[09:22] <ricotz> seb128, see taskcluster/scripts/desktop_comm_l10n.py, I think its usage might come up in the snap build log?
[09:22] <seb128> ricotz, the repacked version from the ppa doesn't fix the issue, 'To',  'Mail' and others are still in english
[09:24] <seb128> ricotz, well the snap is using the upstream builds and not building from source so it's difficult to compare but that's basically what we do, 
[09:24] <seb128>       XPIURL=https://ftp.mozilla.org/pub/thunderbird/candidates/$VERSION-candidates/build$BUILD/linux-x86_64/xpi
[09:25] <seb128>       for locale in de es-ES fr it ja pt-PT pt-BR ru zh-CN; do curl -o "$SNAPCRAFT_PART_INSTALL/distribution/extensions/langpack-$locale@thunderbird.mozilla.org.xpi" "$XPIURL/$locale.xpi"; done
[09:25] <ricotz> oh, I assumed there is a build process going on :\
[09:26] <seb128> it's on our backlog to make the thunderbird snap a source build like firefox
[09:26] <seb128> but that shows that the upstream .xpi are matching the version and working 
[09:27] <seb128> now I'm unsure how they build them but I can try asking 
[09:28] <seb128> ricotz, should I try to revert https://bazaar.launchpad.net/~mozillateam/thunderbird/thunderbird.lunar/revision/753 or is that not going to work due to the upstream vcs changes you mentioned?
[09:29] <ricotz> seb128, see above comments, this repos is needed for the thunderbird parts, but additionally l10n-central is still needed for the browser parts
[09:30] <ricotz> reverting won't work
[09:30] <seb128> ah, I see
[09:30] <ricotz> so whatever taskcluster/scripts/desktop_comm_l10n.py needs to be redone in rules.mk
[09:31] <ricotz> https://searchfox.org/comm-central/source/taskcluster/comm_taskgraph/transforms/l10n_pre.py
[09:38] <seb128> ricotz, do you think you could give a try at doing that? if not I will add it to my backlog but my day became complicate because of issues with the Ubuntu Pro SRUs and a sick teacher which means having to handle a kid in parallel, so it's probably not going to be today for me
[09:52] <ricotz> seb128, I will give it a try when time permits
[09:52] <seb128> ricotz, thanks, I appreciate it
[09:53] <seb128> I need to change location and close IRC, back in ~10min
[13:48] <ricotz> seb128, this should look better now - https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+sourcepub/14462378/+listing-archive-extra
[13:55] <seb128> ricotz, it is slightly but still a regression :-(
[13:56] <seb128> I can see some of the items which weren't translated back, but things like 'To' in the composer or 'Mail' on the left bar aren't translated in french
[13:58] <ricotz> I would not say "slightly" while the translations of the whole settings sections are back ;)
[14:01] <ricotz> seb128, https://paste.debian.net/plain/1268531
[14:01] <seb128> ricotz, ok, sorry, I checked 3 labels I knew without translations on the main UI and 2 are still missing
[14:02] <seb128> so probably not an accurate testcase, sorry for the mischaracterization
[14:02] <seb128> but there is still a problem
[14:02] <ricotz> don't worry
[14:54] <schopin> ricotz: just in case you weren't stalking the rust-updates PPA in the past few days, everything should be in order now ;-)
[14:57] <ricotz> schopin, hey, thank you, already making use of it :)
[14:57] <schopin> I figured as much
[14:57] <ricotz> xenial backports worked out as well
[15:53] <ricotz> seb128, shall I push my thunderbird packaging changes for lunar?
[15:53] <seb128> ricotz, yes please
[15:54] <ricotz> done
[15:54] <seb128> ricotz, are you still working on figuring out the remaining missing strings issues or should I try to msg the mozilla people about it?
[15:54] <seb128> thx
[15:55] <seb128> or did that commit include more change compared to the previous build?
[15:55] <ricotz> seb128, I am not working on it anymore
[15:55] <seb128> ack
[15:55] <ricotz> no, those changes resulted in the build1.2 tarball
[15:57] <nteodosio> Eickmeyer, what is the reasoning behind closing a track after it has been open? Opening seems to be covered in https://wiki.ubuntu.com/UbuntuSeededSnaps#Channel_availability, but the closing I don't get. 
[15:58] <nteodosio> ^bug 2000849.
[15:58] -ubottu:#ubuntu-desktop- Bug 2000849 in chromium-browser (Ubuntu) "[snap] Request: open (and close) stable/ubuntu-23.04 track" [Undecided, Triaged] https://launchpad.net/bugs/2000849
[15:58] <Eickmeyer> nteodosio: That's just what mwhudson taught me to do. Keeps it from showing as an available track in the snap store, aaui.
[15:59] <Eickmeyer> (aiui)
[15:59] <Eickmeyer> However, it doesn't prevent it from seeding.
[16:00] <nteodosio> Alright, I'm not familiar with the process. The idea is then to simply open and close the track and I don't even have to wait for seeding.
[16:01] <Eickmeyer> Right.
[16:01] <seb128> nteodosio, our ISO builds are set up to track the stable/ubuntu-xx.yy channel
[16:01] <seb128> that way the user systems are configured in a way that allow us to publish a revision in that channel if ever needed
[16:02] <seb128> but we close it which makes the store fallback to use to stable
[16:02] <seb128> so in mean they use stable
[16:02] <seb128> but with an opt-out mechanism to control back if needed
[16:02] <nteodosio> Ah I understand! Thanks seb128.
[16:02] <seb128> np!
[16:03] <tsimonq2> OOC, who actually has the powers to open and close those tracks?
[16:03] <nteodosio> tsimonq2, AFAIK, the snap store folks.
[16:04] <Eickmeyer> tsimonq2: And the people who publish the individual snaps.
[16:04] <tsimonq2> Would be nice to get a list/prevent what happened at the beginning of this cycle ;)
[16:04] <seb128> tsimonq2, nteodosio, the owners/collaborators of that specific snap
[16:04] <tsimonq2> (If the track doesn't exist yet, the ISO build flat out fails)
[16:05] <seb128> we have a list and an archive opening item
[16:05] <seb128> if a flavor decide to preload a new snap they need to tell us they are doing so and we add it to the list
[16:08] <nteodosio> seb128, this information is then out of date/inaccurate? "Developers must currently make a request for tracks to be added to their snap via the #store-requests forum category" — https://snapcraft.io/docs/channels 
[16:10] <seb128> nteodosio, I'm not familiar enough with the store to be sure, maybe Ken would know but he's not on IRC atm
[16:13] <ogra> nteodosio, this is exactly the process .... the forum requests are our paper trail for such things so you can even in 2y still find out why a channel/track was created by whom and why
[16:14] <seb128> ogra, but not a process we follow to open/close stable/ubuntu-xx.yy tracks for our default snaps afaik...
[16:14] <ogra> seb128, ah, thats bad ... i think they should be handled the same way (though i guess people just bribe someone via mattermost to get a shortcut)
[16:16] <Eickmeyer> I mean, Studio seeds Freeshow, a snap I maintain, so I open/close a stable/ubuntu-xx.yy track with every upload. Should I have been making a request to myself via the forum?
[16:17] <ogra> how are you abl to open official presistent channels ? only store admins can ... usually 
[16:18] <ogra> devs/uploaders can open temporary branches (that automatically time out), but not permanent release channels 
[16:18] <Eickmeyer> That's the thing. The seeds require only that a track have existed, not that it currently exists.
[16:19] <ogra> but then th ecannel is useless ? isnt it to provide release specific backports of fixes ? 
[16:20] <ogra> at least that is how it was explained to me in 2016 by foundations .... 🙂
[16:20] <Eickmeyer> In the case of Freeshow, it appears as though once it's installed on the system, it just follows the stable track from then on out.
[16:20] <ogra> so why are yu not just using the stable channel all over then ? 
[16:21] <Eickmeyer> Because the seed requires that a stable/ubuntu-xx.yy track exists for the seed.
[16:21] <ogra> seems pretty pointless to open a channel just for an image build if you fall back to te latest/stable one anyway
[16:21] <ogra> oh my
[16:21] <Eickmeyer> Otherwise the .iso build will simply fail.
[16:22] <ogra> yeah, smells like we painted ourselves into a corner here ... 
=== juliank_ is now known as juliank
[16:24] <Eickmeyer> Yeah, I can't explain it. All I know is that in order for it to be seeded, it has to have the stable/ubuntu-xx.yy track opened and closed, then it seeds properly.
[16:25]  * Eickmeyer off to take his son to school
[16:31] <jbicha> ogra: the idea is that Ubuntu could release a fix specific to people running Jammy, if necessary, but usually all Ubuntu releases offer the same snap version
[16:33] <ogra> jbicha, right, but once your app switched to latest/stable it wont go back to stable/ubuntu-xxx so if you dont keep the track, it is moot to have it in the first place
[16:34] <jbicha> ogra: I think you'll find that on user systems, it continues to track the specific Ubuntu branch unless a user switches branches
[16:35] <ogra> jbicha, it switches as soon as the track expired IIRc
[16:36] <jbicha> if that happens, the Ubuntu Tech Board would need to know that, since this branch handling is their policy
[16:36] <ogra> jbicha, well, thats the default behavior for temporary developer branches AFAIK 
[16:37] <ogra> (which are actually designed to test fixes and commits temporary, i dnt think they were expected to be used fr image builds, but ICBW)
[16:37] <nteodosio> Aren't we mixing tracks and branches here? It's [track/]channel[/branch]. 
[16:38] <ogra> nteodosio, well, one is a thing you ad a dev can create yourself (because it automatically goes away and moves your app to latest/stable automatically after the testing) ... the other is a thing the store admins need to create and these are permanent
[16:38] <ogra> *you as
[16:41] <nteodosio> ogra, right, but Eickmeyer metntioned "in order for it to be seeded, it has to have the stable/ubuntu-xx.yy track opened and closed", probably he meant "ubuntu-xx.yy/stable track" instead.
[16:42] <ogra> nteodosio, right, i just doubt the usefulness of this if it snaps back into latest/stable anyway ... sounds pointless to have such a policy if the channel is not planned to be permanent to ship release specific fixes
[16:43] <nteodosio> ogra, I was counting on that after closing the track, reopening would make snapd automatically follow that track again. Otherwise that does look pointless.
[16:44] <ogra> IIRC the reason for that policy was to a) have reproducable builds (which you wont with an expiring thing) and b) to be able to have release-specific fixes for software ... 
[16:45] <ogra> since both wont be possible with an expiring branch, we could as well get rid of that policy ...
[16:46] <nteodosio> ogra, what do you mean with expiring? Tracks don't expire, only branches, correct?
[16:47] <ogra> i always forget which is which ... but the non-expiring ones require a store admin to create them ... the others expire after 30 or 60 days and are gone then ... no way to re-enable them with their old content
[16:48] <nteodosio> Yes, the tracks don't expire, they are the ones we have to request to the store. The branches expire, and we don't need to request them.
[16:48] <ogra> right
[16:48] <ogra> and i dont think the latter ones make sense in context f the policy that is in place
[16:49] <nteodosio> The branches are not in that policy indeed, rather the tracks.
[16:53] <Eickmeyer> nteodosio: No, I meant stable/ubuntu-xx.yy track, as seb128 was saying as well.
[16:55] <nteodosio> Eickmeyer, but that is not a track: The definition is track/risk/branch: https://snapcraft.io/docs/channels
[16:56] <nteodosio> If you really meant to open the branch though, yes I can do that directly without asking the Snap Store.
[16:56] <Eickmeyer> If that's the case, then it's explained incorrectly in the error message in the .iso builder.
[16:57] <nteodosio> Alright, sorry, sticking to terminology threw me off the _track_
[16:57] <ogra> lol
[16:57] <Eickmeyer> LOL
[16:58]  * Eickmeyer blames cdimage-rootfs
[16:59]  * ogra blames the inventor of the nomenclature ...
[16:59] <ogra> it is just confusing ... (which is why i name them by behavior usually) 
=== bandali_ is now known as bandali