poolie | hi all | 00:55 |
---|---|---|
poolie | hi spiv? | 04:02 |
spiv | poolie: hi | 04:39 |
poolie | hi there | 06:19 |
lifeless | hi | 06:28 |
vila | hello poolie ! | 07:02 |
=== hunger_ is now known as hunger__ | ||
=== hunger__ is now known as hunger | ||
jam | morning poolie, good to have you back around | 08:00 |
poolie | hi jam, it's good to be back | 08:12 |
poolie | i had a great trip | 08:12 |
vila | poolie: I was a bit worried you get stuck in Europe due to this other volcano ;) | 08:13 |
jam | poolie: I'm curious why you're online at this time, though. Just finishing up your day? | 08:14 |
poolie | jam it's 17:40 here, not so late | 08:41 |
poolie | i will finish up now though | 08:41 |
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:42 |
vila | poolie: cool, enjoy your evening ! | 08:45 |
poolie | glad we got that straight :) | 08:49 |
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:22 |
Kamping_Kaiser | temporarytao: 'bzr diff' and 'patch'? | 09:24 |
temporarytao | Kamping_Kaiser, i think that's what i need but just to clarify... | 09:25 |
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:26 |
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:27 | |
Kamping_Kaiser | vila: gday | 09:28 |
vila | \o_ | 09:28 |
temporarytao | thanks! | 09:29 |
Kamping_Kaiser | np :) | 09:30 |
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 ? | 09:39 |
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 | 13:50 |
vila | Lo-lan-do: shelves are supposed to be used locally, there are many different available and well supported ways to ship revisions ;) | 14:13 |
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:15 |
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:17 |
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. | 14:18 |
santagada | is there a way to associate two repositories with the same project on launchpad? | 15:46 |
gour | santagada: group? | 15:46 |
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:47 |
santagada | I am going to guess this is impossible, it is 1 project 1 repo because there is no docs about this | 15:50 |
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:24 |
lamont | it's one of those "busy with other things, this is only mildly annoying so far" things | 16:25 |
vila | I see | 16:25 |
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:27 |
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:28 |
smoser | i'm willing to muck around with things now to get that fixed in the future | 16:46 |
maxb | I don't believe there's any way to get bzr diff to do what you want | 16:51 |
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 | 16:52 | |
maxb | Ah, right. Yes, it was the manner in which you brought in the debian version which has caused this | 17:01 |
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:03 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
james_w | "bzr diff | filterdiff" might hide them :-) | 17:14 |
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:15 |
james_w | maxb, I'm not sure if I receive those or not, so a bug might be better | 17:16 |
maxb | ok | 17:16 |
* 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:17 |
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:19 |
* vila shudders | 17:21 | |
vila | yeah, I asked for this changes to be committed with the intent triggering them but... never happened | 17:21 |
james_w | IIRC the intent was that the current script is completely broken :-) | 17:23 |
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:24 |
vila | ok,committed | 17:25 |
james_w | heh | 17:28 |
james_w | thanks vila | 17:29 |
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:34 |
mgz | it seems to have been a cyclic day in my absense. | 17:35 |
vila | requeued | 17:35 |
vila | ha ha ha | 17:35 |
mgz | oh, is 2.4b3 being release today? | 17:43 |
vila | frozen, not released ;) Don't start rumors will you ? | 17:44 |
mgz | ehhee | 17:44 |
smoser | maxb, so do you or vila need me to open a bug ? | 17:55 |
smoser | sorry, i was away a bit. | 17:56 |
vila | hmm, I understood that maxb will open it but I may be wrong | 17:56 |
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:57 |
maxb | Actually, I wonder if we could do it less brutally | 17:58 |
maxb | Yes, we don't need to delete all the branches, we could just remove a few revisions | 18:00 |
smoser | so you still want a bug ? | 18:08 |
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:32 |
mgz | sphinx are being very naughty. | 18:33 |
vila | I've got a fix for them | 18:36 |
mgz | are you filing an upstream bug? | 18:36 |
vila | yup, in progress, patch missing | 18:37 |
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? | 18:40 |
fbond | Maybe I can edit the shelf pack file by hand to remove the root? | 19:06 |
fbond | nm, no time for bzr bugs today... | 19:15 |
=== deryck[lunch] is now known as deryck | ||
mgz | doh. | 20:08 |
mgz | confused by core count detection again. | 20:08 |
vila | hmm, wasn't there a patch to rely on python to do that ? | 20:14 |
mgz | unless I lie the fork code never gets run on my machine | 20:15 |
mgz | because it thinks it knows best based on the fact I only have one cpu | 20:16 |
vila | multi-core ? OS ? | 20:16 |
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:17 |
vila | hehe | 20:18 |
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:29 |
vila | maxb: done | 20:38 |
maxb | thanks | 20:38 |
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:39 |
__monty__ | How do I start solving a bug, how do I know where to look for the code that's responsible? | 20:42 |
* vila blinks | 20:43 | |
vila | __monty__: in bzr ? | 20:43 |
__monty__ | Yes. | 20:43 |
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:44 |
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:45 |
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:46 |
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:48 |
poolie | /back | 20:53 |
poolie | hi jfo, vila, mgz, maxb | 20:53 |
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:54 |
poolie | the short answer is i don't know | 20:55 |
poolie | is ~bzr in ~bzr-core or is it vice versa? | 20:55 |
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:56 |
maxb | It's all a bit messy | 20:57 |
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:58 |
vila | poolie: my god, you fall from your bed ? | 20:59 |
* vila shuckles poor poolie getting remarks at all hours :) | 20:59 | |
JFo | hi poolie :) | 21:00 |
* JFo was looking at another computer for a bit :) | 21:01 | |
poolie | i am a bit | 21:01 |
vila | hehe | 21:01 |
poolie | what's worse is i've been up for a couple of hours | 21:02 |
poolie | how are things here? | 21:02 |
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:03 |
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:06 |
vila | 2.4b3 frozen, some chroots configured, some bugs fixed, more filed, some PPing (jelmer is away AIUI) | 21:10 |
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:11 |
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:12 |
vila | 2) start playing with 'bzr selftest -s bt.symbol_versioning' | 21:13 |
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:14 |
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 ! | 21:15 |
=== 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 | ||
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:15 |
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:17 |
__monty__ | Hmm, I don't know about metaprogramming, maybe I should look for another bug? | 21:19 |
=== mwhudson_ is now known as mwhudson | ||
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:20 |
poolie | i will comment | 21:21 |
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:26 |
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:27 |
vila | hmm, I add a --browser option to checknewsbug.py, in which section should I mention that ? Internals ? | 21:32 |
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:33 |
__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:39 |
poolie | vila, internals | 21:40 |
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:41 |
__monty__ | poolie: Where should a check like this be? Somewhere in commit.py? And how do I add a config variable? | 21:45 |
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:49 |
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:50 |
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 | 21:51 |
=== tomaw_ is now known as tomaw | ||
__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:12 |
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:14 |
__monty__ | poolie: in smtp_connection.py? | 22:24 |
poolie | sounds right | 22:26 |
poolie | or possibly in crash.py, just to say this error is never an internal error | 22:26 |
__monty__ | How can I catch the error from within smtp_connection.py or crash.py? | 22:38 |
poolie | _ | 22:39 |
poolie | __monty__: crash.py has a concept of errors that don't indicate bugs | 22:39 |
__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:40 |
__monty__ | smtp_connection.py then? | 22:42 |
poolie | ok, it's report_exception in trace.py | 22:42 |
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 | 22:43 |
__monty__ | Is there a prefered pastebin for this channel? | 23:16 |
__monty__ | poolie: Would this be enough for a fix? http://pastebin.com/uxh5u0ag | 23:24 |
poolie | that's almost it | 23:26 |
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:27 |
poolie | yes, i have | 23:28 |
poolie | what's wrong? | 23:28 |
poolie | __monty__: how's it going? | 23:41 |
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:42 |
poolie | the default exception-reporting thing should print that probably | 23:43 |
poolie | so you may notneed to specify anything special | 23:43 |
__monty__ | What do you mean by the default exception-reporting thing, report_user_error()? | 23:45 |
poolie | yes | 23:45 |
__monty__ | Should I pass an advice parameter to report_user_error() or is this fix meant to handle every socket.error? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!