| StevenK | wgrant: Running through some examples from http://sage.math.washington.edu/home/wstein/www/home/agc/lit/javascript/xss.html I don't get the JS executed. | 05:01 |
|---|---|---|
| StevenK | Whoa. The iframe works | 05:09 |
| StevenK | That is to say, a comment of '<IFRAME SRC="javascript:alert('XSS');"></IFRAME>' | 05:09 |
| wgrant | There's a good reason I asked you to test it :) | 05:11 |
| wgrant | It may be a bug in your code that I missed, but it's also reasonably likely that there's a buggy librarian involved. | 05:11 |
| wgrant | I do not trust the library authors :) | 05:11 |
| StevenK | The <iframe> JS popup has been the only one that has fired | 05:12 |
| wgrant | Have you tracked down where the leak is? | 05:12 |
| StevenK | Nope | 05:13 |
| StevenK | Something about bubbling | 05:16 |
| cjwatson | wgrant: Er, in as much as I do any of my DB patches. I'm not sure I understand the question | 10:32 |
| wgrant | cjwatson: It looks like the schema from 12 months ago, before it was adjusted so performance wasn't terrible. | 11:01 |
| wgrant | cjwatson: Is there value in splitting LiveFilesystem and LiveFilesystemBuild? | 11:02 |
| cjwatson | I think I just thought that was how it was done based on recipes and translations. But don't we need separate records for The Thing and A Build Of The Thing? | 11:04 |
| wgrant | TTBs don't have two halves | 11:04 |
| wgrant | Recipes are a bit different | 11:04 |
| wgrant | A SourcePackageRecipe may have many SourcePackageRecipeBuilds over years | 11:05 |
| cjwatson | Right, and that's true here too, surely | 11:05 |
| cjwatson | I don't want to have to put the livefs configuration in place (which is basically what LiveFilesystem is) for every daily build | 11:05 |
| wgrant | Er yeah, I was apparently not particularly paying attention when I read that paste. | 11:05 |
| wgrant | Right, other way around, that makes more sense. | 11:05 |
| cjwatson | It's a bit of an unpleasant grab-bag, and possibly it makes more sense to try to have more of those passed per-build from cdimage | 11:06 |
| wgrant | However, you still need to make it look more like binarypackagebuild/sourcepackagerecipebuild/translationtemplatesbuild do today | 11:06 |
| wgrant | The BuildFarmJob table is now an optimisation, mirroring columns from the concrete job table. | 11:07 |
| wgrant | So LiveFilesystemBuild has date_started, status, etc. | 11:07 |
| cjwatson | ok, I may have failed to follow that through. is there a simple-ish way to get a consolidated dump of the current db structure rather than having to read all the patches in sequence? | 11:07 |
| wgrant | Those properties are defined on BuildFarmJobMixin in the code | 11:07 |
| wgrant | \d binarypackagebuild | 11:07 |
| wgrant | Or you can use pg_dump to get the CREATE TABLE, I guess | 11:07 |
| wgrant | Also, LiveFilesystem probably wants an archive column there somewhere. | 11:08 |
| wgrant | And I'd really like to not overload "project", though it's not too bad here I suppose. | 11:08 |
| wgrant | What is that proposed boolean? | 11:08 |
| wgrant | Is it perhaps really a pocket instead? | 11:09 |
| cjwatson | maybe we could spell it image_project for this purpose | 11:11 |
| wgrant | That would probably be better, yeah | 11:11 |
| wgrant | I'm wondering if there's some better name than LiveFilesystem | 11:12 |
| wgrant | Since it sounds like the result of the build | 11:12 |
| wgrant | That's what had me first | 11:12 |
| wgrant | But I guess it's less confusing when you're actually paying attention :) | 11:12 |
| cjwatson | proposed> hm, maybe. the image doesn't go *into* the pocket, though, it's more like a PPA's archive dependencies | 11:12 |
| cjwatson | (though maybe the image *should* go into the pocket) | 11:12 |
| wgrant | Right, but proposed = true doesn't put it anywhere different either. | 11:13 |
| cjwatson | LiveFilesystem - yeah, was the best name I could think of but I'm not totally happy with it, better suggestions appreciated | 11:13 |
| wgrant | Setting PPA dependencies to -backports doesn't mean the binaries don't end up in release :) | 11:13 |
| wgrant | What're they called in the current infrastructure? | 11:14 |
| cjwatson | I think proposed probably ought not to be in the db and ought rather to be a flag passed per-build | 11:14 |
| wgrant | Right, that probably makes sense. | 11:14 |
| cjwatson | since that corresponds well to how it works in the current infra | 11:14 |
| cjwatson | we basically call them live filesystems :-) | 11:14 |
| wgrant | I guess archive could equally be on the build, potentially. | 11:14 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ e.g. | 11:14 |
| cjwatson | the things that need to be in the db are probably those things that distinguish different livefs types we want to continue building alongside each other, and gc etc. | 11:15 |
| cjwatson | archive | 11:16 |
| cjwatson | ? | 11:16 |
| wgrant | Hm? | 11:16 |
| cjwatson | 11:14 <wgrant> I guess archive could equally be on the build, potentially. | 11:16 |
| wgrant | It would seem unwise to hardcode the Ubuntu primary archive; experience have shown that such a decision is often to be regretted. | 11:17 |
| cjwatson | oh, right, um, that would require teaching lp-buildd about that too | 11:17 |
| cjwatson | I take your point; a problem here is that live-build generates the sources.list itself | 11:18 |
| wgrant | Oh, it doesn't use the normal lp-buildd sources.list infrastructure? | 11:18 |
| wgrant | Forgot that detial. | 11:18 |
| cjwatson | we don't really get to insert a full one, it's easier to tell it how to tweak it | 11:18 |
| wgrant | Anyway, best to store an archive now anyway, makes it easier to treat like the rest of the archive-related builds | 11:19 |
| wgrant | Even if the slave implementation means it doesn't completely work right now | 11:19 |
| cjwatson | ok | 11:19 |
| wgrant | So, LiveFSBuild probably wants (id, livefs, archive, distroarchseries, pocket, processor, virtualized, date_created, date_started, date_finished, date_first_dispatched, builder, status, log, failure_count, build_farm_job), plus maybe some denormed attributes for querying later, but those are easy to add. | 11:23 |
| wgrant | Oh, and some way to actually store the results :) | 11:23 |
| cjwatson | er, yeah, *cough* | 11:25 |
| wgrant | Since there are multiple files, I guess just a trivial (livefsbuild, lfa) link table? | 11:26 |
| cjwatson | maybe a notion of type as well | 11:28 |
| wgrant | Unless you want to be more intelligent and stick each type in a separate LFA column on LFB itself | 11:28 |
| wgrant | If there's one of each | 11:28 |
| cjwatson | I'd like to be able to say "give me the latest manifest for livefs <x>" | 11:28 |
| wgrant | But it's been a long time since I looked at cdimage code :) | 11:28 |
| wgrant | Right | 11:29 |
| cjwatson | but also "download all the latest files for livefs <x>" | 11:29 |
| cjwatson | (preferably in a way that doesn't race if it crosses another build) | 11:29 |
| wgrant | But you could then just ask for the latest build for livefs X, then look at its list of files | 11:29 |
| cjwatson | right | 11:29 |
| wgrant | Since lp-buildd doesn't know what files it returns today, and it doesn't seem to provide much benefit for LP to know about them, AFAICT | 11:30 |
| wgrant | I may well be wrong. | 11:30 |
| cjwatson | I also want to be able to make livefs-build-logs keep working, as a permanent archive of all livefs build logs ever, so that'd be "get latest log for all livefses" | 11:30 |
| cjwatson | yeah, possibly it could reasonably just be keyed by filename | 11:30 |
| wgrant | Right, though that's easier, since the log is already privileged. | 11:30 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === _mup__ is now known as _mup_ | ||
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!