[00:01] <maxb> jam: It's a LP bug. It's failed to publish a build-dep on lpia
[00:03] <maxb> nooo, new bzr-git failure on hardy
[03:50] <quotemstr> How can I merge changes HEAD-2 and HEAD-3 in the history?
[07:02] <chx> hi. if i use --hardlink but then edit a file ... how can i make sure my editor breaks the hardlink?
[07:03] <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:04] <bob2> dunno if nano can/does by default
[07:37] <lifeless> there is an ldpreload hack to break them
[07:50] <chx> lifeless: FL-COW?
[07:53] <fullermd> Urp.  Bookmarks is broken with .dev   :(
[12:39] <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:40] <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:41] <damd> any ideas?
[12:44] <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:45] <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:46] <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:52] <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
[13:01] <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:06] <damd> actually, i guess that's not the problem, since it works right when there are no changes
[13:17] <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"
[14:09] <vila> damd: sounds pretty weird
[14:09] <vila> damd: --diff-options without options for a given diff is suspicious
[14:10] <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:11] <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:12]  * 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:15] <damd> why do all things emacs have so ugly logos?
[14:16] <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:18] <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:19] <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:20] <vila> hmm, as official as it can be as this time: http://www.emacswiki.org/emacs/EmacsIcons
[14:22] <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:23] <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:25] <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:26] <vila> hehe
[14:26] <damd> enough senseless ranting for now!
[14:27] <vila> mwahaha, best wallpaper ever : http://i.imgur.com/RxlwP.png
[14:28] <damd> see, even the wallpapers are ugly :(
[14:28] <vila> lol
[14:28] <vila> scratch this itch !
[14:28] <damd> yeah
[14:30] <mgz> http://paste.ubuntu.com/558550/ <- that's a lot of PointlesslyBreakThings lines.
[14:31] <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:32] <vila> mgz: hellllo !
[14:33] <mgz> hey vila!
[14:33] <vila> mgz: what's the context ?
[14:33] <mgz> bug 707954
[14:33] <vila> str(xx) considered harmless ?
[14:33] <vila> harmful I meant
[14:34] <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:35] <vila> adding tests to ensure we cover all code paths there will be ideal
[14:36] <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:37] <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:38] <vila> depends which layer you want to test
[14:39] <mgz> well, ideally lower if I'm covering all those.
[14:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:51] <vila> rats, babune has no log about the features and skipped tests :(
[14:52] <mgz> 2.7 logs skips sensibly now, but the win slave is on 2.6 right?
[14:54] <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:55] <jam> ah, it's the probe
[14:55] <jam> it specifically probes for the exact name "bash" in the path
[14:56] <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:57] <vila> so my guess is that it makes it find exes that weren't found previously
[14:58] <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:59] <jam> and not using shell=True
[14:59] <vila> hmm, not using shell=True is harmless on unices ?
[15:00]  * vila never uses shell=True
[15:03] <mgz> hm, I don't know how to hit some of these branches.
[15:06] <vila> mgz: scary ;)
[15:10] <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:11] <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:12] <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:14] <wash> maxb: *nods* Thanks
[15:17] <jam> mgz: check the annotate on that file. I probably wrote that code about 3-4 years ago
[15:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <jam> vila: did you just run bzr log to find that ?
[15:36] <vila> bzr tags
[15:36] <jam> or 'bzr tags'
[15:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <maxb> hrm. bzr help does not tell you what the options are for tags --sort=???
[15:44] <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:45] <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:46] <tedg> bug 708063
[15:47] <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:48] <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:49] <vila> tedg: but you may have a deeper issue there, .pyc files don't get corrupted randomly on well-behave machines ;)
[15:50] <vila> tedg: python-2.7 on lucid ??
[15:51] <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:52] <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:53] <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:58] <vila> tedg: shooting the messenger :)
[16:34] <mgz> okay, get this baby reviewd time.
[16:37] <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:38] <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:39] <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:40] <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:41] <vila> so I think I will stop poking at this code and start looking at testing it before deploying...
[16:46] <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:47] <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:48] <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:49] <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:54] <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:56] <jam> maxb: I believe hardy is still in its support window
[16:56] <maxb> Yes, but that's not *quite* the same question :-)
[16:57] <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:58] <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.
[17:00] <mgz> he's submitted like, five different things called lazy something this month.
[17:05] <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:07] <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:08] <mgz> I cheated.
[17:09] <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:12] <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:18] <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:19] <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:21] <vila> mgz: with my blessing, send any complaint my way :)
[17:25] <mgz> hm, doesn't look like too many hits.
[17:28] <vila> mgz: you're referring to transport hook hack right ?
[17:30] <mgz> right.
[17:39] <vila> mgz: so nothing worth backporting to 2.3, target 2.4 :)
[17:40] <mgz> I'll put a mp up with some import changes and we'll see.
[17:41] <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:43] <vila> mgz: yup
[17:44] <vila> EODing, bye all
[17:44] <mgz> bye!
[18:12] <maxb> What is the name of the format defining the :param foo: constructs in bzr docstrings?
[18:23] <lifeless> maxb: epydoc restful ?
[18:23] <maxb> thanks
[19:13]  * jelmer waves
[19:14] <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:15] <james_w> ah yeah
[19:30] <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:32] <jelmer> maxb: sounds reasonable
[19:33] <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:34] <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:47] <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:48] <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:49] <jam> anyway, that makes supporting Hardy much less interesting from at least Launchpad's standpoint
[19:50] <jelmer> maxb: that function in dulwich was never unit tested earlier
[19:51] <jelmer> maxb: (and bzr-git does its own patching of urlparse)
[19:52] <jam> mgz: do you need me to submit your non_ascii patch?
[19:53] <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:54] <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:55] <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:57] <jam> mgz: that one looks  fine to me as well
[20:15] <mgz> pushed the first one. I'll let vila look at the other in the morning if he likes before pushing.
[20:38] <sinzui> I am interested in getting https://bugs.launchpad.net/bzr-gtk/+bug/707482 fixed. Is anyone minding bzr-gtk about
[20:39] <poolie> hi mgz, sinzui
[20:40] <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:41] <poolie> so which value is wrong?
[20:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <sinzui> poolie: we care if we resorted the lines. We wont in this case
[20:51] <jam> I'm pretty sure line_no will always be an int, but revno will often be a str
[20:52] <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:55] <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:59] <poolie> sinzui, ping me if you get stuck
[20:59] <sinzui> thanks
[21:00] <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] <jam> summarizes my thoughts on it
[21:01] <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:02] <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:03] <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:04] <lifeless> so the new server thing
[21:04] <lifeless> thats because its on a borrowed box that is labelled 'landscape backup db server'
[21:15] <jam> oh, I understand why
[21:16] <jam> just mentioning that one rt got taken over by about 5 different things that they wanted to do
[21:19] <lifeless> :)
[22:12] <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:13] <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:14] <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:15] <lifeless> I suspect an old bzr client actually
[22:15] <lifeless> we had some bugs in this area
[22:16] <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:17] <nhandler> james_w: Nah, that is alright. Thanks again.
[22:46] <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:47] <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:48] <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:49] <jam> but it isn't written that way
[22:52] <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:53] <jam> lifeless: no
[22:53] <jam> which I tried to convey, but probably just got woryd
[22:53] <jam> wordy