=== popey8 is now known as popey [08:36] https://pastebin.canonical.com/p/3pH2jJRN7h/ it dispatched a thing! [08:38] yay! nice!! [08:39] build didn't work due to archive domain things, but closer! [08:41] :) +1 [08:47] Ooh, fancy. [09:06] looks like my build is being dispatched with 'archive.launchpad.test', which obviously isn't a thing. The build gets a 403 forbidden. Is there anyway I can override/make that work? [09:07] I tried hacking /etc/hosts on the buildd machine, but that didn't appear to work [09:14] tomwardill: That is a thing, but the default apache config restricts the IP addresses that can access it [09:16] aha! [09:16] that would explain the 403 [09:45] wgrant: don't suppose you have an example of an apache config that works tehre? I am failing to create one. I always get 403 [09:47] tomwardill: "Require ip 10.4.0.0/255.255.255.0" (for my LAN subnet), or "Require all granted" [09:49] aha, now I've upgraded to a 404 [09:54] do I need to create a mirror or something in there? [09:56] tomwardill: You can also override the publisher config if you like. /ubuntu/+pubconf IIRC [09:57] Or you can hack override-sources-list on the builder to search/replace stuff, which I sometimes do when I can't be bothered to do anything neater :) [10:00] pubconf did it, thanks [10:01] oooh, it got to the point of trying a git checkout [10:01] I'll call that progress [10:28] Yeah, I usually use +pubconf, or if I need to test primary archive publication then I include the real primary archive in Archive:+admin's manual sources.list entries [10:28] I don't think I've hacked override-sources-list in a long time [10:34] now to make turnip be on port 443 [10:34] * tomwardill stacks the yaks high this morning [10:53] I've changed http://git.launchpad.test:9419/ in launchpad-lazr.conf (in configs/development), but still appear to be getting the old setting. Have I missed another config file? [10:54] hmm, it's changed it in the LP UI, but build is still getting dispatched with the old one [10:58] tomwardill: Did you restart buildd-manager after changing launchpad-lazr.conf? [10:59] ah, maybe not [11:02] tomwardill: But also, what's wrong with 9419? [11:02] Oh, never mind, ignore that [11:02] Confused 9419 with 19417 (the API port) somehow [11:09] 2020-02-25 11:08:55+0000 [-] Iterating with success flag 0 against stage BUILD_OCI [11:09] 2020-02-25 11:08:55+0000 [-] Returning build status: OK [11:09] nice [12:35] where do we normally download wheels from ? [12:36] I went with piwheels.org but is that recommended practice ? [12:39] I'd tend to build them myselr [12:39] No particular need to trust random binaries from the Internet [12:39] But I don't know what others do. [13:03] piwheels is specifically for the raspberry pi, so probably not a huge help for anything that needs compilation [13:05] It's extremely rare to need to download Python stuff from anything other than pypi.org [13:06] lp-signing uses wheel dependencies at the moment because I was following the snap store approach, but now that I've worked out the mechanisms for building wheels as part of the deployment artifact in LP I'm quite tempted to go back to sdists for that [13:07] I would definitely not touch piwheels.org [13:20] tomwardill: Is there any useful QA you can do on your recipe branches? https://deployable.ols.canonical.com/project/launchpad [13:21] I don't think easily, without having the UI/API for project [13:22] Well, either do whatever you can or mark it green :) [13:23] fair :) [14:29] hmm, builddmanager is giving me: exceptions.IOError: [Errno 2] No such file or directory: u'/var/tmp/builddmaster/grabbing/20200225-141618-OCIRECIPEBUILD-12/1/ubuntu/manifest.json', but the file does exist on disk. Is there any likely cause, before I start debugging my way through it? [14:32] tomwardill: I can't think of a likely cause. I'd probably capture an strace [14:45] right, time for a deployment I think [15:40] hmmm, I think I have a callback race type thing [15:44] Ah, that was something that did come to mind in passing, but I figured you'd get it from an strace [15:44] yeah [15:44] just trying to work out the appropriate defer incantations for it [16:54] cjwatson: https://pastebin.canonical.com/p/yCYv9T8xZh/ that's my strace result, which to me looks like it's attempting to read the file before it's finished downloading it (the rename line is after the read line), does that seem reasonable? [16:54] If so, it's a twisted defer thing [16:54] (yay) [16:58] tomwardill: Indeed, probably just a missing yield [16:58] * tomwardill yields all the things [16:59] + self._slave.getFile(file_hash, file_path) [16:59] But getFile returns a Deferred [17:00] So _fetchIntermediaryFile has to be @defer.inlineCallbacks and has to yield that, and _downloadFiles has to yield calls to it [17:01] Otherwise what happens is that it runs up to the point of creating the Deferred but nothing ever arranges to do the rest of the work only once the Deferred has called back [17:01] In some brave new world we might eventually be able to detect this with type-checking [17:02] (i.e. ignoring the result of something known to return a Deferred should normally be a type error) [17:02] aha, nice [17:29] Could I have reviews of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/379648 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/379650, please? Both broadly the same kind of py3-related change [17:37] cjwatson: +1 to both [17:37] * tomwardill -> EOD -> gym [17:42] Thanks [22:51] wgrant: Hmm. On staging, 22 POTemplate rows with source_file_format = 3 (XPI), most recent change in 2011; 1 TranslationImportQueueEntry row with either format = XPI or path like '%.xpi', imported in 2011. Nothing relevant visible in loganberry's rosetta logs (zgrep -i xpi *). Anywhere else you can think of where I should be looking for evidence of the XPI import code being used? [22:52] That's about what I expected. [22:52] I forget exactly how TIQEs are pruned [22:52] But the POTemplate situation is pretty damning. [22:53] I'll hunt a bit more, but at the moment it does look quite dead [22:54] Ah yes, TranslationImportQueue.cleanUpQueue exists, so lack of TIQEs indeed doesn't necessarily say much [22:56] https://git.launchpad.net/launchpad/tree/lib/lp/translations/interfaces/translationimportqueue.py#n95 [23:03] There are some much more recent POFiles attached to those POTemplates though. [23:03] launchpad_staging=> select pofile.id, pofile.path, pofile.datecreated, pofile.date_changed from pofile left join potemplate on pofile.potemplate = potemplate.id where potemplate.source_file_format = 3 order by date_changed desc limit 3; [23:03] id | path | datecreated | date_changed [23:03] ---------+-------------------+----------------------------+---------------------------- [23:03] 3181454 | midbrowser-id.po | 2020-01-03 03:03:18.547327 | 2020-01-03 08:47:12.812078 [23:04] 1296031 | midbrowser-hu.po | 2010-01-28 03:13:06.945838 | 2017-12-18 12:28:58.183975 [23:04] 1670525 | firefox-3.6-ak.po | 2011-01-11 01:03:09.596781 | 2017-05-04 18:50:15.359629 [23:04] (3 rows) [23:04] 3066 rows overall [23:04] That just means someone's submitted a new translation to them [23:04] Some that actually end in .xpi too [23:04] Note what the po names are... [23:04] Neither of those packages have existed in a Long Time. [23:05] launchpad_staging=> select pofile.id, pofile.path, pofile.datecreated, pofile.date_changed from pofile left join potemplate on pofile.potemplate = potemplate.id where potemplate.source_file_format = 3 and pofile.path like '%.xpi' order by date_changed desc limit 3; [23:05] id | path | datecreated | date_changed [23:05] ---------+--------+----------------------------+---------------------------- [23:05] 1296371 | ia.xpi | 2010-01-28 20:35:57.113959 | 2017-03-03 17:30:22.902555 [23:05] 597359 | oc.xpi | 2008-04-15 19:33:07.436437 | 2016-10-10 07:48:45.302841 [23:05] 1295804 | oc.xpi | 2010-01-27 08:31:49.812962 | 2016-10-10 07:48:03.928331 [23:05] (3 rows) [23:05] Not obviously all that active, though surprisingly recent [23:09] /ubuntu/+source/firefox last seems to have had translations in natty [23:28] So I'm tempted to add a feature flag to make that importer raise some clearly-named exception, deploy, wait a month or so, and if we don't see that exception anywhere in OOPS reports or poimport logs, nuke it from orbit [23:29] Wouldn't anything in the last month either have its TIQE still exist or have updated date_changed one one of those two tables? [23:29] Right, but just in case I missed something [23:30] Let's delete it now, and add it back when the ghost of asac gets its revenge. [23:31] I really don't see any reason to be cautious here [23:31] *shrug* OK, fair enough [23:31] I guess it's easy enough to revert if needed [23:31] Uhuh. [23:31] I also said last night it had probably been a decade since it was used [23:31] And your data says nine years [23:32] Did you have a specific memory of something being deleted there or was it a good educated guess? [23:33] No specific memory, but that was around the time Chromium came into the picture and so Firefox switched to its rapid release schedule.