[00:01]  * RenatoSilva is very confused
[00:02] <lifeless> the terminal should encode the unicode string to your code page
[00:08] <thumper> Yay pipelines (bzr-pipeline) they rock!
[00:09]  * LarstiQ wonders what they are
[00:09] <lifeless> poolie: call?
[00:10] <lifeless> LarstiQ: topgit for bzr; no versioning of the structure, its wysiwyg, and uses regular branch objects
[00:10] <thumper> LarstiQ: I'll be blogging about them soon
[00:10] <poolie> um
[00:10] <LarstiQ> lifeless: stgit:topgit :: looms:pipelines?
[00:10] <LarstiQ> thumper: cool
[00:10] <lifeless> LarstiQ: I haven't reviewed how they would work for e.g. ubuntu packages, but certainly should be nice and easier for local patch creation
[00:10] <thumper> LarstiQ: so look out in planet bzr :)
[00:11] <lifeless> LarstiQ: yes
[00:11] <thumper> LarstiQ: hopefully today, but if not, the weekend
[00:11]  * LarstiQ might have a look at them, now that the regular conference part of EuroPython is done
[00:11] <LarstiQ> (tomorrow/weekend)
[00:12] <poolie> lifeless: sure, give me a call
[00:21] <RenatoSilva> bug 394943
[00:44] <igc> morning all
[00:48] <LarstiQ> morning ian
[01:05] <mthaddon> I just tried upgrading bzr to 1.16 per https://edge.launchpad.net/~bzr/+archive/ppa and now I get "bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 15, 0)" to "(1, 16, 1)"." on a bzr branch operation
[01:05] <mthaddon> anyone have any ideas?
[01:08] <Peng_> mthaddon: Yes. Upgrade whichever plugin is whining about it.
[01:09] <mthaddon> that's the only output - I don't know what plugin it's whining about
[01:11] <Peng_> mthaddon: Yeah, I know. There *might* be a traceback in ~/.bzr.log
[01:14] <a_c_m> can you change your parent branch -- switch doesnt seem to do it ?
[01:17] <mthaddon> http://pastebin.ubuntu.com/208656/ is the traceback (I think)
[01:18] <lifeless> mthaddon: bzr-gtk likely
[01:19] <mthaddon> lifeless: I don't have that installed
[01:20] <james_w> mthaddon: bzr-svn
[01:20] <lifeless> oh, traceback - bzr-svn
[01:21] <mthaddon> thx, that did it!
[01:25] <lifeless> mathrick: re Integration - whats confusing?
[01:27] <mathrick> lifeless: you present a bunch of different options, but you don't explain in which the integration happens. And then there's "For projects that do 'releases', the contents of a series could be much more mutable with no ill effects." which I completely fail to get
[01:30] <poolie> lifeless: just to check i understood, did you say last night that spiv would necessarily need to fix bug 368921 as part of his current work?
[01:31] <lifeless> yes, and he has already
[01:31] <lifeless> its in his branch
[01:33] <lifeless> mathrick: so the integration section is largely definitional
[01:35] <lifeless> mathrick: projects that branch off for each release, like bzr does, can do history edits outside of releases without affecting the ability to do archaeology across releases
[01:36] <mathrick> lifeless: humm, I'm afraid I still don't see what the integration is defined as. Is that the process of accumulating the code in branches? Or carving out a single 'release' out of them? (But then, why do you mention those that never do 'releases')
[01:37] <lifeless> its the process of integrating code from developers
[01:37] <lifeless> getting code from my branch to bzr.dev is integration
[01:37] <mathrick> ah
[01:38] <lifeless> if, for instance, we rebased integration it wouldn't affect bzr 1.16 at all
[01:38] <lifeless> s/integration/bzr.dev
[01:38] <mathrick> right
[01:38] <mathrick> although it'd introduce certain confusion potentially
[01:43] <lifeless> right
[01:43] <lifeless> but we could do a history-preserving edit to cleanup something in bzr.dev much more safely than doing it to 1.16
[01:43] <lifeless> because bzr.dev has no releases
[01:45] <mathrick> lifeless: to be precise, history-preserving is defined as "trees will still merge properly afterwards"?
[01:45] <lifeless> yes
[01:48] <mathrick> and what kind of edits can you do where that holds?
[01:48] <mathrick> I thought bzr only had the notion of complete states, so any change whatsoever morphs the state into something new and incompatible, no?
[01:55] <lifeless> so a history preserving edit is broadly a new commit that refers to the old one in some way
[01:55] <lifeless> e.g. as a parent
[01:55] <lifeless> or perhaps we can add some other annotations
[01:56] <mathrick> ah, this way
[01:57] <mathrick> so you mean alter the presentation, but not the contents
[01:57] <lifeless> yes
[01:58] <lifeless> FSVO yes
[01:58] <lifeless> the manifesto tried to capture goals and motivations, not implementations
[02:00] <mathrick> sure, I'm just trying to see what you had and hadn't in mind
[02:00] <lifeless> I wanted to try and get a cohesive view of /why/, so that when people talk about how, they don't need to debate merits of motivation
[02:01] <lifeless> without a rationale that supports e.g. rebase, history discarding edits are very contentious
[02:01] <lifeless> I didn't have particular implementations in mind
[02:02] <mathrick> right
[02:35] <RenatoSilva> join #python
[02:35] <RenatoSilva> join #python
[03:18]  * igc lunch
[03:40] <amanica> how do I resubmit a merge-proposal of a branch on launchpad?
[03:41] <amanica> (I commited more stuff as per review, but I don't know how to get the diff to update)
[03:42] <Peng_> Euhhh. People do it all the time, but i have no clue how.
[03:42] <amanica> https://code.edge.launchpad.net/~amanica/bzr/mv_after/+merge/6733
[03:43] <Peng_> Maybe what you do is use https://code.edge.launchpad.net/~amanica/bzr/mv_after/+register-merge again.
[03:43] <Peng_> I really don't know.
[03:44] <Peng_> I've seen people do it, but I don't know how.
[03:44] <amanica> I tried
[03:44] <amanica> but it wont allow me
[03:44] <amanica> it sais the branch already has a merge proposal
[03:44] <amanica> thanks in any case
[03:44] <Peng_> Can you change the status of the current proposal to superseded and then do it?
[03:44] <Peng_> I'm really just guessin' here.
[03:44] <amanica> I looksee
[03:47] <amanica> I'll just add a comment for now, maybe one of the subscribers will be able to help me. thx again for trying.
[03:54] <amanica> anyways, need to get an hour or two of sleep now before I have to go to work. goodnight/goodmorning.
[04:04]  * spiv -> lunch
[04:28] <sidnei> ooooh
[04:28] <sidnei> vila, jam: ping?
[06:14] <poolie> sidnei: hi
[06:14] <poolie> sidnei: you know vila's been working on a buildbot too?
[06:14] <sidnei> poolie: hey, i was heading to bed and heard a bit :)
[06:14] <poolie> he should be here soon
[06:14] <sidnei> beep even
[06:14] <poolie> well
[06:14] <poolie> by all means sleep
[06:14] <sidnei> poolie: i saw a mention somewhere, but thought it was for something else
[06:14] <poolie> is it 2am there?
[06:15] <sidnei> poolie: yep
[06:15] <sidnei> poolie: anyway, the client part is setup on kerguelen, we just need to find a proper master.
[06:15] <sidnei> poolie: mine is running off a nokia n810 :)
[06:16] <poolie> full points for style
[06:16] <sidnei> hehe
[06:17] <sidnei> alright, have a good erm... day :)
[06:17]  * sidnei hits bed
[06:18] <sidnei> poolie: maybe fwd my message to vila, and i will sync up with him
[06:24] <poolie> night
[06:26] <poolie> lifeless: just remembered, did you file an rt re tmpfs for pqm?
[06:26] <lifeless> poolie: no, got sidelined, sorry. Doing now.
[06:26] <poolie> np
[06:26] <poolie> i just wanted the number
[06:26] <poolie> it's not urgent
[06:27] <lifeless> actually
[06:27] <lifeless>  I can't
[06:27] <lifeless> evolution crashes when I click to change the 'from' address for mail.
[06:27] <poolie> :)
[06:27] <lifeless> \o/ karmic
[06:27] <lifeless> could you file it please?
[06:27] <poolie> i don't believe in evolution :)
[06:28] <poolie> sure
[06:36] <lifeless> poolie: popping out quickly, need to catch the bank before they close
[06:41] <poolie> np
[06:59] <RAOF> lifeless: Yeah, that's everyone's favourite Karmic GTK bug, I believe.
[07:12] <lifeless> RAOF: hmm, maybe I should take the time to fix it :P
[07:12] <lifeless> RAOF: is there a smaller test case than evo?
[07:13] <RAOF> lifeless: Pretty much every GTK app will do something like that _eventually_.  Evo seems to be the best at reproducing the particular phase of the moon required, though.
[07:14] <lifeless> evo is fantastic at it
[07:14] <lifeless> btw, turn up anytime
[07:17] <RAOF> lifeless: Hm.  It seems my laptop wants me to go now :)
[07:17] <RAOF> I was planning to get to the station at about 6ish; if I should be there earlier, I can do so.
[07:18] <lifeless> I live close by
[07:18] <lifeless> you can couch camp till its time to go
[07:19] <RAOF> OK.  I'll check that my phone has absorbed sufficient electrons for the evening and depart.
[07:32] <vila> hi all
[07:35] <igc> hi vila
[07:35] <vila> hi Ian
[07:36]  * vila shudders... At least the sound is back in my VM !
[07:46] <vila> Is there some reviewer around for https://code.launchpad.net/~vila/bzr/394190-osx-test-failures/+merge/8138 ?
[07:46] <vila> Whoever you are, I'll be grateful :-)
[08:17]  * igc heads off for a week of well deserved (in his opinion) vacation
[08:18] <igc> see everyone in a week's time
[08:48] <poolie> vila, i might do that
[08:49] <vila> poolie: that will allow me to reach a significant milestone for by build farm: having all instances fully pass the whole test suite. From there we can decide about the next step.
[09:58] <jml> who wants to review a small UI brancH?
[10:06] <jml> https://code.edge.launchpad.net/~jml/bzr/verbose-lp-login-bug-217031/+merge/8172
[10:11] <jml> bzr branch bzr://truth.local/bzr.dev
[10:11] <vila> jml: reading it right now
[10:11] <jml> vila, thanks.
[10:13] <vila> jml: I don't think 'jml' is meta enough to be used in tests, other than that: approve :D
[10:15] <jml> vila, thanks. will fix, add a NEWS entry & submit
[10:29] <vila> jml: oops, it was a joke ! Feel free to use whatever you see fit, it's refreshing to work with jml instead foo, bar, joe@example.com
[10:29] <jml> vila, hah. it's too late now :)
[10:30] <vila> jml: on the other hand, since it's your real handle, that may be risky if some leak occurs for an obscure reason, but that's a bit paranoiac :)
[10:31] <vila> jml: Now that I think about it, I should re-read these tests more carefully, maybe you're trying to take over every user that is running the test suite...
[10:31] <jml> haha
[10:34] <jml> next step: make bzr use launchpadlib
[10:53] <Kinnison> Is launchpadlib packaged nicely?
[11:00] <jml> Kinnison, I think it's in ubuntu & I think PyPI as well
[11:01] <jml> so... I'm thinking that lp-login should do the launchpadlib oauth authentication
[11:52] <bialix> perhaps I'
[11:53] <bialix> perhaps I'm missing something: does merge requests in bzr ML still supported?
[11:53] <bialix> or should I push my fix to LP as mandatory step?
[11:53] <bialix> vila: hi?
[12:01] <spiv> bialix: they're still supported AFAIK
[12:01] <bialix> ok
[12:01] <bialix> it's just BB is often down
[12:05] <jml> semslie, bzr ls -VR --kind=file --null | xargs -0 grep -In %s
[12:06] <jml> bialix, you can 'bzr send' to LP
[12:06] <jml> bialix, it'll create the branch for you.
[12:23] <bialix> jml: I can *send* to LP?
[12:23] <bialix> how?
[12:24] <jml> bialix, merge@code.launchpad.net
[12:24] <jml> bialix, I think detailed instructions are on help.launchpad.net/Code
[12:25] <bialix> there is nothing about sending
[12:26] <amanica> Peng: I figured out how to resubmit in launchpad: just click on the merge proposal status and change it to resubmit
[12:28] <bialix> amanica: hi, how are you?
[12:29] <amanica> hi bialix, I'm great, and you?
[12:29] <amanica> long time no see
[12:29] <bialix> I'm fine, planning vacation
[12:29] <amanica> ah, I'm still recovering from mine :)
[12:30] <bialix> :-)
[12:30] <amanica> where are you going?
[12:30] <amanica> South Africa perhaps?
[12:30] <bialix> IIUC there is winter, right?
[12:30] <bialix> :-)
[12:31] <amanica> yes, but it doesn't snow here
[12:31] <amanica> not much anyways
[12:31] <bialix> although here is too hot, but I'd like to go to the sea with family
[12:31] <amanica> ah ok, enjoy
[12:31] <bialix> :-)
[12:32] <jml> bialix, https://help.launchpad.net/Code/Review
[12:32] <bialix> did you saw new Bazaar Explorer?
[12:32] <amanica> I still need to try it out - too many things on my todolist, but I'm very exited about BE
[12:33] <bialix> jml: there is certainly some black magic under the hood, how I should specify project?
[12:33] <amanica> I'ms tutorial with pictures looks very nice
[12:33] <amanica> /I'ms/Ians/
[12:33] <bialix> jml: I suspect it still require to have the branch on LP beforehand
[12:34] <bialix> it's not problem per se though
[12:34] <jml> bialix, well, the trunk branch needs to be on Launchpad
[12:34] <bialix> amanica: and you can translate it to Afrikaans ;-)
[12:34] <jml> bialix, if the public url of the submit branch is known to Launchpad, Launchpad will use the project of that branch
[12:34] <jml> bialix, lots of awesome magic.
[12:35] <bialix> jml: ok, will try
[12:36] <amanica> bialix:  I thought about that, but then I think its not that important for Afrikaans-speaking people since our English is generally good
[12:36] <bialix> I know, it was joke
[12:36] <amanica> especially for programmers, since our work is mostly english
[12:36] <bialix> ok ok
[12:36] <bialix> :-)
[12:36] <amanica> :-)
[12:37]  * bialix bbl
[12:49] <jml> poolie, you around?
[13:15] <Peng_> amanica: Ah, thanks. :)
[13:16] <amanica> Peng_: cool, I'm glad I found it
[13:26] <vila> bialix: hi !
[13:26] <bialix> vila: hi
[13:27] <bialix> does jam will be here?
[13:27] <vila> I second jml, it's not mandatory, but we now prefer merge proposals on LP
[13:27] <vila> bialix: nope
[13:27] <bialix> should I re-send my patch?
[13:27] <bialix> can I persuade you to review patch for set_hidden_attr?
[13:27] <vila> I will be better yes, can you add a  test ?
[13:27] <bialix> test for what?
[13:28] <vila> One that really handle a path *under* the directory, the one you have it handling the directory itself,
[13:28] <vila> certainly fine, but no harm in adding one that is described in the comment :)
[13:28] <bialix> ok
[13:29] <vila> I will leave jam approve and land it though as I'm a bit hesitant to land a patch that I can't test myself (yes, yes, setting up a windows VM is still on the list :-/)
[13:32] <bialix> oho! you really surprise me!
[13:38] <vila> bialix: about what ? Nor approving or not having a windows dev VM set up ?
[13:46] <bialix> about your intent to setup windows VM
[13:50]  * bialix tries to send to LP
[13:53] <vila> bialix: I had one in my previous life, but for perl-based dev, I never found the time since to set up one for python (but I briefly used bzr on windows at one point)
[13:55] <vila> I feel a vergence in the force... is jelmer starting to work on releasing bzr-gtk ? :-)
[13:56] <fullermd> No, that was just me...   I had beans for lunch.
[13:57]  * bialix found bug in bzr send @ win32
[13:57] <bialix> what is 'vergence'?
[13:57] <jelmer> vila, :-)
[13:57] <vila> jelmer: if not and I can help to, lpease ask
[13:58] <jelmer> vila, first step is to clear up all bug reports, hopefully a release after that
[13:58] <vila> bialix: no idea, I'm repeating what I heard in Star Wars ;-D
[13:58] <vila> awesome
[13:58] <fullermd> I don't think it's actually a word, at least in any sense like it was used there.
[13:59]  * bialix never seen Star Wars in English
[13:59] <vila> fullermd: your use or Obi-Wan use ?
[14:00] <fullermd> I think it springs from the Star Wars Rule; if it {looks,sounds,tastes} cool, it doesn't matter if it's imaginary or impossible, it's in.
[14:01] <bialix> vila: ha-ha, got it!
[14:01] <bialix> "I feel vergence in the force"
[14:01] <bialix> LOL
[14:02] <bialix> after translating it to Russian I can see your joke
[14:02] <bialix> :-D
[14:02] <vila> bialix: the context in Star Wars was that something was happening, but nobody knows how it will turn out in the end
[14:03] <vila> bialix: and of course paranormal powers are absolutely required for such predictions
[14:05] <bialix> I've always thought they talked about Power or Force (see capitalization), but it seems it's just force :-(
[14:06] <bialix> rats! bzr can't see my default e-mail client. something broken
[14:07] <bialix> again
[14:09] <bialix> ha ha
[14:09] <bialix> I can't send merge request to LP
[14:10] <bialix> it says: All emails to merge@code.launchpad.net must be signed with your OpenPGP key.
[14:10] <bialix> very nice, I don't have one right now
[14:10] <bialix> heh
[14:10] <vila> rats :-/
[14:11] <vila> bialix: you know that lp created stacked branches now though, did you try bzr push lp:~bialix/... recently ?
[14:11] <bialix> old good push should help me
[14:11] <bialix> I have good channel right now, so I'm pushing
[14:11] <vila> ok
[14:11] <bialix> but I'm just wanna see magic
[14:12]  * bialix cries
[14:13]  * fullermd pulls a rabbit out of vila.
[14:13] <bialix> the branch pushed but not scanned yet
[14:13] <fullermd> Voila!
[14:13] <bialix> interesting, can I make merge request regardless?
[14:14] <vila> bialix: it usually takes a few seconds, minutes at worst
[14:14] <vila> bialix: by the way, the push was quick, you *do* have a good connection right now :0D
[14:14] <bialix> I did it! https://code.launchpad.net/~bialix/bzr/hidden_attr_on_unicode/+merge/8181
[14:15] <bialix> but send to ML was very nice thing
[14:15] <vila> bialix: want a cute one, try: 'bzr push ; bzr lp-open' :-D
[14:16] <vila> bialix: You can also request another review from jameinel from the URL above
[14:16] <bialix> C:\work\Bazaar\bzr-repo\hidden_dot_bzr_unicode>bzr lp-open lp:~bialix/bzr/hidden_attr_on_unicode
[14:16] <bialix> Opening https://code.edge.launchpad.net/~bialix/bzr/hidden_attr_on_unicode in web browser
[14:16] <bialix> bzr: ERROR: No module named webbrowser
[14:16] <bialix> You may need to install this Python library separately.
[14:16] <bialix> :-P
[14:16] <bialix> jml: why lp-open tries to open edge???
[14:16] <bialix> it's not fair!
[14:17] <vila> bialix: because, Yes You Can :)
[14:17] <vila> I thought webbrowser was part of the standard python library, are you using bzr.exe ?
[14:18] <bialix> what is Review type?
[14:18] <bialix> of course I'm using bzr.exe
[14:19] <bialix> vila: new test is OK for you?
[14:19] <vila> bialix: then file a bug against bzr.exe for not including a standard package used by a standard plugin :-D
[14:20] <bialix> it should be there, hmmm... another regression?
[14:20] <vila> bialix: yup
[14:20] <vila> bialix: it's imported lazily, could that explain it ?
[14:20] <bialix> yes
[14:20] <vila> hmm, tricky
[14:23] <bialix> yes
[14:26] <bialix> hm, does default e-mail client is editor?
[14:31] <vila> jelmer: can you update me about https://bugs.edge.launchpad.net/bzr/+bug/107169 ? Is it fixed upstream ? How ? Will it find its way in jaunty (since I hit it once after every reboot) ? Didn't Silvester had a work-around (swallowing the exception ?) ? Etc ? :D
[14:42] <jml> bialix, because it uses the edge xmlrpc service, because xmlrpclib handles redirects badly
[14:42] <bialix> I don't understand
[14:42] <jml> bialix, it gets the url from launchpad
[14:42] <jml> bialix, but it gets it from _edge_ launchpad
[14:43] <jml> bialix, so it's an edge url
[14:43] <bialix> non-edge lp can't do this?
[14:43] <jml> bialix, it can, but it will try to redirect anyone in launchpad-beta-testers
[14:44] <bialix> ok, it's too complex for me.
[14:49] <vila> bialix: are you a launchpad-beta-testers member ?
[14:49] <bialix> no
[14:50] <vila> ha, it's a bug then :)
[14:50] <bialix> in me?
[14:51] <vila> bialix: that too :-)
[14:51] <bialix> :-P
[14:52] <vila> no in lp, if you're not part of l-b-t, you shouldn't be redirected to edge, jml ? Am I correct ?
[14:52] <jml> vila, you're half right.
[14:52] <jml> vila, if you are not l-b-t, you are not redirected to edge
[14:52] <jml> but that's not what's happening here
[14:52] <jml> the bzr plugin has made a conscious decision to use edge
[14:53] <jml> because if we don't use edge, then people who are members of l-b-t get terrible errors
[14:53] <jml> because _some_ Python standard libraries don't support redirects.
[14:53] <jml> ZOMG it wasn't 200 it must be an error
[14:55] <vila> jml: ZOMG :) This one can be read in french as is :-D
[14:55] <jml> heh
[14:56] <jml> does l'Académie Française know about that?
[14:59] <vila> jml: pfff ;-P We have what we have and we do what we can with it :) whwwhawdwecwi sounds like mwhahahaha to me...
[15:00] <vila> I always Quebecers were better are defending French, but I was recently told I was wrong...
[15:00] <vila> I always thought Quebecers were better are defending French, but I was recently told I was wrong...
[15:00] <vila> L'Académie Française is good about defending herself though
[15:01] <jml> heh
[15:03] <vila> It's not that I don't like French, I like it very much thank you, but some of translations of words that never existed even in english are just a bit too much for my taste. Some are very nice at capturing the true meaning of the new word, but they are the exceptions. Some are just stupid like mel for mail which is just English with a strange accent ;-)
[15:05] <vila> déverminateur for debuger never made it for me, I was already a addicted bug hunter when they coined it though...
[15:05] <jml> heh
[15:08] <vila> For a good translation, I quite like ordinateur better than computer, but both are a bit out-dated now...
[15:08] <bialix> vila: can you run `bzr selftest -s bt.test_win32utils` on Linux? with LANG=C? please? s'il vous plait?
[15:08] <bialix> (for my patch)
[15:08] <pilky> anyone know what time zone martin pool is in, just wondering when he'd be on IRC
[15:09] <jml> pilky, Sydney.
[15:09] <pilky> ok thanks
[15:10] <vila> bialix: ha, *with* your patch ? WIthout it gives: http://paste.ubuntu.com/209036/
[15:10] <vila> rats, storm here, need to close windows
[15:10] <sidnei> hey vila!
[15:10] <pilky> a rat storm?
[15:10] <bialix> on Linux
[15:11] <vila> bialix: oh come on :-) In my appartment :)
[15:12] <vila> sidnei: Hey ! My word, what is your TZ ?
[15:12] <sidnei> vila: GMT-3
[15:13] <bialix> jam is right, but I think I need to check OS rather than Unicode
[15:13] <pilky> sidnei: -3? Is that Iceland?
[15:13] <vila> sidnei: oh, cool
[15:13] <sidnei> brazil actually
[15:13] <AfC1> lots of rat storms
[15:14] <vila> hmm, I feel like missing a joke about rats and storms, can someone kindly explain ? :-}
[15:14] <pilky> oh, I thought -3 was mid atlantic, ah well
[15:14] <pilky> "vila: rats, storm here, need to close windows"
[15:14] <AfC1> otherwise the rats will get in
[15:15] <sidnei> vila: so what can you tell me about your effort with buildbot?
[15:15] <vila> LOL, I thought 'rats' was kind of metasyntactic curse :)
[15:15] <vila> sidnei: anything you want to know :-)
[15:15] <bialix> vila: can I use TestSkipped or I should introduce OSWindowsFeature to skiup windows-specific tests?
[15:16] <sidnei> vila: what's the plan, basically. i know nothing about it ;)
[15:16] <vila> bialix: Using a feature is better so you get the number of tests skipped in the summary after a selftest run
[15:16] <vila> sidnei: did you see my mail from a couple of hours ago ?
[15:16] <bialix> vila: they'are already there: http://paste.ubuntu.com/209036/
[15:17] <sidnei> vila: maybe not, checking again
[15:17] <vila> bialix: then reuse it or define a new one
[15:17] <vila> bialix: let me have a closer look
[15:17] <bialix> vila: reuse TestSkipped?
[15:18] <vila> bialix: no, the features, circa line 58 in test_win32utils.py
[15:19] <bialix> there is no required module
[15:19] <bialix> even if win32file is not available, the code still works
[15:20] <vila> bialix: then look at bzrlib.test.Feature definition class and all classes that derive from it
[15:21] <bialix> let's say another time: does OS Windows is feature?
[15:22] <vila> bialix: if win32file is not available then I think jam remark is appropriate, use self.requireFeature(tests.UnicodexxxxFeature)
[15:22] <bialix> I can't find one
[15:22] <vila> I don't think OS windows is a feature (no pun intended :-D)
[15:22]  * vila is such a liar
[15:23] <vila> bialix: one sec
[15:25] <vila> bialix: bah, you even have two ! UnicodeFilename and UnicodeFilenameFeature
[15:25] <bialix> hm
[15:25] <bialix> ok, from the name it seems I need the latter
[15:25] <vila> right, UnicodeFilenameFeature is the one to be used, the former sounds like dirt to me
[15:27] <bialix> ok, I've fixed this. pushed on LP. jam already approved.
[15:27] <sidnei> vila: so you have a buildbot master setup yet?
[15:27] <bialix> vila: do you have the power to merge it, oh great master?
[15:28] <vila> sidnei: yes, on jaunty, with three slaves: jaunty, OSX tiger, OSX Leopard
[15:28] <vila> bialix: since jam approved, yes, did you update your branch ?
[15:28] <sidnei> vila: so can we point the buildbot client on kerguelen to it?
[15:28] <bialix> revno.4509
[15:29] <vila> sidnei: if you set up a slave to run the tests certainly
[15:29] <bialix> vila: yes, LP already got it
[15:29] <sidnei> vila: i've got it ready for building the installer, tests would be next step
[15:31] <vila> sidnei: hmm, I'm not sure I understand the logic here, my master ask the slaves to run the tests, not to build an installer
[15:31] <sidnei> vila: i guess you don't understand the master then :)
[15:31] <bialix> sidnei: is that you made zc.build patch?
[15:31] <sidnei> vila: you can configure the master to build many projects
[15:31] <sidnei> bialix: yes
[15:31] <vila> sidnei: ha, then I miss that part
[15:32] <bialix> sidnei: what the goal?
[15:32] <vila> sidnei: and associate only some slaves to some builders ?
[15:32] <sidnei> vila: so, in buildbot terms, you can have many 'builders', those are the different projects. and each 'builder' can have many slaves
[15:32] <sidnei> vila: exactly
[15:32] <vila> oh great
[15:33] <vila> so you mean I will be able to ask kerguelen whatever I want in addition to building the windows installers ?
[15:33] <sidnei> vila: correct
[15:33] <vila> woohoo
[15:33] <sidnei> bialix: automate fetching the build dependencies for the installer.
[15:33] <bialix> and?
[15:33] <vila> bialix: automate running the test suite against bzr.dev once a day and collect the results
[15:34] <vila> bialix: kerguelen is a windows machine in case you didn't notice
[15:34] <bialix> vila: I know
[15:34] <vila> bialix: do I surprise you again ? :-D
[15:35] <bialix> I don't understand why for "automate fetching the build dependencies for the installer." is needed? It's not target per se but mean. Yes? What's the target?
[15:35] <bialix> vila: no :-P
[15:35] <bialix> I was aware about kerguelen
[15:35] <bialix> this name is pun
[15:36] <sidnei> bialix: and there's a ton of dependencies scattered all over the place. you could have a plain python script or even a .bat file to fetch the dependencies, but using zc.buildout there are existing dedicated recipes for doing things like 'download this zip file and unpack in directory X' and 'checkout branch Z from this url'
[15:36] <vila> bialix: looking at your patch in context: self.requireFeature() perfect: http://paste.ubuntu.com/209051/
[15:36] <bialix> vila: thanks
[15:37] <vila> sidnei: do you know if the zope license is compatible with the GPL  ?
[15:37] <bialix> sidnei: are you aware about Bug 388790
[15:38] <bialix> sidnei: if you can solve python-vased install with your zc.build patch this will be Great Target. No?
[15:38] <vila> bialix: does your patch fixes #335362 or is it only a partial fix (i.e. should I --fixes lp:335362)
[15:38] <sidnei> vila: im almost sure it is, but why the question? there's no ZPL code there
[15:38] <vila> sidnei: I think the file you added is under zope license
[15:39] <bialix> vila: not really
[15:39] <sidnei> vila: ah, bootstrap.py might be
[15:39] <vila> sidnei: yes maybe that one
[15:39] <bialix> vila: it was discovered by Naoki while discussing that bug.
[15:39] <vila> bialix: of so, no --fixes
[15:39] <sidnei> vila: http://www.zope.org/Resources/ZPL
[15:40] <bialix> I prefer no fixes
[15:40] <sidnei> "This license has been certified as open source. It has also been designated as GPL compatible by the Free Software Foundation (FSF)."
[15:40] <vila> sidnei: great
[15:41] <sidnei> bialix: i wasn't aware of that bug. in fact, im not supposed to be working on the installers per se, only automating the build.
[15:41] <bialix> automating for what or for who?
[15:42] <vila> bialix: -m '(bialix) Setting hidden attribute on win32 should never fail (and OS locks must die, but I diverge).' ok ?
[15:42] <bialix> perfect!!!
[15:43] <bialix> :-D :-D :-D
[15:43] <sidnei> bialix: having a buildbot that builds each installer every day, so that it requires no manual intervention other than telling buildbot when new versions are released.
[15:43] <bialix> sidnei: so, it can/should be used instead of build_release.py?
[15:43] <vila> bialix: naaaah, they will die, no need for that :)
[15:44] <bialix> rats!
[15:45] <vila> sidnei: so what needs to happen ? You send me your master.cfg file and I send you my build master host/port address ?
[15:45] <vila> sidnei: and you nokia can take some rest ? :0D
[15:46] <sidnei> bialix: supposedly yes. to make it clear, build_release.py expects you to manually get all the bits and pieces like the svn dev binaries and tortoiseoverlays. the new stuff fetches the svn dev binaries and tortoise overlays and all the different bzr branches of the plugins for you, then there's a 'build-installer.bat' that does just the core of what build_release.py does.
[15:47] <sidnei> vila: correct, that's the plan.
[15:47] <vila> sidnei: ok
[15:47] <sidnei> vila: if you can put *your* master.cfg on a branch, and then i send you a merge proposal, that would be perfect actually
[15:47] <sidnei> vila: i like that idea of keeping the passwords external to it though
[15:48] <sidnei> vila: so we should do that
[15:48] <vila> sidnei: ok, I let you know as soon as it is done
[15:48] <bialix> sidnei: one suggestion then: can you start the process from root dir, will be nice as `make xxx` and put all installers there?
[15:48] <sidnei> bialix: sounds good to me
[15:49] <sidnei> bialix: i will do that
[15:53] <jml> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
[15:53] <jml> [GCC 4.4.0] on linux2
[15:53] <jml> Type "help", "copyright", "credits" or "license" for more information.
[15:53] <jml> >>> from bzrlib.transport import get_transport
[15:53] <jml> >>> t = get_transport('bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk')
[15:53] <jml> >>> t.base
[15:53] <jml> 'bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/trunk/'
[15:53] <jml> >>>
[15:54] <LarstiQ> right
[15:54] <jml> what the hell is escaping the tilde
[15:59] <vila> jml: damn ! It's not as if noone landed a patch to avoid precisely that ! :-)
[16:00] <sidnei> bialix: so where the installers should be put? at the root dir?
[16:01] <jml> vila, :)
[16:05] <bialix> sidnei: it will be nice, though the last word should be from jam
[16:05] <sidnei> bialix: ok, thanks!
[16:06] <bialix> sidnei: from the rule: don't break what is working today
[16:07] <sidnei> bialix: yeah, i tried to avoid that as much as possible, hopefully it will be fine.
[16:18]  * mgedmin sighs
[16:18]  * bialix sighs
[16:18] <LarstiQ> mgedmin: can I help you?
[16:18]  * mgedmin doesn't know
[16:19] <mgedmin> do you know why in jaunty I cannot use bzr viz?
[16:19] <mgedmin> I get an internal error
[16:19] <mgedmin> I have no plugins in ~/.bazaar
[16:19] <LarstiQ> bzr-gtk and bzr are both from jaunty?
[16:19] <mgedmin> are there plugins in jaunty that are incompatible with bzr in jaunty?
[16:19] <mgedmin> yes they are
[16:19] <mgedmin> no PPAs
[16:19] <LarstiQ> mgedmin: I would hope not
[16:19] <mgedmin> bzr 1.13.1-1, bzr-gtk 0.95.0+bzr629-1ubuntu1
[16:20] <mgedmin> the error is ... gone!
[16:20]  * LarstiQ blinks
[16:20] <mgedmin> it was DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
[16:20] <mgedmin> I hadn't thought to simply re-run the command again
[16:20] <LarstiQ> ah
[16:21] <mgedmin> should I file a bug?
[16:21] <LarstiQ> that sounds like a bzr-dbus thing
[16:21] <LarstiQ> mgedmin: hmm, maybe check if there is already one
[16:22] <jelmer> mgedmin, IIRC this was a seahorse bug
[16:23] <jelmer> mgedmin, the first time seahorse is contacted over dbus it breaks and doesn't reply
[16:24] <mgedmin> seahorse.py is in the traceback, yep
[16:24] <mgedmin> I'm at a sprint and we'll be kicked away from here in 30 minutes, so I don't have time to search launchpad for bugs now
[16:24] <mgedmin> but thanks for the explanation
[16:28] <mgedmin> hey, actually my working dir is clean and I won't have time to start a new task
[16:29] <mgedmin> oh no, I closed the terminal with the traceback
[16:58] <vila> mgedmin: try again, for me that bug happens only once after each reboot
[17:01] <mgedmin> I'm most definitely not going to reboot just to reproduce a bug, sorry
[17:01] <mgedmin> reboots in ubuntu *suck*
[17:05] <dash> huh. more than in something else?
[17:05] <dash> oh he left
[17:06] <dash> so i guess i can't tell him about http://www.ksplice.com/
[17:07] <vila> dash: LOL
[17:08] <vila> Well my point was to give him the work-around not asking to reproduce :)
[18:15] <johnskulski> I am working with a svn repository that I bzr branched. So when I merge changes, commit and push all the commits come from me and not the people who actually committed. Is there a work flow around this?
[18:43] <Peng_> lifeless: Ya know, lp:bzr-guess is branch 6, even though it uses a 2a repo. :D
[18:43]  * SamB still doesn't understand what the --incremental option to svn-import does
[18:44] <Peng_> SamB: If 'bzr svn-import' was 'bzr branch', 'bzr svn-import --incremental' would be its 'bzr pull'.
[18:45] <SamB> hmm. so why doesn't the help for svn-import say anything to that effect?
[18:46] <Peng_> SamB: I dunno. Maybe I'm wrong, eh? :D
[18:46] <SamB> and why not make it the default?
[18:46] <Peng_> SamB: I dunno. Ask jelmer.
[18:47] <SamB> hmm, I'm pasting this IRC conversation into a bug, okay?
[18:47] <Peng_> Okay.
[18:47] <SamB> thanks ;-)
[18:49] <Peng_> Seconds after I installed bzr-guess, I typed "bzr missung", and it worked. :)
[18:56] <SamB> hmm, too bad that john dude left :-(
[19:15] <SamB> Peng_: okay, it's bug 395266
[19:16] <Peng_> SamB: Yeah, I just saw the bugmail. :D
[19:17] <SamB> Peng: ah.
[19:17] <SamB> didn't know who all was on the team or whatever
[19:17] <SamB> hmm, should I have used your real name instead of your IRC nick?
[19:18] <Peng_> SamB: I'm not, but I subscribe to a lot of bugmail.
[19:18] <Peng_> SamB: Eh, doesn't matte.r
[19:20]  * Peng_ gets killed by ghosts.
[19:21] <Peng_> How do you find if a certain revision ID exists in a repo, without knowing the specific branch?
[19:23] <SamB> oh, that reminds me
[19:24] <SamB> I need to complain about bzr-gtk not supporting visualization of entire repositories, or at least of all branches that can be found within them
[19:24] <Peng_> Oh, never mind, I had just messed something up.
[19:25] <gioele> SamB: use "bzr explore" (from the Bazaar Explorer plugin)
[19:25] <SamB> doesn't that need qbzr?
[19:25] <gioele> SamB: yes it does
[19:26]  * SamB checks if he has that, and if not why not
[19:27] <gioele> SamB: there is a PPA for latest qbzr
[19:27] <SamB> hmm, reason seems to be that it pulls in 65 megabytes of qt4-related dependencies
[19:28] <SamB> stupid gigantic python-qt4 package :-(
[19:29] <Peng_> See? 640k and the CLI should be enough for everyone. :D
[19:35] <gioele> SamB: ask the python-qt4 packagers to split the package into qt4-like sub-modules
[19:37] <SamB> you think they'd listen?
[19:38] <SamB> the libc maintainer was really not keen on splitting the debug info into multiple packages -- not even a seperate one for x86_64 :-(
[19:39] <gioele> SamB: well, libqt4 packages are split in Ubuntu
[19:46] <SamB> libqt4 packages themselves are split here, too
[19:48] <Peng_> What the... How can pulling a bunch of branches from one repo to another leave the new repo with more revisions than the old one? Especially when I left out one branch?
[19:49] <Peng_> Oh, it's cuz I'm a moron and confused which repo was which. :D
[19:51] <jh> hi, I have an outdated local repository with some uncommitted changes. now I want to pull a new copy from the global repository. but with "bzr pull --overwrite" I encounter several conflicts... how is that possible?
[19:53] <Peng_> jh: I guess your uncommitted changes conflict with some upstream changes?
[19:54] <jh> but I said --overwrite
[19:54] <SamB> jh: that's not what overwrite does
[19:54] <jh> what does overwrite?
[19:54] <jh> and what does what I want? =)
[19:55] <gioele> jh:  overwrite means "ignore that I have something to merge upstream"
[19:55] <SamB> what --overwrite does is it disregards whether the revision your tree is currently based on is an ancestor of the one you would be pulling in
[19:55] <SamB> normally, it refuses to pull when your revision isn't an ancestor of the one to be pulled in
[19:56] <jh> hm, bzr pull --overwrite + bzr revert does what I want
[19:56] <SamB> I don't think you should pass --overwrite
[19:57] <SamB> it doesn't do what you want, and might do something you don't want
[19:59] <jh> I just want the current revision from the global repo in my working copy
[19:59] <jh> ignoring everything else
[19:59] <jh> how should I do that?
[20:00] <gioele> bzr update?
[20:01] <gioele> oops, I meant, "make it bound thatn bzr update"?
[20:01] <gioele> s/thatn/then/
[20:01] <jh> "make it bound"?
[20:02] <gioele> bzr reconfigure --bind-to
[20:04] <jh> k, thx
[20:04] <jh> will try that next time
[20:09] <Peng_> Isn't there a bug about Bad Things happening to the dirstate when upgrading to rich roots?
[20:25] <ndurner> Hi
[21:30] <fta> james_w, i have a problem with bzr-builddeb in karmic: http://paste.ubuntu.com/209269/
[21:34] <james_w> fta: ouch
[21:35] <fta> james_w, i have that quite often, and the tarball is always fine. dpkg-buildpackage has no problem dealing with it directly.
[21:37] <fta> started a few weeks ago
[21:37] <james_w> gzip: stdout: Broken pipe
[21:37] <james_w> so tar is dying?
[21:37] <james_w> no, clearly not
[21:37] <james_w> but gzip is failing to write to it
[21:39] <Peng_> I just "bzr pack"ed a 2a repo down 9 KB. Awesome! :D
[21:41] <fta> james_w, as i said, the tarball file is just fine, but bzr-builddeb can't use it, for some reason. looks like a short pipe to me, one end closing too early. as it's gzip complaining, it's either tar or python
[21:42] <james_w> tar I think
[21:43] <fta> but tar in cli has no problem
[21:43] <james_w>                 ret = subprocess.call(['tar','-C',tempdir,'-xf',tarball])
[21:45] <james_w> so I don't see what is different there
[21:45] <james_w> can you reproduce with something like that in a python prompt
[21:45] <james_w> does it happen every time?
[21:51] <Peng_> But then repacking made something else 16 KB larger. So much for that.
[21:51] <Peng_> Shouldn't "bzr pack" be deterministic?
[21:52] <Peng_> Or, well, uh, not changing every time you run it?
[21:54] <fta> james_w, http://paste.ubuntu.com/209289/
[21:55] <Peng_> Err, bytes, not KB.
[22:53] <james_w> fta: I've no idea really why that would be happening
[22:58] <fta> james_w, http://paste.ubuntu.com/209301/
[22:58] <fta> strange, every few days, it's a different tarball. asac is also experiencing that on his side
[22:59] <james_w> how do you "fix" it?
[22:59] <james_w> it happens every time for that tarball once it starts?
[22:59] <james_w> could you add a "v" to the command to see if that gives any clues?
[23:00] <fta> i straced it, it's trying to write on a closed fd
[23:08] <james_w> fta: could you pastebin the strace please?
[23:09] <fta> james_w, http://paste.ubuntu.com/209340/
[23:15] <james_w> so it seems to finish, and then keep trying to write more data
[23:15] <james_w> it is odd
[23:16] <james_w> I wonder if it could be http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/07/02#2009-07-02-python-sigpipe
[23:21] <fta> james_w, sorry, i know a lot of languages but close to nothing in python.. http://paste.ubuntu.com/209345/
[23:22] <fta> i can give you the tarball if you like, it's 100% reproducible here
[23:24] <james_w> you can just add preexec_fn=subprocess_setup to the original call by my reading
[23:24] <james_w> otherwise that works for me
[23:25] <fta> http://www.sofaraway.org/ubuntu/tmp/songbird_1.3.0~a~svn20090703r14148.orig.tar.gz
[23:28] <james_w> thanks