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