[05:01] <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:09] <StevenK> Whoa. The iframe works
[05:09] <StevenK> That is to say, a comment of '<IFRAME SRC="javascript:alert('XSS');"></IFRAME>'
[05:11] <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:12] <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:13] <StevenK> Nope
[05:16] <StevenK> Something about bubbling
[10:32] <cjwatson> wgrant: Er, in as much as I do any of my DB patches.  I'm not sure I understand the question
[11:01] <wgrant> cjwatson: It looks like the schema from 12 months ago, before it was adjusted so performance wasn't terrible.
[11:02] <wgrant> cjwatson: Is there value in splitting LiveFilesystem and LiveFilesystemBuild?
[11:04] <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:05] <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:06] <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:07] <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:08] <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:09] <wgrant> Is it perhaps really a pocket instead?
[11:11] <cjwatson> maybe we could spell it image_project for this purpose
[11:11] <wgrant> That would probably be better, yeah
[11:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:23] <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:25] <cjwatson> er, yeah, *cough*
[11:26] <wgrant> Since there are multiple files, I guess just a trivial (livefsbuild, lfa) link table?
[11:28] <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:29] <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:30] <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.
=== 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