[00:04] <maxb> james_w: ooi, why pin the PPA?
[00:04] <james_w> maxb: I don't want to give free reign to LP developers when I am supposed to be testing the development release of Ubuntu
[00:05] <james_w> maxb: the closer I can stay to pure lucid the better, and the more I know about the changes made the better
[00:05] <maxb> The reason for needing python-support is because python-support disregards python-defaults and embeds its own version list :-/
[00:05] <james_w> wow
[00:05] <maxb> fair enough, but the PPA's delta is small. It's mostly no-change rebuilds
[00:06] <james_w> yeah
[00:07] <james_w> it's not that it's an LP ppa specifically, but that it is an extra archive at all
[00:52] <thumper> mwhudson: any reason why "Modify worker/monitor/UI to handle partial success" task is still blocked for QA (on kanban)?
[00:53] <mwhudson> Ursinha: sorry for breaking the scripts!
[00:53]  * mwhudson hates wikis, by the by
[00:54] <mwhudson> thumper: no reason, fixed
[00:54] <thumper> mwhudson: awesome
[00:57] <Ursinha> mwhudson: lol
[00:58] <Ursinha> thumper: hi, you're the RM this cycle right?
[00:59] <thumper> Ursinha: aye
[01:00] <Ursinha> thumper: mwhudson, are you aware of this oops: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1518S10
[01:00] <james_w> aha!
[01:00] <james_w> ... in doctests is greedy!
[01:01]  * thumper frowns
[01:02] <Ursinha> thumper: I saw about 400 of them on staging, in 02/26
[01:02] <thumper> Ursinha: likely to be when codehosting was updated before the xmlrpc server or vice versa
[01:02] <mwhudson> Ursinha: that'll be the codehosting system not in sync with the appserver
[01:03] <thumper> Ursinha: as long as they are not happening now we should be good
[01:03] <mwhudson> Ursinha: what thumper said
[01:03] <Ursinha> thumper: mwhudson, that's fine, I' ll let you know if they start happening again
[01:03] <Ursinha> thanks :)
[01:03] <mwhudson> thanks
[02:13] <Ursinha> thanks :)
[02:13] <Ursinha> oops
[02:13] <Ursinha> :)
[03:11] <mwhudson> wow, the staging code import slave is _much_ slower than my laptop
[03:11] <mwhudson> we gots some old hardware here...
[03:12] <thumper> mwhudson: how do I debug a particular function?
[03:12] <thumper> with pdb
[03:12] <thumper> I'm in the harness
[03:12] <thumper> and I want to step through a function
[03:12] <mwhudson> thumper: put "import pdb; pdb.set_trace()" in it?
[03:12] <mwhudson> oh
[03:12] <mwhudson> i think pbb.run("f()") ?
[03:13]  * thumper grunts
[03:13] <thumper> it seems I need locals somewhere
[03:13] <mwhudson> or maybe pdb.runcall(f, a1, a2)
[03:14] <mars> mwhudson, neat trick.
[03:15] <thumper> yup
[03:15]  * thumper steps through
[03:16] <mars> thumper, if something blows up in the harness, you may also be able to use pdb.pm() to dissect the traceback.  Haven't tried it though.
[03:16] <thumper> gah
[03:17]  * thumper files first bug
[03:19] <mars> oh, cool
[03:20] <mars> in ipython, "setting %pdb on within ipython will make it such that the pdb debugger will automatically be started at the point of an exception"
[03:20] <mars> err, that should read '%pdb on', as the command
[03:20] <mars> so that would work in the harness too
[03:21] <mars> iharness, specifically
[03:23] <thumper> oh clucking bell
[03:45] <thumper> mwhudson: got a minute?
[03:54] <mwhudson> thumper: sure
[03:54] <mwhudson> (sorry for the delay)
[03:56]  * thumper finishes editing the wiki
[03:58] <thumper> mwhudson: I was just thinking about the bugs I've just filed
[03:58] <thumper> mwhudson: and how urgent they really are
[03:58]  * mwhudson looks at email
[03:58] <thumper> they have to do with the qa of the email stuff
[03:59] <thumper> mwhudson: also I've had an idea about oops 1521SMPSSH1
[03:59] <mwhudson> thumper: 530455 looks like inspiring head-wall interaction
[03:59] <thumper> mwhudson: skype?
[03:59] <mwhudson> thumper: sure
[03:59] <mwhudson> thumper: is that the "None has no attribute close" one?
[04:00] <thumper> yeah
[04:00] <thumper> or no attribute write
[04:00] <mwhudson> er ok
[04:33]  * thumper -> dinner
[04:45]  * mwhudson eods
[06:46] <kfogel> thumper: g'night
[07:01] <thumper> kfogel: night
[07:01]  * thumper EODs
[07:15] <noodles775> wgrant: hey, have you come across this when trying to send a key to your local keyserver? http://pastebin.ubuntu.com/386801/
[07:16]  * noodles775 checks if it's lucid-related...
[07:16] <wgrant> noodles775: Yeah, Lucid-related.
[07:16] <wgrant> There is a patch to pygpgme.
[07:16]  * wgrant finds.
[07:16] <noodles775> Thanks!
[07:16] <wgrant> I think it's attached to a bug somewhere, but I've just been passing it around for now.
[07:16] <noodles775> OK, I'll update the wiki page.
[07:17] <wgrant> http://pastebin.ubuntu.com/386803/
[07:17] <noodles775> Ta!
[07:18] <wgrant> Bug #452194
[07:18] <mup> Bug #452194: Call to gpgme_check_version is required when using gpgme >= 1.2.0 <PyGPGME:New> <https://launchpad.net/bugs/452194>
[07:24] <spm> wgrant: any objections if we add an API to talk to you for all bug searches? no particular reason for asking... ;-)
[07:24] <wgrant> Heh.
[08:06] <adeuring> good morning
[08:25] <jtv> wgrant: my branch for the soyuz dev startup work is up for review.  I *think* I found a way to attach a real GPG key automatically, but I'm not sure it's complete because the UI still says the key is missing.
[08:26] <wgrant> jtv: Link?
[08:26] <jtv> wgrant: yes
[08:26] <jtv> https://code.launchpad.net/~jtv/launchpad/bug-527170/+merge/20433
[08:27] <jtv> wgrant: gets your fingerprint by running gpg --fingerprint
[08:28] <wgrant> jtv: I'd prefer it if it took it as an argument.
[08:28] <wgrant> But let me read.
[08:30]  * wgrant wonders why GPGKeySet.new() takes a person *ID*.
[08:30] <jtv> wgrant: it seems to be a pattern in soyuz
[08:30] <jtv> I've seen it before
[08:30] <wgrant> La la la GPG isn't really Soyuz.
[08:31] <jtv> (Okay, I remember seeing it *once* before but by the bluffer's guide that makes it a pattern)
[08:31] <wgrant> The occasional part of Soyuz does it for performance reasons, though.
[08:31] <jtv> rv42
[08:31] <jtv> ahem
[08:35] <wgrant> It's odd that that doesn't work.
[08:35] <wgrant> Does it actually get added to the table?
[08:42] <jtv> wgrant: yes, it shows up as added to the test account (I called it ppa-user), but when I click through to it, I get a page saying that the key was not found
[08:42] <jtv> This may be because I'm not originally getting the key from zeca, I suppose.
[08:42] <wgrant> Ah, yes.
[08:42] <wgrant> It's a page on keyserver.launchpad.dev, right?
[08:43] <wgrant> Hm, but GPGHandler is meant to use zeca, isn't it?
[08:44] <jtv> wgrant: I believe so, yes
[08:45] <jtv> wgrant: at least I got around the CoC signing trouble by inserting a CoC signed with a fake key.
[08:45] <wgrant> Right.
[08:47] <jtv> that should save a bit of aggro all by itself, though it's not really germane to the rest of the gpg goings-on
[08:47] <jml> good morning Launchpadders.
[08:47] <wgrant> jtv: Yeah, although it's easy with the admin console.
[08:47] <jtv> hi jml!
[08:47] <wgrant> By the way, the CoC infrastructure sucks.
[08:48] <jtv> heh
[08:48] <jtv> one battle at a time  :)
[08:48] <lifeless> wgrant: har har
[08:48] <wgrant> lifeless: Hm?
[08:49] <lifeless> CoC..sucks
[08:49] <wgrant> Heh.
[08:49] <wgrant> (unintended)
[08:50] <jtv> *sigh*
[08:50] <wgrant> Uhoh.
[08:50] <wgrant> What's happened now?
[08:50] <jtv> wgrant: puerile humour has happened
[08:50] <wgrant> Ah.
[08:50] <lifeless> jtv: oh noes.
[08:50] <jtv> I _could_ add here a reference to the gay & lesbian rights group of the same name, but
[08:50] <jtv> okay, I admit it: I couldn't think of a good one
[08:52]  * wgrant must try Landscape at some point.
[08:55] <bigjools> morning dudes
[08:56] <bigjools> jtv, just the man I need to speak to
[08:58] <jtv> uh-oh
[08:59] <jtv> bigjools: I do have a standup coming up I believe, so we may have to work around that, but otherwise might as well try to strike while the iron is hot
[09:00] <jtv> lifeless, wgrant: for the record, I'm a big fan of puerile humour.  I really was sighing only over my failure to come up with a good one.
[09:00] <bigjools> jtv: really quick - is there a way to make PG return a zero as a default value to a query?
[09:00] <wgrant> COALESCE(expr, 0)?
[09:01] <jtv> bigjools: what wgrant said
[09:01] <jtv> That means "expr, or if it's null, 0."
[09:01] <bigjools> parfait
[09:01] <jtv> Works for any number of args.
[09:01] <bigjools> I suck at sql
[09:01] <bigjools> thanks
[09:01] <jtv> SELECT COALESCE(min(id), 0) FROM MyTable
[09:03] <jtv> wgrant: to test, run ./utilities/start-dev-soyuz.sh *first* (I'll be updating the docs) and then ./utilities/soyuz-sampledata-cleanup.py using the --email option to provide your real email address.
[09:04] <jtv> I think I'll rename that latter script to reflect its expanded scope.
[09:09] <wgrant> jtv: The first seems better as a Makefile target.
[09:09]  * wgrant backs up his DB and tests.
[09:09] <jtv> wgrant: cool idea...  I'm thinking one step at a time though, since I'm also learning in the process.
[09:10] <jtv> otp now
[09:11] <wgrant> k
[09:16] <wgrant> security.py is too slooooow.
[09:18] <mrevell> Good morning
[09:18] <jtv> wgrant: while you're waiting for that, I'm off the phone
[09:18] <jtv> hi mrevell!
[09:18] <mrevell> Hi jtv :)
[09:19] <jtv> wgrant: as for making that script a make target, I think it's a good idea.  One problem is setting up the right email address.
[09:19] <wgrant> jtv: I mean the soyuz-starting one.
[09:19] <jtv> wgrant: oww
[09:20] <wgrant> I don't think the other one makes sense.
[09:21] <jtv> wgrant: before turning that into a make target I'd like to see some more robustness... have separate targets for "make sure service foo is running," that sort of thing.
[09:21] <jtv> Right now it just fails somewhere along the line if something's already running.
[09:21] <jtv> Not good for make targets.
[09:21] <noodles775> Hey jtv, have you already included the removal of the sample build (id:8) that is currently building on bob in the sample data?
[09:21] <wgrant> jtv: See for example 'make run_codehosting'
[09:21] <wgrant> noodles775: Good idea.
[09:22] <jtv> noodles775: if that one wasn't in w's original, I don't think I did
[09:22] <wgrant> It wasn't.
[09:22] <noodles775> jtv: ok, it'd be great to do... if you don't have time, I'll do it as a followup.
[09:22] <jtv> Then I didn't.
[09:23] <jtv> noodles775: I've already submitted my branch for review; I'm sure it needs more work, but I want to keep the chunks manageable.
[09:23] <wgrant> Probably because I classically ran it before starting a buildd, so buildd-manager detected that the builder was offline and unassigned the build.
[09:24] <noodles775> jtv: no worries, I'd be happy to add it later :), thanks for simplifying the whole process!
[09:24] <jtv> wgrant: that make target looks useful... is there any documentation that's easier to read than the source and specifies how it deals with already-running daemons?
[09:24] <jtv> noodles775: glad to see you jump in!
[09:24] <wgrant> jtv: bin/run is buildout evil. Kill it with fire.
[09:25] <jtv> wgrant: did I mention I caught a whiff of certain patterns sometimes?  :-)
[09:26] <wgrant> Excellent, it added my correct test key.
[09:27] <jtv> wgrant: if you click through to it though, you'll see that knowledge of it is not complete and I have no idea whether that's likely to be an immediate problem.
[09:27] <wgrant> Where are directories normally created?
[09:27] <wgrant> /var/tmp/poppy and /var/tmp/zeca should probably be added there.
[09:28] <jtv> wgrant: I added that in the start-soyuz script
[09:28] <wgrant> jtv: Ah, right. We should probably work out how to do all this properly.
[09:29] <jtv> wgrant: ideally, yes, though the effort should be commensurate with use.
[09:30] <wgrant> jtv: Ah, that 404 is just because zeca is pretty braindead.
[09:30] <wgrant> It doesn't do indices; if you replace 'index' with 'get' it will work.
[09:31] <jtv> wgrant: whoo!
[09:31] <jtv> any easy way we can fix it up?
[09:31] <wgrant> Not really.
[09:32] <jtv> Oh well.  I'll admit to being selfish here: if it works, I have bigger fish to fry.
[09:32] <jtv> Or should I admit to being shellfish?
[09:32] <wgrant> zeca didn't even take uploads until a little over a year ago. It was a really trivial thing that just served files.
[09:32] <wgrant> Heh.
[09:32] <wgrant> It works, just the link won't.
[09:32] <wgrant> I think it'll do for now.
[09:32] <jtv> \o/
[09:33] <wgrant> Actually, I remember now that zeca didn't originally actually work as a full dev server, but I patched it so it would.
[09:33] <wgrant> I must have just decided that that wasn't worth fixing.
[09:33] <jtv> so it never really works in dev?
[09:34] <wgrant> The link on the person index doesn't, no.
[09:34] <wgrant> But the internals will all work fine.
[09:35] <jtv> btw it turned out that GPGHOME gets set somewhere to a tmp directory, and that's why it was hard retrieving real-world keys.
[09:37] <wgrant> Why does that make it hard?
[09:38] <jtv> I couldn't figure out why I wasn't finding any keys using pygpgme
[09:38] <wgrant> Don't you retrieve them from the server?
[09:38] <jtv> No, ultimately I forked off a gpg _with the variable removed_.
[09:38] <jtv> I tried the --home-dir option, but that didn't do the trick for some reason.  Maybe I used it wrong.
[09:39] <wgrant> Oh, so you're not sending the key to the server?
[09:39] <wgrant> In that case it won't work.
[09:39] <wgrant> I guess mine just already had it.
[09:40] <jtv> gah
[09:44] <jtv> wgrant: I'll see if I can delete my key from zeca and re-test
[09:45] <wgrant> jtv: rm /var/tmp/zeca/*
[09:45] <jtv> wgrant: what about zeca.test?  That's where most of the stuff is.  Or is that _only_ the links to the keys that come in ftests?
[09:48] <wgrant> jtv: I believe that's only used in the test config.
[09:53] <jtv> wgrant: you were right :(
[09:53] <jtv> key not found
[09:54] <jtv> wgrant: so... how _do_ I get that key into zeca?
[09:55] <wgrant> jtv: gpg --keyserver keyserver.launchpad.dev --send-key DEADBEEF
[09:55] <wgrant> I thought that was in the docs.
[09:55] <jtv> wgrant: ah yes, so it is
[09:55] <jtv> I just couldn't place it in the larger picture
[09:55] <wgrant> Ah, right.
[09:55] <jtv> (from my perspective, all that's missing is the ritual goat sacrifice)
[09:55] <wgrant> Heh.
[09:55] <jtv> Anyway, not too hard I'd say!
[09:55] <wgrant> It all makes perfect sense to me now!
[09:56] <jtv> a good ritual goat sacrifice can really work wonders can't it?
[09:56] <wgrant> Always.
[09:59] <noodles775> wgrant, jtv: what have I missed? http://pastebin.ubuntu.com/386876/
[10:00] <wgrant> noodles775: ./scripts/publish-distro.py -C
[10:00] <noodles775> ta.
[10:00] <wgrant> I appear to have not added that to the docs.
[10:01] <noodles775> wgrant: It's there, I just missed it as I had to go back and forth a bit (initially had a corrupt chroot).
[10:01] <noodles775> Ah, I see, it's only htere after the first build, where as it needs to be run before.
[10:01] <jtv> wgrant: is it safe to assume that the key id is always the last 4 octets of the fingerprint?
[10:01] <wgrant> noodles775: Yeah.
[10:02] <wgrant> jtv: That's what it is, so yes.
[10:02] <jtv> cool
[10:02] <wgrant> jtv: But you can also --send-key the fingerprint.
[10:02] <jtv> even better :)
[10:02] <wgrant> I just don't, because I'm lazy.
[10:02] <wgrant> But code has a convenient attribute of not being lazy.
[10:05] <jtv> should we have told noodles775 that he also missed the goat sacrifice?
[10:05] <jtv> Just a thought.
[10:05] <wgrant> Possibly.
[10:05] <wgrant> noodles775: Have you done this before?
[10:05] <noodles775> oh, please do...
[10:06] <noodles775> Nope, just going through for the first time (so I can test some stuff locally).
[10:06] <wgrant> Aha.
[10:06] <wgrant> Only a couple of people have used it, AFAIK.
[10:07] <wgrant> Although it's a lot more streamlined now.
[10:16] <noodles775> Building happily now, thanks wgrant/jtv.
[10:16]  * jtv points at wgrant
[10:18]  * wgrant points back.
[10:19] <noodles775> arg, still failed (chroot problem) http://pastebin.ubuntu.com/386885/ ...but that's just because the package I'm testing with is targeted at security right?
[10:19] <wgrant> noodles775: Ah, yeah, you can't target to security.
[10:19] <noodles775> OK.
[10:20] <wgrant> Unless there's a full copy of the archive somewhere that I don't know about apart from drescher.
[10:20] <wgrant> Er, cocoplum.
[10:20]  * wgrant is stuck in the past.
[10:25] <jml> mrevell, hi
[10:25] <mrevell> hi jml
[10:25] <jml> mrevell, sorry I missed our call. for some reason my calendar didn't buzz at me
[10:26] <mrevell> jml, No worries. I'd heard a rumour you were sprinting at Millbank.
[10:26] <jml> mrevell, no, I'm just at Millbank
[10:26] <jml> mrevell, there's a decorator doing my room at home, so I can't work there.
[10:27] <mrevell> jml, Ah right. I can do a call now, if you're available. If you don't mind, I'll just grab a tea first, though.
[10:27] <jml> mrevell, yeah. me too.
[10:27] <jtv> wgrant: looks like security.py does a lot of needless name-dropping.  I mean, it seems to drop a lot more users than it needs to.
[10:28] <jtv> stub, is that right?  reset_permissions in security.py seems to try and drop every user from every group.
[10:30] <jtv> well, from only two groups actually
[10:31] <jtv> wgrant: sending the key seems to be working
[10:32] <wgrant> jtv: Great.
[10:35] <jml> mrevell, whenever you're ready
[10:35] <mrevell> jml, Cool, just sorting Skype.
[10:37] <jml> mrevell, when I said "skype was ok"
[10:37] <mrevell> :)
[10:43] <stub> jtv: Yes. It is a dumb implementation that needs improving.
[10:43] <stub> jtv: That along with revoking all permissions and regranting them means live updates are pretty much impossible and the script is a low slower than it needs to be.
[10:43] <jtv> stub: for now I'm really just curious if that'd cost significant time, or whether it's a harmless good-enough implementation.
[10:46] <stub> Its not harmess as it means we have to do security modifications manually. If it was smart enough to only apply the changes, we could run security.py against the live database without causing all the active sessions to bomb. It is also slow, as when you scale that up to 150 tables that is an awful lot of queries to issue (slower still when you need to quadruple that to run on all replicas)
[10:46] <jml> mrevell, you've dropped out. should I call you on a landline?
[10:47] <mrevell> If that's okay jml, will message you a number
[10:47] <stub> (although the first bit we could probably fix by doing things in a single transaction now I think of it)
[10:53] <jtv> stub: sounds like an interesting challenge.  I know you mentioned it months ago as something I could tackle.
[10:53] <jtv> IIRC there's only one commit in that script, though maybe it gets called from a loop somewhere
[11:04] <deryck> Morning, all.
[11:11] <jelmer> hey Deryck
[11:26] <wgrant> bigjools: are you still busy, or do you have time to talk about PPA download stats?
[11:27] <bigjools> wgrant: busy as in looking at this security vuln
[11:27] <bigjools> but we can talk
[11:28] <wgrant> bigjools: Ah, no, you have better things to do :)
[11:28] <bigjools> heh :)
[11:28] <bigjools> wgrant: any suggestions on how to tackle it are welcome ;)
[11:28] <bigjools> I've only just literally opened up the file in question to look
[11:29] <bigjools> oh and don't talk about it on here of course
[11:29] <wgrant> Of course.
[11:35] <jtv> lifeless: help!  When I do  branch, subdir = Branch.open_containing(url) ; export(branch.basis_tree(), '/tmp/foo')  from my LP branch, all I ever seem to get is the LP source tree.  Shouldn't that give me the branch at "url"?
[11:51] <jml> noodles775, hello
[11:52] <noodles775> Hi jml
[11:52] <jml> noodles775, I'm now finally looking at the fourteen emails I've got about build from branch since I went to PyCon
[11:53] <jml> noodles775, and I thought, maybe it'd be easier just to talk with you :)
[11:53] <noodles775> jml: sure, call in 10mins?
[11:53] <jml> noodles775, perfect.
[13:00] <deryck> jtv, ping
[13:00] <jtv> deryck: good evening
[13:00] <deryck> jtv, there's a bug from you on the malone 10.02 milestone... still in progress.  But I think you finished this.  Can you look at it and update the status or move it off?
[13:01] <jtv> deryck: will do
[13:01] <deryck> jtv, thanks
[13:02] <jtv> deryck: that one disappears with a lazr-js upgrade, so I'll have to go after that.
[13:04] <jtv> I think.  :/
[13:08] <deryck> jtv, I just did an LP branch updating to latest lazr-js.  So once it lands that should be fixed then.
[13:08] <jtv> deryck: on closer inspection, this looks like it was one that still had a mystery problem.  :(
[13:09] <deryck> jtv, ah, ok.  Do you think you'll look at it again?  If so, let's move to 10.03.  if not, we can un-milestone and take it out of progress.
[13:09] <jtv> deryck: I ended up being stumped IIRC.  Better to let the next volunteer try.
[13:10] <deryck> jtv, that works.  Thanks for looking into it initially, though.
[13:11] <jtv> deryck: good luck with the little bastard :)
[13:11] <deryck> heh
[13:11] <deryck> thanks
[13:16] <noodles775> james_w: Hi, are you free for a call regarding the mockups?
[13:16] <noodles775> (at some point).
[13:17] <james_w> sure
[13:17] <james_w> either now or after lunch?
[13:18] <noodles775> james_w: if you're going to lunch now, then after is fine, otherwise now is good for me.
[13:18] <james_w> I would be going for lunch in 30 minutes or so
[13:18] <james_w> depends how much you have on your mind :-)
[13:18] <noodles775> Perfect, I only expect a 10min call :)
[13:19] <james_w> nice
[13:19] <jtv> noodles775: I successfully set external_dependencies, but aren't they supposed to show up in the UI?
[13:19] <james_w> I'll hold you to that ;-)
[13:19] <noodles775> :-D
[13:19] <noodles775> jtv: yes, I would have expected them to.
[13:19] <jtv> noodles775: I checked in "make harness" as well as the db, and I really have a string in there.  Need a newline at the end maybe?
[13:21] <james_w> noodles775: I should make your skype make silly noises?
[13:21] <noodles775> jtv: I'd check what's being passed to the form for the UI (in browser/archive.py). It might have something to do with the expanded_dependencies field, I haven't checked.
[13:21] <noodles775> james_w: calling now.
[13:21] <deryck> gmb, there is a launchpad-users email question about timeouts with +filebug, saying this is on edge....
[13:21] <jtv> noodles775: thx
[13:22] <deryck> gmb, I'm a little suspect of it, though, because it looks like the old timeout message, and we should be async now, right?
[13:22] <gmb> deryck: I've replied
[13:22] <deryck> gmb, ah, ok.  go, you! :-)
[13:22] <gmb> deryck: If the user has JS disabled then they'll still hit the timeout with long bug titles.
[13:22] <deryck> ah, right.  that makes sense.
[14:08] <intellectronica> gmb: so, i'm trying to create bug heat calculation jobs. i haven't figured out a way to do this with sql only, so i'm writing a script. but it occurred to me that maybe you do know of a way of doing that with just sql. any hints?
[14:09] <gmb> intellectronica: Er... Lemme have a think for a sec.
[14:10] <gmb> intellectronica: So, no, I can't think of a SQL-only way to do it I'm afraid.
[14:10] <gmb> Because the job table is quite complex.
[14:10] <gmb> (Alhtough the BugJob table is stupidly simple)
[14:10] <intellectronica> gmb: oright, so a script creating jobs using the model object is the sensible way to go
[14:11] <gmb> intellectronica: Yes.
[14:11] <gmb> intellectronica: Though... how many are you planning to update?
[14:11] <intellectronica> gmb: cool, thanks
[14:11] <persia> Erm, why can't it be done with SQL?  It's just math, isn't it?
[14:11] <intellectronica> gmb: i was thinking of updating all bugs for malone
[14:11] <intellectronica> is that unrealistic?
[14:11] <gmb> intellectronica: Okay, sure, that sounds pretty sane.
[14:12] <gmb> intellectronica: To clarify, do you want SQL for creating jobs or just for updating heat?
[14:12] <gmb> Cos updating heat is easy peasy.
[14:12] <gmb> (As persia just pointed out)
[14:13] <intellectronica> gmb: no, i want to create jobs, because i want it to go through the webapp code and trigger recalculateMaxBugHeat too
[14:13] <gmb> intellectronica: Right, fair enough. Just checking that I understood properly
[14:16] <deryck> intellectronica, will this trigger max_bug_heat across all projects, or only for malone?
[14:16] <deryck> by "trigger" I really mean "update" :-)
[14:16] <intellectronica> deryck: only for malone
[14:17] <deryck> intellectronica, so maybe generate one job for any ubuntu bug, too, so we can see max_bug_heat updated for ubuntu bugs and check display of that, too.
[14:17] <intellectronica> deryck: ok, makes sense
[14:17] <deryck> intellectronica, thanks
[14:27] <sinzui> jpds: take a look at bug 181298 that I do not think you have seen. It may be invalid now
[14:27] <mup> Bug #181298: Get rid of DistributionMirror.official_candidate <mirror> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/181298>
[14:31] <james_w> using the API to add a tag on staging isn't working, any chance that this has broken server-side?
[14:32] <james_w> ah, it's ok, lists are odd in the LP API and I'm doing it wrong
[14:33] <thekorn> james_w, hehe, yes, .append is not working, you need to overwrite the list
[14:35] <james_w> hey thekorn
[14:35] <james_w> thekorn: are you able to easily reproduce bug 336866?
[14:35] <mup> Bug #336866: When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed" <tech-debt> <lazr.restful:Confirmed for leonardr> <lazr.restfulclient (Ubuntu):Triaged> <https://launchpad.net/bugs/336866>
[14:35] <james_w> I'm having difficulty
[14:37] <james_w> ok, I can do it with a newMessage call and manipulating tags, but not just tag manipulation
[14:39] <thekorn> james_w, yes I can reproduce this bug sometimes, but it is not clear to me under which condition this is reproducible
[14:41] <james_w> bug.newMessage seems to alter the bug, but it doesn't cause a refresh of the bug object
[14:41] <thekorn> james_w, one of my ideas (as descibed in https://bugs.edge.launchpad.net/launchpadlib/+bug/341950/comments/2) was that the http_etag attribute is not updated properly
[14:41] <mup> Bug #341950: lp_save gives HTTP Error 412: Precondition Failed when adding a comment to a bug, but adds the comment anyway <api> <launchpadlib :New for intellectronica> <https://launchpad.net/bugs/341950>
[14:41] <james_w> but I don't see why that should affect just changing tags
[14:49] <thekorn> argh, someone killed staging ;)
[15:11] <jml> hmm
[15:22] <adiroiban> sinzui: hi, for bug 527728, the component name should be exported as „component” , „component_name” or „latest_published_component_name” ?
[15:22] <mup> Bug #527728: Export source package component in API <api> <Launchpad Registry:In Progress by adiroiban> <https://launchpad.net/bugs/527728>
[15:25] <sinzui> adiroiban: I think component_name is correct
[15:25]  * sinzui looks
[15:26] <jml> mrevell, where's that terminology wiki page?
[15:27] <adiroiban> jml: https://dev.launchpad.net/PlainEnglish ?
[15:27] <sinzui> adiroiban: are you adding support to publish the component object, or flattening the data to return the string?
[15:27] <jml> adiroiban, thanks.
[15:28] <adiroiban> sinzui: flattening to return a string... since IComponent has only one attribute
[15:28] <adiroiban> the name
[15:28] <mrevell> jml, Took me a while to find as I gave it a stupid name. Thanks for getting it adiroiban :)
[15:28] <sinzui> adiroiban: SP.latest_published_component_name
[15:29] <adiroiban> sinzui: thanks!
[15:48] <adeuring> a reference to branches
[16:06] <noodles775> james_w: can you pls go over the following use-case text and edit as necessary? https://dev.launchpad.net/BuildBranchToArchiveUI/UseCasePackagingBranch
[16:06] <james_w> sure
[16:06] <james_w> thanks
[16:45] <leonardr> flacoste, gary: hopefully i've fixed it
[16:45] <gary_poster> leonardr: great news!
[16:52] <EdwinGrubbs> gary_poster: do you know if there is a way to pass a variable to a view included with <span tal:content="context/@@+someview" />
[16:53] <gary_poster> thinking, EdwinGrubbs
[16:55] <gary_poster> EdwinGrubbs: Eh, only hacks (maybe you could stash something in request.annotations with a Python expression?).  Alternatively, you could maybe make the view class make the call instead, and have your template call a method on your view class?  The view class could be a lot more flexible.
[16:55] <leonardr> gary, still seems to be another problem...
[16:56] <gary_poster> leonardr: ack.  lemme know if  can help, as before.  You still have an hour ;-)
[17:00] <leonardr> gary: it's a problem with launchpadlib, not with the web service but with the token authorization process
[17:00] <gary_poster> ack.
[17:01] <gary_poster> I guess it still needs to be fixed before we can deploy the other fixes though, so that the tests pass.
[17:01] <leonardr> the strange thing is, it didn't happen last time, and i've undone the only change i made to launchpad last time
[17:11] <deryck> leonardr, ping
[17:12] <leonardr> deryck: hey, i'm very busy right now but if you tell me what's up i can get back to you
[17:12] <deryck> leonardr, sorry.  just wondering if read_only attributes affect etag calculation if they change?
[17:13] <leonardr> deryck: they shouldn't
[17:13] <leonardr> deryck: sorry, i actually don't know
[17:13] <deryck> leonardr, ok, no worries.  we can discuss more later.
[17:24] <kfogel> adeuring: if I've modified lib/canonical/launchpad/javascript/bugs/bugtask-index.js (see http://paste.ubuntu.com/387117/), is there some command I have to run to make it take effect, like to rebuild a compressed javascript file or something?  The change doesn't seem to have had any effect.  On the other hand, the HTML for https://bugs.launchpad.dev/firefox/+bug/1 in my local instance refers to https://launchpad.dev/+icing/rev10420/bu
[17:24] <kfogel> ild/bugs/bugtask-index.js, and fetching that JS file shows my change is present.  Hmmm.
[17:24] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubuntu-expre
[17:25] <kfogel> shut up mup
[17:26] <adeuring> kfogel: I have no idea... Might also be a caching problem within your browser
[17:27] <deryck> kfogel, when you run the dev server, you're in devmode, which uses the individually linked files.
[17:27] <deryck> kfogel, so if your change isn't working, there's something wrong.  No make step is required.
[17:27] <kfogel> deryck: thanks
[17:32] <deryck> kfogel, you can do poor man's debugging with Y.log to see if the area of the code is called, if you don't want to breakpoint with firebug.
[17:33] <kfogel> deryck: thanks -- actually, I think learning how to breakpoint with firebug (which I did not know I could do until you said it just now) might be a good thing.
[17:34] <deryck> kfogel, in code, add a `debugger;` statement.  Or else open the script in firebug and toggle break points next to lines.
[17:34] <deryck> kfogel, the debugger statement is the easiest to me.
[17:35] <kfogel> deryck: thank you
[17:35] <deryck> kfogel, np
[17:37] <kfogel> deryck: whoa!  So I tried going to the .js line in firebug, and my changes are not there in firebug!  (Even though they are when I fetch the script using wget.)
[17:38] <deryck> kfogel, hmm, that's odd.
[17:38] <deryck> kfogel, need to do a call, but I can help debug further shortly.
[17:38] <kfogel> deryck: np.  I'll let you know if I solve it first.
[18:05] <deryck[lunch]> kfogel, sorry, off call, but reallllly need to eat now. :-)
[18:07] <kfogel> deryck[lunch]: np
[18:08] <kfogel> deryck[lunch]: I'm going to grab food too, so we're sort of in sync.  I think I have a clue as to what the problem is; will explain when we're both fed.
[18:27] <jml> I'm getting ValueError: ("Missing 'Version:' header and/or PKG-INFO file", ClientCookie [unknown version] (/usr/lib/python2.5/site-packages))
[18:27] <jml>  
[18:27] <jml> actually, nm.
[18:32] <jml> wait, definitely still getting it
[18:32] <jml> even with current stable
[18:32] <jml> ValueError: ("Missing 'Version:' header and/or PKG-INFO file", ClientCookie [unknown version] (/usr/lib/python2.5/site-packages))
[18:50] <jml> leonardr, is there a document on exposing things over the API?
[18:50] <leonardr> jml: you mean for developers?
[18:50] <leonardr> launcpad developers
[18:50] <jml> leonardr, for Launchpad contributors, yes.
[18:51] <jml> leonardr, I mostly know how to do it, but I'm helping someone else right now and want to save myself writing a poorer version line-by-line on IRC :)
[18:51] <leonardr> jml: it's not too great, but https://dev.launchpad.net/API
[18:52] <jml> leonardr, thanks.
[18:52] <jml> kfogel, when you've got a moment, can you link to https://dev.launchpad.net/API from https://help.launchpad.net/API?
[18:52] <jml> kfogel, I would but I don't have permission.
[18:56] <maxb> And if you're poking those pages, make them stop lying about the API still being in closed beta
[18:56] <maxb> :-)
[19:01] <jml> leonardr, there's still no way to have a read operation return a dict or a list that reliably preserves ordering is there?
[19:01] <leonardr> jml: no, i haven't had time to work on that
[19:02] <jml> leonardr, ok, thanks.
[19:13] <kfogel> jml: sure.  but grrr, what's with this not having perms to edit help.l.n?  I've filed an RT on this, but heard nothing yet AFAIK.
[19:14] <jml> what does this error mean? AssertionError: No IEntry adapter found for IGPGKeySet (web service version: devel).
[19:14] <jml> kfogel, yeah, that sucks.
[19:15] <jml> kfogel, send flacoste the RT number -- he can negotiate a priority bump
[19:16] <kfogel> jml: I will.   Heh, yes, it's RT 37638 and it's about *exactly* this API page.
[19:23] <james_w> jml: missing export_as_webservice_entry() perhaps?
[19:23] <jml> james_w: I don't think so
[19:23] <jml> james_w, class IGPGKey(IHasOwner):
[19:23] <jml>     """OpenPGP support"""
[19:23] <jml>     export_as_webservice_entry()
[19:24] <jml> class IGPGKeySet(Interface):
[19:24] <jml>     """The set of GPGKeys."""
[19:24] <jml>     export_as_webservice_collection(IGPGKey)
[19:25] <james_w> jml: IGPGKeySet will be a top-level collection?
[19:25] <james_w> lp.gpgkeys?
[19:25] <jml> james_w, I don't want it to be
[19:26] <james_w> I thought export_as_webservice_collection was for top-level only, but perhaps I mis-read
[19:27] <jml> james_w, if I remove that export, I get the same error, actually.
[19:27]  * jml tries
[19:29] <jml> yeah, if I remove the export then AssertionError: No IEntry adapter found for IGPGKeySet (web service version: devel).
[19:29] <james_w> is there an existing attribute/method you want something parallel to, or is this different to everything else?
[19:29] <jml> IPerson.gpgkeys
[19:29] <jml> that's what I want
[19:29] <jml> it's a list of objects
[19:30] <jml> there are many like it, but this one is mine
[19:30] <james_w> like IPerson.confirmed_email_addresses
[19:31] <jml> yes
[19:32] <jml> ahhh, I see the issue.
[19:32] <james_w> that uses exported(CollectionField()) rather than a collection class it seems
[19:34] <jml> the code here had value_type=Reference(IGPGKeySet)
[19:34] <jml> in IPerson
[19:34] <jml> the error made me think that I should be looking in IGPGKeySet
[19:48] <jml> abentley, I'm not compus mentus enough to do a review of your scanner events patch
[19:49] <jml> abentley, but I think that Fixtures([ServerFixture(...)]) can be replaced with ServerFixture(...)
[19:49] <abentley> jml, Ah, cool.
[19:50] <jml> abentley, and I think that leaving the @adapter decorators in the code is still a good idea. Moving the registration into zcml seems like a good idea though
[19:51] <abentley> jml, what's the value in retaining the adapter decorators?
[19:51] <jml> abentley, I guess it's a taste thing.
[19:52] <jml> abentley, it means less configuration, and I think appropriately less.
[19:52] <jml> since, say, got_new_revision is never going to handle events other than INewRevision
[19:53] <abentley> I don't understand how it means less configuration.
[19:53] <jml> abentley, means less configuration in the zcml, I guess.
[19:53] <jml> afaict, it's only a taste thing.
[19:54] <jml> as I said though, I'm not particularly compus right now
[19:54] <jml> (wuu jetlag)
[19:54] <abentley> jml, are you suggesting that if the adapters were retained, we could omit the for= stanzas values from the subscriber elements?
[19:55] <jml> abentley, oh yes.
[19:55] <jml> abentley, you could definitely do that.
[19:55] <abentley> jml, it sounds like that's not actually what you meant, though.
[19:55] <jml> abentley, sorry, I was thinking that really hard. I must be in a Faraday cage or something
[19:56] <jml> abentley, yes. what I meant was, retain @adapter(TipChanged), remove the for= line from zcml, jml prefers this but can't explain why.
[19:57] <abentley> jml, thanks for explaining that.  For my taste, it's nicer to have both the "for=" and "handler=" in one place, though.
[19:58] <jml> abentley, ok
[19:58] <jml> abentley, I guess the new job-driven scanner is already loading zcml
[19:59] <abentley> jml, it is.  We has a test that an email job is created by the scanner.
[20:00] <jml> abentley, cool.
[20:00] <jml> abentley, one of the reasons for the old system was avoiding the 2+ second zcml load time
[20:02] <abentley> jml, UpdateBranches is a LaunchpadCronScript, so it also loads the zcml.
[20:02] <jml> *nod*
[20:02] <abentley> jml, so even with the old script, we were loading the zcml.
[20:03] <jml> abentley, I'm surprised and even sceptical
[20:03] <jml> abentley, but will defer to your more current knowledge
[20:03] <jml> oh wait
[20:03]  * jml does some logic
[20:03] <jml> yeah, you're right.
[20:04] <abentley> jml, see LaunchpadScript.run
[20:04] <jml> abentley, well, more relevantly to my addled brain, we getUtility(IBranchScanner) at least once :)
[20:05] <abentley> jml, that too.
[20:12] <mwhudson> uh yeah, anything that talks to the db pretty much has to load the zcml
[20:12] <thumper> morning
[20:26] <kfogel> deryck: so, what I've learned is a) firebug swears those new statements in my patch are being executed, and b) they don't seem to actually affect the body tag in the page, and c) the statements already there, which did the same class mods for the privacy_div tag, also have no effect.  IOW, this code has never been working, even before.  There must be some additional step necessary to get the class change to take effect?  http://paste
[20:26] <kfogel> .ubuntu.com/387117/
[20:58] <kfogel> leonardr: know enough about javascript to know the answer to my question to deryck above?
[20:59] <kfogel> leonardr: the paste is for bug 471195
[20:59] <mup> Bug #471195: Private bugs don't set the body class to "private" <css> <privacy> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/471195>
[21:03] <leonardr> kfogel, give me a minute
[21:03] <kfogel> leonardr: np
[21:04] <leonardr> kfogel: i suspect i will not know enough about javascript; maybe you should try to contact mars in case that's true
[21:04] <kfogel> mars: ayt?
[21:04] <kfogel> leonardr: pinging him
[21:18] <leonardr> kfogel: confirmed, i have no idea what that paste means
[21:19] <mwhudson> kfogel: i'm pretty sure that calling addClass, replaceClass etc takes effect immediatly
[21:19] <kfogel> leonardr: heh, np.  Basically I'm adding/removing one of the class attribute values from a document's <body> tag, but the change isn't taking effect.  Then I realized old code to do effectively the same thing also was having no effect, and that made me wonder what's missing here.
[21:20] <kfogel> mwhudson: there's a replaceClass?  I might try using that; it would simplify the code.
[21:20] <mwhudson> um
[21:20] <mwhudson> maybe?
[21:20] <mwhudson> i think so
[21:20] <kfogel> mwhudson: but it's definitely not taking effect, unless there's some weird browser caching issue going on.
[21:20] <kfogel> I have to manually reload the main page to get it to take effect.
[21:20] <mwhudson> my knowledge of all this is pretty ancient, and not from the launchpad context
[21:20] <kfogel> mwhudson: *nod*
[21:22] <mwhudson> kfogel: i guess i'd try to come up with a tiny example, i.e. write some html by hand
[21:22] <mwhudson> (there is a replaceClass btw)
[21:23]  * mars reads the backchat
[21:28] <kfogel> mwhudson: yep
[21:28] <mars> kfogel, yep, start with http://developer.yahoo.com/yui/3/api/Node.html#method_replaceClass, add a debugger statement on the line before
[21:28] <mars> 'debugger;'
[21:29] <kfogel> mars: thanks!
[21:29] <mars> replaceClass is too convenient to pass up :)
[21:30] <mars> Node also grew a setContent method, but set('innerHTML'...) works too
[21:30] <mars> http://developer.yahoo.com/yui/3/api/Node.html#method_setContent
[21:30] <kfogel> mars: btw, I'm using http://paste.ubuntu.com/387235/ to look for stuff in Launchpad js files, with commands like 'find . -name "*.js" | xargs grep "replaceClass" | ~/bin/no-longer-than'
[21:31] <kfogel> mars: otherwise you get those massive js lines that block out everything else
[21:32] <mars> kfogel, ?  Are you running in devmode?  The JS should be plain, uncompressed
[21:32] <kfogel> mars: i'm in devmode, but my working tree still has the compressed js files
[21:32] <mars> and they are being used?
[21:33] <mars> in Firebug, in the Script tab
[21:33] <mars> and in the document head?
[21:33] <kfogel> mars: no, AFAICT they are not.  I'm debugging with firebug and it's stepping across exactly the lines I expect it to be stepping across, in the files I expect it to be in.
[21:33] <mars> ok
[21:33] <kfogel> mars: I'm talking about when I'm trawling the code for examples to guide me -- not run time, coding tim.
[21:33] <kfogel> time
[21:33] <mars> ah
[21:34] <mars> I had to create a custom search for that :/
[21:34] <mars> +lib/lp, +lib/canonical/lazr, +lib/canonical/launchpad/javascript
[21:34] <mars> Paul is about to fix that though
[21:35] <jelmer> mwhudson: btw, bzr+bzr-git should now support enough to enable colocated branch fetching in code import
[21:35] <mwhudson> jelmer: oo
[21:35] <mwhudson> jelmer: something to try to get working for the next rollout?
[21:36] <jelmer> mwhudson: yeah, that'd be nice
[21:36] <mars> kfogel, let me know when you hit that debugger statement, then we'll use the console to test some nodes
[21:36] <jelmer> mwhudson: would require an extra field in the UI for the branch name at the moment
[21:36] <jelmer> mwhudson: is that what you'd want in the end too, or would you want to have that in the URL?
[21:36] <kfogel> mars: sure, one minute.  and thanks.
[21:37] <mwhudson> jelmer: we couldn't say git://git.gnome.org/gedit.git,feature-x ?
[21:37] <jelmer> mwhudson, not yet
[21:37] <mwhudson> jelmer: it would be easier if we could put it in the url
[21:37] <jelmer> mwhudson, ok, in that case we should wait for a bit more
[21:37] <mwhudson> jelmer: or even better, import all the branches into a colocated branch
[21:37] <mwhudson> but i guess that's a little way off :)
[21:38] <mwhudson> ffs
[21:38] <jelmer> mwhudson: welcome back (-:
[21:38] <mwhudson> jelmer: sorry, did i miss anything there?
[21:38] <jelmer> mwhudson: nope
[21:38] <mwhudson> k
[21:38] <jelmer> mwhudson: I guess colocated branch support in one of Bazaar's formats is further away
[21:39] <jelmer> mwhudson: it would require a new format as well as support in loggerhead/launchpad/qbzr/bzr-gtk
[21:39] <mwhudson> yeah
[21:45] <leonardr> gary, thumper, all tests pass successfully
[21:45] <thumper> leonardr: awesome
[21:45] <gary_poster> leonardr: fantastic
[21:45] <thumper> leonardr: devel has closed
[21:45] <thumper> leonardr: so land on db-devel
[21:45] <leonardr> thumper, can you walk me through it? are there instructions anywhere?
[21:45] <thumper> leonardr: bzr pqm-submit --submit bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
[21:46] <thumper> -m "..."
[21:46] <leonardr> thumper: anything special i need to put in the -m? [rc=thumper] or something like that?
[21:47] <kfogel> mars: okay, I'm on https://bugs.launchpad.dev/firefox/+bug/1 with my firebug console open, having just restarted my dev instance.  The current patch in my working tree is: http://paste.ubuntu.com/387241/ .  I am about to go to the public/private portlet and toggle from public to private.
[21:47] <mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubuntu-expre
[21:47] <kfogel> mars: mup is wrong, and some day I want to fix this bug in mup :-).
[21:47] <thumper> leonardr: yeah
[21:47] <thumper> leonardr: [release-critical=thumper][r=gary][ui=none]
[21:49] <leonardr> thumper: submitted, let me know if you see problems
[21:49] <mars> kfogel, ok.  That should hit the debugger automatically then.  BTW, you do not have to restart between template and JavaScript file changes in devmode - convenient.
[21:49] <thumper> leonardr: ok
[21:49] <kfogel> mars: cool.  I was being paranoid.
[21:50] <kfogel> mars: okay, I'm breakpointed (brokepoint?) on line 525 of that js file ("lp_bug_entry = updated_entry;")
[21:50] <kfogel> about to enter the if(private) condition
[21:51] <mars> kfogel, ok.  First see if it enters the conditional branch you expect
[21:51] <mars> kfogel, then we will try a node test or two
[21:51] <kfogel> mars: it does
[21:51] <mars> ok
[21:51] <kfogel> I'm now on line 528.  (So far, same behavior as I have seen before.)
[21:51] <mars> kfogel, in the console, try 'Y.one('body')'
[21:52] <kfogel> oh, I forgot to mention that when I started, when the bug page was "public", the body tag had the class public.
[21:52] <mars> see what it returns
[21:52] <mars> ok
[21:53] <kfogel> mars: just type that at the >>> prompt in the console?
[21:53] <mars> yep
[21:53] <kfogel> mars: OH
[21:53] <kfogel> d'oh
[21:53] <kfogel> syntax
[21:53] <kfogel> error
[21:53] <kfogel> forgot my semis
[21:53] <kfogel> one sec
[21:54] <mars> well, JS doesn't /technically/ require them... but lets not go there.
[21:55] <kfogel> mars: BODY#document.tab-bugs . main_side public yui-skin-sam yui_3_0_0-4-1267566838367281 { _yuid="yui_3_0_0-4-1267566838367281",  more...}
[21:55] <kfogel> mars: looks good to my untrained eye... ?
[21:56] <mars> kfogel, looks ok.  You can also try Y.one('body').getAttribute('class') to see the class list
[21:56] <mars> more easily
[21:56] <kfogel> oooooh
[21:56] <kfogel> thanks
[21:56] <kfogel> let me try it
[21:57] <kfogel> "tab-bugs main_side public yui-skin-sam"
[21:57] <kfogel> as I expected
[21:57] <mars> or >>> d = Y.Node.getDOMNode;
[21:57] <mars> >>>  d(Y.one('body'));
[21:57] <mars> ok
[21:58] <mars> kfogel, now try the replaceClass call, then print the node again
[21:58] <kfogel> mars: I'm going to just step it, right?  (not write it out)
[21:58] <mars> I wonder if Firebug supports lazy typing?  >>> Y.one 'body'
[21:58] <mars> kfogel, yep
[21:59] <kfogel> mars: oh frig... ffox crashing again
[21:59] <kfogel> this happens like once a day now
[21:59] <kfogel> freezes up my whole system too
[21:59] <mars> Yep! :)
[21:59] <mars> Welcome to Front End Engineering!
[22:00] <kfogel> sigh
[22:00] <kfogel> ok
[22:00] <kfogel> mars I may disappear for a bit, back as soon as I can
[22:00] <kfogel> if restarting ffox doesn't work, I will have to reboot
[22:00] <mars> I still think part of the reason Chrome is popular among web devs is because it *isn't* loaded down with a dozen extensions
[22:01] <mars> kfogel, k
[22:01] <mars> no extensions makes for a much faster browser
[22:12] <kfogel> mars:  I return.
[22:12] <mars> kfogel, ok, let me know when you get the debugger context back
[22:16] <kfogel> mars: you know, I wonder if it's running launchpad that kills my system.
[22:16] <kfogel> mars:  I just rebooted, and I'm already back to sluggishness levels like the ones that caused me to reboot.
[22:16] <kfogel> mars: s'okay, can work with this for now.  but ffox will be slow.
[22:16] <mars> kfogel, odd, should be fine on a fresh boot.  How much RAM do you have?
[22:17] <mars> I have 4GB.  Usually works well.
[22:17] <kfogel> mars: anyway: bug is marked as public right now, body class confirmed as public, and am about to toggle to private with breakpoint set in firebug.
[22:17] <kfogel> mars: I have 2G
[22:17] <mars> Once every few months it hits swap
[22:17] <mars> ok
[22:18] <mwhudson> kfogel: going from 2 to 3 gigs really made my life better
[22:18] <mars> I run between 2.1 to 3GB pretty consistently.  So 2GB may well not be enough.
[22:18] <mwhudson> sad, but...
[22:18] <mars> Dual core or more helps too
[22:19] <kfogel> mwhudson: wow.  Only wish I had known this when I bought it.
[22:19] <kfogel> mars: it's a dell xps M1330
[22:19] <kfogel> dual core
[22:19] <mars> should be upgradeable.  IIRC beuno runs 3GB on his
[22:20] <mwhudson> i got so fed up i just walked into a computer store and paid $70 for a 2 gig stick
[22:20] <kfogel> mwhudson: I think that's in my future.
[22:20] <beuno> I haz 4gb
[22:20] <mwhudson> speaking of which, if anyone wants a 1 gig SO-DIMM.....
[22:21] <kfogel> mars: just hit breakpoint again, on the if(private)
[22:21] <mars> k
[22:21] <kfogel> mars: whups
[22:21] <kfogel> nope
[22:21] <mars> ?
[22:22] <kfogel> when I toggled, the spinner spun, and then the box (in which I checked "private") got a red error that I have seen once before:
[22:22] <kfogel> "The following errors were encountered: No operation name given"
[22:23]  * mars shrugs
[22:23] <mars> Haven't seen that one
[22:24] <mars> Did it do that last time?
[22:27] <kfogel> mars: not sinc once yesterday
[22:27] <kfogel> mars:  sorry, delay in responding is the machine, not me
[22:27] <kfogel> takes that long to switch back to this window!
[22:29] <kfogel> "A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.
[22:29] <kfogel> Script: https://launchpad.dev/+icing/rev10420/yui/attribute/attribute.js:104"
[22:30] <mars> kfogel, what were you doing when it raised that error?
[22:30] <kfogel> mars: well, it's hard to say, because it's hard to know what events ffox heard and which ones it didn't.
[22:30] <kfogel> I was trying to get the bug back to pristine state (i.e., public, with body class saying "public"), so I could repeat the toggle.
[22:30] <mars> kfogel, ok, maybe comment out the debugger statement, get everything running without.  Then uncomment it, F5
[22:31] <kfogel> mars: note there was never a debugger statement -- I was just using firebug
[22:31] <kfogel> mars: I just had to kill the browser, though.  It was unusable.
[22:32] <mars> kfogel, then why did it stop on the if (private) call?  (Or did it?)
[22:32] <kfogel> mars: sorry, I havne't been able to explain the chaos over here
[22:32] <mars> ok :)
[22:32] <kfogel> mars: after reboot, the machine quickly became unusuable again
[22:32] <kfogel> mars:  I tried to debug, but thne spent much effort just trying to get ffox to respond
[22:32] <kfogel> I've killid it now
[22:33] <kfogel> mars: I've shut down ffox and launchpad dev instance server.
[22:33] <kfogel> mars: yet box is still crawling.  frigg.
[22:33] <mars> bitten swap?
[22:33] <kfogel> top shows nothing
[22:33] <kfogel> mars: what does "bitten" mean?
[22:33] <mars> as in, "you took a bite out of it".  Swap space is bitter stuff.
[22:34] <mars> slows the whole system down, even after you have freed up memory elsewhere.
[22:34] <mars> for a little while at least.
[22:34] <kfogel> mars: hunh.  I don't know if I ever touched it.
[22:36] <kfogel> I'm going to see if I can find a computer store.  I'll be literally unable to work until this is fixed.
[22:36] <kfogel> bbiab
[22:36] <mars> hehe, ok
[22:36] <mars> kfogel, I may be offline by then
[22:36] <mars> almost EOD here
[22:36] <mars> kfogel, ping me tomorrow, I can work with you some more on this
[22:37] <mars> kfogel, I'm in EST, same as you
[22:37] <kfogel> mars: thanks
[23:39] <kfogel> mars: still there?  I got RAMz.  rebooting again :-).