[00:00] hi all [00:05] hello [00:05] hi grid [00:20] hi jelmer [01:29] HI. http://doc.bazaar.canonical.com/plugins/en/ is a bit broken at the moment - shows a directory index. [01:30] I ended up there by Googling bzr colo which lead me to the missing http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html [02:24] hi michaelh1 [02:24] huh [02:24] Hey [02:25] i'll have a look at it [02:27] actually, i have to go out right now, but i'll have a look at it soon, thanks for pointing it out === robbyoconnor is now known as hamsterdance === hamsterdance is now known as robbyoconnor === michaelh1 is now known as michaelh1|away === elmo_ is now known as Guest35863 [08:03] morning all [08:28] hi all [08:28] hey poolie. [08:29] just the man [08:29] can you remind me - would python's default stream encoding change when it's run from cron? [08:29] it seems like it fails there but not when run from a terminal [08:29] even with LANG set [08:31] I'll check, but eg sys.stdout.encoding possibly depends on having a terminal, it can sometimes be None certainly [08:38] yup, in pythonrun.c [08:39] for some reason, the setting of the encoding attribute depends on isatty [08:39] if PYTHONIOENCODING is set to something (probably Python 2.7 only), that is used. [08:40] i thought so [08:40] and i'm lazy [08:40] gar [08:41] it's not terribly clear why this logic is used. [08:42] ok [08:42] kanbans have been failing from cron (and spamming me) because there is a unicode character somewhere in the output [08:44] hey guys [08:45] i think i will just manually create an encoder [08:45] shortest fix is probably replace sys.stdout with a codecs module wrapper that encodes to locale.getpreferredencoding [08:45] hi vila [08:45] just recorded a new signature for lp being down, the package importer made tea happily and should do so for the next rollouts [08:45] as long as you're consistent with trying to output unicode, and not mixing in non-ascii bytestrings [08:45] it's actually writing to a file not stdout [08:46] but yes [08:46] I'm still looking at the 6 failures which may also be recorded as identifying lp being down [08:46] s/6/4/ [08:46] oh? [08:46] until we deploy a new restfulclient it will continue to mishandle 503 in reading a collection, perahps [08:47] ... or actually i think i put in a new workaround? [08:47] hehe, one involves preload_root_objects :) [08:47] poolie: right [08:47] in the mean time 'requeue --auto ' is good enough [08:52] done, so 5 new signatures added, [08:53] the first one was *during* the downtime and as such represents the first access to lp which is the most important one [08:54] ok running now, hopefully better, off to squash [08:54] the others were easy to analyze which is good as it means we can progressively update them to cover all cases as they appear [08:54] poolie: enjoy :) [08:54] happy udd hacking [08:57] happy squashing [09:00] excellent, imports aborted during lp down time have already been re-processed with success (with some 'requeue --priority' help ;) [09:56] hi i've ran into a problem where im now missing a couple of commits: i had a colo-workspace with two branches "trunk" and "foo". i wanted to switch betweem them but forgot (or actually thought i didnt need it) to add the "colo:"-prefix and ran "bzr switch trunk" while on the foo branch, and then switched back with "bzr switch foo" [09:56] but.. the foo-branch im on now is not the colo-branch "foo" [09:56] in fact: [09:56] bzr colo-branches [09:56] bzr: ERROR: No colocated workspace in . [09:56] is there any way to get my colo-workspace/branches back? [09:58] i had a couple of commits in colo:foo that are gone now... [10:09] jnl: find . -path '*/.bzr/branch' ? [10:27] jam: ah! ./.bzr/branches/foo/.bzr/branch [10:28] jnl: right, that is how colocated stores the real branches [10:28] I'm not sure how to get your working space colo-ified again [10:28] but the history is still available [10:28] jam: bzr log in that dir looks like my missing branch! [10:28] sweet, thanks! [11:46] jelmer: I managed to get everything into svn, though I had to limit it to 100 changes at a time because the propery hook would fail for some reason after doing many [11:49] redwyrex: oh, that's odd [11:49] redwyrex: what's the error? [11:50] umm something about the tip revision or something [11:50] I assume it's on the svn side [11:55] anyway, thanks for your help [12:21] jelmer: still around? [12:21] lamont: yes, hi\ [12:22] see chinstrap:~lamont/bzr-logs/* [12:23] the .1 on the version is me messing up the upload and repackaging the source with the right dsc format version :( [12:25] Hmm, I thought ~9 already had the source format changed back to "1.0" ? [12:29] lamont: The problem does appear to be that the patches aren't applied [12:30] lamont: is this ~9 from the cat-proposed archive, or yours? [12:31] bah [12:32] jelmer: it had source/format=1, but the .dsc was still new or such [12:32] Architecture: any all [12:32] so I rebuilt it. [12:33] let me see how a .2 fares === tchan1 is now known as tchan [13:32] mgz: I poked at https://answers.launchpad.net/bzr/+question/175127 [13:32] if you could follow up, that would be great, as I spent a bit too much time on it already [13:33] jam: I've just been reading that as I ate my lunch and was wondering how to send you a teddy bear [13:34] will follow up as needed. [13:36] mgz: so we could do something like fix up leo-editor, which may require a losa to run a script we write (branch into a clean repo, copy that back over the original). [13:37] I've seen complaints about leo-editor in bug reports before [13:37] I'm pretty sure he didn't intend to include a file with 800MB of '\' characters [13:40] yeah, and the good news is bzr does now have a check for that kind of accident [13:40] jelmer: I suspect that I know what happened here, verifying that [13:41] getting rid of that revision from the leo-editor repo sounds like a good plan [13:41] jelmer: how much longer will you be aorund? [13:41] mgz: sort of. If you add a file in revision 1, and then in rev2 you bloat it to 800MB, bzr won't warn you [13:41] I don't think [13:41] (the check was put in 'add') [13:42] which is actually what happened here. [13:42] the file has a parent revision. [13:42] which is a wee bit smaller :) [13:50] jam: I noticed when subscribing to things last night I'm down as the approver for foundatons-p-bzr-workflows [13:51] mgz: I think that was mostly that I wanted you to be present at the meeting, and by making you an 'Important Person' it will try to schedule around that. [13:52] I'm now an essential subscriber, so I think the schedual should now know that I need to be there? [13:52] I think it is actually supposed to be in the linaro-training track, which was added after I was setting up the blueprint [13:52] I'll see if I can do something about it [13:53] if there's anything else you need or would like me to do for UDS, poke [13:53] lamont: I'll be around for another 3 hours [13:53] mgz: it looks like the actually session is going to be: https://blueprints.launchpad.net/linaro/+spec/linaro-training-bzr [13:54] Andy set up a different session, so we'll just switch to that one [13:55] wow, I wanted to try and mark it superseded by the other session. [13:55] But if you try to go there [13:55] it requires that you select the superseding blueprint from a drop-down list [13:55] of *all* ubuntu sessions [13:55] it is about 1900 pixels wide [13:56] and probably 10,000 entries in it? [13:57] on the plus side, I can view source to actually get a reasonable view of it, and linaro-training-bzr isn't in there ... [14:01] yep, that was pretty funny [14:01] did you delete it then, or did my hack go horribly wrong? [14:02] mgz: I retargetted it to linaro, and then superseded it with the above spec [14:02] ah, good good. === zyga is now known as zyga-afk === Guest35863 is now known as elmo [15:37] jam: wasn't a name change reason for updating a file's last modified data? [15:50] nevermind, there's something else going wrong === deryck is now known as deryck[lunch] === zyga-afk is now known as zyga === beuno is now known as beuno-lunch === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno [17:50] jelmer: yes, rename to another directory, and changing a filename are in the per-file graph. Note that renaming a directory isn't in the file's graph [17:55] jam: Thanks [17:56] jam: I just fixed the last failing bzr-svn test, which was related to that. [17:56] * jelmer prepares a victory email for the mailing list [18:05] jelmer: congrats [19:27] jelmer: your test suite runs forever on some architectures. just sayin === yofel_ is now known as yofel [20:25] lamont: what's your definition of forever ? :-) More than an hour? [20:26] 8.3 hrs [20:26] you know, forever [20:30] lamont: ah, worse than Launchpad's testsuite in its dark days. That is forever. [20:55] it's also a bbg3 [21:42] exit [22:51] hi jelmer [23:00] hi Noldorin \ [23:06] jelmer: ticket updated, still waiting on some of the bzr builds to finish [23:06] lamont: thanks [23:07] lamont: That's indeed very long. These were the arm/sparc builders? [23:07] and I'll be updating a wiki page somewhere with lessons learned from the packaging fun [23:07] yeah [23:07] arm [23:10] lamont: thanks, that'd be useful [23:11] jelmer: don't delete your final versions from your ppa - I'll want to go poke at them a little in doing that update [23:12] lamont: sure, I'll leave them around [23:14] jelmer, how's things going? [23:17] lamont: do you know when hardy is going to disappear from the builders? after 12.04? [23:22] Noldorin: alright, how are you? [23:22] managed to get the full bzr testsuite to pass against bzr-svn earlier today, which I'm quite pleased with [23:23] jelmer: \o/ [23:23] g'morning spiv :) [23:23] how are things at the big G? [23:23] jelmer: congratulations [23:25] thumper: thanks [23:25] I'll be really pleased when we manage to do this for git and hg, but that's some time away [23:30] jelmer, pretty decent, just as busy as ever heh. [23:30] jelmer, same with you? bzr 2.5 keeping you occupied? === r0bby_ is now known as robbyoconnor