| sil2100 | Hello! | 09:23 |
|---|---|---|
| sil2100 | Does anyone know if I could get a person's upload permissions through launchpad API somehow? | 09:24 |
| sil2100 | Since I'm afraid it's not exported to LP in any way | 09:24 |
| wgrant | sil2100: Sure, though you can only get them on a per-archive basis. See for example the edit-acl tool in lp:ubuntu-archive-tools. | 09:25 |
| sil2100 | wgrant: excellent news then, that's exactly what I would need | 09:25 |
| sil2100 | Let me look it up | 09:25 |
| wgrant | But if you just want to check whether someone can upload a package, use archive.checkUpload instead. | 09:25 |
| sil2100 | Thanks! | 09:25 |
| * sil2100 likes when things are so easy | 09:26 | |
| sil2100 | Yeah, checkUpload seems like the perfect thing, I can just use it when someone will perform an upload for all packages in a silo | 09:28 |
| wgrant | Please don't try to reimplement the upload permission logic yourself. If checkUpload doesn't do exactly what you need, we should adapt it to avoid security issues. | 09:29 |
| cjwatson | Indeed, archive.checkUpload is IIRC what I suggested in Malta when somebody asked in a CI Engine session about checking this externally. | 10:17 |
| cjwatson | wgrant: What do you think of this layout? http://people.canonical.com/~cjwatson/tmp/new-builders.png | 17:34 |
| cjwatson | wgrant: My thinking is that, once scalingstack builders can dispatch both i386/amd64/armel/armhf/arm64 virt and i386/amd64 non-virt, the heading row above them can be two lines and read "Non-virtual: i386 amd64\nVirtual: i386 amd64 armel armhf arm64" | 17:36 |
| cjwatson | wgrant: This sacrifices table sorting, but honestly that was mostly a footgun on that page anyway; "oh, I clicked somewhere random, oh god where did all the builders go, reload page" | 17:36 |
| cjwatson | Hm, might shuffle the names right a little bit and give the icons their own column back. They don't have much mnemonic value, but I do find they help break things up visually a bit. | 18:01 |
| cjwatson | And I hate that sampledata has "386". But you get the general idea. | 18:04 |
| cjwatson | It's a bit non-semantic-web given that it's blatantly tables-for-layout, with the artificial rows. But it's that or multiple tables, I think, and then we have to deal with keeping column widths the same. | 18:08 |
| cjwatson | <tr class="category"> seems to style a bit nicer for this. Updated that image | 18:17 |
| cjwatson | Also have started on the Processor etc. changes needed | 18:46 |
| cjwatson | But EOW now, have a good weekend all | 18:46 |
| wgrant | cjwatson: I don't think they should be labeled as non-virtual at all. | 20:30 |
| wgrant | Rather the x86 Processors have a flag that says they are never virtualised. | 20:31 |
| wgrant | Er, always. | 20:31 |
| wgrant | (but yes, that's roughly how I think the page should look. It may make sense to have filtering, but it's not critical and still much easier to scan) | 20:39 |
| cjwatson | wgrant: to be clear, that screenshot's with the current model; I'm thinking of that as something we could do straight away, that's easier to adapt to the new model | 21:32 |
| cjwatson | I was indeed planning to add Processor.always_build_virtualized - that seems the natural approach | 21:34 |
| wgrant | cjwatson: Right. I'm wondering how that interacts with DAS.supports_virtualized. | 21:35 |
| wgrant | It probably doesn't change the semantics of Processor.restricted. | 21:35 |
| cjwatson | Why was that on DAS to begin with? | 21:40 |
| wgrant | cjwatson: Only some distributions support PPAs, and we used to not enable PPAs for new distroseries until they were usable. | 21:41 |
| wgrant | Distribution now has a flag that could be used to forbid PPA uploads, and new distroseries are less of an issue nowadays. | 21:42 |
| cjwatson | Mm. This is about builder dispatch rather than whether it's a PPA, though. | 21:49 |
| cjwatson | (But yeah, those two used to be conflated.) | 21:49 |
| cjwatson | BinaryPackageBuildSet._getAllowedArchitectures filters out cases where DAS.supports_virtualized and Archive.require_virtualized contradict, so perhaps it would be logically consistent to behave similarly here. | 21:52 |
| cjwatson | That is, if the build farm is set up so that we only do virtual builder dispatch for a processor, and DAS.supports_virtualized is false, you just don't get builds. | 21:52 |
| cjwatson | Or they never get dispatched. | 21:52 |
| cjwatson | The _getAllowedArchitectures semantics would be that you don't get builds at all, I guess. | 21:53 |
| wgrant | They still are conflated to some extent, so the flags are relevant for discussing how this changes things. | 21:54 |
| wgrant | It may make sense to abolish supports_virtualized. | 21:55 |
| wgrant | The unsupported distro filter could then use distribution.official_packages or distribution.supports_ppas. | 21:56 |
| wgrant | The unsupported distro filter could then use distribution.official_packages or distribution.supports_ppas. | 21:57 |
| wgrant | Er, Processor needs supports_virtualized and only_virtualized, or supports_virtualized and supports_nonvirtualized. | 21:57 |
| wgrant | I think it makes sense to have a consistent virtualisation setting on the BuildQueues for a single Archive. | 21:58 |
| wgrant | That is, the flag indicates whether virtualisation is *required*. | 21:58 |
| wgrant | But for Processors with only_virtualized, virtual builders search for non-virtualised builds too. | 21:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
