| maxb | jam: It's a LP bug. It's failed to publish a build-dep on lpia | 00:01 |
|---|---|---|
| maxb | nooo, new bzr-git failure on hardy | 00:03 |
| === zyga is now known as zyga-afk | ||
| === Meths_ is now known as Meths | ||
| quotemstr | How can I merge changes HEAD-2 and HEAD-3 in the history? | 03:50 |
| === Ursinha is now known as Ursinha-afk | ||
| chx | hi. if i use --hardlink but then edit a file ... how can i make sure my editor breaks the hardlink? | 07:02 |
| bob2 | depends on the editor | 07:03 |
| chx | i see. can nano do it? can a file system configured to do it, in general ? | 07:03 |
| bob2 | no | 07:03 |
| bob2 | to (b) | 07:03 |
| bob2 | dunno if nano can/does by default | 07:04 |
| lifeless | there is an ldpreload hack to break them | 07:37 |
| chx | lifeless: FL-COW? | 07:50 |
| fullermd | Urp. Bookmarks is broken with .dev :( | 07:53 |
| === zyga-afk is now known as zyga | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| damd | hi. i have a weird problem which only happens when i use vc-bzr in emacs, but maybe someone here can help me anyways? | 12:39 |
| damd | when i do "C-x v =" on a file in emacs (bzr diff equivalent) i get: bzr: ERROR: [Error 2] The system cannot find the file specified | 12:40 |
| damd | however, when i do "bzr diff that/file.el" in cmd.exe it works just fine | 12:40 |
| damd | any ideas? | 12:41 |
| Tak | can you find out what actual filename emacs is using? | 12:44 |
| Tak | i.e. is it just trying to do `bzr diff file.el` | 12:44 |
| damd | i've tried to look in the source code, reluctant to modify it, but what the hell, what's the worst thing that can happen... let me check | 12:45 |
| Tak | well, if it logs someplace or something... | 12:46 |
| damd | it doesn't | 12:46 |
| * Tak not familiar with emacs nor vc-bzr | 12:46 | |
| damd | i noticed just now that if the file has no changes, everything works as expected saying "no changes found" or similar | 12:52 |
| damd | so it's something that happens when it determines that there are changes | 12:52 |
| damd | okay, i think i've found the problem and it must be on emacs's side | 13:01 |
| damd | "Running bzr diff --diff-options -c vc-bzr.el in background... done" | 13:01 |
| damd | i don't think the working directory is correct | 13:01 |
| damd | therefore it can't find vc-bzr.el | 13:01 |
| damd | actually, i guess that's not the problem, since it works right when there are no changes | 13:06 |
| damd | okay, running the same command that emacs uses in cmd.exe gives me the same error abut a file not being found | 13:17 |
| damd | i'm guessing that this file is "diff" | 13:17 |
| === Ursinha is now known as Ursinha-lunch | ||
| === tchan1 is now known as tchan | ||
| vila | damd: sounds pretty weird | 14:09 |
| vila | damd: --diff-options without options for a given diff is suspicious | 14:09 |
| damd | vila: i wrote a patch for vc-bzr-diff which takes care of it | 14:10 |
| vila | damd: bzr has an internal diff, so I suspect having --diff-options triggers using an external 'diff' which it doesn't find | 14:10 |
| damd | exactly | 14:10 |
| vila | ha good | 14:10 |
| vila | damd: the fact that you're using windows may make the bug more obvious too | 14:10 |
| damd | i would have pushed the patch immediately if i had the time/ability to test it properly | 14:10 |
| vila | damd: are you running emacs from source or from a official release ? | 14:11 |
| damd | from weekly windows builds | 14:11 |
| vila | I see | 14:11 |
| * vila should really switch to vc and stop using dvc if only for test purposes | 14:12 | |
| damd | vc is really nice when you get the hang of it | 14:12 |
| vila | I haven't use it for years | 14:12 |
| damd | why do all things emacs have so ugly logos? | 14:15 |
| damd | the emacs logo itself, the gnu logo, and now the DVC logo, christ that's bad | 14:16 |
| damd | http://download.gna.org/dvc/dvc.png | 14:16 |
| vila | aw, come on there are not that bad :) | 14:18 |
| damd | the DVC logo is probably one of the worst logo's i've seen :| | 14:18 |
| vila | actually the dvc is a nice variation of the emacs one (when you like the later ;) | 14:18 |
| damd | they've literally _forced_ it to look like it says DVC on that gnu head | 14:18 |
| damd | actually, that's what they did with the emacs logo as well... forced it to look like a gnu and now it looks like neither a gnu nor emacs | 14:19 |
| vila | well, the oldest logo I can remember for emacs was a kitchen sink :) | 14:19 |
| damd | yeah, i've seen that, but at least that wasn't official :P | 14:19 |
| vila | hmm, as official as it can be as this time: http://www.emacswiki.org/emacs/EmacsIcons | 14:20 |
| vila | I think even Lucid Emacs was using the kitchen sink icon, at least I was using lucid in these times so that's probably where I remember the icon from | 14:22 |
| damd | i thought only some "funny" distros shipped emacs with that icon | 14:23 |
| damd | this is the emacs icon that is the default in windows: http://www.emacswiki.org/pics/static/CarbonEmacsPackageIcon.png | 14:23 |
| vila | yeah, this one has been around for ehat... ~ 10 years ? | 14:25 |
| vila | ha no, the pencil was added at some point | 14:25 |
| damd | no idea, i only started using emacs about five years ago | 14:25 |
| damd | honestly, if i were to create an emacs logo, i wouldn't know where to start, but i _would_ know where to _not_ start and that is with the current gnu thing | 14:25 |
| vila | hehe | 14:26 |
| damd | enough senseless ranting for now! | 14:26 |
| vila | mwahaha, best wallpaper ever : http://i.imgur.com/RxlwP.png | 14:27 |
| damd | see, even the wallpapers are ugly :( | 14:28 |
| vila | lol | 14:28 |
| vila | scratch this itch ! | 14:28 |
| damd | yeah | 14:28 |
| mgz | http://paste.ubuntu.com/558550/ <- that's a lot of PointlesslyBreakThings lines. | 14:30 |
| mgz | do I need to add a tests for all of the ones that get fixed, or just trust people not to write broken code in future... | 14:31 |
| vila | mgz: hellllo ! | 14:32 |
| mgz | hey vila! | 14:33 |
| vila | mgz: what's the context ? | 14:33 |
| mgz | bug 707954 | 14:33 |
| ubot5 | Launchpad bug 707954 in Bazaar "bzr mv cause ERROR: exceptions.UnicodeEncodeError" [Low,In progress] https://launchpad.net/bugs/707954 | 14:33 |
| === Ursinha-lunch is now known as Ursinha | ||
| vila | str(xx) considered harmless ? | 14:33 |
| vila | harmful I meant | 14:33 |
| mgz | http://paste.ubuntu.com/558552/ <- example test. | 14:34 |
| mgz | str(any_path) is harmful, yup. bzr uses unicode for paths. | 14:34 |
| vila | ha ! yeah, so my last memories was running away crying from the rename exceptions | 14:34 |
| vila | adding tests to ensure we cover all code paths there will be ideal | 14:35 |
| vila | second to that would be to get rid of the str() harmful calls, but finding them and fixing them without tests may be tricky | 14:36 |
| vila | so to come back to your initial question, if you can add a test for every call your fix: perfect | 14:37 |
| vila | trying to avoid future errors... no idea on how to do that (the tests should be a good defense anyhow) | 14:37 |
| mgz | I'm guessing not to blackbox though. | 14:37 |
| vila | depends which layer you want to test | 14:38 |
| mgz | well, ideally lower if I'm covering all those. | 14:39 |
| vila | yup, my memory tells me the relevant code is indeed lower | 14:41 |
| mgz | it's WorkingTree.move ._determine_mv_mode .rename_one | 14:41 |
| vila | have a look at the related exceptions too, that's where I started crying | 14:41 |
| mgz | yeah, they're a bit of a mess. | 14:42 |
| vila | at one point I got lost because exceptions were raised when trying to format an exception | 14:42 |
| mgz | as is the general code for displaying errors about paths, eg bug 388437 | 14:42 |
| ubot5 | Launchpad bug 388437 in Bazaar "notbrancherror doesn't show non-ascii paths correctly" [Medium,In progress] https://launchpad.net/bugs/388437 | 14:42 |
| vila | related to that, | 14:43 |
| mgz | ^I need to fix some of this in another branch anyway | 14:43 |
| vila | the unicode exceptions have an attribute with the faulty string but it's not displayed by default | 14:43 |
| mgz | yeah, that'll be worth doing on top. | 14:43 |
| vila | I was wondering if we could catch them in the bzr script (or wherever the exceptions are caught).. you see the point | 14:44 |
| mgz | yup. | 14:44 |
| vila | I'm still awfully jet lagged so you type too fast for me ;) | 14:44 |
| mgz | so... where are WorkingTree methods tested? | 14:44 |
| vila | did you see the bash_completion failures on windows ? | 14:45 |
| vila | per_tree ? | 14:45 |
| vila | bt.per_tree, bt.per_workingtree | 14:45 |
| mgz | ah, yeah. | 14:45 |
| vila | or may be these ones aren't :-/ | 14:45 |
| vila | I'd so love to add a 'raise' somewhere that would make all the relevant tests fail... | 14:46 |
| mgz | ^nope. | 14:46 |
| vila | -s bp.bash_completion -> 4 failures | 14:46 |
| vila | can you reproduce that ? | 14:47 |
| mgz | it's not really worth testing at all on windows though, and I thought wasn't. | 14:47 |
| mgz | "Missing feature 'bash executable' skipped 12 tests." | 14:47 |
| mgz | so, unlikely to get them. | 14:47 |
| vila | well, I thought that too, but babune was happy with them before... | 14:48 |
| vila | hmm | 14:48 |
| vila | jam: around ? | 14:48 |
| mgz | testing a cygwin bash under the windows python isn't very worthwhile. | 14:48 |
| jam | hi vila | 14:48 |
| vila | jam: hello ! | 14:48 |
| jam | I'm currently on windows, but I ran the test and it gave "missing bash executable" | 14:49 |
| vila | can you run -s bp.bash_completion in your windows setup... damn | 14:49 |
| jam | I'll try and check into it a bit | 14:49 |
| jam | I run the win32 python under cygwin | 14:49 |
| jam | so I would have thought path would be correct | 14:49 |
| vila | rats, babune has no log about the features and skipped tests :( | 14:51 |
| mgz | 2.7 logs skips sensibly now, but the win slave is on 2.6 right? | 14:52 |
| jam | strange | 14:54 |
| jam | running python manually, I see cygwin in the path | 14:54 |
| jam | and running "p = subprocess.Popen('bash -c "echo hello"', shell=True)" works | 14:54 |
| jam | ah, it's the probe | 14:55 |
| jam | it specifically probes for the exact name "bash" in the path | 14:55 |
| jam | so it won't find "bash.exe" | 14:56 |
| vila | haaaa ! doxxx fix ! | 14:56 |
| jam | so why is it finding it for vila | 14:56 |
| vila | in its mergetools proposal gordon tweaked osutils.find_executable_on_path, with weird bits for windows I didn't fully understand | 14:56 |
| vila | so my guess is that it makes it find exes that weren't found previously | 14:57 |
| vila | using a trick that is *not* used when calling the exe, so the probe succeeds now (it was failing before) and the tests now failed (they were skipped before) | 14:58 |
| jam | vila: yep | 14:58 |
| jam | vila: well, I wouldn't be surprised if the tests fail because it isn't compatible | 14:58 |
| vila | which means babune reports skipped tests as successful ones... :-/ | 14:58 |
| jam | more than just because it can't find it | 14:58 |
| vila | true | 14:58 |
| jam | vila: right, the code in test_bashcomp.py looks to be using the exact path to 'bash' | 14:58 |
| jam | and not using shell=True | 14:59 |
| vila | hmm, not using shell=True is harmless on unices ? | 14:59 |
| * vila never uses shell=True | 15:00 | |
| mgz | hm, I don't know how to hit some of these branches. | 15:03 |
| vila | mgz: scary ;) | 15:06 |
| mgz | ...the test just above where I'm adding these looks totally bogus too | 15:10 |
| mgz | self.assertRaises((errors.InvalidNormalization, UnicodeEncodeError), | 15:10 |
| mgz | tree.rename_one, 'a', u'ba\u030arry') | 15:10 |
| mgz | what the hell kind of check is that? it will *always* be raising the second exception, which If A Real User Did It, would print a big ugly traceback. | 15:11 |
| wash | Do the latest versions of bzr-svn support any form of setting SVN properties (specifically, svn:eol-style and svn:mime-type)? | 15:11 |
| vila | mgz: this makes sense | 15:11 |
| vila | mgz: that's what the bug you're fixing is about | 15:11 |
| maxb | wash: No, there is no way to explcitly edit user svn properties through bzr-svn | 15:12 |
| vila | mgz: except that we now know that it's a bug and not an expected behavior | 15:12 |
| wash | maxb: *nods* Thanks | 15:14 |
| jam | mgz: check the annotate on that file. I probably wrote that code about 3-4 years ago | 15:17 |
| jam | back when I was working on supporting normalization inside bzr | 15:18 |
| jam | I know it pre-dated dirstate | 15:18 |
| jam | which was what, 0.15 ? | 15:18 |
| mgz | yeah, it's old, and I'm not even sure why the UnicodeEncodeError is checked for from the history | 15:18 |
| vila | jam: are you sure it hasn't been modified when the rename exceptions have been introduced ? | 15:18 |
| mgz | possibly for when unicode paths aren't supported at all? it's unclear. | 15:19 |
| vila | my gut feeling is that UnicodeEncodeError has been added at this point in time | 15:19 |
| jam | vila: could have been. I wouldn't be surprised if the test was saying "must raise InvalidNormalization" and someone decided to be lazy and have it raize Unicode | 15:19 |
| vila | mgz: you may want to check the InvalidNormalization one | 15:19 |
| vila | jam: yup, that's my feeling | 15:19 |
| jam | mgz: also note, I personally have stopped trying to fight that fight since getting normalization during status is pretty difficult to make it perform well | 15:20 |
| jam | and I ran into people on Windows not having normalized filenames | 15:21 |
| jam | because Japanese windows wanted to use all wide characters in the filename | 15:21 |
| mgz | NF(K)* is pretty deadly, but that's the K. | 15:21 |
| mgz | messes up kana as well as ＦＵＬＬＷＩＤＴＨ characters | 15:22 |
| vila | wow, nicely displayed here :) | 15:22 |
| mgz | something still needs to be sorted jam, because macs seem stuck in limbo wrt unicode at the moment in bzr | 15:22 |
| maxb | NFK* is evil madness | 15:23 |
| jam | mgz: Oh the system is pretty hosed at the moment. NFC is better than NFK, (AIUI) though I didn't know it back in the day | 15:23 |
| jam | however, *I personally* have stopped trying to fight for it. I'd be happy to review stuff | 15:24 |
| leonardr | i have a bzr question for anyone who can help | 15:24 |
| cody-somerville | leonardr, no one can at the moment as you haven't asked your question ;) | 15:24 |
| leonardr | cody: ah, that's the problem. i never asked my question | 15:25 |
| leonardr | i'll explain it in abstract terms but here's the merge proposal of the branch: https://code.launchpad.net/~leonardr/lazr.restful/encode-xhtml-field/+merge/47536 | 15:25 |
| jam | leonardr: I believe the standard line is: "Just ask the question, don't ask to ask", but honestly it is pretty ingrained in us that a polite interruption is the rigth thing to do... | 15:26 |
| leonardr | i do not want to get side tracked on this discussion, but to set the record straight, my first utterance was an introduction and i immediately proceeded to start writing the question | 15:26 |
| jam | I suppose in IRC you want short communication because everyone has to type? Not sure why that became standard | 15:26 |
| leonardr | the last release of this package was at revision 164 | 15:27 |
| leonardr | we're now at revision 166, and i need to do a point release based on revision 164 | 15:27 |
| leonardr | i can just do a release off my branch | 15:28 |
| leonardr | but i'd like to merge it in to the mainline so that it will be easy to find later | 15:28 |
| maxb | That all sounds correct.... where's the question? :-) | 15:29 |
| leonardr | my current plan is to revert to revision 164, commit, merge my branch, commit, do the point release, and then re-merge the code from revisions 155 and 156 | 15:29 |
| leonardr | is there a better way, or is that it? | 15:29 |
| maxb | eek | 15:29 |
| jam | leonardr: reverting is probably not what you want | 15:29 |
| mgz | just branch from -r 164 | 15:29 |
| vila | leonardr: just create a branch at... | 15:29 |
| leonardr | lp:~leonardr/lazr.restful/encode-xhtml-field is a branch from -r 164 | 15:30 |
| vila | leonardr: -r 164, do your release stuff (including commitS) | 15:30 |
| vila | leonardr: then merge your point release on top of your trunk resolving conflicts | 15:30 |
| vila | leonardr: this will reflect the exact history of what you did, pretty clean IMHO | 15:31 |
| leonardr | vila: my problem with that is that there will be no revision in trunk that corresponds to the release | 15:31 |
| maxb | There will be no *mainline* revision in trunk which corresponds to the release | 15:31 |
| vila | leonardr: it will and you can tag it | 15:31 |
| leonardr | vila: ok, what do i tag? | 15:32 |
| vila | leonardr: the tip in your release branch *before* merging it to trunk | 15:32 |
| leonardr | vila: thanks, that was the missing piece | 15:32 |
| vila | leonardr: if you look at bzr history, you'll see that the tags are never on the mainline, always on a dotted revno | 15:33 |
| maxb | .... in a PQM-managed project, which this is not | 15:33 |
| vila | maxb: right, but this shouldn't be a problem either | 15:33 |
| maxb | Not a problem, but it does make the statement that tags are never on mainline not applicable here | 15:34 |
| vila | ho ! | 15:34 |
| vila | right, my remark applied to bzr history *ONLY* | 15:34 |
| jam | maxb, vila: well *some* tags are on the mainline, for people like me that didn't like having to pre-tag before sending it to pqm, but we changed away from that because it was a real PITA to maintain. :) | 15:34 |
| maxb | Ah, the bzr history of bzr | 15:34 |
| vila | maxb: ouch, right, I missed the ambiguity there :-/ | 15:35 |
| maxb | leonardr: So, is this making sense? :-) | 15:35 |
| leonardr | maxb: not at all :) | 15:35 |
| jam | but yes, leonardr, I would tag your release branch, and then merge it, and not try to tag the trunk mainline | 15:35 |
| leonardr | ok, i'll do that and let you know how it goes | 15:35 |
| vila | jam: as can be seen in bzr-0.{7,8,11,13,14,15,16,17,18,90} ? :-D | 15:35 |
| jam | vila: did you just run bzr log to find that ? | 15:36 |
| vila | bzr tags | 15:36 |
| jam | or 'bzr tags' | 15:36 |
| jam | vila: some of those are "?" tags | 15:37 |
| vila | all of them | 15:37 |
| jam | so those were before we merged release branches back into trunk | 15:37 |
| jam | but I still wanted to track them once we finally got tags | 15:37 |
| jam | vila: actually, only bzr-0.0.5 is a mainline revno. | 15:38 |
| jam | I think I did the work to have the tag on the release branch mainline | 15:38 |
| vila | yup, and plan0merge-dev >_< | 15:38 |
| jam | vs my local branch that got merged into the release branch, which was then eventually merged on the mainline | 15:39 |
| jam | vila: I don't have plan0merge-dev tag | 15:39 |
| jam | so that must have been one of yours | 15:39 |
| vila | plan-merge-dev | 15:39 |
| jam | I do have "plan-merge-dev" and "plan-merge-ab" | 15:39 |
| maxb | leonardr: short version: bzr branch -r 164 lp:lazr.restful lazr.restful-0.15.x; cd lazr.restful-0.15.x; bzr merge lp:~leonardr/lazr.restful/encode-xhtml-field; bzr commit; <Standard release procedures, which ought to involve bzr tag>; cd ....../branch-or-checkout-of-trunk; bzr merge ....../lazr-restful-0.15.x; bzr commit; bzr push | 15:39 |
| jam | vila: interesting that plan-merge-dev is a (vila) commit | 15:40 |
| jam | :) | 15:40 |
| vila | I don't think so | 15:40 |
| leonardr | maxb: ok, i'll let you know if i get unexpected results, but if the bzr tag works it should be fine | 15:40 |
| vila | jam: it's from pqm and plan-merge-ab from aaron | 15:41 |
| maxb | leonardr: One specific point to note - to ensure trunk's history is not confusing, it's important to merge the release branch into trunk, and not vice versa | 15:41 |
| vila | jam: both from 200712 | 15:42 |
| jam | vila: it *is* a pqm revision, but it was a (vila) requested one :) I honestly don't know what the idea is | 15:42 |
| leonardr | maxb: sure. that's what i do usually, so it's no problem | 15:42 |
| jam | nor do I *really* care | 15:42 |
| leonardr | (except it's usually not a release branch) | 15:42 |
| jam | though it would be nice to be able to prune/hide tags | 15:42 |
| jam | 100 tags is getting a bit big, the 1000s of tags in an emacs branch is pretty overwhelming | 15:42 |
| maxb | hrm. bzr help does not tell you what the options are for tags --sort=??? | 15:43 |
| vila | jam: weird... I never used tags until being RM... | 15:44 |
| jam | maxb: probably a bug in the help system. If you don't specify that an option can be supplied without the prefix, then it doesn't document the values | 15:44 |
| tedg | Hey, I'm getting a really odd Bazaar error: "ValueError: could not convert string to float: /bfa.ko" | 15:44 |
| jam | vila: "bzr.dev" is now properly failing the bash_completion tests | 15:44 |
| tedg | Any clue on how to get back to a running state from that? | 15:45 |
| maxb | tedg: Do you have a traceback with that? | 15:45 |
| jam | tedg: doesn't look like a float to me :) | 15:45 |
| jam | can you give more of a traceback | 15:45 |
| tedg | Traceback (most recent call last): | 15:45 |
| tedg | File "/usr/bin/bzr", line 139, in <module> | 15:45 |
| tedg | exit_val = bzrlib.commands.main() | 15:45 |
| tedg | File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 1203, in main | 15:45 |
| tedg | _register_builtin_commands() | 15:45 |
| tedg | File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 182, in _register_builtin_commands | 15:45 |
| tedg | import bzrlib.builtins | 15:45 |
| tedg | Not much... | 15:45 |
| vila | !paste | 15:45 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 15:45 |
| tedg | bug 708063 | 15:46 |
| ubot5 | Launchpad bug 708063 in bzr (Ubuntu) "bzr crashed with ValueError in _register_builtin_commands(): could not convert string to float: /bfa.ko" [Undecided,New] https://launchpad.net/bugs/708063 | 15:46 |
| vila | tedg: ouch, sounds like a .pyc corruption no ? | 15:47 |
| vila | tedg: does 'bzr version' works ? | 15:47 |
| vila | tedg: or 'bzr info' | 15:47 |
| tedg | vila, No, neither of those work. | 15:47 |
| vila | tedg: right, so your install is... damaged ? | 15:48 |
| tedg | vila, Which pyc should I delete? | 15:48 |
| tedg | I can just remove the package and reinstall? | 15:48 |
| vila | tedg: well, yes | 15:48 |
| vila | tedg: but you may have a deeper issue there, .pyc files don't get corrupted randomly on well-behave machines ;) | 15:49 |
| vila | tedg: python-2.7 on lucid ?? | 15:50 |
| tedg | vila, Yeah, it's odd. But none the less, it works after the reinstall. | 15:51 |
| tedg | tedg, No on Natty | 15:51 |
| tedg | vila, ^ :) | 15:51 |
| vila | tedg: so InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) is misleading ? | 15:51 |
| tedg | vila, It's correct. That is what I used to install, then I upgraded. | 15:52 |
| vila | bah, of course, DistroRelease: Ubuntu 11.04 is the one I should have looked at | 15:52 |
| vila | tedg: anyway, good to know you're out of trouble | 15:52 |
| vila | I'll mark this bug invalid | 15:52 |
| tedg | Yes, thank you vila. I already marked it so. | 15:52 |
| vila | tedg: you rock, lp-cant-refresh sucks ;) | 15:53 |
| tedg | vila, It's not really a LP specific problem. The web in general sucks :) | 15:53 |
| vila | tedg: shooting the messenger :) | 15:58 |
| mgz | okay, get this baby reviewd time. | 16:34 |
| vila | mgz: :) | 16:37 |
| vila | jam: do you know a way to look at the pending jobs for the package importer ? | 16:37 |
| jam | vila: define "look at" | 16:37 |
| jam | http://package-import.ubuntu.com/status/ tells you what is pending | 16:38 |
| jam | and what is currently running, etc. | 16:38 |
| vila | it currently says 0 but tail -f progress_log shows it keeps adding some | 16:38 |
| vila | so I guess my question is: what's the difference between outstanding jobs and pending jobs | 16:39 |
| jam | vila: when the package importer doesn't have explicit packages to import, it then spins checking random packages for consistency | 16:39 |
| vila | ha, I haven't seen that code yet then | 16:39 |
| jam | so "Outstanding" means it has seen new .deb files that need to be imported | 16:40 |
| vila | I'm working on mass_import.py | 16:40 |
| jam | otherwise it is just poking around doing sanity checks | 16:40 |
| vila | right, and it never stops doing that | 16:40 |
| vila | so I think I will stop poking at this code and start looking at testing it before deploying... | 16:41 |
| mgz | hm, have a feeling there was something else I was going to say in the mp but can't remember it. | 16:46 |
| jam | vila: your mail host is blocking emails from me | 16:46 |
| jam | vila: Remote host said: 550 Too many spams from your IP (98.139.52.70), please visit http://postmaster.free.fr/ [RCPT_TO] | 16:47 |
| jam | and the page they link me to is in French, so I really don't know what to do | 16:47 |
| jam | (well, click the English button...) | 16:47 |
| vila | to put their spam filters were the sun doesn't shine ? | 16:47 |
| jam | it looks like they are blocking all email from some of the mail.*.yahoo.com servers | 16:48 |
| jam | at least, the IP they give resolves to: nm6-vm0.bullet.mail.ac4.yahoo.com | 16:48 |
| jam | which is a bit hard for me to workaround. | 16:49 |
| jam | I can send mail directly from my IP, but that is usually blacklisted because it is a comcast account | 16:49 |
| jam | (or whatever the rules are. It is a "home" account, which is often blanket blocked) | 16:49 |
| maxb | heh :-/ So apparently bzr-git/hardy has *never* worked | 16:54 |
| * maxb wonders whether it's still worth doing hardy in ~bzr PPAs | 16:54 | |
| vila | jam: try using my canonical address ? | 16:54 |
| === leonardr is now known as leonardr-afk | ||
| jam | maxb: I believe hardy is still in its support window | 16:56 |
| maxb | Yes, but that's not *quite* the same question :-) | 16:56 |
| jam | vila: I'm just resending to make sure it works, but it was a note about the bash completion failures from sometime last night | 16:57 |
| maxb | oh, just a moment | 16:57 |
| maxb | Did hardy default to apt installing recommends? | 16:58 |
| vila | maxb: that's not the highest priority, if people are happy with hardy (instead of lucid), they are probably happy with whatever bzr version they have | 16:58 |
| mgz | jelmer needs more imaginative branch names. | 16:58 |
| mgz | he's submitted like, five different things called lazy something this month. | 17:00 |
| mgz | vila: I'm going to have to put up a 2.3 branch that just messes with imports as I've not had time to work on the transport hook and 2.3 is past beta | 17:05 |
| jam | mgz: for your Unicode changes, isn't it just moving when the error occurs? I thought the exception formatter still treats everything via str() | 17:07 |
| mgz | I cheated. | 17:08 |
| mgz | in this case, it gets safely upcast to unicode, then BzrError.__str__ encodes it to utf-8 | 17:09 |
| mgz | I've got some other work that makes unicode things happen sensibly all the way down to bzrlib.trace | 17:09 |
| mgz | so, mojibake not UnicodeError | 17:12 |
| mgz | I'll add a note about this to the mp. | 17:12 |
| jam | well, its an improvement | 17:12 |
| catphish | does bzr have a native grep function? | 17:18 |
| catphish | (preferably in the CLI) | 17:18 |
| jam | catphish: there is a 'bzr-grep' plugin | 17:18 |
| vila | mgz: meh, why don't you just target 2.4 ? | 17:19 |
| catphish | jam: thanks, hopefully that'll do what i want :) | 17:19 |
| mgz | because I left a horrible hack in the code! | 17:19 |
| vila | mgz: with my blessing, send any complaint my way :) | 17:21 |
| mgz | hm, doesn't look like too many hits. | 17:25 |
| vila | mgz: you're referring to transport hook hack right ? | 17:28 |
| mgz | right. | 17:30 |
| === mnepton is now known as mneptok | ||
| vila | mgz: so nothing worth backporting to 2.3, target 2.4 :) | 17:39 |
| mgz | I'll put a mp up with some import changes and we'll see. | 17:40 |
| mgz | ...I actually intended that last mp to go to 2.3 as well, given it didn't change any interfaces, but perhaps 2.4 is safer. | 17:41 |
| === bigjools-afk is now known as bigjools | ||
| vila | mgz: yup | 17:43 |
| vila | EODing, bye all | 17:44 |
| mgz | bye! | 17:44 |
| maxb | What is the name of the format defining the :param foo: constructs in bzr docstrings? | 18:12 |
| === Meths_ is now known as Meths | ||
| lifeless | maxb: epydoc restful ? | 18:23 |
| maxb | thanks | 18:23 |
| === leonardr-afk is now known as leonardr | ||
| * jelmer waves | 19:13 | |
| james_w | hi jelmer | 19:14 |
| james_w | are you at LCA? | 19:14 |
| jelmer | hi james | 19:14 |
| jelmer | no, I'm in Seattle | 19:14 |
| james_w | ah yeah | 19:15 |
| maxb | jelmer: Hi. I've now discovered that bzr-git has in fact never ever been compatible with hardy's ancient python-tdb. I'm thinking of uploading a bzr-git/hardy to the ~bzr PPA with the Recommends: python-tdb dropped, and the default cache format hardcoded to sqlite even if python-tdb is installed. | 19:30 |
| jelmer | maxb: sounds reasonable | 19:32 |
| jelmer | maxb: I wonder how useful it would be to have bzr-git on hardy if it's never been packaged for hardy though | 19:33 |
| maxb | great. This bzr-git/dulwich update has been an epic :-/ | 19:33 |
| jelmer | maxb: is it really an update? have we ever hard bzr-git/dulwich available for hardy? | 19:34 |
| maxb | Well, we had previous versions in the PPA for hardy | 19:34 |
| jam | maxb, jelmer: Note that until fairly recently we still had production machines in LP on Hardy. However, they've all been transitioned to lucid, AFAIK | 19:47 |
| jam | I think LP itself went to lucid nov/dec last year | 19:48 |
| maxb | and there was much rejoicing :-) | 19:48 |
| jam | In Sept, there was "Don't use 2.6-isms because we are still running hardy" | 19:48 |
| jam | Oct 13th was the transition, it looks like | 19:48 |
| jam | anyway, that makes supporting Hardy much less interesting from at least Launchpad's standpoint | 19:49 |
| jelmer | maxb: that function in dulwich was never unit tested earlier | 19:50 |
| jelmer | maxb: (and bzr-git does its own patching of urlparse) | 19:51 |
| jam | mgz: do you need me to submit your non_ascii patch? | 19:52 |
| mgz | jam: I can do it. you have any opinion on whether it should have NEWS? | 19:53 |
| jam | it should have news | 19:53 |
| jam | I don't know that it merits whatsne | 19:53 |
| jam | whatsnew | 19:53 |
| mgz | will do that and push. | 19:54 |
| jam | Possibly, since it is a user-visible change, but definitely NEWS | 19:54 |
| jam | mgz: for your get_transport() change, this is all mechanical, right? You are just changing "from bzrlib.transport import get_transport" to "from bzrlib import transport" | 19:54 |
| mgz | it is. | 19:55 |
| mgz | diff in email is a little wrong because I suck, but I repushed the branch with a less screwed up first revision | 19:55 |
| jam | mgz: that one looks fine to me as well | 19:57 |
| mgz | pushed the first one. I'll let vila look at the other in the morning if he likes before pushing. | 20:15 |
| sinzui | I am interested in getting https://bugs.launchpad.net/bzr-gtk/+bug/707482 fixed. Is anyone minding bzr-gtk about | 20:38 |
| poolie | hi mgz, sinzui | 20:39 |
| poolie | sinzui, it seems like you're most of the way there | 20:40 |
| sinzui | I can make this fix if someone agrees I am on the right path | 20:40 |
| * poolie looks | 20:40 | |
| poolie | so which value is wrong? | 20:41 |
| poolie | i guess line_no? | 20:42 |
| sinzui | poolie: ganonnate's line_no and revno I think. UI is pretty simple, so changing the column types to int is probably right. Since gtktreeview reuses columns for layout when making a tree, casting to str() may be required | 20:42 |
| jam | hi poolie | 20:42 |
| poolie | sinzui, it's strange it's not failing before | 20:43 |
| poolie | i wonder if maverick's pygtk automatically casts or something? | 20:43 |
| poolie | i didn't think it did that | 20:43 |
| poolie | hi jam, how are you? | 20:44 |
| sinzui | pygtk 2.22+ behaves more like gtk | 20:44 |
| jam | poolie: doing well. Nice to see you online, though I worry it means you aren't sleeping all that well. | 20:44 |
| sinzui | poolie: There was a lot of implict goodness in pygtk that is lost as we gtk moves to 3 where there will be a standard api for all bindings | 20:44 |
| poolie | :) mm, i woke a bit before 7, which is pretty reasonable | 20:45 |
| poolie | sinzui, so, since i can't reproduce it, i suggest you change just lineno to type int and see what hapens | 20:45 |
| sinzui | poolie: but this brings up the crucial question what gtk and python is bzr-gtk targeting? | 20:45 |
| jam | strangely I've been waking up at just about exactly 6:51 since I got back. Not getting *up* mind you, but waking up. | 20:45 |
| jam | sinzui: we're certainly still targetting python 2 for the moment (unless you mean gtk v 3?) | 20:46 |
| sinzui | poolies casting with str() is very backward compatible with gtk2. changing the column types is not | 20:46 |
| poolie | ah | 20:47 |
| poolie | well, would we ever use a non-int line number? | 20:47 |
| sinzui | the early liststores had limited column types, which I believe is why the class uses just astring | 20:47 |
| sinzui | poolie: we care if we resorted the lines. We wont in this case | 20:48 |
| jam | I'm pretty sure line_no will always be an int, but revno will often be a str | 20:51 |
| jam | if it is hard to set a column type to int in older code, just go str, since as you mention, sort order doesn't matter | 20:52 |
| sinzui | thanks. I will put a branch together. I will also test the other widgets so that this class of error is fixed in a single effort | 20:55 |
| poolie | sinzui, ping me if you get stuck | 20:59 |
| sinzui | thanks | 20:59 |
| jam | poolie: have you seen the recent updates I did to the package-importer under-losa control discussion? | 21:00 |
| poolie | jam, can you join #ubuntu-meeting | 21:00 |
| poolie | no | 21:00 |
| jam | poolie: rt #39614 and bug #589521 | 21:00 |
| ubot5 | Launchpad bug 589521 in Ubuntu Distributed Development "nagios monitoring of package imports needed" [Critical,Triaged] https://launchpad.net/bugs/589521 | 21:00 |
| jam | summarizes my thoughts on it | 21:00 |
| poolie | ok, thanks | 21:01 |
| jam | short summary is that it needs a fair amount of development done before we can really give up direct access | 21:01 |
| poolie | elliot's suggestion at dallas, which i agree with, is that we should do things ourselves rather than handing it over | 21:01 |
| jam | (and i wonder if that effort would be better spent integrating it with the vcs-import stuff) | 21:01 |
| poolie | i thought i said that's what we'd do, and we'll just rely on them for low-level stuff | 21:01 |
| poolie | keeping the os running etc | 21:01 |
| jam | poolie: note that both the bug and the rt have expanded from "nagios integration" into "move to a new server completely controlled by losas" | 21:02 |
| lifeless | giving up direct access is a bit separate :) | 21:02 |
| lifeless | (I'm lending support, I hope) | 21:02 |
| poolie | thanks for the pointer; i'll look at it | 21:02 |
| poolie | the udd meeting is starting now; let's be there | 21:03 |
| jam | lifeless: it is technically separate, but the discussion on the RT was that we don't want to integrate with nagios, we want to move you to a new server and take away all control. Not that it has to be done that way. :) | 21:03 |
| lifeless | so the new server thing | 21:04 |
| lifeless | thats because its on a borrowed box that is labelled 'landscape backup db server' | 21:04 |
| jam | oh, I understand why | 21:15 |
| jam | just mentioning that one rt got taken over by about 5 different things that they wanted to do | 21:16 |
| lifeless | :) | 21:19 |
| === tomaw_ is now known as tomaw | ||
| nhandler | So does anyone know why I am unable to push to lp:classbot/devel (on Launchpad) (doing so causes bzr to crash): ErrorFromSmartServer: Error received from smart server: ('error', "We are missing inventories for revisions: [StaticTuple('nhandler@ubuntu.com-20100920220053-yztqc4i042olpvnp',)]") | 22:12 |
| lifeless | poolie: I'd like to talk loggerhead (voice) a little when you have a timeslice spare | 22:13 |
| poolie | nhandler, at the broadest level i think someone has pushed bad data into it | 22:13 |
| poolie | lifeless, sure, let me finish things heer | 22:13 |
| james_w | IIRC that error is something to do with stacking | 22:13 |
| poolie | could it be renaming the stacked branch causes that? | 22:14 |
| poolie | :/ | 22:14 |
| poolie | maybe we should ban that | 22:14 |
| james_w | nhandler, try "bzr pack lp:classbot/devel" and then try again | 22:14 |
| james_w | bug 437003 | 22:14 |
| ubot5 | Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003 | 22:14 |
| lifeless | I suspect an old bzr client actually | 22:15 |
| lifeless | we had some bugs in this area | 22:15 |
| nhandler | james_w: That did it. You rock! (but now I have no excuse for not fixing a few outstanding bugs in classbot ;) ) | 22:16 |
| james_w | heh, we can probably break it again if you like ;-) | 22:16 |
| nhandler | james_w: Nah, that is alright. Thanks again. | 22:17 |
| jam | poolie, lifeless: bug 437003 covers it pretty well. It is autopack across pack files where the inventories aren't in the group being repacked. | 22:46 |
| ubot5 | Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003 | 22:46 |
| jam | it is caused by stacking interacting oddly with autopack | 22:47 |
| jam | where you got the inventory in the past, but then get the revision, and then autopack without getting the original pack file in the group | 22:47 |
| lifeless | jam: is historydb optional in loggerhead? | 22:48 |
| jam | no | 22:48 |
| lifeless | poolie: ^ | 22:48 |
| jam | you don't need the *plugin* | 22:48 |
| jam | but it changes how things are stored on disk | 22:48 |
| jam | you certainly could rewrite things until you got to that point | 22:48 |
| jam | but it isn't written that way | 22:49 |
| lifeless | jam: what I mean is | 22:52 |
| lifeless | jam: can trunk loggerhead be used with the performance profile of the loggerhead we use in lp | 22:52 |
| jam | lifeless: no | 22:53 |
| jam | which I tried to convey, but probably just got woryd | 22:53 |
| jam | wordy | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
