[05:41] <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 
[07:18] <locutusofborg> hello, is launchpad failing to get new packages from Debian?
[08:52] <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:54] <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:55] <ilasc> locutusofborg: not sure, can you please share which package you're expecting to get?
[09:00] <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:25] <locutusofborg> libsdl2 has been uploaded 12h before llvm-*
[09:38] <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:39] <ilasc> locutusofborg: looking at logs for this now 
[10:05] <locutusofborg> thanks ilasc 
[10:09] <cjwatson> locutusofborg,ilasc: this is probably GS2 networking trouble
[10:10] <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:11] <locutusofborg> thanks, so maybe please if possible ping once they are fixed, so I know I can force-sync llvm-* :)
[10:16] <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:50] <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:51] <rbasak> The latter's docs suggests it only checks packagesets?
[10:56] <seb128> rbasak, 1/ check if user is in lp.people["teamname"].participants ?
[10:58] <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:59] <cjwatson> There are some things like that that were exported probably overenthusiastically.
[11:02] <rbasak> OK so I should just use checkUpload?
[11:04] <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:16] <locutusofborg> auto sync looks running again correctly, lovely thanks!
[11:36] <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:37] <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
[12:23] <rbasak> OK thanks. I'm grabbing participants now and checking locally.
[12:23] <rbasak> Thanks also to Seb
[13:22] <zyga[m]> cjwatson: hey, I've noticed that some snap uploads timed out after building, I've retried and everything worked correctly
[13:50] <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)
[14:49] <zyga[m]> cjwatson: sorry, let me pull the links for you, I was away
[14:50] <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
[15:46] <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:50] <zyga[m]> understood, thank you for looking after all of this!