[01:28] <poolie> hi spiv
[01:30] <spiv> Hi poolie
[01:30] <poolie> how are you?
[01:33] <spiv> Pretty good, codebrowse now appears to generate OOPSes :)
[01:33] <poolie> great :)
[01:33] <poolie> now we just need to stop it generating oopses :)
[01:33] <poolie> so we're half done?
[01:34] <spiv> And tell the OOPS reports infrastructure about them, apparently, but yes :)
[01:34] <spiv> At least it gives a slightly less ugly page now, even if the reports aren't visible to devs yet :)
[01:37] <lifeless> spiv: are you going to drive this through to conclusion?
[01:37] <lifeless> spiv: if not, please be sure to handover clearly so I or someone else can
[01:37] <spiv> lifeless: I just sent a mail to matsubara
[01:37] <lifeless> \o/
[01:37] <spiv> lifeless: (who finally replied to my mail to him from weeks ago :/)
[01:45] <james_w> renames + bzr-builddeb are starting to get really hairy
[01:45] <james_w> well, they've always been hairy, I'm just starting to realise :-)
[01:45] <lifeless> james_w: lol, yes.
[01:45] <james_w> what we have currently is buggy, and worse, unstable
[01:46] <james_w> it might permute the file ids in your tree on every merge
[01:46] <james_w> which is...not ideal?
[01:47] <lifeless> james_w: it shouldn't do that, I don't think.
[01:47] <lifeless> james_w: at least, the patch I put in had some reasoning about that sort of thing around it.
[01:48] <james_w> lifeless: it looks through a number of trees (including itself) and if the path has a different id in any tree then it will switch it
[01:49] <james_w> so it won't reach a steady state if there are two trees that continue to differ on path2id for a particular path
[01:49] <lifeless> it switches? I thought it took the incoming id
[01:49] <lifeless> because the incoming is 'upstream'
[01:49] <james_w> incoming is a list, not a single tree
[01:50] <james_w> so I think we may have two things that are currently conflated to unpick
[01:50] <james_w> or some earlier assumptions may have to be changed, and it changed to be fewer trees to examine
[01:51] <james_w> there is a "goal tree" that we want to look at
[01:51] <james_w> and the old semantics which was "a list of trees that you should re-use ids from for added files"
[01:52] <james_w> which was added to mainly reduce the conflicts between debian + ubuntu IIRC
[01:52] <james_w> from something like the parallel import problem
[02:01] <lifeless> and upstream vs tarballs
[02:01] <lifeless> we want ids to flow from upstream -> tarball -> debian -> ubuntu
[02:01] <lifeless> I think :)
[02:01] <james_w> yeah, I think
[02:02] <james_w> we have 3 commands to consider: 1. dh-make 2. import-upstream/merge-upstream 3. import-dsc
[02:03] <james_w> dh-make is pretty boring for this, as it just introduces a tarball to a branch, so there is only one source of ids. I just need to check that it will only have a single tree, the upstream tree, and we can ignore it
[02:05] <lifeless> james_w: well
[02:06] <james_w> yes, that's a boring case as there is only a single tree
[02:06] <lifeless> james_w: one problem is that dh-make is what folk are pointed at to 'get going', but if their project is in bzr, they should really start from there.
[02:06] <james_w> lifeless: dh-make works with existing branches
[02:06] <lifeless> ok
[02:06] <lifeless> cool, my misunderstanding
[02:07] <james_w> "if the project is in bzr then start in a branch at the revision corresponding to the release you are packaging"
[02:07] <james_w> it just means we can talk about a single command as the starting point
[02:08] <james_w> import-upstream, this has more trees for sure
[02:08] <james_w> there's the existing "pristine tree" and an optional upstream tree
[02:09] <james_w> we don't really care about the packaging tree, except for an instance of the parallel imports problem
[02:09] <james_w> if we have an upstream tree then it should be authoritative, otherwise there is just the pristine tree, so there's no issue
[02:10] <james_w> the parallel imports problem is: 1) add a file in the packaging 2) new release contains (just in the tarball) that same path
[02:11] <james_w> if we do nothing we get a path conflict, but we can choose to turn that in to a contents conflict if we like
[02:11] <james_w> so far so good
[02:11] <james_w> import-dsc is more complicated I think
[02:12] <james_w> first there are two import_archives done, one for upstream and one for the packaging
[02:12] <james_w> in command line usage there are few trees
[02:12] <james_w> just the ones you are importing on top of
[02:13] <james_w> if we ignore parallel imports then upstream is easy, as there is just the single tree
[02:13] <james_w> for the packaging it may be more tricky, as you have the existing packaging tree, plus the pristine tree you just created
[02:14] <james_w> my guess is that in that case you want the pristine tree to be authoritative
[02:14] <james_w> it will have little impact generally
[02:15] <james_w> however, if we ignored parallel imports then if a file migrates from packaging to upstream (no bzr involved) then you can get packaging fileids changing
[02:16] <james_w> so far, I think we want 0 or 1 target trees, which are authoritative and we look for renames in etc.
[02:16] <james_w> and 0 or 1 opportunity trees which we will take fileids from if we are about to generate one and that tree has the path already
[02:16] <james_w> I'm suspicious that doing that will cause some problems, but I don't know what they are right now
[02:17] <james_w> when the importer use import-dsc, it has access to a lot more trees though, everything for Ubuntu and Debian, past and present
[02:18] <james_w> so, we could have 0 or more opportunity trees, and just pass them as that, but as I said, there may be pitfalls there
[02:18] <james_w> however, it may be that we want target trees as well
[02:19] <james_w> if not now, then maybe further down the road
[02:19] <james_w> I have a feeling that my experiment with rename detection in import-dsc fell down due to something related to that same question
[02:20] <james_w> so, what could go wrong with taking fileids from another tree, rather than generating them?
[02:20] <james_w> we would have to ensure that the ids weren't duplicates within our tree
[02:21] <james_w> obviously it can associate files with different "identities", but that's a risk that is outweighed by the benefits IMO
[02:22] <james_w> I can't really see any other issues
[02:23] <lifeless> right
[02:23] <james_w> if there is a target tree, now or later, then it will override, so that would get you out of some holes
[02:23] <lifeless> I put dup catching code in my patch, fwiw
[02:23] <james_w> lifeless: well, I spent the morning dealing with a crash due to duplicated ids :-)
[02:24] <lifeless> ahh
[02:24] <james_w> coming from a rather odd place though
[02:24] <james_w> if upstream renamed a file, then shipped another file at the old path in the tarball that wasn't in the branch, the code would use the same id for both
[02:26] <james_w> when may we want target trees in import-dsc?
[02:27] <james_w> maybe when we detect e.g. a merge from debian->ubuntu
[02:27] <lifeless> james_w: hang on, I fixed that exact same bug 3-4 months back
[02:27] <lifeless> james_w: with test.
[02:28] <james_w> I can see we may later when it knows about upstream trees and tries to guess how to graft them on
[02:28] <lifeless> james_w: this sounds like a regression
[02:28] <james_w> lifeless: I think it was the other way round, where it renamed on top of another file
[02:28] <lifeless> oh, perhaps its a variation on the theme.
[02:29] <james_w> bug 588060
[02:29] <ubot5`> Launchpad bug 588060 in bzr-builddeb "unversioned executability issue, perhaps in builddeb (affected: 2, heat: 7)" [High,Fix committed] https://launchpad.net/bugs/588060
[02:30] <james_w> ah, no, you fixed rename and replace with a versioned file
[02:30] <james_w> I just extended it to unversioned
[02:31]  * james_w gets to work implementing the above
[03:17] <spiv> Hmm, yo yo internet for me today.
[03:54] <james_w> done
[03:54] <james_w> night all
[03:55] <poolie> night james
[04:32] <jam> hey poolie I have a question for you
[04:47] <jam> I had a question about async/sync feedback of the spawned process. I have all the connections working and "bzr log bzr+ssh://" is working, but it ends up hanging because Twisted needs to know when the process ends
[04:47] <jam> anyway, I'll try to write something up
[04:47]  * jam goes to play the new Metroid
[05:21] <poolie> hi jam
[05:21] <poolie> jam, can you point me to your code?
[07:55] <vila> hi all !
[08:01] <vila> poolie: see late comment on your ui mp
[08:01] <poolie> k
[08:01] <poolie> vila i'm just trying a side branch towards testing these things from scriptrunners
[08:01] <poolie> bit of a distraction but nice if we can do it, from the point of view of testable examples
[08:01] <vila> sure thing
[08:02] <vila> I'm feeling more and more inclined to write 'bzr config'...
[08:03] <poolie> arguably the 'all the configs we have open' should be semi-global state
[08:03] <poolie> perhaps in this context object robert wanted
[08:03] <poolie> vila, oh, what would it do? just be a command to set state?
[08:04] <vila> poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var
[08:04] <vila> or *unset* one !
[08:06] <poolie> could be good
[08:06] <poolie> what are you going to do today?
[08:07] <vila> finish submitting proposal for bug #323111 and then... setup a proper TODO list
[08:07] <ubot5`> Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 1, heat: 8)" [Medium,In progress] https://launchpad.net/bugs/323111
[08:07] <poolie> i mention script runners because even when i intentionally change uncommit's confirmation string, it still passes its tests :/
[08:07] <poolie> oh, yay
[08:08] <vila> urgh, how come ?
[08:09] <poolie> it seems that aspect is not tested
[08:10] <poolie> i would guess because it's a bit too hard to write good tests for user confirmation
[08:10] <poolie> spiv, where was that testdoc script?
[08:10] <vila> he he :) :-| :-/
[08:23] <poolie> vila, so fwiw it fails because scripts run with a TestUIFactory whose stdin is connected to a (probably empty) stringio
[08:23]  * vila shudders... almost all transform tests force the format to be dirstate-with-subtree, I wonder what consequences it has on coverage :-/
[08:23] <poolie> would it be reasonable to arrange for them to pull lines from the script? maybe so
[08:24] <poolie> perhaps only for tests that specifically want this?
[08:24] <vila> err, did you try adding '< y' lines ?
[08:24] <vila> if the script provides no input, that should be an empty stringio, but if it does... it should be respected
[08:25] <poolie> hm
[08:25] <vila> hmm, ok, I overreacted, half of them only force the format :-/
[08:26] <poolie> still, would be good to separate it out
[08:26] <poolie> at least to an abstract "a format with subtrees"
[08:26] <poolie> we could grep for more tests like that
[08:26] <vila> yup, or put them under.. per_workingtree
[08:27] <vila> oh wait, there may be some there already so probably they *are* tested indirectly
[08:27] <poolie> actually it's better than i thought
[08:27] <poolie> it complains the string is missing a newline
[08:27] <poolie> which it is
[08:27] <poolie> but it seems easy to make it tolerate that
[08:27] <poolie> but now i really need to go
[08:28] <vila> script error reporting needs some love, iirc I needed a trick to produce correct line numbers for embedded strings
[08:30] <poolie> just getting a diff across the whole script might help
[08:30] <poolie> sometimes the one line it complains about is not very obvious
[08:30] <poolie> matcher might help
[08:30] <vila> matchers... yeah, I should *really* start using them :-/
[08:32] <poolie> not so hard
[08:32] <poolie> just need to change your habit
[08:32] <poolie> oh, and we need to convert some existing utilities
[08:33] <vila> oh, I'm fully convinced :)
[08:33] <vila> It's just that I keep forgetting ;)
[08:36] <bialix> hey
[08:36] <bialix> vila, poolie: re https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956
[08:36] <bialix> what qbzr should be aware of?
[08:37] <vila> bialix: the new ui.confirm_action() method, that's the point of the mp
[08:37] <bialix> so?
[08:37] <bialix> my brain is slightly slow this morning
[08:38] <vila> bialix: may be you should read it, or at least the comments
[08:38] <vila> bialix: the question is: 'what impact would it have on qbzr if any' to add a new ui method
[08:39] <bialix> ok, IIUC qbzr should override this method, right?
[08:39] <vila> bialix: if you want to decorate it yes, otherwise it will fallback to get_boolean
[08:39] <bialix> as I remember we already using our own ui class, so we just need to override that method here
[08:40] <bialix> the good example is quncommit
[08:41] <vila> bialix: yeah, I think it's enough, I was worried about a case where you override confirm_action and not get_boolean, but that doesn't make sense I think
[08:41] <bialix> it has the custom asker
[08:41] <bialix> no, I really feel stupid today, wait a sec
[08:42] <vila> my concern was: are we introducing a new method that suddenly will prompt from the console ?
[08:42] <bialix> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head%3A/lib/subprocess.py#L832
[08:43] <bialix> my answer based on the link above: no, we have implementation for get_boolean
[08:43] <bialix> we == qbzr
[08:43] <vila> but since the implementation use get_boolean, I think it was silly. Now, if we make confirm_action depends on config variables... there may be other concerns like: always ask when using GUI, respect config var from command line
[08:43] <bialix> vila: how well bzt-gtk will behave I don't know
[08:44] <vila> & respect config var from command line *otherwise*
[08:44] <bialix> "I think it was silly" -- I don't understand
[08:44] <bialix> which one config var from command-line?
[08:44] <vila> I think *I* was silly, my concern was silly
[08:45] <vila> confirm_action use a confirmation_id the plan is to map it to a config var
[08:45] <bialix> so, your concern about our inability to handle get_boolean was wrong, right? ok
[08:46] <vila> so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just the command, stop asking will you ?'
[08:46] <vila> bialix: yes
[08:46] <vila> so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just typed the command, stop asking will you ?'
[08:46] <bialix> so, your concern about our inability to handle get_boolean was wrong, right? ok, when user can override any config parameter from command-line in the universal way? that would be great
[08:46] <bialix> sorry
[08:47] <bialix> the last message messed up
[08:47] <bialix> something wrong with chatzilla
[08:48] <bialix> will we have an universal way to override any config option from command line, like hg?
[08:49] <vila> bialix: you mean:<vila> I'm feeling more and more inclined to write 'bzr config'... ?
 vila, oh, what would it do? just be a command to set state?
 poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var
 or *unset* one !
