[00:19] For my peace of mind, can someone please confirm that if a private PPA password leaks, all that leaks is _read_ access to that _specific_ PPA? [00:22] kyrofa: That's correct. PPA access tokens are read-only and tied to a specific PPA and user. [00:22] wgrant, thank you sir [00:29] Another unrelated question: is there a way to get the signing key for a PPA before it has packages? [00:40] kyrofa: To save resources and not pollute keyservers, LP only generates the key for a PPA once packages exist in it. But do note that this only applies to the first PPA for a given person or team; subsequent PPAs with the same owner should reuse the existing key on creation. [00:49] Oh that's interesting, I never noticed that === lifeless_ is now known as liffeless === liffeless is now known as lifeless === cjwatson changed the topic of #launchpad to: Switching database master, brief outage imminent | Help contact: tomwardill (08:00 - 17:00Z) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad [09:18] (or rather, in read-only mode) === cjwatson changed the topic of #launchpad to: Help contact: tomwardill (08:00 - 17:00Z) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad [09:34] Master switch finished a while ago, sorry for forgetting to update here [09:35] Writes are now going to pure SSD so hopefully that'll help performance [13:45] Could someone explain what's happening in https://api.launchpad.net/devel/debian/+archive/primary/+sourcepub/1934411 please? This object has no date_published entry. What does it mean for a publication history entry to have been created but never published? [13:50] rbasak: An old bug. Prior to https://git.launchpad.net/launchpad/commit/?id=93b487ee1332840f036603b1567183963d6a9fab, the Debian importer created source package publishing history entries as Pending and never set them to Published (unless the publisher was run on them, which never happened in this case). [13:52] rbasak: But it could probably happen in other cases if the SPPH was quickly superseded by a newer version before being published. [13:52] cjwatson: thanks. [13:53] cjwatson: in other cases> in Ubuntu only presumably, or Debian too? [13:53] Because I assume you only create Debian publishing history entries when you see Debian publications? [13:53] In Ubuntu. (I think.) [13:53] Right. [13:53] Got it. Thanks! [13:53] Since the change above, Debian publications are immediately created as Published. [13:54] I don't think something can be immediately superseded, but it can be immediately deleted [13:54] (pretty sure the dominator only considers status == published) [13:55] Hm yes [13:55] So still possible but rarer [13:56] Is there a guarantee that every source_package_publishing_history has a package_upload? [13:58] That seems unlikely; a Debian-imported one doesn't [13:58] Oh [13:58] * rbasak wonders where git-ubuntu gets the source from then [13:59] PackageUpload would seem a slightly odd thing to go through to get the source [14:00] Ah. It defers that to ubuntutools.archive [14:00] You could do sourceFileUrls on the SPPH [14:00] Or yeah, look them up from the archive by source name and version [14:01] Sorry, I forgot the details of the model here. [14:01] package_upload corresponds to something that has been in a queue at some point (/ubuntu/focal/+queue etc.) [14:01] My question is really: if I include spphs with no date_published entries, then will I have a problem importing them? [14:02] Or will something importable always exist? [14:02] (importable == I can grab a source tree, dsc file, etc) [14:02] They should still have files on the sourcepackagerelease even before being published [14:02] Sounds good, thanks [14:02] date_published is more about being put on disk by the publisher [14:03] I'll rely on the date_created of spphs then [14:03] And mostly (completely?) ignore date_published [14:04] date_published is interesting if you want to line things up with when the publisher ran, but I can't think of why it would be interesting to git-ubuntu [14:04] And I'll use the earliest spph (keyed by date_created) for a (source_package_name, source_package_version) pair to keep consistency in ordering [14:05] cjwatson: yeah - sounds like I took a wrong turn in using date_published instead of date_created [14:06] I'm not sure I can authoritatively guarantee that every SPPH will have some associated files - it's possible there are anomalies - but I don't expect that to have anything to do with whether date_published is set [14:07] And I don't know of a situation today where that would happen [14:07] Fair enough. If we find anomalies, the import will probably fail until I add code to detect the anomaly and treat the spph as if it doesn't exist. I think that's OK. [14:08] It is uncommon, but e.g. maitreya [14:08] Possibly only maitreya [14:08] I think we treated that like an early source expiry, rather than excising it from the DB entirely. [14:08] Not importing that is in fact desired [14:08] Indeed. [14:09] Oh maybe also really old obsolete things? [14:09] I don't remember whether we've ever expired source files [14:09] I didn't think so [14:09] (aside from maitreya) [14:09] More detail on maitreya please? [14:09] Legal [14:09] Sounds like a good edge case to make sure git-ubuntu works with. [14:09] We can also put it in an import blacklist [14:10] (also, astrologers) [14:10] But I'd like to make sure git-ubuntu does work against things Launchpad has. [14:10] The gory details are best discussed over beer :) [14:10] I don't think we've expired sources from the Ubuntu primary archive [14:10] For obsolescence reasons, I mean [14:10] Virtual beer? :) [14:11] https://wiki.canonical.com/InformationInfrastructure/OSA/RequestLogging/LP/SQL has some history, ish [14:18] Thanks! [14:47] We just saw a build failure in Launchpad that we didn't reproduce in either of the local builds we did (one using sbuild, one just building in their host). Is there any (not entirely painful :p) way to build packages the way that Launchpad does? (Or at least more closely?) [14:48] (I know this is Complicated, but figured I'd double check that I'm not missing something I could be using.) [14:58] Odd_Bloke: is it a consistent failure? [15:10] Yeah, it's just a difference in environment. [15:10] Which I would like to be able to catch locally/in the build we do in our CI/..., if possible. [16:23] Odd_Bloke: Tom wrote https://dev.launchpad.net/Soyuz/HowToDevelopWithBuildd a little while back, but it uses the LXD VM stuff and is generally a tad new [16:23] And also doesn't do the restricted network stuff I think [16:23] sorry, dropped this conversation and got distracted [16:23] no, it doesn't do the restricted network (it could, but that's a bunch of ufw stuff that I'm not sure I can repeat atm) [17:03] OK, cool, I'll give that a go at some point. Thanks!