[00:55] <poolie> hi all
[04:02] <poolie> hi spiv?
[04:39] <spiv> poolie: hi
[06:19] <poolie> hi there
[06:28] <lifeless> hi
[07:02] <vila> hello poolie !
=== hunger_ is now known as hunger__
=== hunger__ is now known as hunger
[08:00] <jam> morning poolie, good to have you back around
[08:12] <poolie> hi jam, it's good to be back
[08:12] <poolie> i had a great trip
[08:13] <vila> poolie: I was a bit worried you get stuck in Europe due to this other volcano ;)
[08:14] <jam> poolie: I'm curious why you're online at this time, though. Just finishing up your day?
[08:41] <poolie> jam it's 17:40 here, not so late
[08:41] <poolie> i will finish up now though
[08:42] <poolie> vila, no, i came back on my scheduled flight
[08:42] <poolie> good night
[08:42] <jam> poolie: sure, you just didn't say "hi there" until 2 hours ago, and I didn't see you chatting earlier
[08:42] <jam> so I thought that you might have been in a different TZ
[08:42] <jam> I now see that you said high 8 hours ago
[08:42] <jam> hi
[08:45] <vila> poolie: cool, enjoy your evening !
[08:49] <poolie> glad we got that straight :)
[09:22] <temporarytao> hi, can anyone tell me how i can generate a .diff file using bzr and then apply a patch using the diff file?
[09:24] <Kamping_Kaiser> temporarytao: 'bzr diff' and 'patch'?
[09:25] <temporarytao> Kamping_Kaiser, i think that's what i need but just to clarify...
[09:26] <temporarytao> i use diff to create the .diff file by piping the output of 'bzr diff' to a file, right
[09:26] <temporarytao> and then use patch to apply the changes in the file
[09:27] <vila> that should work (expect for binary files, renames and so on)
[09:27] <Kamping_Kaiser> yes. or use merge requests. , bzr help send
[09:27]  * vila nods at Kamping_Kaiser 
[09:28] <Kamping_Kaiser> vila: gday
[09:28] <vila> \o_
[09:29] <temporarytao> thanks!
[09:30] <Kamping_Kaiser> np :)
[09:39] <maxb> poolie: Hello. I was wondering if you happened to know the rationale in lp:~bzr-core/bzr/devnotes being owned by ~bzr-core rather than ~bzr ?
[13:50] <Lo-lan-do> Hi all.  Is it possible to ship a shelve?
[13:50] <Lo-lan-do> Or do a bzr send --uncommitted or so
[14:13] <vila> Lo-lan-do: shelves are supposed to be used locally, there are many different available and well supported ways to ship revisions ;)
[14:15] <Lo-lan-do> The point was not to ship a set of revisions, but an uncommitted patch.
[14:15] <Lo-lan-do> (To a remote box, so bzr merge --uncommitted wouldn't work)
[14:17] <vila> I got that, I'm pointing out that, no, shelves are not meant to be shipped, you can try copying the file under ./bzr/checkout/shelf
[14:18] <vila> but there are cases where you won't be able to use it because it's not *meant* to be used this way
[14:18] <Lo-lan-do> I understand.  I'll do with a simple bzr diff then.
[15:46] <santagada> is there a way to associate two repositories with the same project on launchpad?
[15:46] <gour> santagada: group?
[15:47] <santagada> gour, I wanted to do it with a project
[15:47] <santagada> gour, or do I have to have one project for each repository?
[15:47] <maxb> Sorry to bounce you around, but this question is more rightly discussed on #launchpad
[15:47] <maxb> (I know you were just pointed in this direction)
[15:50] <santagada> I am going to guess this is impossible, it is 1 project 1 repo because there is no docs about this
[16:24] <vila> lamont: ping, did you find a solution for your "AttributeError: 'module' object has no attribute 'trace' " ? (aka bug #788072)
[16:24] <ubot5> Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,Incomplete] https://launchpad.net/bugs/788072
[16:24] <lamont> vila: I did not
[16:24] <vila> :-/
[16:25] <lamont> it's one of those "busy with other things, this is only mildly  annoying so far" things
[16:25] <vila> I see
[16:27] <smoser> hi, i wonder if i can have some help...
[16:27] <smoser> i've got a branch at lp:ubuntu/python-boto
[16:27] <smoser> bzr diff -r tag:1.9b-1..tag:1.9b-1ubuntu5
[16:27] <smoser> shows a bunch of adds and removes or renames
[16:27] <smoser> and the net is that nothing changed
[16:28] <smoser> it was probably user error that created that, but
[16:28] <smoser> (on my part)
[16:28] <smoser> but a.) is there a way to ignore those in a 'bzr diff'
[16:28] <smoser> b.) is there a way that i can get that to happen by default
[16:46] <smoser> i'm willing to muck around with things now to get that fixed in the future
[16:51] <maxb> I don't believe there's any way to get bzr diff to do what you want
[16:52] <maxb> In similar situations I have bzr export-ed both trees and diffed the result.
[16:52]  * maxb grabs the branch to inspect how it arose
[17:01] <maxb> Ah, right. Yes, it was the manner in which you brought in the debian version which has caused this
[17:03] <maxb> smoser: Hmm. I'm tempted to say that the most expedient way to fix it would be to erase the ubuntu branches and have the importer reimport them
[17:03] <maxb> Unless you can think of any other branches which might have history built on top of these
[17:08] <smoser> maxb, probably not.
[17:08] <smoser> at least not that couldn't be ignored.
[17:08] <maxb> smoser: How much to you know about Bazaar file ids?
[17:08] <maxb> s/to/do/
[17:09] <smoser> i know that you just said "Bazaar file ids" and not much more :)
[17:09] <maxb> Hah
[17:09] <maxb> OK, the very quick summary:
[17:09] <maxb> Bazaar tracks the identity of files via an id that is generated when you add it
[17:10] <maxb> This works great most of the time and allows sensible handling of moved files
[17:10] <maxb> However, if the "same" tree is separately imported in two different branches, odd stuff like you can see tends to result
[17:10] <maxb> This is known as a "parallel import"
[17:11] <maxb> There are ways to mitigate this quite a lot, but they are best applied when first merging the two parallel imports - so applying them after 5 ubuntu releases have happened since that merge isn't optimal
[17:12] <maxb> As the only revisions on the branches which are not generated by the importer anyway, are the ones causing the problem, I'm suggesting a reset and reimport
[17:13] <maxb> People who can make this happen are a subset of ~canonical-bazaar folks
[17:13]  * maxb wonders if vila or spiv is around
[17:13] <maxb> or james_w
[17:13] <smoser> yeah, i think that sounds like the best course of action.
[17:13] <james_w> hi maxb
[17:13] <smoser> i'd rather have the tree look sane
[17:14] <james_w> "bzr diff | filterdiff" might hide them :-)
[17:15] <maxb> james_w: Hi. Would you agree with my assessment that if the only non-importer revisions in some UDD branches are a slightly botched parallel import, it's best to delete the branches and restart the import?
[17:15] <james_w> maxb, sounds about right, but today isn't a good day to ask me anything unfortunately
[17:15] <maxb> OK, fair enough. LP question against udd?
[17:15] <vila> I'm busy freezing bzr-2.4b3 but I can run a command on the importer
[17:16] <james_w> maxb, I'm not sure if I receive those or not, so a bug might be better
[17:16] <maxb> ok
[17:17]  * maxb checks delete_branches_from_lp.py syntax
[17:17] <vila> hmm, if this involve running *that* script, yeah a bug to track the process sounds better
[17:17] <maxb> hmm, that could really do with an --ubuntu-only option
[17:19] <maxb> vila: During the sprint, I observed that delete_branches_from_lp.py had local modifications on jubany. Could you have a look at them and commit them if there is nothing confidential involved?
[17:19] <maxb> That way I can put up a MP adding an --ubuntu-only flag without worrying about conflicts
[17:21]  * vila shudders
[17:21] <vila> yeah, I asked for this changes to be committed with the intent triggering them but... never happened
[17:23] <james_w> IIRC the intent was that the current script is completely broken :-)
[17:24] <vila> argh and branches diverged :(
[17:24] <vila> and whoami not set :(
[17:24] <vila> why did I pop up here !
[17:24] <vila> :)
[17:25] <vila> ok,committed
[17:28] <james_w> heh
[17:29] <james_w> thanks vila
[17:34] <maxb> Could I get a requeue_package.py sysvinit too?
[17:34] <maxb> I expect it to fail, but I want to see if the failure reason has changed
[17:34] <vila> no options ?
[17:34] <maxb> no options
[17:35] <mgz> it seems to have been a cyclic day in my absense.
[17:35] <vila> requeued
[17:35] <vila> ha ha ha
[17:43] <mgz> oh, is 2.4b3 being release today?
[17:44] <vila> frozen, not released ;) Don't start rumors will you ?
[17:44] <mgz> ehhee
[17:55] <smoser> maxb, so do you or vila need me to open a bug ?
[17:56] <smoser> sorry, i was away a bit.
[17:56] <vila> hmm, I understood that maxb will open it but I may be wrong
[17:57] <maxb> I was going to open one once I'd had a look at the existing scripts and figured what needs to be done in detail
[17:57] <maxb> However, if you'd like to open one (under launchpad.net/udd) and subscribe me, that works too, and I'll fill in the details later
[17:57] <maxb> Hmm
[17:58] <maxb> Actually, I wonder if we could do it less brutally
[18:00] <maxb> Yes, we don't need to delete all the branches, we could just remove a few revisions
[18:08] <smoser> so you still want a bug ?
[18:32] <mgz> vila: ouch on bug 785098 I wondered why I couldn't repo that
[18:32] <ubot5> Launchpad bug 785098 in Bazaar "bzrlib.tests.test_utextwrap.TestWrap.test_umlaut_followed_by_dash (from ) " [Medium,Confirmed] https://launchpad.net/bugs/785098
[18:32] <vila> see my last comment ? Got sphinx ? Got python test files ?
[18:32] <mgz> yeah, reading it. not having sphinx is why.
[18:32] <smoser> bug 788747 opened
[18:32] <ubot5> Launchpad bug 788747 in bzr (Ubuntu) "requesting diff of one file gives output of all changes" [Undecided,New] https://launchpad.net/bugs/788747
[18:33] <mgz> sphinx are being very naughty.
[18:36] <vila> I've got a fix for them
[18:36] <mgz> are you filing an upstream bug?
[18:37] <vila> yup, in progress, patch missing
[18:40] <fbond> Hi, I just got hit by https://bugs.launchpad.net/bzr/+bug/641330 .
[18:40] <ubot5> Ubuntu bug 641330 in Bazaar "unable to unshelve shelved root-id change" [Low,Confirmed]
[18:40] <fbond> Is there any way to get my shelved content back?
[19:06] <fbond> Maybe I can edit the shelf pack file by hand to remove the root?
[19:15] <fbond> nm, no time for bzr bugs today...
=== deryck[lunch] is now known as deryck
[20:08] <mgz> doh.
[20:08] <mgz> confused by core count detection again.
[20:14] <vila> hmm, wasn't there a patch to rely on python to do that ?
[20:15] <mgz> unless I lie the fork code never gets run on my machine
[20:16] <mgz> because it thinks it knows best based on the fact I only have one cpu
[20:16] <vila> multi-core ? OS ?
[20:17] <mgz> I still need to test that fork works, even on my old machine
[20:17] <mgz> otherwise all you people with fancy new computers will yell at me when my code breaks when you run it
[20:18] <vila> hehe
[20:29] <mgz> bah, this nearly works, there's just an api gap.
[20:29] <maxb> Could I have a "./requeue_package.py --all-of-type xwax" please?
[20:38] <vila> maxb: done
[20:38] <maxb> thanks
[20:39] <maxb> I expect them all to fail, but with new and different tracebacks
[20:39]  * vila returns the thanks ;)
[20:39] <vila> that's a good game
[20:42] <__monty__> How do I start solving a bug, how do I know where to look for the code that's responsible?
[20:43]  * vila blinks
[20:43] <vila> __monty__: in bzr ?
[20:43] <__monty__> Yes.
[20:44] <vila> depends on the bug :) Is it one you encounter yourself or just heard about ?
[20:44] <__monty__> Something I would find on the bug tracker, I don't have a specific bug in mind yet.
[20:45] <vila> ha, hmm
[20:45] <vila> There is no generic answer to such a wide question, there are bugs tagged 'easy' you may want to try first
[20:46] <JFo> or bitesize
[20:46] <vila> https://bugs.launchpad.net/bzr/+bugs?field.tag=easy
[20:46] <vila> hmm, I. not sure we started using bitesize, that's a good idea
[20:48] <JFo> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize&field.tags_combinator=ALL
[20:48] <vila> mgz: do you expect more feedback on https://code.launchpad.net/~gz/bzr/lazy_hook_test_cleanup_785054/+merge/61586 or should we mark it WIP ?
[20:48] <JFo> lots of packages are using it from the look :)
[20:53] <poolie>  /back
[20:53] <poolie> hi jfo, vila, mgz, maxb
[20:54] <maxb> Hello poolie
[20:54] <maxb> I had a question for you - why is ~bzr-core/bzr/devnotes owned by ~bzr-core rather than ~bzr ?
[20:55] <poolie> the short answer is i don't know
[20:55] <poolie> is ~bzr in ~bzr-core or is it vice versa?
[20:56] <maxb> ~bzr is in ~bzr-core
[20:56] <mgz> vila: well, I probably do need some more input, but it can wip till I have some of these other branches landed
[20:56] <mgz> hey poolie!
[20:56] <maxb> So ~bzr-core does mean more people can write - though the vast majority of branches appear to be on ~bzr anyway
[20:57] <maxb> It's all a bit messy
[20:58] <vila> mgz: no, if you need more feedback just put an additional comment
[20:58] <maxb> Ah well. I think I'll get the code review subscriptions issue sorted first, then attack bugmail
[20:58] <vila> poolie: hey !
[20:59] <vila> poolie: my god, you fall from your bed ?
[20:59]  * vila shuckles poor poolie getting remarks at all hours :)
[21:00] <JFo> hi poolie  :)
[21:01]  * JFo was looking at another computer for a bit :)
[21:01] <poolie> i am a bit
[21:01] <vila> hehe
[21:02] <poolie> what's worse is i've been up for a couple of hours
[21:02] <poolie> how are things here?
[21:03] <JFo> not bad
[21:03]  * JFo has a dinner meeting in a few, so will be away
[21:03] <JFo> better get moving now I've looked at the time :-/
[21:06] <poolie> i bet i've already filed a bug asking for a way to subscribe to all code reviews
[21:06] <poolie> vila, how  have you been?
[21:06] <vila> busy ? :D
[21:10] <vila> 2.4b3 frozen, some chroots configured, some bugs fixed, more filed, some PPing (jelmer is away AIUI)
[21:11] <poolie> ah
[21:11] <poolie> yes, we should have rescheduled that
[21:11] <poolie> he is on holidays
[21:11] <vila> .. and still hoping for some reviews on config :-D
[21:11] <poolie> could you officially take it on for tomorrow?
[21:11] <__monty__> I think this is a good bug to start working on: https://bugs.launchpad.net/bzr/+bug/712922
[21:12] <ubot5> Ubuntu bug 712922 in Bazaar "standard way to warn about deprecated parameters" [Medium,Confirmed]
[21:12] <__monty__> However I don't know how to begin.
[21:12] <vila> __monty__: 1) look into bzrlib/symbol_versioning.py and search for the corresponding tests and use cases
[21:13] <vila> 2) start playing with 'bzr selftest -s bt.symbol_versioning'
[21:14] <poolie> hi __monty__
[21:14] <__monty__> hi
[21:14] <poolie> i will try to give you some reviews
[21:14] <vila> 3) write a failing test in bzrlib/tests/test_symbol_versioning.py that will exercise the code you're planning to write
[21:14] <poolie> (you=vila)
[21:14] <poolie> __monty__: are you just looking for some bug to fix?
[21:15] <poolie> there are some tagged easy
[21:15] <poolie> that one should be fairly easy, but involves a bit of metaprogramming
[21:15] <vila> poolie: yeah, np, I was more or less doing it ~officially already
[21:15] <poolie> so depends a bit how much you know python
[21:15] <vila> poolie: great !
=== poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
[21:15] <poolie> vila, jam, do you think https://bugs.launchpad.net/bzr/+bug/602614 is really conclusively fixed?
[21:15] <ubot5> Ubuntu bug 602614 in Bazaar "Out of memory error in _ensure_content on auto repacking" [High,Fix released]
[21:17] <vila> No idea, it was mentioned in the news so I marked it fix released, if there are pending issues, it may be worth filing a new one
[21:17] <vila> new bugs are easier to track for all parties involved (we have bugs opened for too long otherwise)
[21:19] <__monty__> Hmm, I don't know about metaprogramming, maybe I should look for another bug?
=== mwhudson_ is now known as mwhudson
[21:20] <poolie> well, yes
[21:20] <poolie> but that's a pretty popular bug
[21:20] <poolie> so i think it would be a bit pedantic to mark it closed and ask people to move to another
[21:21] <poolie> i will comment
[21:26] <vila> poolie: I see. Sorry, I was a bit rushed while I cut the release (maxb is doing wonders on the package importer and needed a proxy ;)
[21:27] <poolie> np
[21:27] <poolie> really no problem
[21:27] <poolie> it's good to have multiple eyes
[21:27] <poolie> it's just good on hot bugs like this (especially) not to say it's closed when it's not
[21:27] <poolie> but in this case it seems it may well be
[21:32] <vila> hmm, I add a --browser option to checknewsbug.py, in which section should I mention that ? Internals ?
[21:33] <vila> not a major change but interesting for *some* bzr devs :)
[21:33] <__monty__> Maybe this is a better bug to begin with? https://bugs.launchpad.net/bzr/+bug/54624
[21:33] <ubot5> Ubuntu bug 54624 in Bazaar "warn when committing large (binary) files" [Medium,Confirmed]
[21:39] <__monty__> It doesn't sound hard if a file is binary, check the size, if it's bigger than some variable limit, give a warning?
[21:40] <poolie> vila, internals
[21:41] <poolie> or, perhaps better, past to the list
[21:41] <poolie> __monty__: that sounds good
[21:41] <poolie> i wouldn't even bother checking if it's binary
[21:41] <poolie> just if it's more than say 10MB by default, warn
[21:41] <poolie> and ideally take that from a config variable
[21:41] <vila> poolie: the proposal is almost ready, I'll see what reviewers say, no big deal anway
[21:45] <__monty__> poolie: Where should a check like this be? Somewhere in commit.py? And how do I add a config variable?
[21:49] <poolie> __monty__: probably yes, in commit.py
[21:49] <poolie> you should get the wt configuration object
[21:49] <poolie> and then i think just get_user_configuration passing it the name you want
[21:50] <poolie> if you want a really easy one to start https://bugs.launchpad.net/bzr/+bug/364462 would be good
[21:50] <ubot5> Ubuntu bug 364462 in bzr email commit hook "smtp "connection timed out" causes full stack trace to be dumped" [Medium,Confirmed]
[21:51] <jam> poolie: it is not conclusively fixed, but we have more headroom.
[21:51] <jam> I think the ultimate fix is to not read whole files into memory
[21:51] <jam> without that, we'll always have a case where we fail
=== tomaw_ is now known as tomaw
[22:12] <__monty__> poolie: Looking at the traceback (in the bug you suggested) it seems the error should be handled in bzrlib/plugins/email/smtp_connection.py However I don't have the email directory, should I install a certain plugin or is it located somewhere else?
[22:14] <poolie> __monty__: it would be in lp:bzr-email
[22:14] <poolie> however
[22:14] <poolie> there are smtp sending wrappers in bzrlib itself
[22:14] <poolie> i think that's where it should be handled
[22:24] <__monty__> poolie: in smtp_connection.py?
[22:26] <poolie> sounds right
[22:26] <poolie> or possibly in crash.py, just to say this error is never an internal error
[22:38] <__monty__> How can I catch the error from within smtp_connection.py or crash.py?
[22:39] <poolie> _
[22:39] <poolie> __monty__: crash.py has a concept of errors that don't indicate bugs
[22:40] <__monty__> So this should go in crash.py? But how does crash.py know this error occurs?
[22:40] <poolie> hm maybe not crash.py
[22:42] <__monty__> smtp_connection.py then?
[22:42] <poolie> ok, it's report_exception in trace.py
[22:43] <poolie> that has the policy about whether something is a bug (and should get a traceback) or just an environmental or user error
[22:43] <poolie> socket.error is normally an environmental error and should be treated as such
[23:16] <__monty__> Is there a prefered pastebin for this channel?
[23:24] <__monty__> poolie: Would this be enough for a fix? http://pastebin.com/uxh5u0ag
[23:26] <poolie> that's almost it
[23:27] <poolie> but socket.error can mean many other things than just a timeout
[23:27] <poolie> you need to get a string about the particular error
[23:27] <ironcamel> anybody got bzr bisect installed and got it to work?
[23:28] <poolie> yes, i have
[23:28] <poolie> what's wrong?
[23:41] <poolie> __monty__: how's it going?
[23:42] <poolie> probably just printing the str form of the excepiton would be a good start
[23:42] <poolie> ideally we would also include something about just which host we were failing to connect to
[23:42] <poolie> i don't know if socket.error includes that
[23:42] <__monty__> I'm still trying to find out how to get the string :s
[23:42] <poolie> str(e) should do it
[23:43] <poolie> the default exception-reporting thing should print that probably
[23:43] <poolie> so you may notneed to specify anything special
[23:45] <__monty__> What do you mean by the default exception-reporting thing, report_user_error()?
[23:45] <poolie> yes
[23:47] <__monty__> Should I pass an advice parameter to report_user_error() or is this fix meant to handle every socket.error?