[12:48] <broder> tumbleweed: i got back to my room and gave up on udd. when i rewrote the backport security/sru checker script in launchpadlib, it took me about 30 minutes and runs in 11 :)
[12:48] <broder> http://pastebin.ubuntu.com/727221/
[13:00] <tumbleweed> broder: :)
[13:41] <kees> broder: source or it didn't happen! ;)
[13:41] <broder> kees: http://paste.ubuntu.com/727242/
[13:42] <broder> i'm working on reformatting it to feed the output into harvest
[13:54] <broder> Laney: do you know why DEP-8 doesn't add any fields to the .dsc file?
[13:55] <Laney> dude
[13:55] <Laney> I had never even looked at that page before this session
[20:26] <tumbleweed> angelabad: congrats :P
[20:28] <angelabad> tumbleweed, thanks! finally... :-D
[20:31] <jdstrand> broder: re backport security/sru checker> oh! excellent, can you ping me when you start using it regularly?
[20:31]  * jdstrand hugs broder :)
[20:32] <tumbleweed> jdstrand: he made that my problem... next on my todo list
[20:32] <micahg> heh
[20:33]  * jdstrand hugs tumbleweed instead of broder 
[20:33] <jdstrand> broder: ;)
[20:33] <jdstrand> tumbleweed: thanks!
[20:33] <ajmitch> lucky you
[20:33] <jdstrand> tumbleweed: so, would you mind pinging me when the backporters start using it regularly?
[20:46] <tumbleweed> jdstrand: I won't know that, but I can tell you when it's up
[20:59] <jdstrand> tumbleweed: that would be great. thanks again
[21:11] <broder> jdstrand: did you see the preliminary output? it doesn't look like there are very many things that need to be re-backported
[21:12] <broder> (i've cleaned up some of the false positives since that edition of the code, but i don't think i've found any false negatives)
[21:14] <broder> and of the packages listed, quassel and clamav have already been handled, so that just leaves libvirt (jaunty->hardy), pidgin (intrepid->hardy), and tomcat6 (intrepid->hardy)
[21:14] <broder> and i think all of those will require some policy discussion from backports
[21:23] <micahg> broder: any desktop backports for hardy can be ignored
[21:24] <broder> ok, so we don't need to worry about pidgin, but we do need an answer for tomcat and libvirt
[21:26] <broder> given that they were backported from releases which are now desupported, i don't know what the right answer is. as a straw man, i propose reviving the security/SRU packages from the desupported releases as being no worse than what's in backports currently
[21:27] <micahg> right, you could also try to backport fixes from lucid if appropriate (or apply ones from hardy as appropriate)
[21:27] <broder> i'm concerned that creates more friction than is necessary
[21:29] <broder> i should probably check my backport-helper script and see if it will even agree to backport from a dead release...
[21:29] <micahg> well, if want the backport properly patched, it would be necessary, if you want the path of least resistance, then you could just take what was done before
[21:30] <broder> backports doesn't provide security support. we shouldn't get into the business of backporting security updates that aren't directly derived from the package that was originally backported
[21:30] <broder> tracking security/SRUs is already stretching that a good degree from what we've done traditionally
[21:31] <broder> valid_series = set(s.name for s in lp.distributions['ubuntu'].series if s.active)> bah. too clever for my own good
[21:37] <micahg> right, it depends how much effort you want to put into it :)
[21:38] <micahg> I'd suggest showing them (maybe aggregated at the bottom), but flagging that they need extra patches from elsewhere (possibly surrounding supported releases)
[21:38] <micahg> *might need
[21:42] <broder> i'll leave them in the report. i'm planning to just spit out a machine-readable report and slurp that into harvest, and we can hide the ones we don't care about solving there