=== michaelh1 is now known as michaelh1|away
[05:42] <poolie> jam, hi?
[06:22] <poolie> lifeless, hi?
[06:36] <poolie> spiv, hi?
[07:48] <lifeless> poolie: ?
[07:50] <vila> hi all !
[07:56] <poolie> hi there vila
[07:56] <poolie> vila: ah, more free advice :)
[07:57] <vila> ? oom thread ? (catching up with mail)
[07:57] <poolie> on what beta means
[08:00] <vila> oh, my take on that is to stop using 'gold' and just say 'source released' which is what we do anyway
[08:00] <poolie> yep
[08:00] <poolie> i think that's the only change
[08:01] <vila> oh, great to see we agree ;)
=== Merwin_ is now known as Merwin
[08:02] <vila> as for beta/snapshot... I don't have a strong opinion either way
[08:03] <Merwin> hi
[08:09] <poolie> i don't see much point in changing
[08:10] <poolie> vila, so basically i'm going to try inserting a layer that spills out big strings to temp files
[08:10] <poolie> i think it will be at least tolerably clean
[08:11] <vila> hmm, I was wondering about that but couldn't decide if that would be enough, good to try anyway
[08:12] <poolie> i think it's worth a try, yeah
[08:12] <poolie> vila re detecting lp being down
[08:12] <poolie> mm
[08:12] <poolie> i think some of that should go in lazr.restful
[08:12] <poolie> then we need to release and deploy it
[08:13] <poolie> another thing we really need to do is to finish jam's patches
[08:14] <vila> lazr.restful, right, but I'm not sure all of them can go there and I need a solution *now*
[08:14] <poolie> :)
[08:15] <vila> I've seen some 502 bad gateway which probably need to be reported when they are valid errors
[08:15] <vila> and deciding if they are valid or not seem... untractable(sp?)  ;)
[08:16] <vila> re-connection patches... as mentioned, I'm worried we need to address some pre-requisites first or run into an endless whack-a-mole game
[08:17] <lifeless> poolie: you pinged ?
[08:17] <poolie> yep, unping
[08:18] <vila> we went down a road hoping to fix fallouts on the basis that they were no race, reality disagreed
[08:19] <vila> there is still a tough call about using an external server or not
[08:19] <vila> I call it tough as I'm not sure anymore that it will be enough to avoid the race(s)
[08:19] <vila> I *thought* it was the way to go, I'm not sure anymore
=== michaelh1|away is now known as michaelh1
[08:32] <poolie> external server for what?
[08:33] <vila> test server
[08:33] <vila> as opposed to test server in the same process
[08:33] <poolie> oh i see i thought you were still talking about udd
[08:34] <poolie> what's the down side?
[08:34] <vila> the whole 'race chasing' saga has revealed many races were really about running the client and the server in the same process, but the late issues have a different smell
[08:34] <vila> down side of using an external server ?
[08:35] <vila> for one it requires up-front work to make sure it works,
[08:35] <vila> then, if the race is not caused by using an internal one, it's useless to use an external one :)
[08:39] <poolie> hm
[08:39] <poolie> it does not seem like it will often make things much worse
[08:39] <poolie> i thought we already did the work to run it externalyl?
[08:40] <vila> for other kinds of server, yes, I did wrote a plugin, and internally I think there are tests that runs it externally in an ad-hoc way
[08:42] <vila> but I was about to mention that I didn't look too closely to the code itself yet, my last work was to triage the failures on babune to get an overview
[08:43] <vila> from there I concluded that we really have a race (it happens on all platforms which rules out a kernel issue and also probably rules out a python issue)
[08:44] <vila> the question, to me, now boils down to: is this (or these) race(s) caused by running an internal server OR do we have a genuine bug in the smart server
[08:47] <poolie> :/
[08:47] <poolie> and they're all intermittent?
[08:47] <poolie> and they don't show up if you run the tests repeatedly locally?
[08:49] <vila> yup
[08:50] <vila> i.e. we're in a pretty bad situation were we can suddenly see failures to land valid stuff
[08:50] <poolie> i have never seen these hangs or failures
[08:50] <poolie> i don't think i've seen them on pqm either
[08:51] <poolie> therefore they don't exist
[08:51] <poolie> jk
[08:53] <vila> hehe
[08:54] <poolie> no, but seriously
[08:54] <poolie> it's specific to running under jenkins, or on those vms?
[08:54] <vila> mgz and I have been unfortunate enough to encounter them while submitting to pqm ;)
[08:54] <poolie> ah
[09:09] <poolie> vila, so
[09:10] <poolie> what's next?
[09:10] <vila> hmm
[09:11] <vila> so, I identified one race and have a patch for it against 2.4. I ran into conflicts trying to merge up to trunk
[09:12] <vila> and these conflicts are (unsurprisingly) in the test servers
[09:12] <vila> which means reworking a bunch of later submissions
[09:12] <vila> but that's only one race and I'm far from sure it's the only one
[09:13] <vila> and, so far, I didn't want to switch from other stuff I'm already working on :-}
[09:16] <poolie> ok
[09:21] <vila> in summary: those failures are bad but not critical (and hopefully will stay spurious, avoiding a total pqm hang), we probably want to fix them before reviewing/landing the reconnection stuff (to avoid more work)
[09:22] <vila> this hasn't reach the top of my TODO list yet to avoid losing steam in other areas
[09:25] <vila> oh, and jelmer encountered one of them too during an armel build IIRC
[09:27] <spiv> poolie: I'm around for a bit now
[09:33] <poolie> hey
[09:33] <poolie> i was going to talk about some memory stuff but it's ok now
[09:33] <poolie> i wouldn't mind taking up your lunch offer some itme
[09:34] <mgz> morning all
[09:34] <poolie> hi there
[09:38] <poolie> thanks for the review jam
[09:38] <jam> np
[09:40] <spiv> poolie: sure, how about Wednesday?
[09:42] <poolie> wfm
[09:49] <mgz> re races earlier, they're less obvious on PQM mostly because we do far fewer runs there than across all of babune
[09:51] <mgz> I've had both of the two main flavours on pqm though, and one of the bugs was filed by jelmer because it happened on a buildd
[10:02] <_arch> hi
[10:02] <poolie> night all
[10:02] <poolie> i'll be out tomorrow
[10:03] <mgz> have fun at the races!
[10:03] <poolie> thanks
[10:03] <_arch> I have a question concerning symbolic links in bazaar
[10:03] <poolie> no actual races
[10:05] <_arch> I have a working tree that contains a lot of subdirectories that contain a bunch of files. I need to create symbolic links from these files to other subdirectories, and my colleagues need to be able to use these files just by pulling from our repo
[10:06] <_arch> any ideas how to accomplish this?
[10:06] <mgz> I don't understand the problem statement.
[10:07] <_arch> perhaps it's not very clear :)
[10:08] <mgz> it sounds like you're trying to version references to thinks outside the tree, then want people to get your branch and somehow be able to resolve the links?
[10:08] <mgz> that's clearly not going to work.
[10:08] <jam> _arch: Assuming it is something like "bzr init work"; work/files/a; work/links/to_a
[10:08] <mgz> s/thinks/things/
[10:08] <jam> bzr will be able to track them appropriately, as long as you use relative symlinks
[10:08] <_arch> great
[10:08] <_arch> problem solved :)
[10:08] <jam> eg cd work/links, ln -s ../files/a to_a
[10:08] <jam> not full paths
[10:08] <jam> cd work/links
[10:08] <jam> ln -s /home/_arch/path/to/work/files/a
[10:09] <jam> however, it all needs to be in one tree if you want 'bzr pull' to just work
[10:09] <jam> if you have >1 tree, then they'll at least have to pull in each tree
[10:10] <_arch> I must have created my links improperly. Thanks a lot
[10:11] <mgz> bzr could probably complain if you try and version symlinks with absolute paths
[10:11] <mgz> as that's generally going to be a mistake
[10:12] <jam> mgz: not really, just a different use case. "bzr init x; mkdir bin; cd bin; ln -s /usr/bin/python py"
[10:13] <mgz> huh.
[10:13] <jam> or maybe /etc/alternatives ?
=== Merwin_ is now known as Merwin
[11:33] <jelmer> the daily builds now have translations enabled
[11:33] <jelmer> gwenhwyvar:~% LANGUAGE=es_ES bzr rocks
[11:33] <jelmer> ¡Seguro que no!
[12:14] <vila> I don't speak spanish but this sounds like a little joke :)
[12:14] <vila> shouldn't that be s/no/si/ ?
[12:19] <jelmer> vila: yeah :)
[12:33] <Pegasus_RPG> Hello. I just set up a BZR repo on my web server using SFTP/SSH and test-committed a change from my local checkout. The commit worked fine but the file hasn't changed. How can I find out what is going on?
[12:35] <jelmer> Pegasus_RPG: bzr doesn't update remote working trees (push should warn you about this)
[12:35] <jelmer> Pegasus_RPG: you can use the push-and-update plugin to ssh into the server to update the working tree
[12:37] <Pegasus_RPG> jelmer: But I initially pushed using sftp
[12:37] <Pegasus_RPG> then made a checkout (I like checkouts better)
[12:37] <Pegasus_RPG> then made a change, then committed
[12:37] <jelmer> Pegasus_RPG: bzr won't update the checkout, just the branch, over sftp
[12:38] <Pegasus_RPG> I need bzr+ssh://  ?
[12:38] <jelmer> Pegasus_RPG: no, you'll need something like the push-and-update plugint to update the remote working tree
[12:38] <Pegasus_RPG> so how does a commit work with launchpad then?
[12:39] <Pegasus_RPG> I've been doing that for years
[12:39] <jam> jelmer, mgz, vila: Has there been a qbzr *release* to correlate with the Unicode encoding problem, or is 2.5b3 supposed to include qbzr trunk?
[12:45] <jelmer> jam: I'm not sure, I'm having trouble finding the unicode bug at the moment
[12:46] <jam> bug #889208
[12:46] <ubot5> Launchpad bug 872616 in QBzr "duplicate for #889208 TypeError on all commands that get progress report from subprocess" [Critical,Fix released] https://launchpad.net/bugs/872616
[12:46] <jam> well, 872616 I guess
[12:48] <vila> installers for betas are supposed to carry tips unless specifically told otherwise no ?
[12:48] <jelmer> jam: I suspect you'll need trunk as (as far as I can tell) qbzr hasn't done a release since that bug was reported
[12:50] <jam> vila: nope
[12:50] <jam> vila: at least, the last 99 windows installers didn't
[12:50] <jam> perhaps I've just been doing them all wrong
[12:50] <vila> too bad, that's what OSX installers do :-/
[12:51] <vila> they switch to official releases or specific revisions when .0 is reached
[12:52] <vila> the idea being to give some exposure to plugins during the betas and give some incentive to plugin authors to do some official releases
[12:53] <Pegasus_RPG> jelmer: I'm confused...how does Bazaar accomplish it's main function if users can't update the server's repo by default?
[12:53] <jelmer> Pegasus_RPG: it can update the repository, but it doesn't update the files in the working tree
[12:54] <jelmer> Pegasus_RPG: you'll notice that if you run "bzr up" in the remote repository it will create those files
[12:54] <jam> vila: it seems a bit odd to expose trunk's tip, and then revert it to a released version if the plugin doesn't actually make a release.
[12:54] <Pegasus_RPG> jelmer: actually, it complains   bzr: ERROR: No WorkingTree exists for "file:///var/www/Browns/OperationsSystem/.bzr/checkout/".
[12:54] <vila> jam: which is why I said "or specific revisions"
[12:55] <jam> vila: sure. Though IMO it isn't the packager's decision what version of X should be released to the world, but up to upstream. Again, people can certainly have different opinions.
[12:56] <jam> we can certainly change the release process, the build tool is capable of releasing from tip or from explicit versions
[12:56] <jam> I'm certainly not planning on running that debate ATM
[12:56] <jelmer> Pegasus_RPG: hmm, I'm not sure I understand what you're asking in that case
[12:56] <jam> I just noticed 'mgz' saying "wait for the next release", and noticing that it wouldn't actually have the fix
[12:57] <jam> qbzr specifically used to make monthly releases to coincide even with bzr betas.
[12:57] <vila> jam: then you know better than me :)
[12:58] <vila> jam: ask the qbzr maintainers maybe ?
[12:58] <jam> vila: bialix and garyvdm aren't in the channel, mgz made the fix but hasn't responded (is he off today?)
[12:59] <Pegasus_RPG> jelmer: OK... I want to convert an existing static directory on a web server into a bzr repo so I can make a local checkout, work on it, then commit the changes to the live server. How do I do that?
[13:00] <mgz> jam: you're right it's odd, but you do need qbzr trunk currently
[13:00] <Pegasus_RPG> jelmer: So far, I installed bzr locally, straight-copied the static web server files to a local directory, bzr init'ed it, then bzr push --use-existing-dir   to the exising server directory.
[13:00] <jelmer> Pegasus_RPG: ahh
[13:00] <jelmer> Pegasus_RPG: you want to add all the files to the repository - try "bzr add ." followed by "bzr commit"
[13:01] <jelmer> Pegasus_RPG: to upload the files to the remote location, you probably want to use "bzr upload" rather than "bzr push"
[13:02] <jelmer> Pegasus_RPG: ("bzr push" only updates the remote bzr repository, and doesn't update a checkout if it exists there)
[13:02] <Pegasus_RPG> jelmer: ok, so use bzr upload all the time or just the first time?
[13:02] <jelmer> Pegasus_RPG: all the time
[13:03] <Pegasus_RPG> ok. (I still wonder how LaunchPad repos work. There, I can make a local checkout, work on it, then bzr commit and the changes are up on the server for all to soo.)
[13:04] <Pegasus_RPG> jelmer: erm, Bazaar 2.1.2 doesn't know "upload"
[13:04] <vila> Pegasus_RPG: there is no working trees on launchpad
[13:04] <jelmer> Pegasus_RPG: it's a plugin
[13:20] <mgz> initing bzrlib in a script is still a pain
[13:22] <vila> what could make it less painful ?
[13:23] <mgz> not having to know which other random things don't get called in initialize and need to be done seperately
[13:24] <mgz> in this case, I needed commands._register_builtin_commands() and plugin.load_plugins() and commands.install_bzr_command_hooks()
[13:25] <jelmer> mgz: I think we should have a load_plugins=bool argument for bzrlib.intiialize
[13:25] <mgz> vila: do you have a lot of plugins in you base setup?
[13:25] <mgz> jelmer: hooks are also an issue it seems
[13:26] <mgz> vila: can you run lp:~gz/+junk/list_global_options and pastebin the results?
[13:26] <vila> mgz: 28 plugins
[13:27] <mgz> I'm on a minor yak mission.
[13:28] <vila> http://paste.ubuntu.com/738202/
[13:29] <vila> mgz: ^
[13:31] <jelmer> hmm, 48 plugins here..
[13:33] <mgz> do you get anything more running the script jelmer?
[13:35] <jelmer> mgz: Global options used by plugins: ['change', 'directory', 'force', 'merge-type', 'overwrite', 'remember', 'reprocess', 'revision', 'show-ids', 'timezone', 'verbose']
[13:35] <mgz> force and reprocess
[13:35] <mgz> cool, thanks!
[13:36] <jelmer> pipeline uses reprocess
[13:38] <mgz> force is a bit funky, doesn't come with help
[13:38] <mgz> all the bzrlib commands that want --force supply an option so you know what's being forced
=== Kraln- is now known as Kraln
[14:52] <GRiD> jam, thanks for analysis on bug 720853
[14:52] <ubot5> Launchpad bug 720853 in Bazaar "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [Medium,In progress] https://launchpad.net/bugs/720853
=== yofel_ is now known as yofel
=== Quintasan_ is now known as Quintasan
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
=== deryck[lunch] is now known as deryck
=== beuno-lunch is now known as beuno
[18:30] <DeafFish> When will the nested tree feature be released?
[18:55] <jelmer> DeafFish: hi
[18:55] <DeafFish> Hi
[18:56] <jelmer> DeafFish: there is some basic support for nested trees in the experimental 'development-subtree' format in current versions of bzr
[18:56] <DeafFish> Ah, ok
[18:56] <jelmer> DeafFish: finishing nested trees and adding support for it to the stable format is on our list of things to work on
[18:57] <DeafFish> Any word on when it will move into stable?
[18:58] <jelmer> DeafFish: not really, sorry
[18:58] <DeafFish> No worries
[18:59] <DeafFish> As of right now it isn't a problem
[19:00] <DeafFish> Thanks!
[19:15] <glyph> hello bzr
[19:15] <glyph> https://bugs.launchpad.net/bzr/+bug/890373
[19:15] <ubot5> Ubuntu bug 890373 in Bazaar "can't get a launchpad branch into a shared repository" [Undecided,New]
[19:16] <glyph> once again Twisted development is thwarted by trying to use bzr :(
[19:21] <jelmer> hi glyph
[19:22] <glyph> hi jelmer
[19:22] <mgz> looks like bug 806348
[19:22] <ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
[19:23] <mgz> though I thought it was one exarkun had already reported
[19:23] <glyph> mgz: we run into it every so often
[19:23] <glyph> at inconvenient times
[19:23] <jelmer> mgz: I've marked it as a dupe
[19:23] <glyph> I can send you my shared repo if that would help
[19:24] <jelmer> now that bzr-svn passes all the main bzr tests I'm pretty sure it no longmer creates revisions with this issue
[19:24] <jelmer> but there are probably still revisions out there in the wild that were created with older versions of bzr-svn
[19:25] <glyph> jelmer: is there a way to fix it?
[19:25] <glyph> jelmer: we have an official bzr mirror, and we're trying to migrate slowly to bzr rather than svn, these periodic disasters notwithstanding
[19:26] <glyph> jelmer: but throwing out our repository and breaking all clients every time we discover a wayward revision is not really an attractive option :-\
[19:29] <mgz> glyph: as with this other things you guys have reported, looks like we just need to fix the bug
[19:31] <glyph> mgz: yes please
[19:33] <jelmer> glyph: there are two things - 1) updating your mirror to have the right representation of those svn revisions (created with bzr-svn 1.1.1) will make sure you don't hit this bug, and 2) bzr should be able to cope with this situation (perhaps warn, because it is after all slightly different metadata) but not fail
[19:33] <glyph> jelmer: oh
[19:33] <glyph> jelmer: looks like I'm still on 1.0.5dev
[19:33] <glyph> jelmer: has 1.1.1 made it into a mac installer yet?
[19:38] <jelmer> glyph: no, it looks like it's a fair few revisions behind
[19:41] <jelmer> doxx isn't around at the moment, I'll submit an MP
[19:56] <jelmer> glyph: submitted an updated for the 2.4 mac installers, hopefully doxx will merge that for the next one
[19:56] <jelmer> back later
[21:13] <glyph> so speaking of things which don't work right
[21:13] <glyph> what's the status of bzr-git?  can one maintain a git mirror of a bzr repository yet?
[21:14] <jelmer> glyph: no, but we're getting there
[21:15] <jdobrien> hi all... a while ago someone was telling me about an alternative to using repo when you have a number of consecutive branches to work on...any help/reminders would be appreciated
[21:15] <jelmer> glyph: bug #544776 is the main bug to track
[21:15] <ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776
[21:15] <jelmer> jdobrien: hi
[21:15] <jelmer> jdobrien: colocated branches perhaps?
[21:17] <glyph> jelmer: thanks.  I know it's kinda ridiculous to even ask, but: do you have an ETA?
[21:17] <glyph> (how come launchpad doesn't track effort estimates)
[21:19] <jdobrien> jelmer: that's it :)
[21:26] <jelmer> glyph: so, in its most simple form (maintaining an incremental git mirror of the bzr branch, no merging back into bzr), it apparently already works
[21:27] <jelmer> glyph: somebody is using that to maintain a git mirror of mysql
[21:27] <jelmer> glyph: that said, the format is still experimental and there are still a lot of tests that need fixing - I'm not going to enable this until that happens
[21:28] <glyph> jelmer: I'll just bug Twisted people who want us to move to bzr to start clicking on that bug :)
[21:29] <jelmer> glyph: (I don't really want to end up with bugs similar to bug 806348, but for bzr-git)
[21:29] <ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
[21:30] <jelmer> glyph: it is one of the things I'm working on though, and we have made some big improvements towards bug 544776 in the last few months
[21:30] <ubot5> Error: Could not gather data from Launchpad for bug #544776 (https://launchpad.net/bugs/544776). The error has been logged
[21:36] <glyph> jelmer: is there a way to fix the shared repository with the buggy revisions yet without re-importing it from scratch?
[21:38] <jdobrien> jelmer: if I am starting with an empty directory (not bzr'd) and a project in launchpad and i want to use colo, what do i do? I'm following the tutorial and it's not making sense
[21:48] <jelmer> jdobrien: sorry, I don't actually have any experience with bzr-colo myself
[21:48] <jdobrien> jelmer: ok
[21:50] <jelmer> glyph: re-importing from scratch is the only way I'm aware of. fixing the bzr side of things (not error out so badly, but coping with the inconsistent metadata) would also work around it of course
[22:16] <glyph> jelmer: what about lp:twisted
[22:17] <glyph> jelmer: will that automatically re-run its import at some point?
[23:05] <jelmer> glyph: that's a good point, I'll look into it