[01:05]  * spiv waits for the cold&flu pills to kick in fully
[01:05] <lifeless> ugh
[01:06] <spiv> I'm definitely doing much better than yesterday.  I don't seem to actually have a fever anymore, and I got a proper night's sleep.
[01:07] <spiv> Hooray for ubuflu :/
[01:16] <mgz> lifeless: re "Where is test_dir being set?", two instances of `self.test_dir = ` in bzrlib.tests both of which are old
[01:17] <mgz> so I presume the change is something to do with how test methods are put on instances in testtools
[01:17] <spiv> mgz: oh wow, that's a shorter nick!
[01:17] <mgz> blame vila!
[01:26] <igc> morning
[01:33] <lifeless> hmmm
[01:35] <mgz> I presume the code was wrong before, but happened to work because no one was checking if the attribute they'd put the directory name in was still a string or whatever
[01:39] <mgz> didn't look too closely once I'd worked out how easy the fix was
[01:48] <lifeless> mgz: yeah
[03:03]  * igc lunch
[03:39] <nilg> I'm having problems with launchpad since yesterday, anyone else?
[04:31] <Croepha> can bzr diff compressed files? like can it give intelegable changes between revisions of a docx file?
[04:34] <spiv> Croepha: not as a builtin feature
[04:36] <spiv> Croepha: I think it would be possible to write a plugin to do that, or perhaps you could try "bzr diff --using=..." if you already have a tool for producing readable diffs for that file type.
[04:40] <lifeless> nilg: some details please
[04:41] <lifeless> Croepha: you can write a plugin to the diff code that examines specific files in a different way
[04:41] <nilg> lifeless: sorry I works actually
[07:21] <vila> hi all
[07:50] <bialix> heya
[08:14] <igc> night all
[08:15] <GaryvdM> Hi and Night igc.
[08:15] <bialix> night igc
[08:15] <gour> morning
[08:15] <gour> night igc
[08:15] <igc> hi GaryvdM, gour (and night)
[08:16] <gour> #541626 makes bzr-fastimprt unusuable for me
[08:16] <gour> is it just fastimport's problem or affects bzr aswell?
[08:16] <bialix> you should say bug #541626
[08:16] <gour> bialix: thanks
[08:17] <bialix> our pet bot, good ubottu, take a cookie
[08:18]  * gour would like to to darcs <---> bzr and use LP
[08:18] <gour> s/to to/to do
[08:19] <bialix> tailor?
[08:19] <gour> i'm not sure it can do incremental import and believe fastimport should be better supported...igc takes care for it
[08:20] <bialix> perhaps not today
[08:21] <gour> vmiklos (who wrote darcs part) recommends it over tailor as well
[08:29] <GaryvdM> bialix: Nudge https://code.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519
[08:30] <bialix> at evening, sorry, have to work
[08:30] <GaryvdM> bialix: Ok
[08:30]  * GaryvdM looks at 2 qbzr mps
[09:44] <MvG> Hi there! When will 2.1.2 be released? https://launchpad.net/bzr/+milestone/2.1.2 expects it 2010-04-22, and bug #572098 is really annoying. Yes I could work from a snapshot, but I prefer releases for my production work.
[09:45] <MvG> Got the wrong bug, it's #559436 that's annyoing me personally, but seeing a list of 5 high priority fixes looks like a release might be a good thing.
[09:56] <Peng_> bug 559436?
[09:56] <Peng_> Oh.
[09:56] <MvG> Means whenever I switch a branch with local modifications, I get a backtrace... :-(
[09:57] <MvG> s/branch/tree/
[10:01] <GaryvdM> vila: Who is the rm for 2.1.* ?
[10:02] <vila> GaryvdM: hmm, I've lost track here, was it igc or poolie ?
[10:03] <GaryvdM> vila: jam did 2.1.0. I can't find the release announcement for 2.1.1
[10:04] <vila> GaryvdM: yeah, so poolie was RM for 2.1.1, where are you searching for the annoucement ? lp ?
[10:04] <GaryvdM> vila: yes
[10:05] <vila> GaryvdM: hmm, he presumably forgot this bit then
[10:05] <GaryvdM> MvG: Out of the people who could be the rm, none of them are online right now, so it may be a good idea to send a mail to the mailing list.
[10:05] <MvG> GaryvdM: OK, will do so.
[10:15] <vila> GaryvdM: do you remember which toolkit was used for diffamation ? qt ?
[10:15] <vila> GaryvdM: or was it osx specific ?
[10:17] <GaryvdM> vila: It was written in java. I'm not sure which toolkit
[10:17] <vila> wow, who said java was slow ? :-P
[10:21] <vila> for those that couldn't attend UDS,  the video is here: http://ubuntudevelopers.blip.tv/file/3617079/
[10:30] <bialix> does somebody really said that java is slow? he should look at python first
[10:33] <Peng_> Heh.
[10:33] <vila> bialix: some people explained me that they switched from java to python for web apps because python was faster :-P
[10:33] <bialix> ah
[10:33] <bialix> maybe
[10:33] <bialix> but diffamation is desktop thing
[10:38] <guijemont> doesn't java have a reputation of slowness just because a lot of people programming in java don't know what they're doing?
[10:38] <vila> yup, so the key is to focus on the relevant part that needs to be animated, things like shortest edit paths (mentioned in the above presentation) are certainly needed to reduce the data set to process
[10:38] <guijemont> (me? feeding the trolls?)
[10:39] <vila> the same apllies to python really :)
[10:39] <guijemont> certainly
[10:39] <guijemont> that's where the virtue of brainfuck is
[10:40] <guijemont> bad programmers don't go there
[10:40] <guijemont> good programmers don't either though
[10:43] <GaryvdM> vila: http://www.aviz.fr/diffamation/
[10:49] <guijemont> indeed diffamation looks cool
[10:49] <vila> GaryvdM: ecellent, thanks for the url
[11:22] <jml> did anyone take notes for the "Bazaar/Launchpad healthcheck" session at the recent UDS? I can't find it on gobby
[11:23] <vila> jml: ouch, ping poolie ? :-/
[11:24] <jml> vila: I'll send him an email.
[11:24] <vila> mgz: in case you're wondering, I've found the problem with babune
[11:24] <vila> jml: I should have known...
[11:25] <vila> mgz: the selftest -x option can't be used twice (AFAICS) so TestBreakin and its zombies was back...
[11:26] <vila> mgz: I've just finished upgrading babune to lucid and relaunch a full set of runs, gentoo has already succeeded
[11:26] <spiv> jml: bazaar-m-healthcheck?
[11:26] <jml> spiv, ahh, thanks. I was looking for it under the community track
[11:26] <spiv> jml: that would have been logical :P
[11:27] <vila> jml: pfff, I'm so disappointed :-P
[11:27]  * vila runs (not only to avoid jml's great vengeance :)
[11:29] <jml> :D
[11:30] <spiv> vila: Huh, I thought selftest -x could be used twice?
[11:30] <spiv> vila: btw, if you feel inclined, maybe set up a builder for bzr on python2.7?
[11:31] <spiv> (It'll fail to even start tests atm, though, I filed a bug)
[12:00] <bialix> yep, some pages gone from gobby
[12:04] <bialix> jml: that page still there
[12:04] <bialix> titled bazaar-m-healthcheck
[12:05] <jml> bialix: thanks.
[12:05] <bialix> I guess we should put those pages to wiki
[12:06] <jml> bialix, yeah. that'd be good.
[12:07] <jml> bialix, I'm collecting all of the Launchpad-related notes, putting them onto our wiki, then blogging a summary.
[12:07] <jml> I'm not going to do that for Bazaar though.
[12:07] <bialix> ok
[12:07] <bialix> I'll do that for bzr
[12:28] <guijemont> I've named some of you there, hope you don't mind: http://guij.emont.org/blog/2010/05/18/scratching-an-itch-make-bzr-gtk-collapse/
[12:28] <guijemont> GaryvdM, jelmer and vila
[13:00] <nessita> vila: ping
[14:04] <vila> nessita: pong
[14:05] <nessita> vila: hi there! I added a comment on https://bugs.launchpad.net/bzr/+bug/581751
[14:05] <nessita> vila: lifeless suggested me to ping you, is there any debug we can do together?
[14:06] <vila> wow, ubottu can't authenticate ? That's weird...
[14:06] <nessita> any extra info I can add? I can reproduce it consistently
[14:08] <vila> nessita: just sec, let me page in the context
[14:08] <nessita> vila: sure, thanks
[14:10] <vila> hmm, looks like the nightly hasn't been updated since 2010-03-24, so I'm pretty sure it doesn't have the fix
[14:11] <vila> nessita: what do you mean by 'split' the bzr command ?
[14:11] <nessita> vila: yes
[14:11] <vila> nessita: nice host name by the way :)
[14:11] <nessita> heh :-)
[14:15] <vila> nessita: sorry for the delay, I've just updated to lucid and my setup is not fully functional yet
[14:15] <vila> GaryvdM: did you merge annotate_find to trunk ? It seems that branch doesn't work anymore on lucid
[14:16] <nessita> vila: no problem. Just ping me using my nickname and I'll be happy to help debugging
[14:16] <GaryvdM> vila: I have not yet merge annotate_find to trunk, but I have merge trunk in to annotate_find, so annotate_find should work on trunk.
[14:16] <GaryvdM> *should work on lucid
[14:16] <vila> ok, first I'd like to check if the nightly includes the fix I mentioned
[14:17] <vila> GaryvdM: Oh, right, you told me that, let me check
[14:18] <vila> GaryvdM: thanks, that fixed it :)
[14:20] <vila> nessita: right, the fix is revno 5160 on trunk while the nightly seems to be 5106, right numbers, wrong order
[14:20] <nessita> vila: ok, so, is there any way of getting a newer bzr other that branching trunk?
[14:20] <vila> nessita: can you run bzr from sources ?
[14:21] <nessita> vila: I guess so :-)
[14:21]  * nessita branches
[14:21] <vila> nessita: none of the ppas seems to contain better than nightly, this fix should be in the next releases (2.0.6, 2.1.2, 2.2xxx)
[14:23] <vila> spiv: (surely too late but anyway) I thought -x could be used twice too, regression ? (-s can ! :)
[14:24] <vila> nessita: don't forget to run make after branching (hmm, you may need to install some dependencies too, pyrex for one...)
[14:25] <nessita> vila: is there any howto?
[14:25] <nessita> I mean, a list of deps so I install them at once
[14:26]  * vila looks at the package def
[14:26] <nessita> jeje
[14:26] <nessita> that's cheating!
[14:26] <vila> :)
[14:26] <vila> I know we don't have TestDepends but I'm pretty sure we have DevDepends (or whatever the name is)
[14:28]  * nessita is still branching
[14:28] <vila> argh, one more regression, can\t switch virtual desktops anymore
[14:28] <vila> nessita: hmm, first branch ever ?
[14:28] <nessita> yeap
[14:29]  * nessita sings like a virgin, branching for the very first time
[14:31] <vila> shift+ctrl+alt+left instead of ctrl+meta-left .... did the design team infected by emacs viruses ?
[14:31] <vila> nessita: :-)
[14:31] <vila> argh, keyboard layout bug :(
[14:48] <nessita> vila: how big is a bzr branch?
[14:48] <vila> history or working tree ?
[14:49] <nessita> history
[14:50] <nessita> vila: it doesn't matter, I was just curious
[14:50] <nessita> this thing is still branching :-)
[14:50] <vila> nessita: my .bzr shared repo is ~62
[14:50] <vila> ghaa 63M
[14:51] <vila> that should be an upper bound as it contains many revisions that were never (or are not yet :) merged to trunk
[14:51] <vila> nessita: lag/bandwidth ?
[14:52] <nessita> max download rate is 1M for me
[14:52] <nessita> and the branch is using ti all
[14:52] <nessita> it*
[14:53] <nessita> \  78155kB   107kB/s | Fetching revisions:Inserting stream and counting
[14:53] <vila> hmm, 78M already, something weird is going on here :-/
[14:54] <nessita> not relly?
[14:54] <nessita> nessita@dali:~$ du -sh src/bzr.trunk/
[14:54] <nessita> 35M	src/bzr.trunk/
[14:54] <nessita> finished!
[14:56] <vila> nessita: so you used twice the volume of the final branch: something weird happened, can file a bug with these numbers please ?
[14:56] <vila> nessita: then you can ping lifeless :-)
[14:56] <nessita> ok
[14:57] <nessita> vila: make completed successfully
[14:57] <vila> nessita: so, run 'make' in the bzr branch
[14:57] <nessita> done
[14:57] <vila> wow, you rock :)
[14:57] <nessita> heh
[14:57] <vila> no weird messages about extensions nor zlib ?
[14:57] <nessita> nopes, it failed because of the lack of pyrex, which I installed and re run make
[14:57] <vila> nessita: just do './bzr info -v' there
[14:58] <vila> ok, so you should have the other ones already installed (I vaguely remember zlib-dev was required at some point)
[14:58] <nessita> vila: https://pastebin.canonical.com/32382/
[15:00] <vila> nessita: cool
[15:00] <nessita> vila: this worried me though https://pastebin.canonical.com/32383/
[15:00] <nessita> vila: note bzr vs ./bzr
[15:00] <nessita> but versions match?
[15:00] <vila> nessita: try using this bzr for your previously failing ... let me look ta this pate
[15:01] <vila> nessita: yes, versions are bumped for release only, nightly are not your usual beast
[15:01] <nessita> ohhhh ok
[15:01] <nessita> vila: shall I redo the splits with the newer bzr?
[15:01] <vila> but the full output should mention the revno
[15:02] <vila> nessita: not if the fix apply to your case
[15:02] <nessita> perfect
[15:02] <vila> nessita: bah, no
[15:02] <vila> sorry for the convoluted answer
[15:02] <nessita> no problem
[15:02] <nessita> I can do the split again
[15:03] <nessita> shall I branch using newer bzr too?
[15:03] <vila> nessita: no, just try the failing command with the new bzr
[15:03] <nessita> ok
[15:03] <vila> either it's fixed or it's a whole new bug anyway
[15:04] <vila> mgz: babune back in blue, expect for the windows run !!
[15:04] <nessita> it didn't fail!
[15:04] <nessita> vila: nice :-)
[15:05] <vila> nessita: pfew, I'm so glad about that ! This fix was a real pain :)
[15:05] <nessita> vila: thank you very much for your help!
[15:05] <vila> nessita: I was afraid you were hitting the same kind of problem only different, luckily it looks to be the *same* :)
[15:06] <vila> nessita: my pleasure
[15:06] <nessita> seems like it
[15:06] <nessita> vila: have a few more minutes for a follow up question?
[15:06] <vila> nessita: sure
[15:07] <nessita> vila: so, the merged worked (yey!) but, when applied, it removes some files (because the source branch has those removes in it). Is there any way to avoid/undo certain changes?
[15:09] <vila> nessita: if the merge remove 'filea', doing 'bzr revert filea' should restore it, you can then commit and the following merges shouldn't delete it again
[15:09] <nessita> vila: yey, you're right
[15:10] <nessita> thanks again!
[15:13] <vila> nessita: I'll mark the bug as a duplicate then
[15:13] <nessita> vila: please do
[15:15] <nilg`> bzr repo on launchpad is nearly impossible to get from china, any knowledge about that issue?
[15:18] <vila> guijemont: marmitians anonymous, really, you know there are free certificate providers these days ? :-P
[15:23] <vila> guijemont: and, of course, no problem with your citations :)
[15:25] <guijemont> vila: yeah, should handle that one day
[15:26] <guijemont> but the big issue is it's a shared server
[15:26] <vila> ha, yeah, technical problems are so much easier to handle when humans are not involved :-D
[15:46] <GaryvdM> vila: I know you us synergy. Are you aware of this: http://code.google.com/p/synergy-plus/
[15:46] <GaryvdM> *use
[15:48] <GaryvdM> vila: The old synergy segfaults for me. synergy-plus is more stable for me, but the clipboard is broken.
[15:49] <vila> GaryvdM: good to see this nice software resurrected, I'll track it to see how it evolve.
[15:49] <vila> GaryvdM: it's mission critical for me so unless it works better I'll stick with the working one :)
[15:51] <GaryvdM> vila: I see.
[15:53] <vila> GaryvdM: also, I try to minimize installs from source, so unless it's packaged for lucid... I will wait (if someone proposes it as a ppa though.... I will gladly test it ;-)
[15:54] <vila> GaryvdM: Oh, and I have a pending bug against virtualbox about the bad interactions between vbox, synergy and the apple magic mouse...
[16:01] <kfogel> On a Debian GNU/Linux system, ever bzr command gets this warning:
[16:01] <kfogel> /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
[16:01] <kfogel>   RandomPool_DeprecationWarning)
[16:01] <kfogel> But python-paramiko package is up-to-date.  Googling does not reveal any obvious fixes, and the URL given in the warning is a 404.
[16:01] <kfogel> Any ideas?
[16:07] <IslandUsurper> Isn't Crypto a separate download from paramiko?
[16:08] <cbz> what happens when a pack file size gets to the system filesize limit?
[16:08] <IslandUsurper> kfogel, the source install docs list http://www.python.org/pypi/pycrypto/ as the place to get pyCrypto
[16:08] <kfogel> IslandUsurper: thanks
[16:09] <IslandUsurper> kfogel, I would guess there's a different package for it instead of python-paramiko
[16:47] <nessita> hey all, me again with weird issues. Anyone has a hint how to solve this conflicts? https://pastebin.canonical.com/32393/
[16:58] <maxb> You know that that's a pastebin most people can't see?
[16:59] <nessita> duh, sorry, pastebin was disabled a few hours ago :)
[16:59] <nessita> oops, still is
[17:01] <nessita> public paste: http://paste.ubuntu.com/435609/
[17:01] <nessita> maxb: thanks for pointing this out!
[17:08] <maxb> I guess this is a private branch?
[17:10] <nessita> maxb: yes, I split a subtree from a branch and I merged it against another branch in another project
[17:10] <nessita> (using bzr split and bzr merge)
[17:10] <maxb> that sounds... complicated :-)
[17:10] <nessita> yeah
[17:10] <nessita> I'm so frustrated
[17:11] <nessita> but I have to do this, and maintain history
[17:41] <bialix> GaryvdM: still here?
[17:43] <bialix> GaryvdM: maybe I simply should dogfood your bzr-explorer patch? I'm not really wise to easily review your changes
[17:44] <bialix> about duplication: maybe it's worth to require in explorer trunk compatibility with newer qbzr? and keep explorer 1.0.x as compatible with qbzr 0.18?
[17:44]  * bialix going to home, will read irclogs later
[17:44] <bialix> ~~~
[17:50] <mgz> vila: good to know the nix hang problems are not related, was coming to that conclusion here
[17:50] <mgz> I've got some interesting results on the thread leak regression I'll probably post to the mailinglist
[18:05] <pheller> can anyone tell me what provides XMLSerializer ?
[18:08] <pheller> nevermind.  I see it's part of bzrlib now
[18:14] <vila> mgz: (passing around) regression ? The leaks have been there for... a very long time, what are you comparing to ?
[18:14] <mtaylor> abentley: bug in lp-submit in pipelines:  I just got this error: bzr: ERROR: There is already a branch merge proposal: https://code.edge.launchpad.net/1.0/~mordred/drizzle/pandora-build/+merge/14733
[18:14] <mtaylor> abentley: too bad the 1.0 doesn't really belong in that url...
[18:15] <vila> mgz: the bug itself is very stealth and I have never been able to reproduce it on demand...
[18:18] <abentley> mtaylor, funny, I thought I'd fixed that one.
[18:18] <mgz> vila, that's just it, yes, the leaks have always been there, but they were never fatal for *me* before
[18:18] <mgz> and now I can reliably repo.
[18:19] <mtaylor> abentley: it's possible I'm running an old version
[18:19] <mgz> vila: I've got a couple of things I'd like you to check if you can
[18:19] <abentley> mtaylor, just testing now.  It's possible I only fixed lp-propose.
[18:20] <mgz> 1) make really-really sure you're chop-test-run-into-several-smaller-subprocesses workaround is still working, as that should make leaks harmless
[18:20] <mgz> 2) do a full babune test run on r4919 and r4920
[18:23] <abentley> mtaylor, yeah, that's it.  On 2.1, lp-submit will give you that error.  On 2.2, you get lp-propose through its lp-submit alias.
[18:24] <mtaylor> abentley: ok. cool
[18:24] <mtaylor> abentley: I'll just deal with it then
[18:24] <mtaylor> it's certainly not borking me :)
[18:27] <abentley> mtaylor, I'll fix it, just not right now.
[18:31] <GaryvdM> bialix: If you read this in the log, I've replied to your questions in the mp. Thanks
[18:34] <vila> mgz: 1) is demonstrated by babune being almost blue (including some hacks for some slaves to increase BZR_CONCURRENCY *above* the number of available processors)
[18:35] <fullermd> For god's sake, let it BREATHE!
[18:35] <vila> mgz: what do you call a full run ? All slaves ?
[18:35] <vila> fullermd: funnily enough it's the freebsd8 that needs the hack has running it under vbox with more than two cores lead to far too much crashes :-/
[18:36] <vila> s/freebsd8/freebsd8 slave/ and to avoid any misunderstandings, I blame vbox not freebsd (remember the time skew problems I was encountering ? Still there, even worse maybe)
[18:37] <vila> and babune's fans have been changed for more silent, yet still efficient, ones, so it can breathe and I don't hear it complain anyway
[18:37] <fullermd> Obviously, the answer is to make freebsd8 the host rather than the emulated one   ;p
[18:38] <vila> fullermd: all tests are run in slaves, not on host :-P Host is for *my* tests :-)
[18:38] <vila> so I'll still need to have a freebsd slave ;)
[18:39] <fullermd> Daemons don't take well to chains.  You're liable to wake up one day to a trident at your throat.
[18:39] <GaryvdM> If you interrupt a bzr-git fetch, will it resume, or restart?
[18:40] <vila> one more reason to give it only two cores, I may be able to put my neck between the two teeth of the bident :)
[18:41] <vila> fullermd: and stop complaining, now you can blame the lower number of cores to explain why freebsd is the slowest nix on http://babune.ladeuil.net:24842 :-P
[18:41] <fullermd> Ah, yes.  Core limits for VM's should be called the Skynet Prevention Program.
[18:42] <vila> You said the name !!!!
[18:42] <fullermd> jaunty isn't a nix?  ;p
[18:43] <vila> hehe, I was waiting for that, check again in a couple of days or drill down for the trend, jaunty and karmic last run are atypical :-P
[18:44] <fullermd> Doesn't much matter anyway, since Windows does it in 2 minutes  ;p
[18:45] <vila> no no, 55mins, note the debug :) This one is running only a small subset :)
[18:46]  * fullermd snorts.
[18:46]  * vila dinner :)
[18:46] <fullermd> You've got a pathetic career as a benchmarker ahead of you if you're gonna get bogged down in irrelevant details like that   ;p
 mgz: what do you call a full run ? All slaves ? <- windows only, but all tests (minus bb.test_breakin)
[18:47] <mgz> I'll get my write-up done later, then things might start making more sense
[18:50] <mgz> essenstially, I think things have got worse on the threads-leaked-alive front.
[18:51] <mgz> and it's the fault of testtools, which is becoming something of a mantra for me
[18:53] <fullermd> Well, consistency is a virtue, right?
[19:20] <eydaimon> can I create a branch on remote host? say I have a bunch of files in a dir. I want to create a branch on the remote host, and check them in there. how would I do it?
[19:23] <beuno> eydaimon, create teh branch locally and push to it
[19:23] <beuno> it will create it
[19:25] <eydaimon> bzr init . ?
[19:25] <eydaimon> then bzr push pathname?
[19:26] <beuno> bzr init .
[19:26] <beuno> bzr add
[19:26] <beuno> bzr commit -m
[19:26] <beuno> bzr commit -m'Some message'
[19:26] <beuno> bzr push pathname
[19:27] <eydaimon> thanks :)
[19:27] <eydaimon> will the local branch work as a checkout or as a branch?
[19:27] <beuno> youz welcome
[19:27] <beuno> a branch
[19:27] <eydaimon> can I make it a checkout?
[19:28] <eydaimon> so Id on't have to keep pushing
[19:28] <beuno> yes, but you will need to checkout from $path
[19:28] <eydaimon> so first push, then checkout
[19:28] <eydaimon> bzr doesn't seem to like writing to a dir which already exists
[19:33] <beuno> yeah, it's fussy about that
[19:34] <GaryvdM> eydaimon: You can make your local branch a check out by running bzr bind :push
[19:36] <eydaimon> cool. thank you
[19:38] <vila> mgz: hmm, re-trying old revisions on windows with the bug fixes in testtools and subunit may be worth a try, but I won't bet a lot on testtools making things worse
[19:42] <vila> mgz: keep in mind that the root cause is that transport objects don't close their socket, for http that means keeping the connection alive. The servers have to keep their own connections open. At some point python's gc will finally collect the transports and close the client sockets triggering the server sockets close.
[19:43] <vila> mgz: But since that take too long, we finally reach the socket/file handle/thread limit
[19:45] <vila> mgz: now, to fix that, we need to close the socket in either the client or the server, that's where I encountered weird behaviors (uncaught exceptions in the server threads leading to hang threads for once)
[19:46] <vila> mgz: I have some branches where the servers where almost good and where there were almost no more leaked threads and... get interrupted
[19:46] <vila> mgz: It's high n my TODO list now so expect some results soon (for handwaved values of soon of course :)
[19:50] <kojiro> There's something I really don't understand about bzr-svn: If I do a merge/commit/push, it puts back changes that were already on the svn repo, but makes it look like I just made those changes
[19:50] <kojiro> is that really what I should be doing?
[20:05] <vila> fullermd: benchmarker... OMG what a scary thought...
[20:06]  * fullermd . o O ( Vilacraft... )
[20:07] <jam> vila: shouldn't you be ... not in IRC... by now :)
[20:07] <fullermd> Wow, you haven't even started benchmarking, and people are already trying to get rid of you!
[20:07] <GaryvdM> jam :-p
[20:08] <vila> jam: hey ! Indeed :)
[20:08] <jam> hi GaryvdM
[20:08] <vila> Proceed as if I wasn't there :)
[20:08] <jam> vila: I'm seeing an awful lot of blue on babune :). Though I wonder why selftest-windows isn't, seeing as you worked with Martin all week on it...
[20:08] <jam> Are there patches pending?
[20:08] <jam> (At least, I thought you said you got Win32 to pass...)
[20:09] <vila> jam: AFAIUI, most of them are now due to the infamous "Can't start new thread"
[20:10] <vila> I thought we add, but for some reasons, not all tests were running and we based our countdown on that.
[20:10]  * mgz reads log
[20:10] <vila> mgz had landed further patches I believe so the remaining ones should be fixed when the leaks will
[20:11] <vila> oh, he's there (mgz) so he can comment :)
[20:11] <mgz> yup, I'm aiming to splat everything that's not a leak
[20:11] <jam> vila: you know, if you gave that vm 2 cpu's, you're troubles would probably go away...
[20:11] <mgz> including a couple of things I see but babune doesn't
[20:11] <vila> jam: I can't make XP recognize several cores...
[20:11] <jam> *your*
[20:11] <mgz> on the leak-as-regression thing, something has gone seriously bad in the past 300 revisions
[20:12] <jam> vila: my wife runs xp-pro on 2-core
[20:12] <jam> (business machine)
[20:12] <mgz> leaks are harmless provided there's enough memory to spare for the stack space required by lingering threads
[20:12] <vila> ha, pro, that should explain it :)
[20:12] <jam> maybe
[20:12] <vila> mgz: could be, I can try increasing the memory allocated to the vm
[20:13] <jam> xp was based on 2k's kernel, IIRC. So maybe xp-home has an explicit deficit, but xp generally can definitely handle multi-core
[20:13] <mgz> between r4919 and r4937 (which is the first post-testtools rev that doesn't corrupt memory), the working set increased two or three fold
[20:13] <vila> now waitaminute, I'm pretty sure I'm using a pro version...
[20:13] <mgz> and the tests start hanging.
[20:14] <vila> mgz: working set ?
[20:14] <vila> corrupt memory ?
[20:14] <mgz> sorry, yes, this is complicated by lots of unrelated things
[20:15] <mgz> hence easier in a big email than on IRC
[20:15] <vila> ok
[20:19] <jam> mgz: working set => active memory consumption?
[20:20] <mgz> right, it's one of the measures I get from windows, also, pagefile usage, and I'm not sure how they overlap
[20:20] <mgz> (is the combined value the total memory usage?)
[20:25] <bialix> how to configure pqm plugin to send merge request for 2.1 branch?
[20:28] <GaryvdM> bialix: Change the submit branch in branch.conf.
[20:28] <bialix> e.g.?
[20:28] <GaryvdM> bialix: you probably will not have permissions though.
[20:28] <bialix> boom
[20:31] <GaryvdM> bialix:    submit_branch = bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/
[20:31] <GaryvdM> or just
[20:32] <GaryvdM> bzr pqm-submit bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/
[20:36] <mgz> vila: so, I ran the whole testsuite against a bunch of different revisions, summary of the results at <http://float.endofinternet.org/temp/bzr_selftest_result_summary.log>
[20:37]  * bialix rambling on out-of-date hacking.txt instruction re pqm
[20:38] <mgz> the first rev I can test without the crash from r4920 has massive memory usage, and hangs in a threaded test, as does each revision after that
[20:39] <mgz> more recent revisions still have massive memory usage, but run faster (there was a rev aiming to speed up the test suite, right?) and now get various thread-related failures but hang less reliably.
[20:40] <vila> mgz: yes, lifeless optimized a bunch of tests
[20:40] <mgz> I'm going to run some revs between 4945 and 5200 but it seems to me like the regression is between r4919 (which is fine for me) and r4937 (which is the first post-testtools that I can run)
[20:41] <mgz> hence the request for you to try r4919 on babune, if you can
[20:41] <mgz> I expect zero thread problems.
[20:43] <mgz> (the full results are on my server, but are giant xml files that might hurt unsuspecting webbrowsers)
[20:52] <vila> mgz: now running
[20:54] <vila> mgz: that was fast :-/
[20:54] <vila> hmm, the qbzr guys are gone for some more vodka I suspect...
[20:55] <mgz> bah, dodgy unicode handling in error messages is historical...
[20:56] <mgz> don't suppose you have python 2.4 on that box?
[20:56] <vila> mgz: 2.4 2.5 2.6
[20:56] <mgz> AttributeError: 'BzrAutoTimingTestResultDecorator' object has no attribute '_call_maybe' <- and I got this from subunit, and didn't know what the hell it was
[20:57] <vila> pretty old bug
[20:57] <mgz> in bzr? that was fixed?
[20:57] <vila> err wait, you got that *now*
[20:57] <mgz> I might have been trying to test an old revision at the time.
[20:57] <vila> no, I'd say in testtools
[20:58] <mgz> I can run the testsuite back to at least ~4000 cleanly
[20:58] <vila> they try to preserve backwards compatibility with that (IIRC), they may lack 2.4 testers though
[20:58] <mgz> but I have less in-tree infrastructure I'm relying on
[20:58] <mgz> r4919 is before testtools
[20:59] <vila> bite the bullet man, testtools is the future and the sky is the limit ! :-D
[21:00] <mgz> okay, so this probably isn't going to be easy to prove with babune
[21:00] <mgz> but, here's my 4919 run: http://float.endofinternet.org/bzrcst/clasfull/4919
[21:00] <vila> mgz: just try to exclude all http server related tests (add a skip in the server setup if you want) and just focus on the rest
[21:00] <mgz> and 4920: http://float.endofinternet.org/bzrcst/clasfull/4920 (early crash)
[21:01] <mgz> and 4937: http://float.endofinternet.org/bzrcst/clasfull/4937 (crash bug fixed, late hang)
[21:01] <vila> argh, poisoned url, kill firefox, kill firefox ! ;)
[21:01] <mgz> yeah, sorry ;)
[21:02] <mgz> I did load one of those even on your laptop, so it should survive
[21:02] <vila> this bug drove me crazy for a long while, there is really no way to predict when something will fail, hece the --parallel=fork trick
[21:02] <mgz> but that trick seems currently to be insufficent
[21:03] <mgz> and looking at my local test runs, things have got *much worse* with leaks in the past 300 revs
[21:03] <vila> mgz: sure, I knew since the beginning we were on thin ice
[21:03] <vila> it stoppped working for OSX long ago and get rid of the slaves for this reason
[21:03] <mgz> the number of leaks is about the same, but they're causing deadlocks, OOM testfailures, thread handle test failures, and huuuuge memory usage
[21:03] <mgz> so, something changed.
[21:04] <vila> I've seen it appearing on OSX and I could precisely point the revision,
[21:04] <vila> it was totally unrelated :)
[21:04] <mgz> ehhehe
[21:04] <mgz> there is a symptom vs. cause problem with this, too big a problem to isolate
[21:05] <vila> thread scheduling is not... damn, what's the word
[21:05] <mgz> the memory usage is causing the failures, or the leaking is causing the memory usage, or...?
[21:05] <mgz> deterministic?
[21:05] <vila> yeah, thanks, deterministic
[21:06] <mgz> okay, I think I'll do two more things before moving onto another problem for the moment
[21:06] <vila> not closing the sockets is causing the leaks, increasing memory usage (but not all I think)
[21:07] <mgz> #1 cherrypick my r4937 fix back on top of r4920 to see if I can squarely blame testtools for the change in mem usage
[21:07] <vila> more memory usage certainly leads to memory fragmentation, => increasing time => different scheduling => may be more leaks
[21:07] <mgz> #2 run some revs before and after robert's test-speedup (know what number that was?)
[21:07] <vila> at one point it's useless to try to understand what happens
[21:08] <vila> mgz: I think there was several commits for several improvements
[21:08] <vila> I'd say around 2.1 release
[21:14] <mgz> testtools did change some teardown/other details in pretty subtle ways
[21:16] <vila> mgz: don't rely on teardown, use addCleanup, you can't mix both
[21:16] <lifeless> moin
[21:16] <mgz> sure, but were the thread-related tests ever audited for that kind of thing after r4920?
[21:16] <vila> mgz: yes, there was some changes there.... speaking of the devil !
[21:16] <lifeless> vila: you can mix them, they have a defined order
[21:17] <mgz> it's pure fluke that the bb.test_non_ascii problem went on to cause a reliable crash to annoy me into finding and fixing it
[21:17] <mgz> okay, set r4290+4937 running, time for a break.
[21:18] <vila> lifeless: I'm falling asleep right now, but I think I remember cases where you could easily shoot yourself in the foot by mixing them
[21:19] <lifeless> yes, we had a list discussion
[21:19] <lifeless> we want to transition entirely to cleanups
[21:19] <lifeless> go to sleep though :)
[21:19] <vila> right, that was the idea I was trying to convey: use addCleanup, not tearDown
[21:20] <vila> yeah, 22:22 is a good hour for that
[21:20] <mgz> vila: check the diff of r4937 ;)
[21:21] <mgz> the point is it happened 17 revs after the breakage, and there may be similar as-yet-uncaught issues related to threading
[21:25] <vila> mgz: :-D
[21:25]  * vila zzzz.... cmfdinjd bou8rh7m
[22:00] <jam> lifeless: /wave
[22:01] <lifeless> jam: hai
[22:02] <lifeless> jam: did you have a chance to look at dirstate2?
[22:02] <jam> lifeless: I grabbed a copy of it, but haven't poked at it yet
[22:02] <lifeless> ok
[22:03] <lifeless> jam: whats the time for you now ?
[22:03] <jam> 4pm, 1hr before EOD
[22:06] <lifeless> so, between mountain view and montreal. doh, my clock is running out of zones
[22:09] <fullermd> Heck, I just lookit my watch, it tells me what jam's time is   ;p
[22:38] <RumblePure> I'm in utter panic. I've checked out from my main branch to my laptop. I did bzr update on my laptop after having worked on my code, and that created a real mess. Original files got screwed up, and tons of files that end with .THIS and .OTHER have been created.
[22:38] <RumblePure> How can safely revert to latest commit on laptop?
[22:39] <RumblePure> That's all I care about now.
[22:39] <beuno> so
[22:39] <beuno> you had uncommited changes?
[22:41] <RumblePure> beuno: not on the laptop no. I had commited locally
[22:41] <beuno> I don't think I follow
[22:42] <RumblePure> 1. I checked out from my main branch to my laptop.
[22:42] <RumblePure> 2. I worked on my code on the laptop, doing local commits on the laptop's branch multiple times.
[22:42] <RumblePure> 3. Satisified with my work, I wanted to commit back to main branch on stationary.
[22:43] <lifeless> what bzr version?
[22:43] <RumblePure> 4. Bzr said I have to do bzr update before I can do that. After I did bzr update, everything got messed up.
[22:43] <lifeless> we made update much better recently, I thought.
[22:43] <RumblePure> lifeless: we've been over this man, last time this happened I followed your advice and updated to latest version.
[22:44] <RumblePure> 2.1.1
[22:44] <RumblePure> Oh no I think I'm gonna have to throw up.
[22:44] <RumblePure> My local commits are no longer even showing when I do bzr log on the laptop.
[22:45] <lifeless> RumblePure: calm down
[22:45] <lifeless> RumblePure: its all there, there is no data loss
[22:45] <lifeless> RumblePure: do you have bzrtools installed ?
[22:46] <RumblePure> lifeless: then why wont bzr log show my previous local commits?
[22:46] <RumblePure> lifeless: no i dont. what does it do?
[22:46] <lifeless> because they are sitting staged until you commit
[22:46] <lifeless> if you run bzr st
[22:46] <lifeless> and look at the pending merges section of the output
[22:46] <lifeless> your most recent commit before you ran update will be there.
[22:47] <RumblePure> lifeless: they aren't shown when i do bzr st. only the status.
[22:47] <RumblePure> but never mind that.
[22:48] <RumblePure> All I wanna do know is to get things to the way they were before i did bzr update on laptop.
[22:48] <lifeless> RumblePure: 'bzr st' ? not 'bzr st .' or anything else ?
[22:48] <RumblePure> bzr st only
[22:48] <lifeless> ok
[22:48] <lifeless> anyhow
[22:48] <lifeless> if you could install the bzrtools plugin
[22:48] <lifeless> if you're on Debian or Ubuntu, apt-get install bzrtools
[22:49] <RumblePure> i already have it, or so it seems
[22:50] <lifeless> great
[22:50] <lifeless> run 'bzr heads --dead'
[22:50] <RumblePure> ... what does it do?
[22:50] <lifeless> queries your repository
[22:51] <RumblePure> Ok this is good, I think I see my last commit.
[22:51] <jam> lifeless: looking at your dirstate2 branch, I see that you don't handle a failure in "rename current NEW.check". Are you looking for more of a 'logically, this sequence seems correct' check, or a code check?
[22:52] <lifeless> jam: well I know its a sketch, but all feedback is good
[22:52] <lifeless> jam: I think the thing to answer at the moment is 'is this the right approach/what needs to be done to plug conceptual holes in it'
[22:53] <lifeless> RumblePure: now, you'll have something like:
[22:53] <lifeless> HEAD: revision-id<EMAIL_ADDRESS>[22:53] <RumblePure> lifeless: I should say that I just realized that I did have uncommited data on the laptop. So this was data that had not even been locally commited. This was the state before I tried bzr update.
[22:54] <lifeless> RumblePure: ok, so you *did* have uncommitted changes.
[22:54] <lifeless> that makes it trickier.
[22:54] <RumblePure> lifeless: but you can scratch it.
[22:54] <RumblePure> lifeless: not that important right now.
[22:54] <lifeless> RumblePure: you sure ?
[22:54] <RumblePure> lifeless: I'm more forced to than sure, but yeah.
[22:54] <lifeless> ok.
[22:54] <RumblePure> HEAD: revision-id: purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2 (dead)
[22:55] <lifeless> copy that string from the email bit on. E.g. for me it would be<EMAIL_ADDRESS>[22:55] <lifeless> without the (dead) bit
[22:55] <jam> lifeless: so I have some "this bit is hard to understand" stuff. and I still need to go through it step-by-step logically to make sure things fail correctly
[22:55] <lifeless> now first we reset your working tree:
[22:55] <RumblePure> purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2
[22:55] <jam> first bit is that it seems ok
[22:55] <lifeless> bzr revert
[22:55] <lifeless> secondly, we restore your local state
[22:56] <[1]reggie> hey bzr experts -- we have a commit mailer that is failing to work with a SSL server on port 465
[22:56] <lifeless> 'bzr pull --local . -r revid:purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2'
[22:56] <[1]reggie> any chance I"m just missing some config option?
[22:57] <jam> [1]reggie: I don't think smtplib trivially supports SSL, if you can, use TLS on the standard ports
[22:57] <RumblePure> lifeless: ok it says on revision 89, this was better than when bzr log showed only up to 83.
[22:57] <[1]reggie> jam, alas this is not an option (other than just setting up a local smtp server)
[22:58] <lifeless> RumblePure: now that you've encountered this with bzr 2.1.1, we know that we haven't fixed the issue as well as we thought we had. Is your code open source?
[22:58] <RumblePure> lifeless: no, super really sorry man.
[22:58] <lifeless> no problem
[22:59] <lifeless> however, would you be willing to run some queries for us - that would return metadata only ?
[22:59] <RumblePure> lifeless: I remember your buddy at this channel asked the same question. Trust me I wanna help you to 105% to catch this bug, but can't give you the code. :-/
[22:59] <lifeless> thats ok, I understand completely.
[22:59] <jam> [1]reggie: it could probably be updated to do so, looking here: http://docs.python.org/library/smtplib.html
[22:59] <RumblePure> lifeless: affirmitive. but do it quickly
[22:59] <jam> you have to use a different class
[22:59] <jam> SMTP_SSL
[22:59] <lifeless> RumblePure: bzr heads --all
[22:59] <jam> but otherwise should be the same
[22:59] <jam> Not sure how you would indicate that in the config file
[23:00] <RumblePure> lifeless: One question first, is the local branch on my laptop healthy now?
[23:00] <lifeless> RumblePure: should be, yes.
[23:00] <[1]reggie> right. I saw that.  I'm using a binary insatll of windows.  I guess I could use a python install
[23:00] <RumblePure> lifeless: I still got some *.THIS and *.OTHER files laying around. Should I just get rid of them?
[23:00] <lifeless> RumblePure: yes
[23:01] <RumblePure> lifeless: will it bother your inqueries that you want me to run if i just clean up first and do a local commit?
[23:01] <jam> [1]reggie: how are you generating emails then? This is failing for 'bzr send'?
[23:01] <RumblePure> *inquiry
[23:01] <lifeless> RumblePure: it will yes
[23:01] <jam> you can always 'bzr send -o filename' and then send that with another mailer
[23:01] <lifeless> RumblePure: I want you to run
[23:01] <jam> If it is from 'bzr-email', that isn't bundled with the installer anyway
[23:01] <RumblePure> lifeless: ok, lemme at least make a hard copy of the folder.
[23:01] <lifeless> bzr find-merge-base . [the master branch you checked out]
[23:01] <lifeless> that will print a revid
[23:02] <jam> also, on Windows, I think the default is to have "bzr send" spawn whatever MAPI mailer is present
[23:02] <jam> which means we aren't the ones sending to SMTP anyway.
[23:02] <lifeless> I then want you to look in 'bzr log --show-ids' for that revid, and print the revno that it has there
[23:02] <lifeless> On 04/08/2010 03:34 PM, Francis J. Lacoste wrote:
[23:02] <lifeless> > Stuart Metcalf announced that they should be rolling out an OpenID-enabled
[23:02] <lifeless> > Mumble at the end of next week. That will save us from registering 38
[23:02] <jam> anyway, more details needed... :), I might be around later
[23:02] <lifeless> bah sorry, paste error
[23:02] <lifeless> ignore the email :)
[23:04] <mgz> are the email address for third party packagers written down anywhere? I know at least some of them subcribe to the bzr list
[23:04] <RumblePure> lifeless: I reach the master branch through bzr+ssh and a dynamic ip-number that has changed. Will go with new ip-number
[23:04] <lifeless> mgz: they were on the wiki at one point
[23:05] <mgz> I shall poke around.
[23:05] <RumblePure> lifeless: It says it requires argument OTHER
[23:06] <RumblePure> lifeless: oh wait
[23:06] <RumblePure> lifeless: never mind
[23:07] <mgz> hm, DistroDownloads wikipage currently does not seem to have contact points
[23:08] <mgz> or rather, it has general links and things but no email addresses. CCing people on a short email I can do, filing upstream bugs and so on is too much for a teeny change
[23:09] <lifeless> mgz: which change are we talking about ? the dep one? no need to bother there as I said ;)
[23:09] <lifeless> just a courtesy if you feel like it
[23:10] <RumblePure> lifeless: It has revno 83
[23:10] <mgz> well, if I could find email addresses, courtesy would be easy, just post a short message to list with CCs.
[23:10] <RumblePure> lifeless: the revision id that matches what bzr find-merge-base gave.
[23:11] <lifeless> RumblePure: can you look at bzr log <master branch> --show-ids, and get the revno that the base revisionid has there ?
[23:11] <lifeless> RumblePure: it may be 83 as well, just want to be sure
[23:12] <RumblePure> lifeless: affirmitive, it is 83 that has that revid
[23:12] <lifeless> RumblePure: finally, I need to know if you had new files involved in your branch
[23:13] <lifeless> bzr st -r 83..
[23:13] <lifeless> have a look in that, and tell me if there are new files
[23:15] <RumblePure> lifeless: yes i remember and just checked, there were new files involved
[23:15] <lifeless> were those files the ones that went really messy?
[23:15] <lifeless> (I don't know) is an ok answer.
[23:17] <RumblePure> lifeless: other files went messy too, but yeah those files that were new at the time went messy.
[23:17] <lifeless> ok
[23:17] <RumblePure> lifeless: with new, I mean they show up under "added:"
[23:17] <lifeless> I think this gives me enough to try to reproduce
[23:17] <lifeless> thank you
[23:17] <lifeless> now, to get your changes into your master
[23:18] <RumblePure> lifeless: no problem. Just grab me anytime at<EMAIL_ADDRESS>and I'll see what I can do more.
[23:18] <lifeless> as you've only added stuff - doing the following should work:
[23:18] <lifeless> bzr unbind
[23:18] <lifeless> bzr push <master url>
[23:18] <lifeless> bzr bind
[23:18] <RumblePure> lifeless: Can we try that some other time? I really need to get to bed. Just wanna cleanup (remove *.THIS and *.OTHER files) and commit locally. Will that be OK for now?
[23:19] <lifeless> sure
[23:19] <lifeless> thanks for your help
[23:27] <RumblePure> lifeless: Ok, now I've fixed the stuff I lost and commited *breathing out*. Thx for the help lifeless. You saved my day again. You got my email<EMAIL_ADDRESS>Just grab if you want help to track that bug.
[23:30] <lifeless> sure thing, thanks
[23:34] <bignose> when I ‘bzr merge ; bzr revert --forget-merges’ I understand that the working tree remains with the changes, but the merged revisions are gone.
[23:34] <bignose> but what about ‘bzr merge ; bzr revert’? do the merged revisions remain, waiting for a commit?
[23:35] <lifeless> no
[23:35] <lifeless> 'bzr revert' discards all changes
[23:35] <lifeless> 'bzr revert .' discards only path changes
[23:35] <lifeless> 'bzr revert -forget-merges' discards only pending merges
[23:35] <lifeless> its a bit magic; sorry.
[23:35] <bignose> ah. so why would I have seen advice elsewhere to do both ‘bzr revert ; bzr revert --forget-merges’ to be sure?
[23:35] <lifeless> no idea
[23:35] <bignose> is it a behaviour that's been different in the past?
[23:36] <lifeless> nope
[23:36] <lifeless> 'bzr revert' has, ever since creation, been a Big Hammer
[23:36] <bignose> what does “only path changes” mean?
[23:36] <lifeless> files, directories, symlinks that have changed
[23:36] <lifeless> 'things that are paths'
[23:36] <bignose> but not contents?
[23:36] <lifeless> yes their contents
[23:37] <bignose> ah. so what's excluded?
[23:37] <lifeless> pending merges
[23:37] <bignose> heh.
[23:37] <bignose> okay, maybe that's what I'm remembering. ‘bzr revert . ; bzr revert --forget-merges’
[23:37] <bignose> maybe from a person who kept them as distinct operations in their mind
[23:37] <lifeless> I would guess a git user
[23:37] <bignose> righto.
[23:38] <lifeless> as git requires . for basically everything
[23:38] <lifeless> but . is an explicit path for us, rather than nothing which is 'find the root and do the default'
[23:38] <bignose> so, it can be useful to ‘bzr merge ../foo-feature/ ; bzr revert . ; bzr revert ../bar-feature/ ; bzr commit’
[23:38] <bignose> because that allows a single commit of all the merges
[23:38] <bignose> right?
[23:39] <bignose> hmm, no.
[23:39] <bignose> is there a way to get a bunch of revisions from various places, apply them all, and only then commit?
[23:41] <lifeless> bzr merge foo; bzr merge bar --force; bzr merge gam --force; bzr commit
[23:42] <bignose> okay, just read the help on that. perfect, thanks.
[23:43] <bignose> so lifeless, you're no longer living in oz?
[23:45] <RumblePure> lifeless: hey lifeless. I told you I cleaned up, made some changes and then made two or three more local commits. Well guess what. After that I ran bzr update again and it all went smoothly.
[23:45] <RumblePure> lifeless: after the update i commited back to master, no problems!
[23:46] <RumblePure> lifeless: and .bzr/branch/branch.conf still had the new ip-number. Maybe this wasn't related to the changing ip?
[23:46] <RumblePure> lifeless: and I've checked the code. All my latest changes are there.
[23:46] <lifeless> RumblePure: I'm not sure
[23:46] <lifeless> I'll try and reproduce
[23:47] <lifeless> bignose: yah, moved back to NZ
[23:47] <RumblePure> lifeless: but remember when the problem showed up I had some locally uncommited changes when I tried to commit back to master? you think that caused it all?
[23:47] <lifeless> at this point, yes
[23:49] <RumblePure> lifeless: Well I'll try to pin it down some other day, try to find out what's really causing this.
[23:51] <mgz> okay, that's shiny.
[23:52] <mgz> not only did sourceforge let me use my launchpad openid to post a bug report (as I've long forgotten my login), but launchpad understood the concept of an upstream bug at sourceforge and it's easy to make pretty linky.
[23:52] <mgz> it's almost like the days of free software balkanisation are over
[23:52] <lifeless> almsot ;)
[23:55] <ciss_> if i try to revert to revision 1, bazaar tells me: "bzr: ERROR: Path(s) are not versioned" - i suppose this is due to some files been unrecoverably deleted. can i tell bzr to ignore missing files and do the revert anyway?
[23:57] <ciss_> ah, sorry, found my error


[02:14] <aa_> hi, I can't find complete docs on the XMLRPC, it seems that it can't be used to retrieve bug data, is that correct?
[02:53] <Odd_Bloke> !weekend
[02:53] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[02:53] <Odd_Bloke> aa_: ^
[02:53] <Odd_Bloke> I'm afraid I don't know.
[03:04] <aa_> Odd_Bloke: thanks, it's ok though I just wanted an example for a blog post
[03:04] <aa_> Odd_Bloke: http://unpythonic.blogspot.com/2007/11/desktop-widgets-with-pygtk-launchpad.html if you care
[07:37] <Hobbes`> Is it normal/acceptable for someone to be Drafter , Assignee and Mentor for a blueprint on launchpad ?
[08:15] <mdke> Hobbes`: I think it depends on the project rather than on Launchpad policy
[08:18] <Hobbes`> it doesn't sound logical that someone can be their own "mentor"
[08:22] <mdke> I agree
[08:24]  * Hobbsee wishes launchpad did redirects
[08:24] <Fujitsu> Hobbsee: Redirects to/from what?
[08:24] <Hobbsee> Fujitsu: lp.net/~ubuntu-qa, to whatever it is now
[08:24] <Fujitsu> Ah.
[08:52] <philiKON> does anybody know how i would change the "current development focus" from one series to another?
[08:53] <Fujitsu> philiKON: It's a filed near the bottom of the /yourproject/+edit
[08:53] <Fujitsu> *field
[08:53] <philiKON> i see
[08:53] <philiKON> man, the launchpad UI needs some streamlining
[08:53] <philiKON> it's very counter-intuitive
[08:54] <mdke> philiKON: filing bugs is the best way to help with that
[08:54] <philiKON> cool
[08:54] <philiKON> i will
[11:33] <jimcooncat> Read the help and still don't get it -- is there a step-by-step guide to starting and managing my own project?
[11:35] <jimcooncat> I just want to make a simple conversion tool -- generate a UUID and convert it's value to a more useful format.
[11:41] <Odd_Bloke> jimcooncat: Assuming this isn't an existing project, you create a project at https://launchpad.net/projects/+new
[11:42] <jimcooncat> Odd_Bloke: Once I do that, will it be obvious how to get started? I need revision control and a repository for my little app
[11:42] <Odd_Bloke> jimcooncat: Reasonably so.  You'll need to install bzr if you don't already have it.
[11:44] <jimcooncat> Odd_Bloke: Where I'm starting from scratch, would it make sense to start with hello world package and change that?
[11:45] <Odd_Bloke> jimcooncat: I don't quite follow what you mean.
[11:46] <jimcooncat> Odd_Bloke: I can probably make a bash script do what I want to. But I need to make a package out of it, and don't know how. Maybe I should start with a generic package?
[11:47] <Odd_Bloke> jimcooncat: What do you mean by 'package'?
[11:47] <jimcooncat> Odd_Bloke: deb file with dependencies. For example, I need to generate a UUID, so I need ext2 tools.
[11:48] <Odd_Bloke> jimcooncat: OK, a Debian/Ubuntu package?
[11:49] <jimcooncat> Odd_Bloke: Yes, sorry if I wasn't clear. I've read all the docs, and the process seems muddy -- I don't want to become a dd or MOTU.
[11:49] <Odd_Bloke> jimcooncat: OK, this isn't really the channel to ask this in.
[11:49] <Hobbsee> you're doing packaging, or you're making an app?
[11:49] <Odd_Bloke> Simply because people won't know. :p
[11:50] <jimcooncat> Hobbsee, I want to make a simple package from a bash script with dependencies, I want revision control on it, I want community feedback.
[11:51] <Hobbsee> right
[11:51] <jimcooncat> I'm just confused by the documentation. I really need a step-by-step on packaging, bzr, and launchpad.
[11:52] <Odd_Bloke> LP can do the latter two.  It can also build and host the first.  You still need to know how to package your thing independant of LP though.
[11:52] <Hobbsee> so, to create the project and use the revision control, you want the launchpad stuff.  if you want users to compile it, then they can just report bugs with launchapd, and you can ignroe the packaging
[11:52] <Hobbsee> if you want to make it into a nice deb for them, you need the packaging guide
[11:53] <jimcooncat> OK, so should I concentrate on packaging up a deb first, or get bzr set up first, or set up a Launchpad branch first?
[11:53] <Hobbsee> the latter
[11:53] <Hobbsee> you need the code done, before trying to package it
[11:57] <jimcooncat> OK, so for the first version I can just make a very simple batch script, that just calls uuidgen and spits out the value. I'll do my conversion portion later.
[11:58] <jimcooncat> I guess I should just get started and try to learn, but I was really hoping for more of a guide.
[12:01] <Hobbsee> wiki.ubuntu.com/Bzr is the bzr one
[12:01] <Hobbsee> i thought it was linked from bzr docs - or something similar
[12:04] <jimcooncat> Sorry Hobbsee, that is what I need. Captain Obvious strikes again!
[12:04] <Hobbsee> :)
[12:04] <Hobbsee> that' sthe ubuntu one, but the generic one shoudlnt be that different
[12:05] <jimcooncat> Thanks for your time, guys.
[14:15] <ubotu> New bug: #160191 in launchpad "Redirection to edge logs out" [Undecided,New] https://launchpad.net/bugs/160191
[17:21] <markybob> i'm trying to download language files from launchpad, but i havent been getting the emails that it claims i should be receiving with the download link.  it's a gmail account, i've checked the spam, and it's been over a day.  i've tried resubmitting it, but i still havent gotten anything.  is this known?  anyone else seeing it?
[19:42] <salty-horse> hi. has anyone else noticed email notification subject replacing spaces with tabs in the bug title?
[19:46] <pardus> Hi, anybody here who can help me getting translations enabled for my project? Translation file is pending for review for about a week or so.
[20:08] <mdke> pardus: maybe email the launchpad-users mailing list. There is a conference this week so it's possible you'll need to be patient
[20:10] <pardus> mdke: Ok, don't want to sound impatient but the administration seems kind of not responsive. Starting to wonder why tranlations need aproval when I can upload code without anyone checking it.
[20:25] <ubotu> New bug: #160280 in launchpad "How I cancel join invitation to a team" [Undecided,New] https://launchpad.net/bugs/160280
[20:37] <mdke> pardus: yeah, I think you have a valid point. Possibly there is a reason but it would make sense at least to ask :)
[21:41] <ubotu> New bug: #160300 in launchpad "PPA activate page has text with bad grammar" [Undecided,New] https://launchpad.net/bugs/160300
[22:05] <ubotu> New bug: #160308 in rosetta "Timeouts on large export requests" [Undecided,New] https://launchpad.net/bugs/160308
[22:38] <Ubulette> is codebrowse broken ? i get a proxy error after a looooong timeout
[23:08] <Fujitsu> Ubulette: It does seem to be broken - I've poked somebody about it.
[23:15] <Ubulette> Fujitsu, ok, thanks
[23:20] <ubotu> New bug: #160331 in soyuz "Builds screen says no packages building whilst some are building" [Undecided,New] https://launchpad.net/bugs/160331
[23:20] <LaserJock> Fujitsu: you know when translation people are usually around?
[23:21] <Fujitsu> LaserJock: Remember that everyone is probably at AllHands.
[23:21] <LaserJock> bah
[23:21] <LaserJock> that shouldn't excuse them from work ;-)


