| ilasc | rbasak: I'll have a look this morning yes, in the meantime can you please share a copy/paste of the failure message you're seeing after triggering the rescan | 05:41 |
|---|---|---|
| locutusofborg | hello, is launchpad failing to get new packages from Debian? | 07:18 |
| rbasak | "Repository scan failed" | 08:52 |
| rbasak | "Scanning this repository for changes failed. You can manually rescan if required." | 08:52 |
| rbasak | If I click on the "Rescan" button, then: | 08:52 |
| rbasak | "Repository scan scheduled" in a box at the top. | 08:52 |
| rbasak | In yellow at the bottom: | 08:52 |
| rbasak | "Updating repository..." | 08:52 |
| rbasak | "Launchpad is processing new changes to this repository which will be available shortly. Reload to see the changes." | 08:52 |
| rbasak | Then when I refresh, it's back to the "Repository scan failed" message - same as earlier | 08:52 |
| rbasak | ilasc: ^ | 08:52 |
| ilasc | rbasak: ok great, currently looking at logs for this but all I managed to find looks good, need to ask a colleague, will get back to you as soon as we figure it out | 08:54 |
| rbasak | Thanks! | 08:54 |
| ilasc | locutusofborg: not sure, can you please share which package you're expecting to get? | 08:55 |
| seb128 | ilasc, https://launchpad.net/debian/+source/llvm-toolchain-13 is a random example, there was a new upload in Debian yesterday, https://tracker.debian.org/pkg/llvm-toolchain-13, but it hasn't been picked up | 09:00 |
| locutusofborg | libsdl2 has been uploaded 12h before llvm-* | 09:25 |
| ilasc | rbasak: this looks like it's a bug (https://bugs.launchpad.net/launchpad/+bug/1973480) we currently have an MP for it that needs to land | 09:38 |
| ubottu | Launchpad bug 1973480 in Launchpad itself "Repository scan failed (Git)" [High, In Progress] | 09:38 |
| ilasc | locutusofborg: looking at logs for this now | 09:39 |
| locutusofborg | thanks ilasc | 10:05 |
| cjwatson | locutusofborg,ilasc: this is probably GS2 networking trouble | 10:09 |
| cjwatson | the importer is timing out trying to talk to the librarian. and the importer is in GS2, where there are known routing issues. | 10:10 |
| ilasc | hehe was just typing to you for help with this in MM, ok, thanks ! | 10:10 |
| locutusofborg | thanks, so maybe please if possible ping once they are fixed, so I know I can force-sync llvm-* :) | 10:11 |
| cjwatson | rbasak: I just merged https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/422618 onto master, which may help once it's deployed, we'll see | 10:16 |
| rbasak | Thanks! | 10:50 |
| rbasak | On a separate task, I've found myself with a couple of API questions. 1) How do I test for membership of a person in a team? I couldn't find a method under person or team. | 10:50 |
| rbasak | 2) What's the difference between checkUpload and isSourceUploadAllowed? | 10:50 |
| rbasak | The latter's docs suggests it only checks packagesets? | 10:51 |
| seb128 | rbasak, 1/ check if user is in lp.people["teamname"].participants ? | 10:56 |
| cjwatson | isSourceUploadAllowed specifically checks for upload permissions for packagesets that include the named source package, which is a part of what checkUpload looks for. I don't know why it's exported - you should probably ignore it | 10:58 |
| cjwatson | There are some things like that that were exported probably overenthusiastically. | 10:59 |
| rbasak | OK so I should just use checkUpload? | 11:02 |
| rbasak | I can look at .participants, thanks. I just assumed there'd be a more direct way | 11:04 |
| rbasak | Actually now I see that the docs say "If you want a method to check if a given person is a member of a team, you should probably look at IPerson.inTeam()." but it doens't look like that's exported | 11:04 |
| locutusofborg | auto sync looks running again correctly, lovely thanks! | 11:16 |
| cjwatson | # XXX: salgado, 2008-08-01: Unexported because this method doesn't take | 11:36 |
| cjwatson | # into account whether or not a team's memberships are private. | 11:36 |
| cjwatson | rbasak: ^ re Person.inTeam | 11:37 |
| cjwatson | In principle it should be possible to devise an API-suitable version of that but we haven't done it | 11:37 |
| rbasak | OK thanks. I'm grabbing participants now and checking locally. | 12:23 |
| rbasak | Thanks also to Seb | 12:23 |
| zyga[m] | cjwatson: hey, I've noticed that some snap uploads timed out after building, I've retried and everything worked correctly | 13:22 |
| cjwatson | zyga[m]: OK ... I can maybe investigate given links | 13:50 |
| cjwatson | (but if it worked on retry, it's going to be fairly low priority compared to other fires) | 13:50 |
| zyga[m] | cjwatson: sorry, let me pull the links for you, I was away | 14:49 |
| zyga[m] | cjwatson: I'm sure that several timed out but the one I've noticed was for amd64. https://launchpad.net/~zyga/hawkbitctl/+snap/hawkbitctl/+build/1778673 | 14:50 |
| zyga[m] | I've since clicked retry to upload again and it completed without a problem | 14:50 |
| zyga[m] | previously there were two types of failures, a timeout on one and connection refused or something like that, one another | 14:50 |
| cjwatson | zyga[m]: Ah, those were due to network issues in one of our datacentres this morning, now fixed. | 15:46 |
| cjwatson | Same root cause as the Debian import issues earlier. | 15:46 |
| zyga[m] | understood, thank you for looking after all of this! | 15:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!