| 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:07 |
| jimis | lifeless: can it be done with a bzr shell command? | 00:13 |
| lifeless | no | 00:14 |
| lifeless | its using the plumbing | 00:14 |
| 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:18 |
| lifeless | jimis: everything you have locally that isn't in the backup server will be copied | 00:33 |
| jimis | alright, thanks for helping lifeless | 01:11 |
| AfC | Not really a bzr builddeb question, but if I need to do | 03:33 |
| AfC | $ DEB_BUILD_OPTIONS=nocheck bzr builddeb -S | 03:33 |
| 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:34 |
| AfC | Well, doesn't seem to propagate, as expected. Ripping tests out of debian/rules instead. | 03:59 |
| mgz | morning all! | 07:15 |
| vila | hi all ! (including mgz ;) | 07:20 |
| mgz | hey vila | 07:23 |
| 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:25 |
| mgz | yeah, just looking at that now | 07:26 |
| vila | cool | 07:27 |
| mgz | hm, is the TestActivityMixin code right? | 07:28 |
| mgz | can't see from the diff | 07:28 |
| 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:29 |
| 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:30 |
| vila | right, there are two additional changes summarized by the commit messages, | 07:31 |
| 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:33 |
| 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:34 |
| vila | just wanted to make sure you were till agreeing as the extended proposal is quite bugger | 07:35 |
| vila | hehe, bigger | 07:35 |
| mgz | send it! :) | 07:37 |
| vila | sent :) | 07:37 |
| 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:47 |
| bob2 | windows has no execute bit | 08:49 |
| MvG | That's what I thought. But then why does bzr (cygwin command line as well as tortoise bzr) report changes there? | 08:50 |
| mgz | it's a cygwin quirk | 08:51 |
| bob2 | I'd think cygwin would emulate it with some ridiculous hidden file or something | 08:51 |
| 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:54 |
| 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 | 08:57 |
| 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:03 |
| mgz | if you notice any other causes, please file bugs | 09:04 |
| mgz | this stuff is fixable :) | 09:05 |
| vila | mgz: still on the shared-stores review ? Can I help ? | 09:25 |
| mgz | ah, no, wandered off on to other things | 09:26 |
| mgz | I shall resume in a sec | 09:26 |
| vila | for those following from home: quantal chroot installed on jubany and a first package with problematic xz file successfully imported | 14:19 |
| mgz | woohoo. | 14:22 |
| 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:31 |
| james_w | vila, have you seen the fallout? | 14:44 |
| vila | james_w: which one ? I just fixed categorize_failures | 14:45 |
| james_w | add-import-jobs mail too | 14:45 |
| 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:47 |
| vila | ha cool, didn't get the emails yet, that's eexactly the part I'm debugging right now | 14:48 |
| vila | ha crap, crontab don't expand variables, why do I keep forgetting that | 14:51 |
| vila | james_w: any reason to not use LANG=C instead of LANG="en_GB.UTF-8" ? | 14:53 |
| james_w | dunno | 14:54 |
| vila | mgz: can the above have any fallout for the fs encoding ? | 14:54 |
| 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:55 |
| mgz | seems deeply inlikely, what's the full output? | 14:56 |
| mgz | or, why are we worrying about what LANG is set to? | 14:57 |
| vila | yeah, the later, different issue | 14:57 |
| === zyga is now known as zya-afk | ||
| 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 | 14:59 |
| mgz | or you mean it lacks the package? | 15:00 |
| 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:01 |
| vila | err, lacks the package... what do you mean ? The symptom is: bzr: warning: unsupported locale setting | 15:02 |
| mgz | vila: run `locale -a` | 15:05 |
| vila | http://paste.ubuntu.com/1137936/ C.UTF-8 ? | 15:06 |
| mgz | that would be safe. | 15:07 |
| vila | mgz: thanks, one less egg to juggle with | 15:07 |
| 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 | 15:20 |
| === deryck is now known as deryck[lunch] | ||
| LeoNerd | Hrm. I can't bzr ci foo when there are conflicts in bar, an unrelated file | 20:37 |
| fullermd | Conflicts tend to come about from merges. Last I heard, you couldn't ci foo when there was a pending merge period. | 20:39 |
| LeoNerd | My conflict comes from an unshelve | 20:40 |
| fullermd | Ah. That's new on me then. | 20:44 |
| jelmer | maxb: ping | 22:43 |
| maxb | jelmer: pong | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!