=== lamont` is now known as lamont
[00:49] <Noldorin_> hey folks
[00:49] <Noldorin_> is poolie back yet? :-)
[00:50] <poolie> i am here
[00:54] <Noldorin_> poolie, hi
[00:54] <Noldorin_> i'll try and catch you tomorrow, as it's a bit late here
[00:54] <Noldorin_> was just wondering if you were back from holidays
[00:55] <Noldorin_> had some dev related questions
[00:55] <Noldorin_> regarding some time ago
[00:55] <Noldorin_> ta
[08:28] <vila> hi all !
[08:28] <vila> poolie: around ?
[08:32] <poolie> hey
[08:32] <vila> hurrah !
[08:32] <poolie> just had a chat to thomas, all is well
[08:32] <vila> poolie: looking at your udd patch for list_packages
[08:33] <poolie> thanks
[08:33] <vila> poolie: or rather, since I approved it, looking at deploying (shutting down the importer right now)
[08:33] <poolie> i also would have guessed that it was a change on lp
[08:33] <poolie> thus my original bug title
[08:33] <poolie> hard to know
[08:34] <vila> poolie: long story short: there are recent import failures for pristinetar, did you requeue these manually ?
[08:35] <vila> poolie: if not, end of the interruption, if yes, I won't have to search why they were requeued ;)
[08:49] <vila> poolie: ?
[08:55] <poolie> vila, i did not do that
[08:55] <vila> k, thanks
[08:55] <poolie> ...
[08:55] <poolie> maybe at the rally?
[08:55] <poolie> it's a blur
[08:55] <poolie> i don't think so
[08:55] <vila> nope, more recent
[08:55] <vila> no big deal either
[08:57] <poolie> let's check shell history :)
[08:57] <poolie> though, really, it ought to log something
[08:58] <vila> yeah...
[08:58] <vila> I'm rsync the logs and will look at the package ones
[08:59] <vila> rsync'ing
[09:06] <vila> jelmer: quilt not installed breaks the importer (I just deployed bzr-builddeb 2.8.2) :-/ Will file a rt ticket, what is needed ? Just quilt or some more ?
[09:07] <poolie> vila, as well as filing an rt, nag the vanguard in #is
[09:07] <vila> poolie: will do
[09:08] <vila> but usually when I do that I'm pushed back to file an rt ticket ;)
[09:08] <poolie> vila, or, finish converting it to juju :/
[09:08] <vila> doing things in order will hopefully helps :)
[09:08] <poolie> ;)
[09:11] <vila> poolie: list_packages succeeded \o/ (no new packages apparently)
[09:12] <poolie> great
[09:13] <vila> jelmer: does your commit hook for quilt needs to crash when quilt is not installed ? Can't it disaplay a far red blinking warning instead ?
[09:13] <vila> jelmer: additionally, is there a config option to disable it (or any other way) ?
[09:14] <vila> jelmer: and finally, is there a minimum version required for quilt ?
[09:30] <poolie> good night all, that's it for me
[09:34] <vila> good night poolie !
[09:34] <vila> jelmer: rt filed, quilt installed, imports succeeded, want some names to check it worked as intended ?
[09:45] <mgz> morning
[09:50] <vila> heya mgz !
[09:51] <vila> jelmer: pakages that failed without quilt and have now succeeded: http://paste.ubuntu.com/816262/
[09:52] <vila> jelmer: quilt-0.48-5 has been deployed on jubany
[09:53] <vila> jelmer: and look at that... I was wondering how to avoid nexuiz-data endlessly re-trying while we investigate while it seem to be in an endless loop and it too failed with quilt, problem solved ;)
[10:10] <rcsheets> I am getting an operation not permitted error when trying to push. http://pastebin.com/m7JvUbRv
[10:10] <rcsheets> the file referenced in the error message does not exist.
[10:12] <rcsheets> in the branch i'm pushing *from*, that file (and the entire directory it's in) has been moved up a directory. perhaps that's confusing bzr?
[10:18] <mgz> rcsheets: hm, it really doesn't exist? I'd expect ENOENT rather than EPERM then
[10:19] <mgz> there were some changes to chmod on trunk recently to ignore errors, but that was related to running against ntfs and other filesystems that don't support unix file modes
[10:20] <rcsheets> this is on ext4
[10:20] <rcsheets> stat: cannot stat `/srv/bzr/ffm-gms/trunk/cron/cron_customer_order_daily_email.php': No such file or directory
[10:21] <rcsheets> actually i just noticed that from the destination branch, looking at 'bzr log', it seems like it worked
[10:21] <rcsheets> but i can't do an update
[10:21] <vila> rcsheets: which directory doesn't exist exactly ?
[10:22] <rcsheets> Part of the most recent set of changes was moving public/cron/ to cron/
[10:22] <vila> and which bzr version are you using ?
[10:22] <rcsheets> bzr 2.2.4
[10:23] <vila> hmpf, good to know, not tempted to upgrade to our latest stable that is 2.4 ? :-P
[10:23] <rcsheets> i'm stuck for the moment on ubuntu maverick, but i can install a backport or just throw a new version into /opt
[10:23] <vila> k
[10:23] <mgz> okay, so it's being created as part of the merge, then can't be chmoded
[10:24] <mgz> I'd check the perms on the parent directory of the branch you're pushing to
[10:24] <vila> I would start by checking the permissions of all directories
[10:24] <vila> mgz: :)
[10:24] <rcsheets> i will chown them all to myself
[10:24] <vila> hold on
[10:24]  * rcsheets holds on
[10:24] <vila> can you check first so we have a reasonable understanding ?
[10:24] <rcsheets> yes
[10:25] <rcsheets> the /srv/bzr/ffm-gms/trunk directory itself is owned by another user, but mode 775 and i'm in the group.
[10:26] <vila> and below that ?
[10:26] <rcsheets> looking
[10:26] <vila> hey bialix !
[10:26] <bialix> hi vila!!!
[10:26] <bialix> hi mgz!
[10:26]  * mgz bops bialix 
[10:26]  * vila looks at his zoo postcard ;)
[10:26] <bialix> :-D
[10:27] <rcsheets> several other parts of the tree are owned by another user, but again i'm in the group and there are group write permissions
[10:27]  * bialix is happy to say hello to bzristas
[10:27] <vila> bialix: :)
[10:28] <rcsheets> there is nothing in the whole tree below /srv/bzr/ffm-gms/ that i cannot write to
[10:28] <mgz> rcsheets: the other possibility is... the cron directory is getting created on merge? because you moved it?
[10:28] <vila> rcsheets: weird, try chown'ing and retry but I'm not fully confident it will work (on the other hand, I'm known for being rather pessimistic for bugs I don't fully understand ;)
[10:28] <rcsheets> ok
[10:28] <rcsheets> i will tar up what i have now, in case i need to restore it later
[10:29] <vila> mgz: and ? ( a move requires write access on both dirs but that's still write access)
[10:29] <vila> rcsheets: did you check perms under the '.bzr' directory ?
[10:30] <rcsheets> vila: yes i checked for anything not owned by me, using find. it found many things under .bzr owned by the other user, but with group write access.
[10:30] <rcsheets> group=admin throughout the directory structure, and i am in that group
[10:30] <vila> great
[10:31] <rcsheets> now that i own everything, it seems to work fine
[10:31] <rcsheets> yeah, that did it
[10:31] <vila> weird
[10:31] <rcsheets> indeed. well, thanks!
[10:31] <vila> until now, the issues we had with group perms always involved an sftp server ignoring bzr requests for group bits
[10:32] <vila> unless fullermd remembers otherwise... never overestimate alzheimer ;-D
[10:32] <rcsheets> i can retry using the latest bzr from my backup of the repository, if it would be helpful
[10:34] <mgz> bialix: there are a few qbzr/bzr-explorer things I think that need to happen before 2.5, I wonder if you have any other suggestions
[10:34] <mgz> 1) make filesystem watcher disabling work, and make it only watch versioned files
[10:35] <vila> rcsheets: it's an issue with the working tree so it will useful only if you backed it up with the right perms
[10:35] <mgz> 2) fix some exception encoding stuff once bzr has a mechanism for it
[10:35] <mgz> 3) check if colo branches break anything too badly
[10:36] <rcsheets> vila: i backed it up using "tar cf file.tar directory" as root. i *think* tar defaults to preserving all the ownership/permissions if you're root, but i may be wrong.
[10:36] <mgz> I'll do some of that at least next week.
[10:36] <vila> rcsheets: nope, that's my belief too
[10:37] <rcsheets> it looks like it preserved everything
[10:37] <rcsheets> i'll untar it somewhere else
[10:37] <fullermd> The thing with sftp was that it filtered out the setgid bit.
[10:37] <vila> rcsheets: file a bug then so we can keep track of the issue
[10:38] <rcsheets> vila: i thought i'd check first to see if the bug still exists in the most recent release.
[10:38] <vila> fullermd: yup, but did you ever encounter a case where the group bits were not respected while *not* using an sftp server ?
[10:38] <vila> rcsheets: yup, exactly
[10:38] <rcsheets> k
[10:38] <fullermd> Not I.  But I wouldn't hit an issue even then, since I use a sane system that doesn't need that setgid crap anyway  ;p
[10:38] <vila> hehe
[10:40] <vila> mgz, bialix: from the top of your joined heads, how does the bzr installer build the ccurl-ca-buble.crt file and where is it stored ?
[10:40] <vila> geee
=== bialix_ is now known as bialix
[10:40] <vila> curl-ca-bundle.crt
[10:41] <vila> bubble...   lovely tyop
[10:41] <bialix> vila: I've got it from mozilla
[10:41] <vila> bialix: as in: got in once and never rebuild it ?
[10:41] <bialix> it was stored along bzr.exe or inside lib/
[10:42] <bialix> vila: well, I updated it several times in 2007-2008 I think when I maintained windows build
[10:42] <vila> bialix: ok
[10:43] <bialix> mgz: I was disconnected, if you said something before vila asked us about cert, please, repear
[10:43] <bialix> mgz: I was disconnected, if you said something before vila asked us about cert, please, repeat
[10:43] <rcsheets> vila: everything worked fine using 2.5b5
[10:44] <vila> rcsheets: \o/
[10:44] <bialix> vila: what's up with cert?
[10:45] <vila> bialix: the urllib implementation can now verifies certs as long as some root certificates are provided... same issue you had with pycurl, I'm trying to gather how to find them for all platforms now
[10:45] <Riddell> I just noticed that debian bug 641019 is fixed
[10:45] <ubot5> Debian bug 641019 in pristine-tar "pristine-tar does not work with tar files made by openSUSE" [Normal,Fixed] http://bugs.debian.org/641019
[10:45] <vila> Riddell: hello !
[10:45] <rcsheets> fixed bugs are the best kind of bugs
[10:45] <Riddell> so UDD should be workable with KDE tars, I guess it needs a sync
[10:45] <vila> Riddell: yup, I've filed rt #50455
[10:46] <bialix> vila: right. because bzr switched to urllib as default and it did not check certificates, I think that's why cert bundle wasn't updated for a looong time
[10:46] <vila> bialix: ???
[10:46] <Riddell> vila: lovely
[10:47] <vila> bialix: urllib will be the default httpS implementation in 2.6 only
[10:47] <bialix> vila: long time ago in far far galaxy
[10:47] <vila> bialix: are you saying the windows installer don't carry pycurl anymore ?
[10:47] <vila> doesn't
[10:47] <Riddell> vila: I'll look at getting p-t 1.16 into precise when I get a chance
[10:47] <bialix> I think so
[10:48] <bialix> vila: yep, exactly
[10:48] <vila> Riddell: that's lucid we need for jubany but getting >= 1.17 in precise won't hurt !!
[10:48]  * vila coughs
[10:48] <vila> mgz: ^^
[10:49] <Riddell> yeah, needs backporting too
[10:49] <vila> Riddell: I didn't check if 1.16 was enough but 1.17 seem to carry additional fixes
[10:49] <mgz> sorry, was off responding to naoki's mp, unfortunately that's just the kind of change that won't work
[10:49]  * mgz catches up
[10:50] <mgz> bialix: will paste what I said in /query
[10:51] <bialix> mgz, Riddell: I fear new filesystem watcher in explorer do more harm than help
[10:52] <mgz> heh, I bet the certs we ship still have that dutch registrar in then.
[10:52] <bialix> mgz: I think the best we can do before bzr 2.5 is out is make it disabled by default and provide config option for brave hearts
[10:53] <mgz> there are six or so bug reports that I think are filesystem watcher related
[10:53] <bialix> mgz: yes :-(
[10:53] <Riddell> bialix: more problems from it?
[10:53] <mgz> it's mostly down to two things,
[10:53] <bialix> Riddell: mgz>	there are six or so bug reports that I think are filesystem watcher related
[10:54] <mgz> it watches *everything* in the tree, including the .bzr dir, which can confuse other parts of bzr
[10:54] <bialix> on windows it triggers Access is denied error tooooo often
[10:54] <Riddell> bialix: I found it a big help for using explorer, if I have to use refresh all the time I find it no better than command line
[10:54] <mgz> and on windows watching counts as a soft-lock
[10:54] <bialix> that's limitation of filewatcher in Qt
[10:54] <Riddell> bialix: but if there are problems then maybe it's more bother than it's worth
[10:55] <mgz> I think that just limiting to versioned files should fix nix at least, then we can leave enabled there
[10:55] <bialix> Riddell: I think we hit the limitation barrier of Qt itself here
[10:55] <Riddell> to be fair on Qt it is limited by the operating system :)
[10:55] <mgz> there are ways around the windows issues, eg
[10:56] <mgz> moving a file in explorer should unwatch any children first, then rewatch after moving
[10:56] <mgz> but just making the disable/enable work should be the first thing
[10:57] <bialix> Riddell: right
[10:58] <Riddell> I'd love to help but I'm behind on kubuntu stuff because this accident I had has made me slower so I doubt I'll get to it
[10:58] <mgz> Riddell: your occasional opinion is all I'll bug you for :)
[10:59] <bialix> me too
[10:59] <mgz> is there anything else we think has to be done for qbzr or bzr-explorer before 2.5?
[10:59] <bialix> mgz: back to your list: what do you mean by 2) fix some exception encoding stuff once bzr has a mechanism for it
[11:00] <bialix> mgz: and 3) check if colo branches break anything too badly -- do you mean new colocated support in the core from jelmer?
[11:00] <mgz> ah, er bug 599860 and any other things that will need fixing to once bzrlib changes how it does some trace encoding stuff
[11:00] <bialix> because old bzr-colo stuff is used to work
[11:00] <ubot5> Launchpad bug 599860 in Bazaar Explorer "UnicodeDecodeError with BzrError containing localised error message from OS" [Medium,Confirmed] https://launchpad.net/bugs/599860
[11:01] <mgz> ^and right, jelmer's core colo things
[11:02] <vila> mgz: you can probably add some ssl cert bundle building or disable cert verification or all lp users will whine
[11:02] <bialix> mgz: re 599860: I can do a simple workaround by catching Unicode error there and try stringify
[11:02] <mgz> hm, you mean exposing the conf option as a checkbox or something vila?
[11:02] <vila> jelmer: around ?
[11:03] <vila> mgz: I mean if we don't provide a valid bundle all https connections will fail
[11:03] <mgz> bialix: for that bug, it's less about fixing the symptom and more making sure that once the core bzr stuff changes explorer doesn't break
[11:04] <vila> so either we provide it or we set the ssl.cert_reqs option default value to none
[11:04] <bialix> mgz, vila: http://wiki.bazaar.canonical.com/BzrWin32Installer#id20
[11:05] <bialix> out-of-date a bit, but that's what I did back in 2008
[11:05] <mgz> thanks bialix
[11:05] <vila> thanks bialix
[11:06] <vila> stereo effect :)
[11:06] <bialix> we should check whether that still work with bzr.dev exe building
[11:06] <vila> mgz: doxxx may need to do the same for the osx installers
[11:06] <bialix> nice stereo
[11:07] <vila> mgz: I'm working on bug #920455 so I need to know what path to use
[11:07] <ubot5> Launchpad bug 920455 in Bazaar "ssl cert verification needs better defaults for all supported platforms" [High,Confirmed] https://launchpad.net/bugs/920455
[11:08] <vila> mgz, bialix: I probably should reuse bzrlib.transport.http.ca_bundle.py for that (and for now)
[11:09] <bialix> vila: at least that used to work
[11:09] <jelmer> vila: yup
[11:10] <vila> jelmer: (requeing ;)  seen my messages about quilt for udd ?
[11:11] <jelmer> vila: scrolling up now..
[11:14] <bialix> mgz: I'd be happy to prepare qbzr/explorer for bzr 2.5 with you.
[11:16] <jelmer> vila: you can use quilt-smart-merge=False to disable it
[11:17] <vila> jelmer: in the package itself I presume ? (given the name with - instead of _ ;)
[11:17] <jelmer> vila: yes
[11:17] <vila> jelmer: won't work for jubany
[11:17] <vila> jelmer: but keep reading, quilt has been deployed I don't need to disable at a global level anymore
[11:17] <jelmer> vila: given it's a package dependency, I'm not sure if it's really necesary to cope better with quilt being missing as it should always be there
[11:17] <mgz> bialix: that would be great
[11:18] <vila> jelmer: dependency of bzr-builddeb ?
[11:18] <jelmer> vila: yes
[11:18] <vila> of course, I agree then
[11:19] <vila> jelmer: will teach me to deploy unpackaged packages ;)
[11:20] <jelmer> heh, indeed ;)
[11:25] <mgz> bialix: hm, mind if I just cherrypick the treewidget fix to 0.21 rather than rebasing? having the first branch landed and not wanting the last one there makes things a bit more confusing
[11:25] <mgz> will add the news after the cherrypick
[11:30] <bialix> mgz: anything is fine for me
[11:32] <mgz> doing that now, will propose so the diff passes by you
[11:34] <vila> Riddell: cjwatson just mentioned he did sync pristine-tar 1.17 in precise ;)
[11:35] <mgz> dammit, this feature moving is just annoying me now
[11:36] <vila> mgz: rather than two months ago you mean ? :-D
[11:37] <Riddell> vila: lovelyness
[11:39] <mgz> I should update to latest beta, that backward import I think
[11:39] <bialix> mgz: feature moving?
[11:41] <mgz> ha! now on 2.5b5 and... different error ;_;
[11:41] <mgz> plugins/qbzr/lib/tests/test_spellcheck.py", line 25, in <module> class _PyEnchantFeature(Feature):
[11:42] <mgz> TypeError: Error when calling the metaclass bases __init__() takes at least 5 arguments (4 given)
[11:42] <mgz> I should just get a 2.4 install so I'm running the right versions against each other
[11:44] <mgz> okay, tests pass on 0.21
[11:45]  * mgz reverts to .po
[11:48]  * vila out for lunch
[12:25] <mgz> ga, I hate news
[12:25] <mgz> added it to a released section, needed to make a new one
[12:55] <jelmer> vila: hmm, I'm just looking at some test failures in debian
[12:56] <jelmer> it's not a problem if read() in bzrlib/tests/test_test_server.py line 77 raises a 104 error (connection reset by peer) ?
[12:56] <bialix> mgz: thanks
[12:57] <mgz> bialix: I think I got all the bits right in the end, but yell if you see anything I messed up
[13:01] <vila> mgz: hehe, welocme to the club ;)
[13:01] <vila> jelmer: let me have a look
[13:01] <vila> jelmer: trunk ?
[13:02] <vila> jelmer: ha, *that* read :-/
[13:03]  * bialix just re-read the description of qbzr on lp: "A simple Qt cross-platform frontend for some of Bazaar commands" and thought how many of that is still true? simple? some commands?
[13:03] <vila> jelmer: my take here is that we should go back to where this code was introduced and split new tests instead of messing with the existing ones
[13:04] <vila> jelmer: the modifications were based on an assumption that has been proved wrong repeatedly and their intent has never been clear to me
[13:05] <mgz> how do you do that neat tracked-in-0.22 series thing in launchpad?
[13:05] <vila> jelmer: add the fact that these tests tend to succeed for many known (and some more unknown) races to blurry the area...
[13:06] <vila> jelmer: but which tests do you see failing ?
[13:06] <bialix> mgz: click on Target to series
[13:07] <bialix> mgz: select trunk and desired series
[13:07] <Riddell> bialix: and it should11:27 < Tm_T> dpkg: error processing /var/cache/apt/archives/plasma-dataengines-addons_4%3a4.8.0-0ubuntu1~oneiric1~ppa1_amd64.deb (--unpack): trying to  overwrite '/usr/share/kde4/services/plasma-engine-kdeobservatory.desktop', which is also in package plasma-widget-kdeobservatory  4:4.7.4-0ubuntu0.1
[13:07] <Riddell> oh sorry
[13:07] <mgz> ah ah, trunk
[13:07] <Riddell> bialix: and it shouldn't mention Qt, that's an implementation detail
[13:07] <bialix> Riddell: I'm sorry I'm not quite understand
[13:08] <Riddell> bialix: "A simple Qt cross-platform.." Qt can be removed from there, it doesn't matter what widget toolkit you use what matters is the end result
[13:08] <mgz> ...pasted the wrong thing Riddell?
[13:09] <bialix> Riddell: right, that's true, it's simple implementation detail
[13:09] <Riddell> mgz: yes, I shall now remove my stupid thinkpad touchpad with a stanley knife
[13:09] <Riddell> bialix: how about "A user friendly GUI to Bazaar commands and guided usage" ?
[13:10] <bialix> mgz, vila: I'd like to commit my workaround for bug https://bugs.launchpad.net/qbzr/+bug/912344
[13:10] <ubot5> Launchpad bug 912344 in Bazaar "Bazaar explorer crashes when in browse and I try to show annotate on a file" [High,Confirmed]
[13:11] <bialix> although that's clearly bug in bzrlib, but we can workaround it in qbzr itself
[13:11] <mgz> I'm still not used to middle-click paste, I'm alwasy trying to open a new tab but end up in a search for whatever's on (one of) my clipboard at the time
[13:12] <bialix> Riddell: good. But what do you mean by "guided usage"?
[13:13] <bialix> Riddell: but I think your description is better suited to Bazaar Explorer
[13:14] <mgz> something along the lines of Riddell's suggestion would work for qbzr
[13:14] <vila> bialix: workaround seems fine
[13:14] <Riddell> bialix: oh right maybe that's what I'm thinking of
[13:14] <mgz> just need to get across the point that it's guis for individual commands
[13:14] <jelmer> vila: test_handle_request_closes_if_it_doesnt_process is failing
[13:14] <Riddell> bialix: then maybe "A user friendly cross-platform GUI to Bazaar features"
[13:14] <vila> jelmer: yup, known but rare spurious one
[13:15] <bialix> Riddell: !
[13:15] <jelmer> vila: is there any reason getting a 104 error there is invalid?
[13:15] <Riddell> bialix: what's that ment to mean? :)
[13:16] <bialix> Riddell: that mean: yes, that's good one
[13:16] <Riddell> oh nice, go me :)
[13:17] <vila> jelmer: long story short: can't say. I was against closing in handle_request as it broke the known working model...
[13:17] <bialix> "go me"?
[13:18] <mgz> bialix: while I have you, on an unrelated issue, are you aware of anything in bzr-explorer that can cause it to open lots and lots of connections to the same server?
[13:18] <vila> jelmer: *why* it breaks (as revealed by this failure) is unknown to me
[13:18] <mgz> bialix: Riddell is pleased you liked his suggestion
[13:19] <bialix> mgz: I think that's because we have separate codebase for inspecting working tree status + working tree widget + what's is not submitted to the parent branch
[13:20] <mgz> but that's still only two or so connections right?
[13:20] <bialix> mgz: my own opinion on this is that there should be a dedicated process to do all bzr heavy-lifting, while bzr-explorer itself should be a thin frontend, like a browser
[13:21] <bialix> mgz: I've once described  my thoughts on this topic back in April or May 2011, but I haven't had enough spare time to implement this wild and heavy idea
[13:22] <bialix> mgz: that too many connection error also could be triggered in qlog alone
[13:22] <mgz> ha, yes... what causes the error to be raised rather than just opening lots of connections though?
[13:22] <bialix> mgz: bzr-explorer re-fresh status from time to time, so I suppose it re-open the branch many times
[13:23] <bialix> connection just is not re-used
[13:24] <bialix> mgz: yes, the branch should be reopened on refresh, otherwise in some corner cases we lost track of actual changes
[13:24] <bialix> like switching light checkout to another branch behind GUI
[13:25] <bialix> would you like me to find my old rant?
[13:28] <mgz> bialix: that would be nice, doesn't seem to be on the bzr list?
[13:29] <bialix> mgz: would you like to be listed in AUTHORS.txt list of qbzr with your full name, rather than [gz] ?
[13:30] <bialix> mgz: I found it, May 3, 2011. I see it in qbzr ML, should be in bzr ML as well
[13:31] <mgz> bialix: I'm fine with either
[13:32] <vila> bialix: he won't tell you but I'm sure he prefers [gz] ;)
[13:32] <bialix> vila: that was my suspicious too
[13:34] <bialix> mgz: https://lists.ubuntu.com/archives/bazaar/2011q2/072377.html
[13:37] <mgz> thanks bialix
[13:37] <bialix> mgz: actually, I still think it could help, but in the same time it will require too much efforts
[13:39] <bialix> maybe re-using part of TortoiseBzr, but it too tight coupled to windows
[13:39] <mgz> well, we can leave till after 2.5 at least
[13:40] <bialix> maybe using python standard (in 2.6) processing library would help (a lot)
[13:41] <bialix> I meant "processing"
[13:41] <bialix> or it's called now "multiprocessing"
[13:51] <bialix> mgz: do you have a favorite tree?
[13:51] <bialix> we need codename for 0.22
[13:52] <vila> bonzai ? :-D
[13:53] <bialix> it's not a specie, it's a form
[13:53] <vila> rats, for once the tyop was also a pun ;)
[13:53] <mgz> hm.
[13:54] <mgz> alder?
[13:54] <bialix> wrong word
[13:54] <bialix> sold!
[13:56] <mgz> apparently the one round here is alnus glutinosa or black alder.
[13:58] <bialix> nice
[13:58] <mgz> heh, and on the wikipedia page vila, it has a 'Bonsai' section
[13:58] <vila> lol, I'm on the wiki page but not there yet ;)
[13:59] <bialix> this summer I saw exhibition of bonsai trees, it was nice. no alder unfortunately
[14:08] <mgz> bialix: after a qbzr (or bzr-explorer) release, who does the packaging for debian/ubuntu?
[14:08] <bialix> not me
[14:09] <bialix> I'm not sure who make packages now
[14:10] <bialix> who does the packaging for other bzr products?
[14:11] <mgz> someone who's name begins with J and ends with elmer does bzr itself,
[14:12] <mgz> perhaps I can twist his arm into doing or helping me with qbzr and explorer, if he doesn't already.
[14:12] <mgz> right, lunch time for me.
[14:13] <LarstiQ> mgz: http://packages.qa.debian.org/q/qbzr.html points at http://packages.debian.org/changelogs/pool/main/q/qbzr/current/changelog which says mister Elmer and Andrew Starr-Bochicchio
[14:14] <LarstiQ> lately at least
[14:43] <smoser> is this a known error:
[14:43] <smoser> $ bzr branch lp:~orchestra/orchestra/odev
[14:43] <smoser> You have not informed bzr of your Launchpad ID, and you must do this to
[14:43] <smoser> write to Launchpad or access private data.  See "bzr help launchpad-login".
[14:43] <smoser> bzr: ERROR: Target directory "" already exists.
[14:43] <smoser> why would target directory be ""
[14:43] <smoser> ?
[14:46] <vila> smoser: sounds familiar but only for quite recent bzr versions, I think jelmer already fixed it
[14:46] <smoser> this is precise "right now"
[14:47] <smoser> $ dpkg-query --show bzr
[14:47] <smoser> bzr     2.5.0~beta5-3ubuntu1
=== yofel_ is now known as yofel
[14:55] <vila> jelmer: can you confirm ? ^
[15:01] <mgz> LarstiQ: thanks, now do I need to bug you to propose your pypy test fixes? :)
[15:02] <jelmer> vila: no, that's not actually fixed yet but it's on my radar
=== jml is now known as jml`
=== jml` is now known as jml
=== marienz is now known as 5EXAA07MX
=== 5EXAA07MX is now known as marienz
=== SpamapS_ is now known as SpamapS
=== james_w` is now known as james_w
=== deryck is now known as deryck[lunch]
[17:37]  * mgz drives jelmer nuts with non-review review comments
[17:38]  * jelmer_ drives jelmer nuts by not being entirely awake today.
[17:39]  * vila throws nuts
[17:40] <mgz> meh, not a list admin, can't approve my message with too-large attachments
[17:40] <vila> use smaller attachments ;)
[17:40] <mgz> that means downloading, compressing, and reattaching, but yeah, is probably sanest
[17:41] <vila> you really need to send such a big attachment ?
[17:43] <LarstiQ> the limit isn't that high iirc
[17:43] <vila> which list ?
[17:43] <LarstiQ> mgz: no, I should have some time today
[17:44] <LarstiQ> mgz: between work/study/renovating there isn't much to go around
[17:44] <vila> in the good old days, merge proposals came with their associated bundle... and could be quite large
[17:44] <LarstiQ> vila: hmm, true
[17:45] <mgz> internal one, but 6MB was pretty large
[17:46] <mgz> LarstiQ: don't let me stop your carpentry
[17:47] <LarstiQ> mgz: no worries, I need a break from it :)
=== beuno_ is now known as beuno
=== deryck[lunch] is now known as deryck
[18:56] <wgz> ouch, a ValueError on missing certs dir? that's not nice
[19:05] <fullermd> Hey, it's not making a value judgement.
[19:05] <fullermd> Or, wait, I guess it is...
[19:08] <LarstiQ> wgz: at the end of bzrlib.hashcache.HashCache.read there is a comment we should use try/finally, is there a reason we're not doing so?
[19:21]  * wgz checks
[19:22] <wgz> I think just that it was a pain to reindent everything and I didn't hit any cases that actually threw on the intervening lines
[19:23] <wgz> technically things could, but only with broken files I think
[19:25] <lifeless> well, that never happens :P
[19:27] <wgz> :)
[19:28] <wgz> if the error results in bzr exiting anyway, closing the file you're reading from promptly is less important
[19:29] <vila> wgz: Straight ValueError ? Or ConfigValueError  (the later should give proper info to the user) ? Do we need blackbox test for that maybe ?
[19:29]  * vila off
[19:31] <wgz> vila: you changed one of them in your ssl defaults branch anyway
[19:32] <vila> wgz: right, IIRC I *removed* one possible cause of ValueError leaving only a ConfigValueError but imbw
[19:34] <wgz> dammit, I just tried to use vi on this box
[19:34] <wgz> I clearly can't segment my life properly.
[19:47] <lifeless> wgz: bzr is used as a library too though
[19:47] <LarstiQ> wgz: what I have so far, minus tar export changes, is at lp:~larstiq/bzr/bzr-pypy
[19:47] <lifeless> wgz: so 'exit this call' != 'exit the process'
[19:48] <LarstiQ> wgz: there is more work in a similar vein to do still, so not sure about proposing it for merging
[19:50] <lifeless> LarstiQ: does it work?
[19:50] <lifeless> LarstiQ: is it in the right direction?
[19:50] <LarstiQ> lifeless: yes, no NEWS entry written yet
[19:51] <lifeless> do that and merge IMNSHO
[19:52] <LarstiQ> lifeless: ok. While I think on how to formulate that entry I can squash more test failures :)
[19:53] <wgz> yeah, I agree, am always a propose-first news-last person myself
[19:53] <wgz> when I remember news that is.
=== _thumper_ is now known as thumper
=== kirkland` is now known as kirkland