[08:50] <bialix> vila: no, like this: `bzr uncommit --config "bazaar.conf:uncomiit_dont_ask_me = True"
[08:50] <vila> bialix: no like -obzrlib.lock.break=y
[08:50] <bialix> hg allows user to provide config settings for *current* coimmand
[08:51] <bialix> the latter is fine too
[08:51] <vila> bialix: see bug #<that one, thanks ubottu>
[08:51] <bialix> ubottu, don't sleep, read vila's mind, please
[08:52] <vila> bug #491196
[08:52] <ubot5`> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line (affected: 3, heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/491196
[08:52] <vila> yeah, -O not -o
[08:53] <bialix> yeah, rocks
[08:53] <vila> bialix: just metoo it will you ? :D
[08:53] <bialix> :-)
[09:04] <bialix> bug 634240
[09:04] <ubot5`> Launchpad bug 634240 in Bazaar Explorer "Initializing colocated branch fails. (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/634240
[09:04] <bialix> signature of set_reference was changed in 2.2? but news has no mention of it
[09:11] <bialix> vila: you merged taht patch from jelmer
[09:11] <bialix> it has no news
[09:11] <vila> patches welcome :)
[09:11] <bialix> revno 5050.115.58
[09:12] <bialix> in trunk
[09:12] <bialix> the train is already left the station
[09:12] <bialix> who want patches now?
[09:12] <vila> all the people ready to fall in the same trap
[09:13] <vila> bialix: I can't find this revno, revid ?
[09:14] <bialix> sorrrrrrrrrry, it's revno in 2.2 branch
[09:14] <bialix> revid:pqm@pqm.ubuntu.com-20100507115028-tuuxmnormm8oetw6
[09:15] <bialix> it was possible to avoid compatibility break here, but anyway, the train is already left
[09:15] <bialix> sorry for the rant
[09:18] <vila> bialix: right, I reviewed it and rely on bzr-loom to catch compatibility issues so I missed this one :-/
[09:19] <vila> bialix: is that a problem for bzr-explorer only or are there other colo related plugins that will suffer from it
[09:19] <bialix> I'm not sure yet, I need to check bzr-colo plugin itself
[09:19] <vila> bialix: did you find this by running a test suite or manually ?
[09:20] <vila> bialix: underlying question: can we automate something to detect such problems in the future ?
[09:20] <bialix> user filed bug report
[09:20] <vila> :-(
[09:20] <bialix> vila: perhaps
[09:21] <bialix> this specific bug -- yes, it's possible to create at least blackbox test for explorer
[09:21] <vila> On the positive side, it's more instance satisfying the rule: any bug is a missing test :)
[09:21] <bialix> will do while I will be fixing this particular bug
[09:21] <vila> bialix: thanks
[09:22] <bialix> vila: tests rock, yes, but gosh, it tends to steal too much time
[09:22] <vila> bialix: as do bugs
[09:23] <bialix> bzr-colo seems not affected, Neil has 2 code paths for 2.1 and 2.2
[09:26] <spiv> Hmm, the per_tree/test_list_files.py tests could use some refactoring (and many more cases)
[09:27]  * vila grumbles: stupid emacs can't be spawned from xchat to open spiv links
[09:28]  * vila get away from copy/pasted test code in disgust :(
[09:28] <vila> spiv: from future import BB:approve :)
[09:29] <spiv> vila: hah
[09:30] <spiv> Something to try forget about over the weekend and tackle on Monday, perhaps :)
[09:30] <spiv> vila: have a good weekend :)
[09:30] <vila> spiv: you too !
[09:30] <spiv> Also, I'm enjoying the new --format=shiny I added to lp:testdoc
[09:34] <vila> spiv: wow, yummy !
[09:35] <vila> spiv: did you try that on the bzr test suite ?
[09:39] <bialix> vila: from past import brlib-2.1 :-P
[09:39]  * bialix hides
[09:39] <vila> bialix: you're so last century :-p
[09:40] <bialix> I'm tired to fix bugs every time some lib updated it's version
[09:40] <bialix> and, yes, I'm
[11:24] <jdobrien> help!
[11:24] <jdobrien> I am having a problem in maverick with bzr
[11:24] <jdobrien> pqm-submit is broken now
[11:24] <jdobrien> which...I need :)
[11:26] <jdobrien> hehe
[11:26] <GaryvdM> jdobrien: What error are you getting
[11:26] <jdobrien> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://None@bazaar.ubunet/)> ignored
[11:26] <jdobrien> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x17088c0> ignored
[11:26] <jdobrien> sorry for the paste
[11:27] <GaryvdM> np
[11:27] <GaryvdM> jdobrien: Seeing If I can reproduce
[11:28] <lifeless> I'm just droppng by after cleaning teeth :P
[11:28] <lifeless> 2.2.1 fixes this
[11:28] <jdobrien> GaryvdM, this is with the latest from bzr
[11:28] <jdobrien> GaryvdM, sorry. i mean latest maverick
[11:28] <lifeless> it shouldn't be harmful for pqm-submit though, just noisy.
[11:28]  * lifeless waves bai
[11:28] <jdobrien> hmm
[11:29] <jdobrien> GaryvdM, oh fiddle-dee dee, lifeless is right. it's still working
[11:29] <jdobrien> now i have queued my job many times :)
[12:25] <jml> I've got a bunch of checkouts in a directory, and I'd like to quickly get some information about their diff from trunk
[12:26] <jml> essentially, I want to do "bzr di -r submit: $checkout | wc -l" for each of them
[12:26] <jml> is there a plugin for this
[12:51] <spiv> jml: not that I know of
[12:51] <spiv> vila: yes, I added --format=shiny to testdoc because I wanted a quick and easy way to get a sense of the tests that were already in a module
[12:51] <jml> spiv, thanks.
[12:51] <jml> I hope vila's bzr-gardener is released someday soon.
[12:51] <spiv> Although I did try it out on bzrlib/tests/test_*.py, and it looked... shiny.  Bit long, though ;)
[12:51] <vila> jml: shudder, me too
[12:52] <vila> jml: but it's in the front of my mind I swear
[12:52] <jml> :)
[12:52] <vila> jml: I even have an emacs opened with an unfinished line of code :-/
[12:53] <vila> spiv: is it visible somehwere ?
[12:55] <spiv> vila: it's visible in your very own terminal!  testdoc --format=shiny bzrlib/tests/test_*.py
[12:55] <vila> spiv: hehe, the next question would have been: 'or is there a one-liner ?' :-D
[12:56] <spiv> vila: it's pretty simple tool.
[13:10] <vila> spiv: hmpf, attributes... emacs.raise ENOTIMPLEMENTED
[13:11] <vila> ha, works better in terminal.... reminds me of gentoo :-P
[13:12] <vila> spiv: err, some text is barely readable, is that deliberate ?
[13:12] <vila> spiv: things like: From Unicode String Ascii Contents
[13:12] <vila>     From Unicode Deprecated
[13:12] <vila>     From Unicode String Unicode Contents
[13:12] <vila>     From Utf8 String
[13:12] <vila>     None
[13:13] <vila> are in so grey so light... it's white :)
[13:13] <vila> spiv: [37;1m
[13:37] <spiv> vila: my terminal has a dark background.
[13:37] <spiv> vila: patches welcome!
[13:37] <vila> hehe
[16:18] <allenap> MemoryTree has no revert() method, WorkingTree does. Does anyone know if this is this intentional or a defect? I tried, briefly, to use TestCaseWithMemoryTree in some Tarmac tests, but Tarmac relies quite heavily on revert. I wondered if I should file a bug.
[16:18] <mgz> this... rings a bell
[16:19]  * mgz seaches list archives
[16:20] <mgz> https://lists.canonical.com/archives/bazaar/2009q3/061426.html
[16:21] <mgz> about merge rather than revert, but "MemoryTrees aren't a complete
[16:21] <mgz> emulation of a WorkingTree
[16:22] <mgz> seems relevent.
[16:22] <mgz> file a bug maybe?
[16:23] <jelmer> alennap: revert and merge both use treetransform underneath
[16:24] <allenap> mgz: If MemoryTree is not intended as a full emulation of WorkingTree then that's enough. I might file a bug to update the docstring though.
[16:24] <james_w> jelmer: revert doesn't does it?
[16:26] <jelmer> james_w: it does, WorkingTree.revert() calls out to bzrlib.transform.revert which uses TreeTransform
[16:30] <allenap> jelmer: I don't have any experience with treetransform. I am fairly inexperienced with bzrlib on the whole. Are you suggesting that I could perform a revert on a MemoryTree using treetransform?
[16:33] <bialix> GaryvdM: ping
[16:33] <jelmer> allenap: Aaron's saying in that email that merge doesn't work for memory tree because there are alternatives (PreviewTree, TransformPreview) for treetransform on memorytree. I merely wanted to clarify that that goes for revert, too.
[16:33] <bialix> GaryvdM: what is your mind on bug #614123?
[16:33] <ubot5`> Launchpad bug 614123 in QBzr 0.19 "Model tests not testing correctly (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/614123
[16:34] <allenap> jelmer: Okay, cool :) Thank you.
[16:34] <jelmer> allenap: Unless you can use PreviewTree/TransformPreview in the code too, it's probably not possible to use TestCaseWithMemoryTree I guess. Perhaps Aaron has suggestions.
[16:34] <allenap> mgz: Thank you too.
[16:37] <allenap> jelmer: I'm okay doing without TestCaseWithMemoryTree. The test suite is fairly small for Tarmac and will remain so for a long while I would imagine, so using on-disk trees is fine for now.
[16:38] <jelmer> allenap: if you're used to the launchpad testsuite everything is fast and small ;-)
[16:38] <allenap> jelmer: Dead right :)
[16:40] <james_w> jelmer: huh, I thought it was implemented separately, thanks
[16:41] <jelmer> it's quite elegant the way it's done.
[17:07] <mgz> gra, annoying bugs.
[17:11] <mgz> erm... jelmer, the email I just sent you probably comes off rather too snarky. what I meant was saying "Don't Do That Then" doesn't seem to be an effective stratgey to dealing with cross platform issues
[17:25] <jelmer> mgz: It didn't come across as particularly snarky but thanks anyway :-)
[18:11] <mgz> is launchpad ignoring email from jam? I see a couple of messages from him that launchpad still doesn't have.
[18:11] <mgz> eg, https://code.launchpad.net/~vila/bzr/323111-backup-names/+merge/35109
[18:13] <vila> mgz: yeah, he voted but forgot to sign and I reply to the mp...
[18:14] <vila> replied
[18:14] <vila> mgz: so launchpad refused his email, but *I* only commented so no sig required
[18:15] <vila> urgh, hopefully the spammers don't read this channel :-}
[18:25] <cody-somerville> vila, if not, I'm sure they google for "hopefully the spammers don't read this" ;p
[18:26] <vila> cody-somerville: ouch: About 794,000 results (0.22 seconds)
[18:26] <vila> cody-somerville: dood luck to them :-D
[18:26] <vila> ghadd good luck, pff, bad luck yeah
[18:28] <mgz> vila, have we got a bug about the babune random failure on bzrlib.tests.per_transport.TransportTests.test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) ?
[18:28] <vila> mgz: spiv filed on upstream
[18:28] <mgz> cool.
[18:28] <vila> mgz: you're talking about the https specific one right ?
[18:28] <mgz> looks like it.
[18:30] <vila> where we get some attribute missing instead of EBADF ?
[18:32] <mgz> yup.
[18:33] <vila> mgz: there is also the infamous error: Socket is closed in lib/python/paramiko/channel.py", line 787, in sendall_stderr
[18:34] <vila> I don't know if we have a bug filed for that, but ISTR that we catch OSError when we should catch socket.error somewhere...
[18:34] <mgz> spiv got that one too though, right? (provided paramiko ever releases a new version)
[18:35] <vila> no, spiv patch is about IPV4 IPV6
[18:35] <vila> the one I mentioned doesn't make any test fail, just a spurious traceback
[18:36] <vila> from a private paramiko thread or do you I mix several ones... haaa, I need to finish something else first :)
[18:36]  * mgz stops distracting vila
[18:37]  * vila is sure mgz has better things to do :-P
[18:37] <mgz> that is also true... :P
[18:41] <GaryvdM> mgz: How much do you know about building vsproj?
[18:41] <GaryvdM> I got an error building tortoisebzr, which I've know idea how to fix :-(
[18:42] <GaryvdM> But I restared my vm, as I'll only be able to pastebin error in about 5 min
[18:42] <mgz> not much unfortunately, I'm not up to date on the tooling changes
[18:43] <GaryvdM> He - I'm sure you know more than me :-)
[18:43] <mgz> paste it when you've got it and I'll see if I can help
[18:44] <GaryvdM> Ok thanks
[18:57] <mgz> 12448KB    31KB/s | Fetching revisions:Inserting stream <- what the hell bzr, this is a one rev change on top of the very latest bzr.dev
[18:58] <mgz> pushing that shouldn't require more than 10MB download
[18:58] <beuno> maybe it's packing
[18:59] <mgz> I'd really rather it didn't.
[19:00] <GaryvdM> beuno: Packing on a pull should not result in extra data being downloaded.
[19:00] <GaryvdM> It dose though on push to a dumb transport.
[19:00] <GaryvdM> mgz: bzr+ssh or http?
[19:01] <mgz> lp: so should be the former, right?
[19:01] <GaryvdM> Only if launchpad-login is set
[19:01] <mgz> it wouldn't let me push to lp:~gz without.
[19:01] <GaryvdM> Yhea
[19:02] <mgz> dammit! it's that same bug I hit before
[19:02] <mgz> what was the workaround...
[19:03] <mgz> (interrupted the first push because it was going sloooow/hung, and trying again does "fetch up to rev {None}")
[19:04] <mgz> ..delete branch via webinterface then push again
[19:04] <GaryvdM> mgz: Oh - this is a push, not a pull
[19:05] <GaryvdM> mgz: did it say it was stacking?
[19:05] <mgz> yeah, but this bug makes it re-download the entire repo. I'd just forgotten I'd done the exact same thing before.
[19:06] <mgz> ...in April.
[19:06] <mgz> https://lists.canonical.com/archives/bazaar/2010q2/068134.html
[19:09] <GaryvdM> vcbuild.exe : error VCBLD0004: Project 'c:\bzr_inst_build\bzr-windows-installers\build-win32\tortoisebzr\bzr-2.2\shellext\tbzrshellext.vcproj' does not contain a configuration called 'Release|x64'.
[19:09] <GaryvdM> http://pastebin.ubuntu.com/491715/
[19:09] <GaryvdM> mgz: ^ and ideas?
[19:10] <mgz> okay, that sounds pretty straightforward
[19:10] <mgz> presumably the vsproj file really doesn't contain an x64 release config
[19:11]  * GaryvdM checks
[19:11] <mgz> so, either the switch /p:Configuration="Release";Platform="x64" needs changing
[19:11] <mgz> or the project file needs to grow an x64 section
[19:14] <GaryvdM> It dose have the x64 platform in the .vcproj
[19:14] <GaryvdM> I think the problem my be that I only have 32bit windows :-(
[19:14] <GaryvdM> *may
[19:15] <mgz> hm...
[19:15] <GaryvdM> I think it tries to build 32bit and 64bit versions of the shellext
[19:16] <GaryvdM> Let me try figure out how to disable the 64 bit version build.
[19:52] <beuno> hrm
[19:52] <beuno> new bzr error for me:
[19:52] <beuno> beuno@beuno-laptop:~/canonical/ubunet/trunk/sourcecode/funambol_cared$ bzr up
[19:52] <beuno> bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-8005'), ('versioning no contents', 'new-8004'), ('versioning no contents', 'new-8008')]
[21:46] <vila> beuno: ouch, sry I was afk (dinner and cooking, yes in that order), did you manage to sort it out ?
[21:47] <beuno> vila, hi!
[21:47] <beuno> yes
[21:47] <vila> beuno: 1) malformed transform is only raised for *bugs*
[21:47] <beuno> I poked it at until it went away
[21:47] <beuno> reverted, updated, yelled
[21:47] <beuno> not sure how I can report this, if it was a bug
[21:47] <vila> it would be nice if you had a recipe to reproduce
[21:48] <vila> beuno: it probably involve setting the same branches/checkout at some revisions... Did you had uncommitted changes ?
[21:49] <vila> beuno: what kind of wt was it ? branch, checkout, light/heavy, bound branch ?
[21:50] <vila> beuno: may be just attaching a good chunk of your .bzr.log could be a good start and shouldn't require too much time
[21:50] <vila> beuno: poking at that we may have direct answers or more precise questions
[21:51] <vila> vila: I try to summarize my thoughts quickly because I won't be long ;)
[21:55] <fullermd> If you have to summarize your thoughts to yourself, I think you WON'T be long   :p
[21:58] <beuno> vila, I can do that
[21:58] <beuno> the branch is ~1gb
[21:58] <beuno> from a private project
[21:59] <beuno> I'll file a bug with logs
[21:59] <beuno> and we can take it from there
[22:08] <vila> beuno: wfm
[22:12] <vila> fullermd: My thoughts are currently focused on my cooking (which I'm not sure you will be offered to taste now (which you will, I'm sure, deeply regret :-P) and let me assure you it smells already very good) and that, trust me, just can't be summarized, no matter how long you thought about it :-D Now go check the parenthesis, summary ! Ha !