dobey | james_w: but the commit() call that tarmac is making, is passing committer='Tarmac' as an argument | 00:19 |
---|---|---|
dobey | it was working fine before i upgraded to 2.2.0 today | 00:19 |
mkanat | Is "bzr send" using a "mailto" url or something? | 00:21 |
mkanat | Not all MUAs support all the mailto query parameter extensions. | 00:21 |
thumper | it worked fine in kde, just not gnome | 00:22 |
thumper | probably a weird setting | 00:22 |
mkanat | Ahh, yeah. | 00:23 |
spiv | Good morning. | 00:47 |
poolie | hi there spiv | 00:48 |
jam | mkanat: just a note, the primary in-memory cache is brought down to disk in trunk with the bzr-history-db work | 00:50 |
jam | hi spiv | 00:50 |
mkanat | jam: Yeah, that's the primary thing that makes this possible. | 00:50 |
mkanat | jam: But the revision cache is still in memory, IIRC. | 00:50 |
jam | mkanat: it is, but it isn't as necessary | 00:50 |
* mkanat nods. | 00:51 | |
jam | ISTR there are times when it is useful | 00:51 |
jam | we would have to check | 00:51 |
mkanat | Yeah, there are times we have to map revids to revnos in a loop, IIRC. | 00:51 |
jam | we could push harder on moving it to disk if we had to | 00:51 |
mkanat | jam: I think that's probably what we'll do. | 00:51 |
jam | short-term denormalization of a given table | 00:51 |
mkanat | jam: But that won't work in the codehosting situation, will it? Because we can't write to the disk. | 00:52 |
jam | we can | 00:52 |
jam | it already does | 00:52 |
mkanat | Ah, okay. | 00:52 |
james_w | dobey: well, that's when the error was added, so that's no surprise | 01:13 |
james_w | dobey: is test_branch a file you have added? | 01:19 |
james_w | dobey: and in your pastebin "a_branch.tree.commit("Reading, 'riting, 'rithmetic")" doesn't look like it is passing committer= | 01:20 |
mtaylor | if I don't want to re-branch - is there a way to migrate a standalone branch to one inside of a shared repo? | 02:14 |
fullermd | reconfigure | 02:14 |
mtaylor | fullermd: heh. that's too easy | 02:15 |
fullermd | Oh. Well, the Seven Trials of Courage, climbing the North Face of the Eiger, _then_ reconfigure. | 02:16 |
mtaylor | fullermd: excelent. that's better | 02:17 |
fullermd | Anything for a steady customer :p | 02:19 |
mkanat | poolie: I should be able to get to Loggerhead stuff by the end of the week. But if there's something that you need more urgently than that, please let me know. | 02:31 |
poolie | mkanat: nothing springs to mind, i'd just suggest talking to chex or spm or similar if you see them online | 03:00 |
mkanat | poolie: All right. :-) | 03:00 |
=== Ursinha is now known as Ursinha-afk | ||
spiv | poolie: what's the process for getting 2.1.2 into lucid-updates? There have been quite a few dupes of bug 559436, and it just bit Mary... | 05:47 |
ubot5 | Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436 | 05:47 |
lifeless | spiv: read all about it on the stable release update pacge | 05:52 |
poolie | spiv, or see my previous mail about srus | 06:09 |
mtaylor | lifeless: all of the web pages say bzr-hg is under heavy dev ... is it usable for day to day? or will I have less pain with just plain hg? | 06:20 |
lifeless | mtaylor: we use it in prod to import hg on lp.net. | 06:22 |
lifeless | mtaylor: go figure :P | 06:22 |
mtaylor | lifeless: oh - well, that's something then :) | 06:22 |
mtaylor | lifeless: there doesn't seem to be a _great_ way to figure out what form a url should take... can you recommend any help I should look at? or should I just read the source? | 06:22 |
lifeless | http:// ? | 06:23 |
lifeless | I dunno | 06:23 |
mtaylor | lifeless: hah! I was trying to make it much harder - doing hg+http :) | 06:24 |
mtaylor | lifeless: thanks | 06:24 |
spiv | poolie: On reflection I think what I really meant to ask was "why didn't 2.1.2 get proposed as an SRU more-or-less when it was released?" Ideally we'd have proposed it already given the severity/frequency of that bug I think. | 06:59 |
poolie | i don't think there's any good answer | 07:11 |
poolie | we should have | 07:11 |
poolie | the make-a-release chain is already pretty long | 07:11 |
spiv | *nod* | 07:20 |
spiv | Actually, looking at my mail, lifeless said he was about to propose 2.1.2 as an SRU for lucid the day 2.1.2 released. :P | 07:27 |
lifeless | I may have done so even. | 07:29 |
spiv | Hmm, I wonder where it is then... | 07:30 |
lifeless | https://bugs.edge.launchpad.net/ubuntu/+source/bzr needs some love | 07:31 |
spiv | Yeah, I was just noticing that :( | 07:32 |
spiv | https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/bzr/2.1.2-sru | 07:33 |
spiv | linked to bug 528041 | 07:33 |
ubot5 | Launchpad bug 528041 in Bazaar 2.2 "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 21, heat: 136)" [High,Fix released] https://launchpad.net/bugs/528041 | 07:33 |
lifeless | there you go | 07:33 |
lifeless | I was about to claim that I sucked | 07:33 |
spiv | So where in the SRU process did that get stalled? | 07:35 |
lifeless | probably the usual place : the start | 07:35 |
* lifeless takes off the bitter hat | 07:35 | |
spiv | Heh. | 07:35 |
spiv | Well, it looks like we got past step 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure :P | 07:36 |
spiv | lifeless: so my reading of the SRU page says the next thing that needs to happen is someone needs upload the package to lucid-proposed. Does that sound right to you, and can you do that? | 07:44 |
lifeless | AIUI no | 07:45 |
lifeless | ww haven't set up per-package uploads for bzr and its in main | 07:46 |
spiv | So we should subscribe ubuntu-sponsors to the bug to find a sponsor? | 07:48 |
poolie | probably | 07:48 |
poolie | you may need to nag someone | 07:48 |
cody-somerville | I'll sponsor it. | 07:51 |
spiv | cody-somerville: thanks! | 07:52 |
cody-somerville | Does bzr have an exception from the TB to push entire new releases via -updates? | 07:55 |
lifeless | cody-somerville: no, and we're not asking for that | 07:55 |
lifeless | cody-somerville: these point releases are managing in an SRU way upstream | 07:55 |
poolie | cody-somerville: if this is from 2.1.1 to 2.1.2 the changes should be compatible with the sru criteria | 07:55 |
poolie | safe fixes for important bugs | 07:55 |
spiv | This is from 2.1.1 to 2.1.2 | 07:57 |
cody-somerville | 47 files changed, 2926 insertions(+), 2331 deletions(-) | 07:57 |
lifeless | noooo | 07:58 |
lifeless | its either very mechanical, or something confused in udd | 07:58 |
spiv | A heap of that is noise from Pyrex-generated C, I suspect. | 07:59 |
lifeless | bzr diff -r bzr-2.1.1..bzr-2.1.2 | diffstat | 07:59 |
lifeless | 34 files changed, 717 insertions(+), 160 deletions(-) | 07:59 |
lifeless | cody-somerville: ignore the .c files, they are autogenerated - equivalent to configure | 08:00 |
spiv | Heh, yep, lots of /home/mbp/ became /home/robertc/ in Pyrex-generated comments in the C. | 08:00 |
lifeless | we should probably add some sed in there | 08:01 |
poolie | urk | 08:04 |
cody-somerville | Generally an SRU is as minimal as possible to fix a single specific bug. Some packages like landscape have permission from the TB to push point releases like this into -updates. Considering bzr's testsuite, you guys should probably ask for the same exception. In the mean time, is there a minimal diff I can upload? If not, I'd recommend pinging someone from the SRU team to get permission as to avoid doing something that'll end up being | 08:05 |
cody-somerville | rejected. | 08:05 |
poolie | hm | 08:05 |
poolie | we have done previous SRUs on similar changes | 08:05 |
spiv | It sounds like it would be good to get formal permission from the TB just to expedite the process? I know we've had point release SRUs go through before, but IIRC also with some to-and-fro about whether they really satisfy the letter of the SRU policy or not. | 08:08 |
* cody-somerville nods. | 08:08 | |
poolie | ok | 08:08 |
spiv | Expedite the process in future, anyway, perhaps not expedite this particular SRU ;) | 08:08 |
poolie | so in the interim, do you want to merge the patch just for this change? | 08:09 |
poolie | i find it a bit hard to believe that will be much safer but i understand the general process | 08:09 |
cody-somerville | Its up to you guys. I was hoping this was just a quick patch that I could do real quick before heading off to bed. | 08:09 |
cody-somerville | If you want you can get approval from SRU board and I can upload when I wake up if you haven't found someone else to sponsor it by then | 08:10 |
spiv | poolie: well, the linked bug is for the siginterrupt issue, which is definitely good to have fixed, but the bug that triggered me asking about SRUs was bug 559436... | 08:10 |
ubot5 | Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436 | 08:10 |
poolie | cody-somerville: and how do we get that approval? | 08:10 |
cody-somerville | subscribe ubuntu-sru team | 08:11 |
cody-somerville | and then possibly poke someone on the team | 08:11 |
poolie | spiv, can you do that? | 08:20 |
* bialix waiting for Garyvdm | 08:36 | |
poolie | hi bialix | 08:37 |
bialix | hi poolie ! | 08:37 |
=== oubiwann is now known as oubiwann-away | ||
spiv | poolie: sure | 08:46 |
spiv | (The team was already subscribed to that bug as per the procedure on the SRU wiki page, but I'll find and poke someone on it) | 08:48 |
=== oubiwann-away is now known as oubiwann | ||
poolie | spiv, so re https://bugs.edge.launchpad.net/launchpad/+bug/615740 | 08:49 |
ubot5 | Launchpad bug 615740 in Launchpad itself "test_on_merge.py doesn't handle eintr (affected: 1, heat: 6)" [Undecided,New] | 08:49 |
poolie | what the best plan for handling eintr now? | 08:49 |
poolie | such a saga... | 08:49 |
=== oubiwann is now known as oubiwann-away | ||
=== oubiwann-away is now known as oubiwann | ||
spiv | poolie: depends! | 09:02 |
poolie | so there's one select call that's failing | 09:03 |
spiv | poolie: don't have any signal handlers is a good plan, if you can | 09:03 |
poolie | oddly, raising select.error not IOError | 09:03 |
spiv | poolie: if you can't, register it with signal.siginterrupt is good, if you can assume python >= 2.6.6 | 09:04 |
spiv | if you can't do that (you do want the signal to interrupt syscalls, or you can't assume 2.6.6), then your options are less good. | 09:05 |
spiv | select at least is safe to retry the call, if it's happening in your own code. | 09:05 |
poolie | i think it is | 09:05 |
poolie | i don't know if lp assumes 2.6.6 yet? | 09:06 |
poolie | probably not | 09:06 |
spiv | Given that 2.6.6rc1 only just hit maverick, I doubt it :) | 09:08 |
spiv | Ok, I need to wind up for the day, but at least I have code that makes 'bzr reconcile' fix non-canonical CHKs now. | 09:10 |
poolie | yay | 09:14 |
dakira | hi.. how do I get only a list of modified/added files for the last few commits? | 10:03 |
luks | dakira: bzr st -r -3 (last two commits) | 10:22 |
dakira | luks: great.. thx! | 10:42 |
=== khmarbaise__ is now known as khmarbaise | ||
fullermd | Note the difference between "-r-3" (compare rev -3 to the current working tree status) and "-r-3.." (compare rev -3 to the latest commit) | 10:44 |
dakira | fullermd: so "-r -3" == "-r-3.."? | 10:46 |
fullermd | No, "-r-3" == "-r-3"... I don't think there's any long form. "-r-3.." == "-r-3..-1" | 10:46 |
dakira | fullermd: look closely... not "-r-3" but "-r<space>-3".. the latter seems to be equivalent to "-r-3.." | 10:47 |
luks | "-r-3.." != "-r-3..-1" because the range is exclusive | 10:47 |
fullermd | They're the same thing, space or not. | 10:47 |
fullermd | Standard option parsing. | 10:48 |
fullermd | Er, -r-3.. IS exactly the same as -r-3..-1. Open ended ranges go to the end of the tree. | 10:48 |
luks | then my bzr is doing something wrong :) | 10:48 |
fullermd | (well, mod some bugs that have existed in the past with parsing them at least) | 10:48 |
luks | oh | 10:49 |
luks | my bad | 10:49 |
luks | it's sorted differently | 10:49 |
luks | I wonder why -r-3..-1 isn't sorted | 10:50 |
fullermd | Any other day, I'd say "I dunno". Today, the answer is obviously "the world is out to get me". | 10:52 |
dakira | luks: hm.. -r-3.. and -r-3 give me the same results (they compare with the working tree) while -r-3..-1 compares with the last commited revision! | 10:54 |
* fullermd frowns. | 10:54 | |
fullermd | That's... unexpected. | 10:54 |
spiv | I occasionally think that -0 should mean "working tree". | 10:55 |
fullermd | I'd rather have a tree: or something. | 10:55 |
spiv | Then I go have a nice cup of tea in a quiet corner somewhere and reason returns ;) | 10:56 |
fullermd | Well, I do see that listed behavior. I'm pretty sure it used to be like I think it is, so I presume it was changed intentionally... I don't think I like it though. | 10:56 |
fullermd | spiv: Really, it should be "+1" ;p | 10:57 |
spiv | fullermd: no, 0 comes after -1 | 10:57 |
spiv | fullermd: and the uncommitted working tree is the nearest thing we have to the next revision after the most recently committed one... | 10:57 |
fullermd | Yes, but 0 is already taken for null. Anyway, we want to go one rev forward from the current state, so... | 10:57 |
spiv | Right, hence -0 ;) | 10:57 |
fullermd | Of course, since it's not committed yet, it's not real. So, it should be 'i'. | 10:58 |
fullermd | Unless, of course, we steal the imaginary axis to be the timeline along which we allow editing commit logs... | 10:58 |
* fullermd goes off and hides. | 10:58 | |
spiv | $\lim_{revno\to 0}revision(revno)$ | 11:01 |
dakira | fullermd: here's what I get http://pastebin.com/NvRWeNWq | 11:01 |
spiv | Or something. | 11:01 |
* spiv wanders off | 11:01 | |
dakira | bzr is 2.1.1 | 11:02 |
=== Ursinha-afk is now known as Ursinha | ||
=== oubiwann is now known as oubiwann-away | ||
=== oubiwann-away is now known as oubiwann | ||
dobey | james_w: a_branch is a tarmac.Branch, and its commit method calls the bzr commit with committer='Tarmac' | 14:15 |
james_w | dobey: ok, given that I can't see this code I'll have to take your word for it. Also given that I can't see it I can't help you debug it any more. | 14:16 |
dobey | http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/head%3A/tarmac/branch.py | 14:23 |
dobey | http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/206/tarmac/tests/test_branch.py#L40 | 14:24 |
bialix | ddaa: hello | 14:25 |
ddaa | hey bialix | 14:25 |
dobey | i'm trying to get those tests back in trunk and working again. and i almost had it. the commit() worked fine yesterday morning, and the started failing after i ran update-manager and bzr got upgraded to 2.2.0 | 14:25 |
=== oubiwann is now known as oubiwann-away | ||
=== oubiwann-away is now known as oubiwann | ||
james_w | dobey: I don't know. It seems to pass it down ok, but it clearly uses it, you might want to pdb and find out at what level it loses it. | 14:37 |
dobey | yeah, i went hunting through the code path from the stack trace last night and didn't see anything obvious in the code :-/ | 14:41 |
* jelmer waves to james_w, dobey | 14:42 | |
james_w | hi jelmer | 14:42 |
dobey | hi jelmer | 14:42 |
dobey | ah, how the little things can wreck havoc | 15:03 |
dobey | a_branch.*tree*.commit() is not a_branch.commit(). sorry :) | 15:08 |
jelmer | hehe | 15:09 |
jelmer | been there, done that.. with the exact same method. | 15:09 |
dobey | with commit --fixes in bzr, does it store the url as lp:NUM or http://bugs.launchpad.net/bugs/NUM ? or something else? | 15:28 |
jelmer | dobey, the latter | 15:28 |
jelmer | dobey: see also "bzr cat-revision", that will dump the raw representation of a revision | 15:29 |
dobey | ah | 15:29 |
dobey | thanks | 15:30 |
=== deryck is now known as deryck[lunch] | ||
abentley | Anyone have a suggestion on how to debug InvalidUseOfScopeReplacer in the Launchpad test suite, when the test, run by itself, doesn't cause it? | 15:49 |
abentley | I've been trying to backtrack to find the test that is abusing the scope replacer, but so far no dice. | 15:49 |
mgz | nope, 's one of the oddities I've run into before and not had time to track down. | 15:53 |
mgz | a bunch of the doctests fall over with it on ironpython and jython. | 15:54 |
abentley | mgz, with the Launchpad test suite or the bzr test suite? | 15:54 |
mgz | in bzr, sorry. | 15:54 |
Typh | If I push to a location, why would then running bzr update in that location produce "bzr: ERROR: No WorkingTree exists" | 16:36 |
GaryvdM | jam: For some reason, paramiko is no longer being included in libary.zip | 16:36 |
jam | hmmm. I wonder if it got installed as a plain .egg | 16:36 |
jam | .egg doesn't work with py2exe | 16:37 |
GaryvdM | Typh: If you push to a remote location, working trees are not created. | 16:37 |
GaryvdM | jam: Yes - It is installed as an .egg | 16:37 |
GaryvdM | Typh: you can create the working tree by running bzr checkout | 16:37 |
Typh | GaryvdM: oh. oops :D. thanks. | 16:38 |
GaryvdM | Typh: and if you push to a remote location that allready has a working tree, it will then be out of date, and will need a bzr update | 16:38 |
GaryvdM | Typh: This is due to limitations in the remote protocols. | 16:39 |
bialix | heya Gary! | 16:39 |
GaryvdM | Hi bialix | 16:39 |
bialix | did you saw my messages? | 16:40 |
GaryvdM | bialix: Yes - was just going to reply. | 16:40 |
rubbs | Typh: also, if you are pushing to a remote location just to update files for say a webserver, you may want to look at some plugins like push-and-update. I'll see if I can dig up relevant links | 16:40 |
bialix | ok | 16:40 |
Typh | rubbs: no no, I was just trying to recreate a borked checkout on the server. I've never had to push a brand new copy anywhere before :) | 16:41 |
rubbs | Typh: ah, cool. Just checking. | 16:41 |
GaryvdM | bialix: Surely there is a syntax that will work for both versions. I'll take a look. | 16:41 |
=== Ursinha is now known as Ursinha-afk | ||
jam | GaryvdM: I'll log in now and try to fix that | 16:46 |
jam | GaryvdM: I needed to do "python setup.py install -O1 easy_install -O1 -Z" to get it to not install using an egg | 16:51 |
GaryvdM | bialix: Please could you see if this runs with pyqt4.4: http://pastebin.org/466026 | 16:51 |
bialix | GaryvdM: with your patch test suite did not errored, but tests failed | 16:56 |
=== deryck[lunch] is now known as deryck | ||
jam | GaryvdM: it should be fixed now, care to try again? | 16:56 |
GaryvdM | jam: Thanks | 16:56 |
GaryvdM | bialix: Please pastebin test output. | 16:57 |
bialix | GaryvdM: that paste writes success, but is it really success? | 16:57 |
=== Ursinha-afk is now known as Ursinha | ||
GaryvdM | bialix: Yhea - need to check that it's actually connected.... | 16:58 |
bialix | GaryvdM: http://pastebin.org/466035 | 16:58 |
GaryvdM | bialix: I think that previously, the connections in that test were not connecting, and the are now, and exposing bugs in the test. | 17:10 |
bialix | ouch! | 17:11 |
GaryvdM | Funny that they are connecting in qt 4.4, and not 4.6/4.7. | 17:11 |
=== beuno is now known as beuno-lunch | ||
bialix | GaryvdM: I would like to add direct support of colo in qbzr. E.g for commands qswitch, qmerge, maybe others | 17:16 |
bialix | there is custom qswitch in the explorer to understand colo, but I think we can do better in qbzr | 17:16 |
* bialix off to home, bbl | 17:18 | |
CcxCZ | is there way to bind branch multiple times? | 17:29 |
GaryvdM | jam: Thanks - that worked. | 17:33 |
GaryvdM | jam: Is there an easy to test the speed of paramiko? I'd like to see if my patch makes it faster. | 17:34 |
jam | GaryvdM: I don't know of any specific way. I assume trying to do an ssh loopback and see how fast you can transmit bytes | 17:34 |
jam | I don't really know how to set that up, though | 17:34 |
GaryvdM | ok | 17:35 |
jam | probably you could do something with a loopback to openssh via sftp, and just try to read a 1GB file | 17:35 |
jam | or ssh localhost dd if=/dev/urandom | 17:35 |
jam | or something like that | 17:35 |
jam | you could do /dev/zero because it is fast, but I think the channel auto-compresses, and that compresses a bit too well :) | 17:36 |
CcxCZ | doesn't urandom wait for entropy? | 17:37 |
jam | CcxCZ: I thought /dev/random did and /dev/urandom layered cryptographic randomness on top of entropy | 17:37 |
jam | psuedorandomness | 17:37 |
CcxCZ | A read from the /dev/urandom device will not block waiting for more entropy. | 17:38 |
* CcxCZ RTFMed | 17:38 | |
fullermd | Yeah, it's the other way around. urandom doesn't block; random does. | 17:38 |
CcxCZ | though that's not very good for benchmark I guess | 17:39 |
jam | GaryvdM: if you don't mind working through the bzrlib api, you could probably just use "t = bzrlib.transport.get_transport('sftp://localhost/...'); t.get_bytes()" | 17:40 |
jam | That handles all of the "how do I set up paramiko" stuff :) | 17:40 |
GaryvdM | jam: I specifically want to see if I'v removed the "1-2 seconds" that you mention in Bug 271791 | 17:41 |
ubot5 | Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 3, heat: 17)" [Medium,Triaged] https://launchpad.net/bugs/271791 | 17:41 |
jam | GaryvdM: well that is easy to tell | 17:41 |
jam | bzr log sftp://host | 17:41 |
jam | we've patched pycrypto repeatedly for that IIRC | 17:41 |
jam | however, you also have to have a system where time.time()'s resolution is 15ms | 17:42 |
jam | 1ms is fast enough to not really notice 100 calls. | 17:42 |
jam | 1ms == 100ms total, 15ms == 1.5s total, very noticeable | 17:42 |
jam | you can do a loop on time.time() to determine the resolution | 17:42 |
CcxCZ | anyway I guess there isn't simple way synching multiple branches at once. As I look in .bzr/branch/branch.conf, there can be only one bound branch. | 17:43 |
GaryvdM | jam: I have 1ms time.time() resolution, so I guess I won't be able to test. | 17:44 |
jam | GaryvdM: well, IIRC 'import paramiko' triggered it, you could see if it takes 100ms to do so. | 17:45 |
jam | However, I'm pretty sure that code doesn't exist in pycrypto 2.1+ | 17:45 |
jam | They, at least, rejected my patch for it on the basis that you shouldn't be using that code anywy | 17:45 |
* GaryvdM going to get food, while I wait for my build to download. | 17:47 | |
dobey | i'm not overly familiar with bzrlib, but i need some help with getting revision properties out of the revisions from one branch that are being merged into another | 17:59 |
CcxCZ | dobey: can you elaborate on that? | 18:01 |
dobey | i have one branch that has some revisions, with multiple revisions where one revision has a bug fix, but the last revision does not for example | 18:02 |
dobey | and when i merge that branch into another, i need to get all the bugs revision properties for all the revisions that are being merged in | 18:03 |
dobey | but it's not clear to me how to do that exactly | 18:03 |
dobey | i can get properties from the last revision, but it's not clear to me how to get them for all of the revisions which are being merged | 18:08 |
GaryvdM | dobey: Maybe take a look at what bzr missing does. | 18:11 |
GaryvdM | debey: It will involve some graph call, which, I'm not sure. | 18:12 |
GaryvdM | dobey: If you look at bzrlib.missing._find_unmerged , It's quite clear. | 18:16 |
GaryvdM | Instead if the remote_branch.last_revision_info(), use the last revision that you used when you looked at the branch. | 18:17 |
GaryvdM | dobey: You can also look at the revisons that have been removed from branch using uncommit, or pull/push --overwrite | 18:18 |
=== beuno-lunch is now known as beuno | ||
abentley | jam, I'm trying to debug an InvalidUseOfScopeReplacer in the Launchpad test suite. Unfortunately, it's not clear what test is actually misbehaving the tests that raise it run fine by themselves. | 18:23 |
abentley | jam, do you have any suggestion how to debug it? | 18:24 |
dobey | GaryvdM: hrmm, i'm doing a missing._find_unmerged to try and see what's going on, and i get an error: | 18:32 |
dobey | bzrlib.errors.ObjectNotLocked: <bzrlib.groupcompress._GCGraphIndex object at 0x959156c> is not locked | 18:32 |
GaryvdM | dobey: Things are normally locked by missing.find_unmerged, which then calls missing._find_unmerged | 18:33 |
GaryvdM | dobey: I pointed out _find_unmerged, because thats were the interesting code is. | 18:34 |
dobey | ah | 18:34 |
dobey | GaryvdM: thanks! | 18:48 |
jam | abentley: does it tell you the name of the variable it isn't liking? | 19:21 |
abentley | jam, "ui". | 19:21 |
abentley | jam, it's raised from a use of bzrlib.ui.ui_factory.nested_progress_bar in bzrlib/transform.py | 19:22 |
abentley | jam, my bad. It's _factory. | 19:23 |
jam | hmm... there is some confused imports in that file, given that 'ui' is in the lazy section and spelled out explicitly as 'bzrlib.ui' | 19:23 |
abentley | jam, http://pastebin.ubuntu.com/476067/ | 19:23 |
jam | abentley: no it is 'ui', '_factory' is the LazyObject attribute that failed | 19:24 |
abentley | jam, okay. I thought you were looking for the attribute it wasn't liking. | 19:25 |
jam | abentley: The attribute in the module, which is 'ui', not the attribute of the lazy object. | 19:25 |
abentley | jam, right. | 19:26 |
jam | Anyway, I've seen this when asking meliae to dump_all_objects() because it touches everything (In that after it is run, something crashes late) | 19:26 |
jam | you might try excluding the meliae tests vs running everything | 19:26 |
jam | (or including it :) | 19:26 |
abentley | jam, I don't think the launchpad test suite runs the bzr test suite. | 19:26 |
jam | abentley: not the bzr suite. But recently someone added meliae support to launchpad | 19:27 |
abentley | jam, hmm. Okay. | 19:27 |
jam | and I've seen when running bzr, if I ^\ and do a dump, when the process finishes it crashes with the IllegalUse error | 19:27 |
jam | I haven't quite tracked it down yet. (As I don't think meliae should be triggering, but I could see that it might when it tries to call __sizeof__) | 19:28 |
abentley | jam, there are no tests that match 'meliae', so I'm not sure if we're testing it. | 19:30 |
jam | abentley: you might grep the source for 'dump_all_objects()" | 19:31 |
abentley | jam, only used in one place, and its test is disabled because it broke other tests. | 19:33 |
jam | ok, so it isn't me triggering it (directly) | 19:34 |
abentley | jam, no I was asking your advice partly because you're awake, and partly because you implemented lazy imports. | 19:35 |
jam | abentley: you could try something trivial like: http://paste.ubuntu.com/476074/ | 19:36 |
jam | sorry, there is some noise there | 19:36 |
jam | just the import ui change | 19:36 |
abentley | jam, that noise looks strangely familiar :-) | 19:36 |
jam | mostly I'm trying to help isolate the issue. | 19:36 |
jam | this sort of thing usually occurs when you do | 19:37 |
jam | from module import attribute | 19:37 |
jam | and in module that is actually a lazy attribute | 19:37 |
jam | spiv tracked down a case where a package imports a submodule and triggers this (if in bzrlib you used lazy_import to get bzrlib.ui, for example) | 19:37 |
abentley | jam, since I can't reproduce the problem without doing a full test run, I've started a full test run with the import changed. | 19:41 |
svaksha | hi, while pushing a branch bzr hangs with "| 2KB 0KB/s | Fetching revisions:Inserting stream ". Any idea why this happens? TIA. | 20:14 |
svaksha | earlier today it allowed me to commit so at the moment i'm not sure if the error is due to the network or something else. | 20:15 |
svaksha | never mind, problem solved, network issue | 20:20 |
digitalice | hi | 20:26 |
digitalice | how can i checkout a single file from a repo? | 20:26 |
digitalice | like in git: git checkout folder/file.txt | 20:26 |
=== verterok1 is now known as verterok | ||
abentley | digitalice, you can't checkout a single file, but you can get a copy of one using "bzr cat branch/file.txt > file.txt" | 20:27 |
digitalice | no :S? | 20:28 |
digitalice | mmm | 20:28 |
maxb | huh | 20:28 |
maxb | well sulk then :-) | 20:28 |
maxb | I was about to suggest that 'bzr revert file' might actually be wanted | 20:29 |
=== oubiwann is now known as oubiwann-away | ||
jam | abentley, maxb: given http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html | 20:30 |
jam | it actually means he wanted "bzr revert" | 20:30 |
maxb | yup | 20:30 |
maxb | !blame git | 20:30 |
jam | Apparently 'git checkout PATH' is revert the content | 20:30 |
jam | to the explicit value | 20:30 |
jam | not exactly what I think of for checkout, but maybe it fits gits model | 20:31 |
jam | since 'git checkout' is turn the wt into a given revision (possibly based on branch pointer) | 20:31 |
maxb | git has this madness where several commands do almost completely different things depending on whether they act on the whole tree or specific paths | 20:32 |
abentley | jam, crazy. | 20:32 |
jam | abentley: :) | 20:33 |
jam | abentley: for https://code.launchpad.net/~abentley/bzr/revision-id-from-committer/+merge/32246 why only target 2.2 and not older releases? | 20:33 |
ddaa | It probably makes some sense. My guess would be: ease of implementation | 20:34 |
abentley | jam, the bug doesn't cause pain in earlier releases because they won't raise NoWhoami. | 20:34 |
ddaa | since that seems to be an overriding design factor in git | 20:34 |
jelmer | jam: As somebody who has used git on a regular basis, that use of "git checkout" doesn't make sense to me either. | 20:35 |
rubbs | git is confusing | 20:35 |
* rubbs is grateful he learned with bzr, it just makes sense | 20:35 | |
maxb | I agree - so much more that git, even a little more than mercurial, bzr's concepts and UI are definitely a strong point | 20:42 |
maxb | (And to anyone who wonders what I meant about mercurial.... 'hg resolve' == 'bzr remerge') | 20:43 |
rubbs | right, and to be honest I find the one directory per branch a feature. also the lack of a staging area (just why?) and sane by default actions. | 20:46 |
rubbs | and the empty directory tracking has saved my bacon before | 20:47 |
maxb | mhm. I'm not sold on the one directory per branch thing, but the rest, yes. | 20:47 |
jelmer | maxb: There is a patch in progress to resolve that :-) | 20:49 |
maxb | Yes. I'm eagerly looking forward to it :-) | 20:50 |
maxb | It would help my case for adopting it at work, where we do java stuff. Java IDEs tend to make project setup / pointing at a new filesystem directory more heavyweight than it should be | 20:50 |
maxb | Although Bazaar's lacklustre Eclipse support is likely still going to be a major sticking point | 20:51 |
jelmer | maxb: I guess lightweight checkouts can be of use there, but unfortunately their setup is less trivial than colocated branches. | 20:51 |
rubbs | ah, yeah I can see the colocation being an issue with IDE's. I'm a sysadmin so most of my "coding" is done in Vim. | 20:52 |
maxb | The problem with lightweight checkouts is that they make sense to someone who has bought into bazaar, but look like a lot of work to someone who has not | 20:52 |
krisives-gearbox | Does anyone know how nested branch support is started/coming along? | 20:52 |
GaryvdM | jelmer: Did you want me to run the test suit on bzr-svn tip, or the last release? | 20:53 |
jelmer | GaryvdM, tip please | 20:53 |
=== oubiwann-away is now known as oubiwann | ||
GaryvdM | ok - Doing that now | 20:54 |
jelmer | GaryvdM: also, thanks for doing so! | 20:54 |
GaryvdM | Sure, np | 20:54 |
GaryvdM | jelmer: Sorry - bug seems to still exist. | 21:02 |
jelmer | GaryvdM: ok | 21:03 |
jelmer | GaryvdM: Thanks for checking. | 21:03 |
GaryvdM | jelmer: we need to nag vila to add our plugins to babune... | 21:03 |
jelmer | yeah | 21:03 |
GaryvdM | I'm also hoping to setup a daily build of the windows installers | 21:04 |
abentley | krisives-gearbox, AFAIK, no one is working on it. | 21:05 |
krisives-gearbox | abentley: Is the draft doc rather complete? | 21:09 |
abentley | krisives-gearbox, I don't remember. It certainly wasn't approved, though. | 21:10 |
krisives-gearbox | abentley: Where would I go to help that get into motion? My employer wants the feature and is willing to commission it | 21:11 |
abentley | krisives-gearbox, you shoul talk to poolie. | 21:11 |
krisives-gearbox | abentley: Does that involve idling in IRC all the time ? | 21:12 |
abentley | krisives-gearbox, he also can be emailed at mbp@canonical.com | 21:13 |
GaryvdM | jam: I'm done on the ec2 instance. So you can shutdone if needed. | 21:13 |
krisives-gearbox | Oh, Martin Pool | 21:13 |
GaryvdM | jam: Can we please save it state to. | 21:13 |
GaryvdM | jam: The paramiko patch is working nicely. | 21:13 |
=== Ursinha is now known as Ursinha-lunch | ||
jam | GaryvdM: starting a bundle request now | 21:15 |
GaryvdM | jam: Thanks for the use of it. Now that I have had the confidence of doing a few builds, I'm going to try build my own build host in a vm. | 21:17 |
GaryvdM | Maybe setup nightly builds. | 21:17 |
jam | GaryvdM: that would be nice. Though we may just want to get it set up on babune | 21:23 |
jam | once vila gets back | 21:23 |
jam | (next week) | 21:23 |
=== oubiwann is now known as oubiwann-away | ||
=== Ursinha-lunch is now known as Ursinha-afk | ||
=== oubiwann-away is now known as oubiwann | ||
=== oubiwann is now known as oubiwann-away | ||
=== oubiwann-away is now known as oubiwann | ||
=== oubiwann is now known as oubiwann-away | ||
latexer | hey everyone... when using bzr on windows (Win7), I was expecting to be able to put a .ssh/config file in place to override the User config for a certain host... | 22:42 |
latexer | but it doesn't seem to obey/work. | 22:42 |
latexer | I've tried in C:\Users\foo\.ssh\config and C:\Users\foo\AppData\Roaming\.ssh\config | 22:42 |
latexer | neither seem to have an effect. | 22:43 |
latexer | Any suggestions? | 22:43 |
lifeless | are you using putty ? | 22:44 |
lifeless | or openssh ? | 22:44 |
lifeless | if you're using openssh, wherever your openssh looks for the config should work | 22:44 |
latexer | AFAIK, openssh, I used the "standalone" installer to install bzr. | 22:44 |
lifeless | if you're using putty, I think you need to use pageant or whatever | 22:44 |
lifeless | the standalone installer uses putty I think | 22:44 |
lifeless | what change do you need make on a per-host basis (there may be another way to change it) | 22:44 |
latexer | lifeless: it says: "Connected (version 2.0, client OpenSSH_3.8.1p1)" when connecting... | 22:45 |
maxb | Or perhaps bzr on windows might be using paramiko? | 22:45 |
lifeless | latexer: ok definitely openssh then :) | 22:46 |
latexer | lifeless: yeah, so I was trying the usual OpenSSH spots, no luck. | 22:49 |
latexer | lifeless: suggestions for how to find out where OpenSSH is looking? | 22:50 |
lifeless | well, we run ssh pretty simply | 22:51 |
lifeless | uhm, sysinternals have a strace-like tool | 22:51 |
lifeless | you could use that | 22:51 |
latexer | lifeless: oh, indeed. I'll give that a try. | 22:51 |
latexer | lifeless: thanks. | 22:51 |
=== Ursinha-afk is now known as Ursinha | ||
_habnabit | Is there a bzr command that just returns the URL a branch is bound to? | 23:53 |
_habnabit | Nothing more or less. | 23:53 |
Meths | bzr info with a bit of grep? | 23:53 |
_habnabit | I was hoping to avoid post-processing. | 23:54 |
_habnabit | I guess I could make a plugin to do it. | 23:55 |
Meths | Well when a branch can have no URLs or many what kind of output do you actually want? | 23:56 |
_habnabit | A branch can be bound to multiple URLs? | 23:56 |
Meths | well, not bound probably, but push and pull can be different | 23:56 |
_habnabit | Yeah. I'm only talking about the bound URL. | 23:57 |
lifeless | bzr info only atm | 23:57 |
lifeless | I think you need a 3-line python script / plugin | 23:57 |
_habnabit | Mmkay. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!