* SamB gripes about bzr viz not being able to run from a repo ... | 00:45 | |
jelmer | lifeless: will iter_changes() yield unchanged parent directories of changed files | 00:50 |
---|---|---|
=== mario_ is now known as pygi | ||
lifeless | jelmer: look for use_record_iter in commit.py | 00:59 |
lifeless | james_w: ping | 01:03 |
james_w | hey lifeless | 01:03 |
lifeless | james_w: can I get you to debug the stacking bug you stuffered? | 01:03 |
james_w | sure | 01:03 |
lifeless | look at rev 4174 | 01:04 |
lifeless | it has the last change to this | 01:04 |
lifeless | and a test | 01:04 |
lifeless | pdb somewhere in its new code should help isolate whats going on | 01:04 |
spiv | lifeless: you're welcome to come up here today. | 01:04 |
lifeless | spiv: ok, I'll head up shortly then if thats ok; we've got a lot to get across :) | 01:05 |
james_w | ah, that sort of debugging :-) | 01:05 |
lifeless | james_w: yes :) | 01:06 |
james_w | tomorrow then I feel | 01:06 |
spiv | lifeless: sure. | 01:06 |
lifeless | ok | 01:06 |
lifeless | james_w: please attach bzr info -v of your source branch then | 01:07 |
lifeless | james_w: as well as checking you did push with a bzr >> 4174 | 01:07 |
pygi | is there any docs for nested branches support? | 01:16 |
jelmer | lifeless: well, I'm almost done implementing record_iter_changes | 01:20 |
jelmer | lifeless: is iter_changes() O(delta) or O(tree) on bbc trees? | 01:21 |
lifeless | jelmer: working tree is O(tree), revision trees are a function of delta size and log(tree) | 01:24 |
lifeless | -> train to spivs, online again in ~40 | 01:24 |
thewrath | hello all | 01:41 |
lifeless | jelmer: back | 01:59 |
=== ja1 is now known as jam | ||
jelmer | lifeless: IIUC iter_changes does depth-first search based on the target tree? | 02:53 |
jelmer | so if I see a directory is being processed and then see some sibling is being processed I can assume that directory is "done" ? | 02:53 |
lifeless | jelmer: I wouldn't make that assumption | 03:34 |
lifeless | jelmer: because it can jump around with renames and stuff | 03:34 |
lifeless | it might start with one file in a dir, then subdirs, siblings, then find that the dir was reparented and include the parent | 03:34 |
=== UdontKnow is now known as \0 | ||
=== \0 is now known as UdontKnow | ||
=== thunderstruck is now known as gnomefreak | ||
BasicOSX | lifeless: just came here to report the stacking issue, but I see you are on it, I was just about to upload 1.14rc1, I can wait if bug 354036 fix is close | 06:30 |
ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 | 06:31 |
lifeless | BasicOSX: we're getting close, I'm landing the last bits of brisbane-core at the moment too | 06:36 |
BasicOSX | we are all good then, was working vila osx patches and Ian's filter registration patch, so I can hold off until that lands | 06:38 |
lifeless | BasicOSX: cool | 06:38 |
Peng_ | BasicOSX: Are you planning to merge the RemoteBranchConfig stuff from r4251 of bzr.dev into 1.14? | 06:50 |
BasicOSX | Peng: no one specifically requested that | 06:51 |
Peng_ | Eh. | 06:51 |
Peng_ | lifeless: ^^ Did you want that for 1.14? | 06:52 |
lifeless | BasicOSX: Oh, I thought I did | 06:54 |
lifeless | BasicOSX: in my mail about it to the list, I noted that it fixes a regression vs 1.13 | 06:54 |
BasicOSX | hmm, only merge requests I see are the osx test failures and the simplify the content filter registration API | 06:57 |
BasicOSX | well, and bug 354036 | 06:57 |
ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 | 06:57 |
lifeless | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D53C9C.2070200%40mattnordhoff.com%3E | 06:58 |
lifeless | actually thats not the one | 06:58 |
lifeless | BasicOSX: its rev 4251 of bzr.dev | 07:01 |
lifeless | I'll send a mail now | 07:01 |
vila | hi all | 07:01 |
Peng_ | vila: Hello | 07:01 |
BasicOSX | lifeless: got that, (robertc) Fix handling of fallback repositories some more, just cannot find request to cherry pick it (hello vila) | 07:01 |
lifeless | BasicOSX: I've just sent one to the list | 07:02 |
vila | BasicOSX: That was the purpose of lp:~vila/bzr/1.14 | 07:03 |
BasicOSX | I apologize if I missed the initial request... oh, wait | 07:03 |
BasicOSX | info overload lately trying to weed through the 1.14 RC date thread :-( | 07:04 |
lifeless | :P | 07:04 |
vila | BasicOSX: np, that's what teams are for :) | 07:04 |
lifeless | if I can ask a small favour | 07:04 |
lifeless | please leave pqm clear for thie next cole of hours, I'm trying to land all of brisbane core | 07:04 |
BasicOSX | np | 07:04 |
lifeless | and finding gaps in e.g. python2.4 support for it | 07:05 |
lifeless | which are trivialish but a round trip to fix | 07:05 |
Peng_ | lifeless: All of it? Like, "bzr merge ../brisbane-core"? | 07:05 |
vila | lifeless: fwiw, full test suite passed for python2.[456] here | 07:05 |
lifeless | Peng_: well no, I'm not planning on do that at all | 07:06 |
lifeless | Peng_: but do the point there is nothing we want to land | 07:07 |
lifeless | vila: check the _chk_map.pyx and _groupcompress.pyx files :) | 07:07 |
lifeless | vila: _chk_map is in .dev, groupcompress in p.u.c/~robertc/baz2.0/integration | 07:07 |
Peng_ | lifeless: Oh. Well, congrats. :) | 07:10 |
lifeless | groupcompress up to ascii :) | 07:10 |
BasicOSX | lifeless: sorry to pester, but did you find the initial request to merge fallback repositories stuff? I would like to know so I can attempt to fix the holes in my tracking of merge requests. | 07:10 |
lifeless | BasicOSX: I haven't kept looking | 07:12 |
BasicOSX | np | 07:12 |
lifeless | BasicOSX: the fallback repositories stuff was fallout exposed by fixing the config stuff | 07:12 |
lifeless | the branch was about configs | 07:12 |
vila | BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it and prepare the branch for you to merge | 07:12 |
vila | BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it *in bzr.dev* and prepare the branch for you to merge in 1.14 | 07:12 |
* BasicOSX groans | 07:13 | |
lifeless | bug 354036 | 07:14 |
BasicOSX | Getting 354036 issue | 07:14 |
ubottu | Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/354036/+text) | 07:14 |
lifeless | bug 354036 | 07:14 |
ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 | 07:14 |
lifeless | vila: thats a different bug ;) | 07:14 |
vila | grr | 07:14 |
lifeless | vila: so have we fixed --parallel ? | 07:15 |
BasicOSX | Peng: thanks for the catch on the missed merge | 07:16 |
vila | then #354075 fixed by matt, merged by lifeless in his 'Fix handling of fallback repositories some more' patch | 07:17 |
BasicOSX | should the http transport for vila's 1.14 branch work (pass the smart server code)? | 07:17 |
vila | lifeless: --parallel works great here | 07:17 |
vila | lifeless: but you mentioned problems with ec2 ? | 07:18 |
BasicOSX | http worked :-) | 07:19 |
vila | BasicOSX: you mean for pqm submissions ? | 07:19 |
lifeless | vila: yes | 07:19 |
BasicOSX | no, to merge your code into my prepare-1.14rc1 (lifeless requested I stay out of PQM for a couple hours) | 07:19 |
lifeless | BasicOSX: http doesn't trigger the problem | 07:19 |
lifeless | BasicOSX: oh, you can merge from lp all you want, just don't run bzr pqm-submit :) | 07:20 |
lifeless | vila: give ec2test a spin, you'll see | 07:20 |
lifeless | FAIL: test_merge.TestMergerEntriesLCA.test_one_lca_supersedes_path | 07:20 |
lifeless | RemoteException: Traceback (most recent call last): | 07:20 |
lifeless | File "/home/bzrtest/test_branch/bzrlib/tests/test_merge.py", line 1598, in test_one_lca_supersedes_path | 07:20 |
lifeless | self.assertEqual, [], list(merge_obj._entries_lca())) | 07:20 |
lifeless | File "/home/bzrtest/test_branch/bzrlib/tests/__init__.py", line 1055, in expectFailure | 07:20 |
lifeless | raise KnownFailure(reason) | 07:20 |
lifeless | KnownFailure: We don't do an actual heads() check on lca values, or use the per-attribute graph | 07:20 |
BasicOSX | lp = smart server | 07:20 |
BasicOSX | ? | 07:20 |
vila | lifeless, BasicOSX : Someone else than *me* triggers the lp/pqm bug ? Hurrah ! Not jinxed anymore ! | 07:20 |
lifeless | still | 07:20 |
lifeless | BasicOSX: lp: urls reoslve to using bzr+ssh and thus a smart server | 07:21 |
vila | lifeless: I can't do that, I don't have access to ec2, not even sure I can find boto module ? | 07:21 |
BasicOSX | yep, and I'm getting bit but the smart server bug, so I just got vila's patch via http | 07:21 |
lifeless | BasicOSX: oh right, I'm synced() now :) | 07:22 |
lifeless | vila: sign up :) | 07:22 |
lifeless | vila: see the company cloud computing policy in the all hands list archives | 07:22 |
vila | lifeless: I'll look | 07:24 |
vila | By the way, it seems that we have more "warnings.warn("%r was gc'd while locked" % self.repr)" these days nist of them (if not all, involving a LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:33810 blah blah), does that ring someone's bell ¿ | 07:25 |
vila | gee how did I type that reverse ? | 07:25 |
BasicOSX | heh | 07:26 |
lifeless | -> home, groupcompress has landed, I'll be landing the remaining bits very soon. | 07:53 |
lifeless | well, ->home shortly | 07:53 |
lifeless | vila: the answer btw to InterCHKRevisionTree is s/development5/development/ | 08:24 |
lifeless | vila: found the ec2 doc stuff? | 08:24 |
lifeless | -> home now | 08:25 |
vila | lifeless: I need to find what login/pass I should use to access allhands archive first :-( | 08:42 |
fullermd | Well, if it's allhands, I presume you need a fingerprint rather than a password 8-} | 08:49 |
vila | time to upgrade ff then :) | 08:51 |
lifeless | BasicOSX: around? | 09:06 |
igc | lifeless: thanks for landing that stuff today | 09:11 |
* igc dinner - bbl | 09:12 | |
vila | lifeless: still around ? | 09:48 |
vila | I'd still prefer to run locally (for many reasons including ease of debugging). So my question is: do you feel that the problem you encounter is related to the tests protocols rather than any ec2 specific reason ? | 09:50 |
vila | lifeless: by 'locally' I mean connecting via ssh in my LAN to get a close-enough approximation of course | 09:52 |
vila | lifeless: and also because that's a setup I want to be able to use from my laptop to my "data center" :-) | 09:53 |
=== bob2 is now known as Guest95719 | ||
=== Guest95719 is now known as bob2 | ||
lifeless | igc: nearly done | 10:48 |
lifeless | vila: yes, I'm around | 10:48 |
lifeless | vila: I would like it if you were familiar enough with bzr-ec2test to debug problems when it is used | 10:49 |
lifeless | vila: thus, I plan to drag you kicking and screaming through it once :) | 10:49 |
vila | lifeless: ha, I thought so but was unsure :-) | 10:51 |
lifeless | vila: concretely it is failing to de-and-re serialise from ec2 | 10:53 |
lifeless | which I haven't had time to debug myself test. | 10:53 |
vila | lifeless: so it's not directly related to my last patch (as in, it was failing before ?) | 10:54 |
lifeless | I think so | 10:54 |
lifeless | :) | 10:54 |
vila | devil :) | 10:54 |
lifeless | well | 10:56 |
lifeless | I figure a little latitude is due, for doing the heavy lifting to get you your desired parallel suite :) | 10:56 |
lifeless | vila: I have a separate favour for you to do though, and this is rather more important. I'm about to land --development6-rich-root | 10:57 |
vila | huh ? We still separate rich-root ? | 10:57 |
lifeless | its the only one | 10:58 |
lifeless | no dev6 | 10:58 |
lifeless | and aaron has said subtrees need more stuff so leaving out for now | 10:58 |
vila | ha, to underlined that it *is* rich root | 10:58 |
lifeless | yes | 10:58 |
vila | ok | 10:58 |
lifeless | *do-not* want random upgrades and folk having deep troubles | 10:58 |
* awilkins applauds the lack of not-rich-root | 10:59 | |
vila | Didn't we say we'll call it --dev6-rich-root-eat-your-dog ? | 10:59 |
awilkins | --dev6-rich-root-cat-taxidermist ? | 11:00 |
vila | anyway, what favour ? (The more you wait to ask, the bigger is should be, the more I'm frighten :) | 11:00 |
vila | awilkins: don't touch cats | 11:00 |
awilkins | Toxoplasmosis? | 11:00 |
lifeless | vila: merge all the components of brisbane-core from bzr.dev to a single branch and then that into 1.14/get BasicOSX to merge it into 1.14 | 11:03 |
lifeless | vila: *note* I *have not* and do *not intend* to merge the brisbane-core branch directly. | 11:03 |
lifeless | vila: it has content we don't want to land in bzr.dev at this point. | 11:03 |
vila | lifeless: right, so cherry pick from bzr.dev ok. Two things, | 11:04 |
Peng_ | The sucky thing about not having a non-rich-root format is that the Big Rich Root Transition will have to take place before I can use it locally on most projects. :\ | 11:04 |
vila | lifeless: Do you have some reference branch I can use for verification purposes (though one) | 11:05 |
vila | lifeless: two: that means losing the annotations or did your (and Ian's) submissions somehow preserve them ? | 11:05 |
vila | lifeless: if answer to two is yes, don't bother explaining, I can understand why, just want to be clear | 11:06 |
awilkins | What exactly is the reason for things not being bi-directionally compatible with rich-root? | 11:06 |
bob2 | why aren't floats bidirectionally compatible with ints? | 11:06 |
awilkins | That isn't "exactly" | 11:07 |
bob2 | rich-root has data non-rich-root can't represent | 11:07 |
awilkins | Yes, but what is it? | 11:07 |
vila | awilkins: root data :) | 11:07 |
awilkins | Ginger? Valerian? | 11:07 |
vila | awilkins: that data makes root rich | 11:07 |
bob2 | an id for the root directory of a branch | 11:07 |
lifeless | vila: they are gone, we have used --author | 11:09 |
lifeless | awilkins: and versioning of the root | 11:09 |
lifeless | awilkins: which we use in a number of merge corner cases, and for nested trees. | 11:10 |
awilkins | The band-aid needs to be ripped off! .... of course, it doesn't matter much to me, the majority of branches I use are rich-root so I can keep my manager happy with svn commits | 11:11 |
lifeless | vila: btw its 120 seconds for me to run the test suite with 2 ec2 instances | 11:13 |
vila | lifeless: right so, from bzr.dev log that means revnos 4262 4261 4260 4259 4254 4248 4247 4246 4245? 4244 4243 and the one where you land the --dev6 format ? | 11:14 |
vila | lifeless: 120... hmpf | 11:14 |
vila | lifeless: that doesn't include bzr-loom of course :-) | 11:14 |
=== AnMaster_ipv6 is now known as AnMaster | ||
=== Mez is now known as CrazyShoe | ||
=== CrazyShoe is now known as Mez | ||
lifeless | igc: ping | 11:36 |
* lifeless tapdances on igc's toes | 11:53 | |
=== siretart_ is now known as siretart | ||
lifeless | vila: it passed tests in bzr.dev because many tests were not running for it | 12:11 |
lifeless | vila: grab my integration branch if you want to see it blow up ;) | 12:12 |
vila | lifeless: errr, context ? ec2 ? bbc ? | 12:12 |
igc | lifeless: here to help - which branch should I grab? | 12:13 |
lifeless | igc: my integration branch | 12:15 |
lifeless | vila: bbc | 12:15 |
lifeless | igc: if you run bzrlib.tests.workingtree_implementations.test_eol_conversion.TestEolConversion.test_eol_native_with_crlf_i | 12:16 |
lifeless | for selftest | 12:16 |
lifeless | it should fail with a clearly wrong line ending | 12:16 |
lifeless | I see | 12:16 |
lifeless | AssertionError: not equal: | 12:16 |
lifeless | a = 'hello\r\nworld\r\n' | 12:16 |
lifeless | b = 'hello\nworld\r\n' | 12:16 |
lifeless | for instance | 12:16 |
lifeless | give me a clear pointer at whats likely wrong and I'll happily fix. right now I'm fixing real issues with tests that were incorrectly not enabled in bbc that became clear as I did the integration | 12:17 |
lifeless | s/real/other real/ | 12:17 |
igc | lifeless: grabing the branch now. The code on lp is up to 4248 and due for mirroring again in 2 hours so I can't just use loggerhead there | 12:19 |
=== thunderstruck is now known as gnomefreak | ||
lifeless | igc: sorry yes :) | 12:23 |
lifeless | igc: regardless loggerhead wouldn't help you I don't think | 12:23 |
igc | np - it's down now | 12:23 |
lifeless | so, found an issue with labels | 12:23 |
lifeless | without labels in the pack | 12:23 |
lifeless | two packs with different content can then collide, but the indices are no longer equivalnet | 12:25 |
lifeless | [tests fail] | 12:25 |
igc | lifeless: ./bzr selftest TestEolConversion --no-plugins -1 passes for me | 12:26 |
igc | on 4249 | 12:26 |
igc | of your integration branch | 12:26 |
igc | hmm | 12:26 |
lifeless | set LANG=C | 12:26 |
ronny | hmm | 12:26 |
ronny | sadly bzr is the only vcs that has merge instead of pull if the remote diverged | 12:27 |
bob2 | 'has'? you can merge in git in that situation (after fetching) | 12:28 |
igc | ronny: try bzr merge --pull | 12:29 |
ronny | hg and git allow me to pull first, merge later | 12:30 |
bob2 | you can bzr pull to your local mirror of that branch (and if it is in a repository with your branches, it is space efficient) | 12:31 |
lifeless | ronny: bzr can do that too, via fetch | 12:31 |
bob2 | bzr's mass branch management is a bit lacking alas | 12:31 |
ronny | lifeless: so fetch pulls a dangling head into the backing repo? | 12:32 |
igc | lifeless: setting LANG=C doesn't break things for me | 12:32 |
ronny | hmm | 12:32 |
igc | I'll try a wider set of tests | 12:32 |
ronny | i love how this shit differs - in hg/mtn pull is history sync, in bzr/git it has some merge potential (and bzr is the one that needs explicit merge) | 12:33 |
ronny | lifeless: will the fetched remote data get any special marker other than showing up in the heads? | 12:36 |
lifeless | igc: interesting | 12:36 |
lifeless | ronny: no | 12:36 |
igc | lifeless: so the filtered views tests are failing for me cause you deleted development-wt6 - trying them now with development-wt6-rich-rott | 12:36 |
igc | roo | 12:37 |
igc | root | 12:37 |
lifeless | igc: yes,they are passing for me | 12:37 |
lifeless | I have some uncommitted fixes fixing most of the tests | 12:37 |
igc | it needs to go as well and be replaced with you new format | 12:37 |
igc | lifeless: so filtered view tests pass on development6-rich-root, development-wt6-rich-root needs deletion if you haven't done it already | 12:41 |
lifeless | igc: yes, done | 12:42 |
igc | lifeless: did you try --no-plugins? | 12:43 |
jelmer | hey lifeless, igc | 12:43 |
igc | hi jelmer | 12:43 |
jelmer | vila: ping | 12:43 |
jelmer | vila: You mentioned using factory.stdin.getvalue() in your review | 12:44 |
jelmer | vila: but the rest of the file also uses factory.stdin.readline() and the main point is checking the position of the stream | 12:44 |
igc | lifeless: if you put the output from bzr diff in a pastebin, I'll apply that and run the tests again | 12:47 |
vila | jelmer: I think the comment says: ensures stdin is empty no ? Oops, no, the previous test is with a non-empty stdin, sorry, forget that remark then | 12:47 |
jelmer | vila: ok, just making sure I wasn't missing anything. Thanks again for reviewing, I've fixed the other issues. | 12:49 |
lifeless | igc: sure, one sec | 12:49 |
lifeless | http://paste.ubuntu.com/146177/ | 13:00 |
lifeless | sorry, phone call | 13:00 |
lifeless | igc: ^ | 13:04 |
lifeless | igc: I'm going to recommit in a minute, as I had to back out some of the cleanup | 13:04 |
lifeless | and try it again | 13:04 |
lifeless | ok ec2testing | 13:21 |
lifeless | igc: if it fails on the NoEol stuff, I'm going to shove it a pqm | 13:21 |
lifeless | I think it might be me ;) | 13:21 |
igc | lifeless: might be. bzr selftest eol filter --no-plugins -1 works fine for me with your patch .. | 13:22 |
igc | and visually inspecting it, it looks fine | 13:23 |
lifeless | igc: yea, I can't see anything in this breaking it :( | 13:23 |
igc | I got out of bed to help so I'll head back there now | 13:23 |
lifeless | igc: I'm so sorry | 13:23 |
lifeless | igc: where should I look if it still breaks | 13:23 |
igc | lifeless: np. email me if there's still an issue and I'll look into it first thing | 13:23 |
lifeless | I'm staying up till this is landed | 13:24 |
lifeless | I don't need you to fix it, just to point me at the code areas that are potentially implicated | 13:24 |
igc | well bzrlib/filters/eol.py is the starting point | 13:24 |
igc | beyond that, it depends | 13:24 |
igc | sorry - that's not much of an answer | 13:25 |
lifeless | thats ok | 13:25 |
lifeless | I will follow my nose as needed | 13:25 |
lifeless | sleep well, and sorry again | 13:25 |
igc | lifeless: good luck and I'll possibly be up early - hard to tell as the chemo makes me very both very sleepy and very awake depending on god knows what | 13:26 |
igc | so please email any issues | 13:26 |
igc | night all | 13:26 |
lifeless | will do | 13:28 |
lifeless | bombs away | 13:32 |
vila | lifeless: your pending submission in pqm is the last I should backport to 1.14 right ? (It passes tests here) | 13:56 |
lifeless | yes | 13:56 |
jelmer | vila: I'm wondering what to do with smtp as the current implementation asks pre-emptively | 14:02 |
jelmer | vila: ideally we wouldn't always be doing that but only in the cases where the server requires us to | 14:04 |
jelmer | vila: but that seems impractical (impossible?) for smtp | 14:04 |
vila | jelmer: smtp starts by using its own smtp_username and smtp_password config options, I'd say it should use authentication.conf instead | 14:05 |
vila | jelmer: iow, out of scope for your fix IMHO | 14:06 |
jelmer | vila: the problem is get_user() will now return getpass.getuser() rather than None if there's no user configured in authentication.conf | 14:06 |
jelmer | vila: and previously it would skip authentication if None was returned | 14:06 |
lifeless | jelmer: can I ask a favour? | 14:06 |
jelmer | lifeless: you can always ask :-) | 14:07 |
lifeless | jelmer: ... say yes to my next request | 14:07 |
lifeless | jelmer: may I kill your pqm job, its 11PM, want to land development6 and sleep | 14:07 |
jelmer | lifeless: sure, go ahead | 14:07 |
lifeless | tanks | 14:08 |
jelmer | lifeless: please let me know when yours is done so I can requeue mine | 14:13 |
vila | jelmer: I'm pretty sure lifeless will be asleep when pqm lands its patch :) But nothing forbids you to queue now, I think that was the last missing patch | 14:14 |
lifeless | vila: I will be awake till it lands | 14:14 |
vila | lifeless: sorry no offense intended :) | 14:14 |
lifeless | vila: only way to be sure | 14:15 |
lifeless | non taken | 14:15 |
vila | lifeless: good ! So you may have a look at lp:~vila/bzr/bcc-1.14 and tell me if everything looks fine so far | 14:15 |
vila | :) | 14:15 |
vila | lp:~vila/bzr/bbc-1.14 of course | 14:16 |
lifeless | to your list above | 14:16 |
lifeless | 4257 | 14:16 |
vila | indeed, just merged it | 14:16 |
jelmer | vila: any idea about smtp? | 14:17 |
vila | lifeless: errr, was about to merge it (not pushed) | 14:17 |
lifeless | :) | 14:17 |
jelmer | vila: I could add a "return_non_if_default" boolean parameter but that just seems plain wrong | 14:18 |
vila | jelmer: consistency is good, I think smtp should align to either http or getpass.getuser() | 14:18 |
jelmer | vila: but the new behaviour makes unauthenticated smtp impossible | 14:19 |
jelmer | as get_user() will never return None | 14:19 |
jelmer | lifeless: I just got a "success" message from PQM and my branch was merged | 14:21 |
lifeless | jelmer: odd... | 14:21 |
vila | jelmer: unauthenticated http is possible, do the same :-) | 14:21 |
jelmer | vila: yes, but in the case of http we only ask after the remote host gives a "Permission denied" | 14:22 |
vila | jelmer: sure, I was trying to get some time to think :) | 14:22 |
awilkins | jelmer: That reminds me about svn+ prefixes | 14:22 |
jelmer | vila: :-) | 14:23 |
jelmer | awilkins: what about them? | 14:23 |
awilkins | jelmer: I seem to think that if your web server refuses access to the locations that bzr probes to determine whether a web server is a repo, things just stop | 14:24 |
awilkins | I should make a more coherent report | 14:24 |
vila | jelmer: so smtp._authenticate() says: """If necessary authenticate yourself to the server.""", so there should be a way to find if auth is necessary | 14:26 |
vila | In the worst case it means: try to send, catch auth error, authenticate, send | 14:26 |
vila | there is smtplib.SMTPAuthenticationError .... | 14:26 |
vila | ... whose doc string says " Most probably the server didn't accept the username/password"... I love the most probably part :-/ | 14:27 |
jelmer | vila: yeah, SMTP sucks | 14:28 |
vila | jelmer: probably smtp servers requiring auth suck less :-) | 14:28 |
jelmer | vila: The annoying thing here is that we probably won't know whether we need authentication until we've tried sent a full email | 14:28 |
jelmer | s/sent/to send/ | 14:29 |
vila | jelmer: indeed, that's the way http achieve auth, try without and if it fails try with auth | 14:31 |
=== sabdfl1 is now known as sabdfl | ||
vila | lifeless: ha, 4259, the fun stuff :-( | 14:35 |
=== abentley1 is now known as abentley | ||
jelmer | vila: what about an optional default= argument to get_user() that defaults to getpass.getuser() ? | 14:37 |
jelmer | vila: smtp could set that to None | 14:37 |
jelmer | and keep behaving the way it does atm | 14:37 |
vila | jelmer: if you add a FIXME in smtplib about converging and/or addressing the problem, that sounds perfect for your submission | 14:38 |
jelmer | that would keep smtp in the current state but at least support prompting for http | 14:38 |
jelmer | vila: cool, thanks | 14:38 |
lifeless | yes :) | 14:39 |
lifeless | vila: see the pyrex issues? | 14:39 |
lifeless | also: http://pqm.bazaar-vcs.org/ - the eagle is landing | 14:39 |
lifeless | jam: ^ :) | 14:40 |
vila | lifeless: not yet (but I suspected that when you mentioned the problem), I'm in Resolve confclits in NEWS | 14:40 |
jam | lifeless: /cheer /train | 14:42 |
jam | Though your post about duplicate content was a bit concerning | 14:42 |
jam | I have some thoughts about exploiting duplicate content within a group, but having this across .pack files ... | 14:43 |
lifeless | jam: yes; it is rather pathological, but worth resolving in some way for production version | 14:44 |
jam | lifeless: so... we could go with some sort of labels as an easy fix, or push more for getting text content into a chk structure | 14:45 |
jam | I'm concerned about the CHK index exploding even further... | 14:46 |
lifeless | jam: indeed | 14:55 |
vila | landed in bzr.dev | 14:58 |
lifeless | vila: cool | 15:04 |
lifeless | jelmer: go for it | 15:04 |
jelmer | lifeless: thanks, it's already in though :-) | 15:06 |
lifeless | vila: so are you good to get a passing testsuite version for 1.14? | 15:06 |
vila | I run selftest at each commit, I'm at bzr.dev@4261 so 3 more commits to go | 15:06 |
lifeless | cool, I'll hang about a bit then | 15:07 |
vila | err 2 even | 15:07 |
lifeless | as I know you have fast tests :) | 15:07 |
vila | indeed, could not have afford to do that otherwise | 15:07 |
vila | lifeless: yeah for the big fat NEWS entry about bbc :) | 15:11 |
vila | lifeless: ready to merge in 1.14 pushed at lp:~vila/bzr/bbc-1.14 care to have a look, jam too ? | 15:15 |
vila | still running the tests, will do a 'make check' after that | 15:15 |
lifeless | vila: I'm shattered; the mainline is done, I'm happy to hand off | 15:16 |
vila | lifeless: ok | 15:16 |
vila | lifeless: good job, sleep well, no test failure to report so far :-) | 15:16 |
lifeless | vila: cool, thanks. | 15:16 |
jam | vila: so is that cherry-picking brisbane-core into 1.14? | 15:17 |
jam | lifeless: is this the bug you were looking at with spiv: | 15:17 |
jam | ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has | 15:17 |
jam | no attribute 'get_bytes_as'") | 15:17 |
=== ubott2 is now known as ubottu | ||
lifeless | jam: yes | 15:17 |
jam | k | 15:17 |
lifeless | jam: I mailed the list the bug number | 15:17 |
jam | because I just failed to branch vila's code | 15:17 |
lifeless | the fix is to upload more content | 15:18 |
jam | bug 354036 | 15:18 |
lifeless | yes | 15:18 |
vila | jam: yes, it should be: bzr-1.14 + (bzr.dev@4265 - everything not related to bbc) | 15:18 |
lifeless | vila: apply the fix from bug 354036 to the bzr you use to push, remove the branch and push again | 15:18 |
jam | well, for now I can just branch from "http://bazaar..." | 15:19 |
lifeless | indeed | 15:19 |
lifeless | well, I'm halting() or I'll be more than tired tomorrow | 15:20 |
vila | lifeless: I use bzr.dev@4263 to push so the fix should already be included | 15:20 |
ubottu | Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text) | 15:20 |
lifeless | vila: we haven'tlanded the fix for that bug | 15:20 |
ubottu | Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text) | 15:20 |
vila | grrr | 15:20 |
Peng_ | lifeless: There's an error in the docs for development-rich-root: It says it's interchangeable with pack-0.92, not rich-root-pack. | 15:21 |
vila | ubottu you didn't help here ! That's the second time I cross the bugs and that you can't display them >-/ | 15:21 |
ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 15:21 |
vila | ubottu: that wasn't exactly what I was thinking :-) | 15:21 |
ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 15:21 |
lifeless | Peng_: thanks. vila/jam if you could fix that oversight that would be grand | 15:22 |
* lifeless goes | 15:22 | |
vila | uuuurgh, can't pull ~spiv/bzr/stacking-inventory | 15:25 |
vila | ok, pulled with bzr-1.13 | 15:27 |
vila | and pushed with ~spiv/bzr/stacking-inventory at lp:~bzr/bzr/bbc-1.14 | 15:28 |
vila | jam: can you pull that one ? | 15:29 |
jam | vila: I already fetched it with http:// | 15:29 |
jam | but I'll try again on another machine | 15:29 |
vila | jam: rats, I missed that one | 15:29 |
jam | vila: bzr.dev@4265 still fails to branch lp:~bzr/bzr/bbc-1.14 | 15:31 |
jam | maybe you need some actual data transferred so it doesn't no-op the push? | 15:31 |
jam | vila: you could try 'commit --unchanged' and uncommit it later if it works | 15:32 |
jam | (commit --unchanged, bzr push, bzr uncommit lp:...) | 15:32 |
vila | jam: it's a new branch ! The former one was lp:~vila/bzr/bbc-1.14 | 15:32 |
jam | ah | 15:32 |
jam | well, it failed | 15:32 |
jam | so it seems the stacking fix isn't sufficient/complete yet | 15:33 |
Peng_ | So, um, anyone want to fix the doc issue I just mentioned, or should I send a trivial patch or something? | 15:33 |
vila | Peng_: send a trivial patch so that it doesn't get lost | 15:33 |
Peng_ | vila: Okie dokie. | 15:34 |
Peng_ | Okey dokey? Whatever. Anyway. | 15:34 |
Peng_ | Wait, what should it be against? bzr.dev? bbc-1.14? | 15:34 |
vila | bbc-1.14 will be merged in bzr.dev at some point so at least against it | 15:35 |
Peng_ | Whee, AbsentContentFactory traceback! | 15:35 |
beuno | Peng_, downgrade to 1.13.1 :) | 15:36 |
beuno | I had to do that yesterday | 15:36 |
Peng_ | \o/ | 15:36 |
Peng_ | I don't have 1.13.1 anywhere. | 15:37 |
beuno | it's stacked branches and bzr.dev not getting along AFAIK | 15:37 |
* Peng_ kicks the "Target directory already exists" error. | 15:38 | |
vila | Peng_: bzr branch http://bazaar-vcs.org/bzr/bzr.1.13/ | 15:38 |
Peng_ | vila: Well yeah. | 15:38 |
Peng_ | Tags would make it easier to figure out which revision is right, though. | 15:39 |
Odd_Bloke | So I just ran "bzr push svn+ssh://odd_bloke-guest@svn.debian.org/svn/python-modules/packages/python-whoosh/trunk" and got "bzr: ERROR: Prefix missing for branches/python-whoosh; please create it before pushing.". How can I tell bzr-svn to actually push to where I'm telling it? Would it make a difference if .../trunk already existed? | 15:39 |
Odd_Bloke | jelmer: ^ :) | 15:40 |
awilkins | Odd_Bloke: python-whoosh needs to exist | 15:41 |
awilkins | Odd_Bloke: Don't create trunk | 15:41 |
Odd_Bloke | python-whoosh does exist. | 15:41 |
Odd_Bloke | It's talking about an as-far-as-I-can-tell-unrelated '_branches_/python-whoosh'. | 15:41 |
awilkins | Ah, maybe it's branches that needs to exist (or you need to make it think something else about branching scheme) | 15:42 |
Peng_ | Are format help strings hardcoded in the tests anywhere? | 15:45 |
Peng_ | In other words, is bzrdir.py the only place you have to make changes to them? | 15:46 |
Odd_Bloke | awilkins: Using 'bzr svn-layout'? | 15:46 |
awilkins | Odd_Bloke: I'm not entirely sure | 15:46 |
awilkins | Odd_Bloke: I've just resorted to conforming to expectations :-) | 15:46 |
vila | Peng_: running the tests should tell you :) | 15:48 |
Peng_ | vila: But you can tell me more quickly! ;-D | 15:48 |
Peng_ | Wait, so bbc is going to go in 1.14? | 15:49 |
vila | Peng_: I don't know that one by hearth, so I'll have to run the tests :) | 15:49 |
vila | Peng_: that was always the plan :) | 15:49 |
jelmer | Odd_Bloke: hi | 15:50 |
jelmer | Odd_Bloke: you need to use svn-push if you're running an older version of bzr | 15:50 |
vila | BasicOSX: ping | 15:51 |
Peng_ | Well, it looks like the tests weren't updated last time they changed, so I'll go with that. | 15:52 |
Peng_ | So should I send the patch to the mailing list? [1.14]? | 15:52 |
vila | Peng_: yup | 15:52 |
Peng_ | This process needs more magic. All I'd have to do is think "vila, fix this bug" and bang, it would be in bzr.dev 30 seconds later. :( | 15:53 |
vila | Peng_: when in doubt, use more magic | 15:54 |
Peng_ | Shoot, I branched from bbc-1.14, meaning a diff against bzr.dev includes lots of other stuff. :( | 15:55 |
Odd_Bloke | jelmer: Ah, cool, didn't realise how long it had been since I'd updated my bzr.dev/bzr-svn on this machine. | 15:56 |
Odd_Bloke | jelmer: Thanks. :) | 15:56 |
vila | Peng_: why are you diffing against bzr.dev ? Is your branch parent correct ? And the submit one ? | 15:59 |
Peng_ | vila: Well, when sending a bundle to the list, it's most convenient to have the parent be in bzr.dev. Which the tip of bbc-1.14 isn't. Or something. | 16:01 |
Peng_ | I don't want to expend more effort thinking about this! :( | 16:01 |
Peng_ | vila: So, you want the patch against bbc-1.14? | 16:02 |
vila | Peng_: it's indeed the most convenient when sending bumdles against bzr.dev :-) But here you want submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14/ | 16:02 |
vila | Peng_: whatever is easier for you, as I said, we don't want it to be lost, that doesn't mean you have to suffer :) | 16:03 |
Peng_ | So it looks like you and lifeless made the same changes (or at least the same commit messages) in different revisions, one for bbc-1.14 and one for bzr.dev. | 16:04 |
Peng_ | Hence my problems. | 16:04 |
vila | Peng_: I indeed copy/pasted a lot to cherry-pick | 16:04 |
Peng_ | If only we were using darcs. :( | 16:05 |
Peng_ | On a different subject, ice cream! See you later. :) | 16:10 |
Tak | ice cream is always on topic | 16:26 |
Peng_ | What about cake? | 16:27 |
Tak | I suppose that's a matter for debate | 16:30 |
vila | ice cream on top of cake ? | 16:34 |
vila | passed under a chocolate fountain ? | 16:35 |
Peng_ | And deep-fried! | 16:35 |
vila | ubottu don't like chocolate :) | 16:35 |
Peng_ | With M&Ms and powdered sugar on top. | 16:35 |
Peng_ | Heh. | 16:35 |
vila | chocolate | 16:39 |
vila | BasicOSX: ping | 16:39 |
vila | BasicOSX: I have a fix for bug #355454 | 16:40 |
vila | come on ubottu, you should have that one in your cache, it's a hot one | 16:40 |
ubottu | Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix committed] https://launchpad.net/bugs/355454 | 16:42 |
Peng_ | 1.14 is getting a *lot* of patches. | 16:43 |
vila | Peng_: 1.14rc1 is not out yet, at least because of the above bug :) | 16:45 |
tony | hello? | 17:15 |
vila | jam: ping | 17:26 |
tony | hi | 17:26 |
jam | vila: pong | 17:27 |
tony | heh | 17:28 |
vila | jam: regarding fix for #355454, I think abspath is needed because we'll call stat, so my last remark is invalid | 17:28 |
jam | I think I've tracked down the ambiguity, so we just need to decide on a fix | 17:30 |
jam | specifically | 17:30 |
jam | walkdirs()[4] ==> a path that you can pass to stat or open() to get the object | 17:30 |
jam | which may be Unicode or may be an fs path | 17:30 |
vila | yet, we may want to have both rel and abs available to avoid re-calculating rel from abs, I'm pretty sure we use the path that can be either utf8-encoded or unicode depending of what dir reader we use | 17:30 |
vila | jam: exactly | 17:30 |
jam | We use this so that internal to dirstate, we don't have do .decode('utf8') every file | 17:30 |
jam | sorry | 17:30 |
jam | every ptah | 17:30 |
jam | path | 17:30 |
jam | on UTF-8 filesystems, etc. | 17:31 |
vila | yes, same page | 17:31 |
jam | So it sounds like you're finding that the _content_filter stuff *requires* a Unicode string? | 17:31 |
vila | so, do you agree that path is either unicode or utf8 encoded ? | 17:31 |
vila | tree.relpath does | 17:31 |
vila | AFAIK | 17:31 |
jam | vila: I think for current implementations, we do | 17:31 |
jam | I don't think the api requires that | 17:32 |
jam | so I think the problem is how stat_and_sha1 is intermingling with the walkdirs stuff | 17:32 |
jam | I think we already have a reasonable relpath available | 17:32 |
jam | we just *also* need abspath to actually open the file from disk | 17:32 |
vila | so pass both ? | 17:32 |
jam | something like that | 17:33 |
vila | with relpath=None as default ? | 17:33 |
jam | Let me look at the code a bit | 17:33 |
vila | jam: far more tests than actual code (and too much for me to fix it *today*, no problem if it can wait tomorrow) | 17:34 |
jam | if we look at _walkdirs_utf8 we have a bunch of things that are "utf8_relpath" etc. | 17:34 |
jam | vila: I just don't want "fixing" it on Mac to break it on Win32 | 17:34 |
vila | jam: I didn't fix it on mac, I fixed it on interpid | 17:34 |
vila | and I think BasicOSX is also on Linux | 17:35 |
jam | vila: how was it breaking there? (and why wouldn't it have been breaking on PQM) | 17:35 |
vila | jam: ha ha pqm, still the same LANG=C joke ? | 17:35 |
vila | it broke here with python -Werror | 17:35 |
jam | well, supposedly lifeless fixed PQM's LANG issue | 17:36 |
vila | lifeless filed a RT request, I don't know if it has been fixed yet | 17:36 |
jam | he mentioned the likelyhood that things may start breaking accidentally | 17:37 |
jam | so I thought it had happened | 17:37 |
vila | python -Werror ./bzr selftest -s bzrlib.tests.tree_implementations.test_test_trees.TestTreeShapes.test_tree_with_merged_utf8 | 17:38 |
jam | so certainly WT.relpath() is comparing the path with self.basedir | 17:38 |
vila | jam: can you try that ? | 17:38 |
jam | which should be a unicode string | 17:38 |
jam | vila: well, on Windows the tests pass | 17:38 |
jam | because they use Unicode strings for that argument :) | 17:39 |
vila | see ? That's the right fix ! :-) | 17:39 |
vila | lol | 17:39 |
jam | win32 walks in Unicode, because we get it directly from the FooW apis | 17:39 |
vila | jam: doh ! It passes on OSX too ! | 17:40 |
jam | vila: interesting, I get d to convert both arguments to Unicode - interpreting them as being unequal | 17:40 |
vila | ha wait, no extension built here | 17:40 |
jam | vila: right, it will pass without extensions, because the global fallback path is to walk using Unicode | 17:41 |
vila | did you use 'python -Werror' ? | 17:41 |
vila | jam: sure | 17:41 |
jam | vila: well with -Werror it fails, without it just warns | 17:41 |
jam | anyway | 17:41 |
jam | I would actually say the 'correct' fix is to do: | 17:41 |
jam | if type(x) is not unicode: | 17:42 |
jam | x.decode(_fs_enc) | 17:42 |
jam | however, at the moment | 17:42 |
jam | the code paths | 17:42 |
vila | jam: That's the bug ! That's why make check-dist-tarball fails | 17:42 |
jam | state that the only time x isn't unicode | 17:42 |
vila | because it uses python -Werror | 17:42 |
jam | is when fs_enc == utf-8 | 17:42 |
jam | so.... we have a utf-8 relpath already | 17:43 |
jam | it is part of the walkdirs api, and we could pass it into the stat function | 17:43 |
jam | but for ease... | 17:43 |
jam | vila: BB:tweak ... for now your fix is fine, as long as we update the documentation on SHA1Provider.stat_and_sha1() to declare that abspath | 17:46 |
jam | may be a filesystem encoded absolute path | 17:46 |
jam | since it is coming from walkdirs_utf8 | 17:47 |
vila | right, I'll then enhance the patch to provide relpath too and more importantly add some tests parametrization as discussed in brisbane | 17:48 |
jam | vila: the one thing to be aware of... relpath *might* be from a subdir of a directory, I'm not 100% sure where the 'walkdirs' is starting from. | 17:48 |
vila | jam: hmm | 17:49 |
jam | I'm thinking it can be trusted | 17:49 |
jam | I just need to poke around the code and make sure | 17:49 |
jam | vila: it should be fine | 17:52 |
jam | of course... | 17:53 |
vila | jam: ok, I'll add tests for it :) | 17:53 |
jam | this means that we'll have to decode every path again, but perhaps only if they miss the sha hash | 17:53 |
jam | which would be ok | 17:53 |
jam | sorry, the stat fingerprint hash cache | 17:54 |
vila | jam: what worries me more is that g_content_filter_stack queries for filters which may in turn result in IO... | 17:55 |
jam | vila: what IO, you mean having to read config files to figure out if there is a filter for the given file? | 18:04 |
vila | jam: things like that, I didn't dig that far to be 100% sure, just a bad feeling | 18:04 |
vila | since the SHA1Provider already cache the tree, I thought some more may need to be cached, but may be it's already the case and I should not worry | 18:05 |
vila | jam: last thing before I quit, did you had a look or have comments about bbc-1.14 ? Can you make sure BasicOSX is aware of it ? | 18:09 |
vila | s/did you had/did you have/ geee, why do I keep making that one... | 18:09 |
vila | ...is it correct ENglish or *not* ? | 18:10 |
jam | "did you have a look" | 18:11 |
jam | though "did you look at" is easier | 18:11 |
abentley | vila: Isn't it very similar to a French construction where the past tense is used? "As-tu eu.."? | 18:21 |
vila | abentley: that's where my error is coming most probably: As-tu jeté un coup d'oeil sur | 18:22 |
vila | my fingers and my brains walking at different speeds in parallel in French and English just mess things up :) | 18:23 |
vila | brain, mutli-core but still mon-brain :) | 18:23 |
vila | mono argh, time to stop :) | 18:23 |
vila | cooking time | 18:24 |
=== beuno_ is now known as beuno | ||
alaa_ | hey guys. So am getting a stack trace every time i run "bzr st". It is bzr 1.13. The error is TypeError: run() got an unexpected keyword argument "verbose" | 18:41 |
alaa_ | I'll file a bug a bit later, but is there anything i can do now? | 18:41 |
james_w | alaa_: you need to upgrade your copy of the bzr-loom plugin | 18:44 |
alaa_ | james_w: ah yes. I was just looking at the trace, and i saw the loom reference. I'll try that and report back | 18:44 |
alaa_ | james_w: That worked. So this is a known problem then, right? | 18:49 |
Peng_ | alaa_: Yes. Hence it being fixed in newer versions of bzr-loom. :P | 18:51 |
james_w | alaa_: yeah, I would guess that it is the most frequently reported bug in the history of bzr :-) | 18:51 |
alaa_ | Right. It's amazing how it got through since it is in the most used command in bzr :) | 18:54 |
alaa_ | james_w: thank you for your help | 18:54 |
james_w | np | 18:54 |
catojo | hello guys | 18:57 |
Peng_ | Hi | 18:57 |
catojo | Hi Peng_ | 18:58 |
catojo | Can, do you know how much sites that supports the bazaar ? | 18:58 |
Peng_ | What? | 18:58 |
catojo | So, I'm from brazil, thus, I do not speak english correctly. | 18:59 |
catojo | But i want to know how many sites supports bazaar | 18:59 |
catojo | I know launchpad only. | 19:00 |
Peng_ | catojo: Oh. SourceForge added support recently. | 19:00 |
catojo | Cool. | 19:00 |
catojo | I will see. | 19:00 |
catojo | Thanks. | 19:00 |
catojo | Peng_ | 19:01 |
catojo | A have a free software stored at sourceforge. | 19:02 |
catojo | But I'm use SVN. | 19:02 |
catojo | I will try to migrate to bazaar. | 19:02 |
Toksyuryel | bzr rocks | 19:02 |
Toksyuryel | :) | 19:02 |
beuno | It sure does! | 19:03 |
beuno | $ | 19:03 |
Peng_ | catojo: You can use bzr-svn to convert. http://bazaar-vcs.org/BzrForeignBranches/Subversion | 19:03 |
catojo | hmm | 19:03 |
catojo | I will see. | 19:03 |
catojo | Some people will go to FISL 10 ? | 19:04 |
catojo | http://fisl.softwarelivre.org/10/www/ | 19:04 |
Peng_ | beuno: So, which version of my Loggerhead YUI CDN thing do you like best? | 19:06 |
Peng_ | :D | 19:08 |
catojo | Peng_ Yahoo library ? | 19:08 |
catojo | javascript ? | 19:08 |
catojo | YUI | 19:09 |
Peng_ | catojo: Yes. | 19:09 |
catojo | Peng_ Javascript smells good. | 19:10 |
beuno | Peng_, I have options? | 19:10 |
beuno | did I not approve that branch? | 19:11 |
Peng_ | beuno: I made 3 different versions of my little patch. | 19:11 |
Peng_ | beuno: Sure, you did, and then I changed it again. :D | 19:11 |
beuno | ah! hehe | 19:11 |
beuno | ok | 19:11 |
beuno | so | 19:11 |
beuno | URL? | 19:11 |
beuno | and | 19:11 |
beuno | what's your preferencec? | 19:11 |
Peng_ | beuno: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/changes | 19:13 |
Peng_ | beuno: I think revision 322 is the prettiest, but revision 324/325 uses a single, combined JS file instead of half a dozen individual ones, so it should be faster. | 19:14 |
beuno | Peng_, agreed | 19:16 |
beuno | one comment | 19:16 |
beuno | how about not using "yui" as a variable name? | 19:16 |
beuno | ie, use cdn generically | 19:17 |
beuno | other than that, I'd love for that to be merged in | 19:17 |
beuno | don't forget to update NEWS | 19:17 |
Peng_ | beuno: Wait, so do you prefer 324/325 or 322? | 19:19 |
beuno | Peng_, I think 322, even though the URL is hardcoded | 19:20 |
beuno | and I know I complained about that | 19:21 |
beuno | I'm actually ok either way I think | 19:21 |
beuno | both are good, and both itch | 19:21 |
Peng_ | beuno: 324/325 just hardcodes it in the template, and in a more obfuscated way. | 19:21 |
beuno | yeah, that's what itches me about that | 19:21 |
Peng_ | :D | 19:21 |
beuno | so making the var names more generic, and landing 322 I think is a good compromise | 19:21 |
Peng_ | Which var names? | 19:22 |
beuno | use_yui_cdn | 19:23 |
beuno | and def yui_url | 19:23 |
beuno | I'd use: use_cdn, and cdn_url | 19:23 |
beuno | we're using YUI, but we're not married yet ;) | 19:23 |
beuno | maybe even the --yui-cdn | 19:24 |
beuno | to --use-cdn | 19:24 |
Peng_ | Hmm, I see your point. | 19:24 |
beuno | so if we change js libraries, people don't have to update their start scripts :) | 19:24 |
Peng_ | I kind of like the name "yui_url" for the function, though, since it *is* specific to YUI. | 19:24 |
beuno | true | 19:25 |
Peng_ | Well, it's just as specific as the rest of the code. Still, I'd prefer to make the other changes, but stick with "yui_url". | 19:25 |
beuno | I'm fine with that | 19:25 |
Peng_ | I guess it would have to be changed if the JS library is ever changed, but Loggerhead doesn't guarantee internal API stability anyway, does it? | 19:27 |
beuno | not for now, no | 19:27 |
beuno | I'm more concerned about changing things to the users | 19:27 |
Peng_ | Right. Users shouldn't care about the name of that method. | 19:29 |
Peng_ | (Which means *somebody* will, of course. :P ) | 19:29 |
beuno | heh, exactly | 19:31 |
Peng_ | Why are lines in NEWS only about 70 characters wide instead of 79? | 19:34 |
beuno | no idea | 19:34 |
beuno | crazyness | 19:34 |
beuno | like a lot of the rest of the code :) | 19:34 |
Peng_ | Heh. | 19:35 |
Peng_ | beuno: On a different subject, mind if I make LoggerheadConfig a new-style class? Can I do it directly in the trunk without getting reviewed? :D | 19:36 |
beuno | Peng_, Go for it. | 19:37 |
Peng_ | Thanks. | 19:37 |
beuno | this is why you got access to trunk! lower barrier to JFDI stuff | 19:37 |
Peng_ | beuno: Yeah, but I'm still afraid to do it. How much am I allowed to JFD? Trivial things like that? Simple bug fixes? | 19:38 |
beuno | Peng_, in general, it's small bits that don't change anything drastically | 19:39 |
beuno | very small bug fixes, doc changes, etc | 19:39 |
beuno | reviews are a fantastic safety net, and as we get more tests, we may even get a PQM | 19:40 |
Peng_ | Oh, neat. | 19:40 |
beuno | so we can ensure tests pass as well | 19:40 |
Peng_ | Well, I just did it. Pushing to LP is slow! | 19:41 |
Peng_ | (The LoggerheadConfig thing, I mean.) | 19:41 |
beuno | is it? | 19:42 |
beuno | it seems amazingly fast for me with 1.13 | 19:42 |
beuno | I use a checkout to commit to trunk | 19:42 |
beuno | merge in changes from the branch, and commit | 19:43 |
Peng_ | It was like 19 seconds vs. 4. Actually, I'm not sure why. They should both be new enough. Maybe it's just because LP is farther away from me. | 19:43 |
beuno | maybe it autopacked? | 19:43 |
abentley | jam: ping | 19:46 |
beuno | Peng_, I've added 'debug_flags = hpss' to my bazaar.conf | 19:46 |
Peng_ | beuno: It didn't autopack. bazaar.lp seems just plain slow ATM. | 19:46 |
beuno | so you can always look at the logs when these things happen | 19:47 |
beuno | Peng_, could be. mwhudson was working on something with ssh auth | 19:47 |
Peng_ | beuno: Seems slow over HTTP too. | 19:48 |
LarstiQ | Peng_: mail wrapping is usually 72 or 70 characters. | 19:48 |
Peng_ | LarstiQ: Ah, good point. | 19:48 |
Peng_ | beuno: Yeah, but it'll make .bzr.log *really* spammy. | 19:48 |
beuno | Peng_, yes, also called useful :) | 19:49 |
Peng_ | beuno: So, the diff for yui-cdn currently looks like this: http://paste.pocoo.org/show/111505/ bb:approve? | 19:49 |
Peng_ | beuno: But it won't be useful very often. | 19:49 |
beuno | and it tells you how many hpss calls where made | 19:49 |
Peng_ | Hmm, I *do* like weird statistics. | 19:49 |
LarstiQ | :) | 19:49 |
beuno | Peng_, where is yui_url called from now? | 19:51 |
Peng_ | beuno: macros.pt. | 19:52 |
beuno | aha | 19:52 |
beuno | Peng_, bb:approve | 19:52 |
beuno | or lp:approve (?) | 19:52 |
abentley | beuno: " review approve" | 19:53 |
Peng_ | abentley: That's longer. :P And "Bundly Buggy" sounds cool. | 19:53 |
Peng_ | Makes me want to chew bubble gum. | 19:54 |
Peng_ | beuno: Can I land it? | 19:54 |
abentley | Peng_: Thanks. I like the name, though it makes less sense now that it's primarily tracking merge directives. | 19:54 |
Peng_ | abentley: True, but cool > sensible. | 19:55 |
Peng_ | beuno: wb? | 19:57 |
beuno_ | yeah, my ISP is sucking big time | 19:57 |
=== beuno_ is now known as beuno | ||
Peng_ | < Peng_> beuno: Can I land it? | 19:57 |
beuno | Peng_, yes! | 19:58 |
beuno | 15:52 < beuno> Peng_, bb:approve | 19:58 |
beuno | 15:52 < beuno> or lp:approve (?) | 19:58 |
beuno | but of course, that got eaten by the internets blackhole | 19:58 |
Peng_ | beuno: It came through, but I wasn't sure if we should wait on mwhudson or something. (Sorry for the highlight, mwhudson.) | 19:59 |
beuno | Peng_, I think our policy is just 1 review | 19:59 |
Peng_ | Okay. | 20:00 |
bpierre | hi | 20:01 |
Peng_ | beuno: Pushed to my server in 6.57 seconds and LP in 33.05. | 20:02 |
Peng_ | Isn't there some weird performance issue with certain versions of certain things? | 20:02 |
beuno | Peng_, you've downgraded to 1.13, right? | 20:03 |
Peng_ | beuno: Nope. | 20:03 |
Peng_ | beuno: I used http to work around the AbsentContentFactory issue the one time I hit it. | 20:04 |
beuno | ah | 20:04 |
beuno | well, ~1.14 works amazingly well with 1.13 | 20:04 |
beuno | so maybe it's the ssh problem | 20:04 |
beuno | rockstar, abentley, any ideas ^? | 20:04 |
bpierre | I'm trying to use the new code in bzr.dev for EOL handling, and so far nothing work: I've created a 1.14 format branch, added some files, then put '[name *]' 'eol = crlf' in ~/.bazaar/rules, so if I branch the initial branch I should get windows like EOL, right? | 20:05 |
rockstar | beuno, mwhudson was saying something about a regression between 1.13 and older versions of bzr on the client. That's all I know though. | 20:06 |
abentley | beuno: Sorry, no. Others are investigating slow username lookups, which may be related. | 20:06 |
rockstar | abentley, ah, I forgot about that. | 20:07 |
Peng_ | abentley: Slow username looks? What does that impact? Regular old push to bzr+ssh://bazaar.lp.net? | 20:08 |
Peng_ | s/looks/lookups/ | 20:08 |
abentley | Peng: any sftp or ssh access to bazaar.lp.net | 20:08 |
Peng_ | abentley: Ah. That could do it, then, I guess. | 20:09 |
Peng_ | Thanks for the hand-holding. :) | 20:22 |
fbond | Can I pull without updating the working tree? | 20:46 |
james_w | not from the UI I don't think | 20:48 |
rockstar | abentley, hey | 20:57 |
abentley | rockstar: hey | 20:58 |
rockstar | abentley, get_rev_id seems to be confused. | 20:58 |
abentley | rockstar: how so? | 20:58 |
rockstar | So I pass in the revno, and it throws a NoSuchRevision exception, even though I navigated from the history listing of the branch by clicking that revno. | 20:59 |
rockstar | abentley, I'm sure it's because I'm confused, but the documentation looks pretty plain that I just pass in a revno. | 21:01 |
abentley | rockstar: Is it an integer revno, or does it have dots? | 21:01 |
bpierre | did you pass a string or a integer? I recently got a problem with buildbot because of that (after upgrading bzr) | 21:01 |
rockstar | abentley, in this case, it's an integer revno. | 21:04 |
rockstar | abentley, I can take it all the way back to revno 1, and it says it doesn't exist. | 21:04 |
abentley | rockstar: It works for me. | 21:06 |
rockstar | abentley, :( | 21:06 |
abentley | rockstar: https://pastebin.canonical.com/16055/ | 21:07 |
rockstar | abentley, I think I figured it out. The revno was actually '322' | 21:07 |
jelmer | 'evening abentley, rockstar | 21:07 |
abentley | jelmer: Hi. | 21:07 |
rockstar | Hi jelmer | 21:07 |
jelmer | abentley: Do you know what the expected behaviour of revno's is when there are ghosts in the lhs history? | 21:07 |
rockstar | abentley, so it doesn't handle strings that can be converted to integers. | 21:07 |
rockstar | abentley, does this mean I can't get the dotted revnos then? | 21:07 |
bpierre | exactly my problem! | 21:07 |
abentley | rockstar: No, it doesn't. | 21:08 |
abentley | rockstar: That's UI-level functionality. | 21:08 |
abentley | rockstar: Branch doesn't fold, spindle or mutilate its input. | 21:08 |
jelmer | abentley: simply count the first known revid as revno 1? | 21:08 |
rockstar | abentley, that's a good contract, I just needed to figure it out. | 21:08 |
abentley | jelmer: No, it should work backwards from the current revid/revno | 21:09 |
rockstar | abentley, so if I get a dotted revno, how would I get that revid? | 21:09 |
abentley | jelmer: Due to ghosts, the revids for some revnos may not be known. | 21:09 |
jelmer | abentley: ah, that makes sense | 21:10 |
abentley | rockstar: Branch.get_revision_id_to_revno_map | 21:10 |
abentley | rockstar: That operation is much more expensive, and makes sense to cache. | 21:11 |
jelmer | abentley: so in the case that we don't have a reference revno when the revno is unknown, what is the expected behaviour? revno=-1, revno=None or is that simply not possible yet? | 21:11 |
abentley | jelmer: I don't think that case is possible. If we had to handle that case, I'd probably assign the ghost to revno 1. | 21:12 |
jelmer | abentley: ok, that makes sense. thanks | 21:12 |
Necoro | wow ... I just noticed that loggerhead now has syntax highlighting :) | 21:48 |
Necoro | thanks to the author :) | 21:48 |
lifeless | Necoro: :) | 21:53 |
lifeless | mwhudson: was that you? | 21:53 |
mwhudson | lifeless: it was originally a patch from peter bui iirc | 22:06 |
mwhudson | Peng_ and i improved it a big | 22:06 |
mwhudson | *bit | 22:11 |
thumper | a big bit? | 22:13 |
Bluehorn | Hrm, when branching, what does this error message tell me: KnitPackRepository('file://...') is not compatible with | 22:14 |
Bluehorn | KnitPackRepository(...) different rich root support | 22:14 |
Bluehorn | I am branching bzr-builddeb from launchpad into a directory created using bzr init-repo. | 22:14 |
Bluehorn | What worries me is that the message basically tells me, $foo is incompatible with $foo (same values for $foo ;-)) | 22:15 |
cody-somerville | Upgrade your repo | 22:16 |
Peng_ | Bluehorn: They're both KnitPackRepositories, but one has the "rich root" flag on and one doesn't. Yes, the message is rather unhelpful. | 22:17 |
Peng_ | Bluehorn: Do you have any other branches in your repo? | 22:18 |
Peng_ | Bluehorn: What format did you create it in? The default (pack-0.92)? | 22:18 |
Bluehorn | Peng_: yep, default | 22:20 |
Bluehorn | Peng_: just bzr init-repo bzr-builddeb | 22:20 |
Bluehorn | Peng_: Just created a new repo, bzr init-repo --rich-root bzr-builddeb | 22:20 |
jelmer | hmm | 22:21 |
jelmer | 1.15 is going to be awesome | 22:21 |
Bluehorn | Peng_: But I have to admit that the different formats (suggested by bzr help upgrade) are a djungle. | 22:21 |
lifeless | Bluehorn: we are working to remove them all | 22:21 |
Bluehorn | Peng_: I'll go and read bzr help formats | 22:21 |
Bluehorn | lifeless: but you will need backwards compatibility, no? | 22:21 |
lifeless | Bluehorn: yes, but that doesn't mean showing you everything under the sun | 22:22 |
Bluehorn | lifeless: :) | 22:22 |
beuno | lifeless, I see brisbane-core has landed? | 22:22 |
Bluehorn | nice. bzr branch tells me that my repository is deprecated and I should run bzr upgrade. bzr upgrade tells me: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data. | 22:22 |
Bluehorn | so what is the latest and greatest format for rich root repositories? | 22:23 |
james_w | --1.6-rich-root would be recent | 22:23 |
=== samurai_ is now known as samiam | ||
james_w | --1.9-rich-root is the shiniest | 22:24 |
james_w | --development6-rich-root will eat your pets but will be very shiny indeed soon | 22:24 |
lifeless | Bluehorn: --default-rich-root is what you should use if you need rich roots; | 22:24 |
beuno | how's the performance between 1.6 and development6-rich-root? | 22:25 |
lifeless | Bluehorn: note that rich roots are a *one-way* upgrade,so only use them if you know you need to, and don't branch other projects into the same repo | 22:25 |
lifeless | Bluehorn: once we make rich roots the default this advice will go away :) | 22:25 |
Bluehorn | james_w: just upgraded to 1.9-rr. thanks! | 22:26 |
=== samiam is now known as release | ||
Peng_ | Of course, one of the major reasons rich roots aren't the default yet is *because* they're a one-way upgrade. Yay chickens and eggs. | 22:26 |
lifeless | mmmm omelete | 22:27 |
Peng_ | Or some other metaphor or whatever. | 22:27 |
lifeless | jelmer: ah I remember why I pung | 22:28 |
lifeless | I wanted to ask if its cool and accurate to say 'samba4 uses subunit' | 22:29 |
jelmer | lifeless: yeah | 22:30 |
jelmer | lifeless: so far it's mainly the subunit *protocol* though, not yet the subunit project | 22:30 |
lifeless | jelmer: same thing IMO :) | 22:31 |
jelmer | lifeless: I actually hope we can ship with a subunit parser that can do formatting for the buildfarm | 22:31 |
lifeless | would be good | 22:32 |
lifeless | you know I'm very happy to add a perl/ module to upstream | 22:32 |
jelmer | lifeless: and allow developers to use the subunit projects' fancy tools if they have them on their system elsewhere | 22:32 |
jelmer | lifeless: I might contribute back our perl parser at some point, but I need to make it a bit less hackish first | 22:33 |
lifeless | jelmer: why? [less hackish] - I'm not qualified to critique perl code beyond simple readability | 22:33 |
Peng_ | jelmer: Is it a good idea for bzr.dev users to switch to bzr-svn 0.6 now? Will it be really unstable for a while or anything? | 22:36 |
jelmer | lifeless: in particular the API should be hashed out, don't want to break it on people | 22:39 |
jelmer | Peng_: yeah, that should be fine. the main thing atm is that you won't have dpush yet | 22:40 |
lifeless | jelmer: you could put it up with a note saying clearly 'unstable api' | 22:40 |
lifeless | better an unstable api than none | 22:40 |
jelmer | lifeless: or I could just fix it and then contribute it rather than contributing it now, then fixing it, then sending updates :-) | 22:40 |
lifeless | jelmer: up to you | 22:43 |
lifeless | jelmer: just encouraging release early release often, where it seems possible without great risk | 22:44 |
lifeless | jelmer: from my perspective you'd basically own a perl/ subdir; commit directly to it if you want | 22:47 |
james_w | statik: ooh, thanks :-) | 22:56 |
lifeless | james_w: ? | 22:56 |
james_w | in response to a mail | 22:57 |
lifeless | I'm naturally nosey | 22:57 |
lifeless | Odd_Bloke: how does whoosh compare to bzr-search in terms of performance? | 23:15 |
Odd_Bloke | lifeless: I've never used bzr-search, so I don't really know. | 23:18 |
Odd_Bloke | For that matter, I haven't used Whoosh in any performance-critical manner. | 23:18 |
lifeless | ok | 23:18 |
vila | pqm announces: bbc landed in 1.14 :-) | 23:25 |
lifeless | thanks vila | 23:26 |
vila | lifeless: thanks BasicOSX (who manages to *avoid* that annoucement :-) | 23:26 |
lifeless | did you incorporate peng's doc fix for it? | 23:26 |
vila | I don't think so, | 23:27 |
Peng_ | \o/ | 23:27 |
vila | but I also think that the doc fix was making unclear that non rich root format can be imported | 23:28 |
BasicOSX | when will the 1.13.2 stuff be ready :-) | 23:30 |
vila | but the fix is available for all (especially those mastering English :) to comment | 23:30 |
* vila goes to sleep now | 23:30 | |
lifeless | BasicOSX: jam and vila had issues with it yesterday, spiv and I will tackle it more today | 23:31 |
Peng_ | vila: Hmm, you have a point. | 23:31 |
BasicOSX | woah... poolie ! :-) | 23:31 |
poolie | hello! | 23:32 |
BasicOSX | Anymore stuff to squeeze into 1.14rc1? | 23:32 |
lifeless | BasicOSX: no, I think the 1.13.2 fix can go into whatever 1.14 we're up to when its ready - don't block on it | 23:32 |
poolie | i literally just logged in to a computer for the first time in 12 days | 23:32 |
poolie | so i presume you're not asking me :) | 23:32 |
Peng_ | poolie: Well, if you can think of anything... :D | 23:33 |
BasicOSX | poolie: not asking you ;-) | 23:33 |
BasicOSX | Peng: >8-( | 23:33 |
poolie | oh typing feels weird :) | 23:33 |
poolie | hello lifeless, peng | 23:33 |
Peng_ | Hi! :) | 23:34 |
Peng_ | BasicOSX: But if there weren't dozens of things being squeezed in at the last minute, wouldn't you feel underutilized? :) | 23:34 |
lifeless | welcome back poolie | 23:34 |
BasicOSX | Peng: ironically, that would be the truth :-) | 23:35 |
* BasicOSX cheers | 23:36 | |
BasicOSX | All test pass now | 23:36 |
james_w | hey poolie | 23:43 |
poolie | hello james_w | 23:45 |
BasicOSX | should I just close the bugs listed as closed in the NEWS but are still listed as open by tools/check-newsbugs.py ? | 23:47 |
poolie | BasicOSX: probably not just close them, but check whether they ought to be closed | 23:48 |
poolie | it's possible some were eg reopened later, or not totally fixed | 23:48 |
poolie | are there many of them? | 23:48 |
BasicOSX | ok, I opened bug on it, bug 354984 | 23:49 |
ubottu | Launchpad bug 354984 in bzr "./tools/check-newsbugs.py NEWS found issues" [Undecided,New] https://launchpad.net/bugs/354984 | 23:49 |
thumper | abentley: are you still waiting on a review for your big nested tree branch? | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!