| === bdrung_ is now known as bdrung | ||
| === guiverc is now known as guiverc_d | ||
| seb128 | goood morning desktopers! | 08:32 |
|---|---|---|
| seb128 | ricotz, hey, how are you? | 09:02 |
| ricotz | seb128, hey, I am fine, thanks, how are you? | 09:07 |
| seb128 | ricotz, I'm alright thanks! | 09:07 |
| 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:08 |
| 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:10 |
| seb128 | I'm doing that now | 09:11 |
| ricotz | ok, will install it here now too | 09:11 |
| ricotz | seb128, hmm, looks like the l10n-central repos are still required and merged with comm-l10n in some way | 09:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| seb128 | now I'm unsure how they build them but I can try asking | 09:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| ricotz | https://searchfox.org/comm-central/source/taskcluster/comm_taskgraph/transforms/l10n_pre.py | 09:31 |
| 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:38 |
| ricotz | seb128, I will give it a try when time permits | 09:52 |
| seb128 | ricotz, thanks, I appreciate it | 09:52 |
| seb128 | I need to change location and close IRC, back in ~10min | 09:53 |
| ricotz | seb128, this should look better now - https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+sourcepub/14462378/+listing-archive-extra | 13:48 |
| seb128 | ricotz, it is slightly but still a regression :-( | 13:55 |
| 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:56 |
| ricotz | I would not say "slightly" while the translations of the whole settings sections are back ;) | 13:58 |
| 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:01 |
| 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:02 |
| 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:54 |
| 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 | 14:57 |
| ricotz | seb128, shall I push my thunderbird packaging changes for lunar? | 15:53 |
| seb128 | ricotz, yes please | 15:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| Eickmeyer | (aiui) | 15:59 |
| Eickmeyer | However, it doesn't prevent it from seeding. | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| tsimonq2 | OOC, who actually has the powers to open and close those tracks? | 16:03 |
| nteodosio | tsimonq2, AFAIK, the snap store folks. | 16:03 |
| 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:04 |
| 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:05 |
| 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:08 |
| 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:10 |
| 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:13 |
| 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:14 |
| 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:16 |
| ogra | how are you abl to open official presistent channels ? only store admins can ... usually | 16:17 |
| 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:18 |
| ogra | but then th ecannel is useless ? isnt it to provide release specific backports of fixes ? | 16:19 |
| 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:20 |
| 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:21 |
| ogra | yeah, smells like we painted ourselves into a corner here ... | 16:22 |
| === juliank_ is now known as juliank | ||
| 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:24 |
| * Eickmeyer off to take his son to school | 16:25 | |
| 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:31 |
| 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:33 |
| 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:34 |
| ogra | jbicha, it switches as soon as the track expired IIRc | 16:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| ogra | since both wont be possible with an expiring branch, we could as well get rid of that policy ... | 16:45 |
| nteodosio | ogra, what do you mean with expiring? Tracks don't expire, only branches, correct? | 16:46 |
| 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:47 |
| 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:48 |
| nteodosio | The branches are not in that policy indeed, rather the tracks. | 16:49 |
| Eickmeyer | nteodosio: No, I meant stable/ubuntu-xx.yy track, as seb128 was saying as well. | 16:53 |
| nteodosio | Eickmeyer, but that is not a track: The definition is track/risk/branch: https://snapcraft.io/docs/channels | 16:55 |
| 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:56 |
| nteodosio | Alright, sorry, sticking to terminology threw me off the _track_ | 16:57 |
| ogra | lol | 16:57 |
| Eickmeyer | LOL | 16:57 |
| * Eickmeyer blames cdimage-rootfs | 16:58 | |
| * ogra blames the inventor of the nomenclature ... | 16:59 | |
| ogra | it is just confusing ... (which is why i name them by behavior usually) | 16:59 |
| === bandali_ is now known as bandali | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!