[00:05] <taxilian> I wasn't; I tried --all, and it didn't show up there either
[00:06] <fullermd> Well, if it doesn't show up in --all, it's not a dead; it's an ancestor of some other rev.
[00:06] <fullermd> Did you commit after that update?
[00:06] <taxilian> I did
[00:06] <taxilian> because it still showed the change packages
[00:06] <taxilian> so I thought they were still there
[00:06] <fullermd> Well, then that's why it's not a head   :p
[00:07] <taxilian> ok; is there still a way to fix it?
[00:07] <fullermd> Well, they ARE there.
[00:07] <taxilian> I know what the comments are, or at least some specific keys in them
[00:07] <taxilian> would that help?
[00:07] <fullermd> So, let's step back; what state of affairs do you want to end up with, and why is that different from the current?
[00:08] <taxilian> I want to end up with the branch I had before I: bound to another branch, updated, and committed
[00:08] <taxilian> and the reason it's different is that the branch I had had some new changes that should have been pushed to the branch I accidently bound to
[00:09] <fullermd> OK, well they're there now.  Does it matter that they're there via a merge rather than pushed onto the lefthand ancestry?
[00:09] <taxilian> but that's just it; they aren't there
[00:09] <taxilian> bzr status -v lists all the "pending merges", but none of the changes are there
[00:09] <taxilian> the new files are missing, the changes are reverted
[00:10] <taxilian> no backups
[00:10] <taxilian> this represents 4 days of work; you can understand why I'm a little agitated about it =]
[00:10] <fullermd> ....
[00:10] <fullermd> Something doesn't add up.
[00:10] <taxilian> that's what I thought
[00:10] <fullermd> If you commit'd, there won't be pending merges sitting around, because they won't be pending any more (being committed)
[00:10] <taxilian> I uncommitted
[00:11] <fullermd> Before or after you unbound?
[00:11] <taxilian> but that is why I committed; I thought that even though I bound to another branch (the one I branched off of) and updated, that the changes would still be there, just waiting to be committed
[00:11] <taxilian> here, let me tell you the whole sequence:
[00:11] <fullermd> They would be.
[00:11] <taxilian> bzr branch <remote branch>
[00:11] <taxilian> bzr unbind
[00:11] <taxilian> <change a bunch of stuff, work for 4 days>
[00:12] <taxilian> bzr commit
[00:12] <taxilian> bzr merge <remote branch>
[00:12] <taxilian> bzr bind <remote branch>
[00:12] <taxilian> bzr update
[00:12] <taxilian> bzr status -v (at this point, files are gone, but still shows the pending merges)

