[00:07] <lifeless> yah
[00:07] <lifeless> into a shared repository
[00:07] <lifeless> and ues the python fragment I sketched to sync the repository data
[00:13] <jimis> lifeless: can it be done with a bzr shell command?
[00:14] <lifeless> no
[00:14] <lifeless> its using the plumbing
[00:18] <jimis> also do I have to periodically resync the backup-server repo with lp:gcc, or will all data (even public data on lp:gcc) be pushed when backing up?
[00:33] <lifeless> jimis: everything you have locally that isn't in the backup server will be copied
[01:11] <jimis> alright, thanks for helping lifeless
[03:33] <AfC> Not really a bzr builddeb question, but if I need to do
[03:33] <AfC> $ DEB_BUILD_OPTIONS=nocheck bzr builddeb -S
[03:34] <AfC> will the resultant source package, sent to launchpad, be configured to skip the tests?
[03:34] <AfC> Obviously it works locally, but I'm not really expecting it to propagate. Does it?
[03:34] <AfC> [Otherwise, I'll have to patch the tests out of the debian/rules file, which seems sub-optimal]
[03:59] <AfC> Well, doesn't seem to propagate, as expected. Ripping tests out of debian/rules instead.
[07:15] <mgz> morning all!
[07:20] <vila> hi all ! (including mgz ;)
[07:23] <mgz> hey vila
[07:25] <vila> mgz: I addressed your remark on the TestInTempDir proposal, would you mind re-review (just look at the added revs rather than the whole diff though). Also, if you could share your thoughts about the shared stores one, that would be awesome !
[07:26] <mgz> yeah, just looking at that now
[07:27] <vila> cool
[07:28] <mgz> hm, is the TestActivityMixin code right?
[07:28] <mgz> can't see from the diff
[07:29] <mgz> but calling both super...setUp and TestActivityMixin.setUp seems off
[07:29] <mgz> the new style is just to call super from all methods, no?
[07:30] <mgz> but I guess there being no object.setUp messes with that...
[07:30] <mgz> it's a painful way of spelling that bit of code
[07:31] <vila> right, there are two additional changes summarized by the commit messages,
[07:33] <mgz> okay, yup, seems to make sense
[07:33] <vila> 6555 stop relying on base classes deriving from TestCase http://bazaar.launchpad.net/~vila/bzr/thou-shall-use-testcaseintempdir/revision/6554
[07:34] <mgz> mp is already approved
[07:34] <vila> and then, always calling super() instead of mentioning the base class, that one is a bit more invasive but mechanical and tested (as in running the full test suite)
[07:34] <vila> ok
[07:35] <vila> just wanted to make sure you were till agreeing as the extended proposal is quite bugger
[07:35] <vila> hehe, bigger
[07:37] <mgz> send it! :)
[07:37] <vila> sent :)
[08:47] <MvG> Hi! What's the significance of executable bits on Windows? A bzr working tree on a Windows system often reports changes to those x bits, which can be quite confusing. Wouldn't it make more sense to simply ignore that bit on windows?
[08:49] <bob2> windows has no execute bit
[08:50] <MvG> That's what I thought. But then why does bzr (cygwin command line as well as tortoise bzr) report changes there?
[08:51] <mgz> it's a cygwin quirk
[08:51] <bob2> I'd think cygwin would emulate it with some ridiculous hidden file or something
[08:54] <mgz> ...can't find the bug about this currently
[08:54] <MvG> But tortoise shouldn't be affected by cygwin quirks. And just because I use the cygwin bash to execute bzr shouldn't influence the python interpreter bzr is using either.
[08:57] <mgz> maybe bug 938438 then?
[08:57] <ubot5`> Launchpad bug 938438 in Bazaar "`bzr resolve --take-this` clears x-bit on win32" [Medium,Confirmed] https://launchpad.net/bugs/938438
[09:03] <MvG> mgz: Not sure whether all my instances of this problem are due to that bug, but it certainly might contribute.
[09:03] <MvG> Thanks.
[09:04] <mgz> if you notice any other causes, please file bugs
[09:05] <mgz> this stuff is fixable :)
[09:25] <vila> mgz: still on the shared-stores review ? Can I help ?
[09:26] <mgz> ah, no, wandered off on to other things
[09:26] <mgz> I shall resume in a sec
[14:19] <vila> for those following from home: quantal chroot installed on jubany and a first package with problematic xz file successfully imported
[14:22] <mgz> woohoo.
[14:31] <kinkie> hi all.. do you know if it's possible to silence the message about mismatching local/remote repository formats? I don't mind the performance hit, but the message is annoying.. thanks!
[14:44] <james_w> vila, have you seen the fallout?
[14:45] <vila> james_w: which one ? I just fixed categorize_failures
[14:45] <james_w> add-import-jobs mail too
[14:47] <james_w> W: line 14 [quantal]: Deprecated key 'priority' used
[14:47] <james_w> I: This option will be removed in the future; please update your configuration
[14:47] <james_w> /usr/bin/python: can't open file '${BASE_DIR}/bin/add-import-jobs': [Errno 2] No such file or directory
[14:47] <james_w> vila, ^
[14:48] <vila> ha cool, didn't get the emails yet, that's eexactly the part I'm debugging right now
[14:51] <vila> ha crap, crontab don't expand variables, why do I keep forgetting that
[14:53] <vila> james_w: any reason to not use LANG=C instead of LANG="en_GB.UTF-8" ?
[14:54] <james_w> dunno
[14:54] <vila> mgz: can the above have any fallout for the fs encoding ?
[14:55] <vila> james_w: don't remember why you put it there in the first place ?
[14:55] <james_w> no
[14:55] <james_w> I suspect fs encoding indeed
[14:56] <mgz> seems deeply inlikely, what's the full output?
[14:57] <mgz> or, why are we worrying about what LANG is set to?
[14:57] <vila> yeah, the later, different issue
[14:59] <vila> mgz: the chroot has no locale so I'm asked to use LANG=C and I wonder if that will break something else
[14:59] <mgz> LANG=C *is* no locale
[15:00] <mgz> or you mean it lacks the package?
[15:01] <mgz> it may break, depending on whether my filessystem encoding fix is in the bzr version used, and how careful the code is with printing unicode output
[15:01] <vila> I can upgrade bzr
[15:02] <vila> err, lacks the package... what do you mean ? The symptom is: bzr: warning: unsupported locale setting
[15:05] <mgz> vila: run `locale -a`
[15:06] <vila> http://paste.ubuntu.com/1137936/ C.UTF-8 ?
[15:07] <mgz> that would be safe.
[15:07] <vila> mgz: thanks, one less egg to juggle with
[15:20] <vila>  File "/srv/package-import.canonical.com/new/scripts/udd/scripts/requeue_package.py", line 47, in main
[15:20] <vila>     lock = icommon.lock_path(conf.get('pi.locks_dir'), package)
[15:20] <vila> TypeError: lock_path() takes exactly 1 argument (2 given)
[15:20] <vila> shudder
[20:37] <LeoNerd> Hrm. I can't   bzr ci foo   when there are conflicts in  bar,  an unrelated file
[20:39] <fullermd> Conflicts tend to come about from merges.  Last I heard, you couldn't ci foo when there was a pending merge period.
[20:40] <LeoNerd> My conflict comes from an unshelve
[20:44] <fullermd> Ah.  That's new on me then.
[22:43] <jelmer> maxb: ping
[23:51] <maxb> jelmer: pong