| === mwhudson_ is now known as mwhudson | ||
| === yofel_ is now known as yofel | ||
| === BasicPRO is now known as BasicOSX | ||
| jam | morning all | 06:56 |
|---|---|---|
| vila | hey jam | 07:05 |
| vila | morning all | 07:05 |
| === mlh is now known as RumpledForehead | ||
| === RumpledForehead is now known as mlh | ||
| Riddell | good morning | 07:43 |
| jelmer | moin | 07:45 |
| vila | jelmer: Riddell " moin | 07:47 |
| Riddell | oneiric beta's out, time to upgrade everyone! | 08:04 |
| poolie | hi Riddell, jelmer, vila | 08:25 |
| 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:31 |
| 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:33 |
| 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:34 |
| vila | jam: but it makes the file stamp origin even more... surprising | 08:35 |
| vila | jam: any guess for that ? | 08:35 |
| jam | vila: I'm not 100% sure what those timestamps are, let me dig a bit | 08:36 |
| jam | vila: 'the file timestamp', is that mtime or ctime? | 08:37 |
| jam | (last modification time, creation time) | 08:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| vila | jam: so it *has* something to do with when the test starts... | 08:42 |
| 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:43 |
| 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:57 |
| 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:58 |
| poolie | but, do as you think best i suppose | 08:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:06 |
| jam | I'm counting about 12 hours of PQM before your 2.2 branch | 09:07 |
| 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:09 |
| vila | jam: hehe | 09:10 |
| 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 | 09:11 |
| === zyga-afk is now known as zyga | ||
| 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:19 |
| 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:20 |
| danilos | jam: thanks, I will | 10:21 |
| 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 |
| ubot5 | Ubuntu bug 73766 in Bazaar GTK+ Frontends "Remove file does not update view to show file is removed" [Undecided,Fix released] | 10:25 |
| danilos | ubot5, very smart, thank you | 10:25 |
| ubot5 | danilos: I am only a bot, please don't think I'm intelligent :) | 10:25 |
| danilos | that's what I said! | 10:25 |
| jam | danilos: its marked Merged now, I don't think you need me to regress it back to Approved :) | 10:32 |
| danilos | jam: I thought you'd only do a vote, not touch the entire proposal status, but I guess no big deal :) | 10:40 |
| === Quintasan_ is now known as Quintasan | ||
| jelmer | jam: hi, does bug 839515 look familiar to you? | 12:34 |
| ubot5 | Launchpad bug 839515 in bzr (Ubuntu) "bzr crashed with BzrCheckError in _commit_write_group(): Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:3c52a9038699157dee61f9bd1b03d255fa021805',)]" [High,Triaged] https://launchpad.net/bugs/839515 | 12:34 |
| 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:35 |
| jam | jelmer: that specifically looks like the bug that made us default to not fetching tags | 12:39 |
| jam | but it does appear that the *.../ubuntu branch is broken | 12:41 |
| jelmer | jam: thanks for confirming | 12:45 |
| 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:55 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| AuroraBorealis | and it seems that at least in 2.3.4, the verify signatures option went away | 15:03 |
| jelmer_ | AuroraBorealis, there is a verify-signatures command in 2.4 IIUC | 15:05 |
| AuroraBorealis | hmm | 15:05 |
| 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:06 |
| 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:07 |
| jelmer_ | it should be in oneiric | 15:09 |
| AuroraBorealis | i appear to be in natty | 15:09 |
| 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:13 |
| jelmer_ | AuroraBorealis, yep | 15:14 |
| Riddell | should I be worried that the test bzrlib.tests.test_setup.TestSetup.test_build_and_install is failing for me in trunk? | 15:19 |
| 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:20 |
| AuroraBorealis | and yeah, verify -signatures don't work :< | 15:21 |
| AuroraBorealis | i guess i'll file a bug report, after my bagel | 15:24 |
| Riddell | vila: yes it was just that I didn't have everything installed | 15:26 |
| 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:27 |
| vila | just out of curiosity what did you fix ? | 15:28 |
| Riddell | vila: sudo apt-get build-dep bzr | 15:30 |
| vila | ha, well, yeah ;) | 15:31 |
| === beuno is now known as beuno-lunch | ||
| 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:05 |
| AuroraBorealis | and? :3 | 16:06 |
| 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:07 |
| AuroraBorealis | so yeah pretty much the second branch will be a seperate folder inside the repo folder | 16:08 |
| 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:09 |
| AuroraBorealis | usually appname is the repository | 16:10 |
| === deryck is now known as deryck[lunch] | ||
| 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:10 |
| jo-erlend | yes, that's what I meant in my question. What does that look like? | 16:11 |
| 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:12 |
| AuroraBorealis | appname is the repository, it stores revisions and stuff | 16:15 |
| AuroraBorealis | and everything below that is a branch | 16:15 |
| jo-erlend | ok, so it wouldn't make much sense for appname to be versioned? | 16:16 |
| 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:17 |
| 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:19 |
| 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:20 |
| AuroraBorealis | but it will changes obviously the URI of the repo =P | 16:21 |
| jo-erlend | :) | 16:21 |
| jo-erlend | AuroraBorealis, great links. That's precisely what I was looking for :) | 16:24 |
| 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 | 16:25 |
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| 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:35 |
| 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:36 |
| 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:39 |
| 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:51 |
| 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? | 18:52 |
| === med_out is now known as medberry | ||
| amaora | test | 19:35 |
| 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? | 20:58 |
| sixstring | Apparently, you just scp them to the target machine, from ~/.ssh/ | 21:07 |
| jelmer | gdoubleu: what version of bzr-svn are you using? | 23:22 |
| poolie | hi jelmer | 23:26 |
| jelmer | poolie: g'day! | 23:26 |
| vila | hey poolie, jelmer ;) | 23:26 |
| jelmer | hey vila | 23:27 |
| 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:28 |
| vila | jelmer: Me ? Can't have fun with the importer anymore ? | 23:29 |
| 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:30 |
| vila | This curve going down is not getting us enough positive feedback :-p | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!