[00:12] <taxilian> bzr commit (thinking that since the pending merges show, the files are still there)
[00:12] <taxilian> <panic more> (they aren't)
[00:12] <taxilian> bzr unbind
[00:13] <taxilian> bzr uncommit
[00:13] <taxilian> there I stand
[00:13] <fullermd> So, the remote end still has that commit you made?
[00:13] <taxilian> yes
[00:13] <taxilian> presently
[00:13] <fullermd> Which has all those revs in its ancestry.
[00:14] <taxilian> the local should have all the revs in ancestry, since I was unbound when I did them
[00:14] <taxilian> the remote does not
[00:14] <fullermd> The remote does if you committed a merge of them while you were bound to it.
[00:14] <taxilian> but that commit doesn't seem to have sent any files
[00:14] <taxilian> because when I updated, the files and changes all magically disappeared
[00:14] <fullermd> Stipulating that, it will still have sent the revs.
[00:15] <taxilian> I'll check the remote log
[00:15] <fullermd> You can't (barring minor magic) stuff around a rev without stuffing around its ancestors.
[00:15] <taxilian> let us hope that I am no magician; give me a sec to dig a bit
[00:16] <fullermd> Unless you tried to (which means at the least you dug up and did the push via writing code against bzrlib), you didn't.
[00:16] <taxilian> nope; it acts as if the commit I made (Despite the claimed "pending merges") was a no-file merge
[00:17] <fullermd> Forget files.  Look at the revs.
[00:17] <taxilian> it's as if the update erased all my changes, but somehow didn't erase the "pending merges"
[00:17] <taxilian> I'm looking at revs
[00:17] <fullermd> Are you using -n0 on log?
[00:17] <taxilian> there is a rev with the message I used on the commit, but none of the other ones are there
[00:17] <taxilian> I am not
[00:17] <taxilian> one sec
[00:17] <taxilian> ahh, that looks more promising
[00:17] <taxilian> give me a sec to try a revert
[00:19] <fullermd> So you can use that to find the revid, and use pull to swap yourself around to that state.
[00:20] <fullermd> I'm a bit suspicious of ending up with no files changes though.  Barring big bugs, merge wouldn't quietly do that given reasonable assumptions about prior states.
[00:20] <taxilian> I will try that
[00:20] <taxilian> thank you
[00:20] <taxilian> yeah; that's why I'm so confused
[00:20] <taxilian> I thought I'd tried this before and it worked as I expected
[00:20] <fullermd> Generally, either suggesting the merge you did earlier was botched, or you ran something like 'revert .' after the update.
[00:20] <taxilian> I can guarantee that was not the case; I built after the merge, and then I did a bind and an update; all the changes went away
[00:21] <taxilian> this is bzr 1.18.1, incidently
[00:21] <fullermd> I don't suppose it's a public branch?
[00:22] <taxilian> it isn't
[00:25] <fullermd> If you can pastebin a 'log -vn0' from before the point where you initally branch'd up through that last commit, we may be able to make some guesses as to what happened when.
[00:25] <fullermd> But that may expose more info than you want.  Probably doesn't matter in itself, would just be informative.
[00:30] <taxilian> give me a few minutes; I did find the files I need (thank you!) and I need to restore the branch so someone else can use it
[00:31] <fullermd> I'd do 3 times:
[00:31] <fullermd> 1) Preserve the existing (broken in aggregate, but containing all necessary pieces) state of the main branch by branch'ing it somewhere local
[00:32] <fullermd> 2) 'fix' it by using pull/push/something to reset its head to the state prior to that (poking at log should reveal it to you)
[00:32] <fullermd> 3) Do the same to 'your' branch
[00:32] <fullermd> Then you're in a state to move forward, and you have a copy of the b0rkenness for analysis.
[00:32] <taxilian> I'm just going to revert and then commit
[00:32] <taxilian> so the history is intact
[00:33] <fullermd> That...  doesn't some like what you want at all.
[00:33] <fullermd> sound
[00:33] <taxilian> ... it gets all my files back where I want them;
[00:33] <taxilian> why is it not what I want?
[00:33] <fullermd> Well, it leaves a big ugly lump in your history, for one.
[00:34] <fullermd> And are you sure what you're reverting to is what you should be?  The weird state you ended up in suggests things awry.
[00:34] <taxilian> I'm testing the build, but it looks like it is all restored
[00:34] <taxilian> there is just one extra revision that somehow reverts it all back to before my work
[00:34] <taxilian> if I revert back one sub-revision, it works fine
[00:35] <fullermd> Well, it's your codebase.
[00:35] <taxilian> hehe
[00:35] <fullermd> From where I sit, there are only two states I'm confident are good: the remote branch before it got hit with the commit of that update pivot, and your local branch before your merge of the remote.
[00:36] <fullermd> Everything after that, I question.  So if it were me, I'd back up to those two places and try going forward from there again.
[00:37] <fullermd> You're sitting in front of more info about the code than I am, so if you're confident in that first merge, you can try going forward from there instead.
[00:38] <taxilian> yeah, I'm looking over a full diff to make sure
[00:38] <fullermd> I'd be very down on going forward from after that second merge though; just reverting the files and commiting a new rev on top will lose any annotations at the least.
[00:41] <fullermd> Anyway, I must off.  I'm on serious plus time for sleep.
[00:43] <taxilian> I appreciate your help
[00:43] <taxilian> it was a lifesaver
[00:45] <RenatoSilva> verterok: hi
[03:08] <poolie> kfogel: i really wasn't feeling guilty
[03:08] <poolie> i was just saying thanks
[03:09] <kfogel> poolie: oh, I know; my first line there was just a joke.  I knew you'd already seen the joke, but this is open source, so there's always more audience for the same joke :-).
[03:09] <poolie> Year of the Linux Desktop ;-)
[03:14] <RenatoSilva> verterok: hi
[03:14] <verterok> RenatoSilva: hi
[03:15] <verterok> RenatoSilva: your patch for redstone xmlrpc is already fixed in 1.1.1 :)
[03:15] <RenatoSilva> verterok: did you see my comments to you here yesterday?
[03:16] <verterok> RenatoSilva: nope, crappy network connection
[03:16] <RenatoSilva> verterok: you mean redstone guys have applied the fix? I see no status change in SF
[03:17] <RenatoSilva> verterok: I think you have heard of the blackout here, that's why I was disconnected
[03:18] <verterok> RenatoSilva: a different patch, but the same fix
[03:20] <RenatoSilva> verterok: I saw you have merged the changes, with them I could run all the tests successfully (0 errors/failures) in mvn, eclipse and in hudson
[03:21] <RenatoSilva> verterok: 1.1.1 is the version in the winXP repo here (I'm in Ubuntu now), but isn't it the same version since we beginned to work on this?
[03:22] <RenatoSilva> verterok: I mean, I've got the impression that 1.1.1 is the unpatched version
[03:23] <verterok> RenatoSilva: I did checjkut from their svn
[03:23] <verterok> *checkout
[03:24] <RenatoSilva> verterok: ok so it's not 1.1.1 right. I was testing yesterday: the 1.1.1 version causes test errors, when I replace it with the patched version, the errors dissapear
[03:26] <RenatoSilva> verterok: it's weird but I was testing a few minutes ago, and now I'm getting errors (1 or 2) in winXP regarding file access/permission, both in eclipse and mvn
[03:26] <verterok> RenatoSilva: I think that's my fault
[03:27] <verterok> I changed a call from getCanonicalPath to getPath in the TestsConfig class
[03:28] <RenatoSilva> verterok: that is, no errors/failures yesterday, but one or two errors today :( One thing different I've done is that I've updated bzr-xmloutput with the latest version from trunk (I think it was in rev 101 and I pulled 6 revs or so). Would that be the cause?
[03:29] <RenatoSilva> verterok: hm, I don't remember if the test success was with the getPath stuff merged
[03:29] <verterok> RenatoSilva: it's one line change, revert it ;)
[03:31] <RenatoSilva> verterok: I was trying now to run the tests in Ubuntu, but I can't. The deb package from apt repo is 0.8.3, but I get errors with that version
[03:32] <verterok> RenatoSilva: yes, it's quite old
[03:33] <RenatoSilva> verterok: I tried to replace it with trunk, but failed. It's easy in windows, you just replace/update the xmloutput folder.  Here in Ubuntu it's not, can't get the plugin loaded by bzr, it seems that there are external metadata invloved. I tried to install the deb, and replace the dir with trunk, but didn't work either :(
[03:33] <RenatoSilva> verterok: so you have uncommitted the getPath change?
[03:34] <RenatoSilva> verterok: it is still there: I've done
[03:34] <verterok> RenatoSilva: not yet
[03:34] <RenatoSilva> s/I've done/http://bazaar.launchpad.net/~verterok/bzr-java-lib/encoding-and-test-fixes/revision/215
[03:35] <RenatoSilva> you'll have to uncommit twice right? that will break my branch , right? (because I've merged that revision)
[03:36] <verterok> no, I already merged your branch
[03:37] <RenatoSilva> but my branch have merged yours
[03:37] <verterok> RenatoSilva: I'll resolve the conflict :)
[03:38] <RenatoSilva> hum, to undo the chnage you won't uncommit it, you'll do a new commit to get back to getCanonicalPath(), right?
[03:38] <verterok> RenatoSilva: I changed that because I'm having probles with a path containing: ó
[03:39] <verterok> RenatoSilva: right
[03:40]  * RenatoSilva suffers of the uncommit syndrome
[03:42] <RenatoSilva> verterok: let me go back to windows, I'll change that line and see if the tests pass. I'll rollback the xmloutput too
[03:54] <RenatoSilva> verterok: back in winxp
[03:54] <RenatoSilva> verterok: yesterday: http://img195.imageshack.us/img195/2136/testsok.png
[03:55] <RenatoSilva> verterok: when I go back to getCanonicalPath, I get 5 errors
[03:56] <verterok> ouch
[03:56] <RenatoSilva> verterok: if I keep getPath, I get only 1 error
[03:56] <verterok> RenatoSilva: I'm getting errors in linux with getPath
[03:57] <RenatoSilva> verterok: this one? http://steppenwolf.selfip.net/hudson/job/bzr-java-lib%20%28encoding%20and%20tests%20fixes%29/org.vcs.bazaar.client$bzr-java-lib/16/testReport/org.vcs.bazaar.client/BazaarClientTest/testAnnotate/?
[03:58] <verterok> RenatoSilva: yeap
[03:59] <RenatoSilva> it's the same string except for the leading /home in the actual version
[04:01] <RenatoSilva> verterok: do you know how to install the trunk version of bzr-xmloutput in Ubuntu? That way I could also run the tests in *nix, and check the errors
[04:02] <RenatoSilva> so simple in win, but not in linux
[04:02] <verterok> RenatoSilva: first unintall the package
[04:02] <RenatoSilva> already unisntalled it
[04:02] <verterok> RenatoSilva: and after that: mkdir ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr branch lp:bzr-xmloutput xmloutput
[04:07] <RenatoSilva> verterok: nice! I'll try that
[04:07] <RenatoSilva> verterok: I've continuously uncommitting the recent changes in xmloutput's trunk
[04:08] <RenatoSilva> verterok: getting different ammount of errors on each
[04:08] <verterok> RenatoSilva: the hudson instance is using xmloutput trunk
[04:08]  * RenatoSilva uncommitting till find any working rev
[04:09] <verterok> RenatoSilva: what errors are you getting?
[04:14] <RenatoSilva> verterok: reverted a few changes and didn't get it working, let me go back to tip and show you the error
[04:14] <lifeless> verterok: why don't you use subunit2junitxml in http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/lastBuild/testReport/
[04:15] <verterok> lifeless: good point, actually the bzr-xmloutput job isn't configure yet, I was trying to use pyjunitxml
[04:15] <RenatoSilva> verterok: you're using xmloutput trunk in hudson? then it may something with my local machine, just passed all tests there: http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/21/
[04:16] <lifeless> verterok: bzr selftest xmloutput --subunit | subunit2junitxml -o tests.xml
[04:16] <verterok> lifeless: oohhh, nice!
[04:17]  * verterok update the job config
[04:17] <lifeless> you'll need python-junitxml, subunit-0.0.1 installed
[04:18] <verterok> lifeless: is there a package/ppa?
[04:18] <lifeless> its all in karmic
[04:18] <lifeless> and yes, there is a usbunit ppa or two
[04:18] <verterok> even better! :)
[04:22] <RenatoSilva> verterok: with mvn I get 1 error: http://pastie.org/694861.txt
[04:22] <verterok> lifeless: I can't find pyjunitxml :/
[04:22] <RenatoSilva> verterok: O arquivo j\xe1 est\xe1 sendo usado por outro processo. == the file is already being used for another project
[04:23] <RenatoSilva> verterok: * by another proecess
[04:23] <verterok> RenatoSilva: yes, that's weird..the same test fails all the time?
[04:23] <RenatoSilva> verterok: let me run again
[04:24] <lifeless> verterok: apt-get install python-junitxml
[04:24] <verterok> lifeless: yes, it can't find it
[04:25] <lifeless> checking
[04:25] <lifeless> I may not have managed to get it synced to ubuntu before release
[04:25] <RenatoSilva> verterok: different error now! org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: Permission denied: "C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests658081888924229416/working_copies/unknowns/.bzr/branch/lock/held": [Error 5] Acesso negado
[04:25] <verterok> lifeless: oh, ok. I can use the debian deb :)
[04:26] <verterok> RenatoSilva: yes, looks like a race condition...but we don't use threads..so this is weird
[04:26] <lifeless> verterok: do you hold open multiple locks?
[04:27] <verterok> lifeless: I don't open locks :)
[04:27] <verterok> lifeless: xmloutput starts a long running xmlrpc service, and bzr-java-lib sends requests (commands) to it
[04:27] <verterok> lifeless: plain bzr CLI commands
[04:28] <verterok> lifeless: the xmlrpc service just use some hacks to get the output but it basically calls run_bzr
[04:29] <RenatoSilva> verterok: man, that's crazzy, it was working perfectly yesteday. What I did to cause this?
[04:30] <RenatoSilva> verterok: tested the getPath, and xmloutput, didn't work
[04:30] <verterok> RenatoSilva: did you updated bzr/xmloutput/python/anything? :)
[04:30] <RenatoSilva> verterok: well I've installed AVG9, can't see anything else new I've done
[04:31] <RenatoSilva> verterok: as I said I've pulled the latest changes (5 or 6 revs) from trunk in xmloutput
[04:31] <verterok> RenatoSilva: what's AVG9? :)
[04:32] <RenatoSilva> verterok: but I uncommitted them till get to the latest merge you did from my fixes, and I get errors still
[04:32] <RenatoSilva> verterok: anti-virus :)
[04:32] <verterok> RenatoSilva: I think there are some issues with anti-virus and bzr...but I'm not sure
[04:32] <RenatoSilva> verterok: man, the errors are random
[04:32] <verterok> lifeless: do you know? ^
[04:33] <RenatoSilva> verterok: I'm running  in eclipse, I had 1 error, now I have 3 errors
[04:33] <lifeless> antivirus does ten to interfere
[04:34] <RenatoSilva> verterok: des any process (bzr/python) is started with another user by any chance?
[04:34] <verterok> RenatoSilva: nope
[04:38] <RenatoSilva> oh, can't turn AVG off :(
[04:38] <lifeless> verterok: did you get that deb?
[04:38] <verterok> lifeless: I'm waiting the upgrade to finish
[04:39] <lifeless> :P
[04:40] <lifeless> verterok: yeah, it didn't hit ubuntu for some reason. its in unstable and testing
[04:43] <RenatoSilva> verterok: deactivated AVG and win firewall, but still getting erros :(
[04:43] <RenatoSilva> verterok: random errors :(
[04:44] <verterok> hmm, that's weird
[04:44] <verterok> :(
[04:45] <RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
[04:45] <RenatoSilva> verterok: also access denied
[04:50] <RenatoSilva> how can it tell C:\Arquivos de programas\Bazaar\bzr.exe is unknown, but just sometimes
[04:54] <_Andrew> heya
[04:54] <lifeless> verterok: still failing :P
[04:54] <lifeless> _Andrew: hai
[04:54] <verterok> lifeless: yeap
[04:59] <verterok> lifeless: https://pastebin.canonical.com/24652/
[04:59] <verterok> ooops, wrong pastebin, sorry
[05:00] <verterok> lifeless: http://pastebin.ubuntu.com/316584/
[05:02] <lifeless> verterok: I can read both :P
[05:02] <verterok> lifeless: I know...but you know, I should use public pastebin :)
[05:03] <lifeless> verterok: can you branch lp:pyjunitxml
[05:03] <verterok> sure
[05:03] <lifeless> and run python -m subunit.run junitxml.test_suite | subunit-stats
[05:04] <verterok> lifeless: all good
[05:04] <lifeless> bahhhh
[05:04]  * lifeless hates datetime
[05:05] <verterok> lifeless: the utcnow() is the offending bit :)
[05:05] <lifeless> well
[05:05] <lifeless> subunit should be calling time()
[05:05] <lifeless> what subunit version did you end up with ?
[05:06] <lifeless> actually, do this:
[05:06] <verterok> lifeless: 0.0.2-1
[05:06] <lifeless> bzr selftest --subunit xmloutput | grep -v 'time:' | subunit2junitxml -o tests.xml
[05:07] <verterok> ok
[05:07] <lifeless> if that fixes it, please file a bug on pyjunitxml
[05:08] <verterok> lifeless: yeap, it worked now
[05:08] <lifeless> so subunit in bzr generates Zulu timestamps
[05:08] <lifeless> utc == zulu, but python is DAFT
[05:11] <lifeless> verterok: \o/ looks nice
[05:12] <verterok> :)
[05:12] <verterok> lifeless: thanks!
[05:12] <lifeless> anytime ;)
[05:12] <lifeless> show the u1 folk:P
[05:12] <verterok> lifeless: already did it to lucio ;)
[05:13] <_Andrew> I want to know if it's possible to force people to update for the the repo they cloned from. The reason I ask this is because we want "trunk" and then "live" branches but we want people contributing to trunk in a centralized fashion
[05:13] <lifeless> verterok: heh, I didn't see it on the channel ;P
[05:13] <verterok> lifeless: a while back :)
[05:13] <lifeless> _Andrew: update for ?
[05:14] <_Andrew> ah sorry
[05:14] <verterok> lifeless: Bug #481119
[05:14] <_Andrew> I meant when people push to trunk force them to update first?
[05:14] <lifeless> verterok: yes but it wasn't working before ;)
[05:14] <verterok> good point :)
[05:14] <lifeless> _Andrew: set the append_revisions_only config setting
[05:14] <_Andrew> ok
[05:19] <_Andrew> Sorry I'm confused about this option
[05:19] <_Andrew> When I init with it in "trunk" and 2 people clone trunk
[05:19] <_Andrew> person one pushes to trunk, and then person 2 does the same thing..
[05:20] <_Andrew> Does that mean person 2 will be forced to update first?
[05:21] <lifeless> yes
[05:22] <_Andrew> sweet
[05:22] <lifeless> mwhudson_: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/
[05:22] <_Andrew> That's exactly what I need
[05:23] <lifeless> mwhudson_: you can click on the test grapho too, to get details
[05:27] <verterok> lifeless: I'm adding pylint ;)
[05:28] <lifeless> is there a lugin, or just via shell commands?
[05:29] <verterok> lifeless: via shell, but there is the Violations plugin, that knows how to read pylint output
[05:31] <RenatoSilva> verterok: maybe the errors are because of the branch format of xmloutput you've upgraded to?
[05:32] <RenatoSilva> I'm afraid of installing bzr 2. Should I?
[05:32] <RenatoSilva> does bzr 2 work just fine with old branch formats?
[05:32] <verterok> RenatoSilva: yes, you should :) using 2a is a pleasure
[05:32] <verterok> RenatoSilva: yes
[05:33] <RenatoSilva> verterok: I've installed xmloutput 0.8.4 using the installer, checking if the errros are at least constant
[05:34] <RenatoSilva> verterok: what is better in the new format? just faster?
[05:35] <verterok> RenatoSilva: speed is one of bug advantages
[05:35] <verterok> *big
[05:36] <RenatoSilva> what other advantages? did you get any trouble after upgrading?
[05:36] <RenatoSilva> the errors here are still random, but not the same errors I had before
[05:37] <verterok> RenatoSilva: no, I'm using it in every new project..and plan to move bzr-eclipse/java-lib to it in the near future
[05:37] <RenatoSilva> verterok: I get an error when branching ~/bzr-xmloutput/encoding-fixes-388300 :( because of the branch format. It is a stacked branch :(
[05:38] <verterok> RenatoSilva: yes, you need to use the new format, or avoid stacking
[05:38] <RenatoSilva> maybe that error should not happen
[05:38] <RenatoSilva> I don't know how to avoid stacking
[05:38] <RenatoSilva> or migrate a stacked branch
[05:39] <verterok> RenatoSilva: neither me, I never did it :/
[05:39] <RenatoSilva> verterok: afaik you just can't
[05:39] <RenatoSilva> avoid stacking
[05:40] <verterok> RenatoSilva: I can put a tarball somewhere if you need to get trunk
[05:40] <RenatoSilva> guys, if I create a stackied branch and the main one gets upgrated to the new format, is it possible to recover the stacked branch?
[05:41] <RenatoSilva> verterok: I want to get my old branch, it's totally broken now :(
[05:41] <RenatoSilva> verterok: not sure why but I can bzr branch trunk
[05:42] <RenatoSilva> just like bzr 1.18 can handle the new format
[05:42] <verterok> RenatoSilva: did you tried doing the upgrade in lp?
[05:42] <RenatoSilva> can it?
[05:42] <verterok> RenatoSilva: bzr upgrade --2a lp:~/bzr-xmloutput/encoding-fixes-388300
[05:42] <RenatoSilva> verterok: you mean a command pointing directly to the lp copy?
[05:43] <verterok> RenatoSilva: I upgraded xmloutput, bzr-hudson/jira like that
[05:43] <RenatoSilva> verterok: but 2a is availablr only in bzr 2 right? will install and try. What I don't understand is why we can branch the 2a branch with bzr 1.18, I tought it would not be possible
[05:44] <verterok> RenatoSilva: bzr upgrade --help
[05:44] <verterok> that should show you the supported formats
[05:45] <RenatoSilva> 2a is there, weird
[05:45] <RenatoSilva> if 1.18 already supports 2a, then what's the point of bzr 2?
[05:45] <RenatoSilva> I thought it was just the branch format
[05:49] <RenatoSilva> verterok: installed bzr 2, it comes with xmloutput 0.8.5, but where is the SimpleXMLRPCServer.py?
[05:49] <verterok> RenatoSilva: it should be included...right?
[05:50] <verterok> RenatoSilva: I don't know much about the win-installers
[05:50] <RenatoSilva> it's not there, let me run the tests
[05:51]  * verterok heads to bed
[05:51] <verterok> RenatoSilva: if SimpleXMLRPCServer.py is missing, please file a bug in bzr about the broken xmloutput in the installer
[05:52] <RenatoSilva> ok, see you, I'll try to fix things here
[05:52] <verterok> RenatoSilva: I need to sleep a few hours, seeya later!
[05:52] <RAOF> RenatoSilva: bzr 2 changed the default format to 2a; 2a was supported for a while before bzr 2.0
[05:52] <RenatoSilva> see you :) thanks
[05:52] <RenatoSilva> RAOF: ok
[05:52] <verterok> later all!
[05:52] <verterok> lifeless: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/violations/
[05:53] <lifeless> james_w: btw, upgrade bzr-build* to 2a :)
[05:57] <_Andrew> um
[05:58] <_Andrew> When I use  --append-revisions-only  to init a branch and then clone it to branch1 and branch2. If I push a change up to trunk in branch1 and then do to same in branch2 it complains that the branches have diverged rather then force me to update
[06:00] <_Andrew> Is there anyway to prevent the branches from diverging due to users forgetting to update beforehand ?
[06:00] <RenatoSilva> Anyone has any idea of what could be causing these errors? http://pastie.org/694933.txt
[06:01] <RenatoSilva> unknown command "c:\Arquivos de programas\Bazaar\bzr.exe"  ???
[06:01] <RenatoSilva> Access denied ???
[06:02] <lifeless> _Andrew: no, people can do strange things ;)
[06:03] <lifeless> verterok: the pylint output is harsh
[06:04] <lifeless> pyflakes with the  lazy imprt patch would be better
[06:06] <_Andrew> There's no way to do that you mean?
[06:06] <_Andrew> because it's creating problems in the office
[06:08] <mwhudson> pylint is really great at producing masses of output
[06:10] <bob2> yay for pyflakes
[06:11] <RenatoSilva> anyone invoved with win installers? where is xmloutput/SimpleXMLRpcServer?
[06:15] <_Andrew> ah...
[06:16] <_Andrew> so I figured I am doing this wrong
[06:16] <_Andrew> My developers need to do bzr checkout... not bzr branch or clone
[06:16] <bob2> maybe
[06:17] <bob2> that has potential pitfalls of its own
[06:17] <_Andrew> That way they can't screw up and make their own branches that need merging
[06:17] <_Andrew> oh really?
[06:17] <bob2> merging isn't a bad thing
[06:17] <_Andrew> What are the problems?
[06:18] <bob2> imvho the result of doing 'bzr up' in a bound branch with local changes is a bit confusing
[06:21] <_Andrew> ah
[06:21] <_Andrew> The problem is that we need to do this way otherwise people keep screwing up the trunk branch
[06:22] <_Andrew> They try to push without updating then get confused with the merge process
[06:22] <_Andrew> Then there are tons of conflicts
[06:22] <bob2> well, if they ever do a "commit --local", they'll have the same problem
[06:23] <bob2> and those conflicts can occur with 'bzr up', too
[06:23] <_Andrew> you're right about that
[06:47]  * RenatoSilva is grrrrrrr with random test errors
[06:55] <RenatoSilva> anyone with bzr + mvn+ up-to-date winXP?
[06:55] <RenatoSilva> I would like some help with testing a LP branch
[07:52] <poolie1> RenatoSilva: what particular problem?
[07:54] <RenatoSilva> poolie1: do you have the logs there? I pasted some links. Basically  --random-- errors when testing bzr-java-lib
[07:54] <poolie1> what do you mean by testing the branch?
[07:54] <RenatoSilva> poolie1: errors about access denied, bzr.exe not found (showing the correct path)
[07:54] <poolie1> i didn't see the logs
[07:54] <RenatoSilva> poolie1: unit testing
[07:54] <poolie1> running tests located in that branch?
[07:54] <RenatoSilva> poolie1: you'd have to branch bzr-java-lib
[07:54] <poolie1> what's the url?
[07:55] <RenatoSilva> poolie1: lp:~verterok/bzr-java-lib/encoding-and-test-fixes
[07:56] <RenatoSilva> poolie1: no
[07:56] <RenatoSilva> poolie1: ~renatosilva/bzr-java-lib/encoding-fixes
[07:56] <RenatoSilva> they're almost the same
[07:59] <RenatoSilva> poolie1: I've got one specific test method running, and randomly failing/passing
[07:59] <RenatoSilva> poolie1: then I've got the .bzr.log for each case separately
[07:59] <poolie1> paste the log url again pls?
[08:00] <RenatoSilva> poolie1: the only relevant diff is that the success log has new lines, no error info in the failing log
[08:02] <RenatoSilva> poolie1: http://pastie.org/695026.txt
[08:03] <poolie1> sorry i really have no idea about this
[08:03] <poolie1> better ask gg or someone
[08:03] <RenatoSilva> poolie1: the bzr log there is the success log, with the new lines that are supressed when the test fails (see the '>>>>>>>>>')
[08:04] <RenatoSilva> poolie1: ok will show that to Guillermo
[08:05] <RenatoSilva> poolie1: but did you get the branch?
[08:05] <RenatoSilva> would appreciate if someone could test bzr-java-lib
[08:05] <RenatoSilva> in winxp
[08:06] <RenatoSilva> poolie1: the only thing I can think of is that the win updates have introduced the problem
[08:06] <RenatoSilva> poolie1: it was working yesterday! http://img195.imageshack.us/img195/2136/testsok.png
[08:08] <RenatoSilva> what I think is so weird is: how can I get access denied errors?
[08:09] <RenatoSilva> I wonder if it's rather related to the new 2a format
[09:09] <quicksilver> ooh scary : bzr: ERROR: exceptions.KeyError
[09:13] <poolie1> jam i don't understand the cover letter of https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-update-by-delta-bug/+merge/14628
[09:20] <bialix> quicksilver: LOL
[09:30] <poolie1> good night all
[09:30] <poolie1> lotzman, hey?
[09:30] <poolie1> i'd almost rename the role but it might be too obscure
[09:57] <bialix> poolie: ooh, I've lost your joke. Night.
[09:57]  * bialix interesting why poolie joking from me?
[10:03] <bialix> hi GaryvdM
[10:03] <GaryvdM> Hi
[10:04] <GaryvdM> I'm working on the qrevert changes - I found a few other issues.
[10:05] <GaryvdM> bialix: I just experienced the qadd/select all bug, but I have not looked into it yet.
[10:05] <bialix> GaryvdM: ok
[10:05] <bialix> GaryvdM: re qrevert changes: I think "Forget pending merges" will be good label, is not?
[10:06] <bialix> GaryvdM: I'm planning to finish off encoding patch from naoki
[10:06] <GaryvdM> I don't know. I've not thought about, I'm just looking at the behaviour side of the design
[10:07] <GaryvdM> bialix: cool
[10:07] <bialix> that's ok, we can polish labels later
[10:08] <bialix> I found interesting bug with our qsubprocess last night
[10:08] <bialix> it's related to get_boolean
[10:08] <bialix> I've already committed fix, but it seems we should be aware about the places where we trying to send strings with \n inside
[10:09] <GaryvdM> ok
[10:15] <bialix> GaryvdM: I want to move cmd_qsubprocess to subprocess.py
[10:15] <bialix> they are closely related and depend each from other
[11:25] <gioele> can I raise an exception "softer" than BzrCommandError? BzrCommandError says "bzr: ERROR: Commit cancelled", given that the user cancelled the commit, I don't see that as an ERROR, just a message
[11:27] <_Andrew> anyone know why my "trunk" doesn't update when I commit changes to it?
[11:27] <gioele> _Andrew: what do you mean with "update"?
[11:27] <_Andrew> eh, sorry. I mean doesn't show files I add
[11:28] <_Andrew> say I bzr init trunk
[11:28] <_Andrew> then bzr checkout
[11:28] <_Andrew> If I change files in my checkout and commit it doesn't update the files in the trunk dir?
[11:32] <fullermd> If the trunk is across a remote protocol, it won't.  Remote protocols don't touch the working tree.
[11:32] <gioele> _Andrew: if you commit in a bound checkout the changes will go back to the bound branch, but you will not see those changes in the other working trees, including the one you checked out from. Try to update the trunk
[11:35] <_Andrew> what if multiple people update the trunk?
[11:35] <_Andrew> Will that screw it up with different users doing bzr update on the same folder?
[11:35] <fullermd> Perhaps the better question is whether you really need a WT with that branch.
[11:37] <_Andrew> I think this plugin does what I want. https://code.launchpad.net/~bzr/bzr-push-and-update/trunk
[11:38] <fullermd> That just automates running the update.
[11:41] <_Andrew> Can't I just add a hook script then?
[11:41] <fullermd> That's what push-and-update is   :p
[11:43] <_Andrew> ah
[11:43] <_Andrew> That's what I thought
[11:43] <_Andrew> Then I should use that
[11:44] <fullermd> Generally, though, I'd tend toward just whacking the WT in the first place.  No reason to have it there.
[11:50] <_Andrew> WT?
[11:51] <knielsen> hi, I'm using bzr 2.0.2. One of the repos I'm using at Launchpad switched to format 2a, so I think I need a new shared repo with this format. I'm trying both bzr upgrade and (on another box) bzr init-repo --2a and new branching. But I'm having some problems
[11:52] <fullermd> _Andrew: Working Tree.
[11:52] <knielsen> I'm using the MySQL and MariaDB trees, and both new bzr branch lp:maria and convert of old shared repo is impossibly slow. Running for > 4 hours now and only 20000/59443 revisions transfered
[11:52] <_Andrew> ah
[11:53] <fullermd> knielsen: I'm pretty sure MySQL isn't in 2a yet, so if you're branching it into a 2a repository it's going to convert on the fly.  Which takes a long time.
[11:53] <knielsen> any suggestions for a better way to be able to access format 2a branches from the same shared repo as MySQL/MariaDB? Or do I just need to let it run for however many hours?
[11:53] <fullermd> knielsen: (and will probably make you incompatible with upstream, as I don't think they're using rich-root repos)
[11:53] <fullermd> Why do you want to share a repo across projects without any common history anyway?  Seems kinda pointless.
[11:54] <knielsen> fullermd: hm, bummer. So I'll need to use two different shared repos then it seems? One for projects with old format and one for new format?
[11:54] <fullermd> Well, I generally just use a different shared repo for each project.  There's no gain in it when there's no history to share.
[11:54] <maxb> Hi, I am struggling to decide whether I should recommend Bazaar or Mercurial to my workplace - can anyone point me to anything they think I should read?
[11:55] <knielsen> problem is that then you have to work in completely different subtrees... but ok, I can probably manage thanks for suggestion
[11:55] <fullermd> Well, I do anyway.  There's ~/work/projfoo and ~/work/projbar and so on...
[12:05] <_Andrew> Where do I put hooks on the server side?
[12:05] <_Andrew> in the .bzr dir in a working copy?
[12:06] <_Andrew> .bzr/plugins ?
[12:10] <fullermd> No, plugins either get installed in the system-wide lib dir or per-user ~/.bazaar/plugins/
[12:11] <fullermd> Some may have to be enabled in branch.conf, some don't.
[12:11] <fullermd> But in the case of push-and-update, server side is irrelevant; it runs from the client side.
[12:13] <_Andrew> Everyone is has their own branch on one machine
[12:13] <_Andrew> on**
[12:13] <_Andrew> maybe I can just enable the plugin system wide?
[12:34] <GaryvdM> maxb: http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html
[12:37] <maxb> hmm, Bazaar Explorer looks nice.... not for me, but could be a great selling point for the less technical Windows users
[12:41] <bialix> maxb: what's most important for your workplace?
[12:42] <maxb> hmm, many things. I care most about having a vcs with good support for a code-reviewing feature-branch based workflow
[12:43] <bialix> that's very broad
[12:43] <bialix> hg" all branches in one repo
[12:43] <bialix> bzr: every branch in separate directory
[12:43] <bialix> for many people this is show stopper
[12:44] <bialix> code review: depends on the system you will use
[12:44] <bialix> it seems like Review Board supporting both hg and bzr
[12:45] <bialix> retvield? maybe supports bzr, I've commented on the patch for bzr support while ago, but hg should be there already 'cause it's google choice
[12:45] <maxb> hg can be used in a very bzr-like manner too - you just treat every hg repository like you would a bzr branch
[12:45] <bialix> Windows users? TortoiseHg rules out bzr
[12:45] <bialix> unless you see Bazaar Explorer as better tool
[12:46] <bialix> maxb: hg can be as bzr, but bzr cannot be as hg with branches
[12:46] <bialix> unless you *call* Bazaar Explorer as better tool
[12:46] <maxb> Indeed, one of my concerns about bzr is what to do with branches whose fate is never to be merged into trunk, but whose history must be kept
[12:47] <maxb> (e.g. mainenance / cherry pick / failed feature branches)
[12:47] <bialix> maxb: recently on SO was question about such branches, hg book seems to suggest keep such branches in separate repos
[12:47] <maxb> SO ?
[12:48] <bialix> stackoverflow
[12:48]  * maxb googles
[12:48] <bialix> maxb: http://stackoverflow.com/questions/1672487/mercurial-why-would-you-maintain-separate-branches-versions-of-software-in-separ
[12:51] <maxb> Indeed. At which point Mercurial's "advantage" of being able to stash such things in a single repository then evaporates
[12:51] <bialix> maxb: even if you don't need Bazaar Explorer there is still hidden power ready for you: QBzr
[12:52] <maxb> On the other hand, hgwebdir rather beats loggerhead in good listing of many branches
[12:52] <bialix> it seems so
[12:53] <bialix> every tool has it's power and lower
[12:55] <maxb> I'm surprised at the bzr benchmarks in GaryvdM's links, I thought hg was faster
[12:56] <bialix> maxb: although I'm addicted to bzr, I can't say honestly that bzr is much greater than hg. There is places where hg clearly better, and there is places where bzr is clearly better. It depends what is most important for you, that's what I think about bzr vs hg comparison
[12:56]  * maxb ponders attempting to bzr->hg the launchpad repository for a subjective speed test
[12:56] <bialix> maxb: actually there is no big and comprehensive benchmarks for bzr 2a format
[12:56] <bialix> yet
[12:57] <maxb> http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html claims to be benchmarking the firefox repository under bzr 2.0.0
[13:02] <bialix> I can't comment those numbers, maybe igc can
[13:14] <_Andrew> can anyone point me in the direction of a simple post commit hook script?
[13:17] <awilkins> stackoverflow guy is wrong  ; SVN uses branches to define tags, not the other way
[13:17] <awilkins> Branching is cheap in SVN so they overloaded it's use to create tags instead of doing it the way CVS does
[13:18] <awilkins> DVCS systems actually go back to the CVS way of labelling a specific revision albeit on a global basis and not per-file
[13:21] <awilkins> I would say that the folder-per-branch vs one-folder-with-all-branches thing is only a showstopper for those people who don't bother thinking about things...
[13:32] <bialix> awilkins: you're right, but many people don't bother even thinking
[13:32] <bialix> _Andrew: in which sense?
[13:32] <_Andrew> oh geeze nevermind
[13:43] <GaryvdM> Grr @ _Andrew
[15:28] <Tak> has nobody noticed that the guy-with-hat avatar in the bzr docs is extremely phallic?
[15:30] <bialix> Tak: hmm, what about bzr logo then?
[15:32] <fullermd> Well, if that's phallic, it's a phallus in need of some corrective surgery...
[15:35] <GaryvdM> bailix: http://bazaar-vcs.org/stuart
[15:36] <GaryvdM> oh - know - that must be something else
[15:36] <bialix> GaryvdM: :-)
[15:37] <bialix> tortoise in attack?
[15:38] <bialix> GaryvdM: it seems I'm missing your joke
[15:38] <GaryvdM> No - joke, I was confused
[15:38] <GaryvdM> tak: who are you talking about?
[15:40] <bialix> GaryvdM: perhaps http://doc.bazaar-vcs.org/bzr.2.0.2/en/user-guide/using_gatekeepers.html
[15:40] <bialix> gatekeeper in the brown hat
[15:41] <GaryvdM> Oh - ok
[15:41] <Tak> yes, that
[15:44] <bialix> GaryvdM: thanks
[15:44] <Tak> "We have .NET and Objective-C bindings in progress" <= anyone know where I can find more info?
[15:46] <bialix> Tak: Objective-C I believe it's what pilky doing
[15:47] <Tak> and the other? ;-)
[15:47] <bialix> bzr gui from mac
[15:47] <bialix> .NET?
[15:47] <bialix> I dunno
[15:47] <bialix> it should be something about integration of bzr into MS Visual Studio'
[15:47] <bialix> or maybe what Martin (rar?) doing
[15:48] <bialix> Martin's work on Iropython and jython
[15:49] <Pilky> someone called?
[15:49] <Pilky> Tak: where's that quote from?
[16:05] <GaryvdM_> bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs.
[16:18] <GaryvdM_> bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs.
[16:19] <bialix> GaryvdM_: feel free to ask more questions, I can work as translator proxy
[16:19] <bialix> Vologymyr (Casufi) is not very good in English
[16:20] <GaryvdM_> bialix: no more questions to the user - I'm sure that it is not to hard to reproduce, and to fix, I will need to reproduce it my self.
[16:20] <GaryvdM_> bialix: just need time...
[16:20] <bialix> as usual :-)
[16:28] <bialix> GaryvdM_: ping
[16:28] <bialix> any idea what's this: QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout
[16:28] <bialix> got while testing naoki's patch
[16:30] <Lo-lan-do> Hi all
[16:31] <Lo-lan-do> I'm having problems using basic auth over https, when the same branch accessed over http works fine with the same authentication.conf
[16:31] <Lo-lan-do> Any hints?
[16:32] <GaryvdM_> bialix: When you init a layout, you pass it a parent widget. This sets the widgets layout to the layout you just init__ed
[16:32] <GaryvdM_> bialix: you can't do that more than once.
[16:32] <bialix> GaryvdM_: I see
[16:32]  * GaryvdM_ => tv
[16:32] <bialix> GaryvdM_: QtGui.HBoxLayout() w/o parameters fix this
[16:34] <bialix> naoki: ping
[16:57] <phinze> question from our sysadmin: "can I just add two random files into a bzr branch on VPR09 which having any checkout"
[16:57] <phinze> "I just have one file I need to add from a random server"
[16:57] <phinze> sans VPR09, heh
[16:57] <phinze> $REMOTE_SERVER more like
[16:59] <GaryvdM_> phinze: I think you are asking if you can add a file to a branch, without that branch having a checkout/working directory?
[16:59] <GaryvdM_> No
[16:59] <phinze> GaryvdM_: -nod-
[16:59] <phinze> yeah i thought that was the case... figured it was worth a double-check though
[16:59] <phinze> thx
[17:12] <Tak> Pilky: it's from http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html#plugins-and-bzrlib
[17:12] <Tak> (sorry, called away)
[17:35] <GaryvdM_> bialix: I want to write a pyqt like interface for source-highlight-qt. (http://srchiliteqt.sourceforge.net/)
[17:40] <GaryvdM_> oh bialix not here :-(
[17:49] <vxnick> hi all - I'm trying to break a lock on Launchpad, but bzr is giving me this: bzr: ERROR: Unsupported protocol for url "lp-46125520:///~sitecmd-developers/sitecmd/trunk/.bzr/branch/lock"
[17:54] <vxnick> not to worry, fixed by removing the numbers and :/// from that
[17:54] <GaryvdM_> vxnick: Thats a known bug. Rather do this: bzr breaklock lp:~sitecmd-developers/sitecmd/trunk
[17:54] <vxnick> GaryvdM_: thanks, figured that out eventually :)
[21:30] <lifeless> jml: I'm popping over to the coffee shop for brekkie, if you want to join me Ihave some testtools refactoring to show & tell on.
[22:45] <mkanat> I just tried to do a merge with 1.18.1 and got: bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked
[22:45] <mkanat> This is a merge from a remote pack repo into a local pack repo.
[22:52] <lifeless> mkanat: fixed in 2.0.1 I think.
[22:52] <lifeless> spiv: ^
[23:01] <mkanat> lifeless: Yeah, upgrading fixed it, thanks.
[23:03] <fullermd> It sure does get peaceful 'round here when everybody's off sprinting   :p
[23:05] <mkanat> I was wondering. :-)
[23:10] <spiv> mkanat, lifeless: I certainly fixed a bug like that, not sure if it includes that case or not.
[23:11] <mkanat> spiv: It seems to have fixed that case.
[23:11] <spiv> Cool.
[23:11] <fullermd> spiv: He said upgrading fixed it!  Take the credit!
[23:11] <fullermd> "Oh, yeah, I totally fixed that.  In my sleep.  Drugged up on morphine."
[23:13] <mkanat> lol


