[00:00] <wgrant> Oh.
[00:01] <wgrant> I see why this happens now.
[00:01] <wgrant> There's a proper fix, but this reversion is probably better.
[00:01] <wgrant> (for now)
[00:01] <weather15> why?
[00:02] <wgrant> wallyworld: ^^
[00:02] <wallyworld> wgrant: ?
[00:03] <wgrant> wallyworld: I (and everyone else, it seems) was misunderstanding the code. write_htpasswd is given the name of a temporary file which was just created, with mode 600.
[00:03] <wgrant> Not the old .htaccess file.
[00:03] <wgrant> So this makes sense.
[00:04] <wgrant> I now understand why that patch works.
[00:05] <weather15> no solution to my problem?
[00:06] <wallyworld> thumper: i need that cowboy eyeballed asap. see mp ^^^^^^^^^
[00:06] <wallyworld> thumper: only one losa left and he is waiting
[00:06] <wgrant> weather15: What happens if you try to retrieve testopenid.dev from the server?
[00:06] <wgrant> wallyworld: The MP looks empty to me :/
[00:06] <thumper> wallyworld: looking
[00:06] <wgrant> Ah, there.
[00:06] <wallyworld> wgrant: fixed. i was being dumb
[00:07] <weather15> Service Temporarily Unavailable
[00:07] <wgrant> weather15: You killed 'make run'?
[00:07] <thumper> wallyworld: you aren't really reverting the fix are you?
[00:07] <weather15> wgrant see this: http://pastebin.ubuntu.com/533655/
[00:07] <wallyworld> thumper: no. but that effectively what it does
[00:07] <wallyworld> it a new branch
[00:07] <wallyworld> bad comments i guess
[00:08] <thumper> ah...
[00:08] <wgrant> Preferably don't merge that fix, but please cowboy it.
[00:08] <thumper> what is really changing here?
[00:08] <wallyworld> it will be cleaned up. i justed wanted to get the cowboy done
[00:08] <thumper> wgrant: doesn't open(..., 'w') overwrite?
[00:08] <wgrant> thumper: Yeah, but it doesn't set the mode.
[00:08] <wallyworld> thumper: see pastebin http://paste.ubuntu.com/533638/
[00:09] <thumper> wgrant: so really what is the difference for the cowboy?
[00:09] <wgrant> thumper: What do you mean?
[00:10] <wgrant> thumper: The problem is that write_htpasswd is being called on a tempfile.
[00:10] <wgrant> The tempfile is 600.
[00:10] <abentley> wallyworld: pong
[00:10] <wgrant> thumper: open(..., 'w') truncates, but does not set the mode to the 644 that we require.
[00:10] <wgrant> thumper: This is unobvious, and apparently a drive-by cleanup a week or so ago.
[00:12] <wallyworld> abentley: hi, just was looking for some eyeballs to review a cowboy. see mp a few lines above ^^^^^^ thumper is onto it
[00:12] <mbarnett> if the file doesn't exist at all (in the case of a newly privatized PPA) is the file going to be initially created with the correct permissions?
[00:13] <weather15> wgrant what can I do?
[00:13] <wgrant> mbarnett: That's irrelevant. It creates a new tempfile, writes to that, then renames it over the top of the old one, if any.
[00:13] <wgrant> (to attempt to be atomic)
[00:14] <thumper> wgrant: I just don't see why this is any different
[00:14] <thumper> wgrant: how confident are you that this works?
[00:15] <wgrant> thumper: It deletes the file and creates it again.
[00:15] <wgrant> Umask is 0022
[00:15] <thumper> and the existing file is 600 why?
[00:15] <wgrant> I've tested it locally, and it's just the same as the old code which worked.
[00:15] <wgrant> thumper: Because that's what mkstemp does.
[00:15] <thumper> mbarnett: do the cowboy plz
[00:15] <wgrant> Yay.
[00:16] <wallyworld> thumper: thanks
[00:16] <thumper> wgrant: why is the existing filename mkstemp?
[00:16] <thumper> wgrant: I'm just trying to understand
[00:16] <wallyworld> thumper: did we want the cowboy to become the accepted fix
[00:16] <thumper> wallyworld: probably not
[00:16] <abentley> wallyworld: in fact, it's something that looked wrong when I reviewed the code, and I said so at the time.
[00:17] <thumper> wallyworld: I think it should be looked at as it isn't obviously wrong
[00:17] <wgrant> thumper: generate-ppa-htaccess creates a new temp file (using mkstemp), calls write_htpasswd on it, then renames it to .htpasswd.
[00:17] <mbarnett> thumper: thanks.
[00:17] <wallyworld> thumper: abentley: np. who should i assign the bug to?
[00:17] <wgrant> I can't see the original MP (it's a private branch), but it looks like something which could have been fixed as part of a review.
[00:18] <thumper> wallyworld: don't assign it to anyone
[00:18] <mbarnett> patched
[00:18] <thumper> wallyworld: but pass it on to soyuz
[00:18] <wallyworld> mbarnett: thanks!
[00:18] <mbarnett> now we need to update a subscirption and make sure it worked!
[00:18] <wgrant> mbarnett: Have you fixed existing file modes?
[00:18] <wallyworld> thumper: ack
[00:18] <thumper> wgrant: would it be better to look at the mode of the file rather than depend on the umask?
[00:18] <wgrant> thumper: Of course.
[00:18] <wgrant> And it should be tested.
[00:18] <mbarnett> wgrant: yeah, all were set properly
[00:19] <wgrant> But I lack time to do that right now.
[00:19] <mbarnett> wgrant: re-running my find to make sure no more snuck in
[00:19] <weather15> Traceback (most recent call last):   File "bin/killservice", line 23, in <module>     import lp.scripts.utilities.killservice   File "/home/weather15/launchpad/lp-branches/devel/lib/lp/scripts/utilities/killservice.py", line 25, in <module>     from canonical.lazr.pidfile import ( ImportError: No module named pidfile make: *** [initscript-stop] Error 1
[00:19] <weather15> ???
[00:21] <abentley> wgrant: Yeah, it was considered a security vulnerability that we were publishing private PPAs before setting up their auth.
[00:21] <wgrant> abentley: I know the bug and fix, but I can't see the comments in the MP.
[00:22] <wgrant> I was wondering if the problematic change was a review fix.
[00:23] <mbarnett> no errors in the logs on the subsequent ppa generation runs.  gonna change a subscription now and make sure it is happy
[00:26] <abentley> wgrant: it was.
[00:26] <wgrant> Hah.
[00:28] <abentley> wgrant: rev 11842.1.12 of stable.
[00:30] <wgrant> ... why did I not think to check the revision history.
[00:36] <wgrant> and the build farm seems to still be alive.
[00:49] <wgrant> Is PQM untestfixed at the moment?
[00:52] <lifeless> who knows?
[01:21] <poolie> seiflotfy: hey
[01:21] <seiflotfy> hi poolie
[01:21] <seiflotfy> hi all
[01:21] <poolie> seif is interested in feeding launchpad actions into zeitgeist
[01:21] <seiflotfy> so
[01:21] <poolie> which i think would give an incredible experience
[01:21] <poolie> "that bug i touched the other day"
[01:21] <seiflotfy> Using Zeitgeist as a backend in Launchpad will allow users to have a personal timeline of their activities regarding themselves or specific project. This will allow easier tracker of when things were done commited and view a chronicle of the project in terms of all (blueprints/bugs/etc..) mashed together.
[01:21] <seiflotfy> To do so Zeitgeist will just need 1 minor change which is use a different SQL DB to allow multiple read and write.
[01:21] <poolie> seif i just saw this general topic of zeitgeist-like-things was mentioned in the Economist last week
[01:22] <seiflotfy> really
[01:22] <seiflotfy> where?
[01:22] <seiflotfy> iiiiiiiiiiiiiiiiithe magazine
[01:22] <seiflotfy> sorr
[01:22] <seiflotfy> sorry typo
[01:22] <seiflotfy> sor
[01:22] <seiflotfy> ok
[01:22] <seiflotfy> fixed the keyboard
[01:22] <seiflotfy> sorry
[01:22] <seiflotfy> ok
[01:22] <seiflotfy> ...........
[01:22] <poolie> :)
[01:23] <james_w> seiflotfy, what's the db backend of zeitgeist? Can it be replicated?
[01:23] <seiflotfy> sqlite
[01:23] <seiflotfy> james_w, we have an extension that forwards zeitgeist stuff to couchdb
[01:23] <poolie> seiflotfy: http://www.economist.com/node/17388382?story_id=17388382
[01:24] <seiflotfy> james_w, its easy to exchange the backend
[01:24] <seiflotfy> the trick is in what shoudl be stored
[01:24] <james_w> seiflotfy, so LP could write a different backend to use a more appropriate technology for it?
[01:25] <seiflotfy> yes
[01:25] <seiflotfy> i was thinking of postgre sql
[01:25] <james_w> ok, what would zeitgeist provide in that situation, over some hacked up timeline view?
[01:25] <seiflotfy> james_w, i dont understand you question
[01:26] <james_w> seiflotfy, just trying to understand what benefit using zeitgeist itself would have
[01:26] <mortenmj> hello
[01:26] <seiflotfy> yeah
[01:26] <james_w> I agree that the functionality would be good for LP, but I'm unsure whether the code itself makes sense
[01:26] <seiflotfy> james_w, i dont understand the question though
[01:26] <poolie> if you're talking about having zeitgeist directly access the launchpad pgsq, that's probably not feasible
[01:26] <seiflotfy> no no no
[01:26] <poolie> are you talking about having zeitgeist run on the client, or also having it run in the datacentre?
[01:27] <seiflotfy> poolie, it shoudl run on the datacenter with its own DB
[01:28] <seiflotfy> james_w, the code is stable
[01:28] <james_w> seiflotfy, my concern would be that zeitgeist was designed for activity tracking on desktops. Using it in a webapp is quite different. I want to separate the concept from the implementation.
[01:28] <seiflotfy> and being used by canonical already for unity
[01:28] <seiflotfy> james_w, not really
[01:28] <poolie> how about having lp emit data into couch, in the dc, and then having zeitgeist pull some per-user parts of that?
[01:28] <seiflotfy> we developed it for using it with webapps too
[01:29] <seiflotfy> james_w, i can track twitter stuff easily
[01:29] <seiflotfy> james_w, poolie , zeitgeist supports exchangable backends per default :)
[01:30] <seiflotfy> so the DB where the data is stored is not a problem
[01:30] <seiflotfy> its about how it is stored
[01:30] <seiflotfy> james_w, I already started mapping out how user activities on launchpad will be logged
[01:30] <seiflotfy> and tbh its pretty easy
[01:30] <james_w> I'd suggest that you send it to the mailing list, you'll reach a larger fraction of LP developers that way
[01:32] <seiflotfy> james_w, sure thing
[01:32] <seiflotfy> http://pastebin.ca/1995138
[01:33] <seiflotfy> poolie, this is how a bug report would look like
[01:33] <seiflotfy> i can save this as it is in zeitgeist
[01:33] <seiflotfy> this will allow me to query a timeline for user/project/team/bug
[01:35] <poolie> ok..
[01:35] <poolie> spiv and i might get some lunch, biab
[01:35] <poolie> agree with james, sending it to the list too could be good
[01:35] <james_w> seiflotfy, what about privacy?
[01:36] <seiflotfy> james_w, in which sense
[01:37] <seiflotfy> james_w, its easy to set the privacy issues of who gets to see what as a layer between zeitgeist and launchpad
[01:37] <seiflotfy> its a simple logic
[01:37] <james_w> right, but you need to account for that
[01:37] <james_w> bugs can be private
[01:37] <seiflotfy> depends on how the team is set up
[01:38] <wallyworld> thumper: could you plz stamp this so i can progress it https://code.edge.launchpad.net/~wallyworld/launchpad/person-mergequeue-listview/+merge/41122
[01:38] <seiflotfy> james_w, the logic part for privacy is an issue that should be taken seriously and I agree on that, but its easier than oyu think
[01:38] <seiflotfy> james_w, can u give me the launchpad list
[01:41] <james_w> seiflotfy, I'm not saying it's hard, I'm saying it's a requirement for LP, so if your proposal doesn't mention it then it will be the first objection that people make
[01:41] <seiflotfy> james_w, taken into consideration
[01:41] <seiflotfy> james_w, the problem i dont have it all thought out yet
[01:41] <seiflotfy> i would like to do it with the launchpad team
[01:41] <seiflotfy> think it through with u guys
[01:42] <james_w> https://launchpad.net/~launchpad-dev
[01:45] <seiflotfy> james_w, join the team or write to<EMAIL_ADDRESS>?
[01:46] <james_w> I think you have to do the former to do the latter
[01:50] <seiflotfy> ok
[01:50] <seiflotfy> i am applying to join then
[02:09] <lifeless> [02:09] <lifeless>     Hard / Soft  Page ID
[02:09] <lifeless>      198 /   62  Person:+commentedbugs
[02:09] <lifeless>      138 / 5176  Archive:+index
[02:09] <lifeless>       78 /  267  BugTask:+index
[02:09] <lifeless>       44 /  308  Distribution:+bugtarget-portlet-bugfilters-stats
[02:10] <lifeless>       36 /    1  Bug:EntryResource:newMessage
[02:10] <lifeless>       28 /  267  Distribution:+bugs
[02:10] <lifeless>       26 /   53  Archive:+copy-packages
[02:10] <lifeless>       21 /  135  POFile:+translate
[02:10] <lifeless>       17 /   24  DistroArchSeries:+index
[02:10] <lifeless>       15 /   10  ProjectGroup:+milestones
[02:10] <wgrant> Yay, we aren't winning any more :D
[02:11] <lifeless> sum the two figures ;)
[02:13] <wgrant> :(
[02:28] <poolie> seiflotfy: yeah, privacy seems to be the hard thing
[02:28] <StevenK> wallyworld: Pong
[02:28] <seiflotfy> poolie, not at all
[02:29] <seiflotfy> i think it can be done as a logic between launchpad and the server-zeitgeist
[02:29] <poolie> excellent
[02:29] <seiflotfy> poolie, its pretty easy
[02:29] <wallyworld> StevenK: hi, no matter now. there was an cherry pick i wanted to get eyeballed. all sorted, thanks
[02:29] <seiflotfy> poolie, i am sending out an email to the launchpad and zeitgeist lists
[02:29] <StevenK> wallyworld: I'm not working this week in any case :-)
[02:29] <seiflotfy> this would get us into good discussion :)
[02:29] <wallyworld> StevenK: lucky bastard. you on leave?
[02:30] <StevenK> wallyworld: Yup, until Monday
[02:30] <wallyworld> StevenK: well get off irc then and enjoy your holiday :-)
[02:37] <seiflotfy> poolie, i sent out an email to the dev list :)
[02:39] <seiflotfy> poolie, i am off to bed again
[02:39] <seiflotfy> its 3:40 am here
[02:39] <poolie> ok
[02:39] <poolie> sleep! :)
[02:39] <seiflotfy> n8
[02:41] <poolie> wallyworld: can you have a look at bug 674581
[02:41] <_mup_> Bug #674581: Sourceforge Mercurial Import Fails <hg> <mercurial> <souorceforge> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/674581>
[02:42] <poolie> and say whether it's a dupe or a known limitation?
[02:42] <wallyworld> poolie: ok, i'll look
[02:44] <wallyworld> poolie: not sure - i'm a bit uneducated as yet on this stuff. perhaps thumper could comment? ^^^^
[02:44] <thumper> ah... whut?
[02:45] <wallyworld> thumper: could you take a quick look at poolie's bug above. i can dig further. i thought you may just look at it and know what was happening based on past experience
[02:46] <thumper> wallyworld: most hg imports fail
[02:46] <thumper> around 80%
[02:46] <thumper> bzr-hg is not really going anywhere
[02:46] <wallyworld> ok. so it's a limitation in our importer
[02:46] <thumper> I'm looking at the imports
[02:50] <thumper> wallyworld: the only thing I could suggest is to try the import locally
[02:51] <wallyworld> thumper: thanks. poolie see thumper's comment ^^^^^^
[02:51] <poolie> it's failing to connect to the server
[02:52] <thumper> poolie: I see that, have you tried it locally?
[02:52] <poolie> i can connect tothe url
[02:52] <poolie> i didn't actually try bzr-hg
[03:02]  * thumper tries
[03:07] <thumper> poolie: bzr-hg fails miserably with that import
[03:07] <thumper> I've commented on the bug
[03:07] <thumper> I think that the server is looking at the client type
[03:07] <thumper> hg client works fine
[03:07] <thumper> bzr gets the http redirect
[03:08] <thumper> and so fails on the unknown bzrdir format
[03:08] <thumper> poolie: I added a bzr-hg task
[03:10] <poolie> i see
[04:30] <lifeless> anyone seen 'Module canonical.launchpad.webapp.login, line 440, in expireSessionCookie
[04:30] <lifeless> value = request.response.getCookie(session_cookiename)['value']
[04:30] <lifeless> on launchpad.dev logging in ?
[04:30] <lifeless> TypeError: 'NoneType' object is unsubscriptable<br />'
[04:34] <wgrant> No.
[04:34] <wgrant> I blame Cassandra!
[04:38] <lifeless> hah
[04:38] <lifeless> so, did you gain much from my notes?
[04:41] <wgrant> Mm. It looks good for some stuff (like the session bits you mentioned). But I need to look into it more deeply to see how it could feasibly replace much more than that.
[04:50]  * thumper EODs
[04:58] <lifeless> sinzui: ping
[05:00] <lifeless> wgrant: its what, 4pm for you ?
[05:00] <wgrant> lifeless: 4pm, yeah.
[05:00] <lifeless> hmm, actually, I can just look at my mail in the morning.
[05:00] <lifeless> I have a fix for Person:+commentedbugs
[05:01] <lifeless> Its a one-word fix.
[05:01] <wgrant> Hah.
[05:01] <lifeless> https://code.launchpad.net/~lifeless/launchpad/malone/+merge/41127
[08:32] <adeuring> good morning
[08:46] <henninge> danilos: Hi!
[08:50] <jelmer> wallyworld_, wgrant: Thanks for dealing with the permissions issue crisis! I'm looking at a proper fix now.
[08:51] <wallyworld_> jelmer: no problem at all. i updated the incident report with a few extra details which i also included in the email
[08:53] <jelmer> wallyworld_: Thanks.
[09:17] <bigjools> hello
[09:37] <wgrant> jelmer: Great.
[09:37] <wgrant> jelmer: An unobvious bit of code, that one :/
[09:37] <wgrant> jml: Thanks for landing that.
[09:37] <bigjools> wgrant: my fix seems to have worked
[09:38] <wgrant> bigjools: Yup, looks OK today.
[09:38] <bigjools> no, to work out wtf they take so long to respond
[09:38] <wgrant> bigjools: The "fix" being the removal of failure count assessments?
[09:38] <bigjools> now*
[09:38] <wgrant> Or increasing timeouts?
[09:38] <bigjools> yes
[09:38] <bigjools> nothing would have got failed if the assessment method had been left
[09:38] <wgrant> Huh.
[09:39] <wgrant> Interesting.
[09:39]  * bigjools will land the fix properly today
[09:39] <wgrant> So you increased the TCP timeouts across the board?
[09:40] <bigjools> all xmlrpc connections
[09:40] <wgrant> Hmm.
[09:41] <bigjools> that's the *connection* timeout
[09:41] <wgrant> Can we grab logs from palmer and co. and see what was happening around the time of the timeouts?
[09:41] <wgrant> Also, do we have resource graphs from the non-virt builders? I'm guessing not.
[09:41] <bigjools> yeah I'll sort that out
[09:41] <wgrant> :(
[09:41] <bigjools> we do
[09:41] <wgrant> !
[09:41] <wgrant> Yay.
[09:41] <wgrant> There may be hope yet.
[09:41] <bigjools> as in like the one I showed you for the virtual ?
[09:42] <wgrant> No, I mean load and memory usage and stuff.
[09:42] <bigjools> oh that
[09:42] <bigjools> ummm
[09:42] <bigjools> I'll check
[09:42] <bigjools> do you know which ones (apart from palmer) to save me looking them up? :)
[09:42] <wgrant> All of them, I believe it was.
[09:43] <wgrant> One or two may have survived. But I don't recall which.
[09:58] <jml> wgrant: it did it automatically
[09:59] <wgrant> jml: Huh?
[09:59] <jml> wgrant: I think there was some kind of mail queue delay
[10:00] <wgrant> Ah.
[10:00] <jml> wgrant: because another branch that I had forgotten about also landed.
[10:00] <wgrant> Heh.
[10:00] <jtv> stub: any idea why our makefile has "schema" depending on "clean_codehosting"?
[10:01] <stub> No idea
[10:01] <jtv> Having it depend on build definitely looks like overkill—we don't _really_ need new WADL to build a new DB, do we?
[10:02] <stub> Or should I say 'because that Makefile has become utterly unmaintainable'
[10:02] <jtv> Too late—I'm hacking & slashing at it.
[10:02] <stub> I don't know when we need WADL.
[10:02] <wgrant> jtv: make schema will be deleting branches, so it probably makes sense to clean up their directories too...
[10:03] <jtv> wgrant: make schema deletes branches?  That's surprising.
[10:03] <wgrant> jtv: It resets your DB.
[10:03] <wgrant> So...
[10:04] <jtv> wgrant: I'm waiting with bated breath for you to finish that sentence!
[10:04] <wgrant> jtv: Is Codehosting going to be wonderfully happy if it tries to create a branch and there's already something there?
[10:05] <jtv> wgrant: I still fail to see the connection between that and the DB schema.
[10:05] <wgrant> jtv: 'make schema' will remove all your extra branches. If you create a new one, it's going to use an ID that's already on disk.
[10:06] <jtv> wgrant: nope, I'm still not getting it.  What are my "extra branches"?
[10:06] <wgrant> jtv: Any branches you create on top of the sampledata.
[10:06] <jtv> Oh, you're saying it needs to reset the local codehosting state in conjunction with the schema.
[10:06] <wgrant> Which are probably the same as those that are in the directories that clean_codehosting deletes.
[10:07] <jtv> (Why not the local librarian state though, I have to wonder)
[10:07] <jtv> Yes, schema also depends on clean_codehosting.
[10:07] <wgrant> Hmm. clean seems to remove just about everything except the dev librarian.
[10:08] <wgrant> Oh.
[10:08] <wgrant> schema removes the dev librarian.
[10:14] <jtv> ISTM schema may only need to depend on $(PY) and clean_codehosting.
[10:14] <wgrant> Not even compile?
[10:15] <wgrant> Looks like you may be right.
[10:16] <jtv> I can't see compile doing anything more fundamental than UI-level work.
[10:17] <jtv> Or wait, no, compile also did mailman.
[10:17] <jtv> (Which it could do perhaps 10 seconds faster with a judicious -j option, but the change I have in PQM right now should make that sort of pointless)
[10:18] <jtv> But I imagine mailman is not necessary for what we want from "make schema."
[10:18] <wgrant> I would hope not.
[10:18] <wgrant> Unless something imports it.
[10:19] <wgrant> Which ew.
[10:19] <jtv> We'll see, when my current branch clears PQM.
[10:19] <wgrant> What does it do?
[10:19] <jtv> Not break when you "make -j2" :-)
[10:19] <wgrant> Hah.
[10:20] <jtv> It's a pretty even break between "generate WADL" and "do everything else," so gratifyingly close to a 2× speedup.
[10:20] <jtv> benji & I got worked up about build speeds last night.  He may have a way to skip the half a million optparse "add_option" calls from the WADL generation.
[10:20] <jtv> Unexpected?  It was to me.
[10:21] <jtv> In a 4-minute profiling run of wadl generation, add_option accounted for about one minute.
[10:21] <bigjools> wow
[10:21] <jtv> (Profiling added less than 100% runtime overhead for me, so estimate the gains at 30s)
[10:21] <wgrant> jtv: Oh, last time I tried to profile the WADL generation it didn't finish...
[10:22] <jtv> See?  Things aren't so bad these days!  :-)
[10:22] <wgrant> Heh.
[10:23] <jtv> It could be worth doing separate wadl generation runs for separate API versions, though single-cores shouldn't sniff at the repeated zcml overhead either.
[10:24] <jtv> Ironically, "make" would be just the tool for limiting that job to only the files that need updating.  But the finer details are hidden away in a python script.
[10:24] <wgrant> Yes :(
[10:45] <wgrant> That was quite a mail backlog.
[11:47] <bigjools> jml: did you change something recently in testtools?  I am getting errors about "can't import StartsWith" and I've dist-upgraded and updated-sourcecode...
[11:48] <wgrant> And updated download-cache and remade?
[11:48] <bigjools> I've never had to do that before
[11:48] <wgrant> And the dozens of other dependency mechanisms? :D
[11:48] <bigjools> that's the nice thing about standards, there's so many to choose from
[11:48] <wgrant> But really, testtools is an egg. Update download-cache and run make.
[11:49] <bigjools> utilities/update-sourcecode does all that
[11:49] <wgrant> Doesn't that just update sourcecode?
[11:49] <wgrant> rocketfuel-get is the one that does it all.
[11:49] <bigjools> it just calls the latter
[11:49] <wgrant> I think you have it the wrong way around.
[11:49] <bigjools> last time I looked, anyway
[11:49] <wgrant> rocketfuel-get calls update-sourcecode.
[11:49] <bigjools> that's what I said
[11:49] <wgrant> update-sourcecode pulls everything in sourcecode/
[11:56] <bigjools> make clean seems to have fixed it
[11:56] <bigjools> the Windows solution
[11:56] <wgrant> Oh.
[11:57] <deryck> Morning, all.
[11:57] <bigjools> wotcha deryck
[11:57] <wgrant> bigjools: There was an email about that a week ago.
[11:57] <wgrant> An egg was changed.
[11:57] <bigjools> ahhhhhhh I remember now
[11:58] <bigjools> I fixed it on one box but not my other
[11:58]  * bigjools goes back to tracking down PoolFileOverwriteErrors
[11:58] <wgrant> :(
[11:58] <wgrant> Copies?
[11:59] <bigjools> trying to work that out but I 99% suspect so
[11:59] <wgrant> :(
[12:00] <bigjools> wgrant: https://launchpad.net/~rhpot1991/+archive/ppa/+packages
[12:00] <bigjools> see mythbuntu-lirc-generator
[12:01] <bigjools> I wonder if it's down to .debs moving between sources
[12:05] <wgrant> bigjools: Let's see..
[12:05] <wgrant> That doesn't sound likely.
[12:05] <deryck> *sigh* why do we put up with this internet thing?
[12:05] <wgrant> But this is Soyuz.
[12:06] <bigjools> wgrant: the files were put in the librarian a few hours apart
[12:06] <bigjools> currently hunting down where they are published
[12:06] <wgrant> bigjools: I am confuse.
[12:07] <wgrant> bigjools: That file isn't in any of the other sources in the PPA.
[12:07] <bigjools> 2 files with the same name
[12:07] <bigjools> yep
[12:09] <wgrant> bigjools: Something is really screwed.
[12:09] <wgrant> There was never a binary by that name published.
[12:09] <wgrant> Of any version.
[12:09] <wgrant> On any arch.
[12:09] <wgrant> So WTF is it doing on disk?
[12:10] <wgrant> It's not a half-written file?
[12:11] <bigjools> no idea
[12:11] <bigjools> hmmmm
[12:11] <bigjools> it might be a merged account
[12:11] <wgrant> Ahh.
[12:12] <bigjools> the same file is in rhpot1991-merged
[12:12] <wgrant> That would do it.
[12:12] <wgrant> That is good news.
[12:12] <bigjools> sigh
[12:12] <bigjools> so I can either block merges of persons with ppas
[12:13] <bigjools> or work out htf to merge them
[12:14] <wgrant> I say you should block merges if there are undeleted PPAs on the source.
[12:14] <wgrant> We have no hope of merging them.
[12:15] <wgrant> bigjools: Can we convince the publisher to rename PPAs once it's deleted them, like we do with account deactivation?
[12:16] <bigjools> we'd need to track the old and new names to do that
[12:16] <wgrant> Why?
[12:16] <bigjools> oh - once they are deleted it's fine
[12:16] <bigjools> missed that but
[12:16] <wgrant> Exactly.
[12:16] <bigjools> bit
[12:17]  * bigjools prepares sql to fix data
[12:17] <bigjools> then, I need to solve the double-copy thing
[12:17] <wgrant> Just the one PPA?
[12:17] <bigjools> my life is fun-filled
[12:18] <bigjools> wgrant: argh, there's a PFOE in ubuntu too
[12:18] <wgrant> bigjools: Which file?
[12:18] <lifeless> bigjools: hey
[12:18] <lifeless> can I ask a favour
[12:18] <bigjools> a few
[12:19] <lifeless> https://pqm.launchpad.net/ - see the second job there from me - '[r=lifeless][ui=none][bug=668138] Add a DISTINCT to the commentedbugs subselect for performance.', bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/malone
[12:19] <bigjools> gfortran-arm-linux-gnueabi_4.4.4-9_amd64.deb, gcc-arm-linux-gnueabi_4.4.4-9_amd64.deb, gobjc-arm-linux-gnueabi_4.4.4-9_i386.deb ...
[12:19] <bigjools> well basically all the debs for gcc-defaults-armel-cross
[12:19] <bigjools> lifeless: yo
[12:19] <wgrant> :(
[12:19] <wgrant> That package gave me nightmares.
[12:19] <lifeless> bigjools: that should, in theory, be merged in about 1/2 an hour to an hour
[12:20] <lifeless> bigjools: then buildbot, then qastaging etc
[12:22] <lifeless> bigjools: it should fix our current highest frequency oops - but I'm going to be in transit ...
[12:22] <bigjools> lifeless: you want me to watch it, or what?
[12:22] <lifeless> yeah
[12:23] <lifeless> if it disappears out for some reason, can you resurrect it - it passed ec2 overnight
[12:23] <bigjools> bug 668138]
[12:23] <_mup_> Bug #668138: Person:+commentedbugs timeouts <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/668138>
[12:23] <bigjools> lifeless: sure
[12:23] <bigjools> lifeless: why is that not "in progress" ...
[12:23] <lifeless> when you EOD, if you can tag flacoste or someone
[12:23] <bigjools> yarp
[12:23] <lifeless> great
[12:23] <lifeless> I'll try to check in from airports etc
[12:24] <lifeless> thank you
[12:24] <bigjools> I've subscribed the bug so I will expect a qatagger email
[12:24] <bigjools> np
[12:24] <bigjools> now, back to my thousands of oopses
[12:25] <wgrant> bigjools: So, the package is fairly evil, and epochs are involved.
[12:25] <wgrant> But filename conflicts should still have been caught :/
[12:26] <wgrant> I hate epochs.
[12:29] <bigjools> wgrant: there's a bug somewhere, should be easy to re-create
[12:30] <jml> bigjools: we added StartsWith to testtools recently and removed it from lp
[12:32] <wgrant> bigjools: I don't think we ever check for binary file conflicts on upload...
[12:33] <wgrant> bigjools: We do for copies. And we check that the version isn't older than one already in the archive.
[12:33] <wgrant> But I cannot see a binary file check anywhere :/
[12:35] <bigjools> hmmm
[12:35] <bigjools> I thought there was one
[12:35] <wgrant> So did I.
[12:35] <wgrant> There's one in dscfile
[12:36] <wgrant> And PackageUploadSource does it as well.
[12:36] <wgrant> But not PackageUploadBuild.
[12:37] <bigjools> doesn't the source upload check inspect the debs mentioned in the control file?
[12:37] <wgrant> There is no source.
[12:37] <wgrant> This is a binary upload.
[12:37] <bigjools> in the original source I mean
[12:37] <wgrant> Hmm? You can't get binary details directly from the source.
[12:38] <bigjools> I guess not file names
[12:38] <bigjools> crap
[12:38] <wgrant> You can't get anything at all.
[12:38] <wgrant> Normally they will sort of match.
[12:38] <bigjools> you can get the package name
[12:38] <wgrant> Not necessarily :/
[12:39] <wgrant> It's conventional, but I don't believe policy requires it.
[12:39] <wgrant> And lots of packages violate it.
[12:40] <wgrant> We probably just need to do the binary file check.
[12:40] <wgrant> And thwack people who write packages like that :)
[12:40] <bigjools> yay
[12:44] <lifeless> policy can't require it, because folk have transitional packages and so forth
[12:44] <wgrant> Right.
[12:45] <wgrant> I mean more to thwack people who write packages which duplicate versions.
[12:48] <bigjools> well the lack of a check in the uploader is thwackable
[12:48] <wgrant> Certainly.
[12:48] <bigjools> especially since it's done in the package copier!
[12:48] <wgrant> It's just distressing that it has been missing for nearly five years.
[12:48] <bigjools> sounds like some code refactoring is in order
[12:49] <wgrant> I'd like to push all copies and uploads through PackageUpload, really.
[12:50] <bigjools> mmmm maybe, I dunno
[12:50] <bigjools> need to think about that, because I want to put copies through a job at some point
[12:59] <wgrant> bigjools: I think we probably need to attempt to discuss and think about redesigning all the upload and copy stuff at some point... the current model seems to be creaking.
[12:59] <wgrant> Badly.
[12:59] <bigjools> if you can define exactly where and why it's creaking, yes
[13:00] <wgrant> A few things immediately spring to mind... We have no copy tracking. We unnecessarily reupload files on privacy changes. We have incorrectly duplicated inefficient checking logic. archiveuploader is madness.
[13:02] <wgrant> We ideally want NSS to not suck. And backports would be nice. And we have issues with copying between series and archives with different architectures.
[13:02] <wgrant> And any solutions to these are going to be hacked onto a system that was designed before archives existed, and even before pocket copies were envisioned.
[13:08] <bigjools> reuploading actually helps, it stops the request from timing out when the security team unembagoes something!
[13:08] <bigjools> but yeah, it's unnecessary.  Wish we'd known that at the time.
[13:08] <wgrant> Yeah :/
[13:09] <bigjools> I need fud
[13:18] <lifeless> lp.translations.windmill.tests.test_languages.LanguagesFilterTest.test_filter_languages
[13:18] <lifeless> bb test failure
[13:23] <lifeless> https://bugs.launchpad.net/rosetta/+bug/676980
[13:23] <_mup_> Bug #676980: lp.translations.windmill.tests.test_languages.LanguagesFilterTest.test_filter_languages failing <Launchpad Translations:New> <https://launchpad.net/bugs/676980>
[13:24] <jml> hi
[13:24] <jml> hi
[13:24] <jml> (oops)
[13:24] <gmb> Arrgh. Why does LaunchpadFormHarness use '<IP_ADDRESS>' rather than 'launchpad.dev'? That's odd.
[13:25] <jml> I was just about to raise the test failure issue
[13:25] <jml> lifeless: what should I do about it?
[13:25] <lifeless> jml: you could analyse the test to see if it has race conditions like those fixed in other tests recently.
[13:25] <lifeless> jml: you could run it locally and see if it passes.
[13:25] <lifeless> jml: both of those would be useful to do, I think.
[13:25] <jml> lifeless: you mean, actually address the root cause of the problem?

[13:26] <jml> ok.
[13:26] <jml> I really did have better things to do today.
[13:27] <lifeless> jml: amen
[13:27] <deryck> or we could just disable the windmill tests entirely ;)
[13:28] <jml> deryck: the sky would fall in
[13:28] <deryck> jml, clearly, some are of this opinion.
[13:29]  * deryck isn't afraid of falling sky
[13:29] <lifeless> deryck: oh good morning
[13:29] <deryck> hi lifeless
[13:30] <lifeless> deryck: can you take on the +commentedbug thing I handed off to Julian before - you'll be awake longer, and its right up your alley :)
[13:30] <danilos> lifeless, I don't remember seeing that test fail ever in the past, and I am sure we haven't changed anything remotely related :(
[13:30] <lifeless> danilos: ouch
[13:30] <deryck> lifeless, sure, I don't mind.
[13:30] <lifeless> danilos: I'm sure we'll figure it out soon enough
[13:30]  * deryck looks at scrollback
[13:31] <lifeless> deryck: its in devel now, needs to get to stable, be qa on qastaging and then (assuming all other bits are qa'd) deployed : will fix the highest oops we have :)
[13:31] <danilos> lifeless, yeah, let's see if it's spurious first, and if it is, then really ouch... I prefer reliably failing tests :)
[13:31] <deryck> lifeless, sure, I'll keep an eye on it.
[13:32] <lifeless> deryck: cool
[13:34] <deryck> jml, lifeless, danilos -- there is no timeout value on the assert in the windmill tests.  passing in the past has likely been timing luck.
[13:35] <jml> deryck: I know next to nothing about windmill tests. Got something I can look at to figure out what you mean?
[13:35] <danilos> deryck, quite some luck for roughly 6 months or so since the test was introduced, but I won't dispute it
[13:36] <deryck> indeed, this is browser testing for you ;)
[13:36] <lifeless> ok, must run
[13:36] <lifeless> good luck!
[13:36] <deryck> jml, danilos -- http://pastebin.ubuntu.com/533852/
[13:37] <deryck> jml, danilos -- so what happens is this: there is a page load wait and then the assert, but if the page load is complete but the page not entirely initialized, these sort of asserts can fail.  the timeout buys you some time but can potentially make the test slower.
[13:38] <deryck> however, the assert will pass as soon as the element is available.  so doesn't always wait the full timeout.
[13:38] <jml> deryck: I see.
[13:39] <danilos> deryck, yeah, makes sense, thanks
[13:39] <danilos> deryck, since you've already gone through the trouble, do you mind landing a fix as well? :P
[13:40]  * danilos whistles innocently
[13:40] <deryck> heh
[13:40] <deryck> sure, I can do it.  rs=danilos? :-)
[13:40] <danilos> deryck, yep
[13:40] <danilos> deryck, even r=danilos — I did look at it and see no problems :)
[13:41] <deryck> excellent :-)
[13:41]  * deryck branches and runs test for paranoia
[13:41] <danilos> deryck, assigned bug 676980 to you, thanks again :)
[13:41] <_mup_> Bug #676980: lp.translations.windmill.tests.test_languages.LanguagesFilterTest.test_filter_languages failing <Launchpad Translations:Triaged by deryck> <https://launchpad.net/bugs/676980>
[13:41] <deryck> np at all!
[13:42] <deryck> this is all I've been doing for 3 weeks anyway... trying to get windmill tests to pass. *sigh* ;)
[13:42] <jml> deryck: thanks.
[13:45] <jml> anyone working on bug 636193?
[13:45] <_mup_> Bug #636193: feature flags need to self document <feature-flags> <Launchpad Foundations:Triaged by mbp> <https://launchpad.net/bugs/636193>
[13:49] <bigjools> deryck: disabling windmill.... what a great idea.. :)
[13:49] <deryck> bigjools, you know, no one ever says differently, until you ask on a mailing list about that option. ;)
[13:50] <bigjools> deryck: we're a bunch of 2-faced....
[13:50] <deryck> although, I think we need a new process doc.... if you're in favor of keeping windmill, you are required to do the next lazr-js upgrade branch.
[13:50] <bigjools> lol
[14:16] <lifeless> all hail the great free internet gods
[14:19] <bigjools> wgrant: https://bugs.launchpad.net/soyuz/+bug/66974
[14:19] <_mup_> Bug #66974: Binary versions not checked correctly <boobytrap> <soyuz-upload> <Soyuz:Triaged> <https://launchpad.net/bugs/66974>
[14:19] <bigjools> wgrant: that is an *old* bug :/
[14:33] <deryck> mars, hi.  you learn anything from that test run I sent you yesterday?
[14:35] <mars> deryck, no, unfortunately.
[14:36] <mars> I looked through, and looked at the windmill source code a bit.  Nothing jumped out at me.
[14:36] <mars> But I did find that the socket code was doing something odd
[14:36] <mars> it only logs socket connections after they are connected.  So the connections causing problems may not be logged, or they could be left open
[14:37] <deryck> mars, ok, so what do I do here?  I'm 3 weeks in on this.  rockstar has 3 weeks prior to that.  it's majorly blocking work, but I need to get the new lazr-js in.  How do I get it landed?
[14:39] <mars> deryck, I am thinking about it.  There should be some way around this.
[14:39]  * rockstar votes "dump windmill" and runs away.
[14:44] <mars> deryck, what test did you run that had the thread trash?
[14:44] <mars> deryck, locally, the exact command please
[14:45] <deryck> mars, pick a test, pick any test, ;)  but I did:  xvfb-run ./bin/test -cvvt test_bug_commenting
[14:45] <deryck> mars, the bug commenting test runs pretty quickly, which is why I picked it.
[14:46] <mars> deryck, I am going to trying running it through wireshark, maybe that will catch something
[14:47] <deryck> mars, ok.  I'll just hang out and wait on you.  Thanks for the help!
[14:53] <mars> jml, around?  danilos just sent a list mail about a testtools failure in a twisted test case.  It sounds like something you may know about?
[14:53] <jml> mars: it's not a testtools failure
[14:53] <lifeless> jml: whats the tag to say 'this is a feature request'
[14:53] <danilos> lifeless, "feature" :)
[14:53] <jml> lifeless: feature, iirc. there's a wiki page w/ bug tags
[14:54] <lifeless> jml: I feel a strong desire to mark all 'feature' bugs as wishlist.
[14:54] <lifeless> jml: but I'm restraining myself.
[14:54] <jml> lifeless: thank you
[14:54] <mars> jml, ah, by 'testtools failure' I meant 'it may be something to do with testtools', not within testtools itself
[14:54] <jml> mars: it doesn't have anything to do with testtools
[14:54] <danilos> lifeless, well, we've basically stopped using wishlist priority and usually mark feature bugs as 'low' instead
[14:54] <mars> my mistake
[14:54] <lifeless> jml: thank you for restraining myself :) ?
[14:54] <jml> lifeless: yes.
[14:55] <lifeless> jml: you're welcome
[14:55] <lifeless> danilos: why don't we use wishlist?
[14:55]  * jml so does not have headspace for this discussion right now
[14:55] <danilos> lifeless, because it's orthogonal to priorities, I guess... but it was an ancient discussion and I don't remember the specifics anymore; I am sure sinzui does, though :)
[14:56] <lifeless> jml: for reference - https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=High&field.tag=-feature
[14:57] <sinzui> lifeless, https://dev.launchpad.net/BugTriage
[14:58] <sinzui> lifeless, ^ since there are three states, and Lp defines the use of critical, we have two importance states left, high, because we only work on high things, and low, because we might do fix the issue in the future
[14:58] <lifeless> sinzui: that diesn't discuss wishlist at all
[14:59] <lifeless> sinzui: I'm fine with not using medium - there is a similar experiment running in testtools and related projects.
[14:59] <lifeless> however, I'm not sure bugs /are/ a work queue. Nevertheless - thanks for the link
[14:59] <sinzui> I use medium in my own projects. I rejected critical
[15:00] <sinzui> I want real words. do now, do soon, do when at an opportunity
[15:02] <lifeless> sinzui: I think thats a different concept to bugs per se, but related.
[15:02] <lifeless> anyhow, I have to go through security, I hope to be back online again in a bit
[15:11] <jml> mars: oh, I'm sorry, I didn't see the *actual* error that's in the full log but not the email
[15:13] <mars> jml, no problem, I should not have punted to you without understanding it first myself
[15:28] <mars> deryck, argh, I keep running into the 'text=bytea' problem.  I can't even run launchpad.dev :(
[15:29] <mars> this after a database drop and rebuild
[15:31] <mars> back to code inspection, maybe that will spark something
[15:37] <deryck> mars, ok.  I didn't have that issue.
[15:49] <deryck> mars, are you running against my branch?
[15:49] <mars> deryck, yes
[15:50] <deryck> mars, ok, cool
[15:57] <jml> danilos: answered. hopefully enough for you to go on.
[15:57] <danilos> jml, thanks
[15:57] <danilos> jml, I've ran the tests locally already, and just submitted directly to pqm
[15:59] <jml> danilos: are you going to try to address the problem?
[16:00] <mars> deryck, I am looking at the windmill.server.https code now, maybe there is some way to figure out which threads are still around, and why
[16:00] <mars> deryck, taking an early lunch, back in a little while
[16:00] <danilos> jml, most likely not, since I'm off after tomorrow and I got a few pressing issues for today and tomorrow
[16:00] <jml> :(
[16:01] <jml> well, maybe someone else will pick it up
[16:01] <deryck> mars, ok, on call.  talk to you soon.
[16:44] <EdwinGrubbs> leonardr: ping
[16:51] <jml> james_w: do you know if https://bugs.launchpad.net/launchpad-code/+bug/365098 has been fixed?
[16:51] <_mup_> Bug #365098: Anyone who can write to a sourcepackage should be able to set the official package branch <package-branches> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/365098>
[16:51] <james_w> I don't think so
[16:51] <jml> ok.
[16:51] <jml> thanks
[16:52] <leonardr> edwingrubbs, hi
[16:55] <EdwinGrubbs> leonardr: I was wondering if I should just add some parameters to a REST method to slice it, or if can re-use the REST API's ability to slice collections. I would just convert the method to a collection, but it has other parameters.
[16:57] <leonardr> EdwinGrubbs: if your method returns a resultset, it should already be sliceable
[17:00] <EdwinGrubbs> leonardr: right now, it returns a list so that only one call is necessary to get all the data that the timeline graph needs. Would I be able to use a DecoratedResultSet, or does each item in the result need to be an exported entry?
[17:01] <leonardr> EdwinGrubbs: a list should also be sliceable, but at that point what's the point? are each of these items huge?
[17:04] <EdwinGrubbs> leonardr: each item is not huge. If it just needs to be sliceable, then the DecoratedResultSet should work.
[17:04] <leonardr> EdwinGrubbs: yes, or just returning a list should also work
[17:04] <leonardr> try it and see
[17:37] <bigjools> leonardr: can I poke you about a webservice problem for a moment?
[17:51] <leonardr> bigjools, sure
[17:51] <bigjools> leonardr: thanks - you reviewed a branch of mine a while ago and I am just getting around to land it
[17:52] <bigjools> https://code.edge.launchpad.net/~julian-edwards/launchpad/api-expose-builders/+merge/39379
[17:52] <bigjools> I've not changed it and it's now failing tests: http://pastebin.ubuntu.com/533928/
[17:52] <bigjools> I can't figure out why
[17:52] <leonardr> ok
[17:53] <bigjools> I suspect some wadl problem but I've done "make clean;make" before running the test
[17:54] <leonardr> bigjools: yes, you'd get that problem if nopriv_launchpad was using an old wadl. do you have any caches from launchpad.dev in your ~/.launchpadlib?
[17:54] <leonardr> it would be a bug for the testrunner launchpadlib to look there, but it could be happening
[17:54] <bigjools> I am getting deja vu
[17:55] <bigjools> yes there's a cache there
[17:55] <leonardr> remove that cache and see what happens
[17:56] <bigjools> ok, running ...
[17:56] <leonardr> if it works, then file a bug against launchpad saying that launchpadlib_for is still looking in .launchpadlib instead of a temp directory. it might be something that can be fixed by upgrading launchpad's version of launchpadlib, or it might have been _caused_ by upgrading launchpad's version of launchpadlib so the order of arguments are different
[17:56] <bigjools> ok
[17:57] <bigjools> still failing :/
[17:57] <bigjools> I removed ~/.launchpadlib/api.launchpad.dev/
[17:58] <leonardr> bigjools: ok, step into launchpadlib_for and see what cache directory it comes up with
[17:58] <leonardr> then, keep an eye on that cache directory
[17:58] <leonardr> look at the wadl and see if 'builders' is mentioned
[18:02] <bigjools> leonardr: the code has "cache = tempfile.mkdtemp ...."
[18:02] <dobey> hey guys. does the source package recipe builder stuff not use the same buildds as PPA builds to build the source packages?
[18:03] <bigjools> dobey: why do you say that?
[18:03] <dobey> bigjools: https://code.edge.launchpad.net/~ubuntuone-hackers/+recipe/protocol-dailies/+build/7779
[18:03] <bigjools> dobey: natty is not ready for recipe builds
[18:06] <dobey> bigjools: what is prevening it from being "ready" exactly? it makes it hard to build dailies for the ubuntu development release :-/
[18:06] <bigjools> dobey: talk to abentley
[18:07] <dobey> abentley: hi. :) ^^ what's blocking source recipes from working on natty?
[18:08] <abentley> dobey: What's preventing it from being ready is that bigjools thinks maybe it caused the build farm failures of a couple weeks ago.
[18:08] <abentley> bigjools: Success with memory limit on recipe build: http://librarian.dogfood.launchpad.net/57529959/buildlog.txt.gz
[18:08] <abentley> https://code.dogfood.launchpad.net/~abentley/+recipe/test/+build/4803
[18:08] <dobey> hrmm
[18:09] <bigjools> abentley: nice
[18:09] <bigjools> abentley: the new manager is better about timeouts now so we should try again tomorrow
[18:09] <bigjools> well, when I get it rolled out tomorrow
[18:09] <abentley> bigjools: I thought the new manager was already rolled out?
[18:10] <bigjools> cowboyed
[18:10] <bigjools> well - the timeout fix to it is cowboyed
[18:10] <bigjools> the fix landed today on devel
[18:10] <bigjools> I'll roll it tomorrow
[18:11] <abentley> bigjools: cool.  I'll get this rlimit branch reviewed, and we can throw that in the mix, too.
[18:11] <bigjools> leonardr: "builders" is not in the wadl that's in the cache dir :/
[18:11] <leonardr> bigjools: in that case your top-level collection is not being properly published
[18:11] <bigjools> leonardr: I wonder if the recent interfaces apocalypse broke it - I bet that's it actually
[18:11] <bigjools> I need to register it in the zcml
[18:12] <bigjools> abentley: excellent - we can coordinate tomorrow
[18:12] <bigjools> thanks for the help leonardr
[18:13] <leonardr> sure
[18:13]  * bigjools -> fud
[18:14] <Ursinha> bigjools, after fud... could you please give your ideas on bug 673985?
[18:14] <_mup_> Bug #673985: Provide a way to mark something as QA done before it was landed <qa-tagger:New> <https://launchpad.net/bugs/673985>
[18:17] <dobey> leonardr: btw, i added the print of the team object yesterday, and it still failed, but the object was valid and pointed at the right thing. trying a 3 second sleep now to see if that helps at all.
[18:17] <leonardr> dobey: remind me what the exact problem was?
[18:18] <dobey> leonardr: the two calls to getMembersByStatus
[18:18] <jml> the planet is down :(
[18:23] <abentley> jml: And the sky is up.  Unless you're in Australia :-)
[18:23] <jml> abentley: :D
[18:36] <jml> I'm off for the day. Tomorrow, email email email and maybe some naughty programming.
[18:37] <leonardr> dobey: i don't have any advice beyond stepping through the code and seeing what's different about the data structure or the code execution path in the first time vs. the second time
[18:38] <dobey> leonardr: right. i was just letting you know where i was at now :)
[18:38] <leonardr> sure
[18:42] <deryck> bdmurray, ping
[18:44] <bdmurray> deryck: hey
[18:45] <deryck> bdmurray, hey.  So we're expiring Ubuntu bugs now each day.  Doing 200 a day as we discussed....
[18:45] <deryck> bdmurray, and I'll let this run for about month until we clear the ~6000 bug backlog.
[18:45] <bdmurray> deryck: right
[18:45] <deryck> bdmurray, and then we'll open it up to expire for every project.
[18:45] <deryck> bdmurray, so if you see any issues, let me know.
[19:05] <deryck> mars, hi.  Any luck on my branch?  (he says too anxiously) :-)
[19:05] <mars> hehe
[19:07] <mars> deryck, I had some time to think about it.  The problem is figuring out which threads are still around, and why
[19:08] <deryck> mars, right.  That's where I got stuck, too.  I pdb'ed into the middle of windmill.server.https and just couldn't figure out how to work that out.
[19:08] <mars> deryck, I was thinking, as a first step, could we debug the https server to print a threadID whenever a new thread is started, and again when it is told to shut down?
[19:09] <mars> deryck, and a threadid when it makes a socket connection
[19:09] <mars> that way you could see "tID 2: started; tID 2: http://blah; tID2: stopping"
[19:09] <deryck> sure, that makes sense to me.
[19:09] <mars> any thread that does not print "stopping" is a problem
[19:10] <deryck> right
[19:10] <deryck> mars, are you trying this now?
[19:10] <mars> I dislike this approach, it's dirty, inelegant, but it might work
[19:10] <mars> deryck, I thought about it.  Do you think you could try patching for it?
[19:11] <deryck> mars, I don't think I understand where windmill is starting and stopping threads completely, but I can try to work it out.  Also, I had issues with print statements being swallowed earlier and had to pdb to get at objects.
[19:12] <mars> deryck, try printing to sys.stderr, it should work
[19:12] <deryck> ah, ok
[19:12] <mars> deryck, perr = functools.partial(print, file=sys.stderr)
[19:13] <deryck> ok
[19:13] <deryck> mars, thanks.  That gets me going again.  Will try again here in a second.
[19:14] <mars> deryck, no problem.  I think windmill.server.https is the right place to start.  Each server instance is a ThreadingMixin, so you will have a bunch of them.
[19:14] <deryck> right, that's what I thought, too.
[19:14] <mars> thankfully that part is close to the standard library,
[19:16] <mars> deryck, ah, just saw WindmillHTTPServer.process_request() (line 433).  It calls thread.start().  That is one good option to begin at.
[19:17] <deryck> mars, gotcha.  Thanks.
[19:17] <mars> deryck, let me know how it goes.  I am going to start hacking on my other deadline-driven work.
[19:17] <deryck> will do
[19:39] <EdwinGrubbs> mars: do you happen to remember where we configure certain object types not to be security proxied?
[19:39] <mars> EdwinGrubbs, sorry, I have no idea
[19:39] <EdwinGrubbs> sinzui: ^^^
[19:39] <deryck> thumper, ping
[19:40] <mars> EdwinGrubbs, pick an object you know is not proxied, then grep the ZCML for it?
[19:40] <sinzui> Edwin Utility verses SecuredUtility in ZCML
[19:43] <jamesh_> sinzui: that just determines whether the returned utility is security proxied.  It doesn't set a policy for a class
[19:43] <EdwinGrubbs> sinzui: yes, but a dict, str, and I believe some other classes we have specified do not get security proxied when they are returned from a secured utility.
[19:43] <jamesh_> EdwinGrubbs: there is some Python code that does this for a Storm type in storm/zope/__init__.py
[19:45] <EdwinGrubbs> jamesh_: thanks
[19:56] <dobey> leonardr: ah-hah. i've found the problem
[19:56] <leonardr> dobey: ?
[19:57] <dobey> leonardr: foo = team.getMembersByStatus(); foo.extend(team.getMembersByStatus())
[19:57] <dobey> leonardr: apparently the .extend() there causes launchpadlib to attempt to alter the list via the API
[19:58] <dobey> leonardr: which of course fails (though the traceback is whacky)
[19:58] <leonardr> dobey: so it thinks that 'extend' is a webservice method?
[19:59] <dobey> leonardr: i guess. if i do foo = [x for x in team.getMembersByStatus()] to assign it, and then do foo.extend(team.getMembersByStatus()) after, it seems to work
[20:00] <leonardr> ok, good to know
[20:01] <dobey> leonardr: is that a bug i should file against lplib/wadllib/restfulclient? or is it just me trying to be too clever and i shouldn't do that?
[20:02] <leonardr> dobey: i think you're trying to be too clever. objects you get from the web service play by different rules than normal python objects, and part of our next project is making this more clear
[20:03] <dobey> ok
[20:08] <deryck> booyah!  I have some knowledge now, mars!
[20:09] <mars> deryck, great!  What did you find out?
[20:09] <deryck> mars, so all the threads that are left behind are the launchpad.js file.
[20:10] <deryck> mars, http://pastebin.ubuntu.com/533988/
[20:10] <mars> I thought we used lp.js now?
[20:10] <deryck> mars, it's called launchpad.js, I thought.
[20:11] <deryck> mars, lp.js is a file in lp.app.javascript
[20:11] <mars> ah
[20:11] <mars> deryck, please please /please/ send me patch that made this possible :)
[20:11] <deryck> mars, and launchpad.js on disk is 1.3 Mb now.
[20:12] <deryck> about 450k compressed.
[20:12] <mars> ok, that's a bit better
[20:12] <deryck> mars, presumably windmill is trying the compressed form, right?  but I guess the browser and/or server is hanging making sense of it?
[20:13] <mars> hmm, could be.  I wonder, it must be working, right?  Otherwise the page would not function.
[20:13] <mars> deryck, that is the only javascript file?
[20:14] <mars> no, Mochikit.js as well
[20:14] <deryck> mars, but it is the only js file when not in devmode that we build.  and playing locally in devmode or not, everything works fine.  Thought in devmode the browser can slow in firebug because of all the individually linked files.
[20:15] <deryck> mars, meant only file besides mockikit
[20:16] <deryck> mars, and here's my windmill patch to make all this noise.  :-)  http://pastebin.ubuntu.com/533990/
[20:20] <deryck> mars, does this suggest our only way forward is making the file smaller or getting dynamic loading via a combo loader working?
[20:34] <mars> deryck, I am not sure
[20:35] <mars> if that suggests the only way forward
[20:35] <deryck> ok
[20:35] <mars> deryck, did the file size change much across versions?
[20:35] <deryck> mars, oh way bigger.
[20:35] <mars> ?
[20:35] <mars> why?
[20:35] <mars> did the YUI core grow?
[20:35] <deryck> yes, many more files now.
[20:36] <deryck> they assume combo loading not concating. :-)
[20:36] <mars> so we may need to look at unloading some stuff from our own bundle then
[20:36] <mars> new functionality that we do not need
[20:37] <deryck> yeah, that's one way.
[20:37] <deryck> I can consider the options now. at least I know what's going on.
[20:39] <LPCIBot> Project devel build (228): FAILURE in 3 hr 42 min: https://hudson.wedontsleep.org/job/devel/228/
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=danilos][ui=none][bug=676980] Fix up a translation windmill test
[20:39] <LPCIBot> to be more stable by adding a timeout value to an assertProperty.
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=EdwinGrubbs][r=benji][ui=none][bug=318842][bug=383615][bug=488491]
[20:39] <LPCIBot> Enable tests.
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][no-qa] Changes to
[20:39] <LPCIBot> cron.publish-copy-archives copied from the actual changes made
[20:39] <LPCIBot> in production to get it working
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][no-qa] launchpad-buildd updates for
[20:39] <LPCIBot> SIGILL to not automatically retry the build
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=jelmer][ui=none][bug=676479] Make XMLRPC connections to builder
[20:39] <LPCIBot> slaves respect the config's timeout value. Also add more logging.
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=benji,edwin-grubbs][ui=none][no-qa] Support "make -j2"
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=668138] Add a DISTINCT to the commentedbugs
[20:39] <LPCIBot> subselect for performance.
[20:39] <LPCIBot> * Launchpad Patch Queue Manager: [r=benji,
[20:40] <LPCIBot> edwin-grubbs][ui=none][bug=676489] fix bug 676489 by adding code in
[20:40] <LPCIBot> the apache log parsing to handle a space in the path.
[20:40] <_mup_> Bug #676489: librarian apache log parser failing to parse bogus line in access log <librarian> <oops> <Launchpad Foundations:Triaged by gary> <https://launchpad.net/bugs/676489>
[20:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][no-qa] Add person merge queue listing page
[20:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap,gmb][ui=none][bug=594247] use JOIN and LEFT JOIN to link
[20:40] <LPCIBot> tables needed to search for bugtask releated to a structural
[20:40] <LPCIBot> subscriber;
[20:40] <LPCIBot> refactoring of BugTaskSet.search() and BugTaskSet.serachBugIds();
[20:40] <LPCIBot> more tests for BugTaskSet.search()
[20:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][ui=none][bug=675562] Fail requests for master stores if we
[20:40] <LPCIBot> are in read-only mode,
[20:40] <LPCIBot> no matter what database policy is currently installed.
[20:40] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=654372] Optimise source domination down from a
[20:40] <LPCIBot> few minutes to less than a second.
[20:40] <rockstar> Thanks LPCIBot.  I was trying to read mars and deryck's conversation...
[20:40] <mars> lol
[20:42] <mars> I wonder why IRC bots aren't aware when a conversation is going on - they could just wait 10 seconds for an idle moment in the channel
[20:42] <benji> good point, mars
[20:43] <rockstar> deryck, mars, so, YUI's *-min files concatenated together, the files are about 850K
[20:44] <EdwinGrubbs> leonardr: I'm not sure if you would consider this a bug, since I can get around the issue by returning a DecoratedResultSet of IEntry objects instead of dicts. ResourceOperator.should_batch() decides not to batch list objects, which is why a list of dictionaries is encoded fine, but a DecoratedResultSet of dicts does not work.  BatchingResourceMixin.batch() pukes on dicts in result sets because it tries to call checkPermission()
[20:44] <EdwinGrubbs>  and EntryResource() on the dict. For some reason, checkPermission() blows up because it tries to pass the dict to weakref.ref().
[20:44] <mars> rockstar, IIRC we rolled our own bundle before
[20:44] <deryck> rockstar, plus all our files.
[20:44] <rockstar> deryck, mars, yeah, this is WITHOUT lazr-js (I've just submitted the lazr-js abandonment branch to PQM)
[20:45] <rockstar> mars, deryck, roll your own bundle is actually rather complicated now, since the dependency graph is a little frustrating to follow in any scale.
[20:45] <mars> :(
[20:45] <deryck> rockstar, what do you mean send to pqm?  You've another yui upgrade branch?
[20:45] <leonardr> edwingrubbs: in general our support for named operations that return lists of non-entries is poor
[20:45] <EdwinGrubbs> leonardr: I guess the security proxy knows not to bother calling checkPermission() on dicts, so maybe the REST API should copy its logic.
[20:45] <rockstar> deryck, sorry, I'm working in the U1 context now...
[20:45] <deryck> ah
[20:45] <mars> rockstar, deryck, not fun.  We are fighting the grain of the library then.
[20:45] <deryck> we need to get a proper loader going.  tis the one true way
[20:46] <leonardr> EdwinGrubbs: go ahead and file a bug, i don't think we'll get to it for a good while though
[20:46] <rockstar> mars, deryck, this is not a bug that's ever going to get fixed, I suspect.
[20:46] <EdwinGrubbs> leonardr: ok, thanks
[20:46] <mars> deryck, that would be nice, but we need to find one possibly lame way if we want to land your patch right now :)
[20:47] <mars> rockstar, what but isn't going to get fixed?
[20:47] <mars> bug
[20:47] <poolie> hi all
[20:47] <mars> Hi poolie!
[20:47] <rockstar> mars, the 512K bug.
[20:47] <mars> right
[20:47] <rockstar> mars, did I tell you that mikeal said "windmill is dead?"
[20:47] <mars> rockstar, I disagree.  I think it will be fixed, but it will be 5 years from now :)
[20:48] <mars> rockstar, yes, we discussed that
[20:48] <rockstar> mars, no one is working on windmill anymore.
[20:48] <mars> rockstar, wait, was the 512K bug in windmill, or in Firefox?
[20:48] <rockstar> mars, I know I keep banging this drum, but windmill is not the tool of the future.
[20:49] <rockstar> mars, it was in windmill, because we could run in the non-devmode and it worked fine for us.
[20:49] <mars> rockstar, that may be true, and I am all for investigating other alternatives, but I don't think tossing out windmill will help us land the YUI 3.2 patch right now.
[20:50] <rockstar> mars, I don't see why it wouldn't.  Windmill is what's blocking the landing.
[20:50] <mars> that should read, I don't think we can take tossing out windmill as an option to get this patch landed
[20:50] <rockstar> mars, so then we wait until the next time someone needs to update the javascript
[20:51] <mars> rockstar, you mean, we will have to wait until then to evaluate and replace the tool?
[20:52] <deryck> I think we need to sort out the tool asap, and I also don't think the tool gains us that much right now. ;)
[20:52] <rockstar> mars, well, if we don't do something drastic, we'll continue to roll our own.
[20:52] <rockstar> mars, deryck, it's on my list of things to do for the next six months to set up our own combo loader.  This might help in the future.
[20:53] <deryck> so I think in the short term, I'll see what files we can exclude.  But this is non-trivial, too.  Requires build changes, even if minor build changes.
[20:53] <rockstar> mars, deryck, just today, beuno and I weighed the cost of rolling our own yui v. just having a larger file, and we just decided on the larger file, because rolling your own becomes a maintenance nightmare.
[20:53] <mars> deryck, I think you just have to change the file list in base-template-macros, no?
[20:53] <deryck> I thought it was just a for file in dir: concat script.
[20:53] <rockstar> deryck, you know how I feel about this.  As we workaround it this time, we forget about it until we hit it again, and then we try and work around it again.
[20:54] <deryck> but maybe it gets the list from the base macro template.
[20:54] <deryck> rockstar, you know I *totally* agree :-)
[20:54] <deryck> these tests aren't even really very good.
[20:54] <deryck> I don't think they gain us anything.
[20:54] <deryck> but I've said all this before ;)
[20:55] <deryck> well, gain us much. ;)
[20:55] <lifeless> afternoon :)
[20:55] <rockstar> deryck, so you can roll your own, but be prepared for some really obscure errors.
[20:56] <deryck> rockstar, yeah, I'm not found of this option either.  But I don't see I have any other option.  It's disable tests or roll my own smaller file (and hope for the best).
[20:56] <rockstar> deryck, also, make sure you run with filter: 'debug' in your LAZR_CONFIG, otherwise, you won't see breakages.
[20:56] <rockstar> deryck, I'm not convinced that we can get much smaller.  We have A LOT of javascript.
[20:57] <mars> deryck, fwiw, if we had some insight on browser-level testing from U1, Landscape, ubuntu.com/ISD, or current industry best practice, then cool.  But it will take that level of investigation to convince everyone to toss the tool out.
[20:57] <mars> rockstar, deryck was saying the YUI core grew between versions - that is features, isn't it?
[20:58] <mars> we may need to switch to -base.js everywhere
[20:58] <mars> and then build up
[20:58] <deryck> mars, I disagree. No one understands the tool or any other option.  There is just fear and paranoia.  I'm not willing to do such research for a pointless lost argument...
[20:58] <deryck> mars, and it's too much to change on my own.
[20:58] <deryck> i.e. a weekend hacking to proof of concept.
[20:59] <mars> right, I understand
[20:59] <rockstar> mars, well, not entirely, and some of those features are for new core things.
[20:59] <rockstar> mars, remember, we're going from 3.0 to 3.2.  That's a pretty big jump.
[20:59] <mars> deryck, fwiw, I picked windmill in the first place (2 years ago now).  If you want, I can explain the reasoning some time.
[21:00] <rockstar> Anim, for instance, now wants to use Transition in some browsers.
[21:00] <deryck> mars, no, that's ok. :-)  I'm not against your original choice.  There are things I quite like about windmill even....
[21:00] <mars> rockstar, yeah, and unfortunately I have not been tracking the library - I don't know much about the changes
[21:00] <deryck> mars, I'm against the blind loyality to a system that at this point doesn't provide us much.
[21:00] <poolie> jam: aren't there two north american losas?
[21:00] <jam> As I understand it
[21:00] <poolie> jam, here, unless it's private
[21:00] <mars> poolie, Chex and mbarnett
[21:00] <jam> I'm not sure why mthaddon is the primary one working on my request
[21:00] <jam> I assume it is a comfort level thing?
[21:01] <jam> He's the only one who has posted to the rt
[21:01] <deryck> anyway, I need to EOD mars and rockstar.  I'll see what I can work out tomorrow.
[21:01] <rockstar> deryck, okay, keep me posted.
[21:01] <poolie> bye deryck
[21:01] <mars> deryck, I agree, and I am for evaluating alternatives - all software has a lifecycle.  (Even zombies like Emacs and vi!)
[21:01] <deryck> lifeless, I think your branch is still playing in buildnot.
[21:02] <deryck> heh, didn't mean that typo.
[21:02] <mars> hehe
[21:02] <rockstar> mars, mikeal said that basically everything they hated about Selenium when they started Windmill is basically fixed now.
[21:02] <lifeless> deryck: kk
[21:02] <deryck> but one last thing on this....  it's not *just* the tool.... it's that we have no idea why to even use the tool.  browser testing can't be approached like unit testing.
[21:03] <mars> deryck, good point
[21:03] <deryck> we will end up with the same crappy tests run by another tool
[21:03] <mars> :D
[21:03] <mars> funny, and true
[21:03] <deryck> which is why I advocate disabling the tests. :-)  Kill the pain.  Get on with work, and figure out to how to do this right before trying again.
[21:03] <rockstar> mars, U1 is probably going to go with YETI.
[21:04] <mars> rockstar, no idea what that is
[21:04] <mars> something else that needs shaving
[21:04] <mars> ?
[21:04] <deryck> anyway, bye all.
[21:05] <rockstar> mars, YETI = Yahoo Easy Testing Interface. It's how the YUI tests get run.
[21:05] <jam> poolie: as an aside, I haven't seen any real l-osa interaction on any channel other than -ops, and even then I've gotten misses (though probably if I haven't heard a response in 30min, I should just send it again)
[21:05] <mars> rockstar, got it: http://yuilibrary.com/projects/yeti/
[21:06] <rockstar> mars, yeah.  It's more for pre-commit tests than it is for CI.
[21:06] <mars> "Yeti is designed to help you run tests before you commit. It compliments existing CI tools like Selenium and Hudson which run tests post-commit. Yeti is not a replacement for those tools."
[21:06] <rockstar> But I don't see why it can't also be used for CI, but reid advised against it.
[21:07]  * lifeless looks for another handoff
[21:07] <mars> rockstar, windmill and stuff test the full house of cards - that is why we started using them, and why they fall over all the time
[21:07] <poolie> jam, like francis said, they're just swamped
[21:07] <poolie> perhaps it's worth just shelving it entirely until they can give you some dedicated time?
[21:08] <rockstar> mars, yeah, but windmill was actually developed for CI type tests.
[21:08] <poolie> hi flacoste
[21:08] <flacoste> hi poolie
[21:08] <rockstar> And the tests we wrote for it are very much CI type tests.
[21:08] <jam>  /wave
[21:08] <flacoste> hi jam
[21:08] <mars> rockstar, yep.  Deryck's argument partly hinges on our understanding of, and deriving value from, that fact.
[21:09] <jam> poolie: I certainly think that the best use of time would be to just pre-arrange a couple of hours, and have a live conversation and testing of it.
[21:09] <jam> I'm not all that great at sysadmin stuff, the production config is nothing like local config, etc.
[21:09] <mars> rockstar, we also have the complimentary xUnit suite with YUITest
[21:09] <jam> I don't have access to production to see what it is actually like
[21:09] <poolie> it seems like you could (are?) waste a lot of mental energy waiting around to see if they've responded
[21:09] <mars> rockstar, so, two tools, two roles.  What do other projects do in the industry, and at this company?
[21:10] <rockstar> mars, I think that Launchpad is kinda the leader in js testing, actually.  This means we're kinda feeling around in the dark.
[21:10] <jam> poolie: well, today I mostly switched off, and was doing code review, etc, so not a lot of waste
[21:10] <jam> but certainly I spent some time making sure the init script worked on my machine
[21:10] <jam> but it doesn't match production
[21:10] <lifeless> rockstar: within Canonical?
[21:10] <rockstar> lifeless, yes.
[21:11] <lifeless> qa folk - https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html seems to be missing 10 new commits, am I just eager, or is something wrong ?
[21:11] <flacoste> rockstar, mars: yeah, nobody else is really paying that much attention to automated JS testing
[21:11] <mars> lifeless, you can check the logs on devpad, if you want.
[21:12] <lifeless> mars: https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log does not have a timestamp in it
[21:12] <rockstar> flacoste, landscape is, and they're having problems too.  jstestdriver randomly decides not to run tests.
[21:12] <mars> lifeless, really?  That's an oversight
[21:12] <flacoste> rockstar, mars: Landscape started with Selenium and dropped it
[21:12] <mars> lifeless, we should fix that
[21:13] <flacoste> rockstar, mars: now Landscape is ysing yuitest with jstestdriver as a harness
[21:13] <lifeless> mars: have a look :)
[21:13] <rockstar> flacoste, yeah.  I assume, at some point, we'll swing for the fences and actually get a home run.
[21:13] <flacoste> rockstar, mars: ISD started using Selenium, than Windmill now looking into Selenium2 (never really systematized on anything)
[21:13] <rockstar> ...Or 6 runs, if you're in that part of the world.
[21:13] <mars> flacoste, ok, so is the whole integration testing idea a mountain not worth climbing, or are we just not committed enough?
[21:14] <poolie> i'm going to try to pilot more today, depending what else is in my inbox
[21:14] <flacoste> mars: deryck would say not worth climbing, i say not commited enough
[21:14] <flacoste> mars: industry standard is selenium-grid
[21:14] <rockstar> flacoste, yeah, we're in a black hole.  U1's fix seems to be "don't go to long before we can fix it" and lifeless' recent changes might be helpful there.
[21:14] <mars> flacoste, rockstar, or possibly, no one save BigCos like Yahoo have made it to the top.  The OSS world is still building convenient, stable tools to work with?
[21:14] <flacoste> or any custom solution built on top of selenium, (like google does)
[21:15] <rockstar> mars, Yahoo still struggles with it.
[21:15] <rockstar> mars, only small groups test at Yahoo.
[21:15] <lifeless> hudson has selenium-grid glue I think
[21:15] <lifeless> FWIW
[21:15] <flacoste> mars, rockstar: go read Bjorn's report from last year Google Testing conference
[21:15] <mars> rockstar, I remember the Google "If you try it, don't go here, or there" slides :)
[21:15] <rockstar> lifeless, yeah, YUITest has hudson glue as well.
[21:16] <mars> flacoste, ah, I remember now
[21:16] <flacoste> poolie: i'm free for the next 1h45 if you want to talk, but i'm fine with resuming next week if you rather not
[21:17] <mars> rockstar, only small groups test at Yahoo??
[21:17] <flacoste> mars, rockstar: iirc, google was working on webc or something like that would should be more reliable than selenium for piloting the browser, but not sure where this is at now
[21:17] <mars> rockstar, so the industry standard is still manual testing?
[21:18] <poolie> flacoste: now's good for me; we haven't spoken for a while
[21:18] <lifeless> mars: industry standard is probably user complaints.
[21:18] <lifeless> mars: depending on how you define industry, and standard.
[21:18] <mars> lifeless, haha
[21:18] <rockstar> flacoste, are you talking about jstestdriver?  That's what Google uses to test gmail.
[21:18] <mars> lifeless, we are working at the bleeding, gory edge of the whole thing
[21:19] <flacoste> rockstar: i don't think so, it was also in Bjorn's report
[21:19] <rockstar> mars, yeah, I was surprised too.  I had lunch with the Yahoo Sports team, and they just farm it out to their QA team.
[21:19] <mars> flacoste, are you talking about that project that became Selenium2?
[21:19] <mars> rockstar, could just be institutional momentum
[21:20] <mars> Remember what a shock it was to start on LP and find how far ahead the practice here is
[21:20] <mars> rockstar, could also be ease of implementation: perhaps everyone in the industry knows how to do manual JS+QA.  Few know automated testing.
[21:21] <flacoste> mars: it might be
[21:21] <mars> So, do we have some options here?
[21:21] <rockstar> mars, yeah.  U1 makes sure that the barrier for rolling out a fix in cases like that is very small.
[21:22] <mars> rockstar, right, and that helps a lot, I'm sure.
[21:22] <jderose> rockstar: MooTools seems to be one of the more test-driven JS libs, and they're using Windmill: http://www.getwindmill.com/  <= you guys ever try it (i haven't)
[21:22] <mars> "cap deploy"
[21:23] <rockstar> jderose, you cant' see the backchat where I say terrible things about the mothers of the windmill developers.
[21:24] <jderose> hehe, okay, that answers my question
[21:24] <mars> jderose, the Launchpad project has a decent sized windmill test suite, all Python, integrated as python unittests.
[21:24] <rockstar> jderose, launchpad uses windmill, and no one believes me when I say we shouldn't.  :)
[21:25] <jderose> rockstar: so what should you use?
[21:25]  * mars notices they redid the windmill homepage
[21:25] <lifeless> sinzui: do we support safari?
[21:26] <lifeless> sinzui: - https://bugs.launchpad.net/launchpad-web/+bug/97266
[21:26] <_mup_> Bug #97266: Suggestions menu next to "Choose..." doesn't do anything <launchpad-web:Triaged> <https://launchpad.net/bugs/97266>
[21:26] <sinzui> yes, in the form of webkit engine that underlies safari, konqueror, and chromium
[21:27] <lifeless> sinzui: do you think that that bug is high ? I'm torn.
[21:28] <sinzui> it is not high because the work around is to type what you see in the list for item 1
[21:28] <mars> lifeless, "Safari 1.3"?
[21:28] <sinzui> that is broken in chromium now
[21:28] <lifeless> sinzui: it is ?
[21:28] <sinzui> yes
[21:28] <lifeless> I think I'll leave it high and add confusing-ui
[21:29] <rockstar> jderose, that's still up for discussion.
[21:29] <lifeless> we're making chromium default in Ubuntu I think, aren't we?
[21:29] <lifeless> mars: EOldBug
[21:30] <sinzui> yep, still broken
[21:30] <mars> lifeless, if Curtis didn't say it affects current Chromium, I would say it is not a supported browser.  We only support Safari 3+ now.
[21:30] <lifeless> hmm
[21:30] <lifeless> is https://bugs.launchpad.net/malone/+bug/86352 still relevant
[21:30] <_mup_> Bug #86352: SchoolTool imported bugs have invalid reporters <oops> <tech-debt> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/86352>
[21:30] <lifeless> we've changed our email handling, haven't we?
[21:31] <mars> lifeless, old, but here was the plan, back when I played webmaster: https://dev.launchpad.net/GradedBrowserSupport
[21:31] <sinzui> mars, please listen to what I said. This is a webkit issue. I just tested the bug (again) and it is still broken in chromium Maverick
[21:31] <sinzui> It is broken in Kubuntu maverick
[21:32]  * sinzui tags the bug so it is with its friends
[21:33] <mars> sinzui, I understand.  Unfortunately a GBS table like the one I wrote doesn't take root-level engine bugs into account well.
[21:33] <mars> It assumes you can't easily discern a bug in the engine vs. a bug in the browser's integration of said engine
[21:33] <sinzui> I tag most of the bugs in launchpad-web  with the browser engine when it is known
[21:33] <sinzui> opera is another class of victim
[21:33] <mars> sinzui, +1, that is a big step forward then
[21:36] <sinzui> I was pondering how to tad IE issues last night. I think the versions with undocumented changes make it difficult to say if a  issue is ie, 6, 7, or 8. I believe we have one bug that is definitely IEs problem, but it is only fixed in version 8
[21:36] <lifeless> sinzui: 'usersthathatefreedom'?
[21:38] <sinzui> The inline help iframe sitting invisible over the login button is a nightmare. I think the only fix is to re-implement the the feature with ajax instead of an iframe
[21:40] <sinzui> does anyone who uses opera have a moment to check two presentation issues
[21:40] <lifeless> ok
[21:40] <lifeless> boarding
[21:40] <lifeless> ciao
[21:41] <weather15> Hello Everyone
[21:41] <weather15> After configuring Apache to access Launchpad from a remote machine I get this error: Secure Connection Failed                                                                      An error occurred during a connection to launchpad.dev.  SSL received a record that exceeded the maximum permissible length.  (Error code: ssl_error_rx_record_too_long)
[21:42] <weather15> My Apache config looks right any idea as to what's wrong?
[21:42] <mwhudson> that usually means that you're not talking ssl when something is expecting you to i think
[21:42] <mwhudson> not really a launchpad issue
[21:55] <weather15> is this something know that the instructions in the documentation do not work?
[21:55] <weather15> *known
[22:05] <weather15> Everything here is as said in the documentation
[22:10] <weather15> I would think this would work! <VirtualHost <IP_ADDRESS>:443>
[22:18] <weather15> ??
[22:20] <weather15> wgrant are you outthere?
[22:21] <weather15> *out there
[22:39] <weather15> It seems that Mod-ssl is not loading
[22:44] <weather15> any idea as to why this does not work? It seems to that it has to do with Launchpad's Apache Config
[23:04] <weather15> Looks to like Apache is not even running on port 443:tcp6       0      0 :::443                  :::*                    LISTEN
[23:10] <EdwinGrubbs> leonardr: is there a specific IField that works for exporting a dict that can just be converted to json?
[23:11] <leonardr> EdwinGrubbs: i don't know. i have no experience with named operations that return dicts. you might ask bdmurray
[23:13] <rockstar> wallyworld_, hi
[23:13] <wallyworld_> rockstar: otp
[23:14] <wgrant> EdwinGrubbs: I don't think you declare it as anything.
[23:14] <wgrant> EdwinGrubbs: It just works.
[23:15] <rockstar> wallyworld_, okay. I was just pinging you to see how the war was going.
[23:20] <maxb> It seems that leaving the code import machines deactivated for 2 days has left the import queue seriously backlogged
[23:23] <wgrant> Hm, really?
[23:23] <wgrant> Aren't most imports tried every 6 hours?
[23:23] <maxb> Hmm, actually no, but something's screwed up
[23:23] <maxb> The importds are full of imports, but new imports registered on Monday haven't had their initial import run yet
[23:24] <wgrant> Hmm.
[23:24] <wgrant> Something is up, yeah.
[23:24] <wgrant> Lots of branches haven't imported since the 15th.
[23:24] <rockstar> Wasn't there an incident where we disabled the importds?
[23:25] <wgrant> Over the weekend, yeah.
[23:25] <wgrant> But they were reenabled.
[23:25] <maxb> https://code.launchpad.net/~vcs-imports/sope/debian-tfh is the earliest new import that has not been processed
[23:25] <wgrant> A suspicious number are stuck like this:
[23:25] <maxb> To put a time box on when the problem started
[23:25] <wgrant> 2010-11-18 23:19:40 INFO    Getting exising bzr branch from central store.
[23:25] <wgrant> 2010-11-18 23:19:40 INFO    [chan bzr SocketAsChannelAdapter] Opened sftp connection (server version 3)
[23:25] <wgrant> 2010-11-18 23:19:40 INFO    35 bytes transferred
[23:26] <wgrant> Even some that started an hour ago.
[23:26] <wgrant> eg https://code.launchpad.net/~rpm5/rpmlint/trunk has been going for 51 minutes, but normally takes 20 seconds.
[23:27] <maxb> In fact, I wonder if there's a single successful import since the 15th
[23:28] <maxb> The never used to log "[chan bzr SocketAsChannelAdapter] Opened sftp connection (server version 3)
[23:28] <maxb> ", afaik, before
[23:28]  * mwhudson looks at a graph
[23:28] <wgrant> They seem to time out after an hour.
[23:28] <wgrant> So we will be backlogged.
[23:29] <wgrant> Yeah, they time out after almost exactly 60 minutes.
[23:30] <wgrant> Oh, killed with KeyboardInterrupt.
[23:30] <wallyworld_> rockstar: off the phone now. how's life in greener pastures?
[23:31] <rockstar> wallyworld_, it's a nice evening in Buenos Aires.
[23:31] <rockstar> wallyworld_, how goes merge queues?
[23:31] <wallyworld_> rockstar: wow i didn't realise you were there. lucky you :-)
[23:32] <wallyworld_> rockstar: i have a branch almost ready to land (for the product queues etc). but it's been on hold most of the week due to other tasks
[23:33] <wallyworld_> rockstar: i landed the person listing branch yestersay into devel
[23:33] <rockstar> wallyworld_, awesome.
[23:33] <rockstar> wallyworld_, so I guess that means you haven't pulled out the json constraint on the configs?
[23:34] <wallyworld_> rockstar: no :-( i have a few items left on my todo list. should get to it monday or tuesday. is that too late. i can do something over the w/e if you need it
[23:35] <rockstar> wallyworld_, okay.  I'll see if I can get to it this weekend, in any case.  I'm also going to work on getting the merge proposals queueable.
[23:36] <mwhudson> uh yes, the codeimport graphs is terrible
[23:36] <wallyworld_> rockstar: i would think that make the mp queueable would take priority?
[23:36] <wallyworld_> rockstar: the json cleanup can happen after that?
[23:38] <rockstar> wallyworld_, yeah, but it's small.
[23:40] <wallyworld_> rockstar: that's a sad problem for you to have but what does it have to do with json? :-)
[23:41] <rockstar> :)
[23:42] <wallyworld_> rockstar: i'll ping you then before i start on anything and we'll take a view from there
[23:44] <rockstar> wallyworld_, cool.
[23:44] <rockstar> wallyworld_, jml went over the LEP, might be good for you to read it.
[23:44] <mwhudson> hang on
[23:44] <wallyworld_> rockstar: will do
[23:44] <mwhudson> why is bzr on the importds using the paramiko  transport
[23:47] <maxb> IIUC, the implication from the various logs on https://code.edge.launchpad.net/~vcs-imports/transaction/trunk suggests it was back when it was working too