| tsimonq2 | I've found a shiny bug and this is the farthest I've gotten in setting up LP, so hi. :) | 15:19 |
|---|---|---|
| tsimonq2 | With bug 1686242 - turns out the Librarian stores the buildinfo file, you can access it if you scroll through database queries to find the correct ID, but it's not linked on the build page once complete. | 15:20 |
| mup | Bug #1686242: .changes files reference .buildinfo files that aren't exposed <Launchpad itself:Confirmed> <https://launchpad.net/bugs/1686242> | 15:20 |
| tsimonq2 | The buildinfo files aren't marked as private, they aren't non-accessible, just not referenced well. | 15:20 |
| tsimonq2 | I'm looking for any pointers or any specific functions in which I could implement this. | 15:21 |
| tsimonq2 | (As far as my setup goes, two LXD virtual machines (yes, not containers, explicitly virtual machines), one has Launchpad itself and the other has launchpad-buildd. I'm able to successfully build packages when uploaded to "Lunar" but not PPAs, weirdly enough, where nothing is even dispatched.) | 15:23 |
| tsimonq2 | By tracking ./scripts/process-upload.py /var/tmp/builddmaster [etc.] I found the database calls for the Librarian - after that point the ID seems "lost" to the end user. | 15:24 |
| tsimonq2 | Anyway, I'll lurk here for a while. Let me know your thoughts. | 15:25 |
| tsimonq2 | It looks like the solution is to insert two rows into SourcePackageReleaseFile, one for the changes file and one for the buildinfo file. Makes everything work. | 16:03 |
| tsimonq2 | In other news, sourcepackagerelease isn't updated with the correct buildinfo from the buildd, instead it holds onto the source upload's buildinfo. I suspect those ones could be cleaned up, I think only the finished buildinfo files are useful. | 16:13 |
| tsimonq2 | 472-476@SQL-main-primary UPDATE BinaryPackageBuild SET buildinfo=239 WHERE BinaryPackageBuild.id = 36 | 16:18 |
| tsimonq2 | That makes more sense, so the source package has the original buildinfo and the binarypackage has the updated buildinfo | 16:18 |
| cjwatson | tsimonq2: would need to check an actual MP, but linking them as SPRFs _sounds_ reasonable at least | 17:30 |
| cjwatson | I don't think it's quite correct to think of source buildinfo as being "original" and binary buildinfo as being "updated" though | 17:31 |
| cjwatson | They're from different build passes | 17:31 |
| tsimonq2 | I have a diff currently that adds the binary buildinfo file as an SPRF. Should the uploaded buildinfo file also be visible anywhere? Otherwise my next step was tackling source.changes. | 17:35 |
| tsimonq2 | Oh, wait. That buildinfo file has an arch on it, so that doesn't seem exactly right. | 17:37 |
| tsimonq2 | Okay, so the source.buildinfo should probably be an SPRF and the amd64.buildinfo should probably be a BPRF. | 17:39 |
| tsimonq2 | cjwatson: I have some code pushing right now which should correctly expose those buildinfo files. My only remaining concern is about the .changes files, which would be useful for using a tool like dget. | 19:17 |
| tsimonq2 | https://code.launchpad.net/~tsimonq2/launchpad/+git/launchpad/+merge/448527 | 19:20 |
| cjwatson | The main concern about .changes files is that we mustn't expose the signed copies. | 19:47 |
| tsimonq2 | Ah, okay. | 19:48 |
| cjwatson | Because the signed versions act as upload instructions, so they could potentially be misused. Unsigned versions are fine to expose though. | 19:48 |
| tsimonq2 | Makes sense. I think the buildinfo would be a good start to at least simplify queue reviews, though. :) | 19:49 |
| cjwatson | Hopefully this is obvious, but we'll need tests for your change. | 19:49 |
| tsimonq2 | Sounds good. | 19:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!