[23:15] <rob321> hey folks....  I recently upgraded to Ubuntu 12.04 LTS and suddenly I can't get any printers here to work... I have both a cannon and HP (HPLIP installed) and the system recognizes the printers, says it has sent the print job, says it has been printed, and yet the printer doesn't even stir from sleep
[23:34] <rob321> no one awake apparently...


[17:26]  * thorwil cycled through nature and brought some of it back home in his socks
[20:45]  * vish wonders if cycling is why thorwil's IRC presence pattern has changed
[20:46] <thorwil> vish: i used to keep the computer running, now i usually turn if off when leaving the house for a bit longer
[20:46] <vish> ah!
[20:47] <vish> thorwil: trying to save the planet, eh? ;p
[20:47] <thorwil> heh


[14:41] <cjohnston> any devs around? Have an issue between LP and summit that we need some assistance figuring out please.
[19:27] <lifeless> cjohnston: shoot
[19:28] <nigelb> lifeless: ohai. We're having an issue wwith the https://blueprints.launchpad.net/sprints/uds-p/+temp-meeting-export thingy.
[19:28] <cjohnston> yay!
[19:28] <cjohnston> go nigelb!
[19:28] <cjohnston> its like nigelb has my nick on highlight
[19:29] <nigelb> The subscribers listed in https://blueprints.launchpad.net/linaro/+spec/linaro-summits-server-1 don't show up on the meeting export page :(
[19:38] <lifeless> should really switch to using API's :)
[19:39] <cjohnston> lifeless: feel free to join our session on wednesday ;-)
[19:40] <nigelb> lifeless: I don't think there's an appropriate API for this.
[19:40] <nigelb> If there is, I'm willing to make the switch.
[19:40] <lifeless> cjohnston: if its in your afternoon, I may; I'm not at UDS though
[19:40] <cjohnston> It's at noon EST IIRc
[19:40] <lifeless> nigelb: just export sprints on the API; there doesn't need to be a tailored one
[19:41] <nigelb> Hrm. How do I get subscribers to a BP on the API?
[19:41]  * nigelb looks at docs
[19:41] <lifeless> anyhow
[19:41] <lifeless> uhm, are all bp's faulty, or just that linaro one ?
[19:42] <cjohnston> I believe there are atleast a couple
[19:42] <lifeless> worth checking what they have in common then, if its not all
[19:42] <nigelb> linaro one is the one we have a complaint about.
[19:43] <lifeless> e.g. unicode names (loïc)
[19:43] <lifeless> or being in two different sprints (uds-p and lcq4.11)
[19:43] <lifeless> obviously there is a bug somewhere; I presume you've checked the meeting export page to determine that the data is missing there, vs a summit bug ?
[19:43] <nigelb> Yeah, we have :)
[19:44] <nigelb> summit uses the meeting export page.
[19:44] <nigelb> And the data isn't there.
[19:44] <lifeless> ok; and what another faulty blueprint ?
[19:44] <nigelb> cjohnston: Know of another faulty one?
[19:45] <cjohnston> ya
[19:45] <cjohnston> looking for it
[19:45] <cjohnston> https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-improving-ubuntu-upstream-relationship
[19:45] <nigelb> cjohnston: that one is fine breakage.
[19:46] <nigelb> Not accepted into uds-p
[19:46] <nigelb> and hence won't show up in meeting export.
[19:46] <cjohnston> its on the schedule nigelb
[19:46] <nigelb> wha.
[19:46] <lifeless> it shouldn't be :)
[19:46] <nigelb> lifeless: sprints are exposed over the API? I don't see anything in API doc.
[19:46] <cjohnston> tuesday at 11 in grand serra h
[19:47] <cjohnston> its approved for lcq4.11
[19:47] <lifeless> cjohnston: it may be manually locked in but the lp data is inconsistent
[19:47] <lifeless> nigelb: may need to be added...
[19:47] <cjohnston> so if its approved for lcq4.11 doesnt that make it valid?
[19:47] <nigelb> lifeless: Agreed. I'll work on that next cycle and get it done.
[19:48] <nigelb> cjohnston: meeting export is only run for uds-p, and not being approved there doesn't get it added into summit automatically.
[19:48] <nigelb> I think someone added at manually.
[19:48] <lifeless> easy fix - get a uds driver to ack it
[19:48] <nigelb> Jorge!
[19:48] <cjwatson> I can do it
[19:49] <nigelb> cjwatson: Please do :)
[19:49] <cjwatson> done
[19:49] <nigelb> Thanks!
[19:49] <cjohnston> there are more that are only approved for lcq
[19:49] <lifeless> that might be a distraction then, lets get that one acked and refresh summit, see if that fixes it.
[19:49] <cjohnston> how are they getting some of the participants but not all of them
[19:49] <cjwatson> though, um, it's pretty nasty that we have to basically make uds-p a superset of lcq4.11
[19:50] <lifeless> cjohnston: well, the next candidate is a unicode bug
[19:50] <lifeless> e.g. the first has loïc the second has Данило Шеган
[19:51] <lifeless> I'd hope we were well beyond such things, but ... you never know your luck in the big city
[19:51] <nigelb> I'm going to bet on a unicode bug.
[19:51] <nigelb> Because I've seen 2 BPs with danilos in it that broke updates :)
[19:51] <cjohnston> https://code.launchpad.net/~james-w/summit/usability/+merge/80108
[19:51] <lifeless> have you guys filed a bug yet ?
[19:51] <cjohnston> lifeless: nigelb ^
[19:51] <cjohnston> i wonder if thats what that one is for
[19:52] <nigelb> Nope.
[19:52] <cjohnston> the unicode part of it
[19:52] <nigelb> Django's __unicode__ has nothing to do with what lifeless is talking about.
[19:52] <cjohnston> k
[19:53] <lifeless> cjwatson: does man-db hit all man page inodes ?
[19:54] <cjwatson> probably yes, e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620947
[19:54] <cjwatson> (well, that's cat page directories)
[19:54] <cjwatson> it'll skip input directories that weren't modified since the last run
[19:55] <cjwatson> cjohnston: if the LP export is wrong then I doubt it's worth looking for relevant changes to summit ...
[19:56] <cjohnston> that was a new change cjwatson and i didnt really ever look at it, so i was just wondering if that could be it
[19:56] <lifeless> cjwatson: heh, so yah i was watching man db on my freshly booted desktop and going 'how can that be measurable time' :)
[19:56] <cjwatson> cjohnston: but logically it can't have affected the content of the LP export
[19:56]  * nigelb dons his LP community developer hat on mucks around in sprint code.
[19:56] <lifeless> nigelb: cjohnston: is there a bug for this yet ?
[19:57] <cjohnston> https://bugs.launchpad.net/summit/+bug/883407 is our bug
[19:57] <_mup_> Bug #883407: Summit fails to show all my subscribed talks <Summit:Incomplete> < https://launchpad.net/bugs/883407 >
[19:57] <cjwatson> lifeless: the thing that really kills man-db performance is forking subprocesses when it doesn't need to; I've been working (in my CFT) on adding better in-process support to libpipeline, sort of coroutine-like
[19:58] <cjwatson> lifeless: microbenchmarks suggest that that accounts for the overwhelming majority of the runtime
[19:58] <lifeless> cjwatson: interesting; it must create bazjillions of subprocesses - my desktop is a very recent performance cpu w/ tonnes of RAM
[19:58] <cjwatson> several per page
[19:59] <lifeless> cjwatson: that, or microbenchmarks are ignoring IO time (a common issue)
[19:59] <nigelb> FUUUU.
[19:59] <nigelb> I found the problem.
[19:59] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630799#20
[19:59] <nigelb>             if subscription.personID not in attendee_set:
[19:59] <nigelb>                 continue
[19:59] <nigelb> IF someone is not registered on lp for uds-p sprint, their name doesn't show up in temp-meeting-export.
[19:59] <lifeless> of course
[20:00] <cjwatson> lifeless: I doubt that's it, because the "fork roughly the right number of processes" microbenchmark I ran had runtime very similar to that of man-db itself
[20:00] <nigelb> That yes, the people missing don't seem to be registered for uds-p.
[20:00] <nigelb> s/That/And
[20:00] <lifeless> cjwatson: ah, thats good corroboration
[20:00] <cjwatson> er, wait, misremembering slightly
[20:00] <nigelb> Yay for mucking in launchpad source :)
[20:00] <cjwatson> depends how you run the microbenchmark, but at any rate details in that bug message
[20:00] <nigelb> *so* glad I started hacking on LP.
[20:01] <lifeless> cjwatson: thanks, yes I see
[20:01] <cjwatson> in /usr/share/man, 'find -type f | xargs cat | zcat >/dev/null' => 2.5s, 'find -type f | xargs -n1 zcat >/dev/null' => 98s, mandb => 100s
[20:01] <lifeless> 20K processes \o/
[20:02] <cjwatson> s/98/88/
[20:02] <lifeless> cjwatson: the libpipeline thing would also be a good point to introduce concurrency
[20:02] <cjwatson> now all I need is less work to do so that I can have time to finish this ;-)
[20:03] <cjwatson> maybe, but my gut feel based on the 'find -type f | xargs cat | zcat >/dev/null' test is that it doesn't need it
[20:03] <lifeless> cjwatson: won't help on cold cache situations much/at all, but would on hot
[20:03] <lifeless> cjwatson: depends how fast you want it to be :)
[20:04] <lifeless> cjwatson: on cold cache situations it may permit some extra disk concurrency if depth(disk tag queue) <= cpucount
[20:04] <lifeless> if thats false, you might overwhelm the scheduler
[20:04] <cjwatson> I think shaving off 80% is eminently possible simply by avoiding the process storm, and that would bring it down to an entirely acceptable runtime in my book; I would rather not introduce concurrency when I don't need to
[20:05] <lifeless> :) shaving off 80% would be awesome, and your plan sounds eminently sensible
[20:05] <lifeless> cjohnston: nigelb: so, long story short - folk that haven't registered are silently dropped.
[20:05] <nigelb> lifeless: Yep.
[20:05] <lifeless> cjohnston: nigelb: workaround is to get them to register if the are planning to attend remotely, I think there is a flag fo rthat
[20:06] <nigelb> lifeless: No, no. The problem is the 2 sprints
[20:06] <nigelb> The issue is because linaro has a sprint of its own and a lot of linaro folks are only registered on the linaro sprint.
[20:06] <nigelb> We need to get them to register on both.  That's the least painful way.
[20:07] <nigelb> Anything else involves a non-trival summit code change less than 24 hours before UDS :D
[20:07] <cjohnston> lifeless: http://summit.ubuntu.com/uds-p/2011-11-01/  why would riku-voipio show up in linaro server summit (grand sierra I at 9) but not Linaro Ubuntu LEB (grand sierra H at 11)
[20:08] <lifeless> cjohnston: summit has local overrides for stuff; check that hasn't been done first.
[20:08] <nigelb> Is that the one cjwatson just approved. They may be some manual thingies there.
[20:08] <nigelb> I don't think it was in +temp-meeting-export until about 10 minutes back.
[20:09] <cjohnston> nigelb: he was already in that one.. so cjwatson just approving it wasn't relevent
[20:09] <cjwatson> no, I approved https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-improving-ubuntu-upstream-relationship
[20:09] <nigelb> Yeah, that's the Linaro Ubuntu LEB
[20:09] <cjwatson> oh right
[20:09] <nigelb> cjohnston: It is. Someone manually added the BP and probably a few relevant people.
[20:09] <nigelb> Fairly sure ricardo is a track lead.
[20:10] <cjohnston> added releevant people where? in summit? because he wouldn't get imported on that one if he isnt an attendee for uds-p
[20:10] <nigelb> he's a summit attendee.
[20:10] <nigelb> But if the BP and its people were manually imported...
[20:10] <lifeless> this is why having summit manually override is nuts ;)
[20:11] <lifeless> either move the data store to summit
[20:11] <lifeless> or enhance LP to directly do what you want
[20:11] <lifeless> that will avoid all this skew
[20:11] <lifeless> which completely confuses folk :)
[20:11] <nigelb> I'll take option 2 :)
[20:11] <nigelb> well, the problem is, people don't trust summit
[20:11] <nigelb> and override stuff t work
[20:12] <nigelb> Instead of *asking*
[20:12] <lifeless> nigelb: no reason the overrides can't be stored in LP
[20:12] <nigelb> I thought this stuff was not going to be maintained in the future?
[20:12] <lifeless> huh?
[20:12] <lifeless> issuetracker says we're consolidating concepts, not eliminating functionality.
[20:13] <nigelb> ah.
[20:13] <nigelb> In wwhich case, I will bug fracis at the summit session and figureout something
[20:13] <nigelb> I'm definitely will to put the LP work in :)
[20:13] <nigelb> (Sigh, I wish I was there in person)
[20:13] <lifeless> it should be fairly straight forward: identify the places that summit is duplicating data from LP, and nuke with vengeance.
[20:14] <nigelb> heh
[20:14] <lifeless> the cost of changing LP has dropped a bit already
[20:14] <lifeless> I'm confident the next 3-4 months will see another drop
[20:14] <nigelb> \o/
[20:14] <nigelb> and 2 of us have commited patches to LP.
[20:14] <nigelb> So, we're good on that front mostly.
[20:14] <lifeless> yah
[20:15] <lifeless> the alternative is to move attendance totally out of LP
[20:15] <lifeless> or things like that
[20:15] <lifeless> now, I don't have a preconceived 'right' solution
[20:15] <nigelb> Hrm, I'm open to that as well.
[20:15] <lifeless> my criteria are:
[20:15] <nigelb> Just import relevant people from BPs. Not from sprint attendance only.
[20:15] <lifeless>  - no duplication once its done (mirroring is ok, but duplicate isn't)
[20:16] <lifeless>  - LP isn't left with stub functionality: what remains should make sense on its own [or with summit as a blessed official addon that anyone can run]
[20:17] <lifeless> My *suspicion* is that moving session times into LP, to permit LP storing pinned sessions, is the simplest change.
[20:17] <nigelb> ..
[20:17] <lifeless> Separately we need to address this two-sprint thing.
[20:17] <nigelb> You'll let us do that? :)
[20:17] <lifeless> nigelb: why wouldn't I ?
[20:17] <nigelb> \o/
[20:17] <lifeless> nigelb: LP was *born* to support Ubuntu
[20:17] <nigelb> I will completely jump with joy if we can get that done :)
[20:18] <lifeless> pics or it didn't happen
[20:18] <lifeless> :)
[20:18] <nigelb> heh
[20:19] <nigelb> To be honest, I thought those bits were not changeable from launchpad end.
[20:19] <lifeless> ok, well I'm going to put nose to the grindstone and put this amqp oops workaround in place
[20:19] <nigelb> This opens up a whole new avenue of possiblities.
[20:19] <lifeless> nigelb: Ok, so big picture and little picture.
[20:19] <lifeless> big picture: we don't want to add random new features to LP without them tying in sensible. Just because it needs doing doesn
[20:19] <lifeless> 't mean it needs doing the LP DB
[20:20] <lifeless>  -> Look at the results tracker, separate DB, will become part of LP UI soon though.
[20:20] <lifeless>  -> fixing an existing feature is not adding a random new feature.
[20:21] <nigelb> Right.
[20:21] <lifeless>  -> supporting Ubuntu is a primary role for LP [explicitly Ubuntu in addition to its broader role of supporting the free software community]
[20:21] <lifeless> little picture:
[20:21] <lifeless>  -> summit and lp sprints have overlapping models that leads to skew and confusion
[20:21] <lifeless>  -> this is a problem
[20:22] <lifeless>  -> lets fix :)
[20:22] <nigelb> It took me half a day to track this down. I've worked on both summit *and* LP.
[20:22] <nigelb> So, yes. Skew and confusion indeed.
[20:22] <lifeless> one approach is to let LP store the entire model
[20:22] <lifeless> another approach is to remove from LP the parts of the model that are maintained by summit
[20:23] <nigelb> Most of wwhat summit does is mirroring.
[20:23] <nigelb> But summit lets overriding of stuff. Like creating a meeting without a BP.
[20:23] <lifeless> yes, but ELOCALOVERRIDES
[20:23] <nigelb> Exactly.
[20:23] <lifeless> so I think if we say 'LP sprints are not able to represent what happens at UDS', thats fairly clearly a defect in LP
[20:24] <nigelb> Indeed.
[20:27] <lifeless> 'What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer. '
[20:27] <lifeless> *interesting*
[21:55] <lifeless> wgrant: when you are around, I'd like that incremental review.
[21:55] <lifeless> wgrant: other than this weird rosetta isolation thing, i think the branch is GTG
[21:55] <wgrant> lifeless: Sure, will look shortly.
[21:56]  * nigelb blinks.
[21:56] <nigelb> Oh. Its a Monday.
[21:56] <nigelb> Right.
[21:57] <lifeless> I'm thinking of making TestCase.setUp create an oops-message with the testid
[21:58] <lifeless> I think that might make debugging some of these things easier
[21:58] <wgrant> What do you mean?
[22:03] <lifeless> ErrorReportingUtility.oopsMessage('test %s' % (self.id(),))
[22:04] <wgrant> lifeless: Ah!
[22:04] <wgrant> Hmm, perhaps.
[22:05] <wgrant> lifeless: Could you please explananlyze https://pastebin.canonical.com/55125/ on qastaging?
[22:05] <wgrant> 1-2ms on DF, 400-600ms on qas.
[22:05] <wgrant> At least that's what ++profile++sql says.
[22:06] <lifeless> 4.5ms
[22:06] <lifeless> 6.1ms 'total runtime'
[22:06] <lifeless> ah
[22:06] <wgrant> Perhaps ++profile++sql is buggy.
[22:07] <lifeless> wgrant: when you say 1-2ms on DF
[22:07] <lifeless> wgrant: are you executing the query, or the explain analyze ?
[22:07] <wgrant> explain analyze
[22:07] <lifeless>  ?column?
[22:07] <lifeless> ----------
[22:07] <lifeless>         1
[22:07] <lifeless> (1 row)
[22:07] <lifeless> Time: 745.439 ms
[22:07] <lifeless> when I execute it
[22:07] <lifeless> try executing it
[22:07] <wgrant> Still lightning fast.
[22:07] <lifeless> explaining is lightning fast, executing is slow
[22:07] <wgrant> Well, 8ms, but still fast.
[22:07] <lifeless> on qas
[22:07] <wgrant> Odd.
[22:08] <lifeless>                                                      Index Cond: ((public.teamparticipation.team = public.distribution.owner) AND (public.teamparticipation.person = 21997))
[22:08] <wgrant> Any idea how that could be?
[22:08] <lifeless>  Total runtime: 0.754 ms
[22:08] <lifeless> (64 rows)
[22:08] <lifeless> unreported time is usually either startup or wire-transmission overheads
[22:08] <wgrant> But the returned value is [(1,)]...
[22:08] <lifeless> I didn't say it fitted ;)
[22:10] <lifeless> what does this intend to do ?
[22:11] <wgrant> It's the legacy bug visibility query.
[22:11] <lifeless> 0.9ms to profile on wild
[22:12] <wgrant> profile == explanalyze?
[22:12] <lifeless> 386ms to execute
[22:12] <lifeless> yes
[22:12] <wgrant> WTF
[22:12] <lifeless> that was local machine so no networking etc possible
[22:14] <wgrant> With \timing on, how long does the EXPLAIN ANALYZE take?
[22:14] <lifeless> 6.1ms
[22:14] <wgrant> Not the time it gives, but the time it takes?
[22:15] <lifeless> 6.1ms!
[22:15] <wgrant> Bah.
[22:15] <lifeless> Repeating the question presumes I misunderstood
[22:15] <lifeless> I have timing on always ;)
[22:15] <wgrant> So it's not some pathological query parsing or anything. it's just insane.
[22:15] <lifeless> please tell me you're not going to put this into every bug query ?
[22:17] <wgrant> What about https://pastebin.canonical.com/55126/?
[22:17] <wgrant> That's a query that's already there.
[22:17] <wgrant> Very similar.
[22:17] <lifeless> I'd factor out the TP stuff into a CTE
[22:17] <wgrant> Is it still slow?
[22:17] <wgrant> So would I, but this whole thing is being deleted shortly.
[22:17] <lifeless> 580ms
[22:17] <lifeless> 0.7ms to profile it
[22:18] <wgrant> explanalyze gives a quick plan, though?
[22:18] <wgrant> Right.
[22:18] <wgrant> WTF?
[22:18] <wgrant> This making our bug pages 600ms slower than they have any justification for being.
[22:18] <lifeless> that should be an explainanalyze
[22:18] <lifeless> bah
[22:18] <lifeless> a union all
[22:18] <lifeless> but it doesn't correct the issue
[22:18] <wgrant> The first query I gave you is now on qastaging. I landed it because it performed really well on DF :)
[22:18] <wgrant> Right, I didn't write those conditions.
[22:19] <wgrant> The second query is an existing one which is on prod.
[22:19] <wgrant> The first is the condition for the second one being reused to implement Bug.userCanView.
[22:20] <lifeless> dropping the bug columns doesn't help
[22:20] <wgrant> So, any leads on the slowness? I can't reproduce on DF.
[22:20] <wgrant> Hmm.
[22:20] <lifeless> fiddling
[22:20] <wgrant> Thanks.
[22:25] <lifeless> 43ms do ?
[22:25] <lifeless> https://pastebin.canonical.com/55127/
[22:25] <wgrant> That's still crap, but how?
[22:25] <lifeless> CTE
[22:26] <wgrant> Indeed, that is faster...
[22:26] <lifeless> 12ms hot
[22:26] <wgrant> Unsurprising.
[22:26] <wgrant> But how?
[22:26] <lifeless> CTE, you can ignore the inner limit 1, thats not needed
[22:26] <wgrant> Well, not surprising that it's faster.
[22:26] <wgrant> But I didn't bother optimising because it was sub-ms.
[22:26] <wgrant> Except that it's not.
[22:27] <wgrant> Because EXPLAIN ANALYSE is a lie.
[22:28] <wgrant> lifeless: https://pastebin.canonical.com/55128/
[22:28] <lifeless> so, there is probably an execution bug in pg
[22:28] <lifeless> and its probably fixed in 9.3
[22:28] <wgrant> 9.3 is out!?
[22:28] <wgrant> You mean 9.1?
[22:28] <lifeless> no
[22:29] <lifeless> That was called humour
[22:29] <wgrant> Hah
[22:29] <lifeless> 181ms cold
[22:29] <lifeless> and hot
[22:29] <wgrant> This is the real one that will be executed for !~launchpad on prod.
[22:29] <wgrant> Hmm.
[22:29] <wgrant> Not sure if worth rolling back...
[22:31] <lifeless> hah
[22:31] <lifeless> I fluffed my edits
[22:31] <lifeless> check the bugsub clause
[22:31] <wgrant> Heh
[22:31] <lifeless> still 12ms
[22:31] <wgrant> Does that fix it back to the old speed?
[22:32] <lifeless> returns 0 rows
[22:32] <wgrant> That's wrong.
[22:32] <wgrant> I have a subscription through a team.
[22:32] <lifeless> on qas ?
[22:32] <wgrant> ~ubuntuone, in particular.
[22:33] <wgrant> Yes.
[22:33] <lifeless> 13ms 1 row
[22:33] <lifeless> fixed
[22:33] <wgrant> Damn.
[22:33] <lifeless> https://pastebin.canonical.com/55129/
[22:34] <lifeless> 4ms for the new one CTEified
[22:34] <wgrant> "new one" == only two things being unified?
[22:34] <lifeless> yes
[22:34] <wgrant> Thanks.
[22:34] <lifeless> 4 with and without UNION ALL
[22:35] <lifeless> https://pastebin.canonical.com/55130/
[22:36] <wgrant> So, this is a bit of a worry :/
[22:36] <lifeless> whats the current live query ?
[22:36] <wgrant> Bug.userCanView on prod is currently an undefined number of queries, depending on caching.
[22:37] <wgrant> Might get a ++oops++ to find out.
[22:37] <lifeless> remember that we don't cache across requests
[22:37] <wgrant> Yes.
[22:38] <wgrant> But I mean it's not obvious from the method what will need to be done.
[22:38] <lifeless> sure
[22:38] <lifeless> ok, I'm going to go start doing limited test run bisects to find this rosetta issue
[22:38] <wgrant> Good plan.
[22:40] <lifeless> its reported test 12751. I think I'll power-of two working up, rather than shrinking
[22:56] <lifeless> wow
[22:56] <lifeless> pickledb is -not- what you'd think it is. Way to confuse.
[22:57] <lifeless> it may still be terrible, but its a different sort of terrible
[23:02] <wgrant> lifeless: How is https://pastebin.canonical.com/55131/ on prod? sub-ms on DF, 340ms in ++oops++.
[23:04] <lifeless> 253ms
[23:04] <lifeless> 160 repeated
[23:05] <lifeless> 250ms third time
[23:05] <wgrant> 1 row?
[23:05] <lifeless> so very variable
[23:05] <lifeless> yes
[23:05] <wgrant> WTF?
[23:06] <lifeless> I have drop lynne up the street
[23:06] <wgrant> Let's run LP on mawson :)
[23:06] <wgrant> k
[23:08] <wgrant> Well.
[23:08] <wgrant> Indeed, that bug renders in 0.81s on DF.
[23:08] <wgrant> 2.5s on prod.
[23:09] <wgrant> Ah, because I'm an admin on DF, so it skips the bits of the queries that make everything slow except not.
[23:10] <wgrant> (but the queries I was timing before were from qastaging)
[23:10] <wgrant> Hah.
[23:10] <wgrant> 4 extra queries, but still 0.88s.
[23:11] <wgrant> So, DF is three times faster than prod.
[23:11] <wgrant> prod is pretty fucked.
[23:19] <poolie> hi all
[23:20] <wgrant> Morning poolie.
[23:20] <poolie> so that was a bit of an anticlimax that the buildd upgrades did not fix all the memory issues
[23:20] <poolie> we can investigate more
[23:20] <poolie> locally
[23:21] <poolie> i hope a second attempt won't take so long
[23:22] <lifeless> wgrant: thats interesting
[23:22] <lifeless> wgrant: unpleasant. But interesting.
[23:22] <lifeless> wgrant: I suspect table/index bloat
[23:23] <wgrant> That would be the leading theory, I expect, but the high variance suggests that it may be something else.
[23:23] <lifeless> not really
[23:23] <lifeless> I have a unified theory ;)
[23:23] <lifeless> table bloat means more pages are consulted
[23:24] <lifeless> consulting a *page* involves a lock
[23:24] <wgrant> Ah.
[23:24] <wgrant> Yeah.
[23:24] <lifeless> pg lock scalability is known suboptimal (and under improvement)
[23:24] <wgrant> We really should upgrade to 9.1 at some point.
[23:24] <wgrant> I guess that can happen soon after slony1-2.
[23:24] <lifeless> increasing the page count by (say) 100 fold would increase lock overhead by 1000 fold
[23:24] <lifeless> bah 100 fold
[23:25] <lifeless> anyhow, that would provide lots of room on a busy server (e.g. prod) for happening to not contend on those page locks
[23:26] <lifeless> the CTE causes a more efficient scan of the persons rows after after that stops consulting that table at all
[23:26] <wgrant> Yes.
[23:26] <lifeless> thats my theory anyhow
[23:26] <wgrant> Quite reasonable.
[23:26] <wgrant> So, sounds like we should upgrade postgres and continue fixing LP to not be ORMish.
[23:26] <lifeless> its a 72MB table
[23:27] <wgrant> What is?
[23:27] <wgrant> TP?
[23:27] <lifeless> yes
[23:27] <lifeless> conceivable packable during FDT
[23:27] <wgrant> Surely that's all going to be hot.
[23:27] <lifeless> oh it will be
[23:27] <lifeless> no disk IO at all I expect
[23:29] <poolie> huwshimi: hi, maybe we can have a talk about markdown together some time
[23:33] <lifeless> bah, can't find the blog post
[23:33] <lifeless> wgrant: anyhow, fseek() takes out a kernel lock
[23:33] <lifeless> wgrant: and postgresql fseeks(-1) to get the size of files it 'reads'
[23:35] <poolie> a per-file lock, or a larger scope than that?
[23:35] <lifeless> poolie: I don't remember the analysis
[23:38] <wgrant> lifeless: Can you check bloat on tables?
[23:38] <lifeless> yes, if I poke around a bit
[23:38] <wgrant> 00113-00338@SQL-main-slave SELECT DISTINCT ON (Person.name, BugSubscription.person) Person.account, Person.creation_comment, Person.creation_rationale, Person.datecreated, Person.defaultmembershipperiod, Person.defaultrenewalperiod, Person.displayname, Person.hide_email_addresses, Person.homepage_content, Person.icon, Person.id, Person.logo, Person.mailing_list_auto_subscribe_policy, Person.merged, Person.mugshot, Person.name, ...
[23:39] <wgrant> ... Person.personal_standing, Person.personal_standing_reason, Person.registrant, Person.renewal_policy, Person.subscriptionpolicy, Person.teamdescription, Person.teamowner, Person.verbose_bugnotifications, Person.visibility, BugSubscription.bug, BugSubscription.bug_notification_level, BugSubscription.date_created, BugSubscription.id, BugSubscription.person, BugSubscription.subscribed_by FROM Bug, BugSubscription, Person, TeamParticipation ...
[23:39] <wgrant> ... WHERE (Bug.id = 597155 OR Bug.duplicateof = 597155) AND BugSubscription.bug = Bug.id AND TeamParticipation.person = 21997 AND (TeamParticipation.team = BugSubscription.person) AND (Person.id = TeamParticipation.team) ORDER BY Person.name
[23:39] <wgrant> Fail.
[23:39] <wgrant> Didn't meant to paste all that.
[23:39] <wgrant> But anyway, that's 225ms on prod, 4ms on DF (from ++oops++)
[23:39] <lifeless> oh cool
[23:39] <lifeless> index-only scans is in tip
[23:40] <wgrant> Nice.
[23:40] <StevenK> wgrant: When I hung around on #linux/ircnet years ago -- we had a term for that; "slammermaus": a mouse that randomly selects great gobs of text and pastes it into the channel.
[23:41] <wgrant> And then the big query I asked about second ("SELECT BugTask.blah ... WHERE (massive union)") is 420ms vs 5ms,
[23:42] <wgrant> Those two queries make up half the render of time of the bug when prod is hot.
[23:42] <lifeless> wgrant: http://pgsnaga.blogspot.com/2011/10/index-only-scans-and-heap-block-reads.html
[23:42] <wgrant> And there's still another 200ms I need to track down.
[23:43] <wgrant> Ahhh very nice.
[23:44] <wgrant> Although this is going to make vacuums even more critical for performance.
[23:44] <lifeless> open question is if autovaccuum manages
[23:44] <wgrant> Exactly.
[23:47] <wgrant> lifeless: I guess it's good that we can reproduce this on qastaging.
[23:48] <lifeless> tes
[23:49] <wgrant> Without those two bad queries, we could reasonably easily get such bugs below 0.5s.
[23:49] <wgrant> Which is still terrible, but not as bad as it is now.
[23:49] <wgrant> Anyhow.
[23:49] <wgrant> I might land that CTE.
[23:49] <wgrant> Which will fix one of the queries.
[23:49] <wgrant> And add another instance of it.
[23:58]  * lifeless headdesks
[23:58] <lifeless> running test_rosetta_branches_script before $1_oops causes the too-many-oops situation


