[00:03] <poolie> looks like i got some interesting feedback about colo
[00:23] <jelmer> poolie: indeed.. almost all enthusiastic too
[00:23] <jelmer> poolie: when you say bring bzr-colo into core, did you mean as-is or in some form or another?
[00:25] <sidnei> hi poolie
[00:34] <poolie> oh, definitely with changes
[00:34] <poolie> apparently i should have been more clear about that
[01:07] <mgz> hm, how clean does pqm make things before trying a build?
[01:07] <mgz> ...I'd better just give up for the night I think.
[01:09] <lifeless> mgz: rm -rf clean
[01:14] <mgz> out of clever ideas as to what's wrong then, will fall back to blaming cython. shame I can't actually get at the generated C file.
[01:15] <mgz> if someone has the same version pqm does and want to try compiling my branch while I sleep, that'd be great.
[01:29] <poolie> mgz, i'll see what i can doo; sleep well
[01:30] <poolie> biab
[02:16] <ScottK> How do I remove a remote brach?  Not on LP, in this case on alioth.
[02:20] <lifeless> rm -rf
[02:20] <lifeless> uhm thats not helpful
[02:20] <lifeless> what I mean is, that just deleting the directory is the way
[02:21] <lifeless> and we don't have an API in bzrlib to do that at the *branch* level, but if you don't have sftp access to the branch, bzrlib's VFS can let you do the delete remotely with a few lines opython.
[02:21] <lifeless> probably a bug report would be good too
[02:22] <ScottK> I do have sftp access, so I can do it that way, but I was hoping for bzr rm -rf && bzr push or something.
[02:22] <ScottK> I'll file a bug against bzr.
[02:23] <spiv> I think there may already be a bug report.
[02:27] <ScottK> I didn't find it.
[02:27] <spiv> Ok, probably not then. :)
[07:35] <vila> hi all !
[08:32] <jam1> morning all
[08:32] <vila> hey jam :)
[08:32] <jam> sidnei: afaik, nobody is regularly running those benchmarks.
[09:45] <sidnei> hi jam
[09:46] <jam> morning sidnei
[09:46] <jam> well, morning here at least
[09:46] <sidnei> jam, here too, 6:45 to be more precise
[09:48] <sidnei> jam, we might have a volunteer for setting up the benchmarks. let's see if he sticks around :)
[10:19] <jam> sidnei: are you usually up that early?
[10:20] <sidnei> jam, i usually go back to bed for a few more hours, but decided not to today. my kids wake up around 6am. the good news is that they go to bed around 10pm. and they're just 5mo old.
[10:23] <jam> jelmer: so it certainly seems that python2.7 has yet-again changed the size of python objects
[10:23] <jam> sigh, I already had 2.5 vs 2.6 code, now I need to add 2.7 into the mix
[10:27] <jam> I can reproduce 3 failures here
[10:28] <jam> at least the failure for 'string' sizes
[10:28] <jelmer> jam: ah, urgh :-/
[10:32] <jam> jelmer: I just committed a change which handles the String cases. which are all that were failing here
[10:32] <jam> I think the other bits are probably a 64 vs 32-bit difference.
[10:32] <jam> Care to help me work them out?
[10:32] <jam> do you have a python2.6 on your machine to work with?
[10:33] <jelmer> yep, I have 2.6 installed here
[10:33] <jelmer> 3 of my 9 errors are gone with the latest trunk
[10:34] <jelmer> what can I do ?
[10:34] <jam> jelmer: can you run it w/ python2.6 and see if they all pass?
[10:34] <jam> I'm wondering if I'm just failing on 64-bit always
[10:34] <jam> I have a gut-feeling that I'm rounding to 4-byte precision, and on 64-bit it always rounds to 8-byte precision
[10:35] <jam> (a struct will always be a multiple of 8-bytes rather than 4-bytes, but that might also be a python-2.6 vs 2.7 ism)
[10:37] <jelmer> jam: fails on python2.6 too
[10:37] <jelmer> same 6 tests
[10:38] <jam> jelmer: k. Yeah, I think I'm just off on how 'packed' the struct will be.
[10:38] <jam> I'll poke at it differently, just a sec
[10:45] <jam> jelmer: try again with trunk revno 188
[10:47] <jelmer> jam: one left now with both 2.6 and 2.7
[10:47] <jelmer> test__sizeof__with_dummy (meliae.tests.test__loader.TestMemObjectCollection)
[10:47] <jelmer> AssertionError: 8340 != 8344
[10:49] <jam> jelmer: done in 189, I just missed the fix for that test.
[10:50] <jelmer> jam: I can confirm it works now
[10:50] <jam> jelmer: what brought it to your attention?
[10:51] <jelmer> jam: There's a transition going on in Debian (dh_pycentral/dh_pysupport -> dh_python2) so I had to upload a new meliae anyway and was looking at running the test suite at build time, just to be sure.
[10:59] <jelmer> jam: It looks like the exit code of run_tests.py doesn't change if any tests failed btw
[11:00] <BlankVer1e> how to find the last three logs , bzr log | head shows only 1
[11:00] <jam> jelmer: patches welcome, I've never needed the return code, because I didn't script it. I'm not entirely sure how to
[11:00] <jam> BlankVer1e: bzr log --last 3 ?
[11:00] <jam> sorry, "bzr log -r last:3"
[11:01] <jam> bzr log -r -3..-1 is what I would use, though
[11:37] <leo2007> How to resolve this error http://paste.pocoo.org/show/7CYpcX5yqrzmNUAVubHG?
[11:37] <jelmer> leo2007: run "bzr break-lock bzr+ssh://leoliu@bzr.savannah.gnu.org/emacs/trunk"
[11:38] <leo2007> that only break locks by me right?
[11:39] <leo2007> I basically C-c interrupt a 'bzr push' and now this problem.
[11:40] <jam> leo2007: bzr break-lock will only break the lock you ask it to, but it will break anyones lock. Which is why we give you the preview of who is claiming the current lock
[11:40] <jam> in your traceback, you can see your name
[11:40] <jam> "held by leoliu@vcs-noshell"
[11:41] <leo2007> ok breaking in process.
[16:35] <happyaron> where to find bzr-fast-export.py?
[16:36] <jelmer> happyaron: it's a part of the bzr-fastimport plugin
[16:37] <happyaron> thanks
[17:15] <jml> vila: hello
[17:15] <vila> jml: hey ! . o O (In what TZ is he ?!?!)
[17:15] <jml> vila: I can report that when I pull Launchpad branches that delete directories, Bazaar still gives me conflicts about not being able to remove those directories
[17:15] <jml> vila: I'm in the UK
[17:15] <jml> I am in *the* timezone.
[17:15] <vila> :)
[17:16] <vila> weird
[17:16] <jml> yeah.
[17:16] <jml> how about I make a minimal example
[17:17] <vila> yeah, that would help :-/ Orphans are still pretty rare so it's not that obvious to catch errors in edge cases
[17:18] <vila> jml: but you *do* have 'bzr.transform.orphan_policy=move' in your bazaar.conf right ?
[17:18] <jml> bzrlib.transform.orphan_policy=move
[17:18] <vila> (carefully copy/pasted from mine to avoid typos)
[17:18] <jml> ahh... bzr not bzrlib
[17:19] <vila> argh, 'bzr' not ... yeah
[17:19] <jml> ok.
[17:19] <jml> trying that
[17:21] <jml> yay
[17:21] <jml> directory/module.pyc has been orphaned in bzr-orphans
[17:21] <vila> \o/
[17:22] <vila> now, you have several options:
[17:22] <vila> - rm -fr bzr-orphans each time it appears
[17:22] <vila> - add it to .bzrignore
[17:22] <jml> oops
[17:22] <vila> - keep it intact to test that adding cruft there works ;)
[17:23] <jml> vila: were there any options between "rm -fr" and "keep it"?
[17:23] <vila>  - add it to .bzrignore
[17:24] <vila> jml: feel free to mix them ;)
[17:24] <jml> vila: ok, thanks.
[17:24] <jml> vila: is there a way I can customize the directory name / location?
[17:25] <vila> jml: and keep the feedback coming, I'm happy with it myself but I hit it so rarely I don't give myself useful feedback ;)
[17:25] <vila> jml: not really, one constraint of the implementation is that it should be *inside* the working tree
[17:25] <jml> vila: hmm ok.
[17:26] <jml> launchpad has a funny .bzrignore such that anything beginning with '+' is ignored. Hoped I could take advantage of that and save a commit
[17:27] <elmo> vila: http://package-import.ubuntu.com/status/udev.html#2011-03-15%2021:02:25.173640 <-- is that class of failure mode known?
[17:28] <vila> elmo: I think so, at least it's not the first time I've seen similar backtraces
[17:28] <elmo> vila: ok
[17:30] <vila> elmo: and the link at the bottom of the page is a good way to check that too, in this case... there are far too many >-/
[18:10] <jam> vila: isn't this http://package-import.ubuntu.com/status/adduser.html#2011-03-15%2022:54:36.634617
[18:10] <jam> the bug Andrew fixed about sharing transports?
[18:10] <james_w> yes, but it's not rolled out on jubany
[18:10] <jam> james_w: ok
[18:10] <jam> just checking, since it is currently the #1 failure
[18:10] <vila> jam: needs to be... as james_w said
[18:32] <vila> james_w: does this sounds reasonable: http://paste.ubuntu.com/583920/ ?
[18:32] <vila> james_w: AIUI, there are 3 kinds of files involved there
[18:33] <vila> james_w: 1) the logs (for the mass_import and the packages, bug #719888 asking for them to be grouped)
[18:33] <vila> james_w: 2) the status files for the web site
[18:34] <vila> james_w: 3) the diffs and merges (for debug ?)
[18:34] <vila> james_w: so putting them in different directories should be a problem (as long as no imports are running when deploying the new scripts)
[18:35] <vila> james_w: the additional question is: are diff/merges ever re-read by the scripts  (I'm 90% sure they aren't but I'd like confirmation) ?
[18:36] <james_w> the diffs and merges are the start of replacing merges.ubuntu.com, so need to be served over http
[18:36] <james_w> they are not re-read
[18:36] <vila> ohhh
[18:37] <vila> james_w: so just http://paste.ubuntu.com/583921/ would be fine then ?
[18:37] <james_w> well
[18:37] <vila> james_w: the bit I can't find is where the link is made between this directory and the web server itself
[18:37] <james_w> maybe, depends how apache is configured :-)
[18:37] <vila> :-D
[18:38] <vila> james_w: what I'd like to do is separate the logs from the www
[18:38] <james_w>         DocumentRoot /srv/package-import.canonical.com/new/logs/
[18:40] <vila> james_w: right, so that could be s/logs/www/ right ?
[18:40] <james_w> it could be
[18:40] <vila> james_w: ok, thanks
[18:40] <james_w> if we don't want to make the logs accessible over http
[18:42] <vila> james_w: well, if we want to publish relevant data the logs would need to be filtered anyway IMHO
[18:42] <james_w> why?
[18:46] <vila> james_w: well, I imagine that users won't be interested by all the details ?
[18:47] <vila> james_w: or because the raw content won't be pretty enough ?
[18:47] <james_w> right, but they aren't even linked
[18:48] <james_w> I don't have a strong preference fwiw
[18:48] <vila> james_w: indeed, and I understood that the bug was filed because the admins wanted to put the log files elsewhere to better track space consumption ?
[18:49] <james_w> I don't know
[18:49] <vila> or did I went too far by considering that the mass_import log files and the import_package log files where in the same category ?
[18:49] <james_w> I never spoke to Tom about this
[18:50] <vila> james_w: ok, thanks for the input anyway
[20:51] <lifeless> for jam/poolie - http://code.google.com/p/snappy/ - we were talking lzo etc back when looking at entropy coding in packs
[20:54] <bob2> is that the same as zippy?
[21:05] <bob2> ah, it is
[22:11] <mgz> finally through most of the interminable python-dev vcs threads and reading poolie's colo post from the other day