| GunnarHj | Hi cjwatson! Last night gnome-software was built and the translations were stripped off, but no imports to Rosetta seem to have happened. The build logs mention some lock... Can you please take a look? | 10:04 |
|---|---|---|
| cjwatson | GunnarHj: What exactly did the build logs say? | 10:06 |
| GunnarHj | cjwatson: https://launchpadlibrarian.net/559175519/buildlog_ubuntu-impish-amd64.gnome-software_40.4-1_BUILDING.txt.gz | 10:07 |
| GunnarHj | Maybe not important, considering that the translation tarballs were created. | 10:08 |
| cjwatson | GunnarHj: Do you mean things like "INFO: pkgstripfiles: waiting for lock (gnome-software-plugin-flatpak) ..."? That's purely internal to the build, related to parallelism. | 10:08 |
| GunnarHj | cjwatson: That's what I meant. | 10:08 |
| cjwatson | However, there is another lock apparently stuck. Let's check with IS | 10:11 |
| GunnarHj | Tnx. | 10:11 |
| cjwatson | GunnarHj: Thanks for lettign us know. The queue is clearing now | 10:28 |
| cjwatson | *letting | 10:28 |
| seb128 | GunnarHj, https://translations.launchpad.net/ubuntu/impish/+source/gnome-software states ' This source package is sharing translations with GNOME Software trunk series. ', which usually prevents import from sources? | 10:28 |
| cjwatson | The import job should still at least run | 10:29 |
| seb128 | shrug, the sharing is enabled again for most sources it seems | 10:31 |
| seb128 | checked https://translations.launchpad.net/ubuntu/impish/+source/nautilus as an example | 10:31 |
| cjwatson | I never did get my head entirely around sharing | 10:31 |
| seb128 | I did manually unset it for most things previous cycle, | 10:31 |
| seb128 | cjwatson, me neither, but my understanding is that when sharing is enable then it doesn't import things from the ubuntu source uploads | 10:32 |
| seb128 | which isn't what we want we we have downstream strings changes | 10:32 |
| seb128 | also often the upstream imports are outdated, especially GNOME ones as described on https://answers.launchpad.net/launchpad/+question/698744 | 10:34 |
| seb128 | cjwatson, what would be the right way to get the sharing thing reviewed more into details? It's a real issue than the options keeps turning itself on every cycle, it's screwing our translations for Ubuntu | 10:35 |
| cjwatson | Is there a bug explaining the problem as a starting point, at least? | 10:36 |
| cjwatson | I *thought* that sharing meant that imports still happened but possibly turned into suggestions instead; but my understanding is fuzzy | 10:38 |
| cjwatson | And AFAICS it's controlled by the distroseries/productseries packaging links, which have very open permissions | 10:38 |
| cjwatson | However I should probably stop speculating because fuzzy understanding | 10:39 |
| seb128 | I didn't open a bug since I'm unsure there is a bug there | 10:39 |
| seb128 | afaik it's working as intended, just that somehow the sharing got re-enabled despite being manually turned off (or is on for new ubuntu series rather than using the value from the previous one) | 10:40 |
| seb128 | and the fact that it isn't what we want for most GNOME components since our Vcs imports are outdated and we have downstream changes | 10:40 |
| seb128 | but yeah, a bug would give us a place to discuss the issue and it can turn into a question if needed | 10:41 |
| cjwatson | If I'm understanding things correctly and it's controlled by the packaging links, then those are writable by pretty much anyone and the UI rather encourages people to make links where it looks sensible | 10:42 |
| cjwatson | Perhaps we need a separate flag | 10:42 |
| seb128 | I'm also not sure my understand how the feature is right | 10:43 |
| seb128 | but I think to remember from observation that | 10:43 |
| seb128 | but I think to remember from observation that translations for a source would not end up in the import queue for a package upload if the setting is enabled | 10:43 |
| cjwatson | I can't find evidence of that in the code | 10:45 |
| cjwatson | This may be something I'm overlooking, but it's not obvious to me at least | 10:45 |
| GunnarHj | cjwatson: The behavior described by seb128 makes sense, sort of. A sharing link should go to a repo, i.e. it tells the project to import translations fram that repo, and hence assume that the package's .po files are not needed. But with that said, we don't rely on repos in most cases and want it to import from build tarballs instead. | 10:59 |
| cjwatson | This wasn't what I understood the intent of sharing to be, though - I thought the point was to merge translations from both distroseries and productseries, rather than to force the productseries to have primacy | 11:02 |
| cjwatson | (Where "merge" might end up with a bunch of suggestions that come from one side or the other) | 11:03 |
| GunnarHj | cjwatson: If that was the intention, there is a bug. | 11:07 |
| GunnarHj | seb128: Saw you removed the sharing link. (Why do I never remember to check that?) Just did a no-change rebuild of g-s. Let's see. | 11:10 |
| cjwatson | I'm hoping we can get a bug report (either a new one or a pointer to an existing one) with details of the incorrect behaviour | 11:10 |
| GunnarHj | cjwatson: Makes sense. | 11:11 |
| seb128 | I will write one now | 11:12 |
| cjwatson | Also not sure a no-change rebuild was needed since the existing upload job queue hasn't cleared yet and it's probably still in there ... | 11:12 |
| GunnarHj | cjwatson: Ah, sorry. | 11:13 |
| cjwatson | Wow, this is certainly a heck of a queue for PackageTranslationsUploadJob | 14:17 |
| cjwatson | I don't have a current view of its length, but I'm guesstimating it's about 75% of the way through | 14:18 |
| cjwatson | (There were 1250 WAITING jobs in the last production dump from about four days ago that was restored onto staging; the lock had been stuck for about 14 days :-(; and it's processed 1343 jobs today) | 14:19 |
| cjwatson | 2021-09-20 14:27:22 INFO Running <PackageTranslationsUploadJob for gnome-software in ubuntu impish> (ID 66174304) in status Waiting | 14:30 |
| cjwatson | So it's definitely doing *something* for gnome-software | 14:30 |
| cjwatson | And I see it in the import queue: https://translations.launchpad.net/ubuntu/impish/+source/gnome-software/+imports | 14:31 |
| cjwatson | That's even though it still says "This source package is sharing translations with GNOME Software trunk series" on https://translations.launchpad.net/ubuntu/impish/+source/gnome-software | 14:32 |
| cjwatson | seb128: ^ | 14:32 |
| cjwatson | I can't rule out that it's filtered out at some later stage of course, because this is a complex system and I don't understand all of it, but it is at least getting that far | 14:34 |
| cjwatson | Seems to be evidence against "translations for a source would not end up in the import queue for a package upload if the setting is enabled" from above? | 14:34 |
| seb128 | indeed, thanks | 14:35 |
| cjwatson | I'd be interested in information on whether this makes it all the way through the pipeline. I expect the import queue similarly has a large backlog at the moment so maybe worth checking back tomorrow | 14:36 |
| seb128 | I will keep an eye for that | 14:38 |
| seb128 | I don't remember the details of the issue we had past cycles, I know I had discussions about that wgrant in the past | 14:39 |
| cjwatson | OK, can dig back through IRC logs if we need to | 14:39 |
| seb128 | maybe launchpad's behaviour got improved in recent cycles | 14:39 |
| cjwatson | I don't think so | 14:40 |
| cjwatson | If it did it was unintentional :) | 14:40 |
| seb128 | checking for example https://translations.launchpad.net/ubuntu/impish/+source/gnome-disk-utility/+sharing-details the automatic sync is disabled for some reason and the options are greyed out for me | 14:41 |
| cjwatson | Translations has had quite a bit of code churn to port to Python 3 (there's a fair bit of bytes/text subtlety there, as you might imagine) and other things like that, but I think the last substantive model-level behaviour change was removing XPI imports | 14:41 |
| seb128 | cjwatson, trying random examples, https://translations.launchpad.net/ubuntu/impish/+source/evolution/+imports has no .po for example | 14:43 |
| seb128 | but it has a template in the queue from a recent upload | 14:43 |
| cjwatson | qhttps://translations.launchpad.net/ubuntu/impish/+source/gnome-software/+imports has po files though | 14:44 |
| cjwatson | er, https://translations.launchpad.net/ubuntu/impish/+source/gnome-software/+imports | 14:44 |
| seb128 | right, I don't understand why sometimes they are there and sometime not | 14:46 |
| seb128 | it's black magic to me | 14:46 |
| seb128 | or https://translations.launchpad.net/ubuntu/impish/+source/deja-dup/+imports | 14:48 |
| seb128 | where the recent build had translations, https://launchpad.net/ubuntu/impish/+upload/26714247/+files/deja-dup_42.8-1ubuntu1_amd64_translations.tar.gz | 14:48 |
| seb128 | but it doesn't help that filtering on 'imported' isn't really showing the full history | 14:49 |
| seb128 | iirc wgrant said on the past that it has memory only of recent activities for some reason and that having nothing showing as imported wouldn't mean nothing had been imported | 14:50 |
| seb128 | so you need to see on recent enough uploads | 14:50 |
| cjwatson | Hm, so if has_sharing_translation_templates is true, then the translations upload job only considers .pot files | 14:53 |
| cjwatson | That is true if the source package has a sharing partner *and* the sharing partner has "current" templates | 14:54 |
| cjwatson | Which is exported on the webservice API for that template as the "active" attribute | 14:55 |
| cjwatson | https://translations.launchpad.net/gnome-software has no templates, so they can't be current | 14:58 |
| seb128 | k, I see, so we got lucky there | 14:58 |
| cjwatson | https://translations.launchpad.net/gnome-software/trunk rather | 14:58 |
| seb128 | at least, it makes some sense now! | 14:58 |
| cjwatson | But https://translations.launchpad.net/evolution/head does | 14:58 |
| cjwatson | I think I've reached the limit of what I can figure out by reading code and intuition though. I don't know why the "don't import .po files if the sharing partner has current templates" rule is there | 14:59 |
| cjwatson | There used to be a comment on similar code that said "We do not want to override upstream translations, if translation sharing is enabled" | 15:01 |
| cjwatson | It used to suppress even .pot imports | 15:01 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/732612 maybe? | 15:02 |
| cjwatson | But I think for any more reasoning than that we need whatever institutional memory wgrant has | 15:03 |
| seb128 | cjwatson, thanks for digging the details, at least now it makes some sense and match what we have been seeing in past cycles, I opened https://bugs.launchpad.net/launchpad/+bug/1944211 | 15:05 |
| seb128 | https://answers.launchpad.net/launchpad/+question/698744 is also making the issue more important | 15:05 |
| cjwatson | True, though we can't rely on git-to-bzr imports for those forever anyway - in some cases those are nearly-unfixably broken | 15:09 |
| cjwatson | seb128: Hm, would one approach be if we gave you a dump of all the git.gnome.org branches / code import URLs we have registered, and somebody at your end prepared the mapping? We can certainly hand off individual projects from ~registry if needed as well, it's just likely to require a bit more case-by-case thought | 15:12 |
| cjwatson | seb128: Added such a dump to the question now | 15:19 |
| seb128 | cjwatson, sorry, I had to step out just before you asked the question earlier, providing the old<->new url table seems easy enough, I will get that added to the question tomorrow | 17:30 |
| cjwatson | seb128: ta | 18:00 |
| toddc | How/Who can change owner of https://launchpad.net/~ubuntu-arizona to https://launchpad.net/~tcole3737 ??? | 18:33 |
| cjwatson | toddc: The current owner is https://launchpad.net/~todd-bailey - are they contactable? | 19:50 |
| cjwatson | toddc: If they aren't, you can email rt@ubuntu.com, describe the situation and what efforts you've made to contact them, and ask Canonical's sysadmins to change the owner | 19:51 |
| toddc | cjwatson: thank you I will do that --not heard from him in 8-10 years minor detail | 19:54 |
| cjwatson | Right, we normally prefer to have the existing owner pass things on through normal processes, but there are always options if not. (I see you're already an admin of that team.) | 19:57 |
| cjwatson | Er, assuming that account is yours. | 19:57 |
| cjwatson | (Ah yes, IRC link matches.) | 19:57 |
| kyrofa | Are there known issues with the snap builders right now? All my builds seem to be failing trying to reach ftpmaster.internal | 21:38 |
| cjwatson | kyrofa: if you read this in logs or whatever, please provide links so that we can investigate | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!