[04:29] <kees> how do I update the kernel on a bootable USB stick?
[05:28] <jjohansen> kees: what kind of bootable stick?
[06:18] <kees> jjohansen: I was using one created with usb-creator-gtk.  figured out I could swap out the vmlinuz in the /casper directory.  that got me far enough (I didn't need a full userspace, just needed to see dmesg)
[17:04] <Sangeeth> I'm new to Linux Kernel and deveopment... Could someone help me out...
[19:49] <Sangeeth> I would like to start contributing to the kernel dev team... I'm a rookie... But, i have a lot of passion for it... I can program well in C++...
[19:58] <hyperair> wow, such passion, that he leaves only 3 minutes after declaring it.
[19:59] <jernst> ;-)
[20:01] <jernst> is it the right channel to discuss alsa issues with recent sound cards (hda_intel ALC887) ?
[20:03] <hyperair> you should probably poke crimsun_
[20:05] <jernst> thanks hyperair
[20:07] <jernst> crimsun_: I filled bug 595094 and have six of these machines waiting to be deployed with Ubuntu ; unfortunately the sound doesn't work as expected (very low volume). If you have time to look at it, let me know what I can do (I tried to play with hda_analyser but had no luck)
[20:07] <ubot2> Launchpad bug 595094 in linux (Ubuntu) (and 1 other project) "Inaudible sound on Asus EeeTop ET2203 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595094


