[06:56] <jam> morning all
[07:05] <vila> hey jam
[07:05] <vila> morning all
[07:43] <Riddell> good morning
[07:45] <jelmer> moin
[07:47] <vila> jelmer: Riddell " moin
[08:04] <Riddell> oneiric beta's out, time to upgrade everyone!
[08:25] <poolie> hi Riddell, jelmer, vila
[08:31] <poolie> vila, so there's no pressure for a 2.3.5 or 2.4.1 yet?
[08:31] <vila> worth a check but I think we're fine there
[08:33] <poolie> so 2.2.5 is mostly for the sake of branch-out-of-date warnings?
[08:33] <vila> I should file a bug probably if only to collect feedback about what the upgrade policies are across ... err... whatever combination of python/subunit/testtools we want to support on ... hardy, lucid and up ?
[08:34] <vila> so far yes, there is also #805809 but it's unclear that many people can/will encounter it
[08:34] <jam> vila: if you're just doing "date" on pqm, it tells you the timezone
[08:34] <vila> jam: UTC then
[08:35] <vila> jam: but it makes the file stamp origin even more... surprising
[08:35] <vila> jam: any guess for that ?
[08:36] <jam> vila: I'm not 100% sure what those timestamps are, let me dig a bit
[08:37] <jam> vila: 'the file timestamp', is that mtime or ctime?
[08:37] <jam> (last modification time, creation time)
[08:38] <jam> its pretty clear that your file times don't correlate well with your datestamps
[08:38] <vila> jam: I mean the stamp embedded in the file *name*
[08:39] <jam> vila: I think that might be the time it was submitted, which could certainly vary wildly from when the test starts
[08:39] <vila> jam: so patch.1314909400.log ==> 2011-09-01 22:36:40
[08:39] <vila> jam: you mean received ?
[08:39] <jam> vila: sure
[08:39] <jam> given that 2 of them are about 3 seconds different
[08:39] <jam> 2011-09-01 13:03:31: duration: 2:53:02 start: 2011-09-01 15:18:26, end: 2011-09-01 18:11:28
[08:39] <jam> 2011-09-01 13:03:34: duration: 2:07:47 start: 2011-09-01 18:13:16, end: 2011-09-01 20:21:03
[08:39] <jam> that can certainly be "submit submit"
[08:40] <jam> but it won't be running a test in between there
[08:40] <vila> jam: vary, yes, depending on load, but *after* selftest starts ???!?!?!
[08:40]  * jelmer will bbiab
[08:40] <vila> jam: yeah, I noticed the 3 seconds
[08:40] <jam> vila: not-be-reliable-at-all-because-it-has-nothing-to-do-with-when-the-test-starts
[08:41] <poolie> hi jam?
[08:41] <vila> jam: well, the file *has* to exist before we write into it
[08:41] <jam> hi poolie
[08:41] <poolie> hey, see my pm?
[08:41] <jam> poolie: I did not
[08:41] <jam> ugh, there it is
[08:42] <vila> jam: so it *has* something to do with when the test starts...
[08:43] <jam> vila: given the lack of significant correlation, I would ignore it personally
[08:43] <jam> or read the pqm code to figure out what the number means
[08:57] <poolie> vila, hey, i'm kind of concerned this pqm investigation is ..
[08:57] <poolie> being done in a laborious way, i suppose
[08:57] <poolie> i want the test suite to be fast again
[08:58] <poolie> IS are working on replacing the machine
[08:58] <poolie> separately we could look at tarmac
[08:58] <poolie> hopefully this particular setup has a life expectancy of only days or weeks
[08:59] <poolie> but, do as you think best i suppose
[09:00] <jam> poolie: I have a patch that just removes fsync, and I'm happy enough that it fixes the short term issues
[09:00] <jam> its about 2:1
[09:01] <poolie> wfm
[09:01] <poolie> ok, good night then
[09:01] <vila> poolie: well, I agree with all you've said above, that was my understanding weeks ago when I realize the slowdown (i.e. wait for the new pqm before anything else), as you've seen the patch was minimal and I didn't spend much on it
[09:01] <poolie> ok
[09:03] <vila> jam, poolie, jelmer, Riddell : thanks for not targeting lp:bzr/2.2 with your landings today, other branches are fine, will slow me down a bit, but I can work on other stuff
[09:06] <jam> vila: I shall never submit to your tyranny!
[09:06] <jam> and vila, you're probably not going to get a merge window before tomorrow, unfortunately
[09:07] <jam> I'm counting about 12 hours of PQM before your 2.2 branch
[09:09] <jam> vila: unless you want to prioritize: https://code.launchpad.net/~jameinel/bzr/2.4-disable-selftest-fdatasync-837293/+merge/73757 before the rest :)
[09:10] <vila> jam: hehe
[09:11] <vila> yeah, I went to the pqm web page after saying this and... well, the point is: once 2.2.5 lands, I'll need to pull and submit again to open 2.2.6, so please leave 2.2 alone until you see the opening
[10:19] <danilos> jam: hi, thanks for the review — I think I'll just go with what I have now, just because HTTP headers seem to be set already and I'd have to restructure the code a bit otherwise to be able to raise a HTTPNotFound instead
[10:19] <jam> danilos: I don't think the headers are sent until we actually start sending data
[10:19] <jam> but I could be wrong
[10:19] <danilos> jam: also, LP seems not to have picked up on your "merge:approve": I think you've got to use something like " merge approve\n review approve"
[10:20] <jam> danilos: no, I just need "merge: approve" vs "merge:approve" I was missing a ' '
[10:20] <jam> merge approve auto review approves
[10:20] <danilos> jam: I've actually tried it out and got "AssertionError: Attempt to set headers a second time w/o an exc_info"
[10:20] <danilos> jam: oh, nice, I didn't know that :)
[10:20] <jam> danilos: yeah, saves typing
[10:20] <jam> so sure, go ahead and land it
[10:21] <danilos> jam: thanks, I will
[10:25] <danilos> jam, can you please mark it as approved so it doesn't appear as unapproved on the bug (https://code.launchpad.net/~danilo/loggerhead/bug-839395/+merge/73766)
[10:25] <danilos> ubot5, very smart, thank you
[10:25] <danilos> that's what I said!
[10:32] <jam> danilos: its marked Merged now, I don't think you need me to regress it back to Approved :)
[10:40] <danilos> jam: I thought you'd only do a vote, not touch the entire proposal status, but I guess no big deal :)
[12:34] <jelmer> jam: hi, does bug 839515 look familiar to you?
[12:35] <jelmer> I remember there were some stacking bugs that were fixed a while ago that looked similar. Could this be fallout from those bugs?
[12:39] <jam> jelmer: that specifically looks like the bug that made us default to not fetching tags
[12:41] <jam> but it does appear that the *.../ubuntu branch is broken
[12:45] <jelmer> jam: thanks for confirming
[14:55] <AuroraBorealis> so continuing my question that i didn't get answered, what exactly does 'signing' your commits do? since after signing mine, the branch appears unchanged
[14:58] <jelmer_> AuroraBorealis, with newer versions of bzr you can see the signatures by running "bzr log" with a particular option
[14:58] <AuroraBorealis> does that include 2.4.0?
[14:59] <jelmer_> AuroraBorealis: I'm not sure, it might just be bzr.dev at this point
[14:59] <AuroraBorealis> it seems natty doesn't have 2.4.0 yet o.o
[14:59] <jelmer_> AuroraBorealis, though bzr has supported creating signatures since before 2.0 I think
[15:00] <AuroraBorealis> so should i push my local branch over my remote one to get it to have the signatures?
[15:00] <AuroraBorealis> since i did it on my local branch, it says that no changes were made
[15:01] <jelmer_> I'm not sure if we fill in signatures yet, I think we just fetch the signature for a revision when we fetch the revision
[15:03] <AuroraBorealis> and it seems that at least in 2.3.4, the verify signatures option went away
[15:05] <jelmer_> AuroraBorealis, there is a verify-signatures command in 2.4 IIUC
[15:05] <AuroraBorealis> hmm
[15:06] <jelmer_> AuroraBorealis: the verify signatures option in 2.3.4 had been there for a while but wasn't actually implemented, which was why it was removed
[15:06] <AuroraBorealis> ah.
[15:06] <AuroraBorealis> so the entire signing thing needs some more work to actually be useful :3
[15:07] <jelmer_> AuroraBorealis: you can use "bzr verify-signatures" today
[15:07] <jelmer_> AuroraBorealis: so it is useful, though there are some more improvements we should make
[15:07] <AuroraBorealis> well i'm on linux and it hasn't upgraded xD
[15:09] <jelmer_> it should be in oneiric
[15:09] <AuroraBorealis> i appear to be in natty
[15:13] <jelmer_> AuroraBorealis: you can use the bzr PPA for 2.4.0 (should work on natty), or otherwise be patient for another two months
[15:13] <AuroraBorealis> is the ppa this? https://launchpad.net/~bzr/+archive/ppa
[15:14] <jelmer_> AuroraBorealis, yep
[15:19] <Riddell> should I be worried that the test bzrlib.tests.test_setup.TestSetup.test_build_and_install is failing for me in trunk?
[15:20] <vila> Riddell: locally or only on pqm ?
[15:20] <Riddell> locally
[15:20] <vila> then yes
[15:20] <vila> and I feel your pain :-/
[15:20] <AuroraBorealis> and yay i made bzr crash
[15:20] <Riddell> actually it might be due to my new install
[15:21] <AuroraBorealis> and yeah, verify -signatures don't work :<
[15:24] <AuroraBorealis> i guess i'll file a bug report, after my bagel
[15:26] <Riddell> vila: yes it was just that I didn't have everything installed
[15:27] <vila> Riddell: so it fails on on pqm now ? Missing dependency there ?
[15:27] <vila> s/on on/only on/
[15:27] <Riddell> vila: no it only ever failed locally
[15:27] <vila> ha cool
[15:28] <vila> just out of curiosity what did you fix ?
[15:30] <Riddell> vila: sudo apt-get build-dep bzr
[15:31] <vila> ha, well, yeah ;)
[16:05] <jo-erlend> I've started working with bzr and I'm really loving it. But I'm a newbie t this, and VCS in general, and I'd like to learn how to actually work with it... I mean, I currently have one directory on my computers, called ~/devel/appname and an lp bzr repository that I push to.
[16:06] <AuroraBorealis> and? :3
[16:07] <jo-erlend> and that's good, but I'm only using one branch. I'd now like to start experimenting more widely with my app, so I thought I'd setup different branches to work with, and then merge with a main branch, that in turn is pushed to lp from time to time.  Is it simply a matter of using different directories, or are there other things to consider?
[16:07] <AuroraBorealis> you have your main branch
[16:07] <AuroraBorealis> and then you just branch from that
[16:07] <AuroraBorealis> do stuff with it
[16:07] <AuroraBorealis> and when you want to merge it back, merge the main one with the other one
[16:08] <AuroraBorealis> so yeah pretty much the second branch will be a seperate folder inside the repo folder
[16:09] <jo-erlend> ok, so instead of having my code in ~/devel/appname, I'd have it in ~/devel/appname/trunk, /testing, etc? And the ~/devel/appname directory would only contain branches?
[16:10] <AuroraBorealis> usually appname is the repository
[16:10] <AuroraBorealis> trunk is the 'main deveopment branch'
[16:10] <AuroraBorealis> and then testing can be a seperate branch where you are doing experimental stuff
[16:10] <AuroraBorealis> then you can merge testing back into trunk and whatever
[16:11] <jo-erlend> yes, that's what I meant in my question. What does that look like?
[16:12] <jo-erlend> does it mean I'll have my code in appname and subdirectories of that directory will contain the branches? Or will other branches be in the same parent as the trunk?
[16:15] <AuroraBorealis> appname is the repository, it stores revisions and stuff
[16:15] <AuroraBorealis> and everything below that is a branch
[16:16] <jo-erlend> ok, so it wouldn't make much sense for appname to be versioned?
[16:17] <AuroraBorealis> well i'm just assuming that the folder appname is a repository
[16:17] <jo-erlend> right.
[16:17] <AuroraBorealis> so its not really versioned, it just holds branches
[16:17] <jo-erlend> unless that requires additional setup. It's only a directory here.
[16:17] <AuroraBorealis> you have to run bzr init-repo or create it in bazaar explorer
[16:19] <AuroraBorealis> see: http://doc.bazaar.canonical.com/latest/en/user-guide/shared_repository_layouts.html?highlight=repository
[16:19] <AuroraBorealis> and http://doc.bazaar.canonical.com/latest/en/user-reference/repositories-help.html?highlight=shared%20repository
[16:19] <jo-erlend> ok, and that is self contained so it doesn't matter if I change the name of the directory later?
[16:20] <AuroraBorealis> the name of the repository or the branch?
[16:20] <AuroraBorealis> i dont think it matters, because the actual information is in the .bzr directory in the repo / branches
[16:21] <AuroraBorealis> but it will changes obviously the URI of the repo =P
[16:21] <jo-erlend> :)
[16:24] <jo-erlend> AuroraBorealis, great links. That's precisely what I was looking for :)
[16:25] <AuroraBorealis> the thing about bazaar is that it supports multiple models
[16:25] <AuroraBorealis> so you can do it like git does, or svn and whatnot
[18:35] <gdoubleu> Using bzr-svn here, and somehow I've got a file that bzr considers versioned but that doesn't exist in the svn repo
[18:35] <gdoubleu> if I try to bzr remove the file, bzr ci, bzr dush, then I get a "SubversionException: ... path not found" error
[18:36] <gdoubleu> any ideas on how this can be corrected?  Can I safely add the file using svn and then bzr pull the change into the bzr repo?
[18:39] <gdoubleu> On a related note, other than diff'ing an export from the bzr repo and svn repo, is there any way to check if there might be other files/contents out of sync between the bzr branch and the svn repo?
[18:51] <jo-erlend> hmm. I had a branch on launchpad that I was working on .I then proposed a merge for upstream, and it was accepted. Now the branch is gone. Is that normal?
[18:52] <jo-erlend> oh, it's just hidden. But is it a bad idea to keep working on that branch after it's been merged with upstream, or will that simply mark it as unmerged?
[19:35] <amaora> test
[20:58] <sixstring> I've got bzr (client) setup just fine on one machine. But when I try to branch on a second machine, I get SSH key madness. Any idea how to make SSH or BZR happy? Do I need to copy my keys from one machine to another?
[21:07] <sixstring> Apparently, you just scp them to the target machine, from ~/.ssh/
[23:22] <jelmer> gdoubleu: what version of bzr-svn are you using?
[23:26] <poolie> hi jelmer
[23:26] <jelmer> poolie: g'day!
[23:26] <vila> hey poolie, jelmer ;)
[23:27] <jelmer> hey vila
[23:28] <jelmer> This is just wrong. when I get home on a Friday evening it ought to be quiet on IRC...
[23:28] <fullermd> Maybe your calendar crashed.
[23:28] <vila> ok, I'll mute myself ;)
[23:28] <poolie> it's saturday morning, i'm at google working on the lca programme
[23:28] <jelmer> poolie: I guess you're excused then; vila however... :-P
[23:28] <vila> Oh, you went there too ?
[23:29] <vila> jelmer: Me ? Can't have fun with the importer anymore ?
[23:30] <jelmer> vila: :)
[23:30] <vila> We need to record imports success instead of import failures: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29
[23:31] <vila> This curve going down is not getting us enough positive feedback :-p