[00:04] <kwwii> Cimi: hrm?
[00:05] <kwwii> zniavre: that does not show me the problem
[00:05] <kwwii> anyway, time for sleep
[00:05] <kwwii> night all
[00:26] <coz_> is the ubuntu logo on lucid going to change?? please say yes :)
[00:27] <coz_> I mean for maverick?
[03:34] <dashua> vish, You have the source .svgs for the button troughs?
[12:58] <directhex> is there a copy of the slides from http://video.ubuntu.com/uds/maverick/UDS-M-Making-Beautiful-Fonts-high.ogv anywhere? a video saying "look at this awesome font" which doesn't show the screen is kinda pointless
[13:05] <thorwil> directhex: so far it doesn't look like the slides are available. we could of course pester iainfarrell, but i asked him twice already ;)
[13:05] <directhex> don't worry about it.
[13:10] <knome> i'm sure iainfarrell is also *very* busy ;)
[13:51] <iainfarrell> Hi directhex yes they are
[13:51] <iainfarrell> Dalton Maag put them on their website
[13:51] <iainfarrell> hang on
[13:52] <iainfarrell> http://www.daltonmaag.com/docs/FontDevelopment.pdf
[14:41] <directhex> iainfarrell, oh, handy!
[14:41] <iainfarrell> directhex: indeed
[14:41] <iainfarrell> glad you're finding it interesting
[14:41] <iainfarrell> take any questions you have to the blog so we can chat about it :)
[14:42] <directhex> iainfarrell, i don't have much of an eye for design, so it's always interesting to see how subtle the differences in the design process for things can get
[14:43] <iainfarrell> directhex: it's a very complex process that's for sure
[14:43] <iainfarrell> directhex: glad to see people are interested :)
[14:48] <directhex> iainfarrell, i read somewhere that it's possible to get ahold of vector images of words rendered with the current in-progress font, for use on web pages e.g. loco sites. is that the case?
[14:48] <iainfarrell> directhex: yes the guidelines and logo assets are on the design team blog in the toolkits section
[14:49] <iainfarrell> directhex: http://design.canonical.com/the-toolkit/ubuntu-brand-guidelines/
[14:52] <directhex> iainfarrell, yeah, one thing i wasn't clear on with those - there's no mention of aubergine in there, which confuses things somewhat given the "white and orange" example on page 7 has different colourization to the logo used in the boot screen in lucid
[14:54] <iainfarrell> directhex: there's more to come in terms of colour
[14:54] <iainfarrell> we have to explain in more detail where we see colours being used
[14:54] <iainfarrell> but Aubergine is generally to be used sparingly where Ubuntu is concerned
[14:54] <iainfarrell> so we use it in the boot to take the edge off the black for example
[14:55] <iainfarrell> but not in many other places
[14:55] <iainfarrell> Canonical leads much more with Aubergine but doesn't use Orange as much
[14:55] <iainfarrell> because that's Ubuntu's primary colour
[14:55] <directhex> ETA? it makes it difficult to design web content relevant to lucid when neither lucid's colourization nor font are formalized clearly
[14:56] <iainfarrell> The font will come with the next release in the first instance, we're planning a public beta but more on that soon - I don't have dates yet
[14:56] <iainfarrell> If I were you I'd look at the new websites for guidance
[14:56] <iainfarrell> and we'll publish guides as soon as we can
[14:56] <iainfarrell> we have a list
[14:56] <iainfarrell> we're working through it
[14:56] <iainfarrell> I'll see if we can find a way of sharing the tasks ahead
[14:57] <iainfarrell> so you guys know what you're getting and when
[15:01] <directhex> I'll keep using Xenu for now, then. it's good enough to fool the casual observer.
[15:04] <iainfarrell> directhex: is that a free font?
[15:05] <directhex> iainfarrell, it's $30 of font
[15:06] <iainfarrell> directhex: I'd wait if I were you
[15:06] <iainfarrell> look at the CSS on the website
[15:06] <iainfarrell> for the fonts we've chosen that go well with the Ubuntu font
[15:06] <iainfarrell> and maybe update later
[15:11] <directhex> iainfarrell, that's not a bad idea as far as content goes, but there are limited options for Ubuntu-looking title fonts. Other than the old font, of course.
[15:12] <iainfarrell> yeah, I would advise against using the old font
[15:12] <iainfarrell> but using other fonts isn't necessarily bad
[15:12] <iainfarrell> the ubuntu font is our word mark and logo
[15:13] <iainfarrell> so don't feel like you have to slavishly conform
[15:13] <iainfarrell> if your website is about Ubuntu use the logo
[15:13] <iainfarrell> but it's also your website
[15:13] <iainfarrell> your project
[15:17] <directhex> "look at the css" - you know there are 27 stylesheets on ubuntu.com, right? ;)
[15:18] <iainfarrell> directhex: ok, that might not have been the most straight forward one :)
[15:18] <directhex> aha, yay for web developer toolbar
[15:19] <directhex> hm. "ubuntu beta", vera, dejavu. think that's what i already had in mind
[15:20] <iainfarrell> directhex: great minds
[15:26] <coz_> hey guys
[15:26] <coz_> so who is doing what for maverick?
[15:27] <coz_> or is most of it left up to the "official" art team?
[15:50] <directhex> iainfarrell, i like making things look like other things, as far as the technology permits anyway, hence http://imgur.com/AHlSI
[15:51] <iainfarrell> directhex: right, is that an updated login screen?
[15:51] <directhex> iainfarrell, no, it's grub
[15:52] <iainfarrell> wow
[15:52] <iainfarrell> I didn't recognise it :)
[15:52] <directhex> i wish that anti-aliased font patch would make it into grub though ¬_¬
[15:57] <iainfarrell> directhex: all in good time I'm sure
[15:57] <iainfarrell> that's an interesting one though
[15:57] <iainfarrell> because it makes grub look like a login
[15:58] <iainfarrell> which might be confusing to users who think it's a login screen if the machine has been set up for them
[15:58] <coz_> is this red circle with cutout ubuntu symbol also going to be in marverick??
[15:59] <iainfarrell> that almost doesn't matter compared to the fact that I use it every day and casually looking at it thought it was the login screen so might confuse the non hardcore user even more
[15:59] <directhex> or it might do the reverse, by making grub feel like something they're already familiar with, rather than something scary and "DOS-like". i dunno, i don't conduct user studies. i just do things for fun.
[15:59] <iainfarrell> the Ubuntu logo in the orange circle _is_ the finalised logo now
[16:00] <iainfarrell> so it will be in Maverick in some form, yes
[16:00] <coz_> iainfarrell,  oh thats a shame... I think it looks like a bad design decision
[16:00] <directhex> that and i found it rather easier to shoehorn a grub boot list into GDM's style than trying to do something with the plymouth style.
[16:00] <iainfarrell> coz_: if you look in the guidelines the circle of friends can be used without it
[16:01] <iainfarrell> but in the Ubuntu word mark
[16:01] <iainfarrell> and in most cases
[16:01] <iainfarrell> it will be in the circle
[16:02] <coz_> iainfarrell,  understood... but still a poor design.... how much "influence" do the "community" art team have with "official" art team?
[16:04] <iainfarrell> coz_: what makes you say it's a poor design, can you give me a scenario where it doesn't work?
[16:04] <coz_> iainfarrell, its a circle... first off... and a white cut out of the logo... looks as if it was done as a last minute design in a hurry
[16:05] <coz_> iainfarrell,  it doesnt work well because it is first seen as a circle  not the ubuntu logo... depending on your gestault view I suppose
[16:07] <iainfarrell> Sounds more like you don't like it coz_ more than it's a bad design
[16:07] <iainfarrell> I don't look at it and see just a circle
[16:07] <iainfarrell> it's an evolution of the circle of friends
[16:07] <coz_> iainfarrell,  well  that;s  one explanation.. but no.. it is a bad design... far to simplistic but not minimalistic
[16:07] <iainfarrell> and I assure you it wasn't quick or last minute
[16:08] <coz_> iainfarrell, I believe it was not last minute
[16:09] <iainfarrell> coz_: I think we'll have to agree to disagree :)
[16:10] <coz_> iainfarrell,  but after 6 years of ubuntu... and all of the available ..more interesting designs.. just online... this one is tooo simplisitc   and yes I suppose there is nothing to do but agree to disagree :)
[16:10] <iainfarrell> We worked hard to make something that was simple but didn't leave the good things like the idea of the circle of friends behind
[16:11] <directhex> coz_, some art decisions are good, some are bad. i don't see the CoF refresh as bad
[16:11] <iainfarrell> and you're welcome to play with it and throw ideas around
[16:11] <coz_>  directhex   understood
[16:11] <iainfarrell> which is the great thing about this project of ours
[16:11] <iainfarrell> plus we couldn't throw out the COF when so many people have tattoos of it :D
[16:11] <coz_> iainfarrell,  yes but again ...how much influence does the "community art team" have on the "official art team" ?
[16:12] <directhex> coz_, when all's said & done, it's the old CoF in monochrome.
[16:12] <coz_> directhex,  yes exactly...
[16:13] <iainfarrell> coz_: I think if your contributions are in line with the work we're doing on maverick - see design blueprints, or are an interesting idea
[16:13] <coz_> here let me whip up a "minimalistic" one instead of just simple hold on
[16:13] <iainfarrell> then you can have a lot of influence
[16:13] <iainfarrell> we really welcome input
[16:13] <iainfarrell> but we're a young team, and we have a remit to get certain foundations set before we start to expand it out
[16:13] <coz_> iainfarrell,  cool :)
[16:14] <iainfarrell> but we're also a small team
[16:14] <directhex> the new CoF is easier to gently parody than the old one was, anyway. hence http://i.imgur.com/auhrX.png
[16:14] <coz_> let me finishe this one  in inkscape hold on
[16:15] <coz_> ok rushed and very minimalistic     http://dl.dropbox.com/u/132551/UBUNTU/logo-coz.svg
[16:16] <coz_> not that I prefer that one... but there are alternatives  to  two colours... or cut outs ... and certainly "white" logos :)
[16:16] <iainfarrell> there are
[16:16] <iainfarrell> and we explored them :)
[16:16] <iainfarrell> this mark has to work online, on the desktop, in print all over
[16:16] <iainfarrell> and we wanted something that wouldn't suffer when translated
[16:17] <iainfarrell> so the example you have here
[16:17] <iainfarrell> might work well on screen
[16:17] <coz_> iainfarrell,   understood...  did the original logo suffer on these?
[16:17] <iainfarrell> but not in black and white
[16:17] <iainfarrell> yeah, a bit actually. not easy to reproduce in black and white for example
[16:17] <coz_> iainfarrell,  because of the values
[16:17] <coz_> understood
[16:17] <directhex> better in pure mono than in varying qualities of greyscale
[16:18] <coz_>  and the font?  has that been "officialized"
[16:18] <iainfarrell> directhex: exactly which is something we did initially and community had come around to in some custom themes too
[16:18] <directhex> coz_, it's not final
[16:18] <iainfarrell> coz_: I'm not sure what "officialized" means :)
[16:19] <directhex> coz_, i.e. iainfarrell won't give me a .ttf
[16:19] <iainfarrell> the logo type is and I have a close to final font which we're going to be sharing soon
[16:19] <iainfarrell> but it's not all finished
[16:19] <directhex> coz_, the *design* of the font is final, but not the actual implementation
[16:19] <coz_> directhex,   ah I was about to ask for an example :)
[16:19] <iainfarrell> exactly
[16:19] <iainfarrell> so the guys working on the font are close to having a full latin type set
[16:19] <iainfarrell> once we have that we'll do some internal testing
[16:19] <iainfarrell> and then open a public beta
[16:19] <iainfarrell> but we've not worked out the details yet
[16:19] <coz_>  very cool .. look forward to the font
[16:19] <iainfarrell> but it's coming your way soon
[16:20] <iainfarrell> yeah
[16:20] <iainfarrell> it's lovely
[16:21] <coz_> iainfarrell,  all the more reason to make the logo "lovely: :)
[16:21] <iainfarrell> well it does make the logo lovely
[16:21] <iainfarrell> that's the one that's everywhere now
[16:21] <coz_> :)  ok we can disagree with no bad feelings :)
[16:22] <iainfarrell> coz_: course we can :) I think we made a great logo and have a foundation for some fabulous work
[16:22] <coz_> has anyone worked on "case" badges?  the origianl one  submitted a few years back is still nice in my opinion
[16:22] <iainfarrell> and we want people to contribute and have conversations like this
[16:23] <iainfarrell> coz_: case badge? forgive my ignorance :)
[16:23] <coz_> iainfarrell,  let me upload the origianl hold on
[16:23] <iainfarrell> k
[16:24] <coz_> have to find it   hold on
[16:25] <coz_> iainfarrell,    http://dl.dropbox.com/u/132551/UBUNTU/00.svg
[16:29] <iainfarrell> ahh ok
[16:30] <iainfarrell> so where was that used?
[16:30] <coz_> iainfarrell,  well it was supposed to be used  for companies making ubuntu systems  so that it would be tagged with that case stickerr
[16:33] <iainfarrell> coz_: I see
[16:34] <iainfarrell> There are new stickers in development but they're being done as part of our work with our marketing and OEM team
[16:34] <iainfarrell> so I'm not sure we'd share them because we're trying to validate that things work with Ubuntu
[16:34] <iainfarrell> as opposed to people just being able to add their own stickers
[16:34] <iainfarrell> otherwise it's like the wild west out there :)
[16:35] <coz_> iainfarrell,   understood... this one was made by a fellow several years ago I just edited it for him... but  is it possible to join the marketing team?
[16:36] <iainfarrell> I was talking about the in house team, I don't know how we handle marketing with the community actually
[16:36] <iainfarrell> I think there is a team
[16:37] <coz_> iainfarrell,  mm  too bad we cant get into the "house" team
[16:39] <iainfarrell> well they're Canonical employees but I imagine they have the same remit as us to engage with the community
[16:39] <iainfarrell> but I'm not sure who you'd talk to :s
[16:40] <coz_> iainfarrell,  understood... just wondering why they pick who they pick as employees... rather background in the field etc etc :)
[16:41] <iainfarrell> yeah, sorry as a project Manager in the design team I'm not the person to ask but have a look on the Ubuntu wiki
[16:41] <iainfarrell> Ihave to run I'm afraid
[16:41] <iainfarrell> good chatting though
[16:42] <iainfarrell> catch you later