[08:59] <neiljerram> brendand, roaksoax, FYI I just added a bit more investigation of my Xenial booting problem to https://bugs.launchpad.net/maas/+bug/1577838
[11:10] <youplabo1m> Hey :)
[11:11] <youplabo1m> In few hours, I ll use MaaS to deploy 16.04 servers. Is it possible to configure zfs pools with it ? It will be perfect
[11:11] <youplabo1m> for prepare LXD deploy :p
[11:11] <youplabo1m> to
[13:39] <kiko> youplabo1m, not yet with MAAS, unfortunately -- but you can definitely set up ZFS once Ubuntu is deployed
[13:39] <kiko> youplabo1m, we added XFS support in MAAS 2.0 (currently in beta)
[14:05] <youplabo1m> kiko: thx for this info :)
[14:06] <kiko> youplabo1m, what will you use MAAS for?
[14:07] <youplabo1m> kiko: deploy ubuntu 16.04 and replace KVM by LXD. And for LXD, I want use ZFS as storage
[14:08] <youplabo1m> I ll configure zfs with ansible. no problemo :p
[14:08] <kiko> awesome
[14:08] <kiko> youplabo1m, curious how well does ansible play with MAAS? can it drive the MAAS API?
[14:09] <youplabo1m> I never use it yet with MaaS. I am in my test periode phase
[14:09] <kiko> interesting
[14:09] <kiko> let me know what your experience is, a blog post would be killer
[14:13] <youplabo1m> oki doki
[15:32] <mup> Bug #1513485 changed: Commissioning doesn't update the IP of PXE interface UI, maybe due to lease parser failure <MAAS:Fix Released> <https://launchpad.net/bugs/1513485>
[15:32] <mup> Bug #1577863 changed: [1.9.2] Using Xenial Kernel by default to enlist/commission and can't seem to be able to change it <oil> <MAAS:New> <https://launchpad.net/bugs/1577863>
[16:51] <mup> Bug #1580260 opened: [2.0a4] Reserved IP ranges should be allowed to be created by standard users <MAAS:Triaged> <https://launchpad.net/bugs/1580260>
[18:03] <mup> Bug #1580279 opened: maas-cli 2.0 doesn't find 1.0 api <amd64> <apport-bug> <xenial> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1580279>
[18:03] <mup> Bug #1580280 opened: [2.0a4] Disks less than 4MB in size cause a traceback on the MAAS server <storage> <MAAS:Triaged> <https://launchpad.net/bugs/1580280>
[18:04] <mup> Bug #1580279 opened: maas-cli 2.0 doesn't find 1.0 api <amd64> <apport-bug> <xenial> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1580279>
[18:33] <mup> Bug #1580285 opened: [2.0b5] Machines successfully commission but don't get marked 'Ready' <MAAS:New> <https://launchpad.net/bugs/1580285>
[19:03] <mup> Bug #1580299 opened: Failed to monitor services and update database. <MAAS:New> <https://launchpad.net/bugs/1580299>
[19:33] <mup> Bug #1580299 changed: Failed to monitor services and update database. <MAAS:New> <https://launchpad.net/bugs/1580299>
[19:50] <bugrum> Is there a reason why MAAS 2.0 no longer supports Wake-on-LAN? This is a really useful feature
[19:51] <bugrum> The MAAS 2.0 Web UI no longer has it as an option
[19:51] <bugrum> on Ubuntu 16.04 LTS
[21:05] <kiko> roaksoax, see above wrt WoL
[21:05] <kiko> roaksoax, why was it removed, truly?
[21:45] <mup> Bug #1580350 opened: [2.0b5] AMT machines using wsman do not netboot <MAAS:Confirmed> <https://launchpad.net/bugs/1580350>