igc | morning all | 00:09 |
---|---|---|
igc | moening lifless, mwhudson | 00:09 |
igc | let's try that again ... | 00:10 |
mwhudson | hi igc | 00:10 |
igc | morning lifeless, mwhudson | 00:10 |
mwhudson | :) | 00:10 |
jml | lifeless: why doesn't aws-status read my access key from the same file as ec2test? | 00:21 |
jml | i.e. ~/.ec2/aws_id | 00:22 |
lifeless | it uses the same variables as bzr ec2test | 00:23 |
lifeless | and if it doesn't find it it will look in gnome-keyring too | 00:23 |
lifeless | you could file a bug to have it look at a file as well; AFAIK the amazon toolchain just looks for environment variables, which is why I copied that | 00:24 |
jml | lifeless: ok. | 00:24 |
jml | lifeless: the real answer might be "Why does Launchpad's ec2test use a non-standard file" | 00:24 |
* jml makes a note | 00:24 | |
lifeless | of course, if the amazon toolchain does read a file, a bug on txaws is definitely in order | 00:26 |
jml | lifeless: yeah. I'll chase it up later. | 00:27 |
lifeless | thanks | 00:28 |
AfC1 | lifeless: Robert, you're signing emails with a key that's not on the public keyservers. You might want to upload it somewhere. | 00:36 |
=== AfC1 is now known as AfC | ||
lifeless | AfC: odd, I have. it just hasn't propogated >< | 00:37 |
AfC | lifeless: It's not on subkeys.pgp.net or pgp.mit.edu | 00:37 |
AfC | lifeless: I would have thought you would have uploaded to them directly, seeing as how they're the main ones | 00:38 |
* igc working on branch-specific rules today | 00:40 | |
lifeless | igc: you were going to mail about the issue; have I missed that ? | 00:41 |
igc | lifeless: nope - sending it today | 00:41 |
poolie | good morning | 00:54 |
=== _thumper_ is now known as thumper | ||
thumper | how worried should I be about 2485 revisions missing parents in ancestry and 3547 inconsistent parents? | 00:57 |
lifeless | thumper: it will be affecting the output of annotate | 00:57 |
lifeless | the 2485 are the unimported arch revisions | 00:58 |
thumper | 2645 ghost revisions | 00:58 |
lifeless | oh hmm | 00:58 |
igc | morning poolie | 00:58 |
lifeless | then its filled in ghosts | 00:58 |
bob2 | would it be sensible to have 'bzr bind' with no args pick one of the configured urls (maybe in order: parent, push, merge)? | 00:58 |
lifeless | you should reconcile anyhow | 00:58 |
poolie | helol igc | 00:58 |
lifeless | bob2: confusing | 00:58 |
poolie | will comment on your docs soon | 00:58 |
lifeless | bob2: as it already has a saved bound location | 00:59 |
thumper | lifeless: what will reconcile do? | 00:59 |
poolie | bob2: if it guaranteed to rebind just where it was last bound | 00:59 |
poolie | what he said | 00:59 |
lifeless | it will rewrite the parents | 00:59 |
thumper | to what? | 00:59 |
lifeless | to the correct value based on the data available in the repository | 00:59 |
bob2 | lifeless: hm, I meant, only if it didn't have a previously saved one | 01:00 |
lifeless | bob2: still confusing, no | 01:00 |
bob2 | ok | 01:00 |
lifeless | bob2: as in | 01:00 |
lifeless | bind (grabs parent) | 01:00 |
lifeless | pull x (sets parent in master and local) | 01:00 |
lifeless | unbind | 01:00 |
lifeless | bind | 01:00 |
lifeless | (does not grab parent) | 01:00 |
bignose | with Loggerhead, browsing a file gives me the “annotate” view | 01:14 |
thumper | what's the status of bzr-hg? | 01:14 |
bignose | how can I just view the content of the file from head, without annotation? | 01:14 |
bignose | i.e. the URL formed has …/trunk/annotate/head%3A/README | 01:15 |
bignose | what URL should I use instead to just display the raw content of that revision of the file? | 01:15 |
lifeless | mwhudson: ^ | 01:16 |
mwhudson | bignose: there is no view to display the raw content | 01:16 |
bignose | :-( | 01:16 |
mwhudson | bignose: because we're worried about xss attacks | 01:17 |
mwhudson | bignose: there is a branch which adds it somewhere, but we need a way to turn it off | 01:17 |
mwhudson | bignose: https://code.edge.launchpad.net/~intellectronica/loggerhead/view-file is one | 01:18 |
bignose | mwhudson: thanks for the response. | 01:19 |
lifeless | mwhudson: 'if hacked(): disable_it_now()' ? | 01:19 |
mwhudson | bignose: np | 01:19 |
mwhudson | lifeless: yeah | 01:19 |
lifeless | it would be nice to be able to get at plain text versions | 01:20 |
lifeless | its a pity that browser authors are insane | 01:20 |
bignose | mwhudson: actually on second thought: what XSS vulnerability? | 01:20 |
lifeless | [content sniffing] | 01:20 |
lifeless | bignose: I could upload arbitrary html to my branch | 01:20 |
bignose | shouldn't it be just a matter of serving the file as ‘Content-Type: text/plain’? | 01:20 |
mwhudson | ha, ha, yes, it should | 01:21 |
lifeless | bignose: many browsers sniff content and ignore content-type | 01:21 |
lifeless | bignose: and there is now a 'standard' under discussion for controlling when the do this. Its insane | 01:21 |
bob2 | haha | 01:21 |
bob2 | is it enabled via a meta tag? | 01:21 |
bignose | lifeless: those broswers deserve to get pwned then :-) | 01:22 |
bignose | hmm, though I guess in that case it's the site getting pwned. | 01:22 |
lifeless | its batshit insane | 01:22 |
lifeless | and es | 01:22 |
lifeless | *yes* | 01:22 |
lifeless | http://www.nabble.com/NEW-ISSUE:-content-sniffing-td22795699.html | 01:22 |
lifeless | I should raise this on the wg | 01:23 |
bignose | yes, please. that's intentional brokenness | 01:23 |
bignose | it's like Reply-To field munging, except with hideous security vulnerability | 01:23 |
lifeless | http://tools.ietf.org/html/draft-abarth-mime-sniff-00 is the spec | 01:23 |
lifeless | mwhudson: in theory if you avoid all the holes in that, it would be safe to present it as application/octet-stream. Note that I haven't read the algorithm in sufficient detail to comment. | 01:26 |
lifeless | I just followed the surface discussions | 01:26 |
mwhudson | lifeless: that would be nice | 01:26 |
bignose | eugh. ‘text/plain’ would be better | 01:26 |
lifeless | bignose: what would be? (no quotes please) | 01:27 |
bignose | content which can't display well as ‘text/plain’ should be downloaded anyway IMAO | 01:27 |
mwhudson | but the fact remains that it's going to require a lot more effort to get right than it should | 01:27 |
bignose | lifeless: fix yer UTF-8 man :-) | 01:27 |
bignose | lifeless: text/plain | 01:27 |
lifeless | bignose: I want to; its somewhere down in xlib | 01:27 |
lifeless | bignose: we don't know what the type is as bzr doesn't encode mime types in its store | 01:28 |
bignose | (specifically in the context of showing content of a file under VCS) | 01:28 |
lifeless | bignose: so text/plain would be a guess, and work badly with showing a jpg, for instance | 01:28 |
bignose | lifeless: yes, that's why I'm saying the common denominator should be text/plain | 01:28 |
lifeless | its also likely that text/plain is one of the ones browsers sniff-up to html | 01:28 |
bignose | right, and application/octet-stream would be *just as bad* for non-text content | 01:29 |
bignose | lifeless: this was in direct response to you saying if-the-sniffing-problems-are-resolved | 01:29 |
lifeless | bignose: oh; so they won't be. Browsers are out there (including FF as far as I know) | 01:30 |
lifeless | the only way to resolve it is to implement http/2.0 and have a very large blacklist hammer for any nonconformant browsers that appear | 01:30 |
* bignose deprecates stupid people. | 01:31 | |
lifeless | pragmatically thats not happening, so we have to a) convince authors not to be idiots from here on out, and b) work within the limits of whats out there | 01:31 |
lifeless | 'resist the temptation to guess' isn't something that ie or mozilla had heard, I guess. | 01:31 |
mwhudson | lifeless: i think the correct response to the issue in http://tools.ietf.org/html/draft-abarth-mime-sniff-00 involves a time machine and a very large bat | 01:38 |
eferraiuolo | I was wondering if it's built in or if you need the bzr-git plugin to run: bzr branch git:// commands? | 01:39 |
mwhudson | eferraiuolo: you need the git plugin | 01:40 |
eferraiuolo | mwhudson: cool, well I'm about to branch it then :-) | 01:41 |
Peng_ | eferraiuolo: bzr-git depends on dulwich as well. | 02:17 |
lifeless | poolie: I think a script is better than trying to get all devs to change their bug filing behaviour :) | 02:32 |
poolie | it seems to me the importance needs to come from a human | 02:33 |
poolie | i don't see how a script can generate it | 02:33 |
poolie | it could make them all default to wishlist i guess | 02:33 |
poolie | that might force people to dtrt | 02:33 |
lifeless | medium seems fine to me | 02:33 |
lifeless | anyhow, my previous comment was 'when I've thought about I do', which seems valid to me | 02:34 |
* igc lunch | 02:35 | |
poolie | BB seems to be down.. | 02:39 |
lifeless | mondayitis | 02:39 |
poolie | not a good day for servers apparaently | 02:40 |
jelmer_ | mwhudson: main improvement is that dpush to remote git repositories works now | 03:03 |
jelmer_ | mwhudson: and pull from remote git repositories only does one smart protocol command now | 03:04 |
=== mlh_ is now known as mlh | ||
mwhudson | jelmer_: so nothing very interesting from a launchpad pov | 03:20 |
jelmer_ | mwhudson: no, not really | 03:21 |
mwhudson | cool, less work for me :) | 03:21 |
mwhudson | jelmer_: i set up a samba import on staging :) | 03:23 |
jelmer_ | mwhudson: :-) | 03:27 |
jelmer_ | mwhudson: are there other git branches there yet that I can look at? | 03:27 |
mwhudson | well, some on staging | 03:27 |
jelmer_ | which ones? | 03:28 |
mwhudson | but staging has just gone *bang* | 03:28 |
mwhudson | jelmer_: etckeeper, gedit, banshee | 03:28 |
=== timchen119 is now known as nasloc__ | ||
jelmer_ | re | 03:55 |
jelmer_ | thumper: it can view history but that's it, no fetch | 03:56 |
lifeless | jelmer_: are you going to do some stuff to it? | 03:56 |
jelmer_ | lifeless: Don't have anything planned atm, would be interested in doing so | 03:57 |
thumper | jelmer: what? | 03:58 |
jelmer_ | thumper: bzr-hg | 03:58 |
thumper | jelmer: ah | 03:58 |
thumper | jelmer: how big a repo can bzr-git handle right now? | 03:59 |
jelmer_ | thumper: I've imported samba on my desktop machine | 03:59 |
thumper | jelmer_: how big is that? | 03:59 |
thumper | in the big picture of things | 04:00 |
thumper | say compared to the kernel | 04:00 |
thumper | or evolution | 04:00 |
jelmer_ | thumper: IIRC it's ~70k revisions, about ~3k files in the tree on average | 04:01 |
jelmer_ | I'm not sure what the numbers are for the kernel | 04:01 |
jelmer_ | evolution is smaller than samba, at least | 04:01 |
lifeless | less commits more files for the kernel, IIRC | 04:02 |
jelmer_ | thumper: the #1 bottleneck is the inventory handling in bzr | 04:02 |
lifeless | jelmer_: in dev6 still? | 04:03 |
wgrant | Does CHK fix that? | 04:03 |
jelmer_ | lifeless: dev6 is significantly better, but afaik the lp imports are still using 1.9 | 04:04 |
jelmer_ | lifeless: with dev6 inventory handling accounts for 20% of the CPU time during git imports | 04:04 |
lifeless | jelmer_: thats good; should be lower though | 04:04 |
jml | where is the mainline commit message policy for bzr documented? | 05:26 |
jml | I didn't realize that NEWS conflicts can never auto-resolve. | 05:33 |
igc | lifeless, poolie, jam: status update & proposed direction for branch-specific rules sent to the list now | 05:46 |
igc | jelmer_: ^^^ | 05:50 |
poolie | hi igc | 05:52 |
poolie | igc re bug 345693 being closed | 05:53 |
ubottu | Launchpad bug 345693 in bzr-usertest "should test "bzr ls -r -1"" [Undecided,Fix released] https://launchpad.net/bugs/345693 | 05:53 |
poolie | does that mean we should cross "Check performance of full inventory extraction" off the brisbane-core list? | 05:53 |
* igc looks | 06:05 | |
poolie | ok so i see that means we now have a usertest for it | 06:06 |
poolie | and iirc it didn't turn out to be too slow? | 06:06 |
igc | poolie: I think it was slower but it's not a major deal for ls | 06:06 |
poolie | ok | 06:07 |
igc | it may be for other commands though | 06:07 |
poolie | so, not too many of them should be using it | 06:07 |
poolie | i'll cross it off for now | 06:07 |
igc | poolie: ok. I'll rerun the benchmark soon as well to see where it's at | 06:07 |
igc | poolie: on another topic, abentley has appointed you as the reviewer for his compositetree patch | 06:08 |
igc | poolie: that makes you the bottleneck :-) | 06:08 |
igc | poolie: he wants you to say wwhether the design doc is now sufficient or not to proceed | 06:08 |
poolie | :) | 06:08 |
poolie | ok | 06:08 |
lifeless | popping up to the chemist, back soon | 06:10 |
=== abentley1 is now known as abentley | ||
lifeless | jelmer_: oh, I know why it was slow for you to push cross-format | 06:56 |
lifeless | jelmer_: it's john's changes to IDS | 06:56 |
lifeless | poolie: 374726 for vila | 07:01 |
lifeless | poolie: I suspect thats more than a day to have a good answer on | 07:02 |
lifeless | poolie: so I'll look for other things tomorrow | 07:02 |
=== TheMuso_ is now known as TheMuso | ||
poolie | bug 374726 | 07:16 |
vila | hi all | 07:16 |
ubottu | Launchpad bug 374726 in bzr "annotate performance on development-rich--root" [High,Triaged] https://launchpad.net/bugs/374726 | 07:16 |
poolie | hello vila | 07:16 |
vila | hmm thanks for the gift lifeless :) | 07:17 |
lifeless | vila: anytime | 07:18 |
lifeless | vila: I know you've looked at annotate recently :) | 07:19 |
vila | lifeless: yup | 07:19 |
vila | and from what I recall before paging in I can't see why it could become slower... I'll see | 07:20 |
lifeless | well, if you bench a few juicy files from bzr and emacs and its fine, then we'll know :) | 07:21 |
vila | ...and mysql :) | 07:21 |
lifeless | indeed | 07:22 |
lifeless | I built drizzle on the weekend | 07:22 |
lifeless | ... and found [and fixed some] bugs :) | 07:22 |
vila | sheesh, wrong button | 07:23 |
lifeless | haha | 07:23 |
lifeless | poolie: I've done as much wiki gardening as I think is useful for a few days | 07:24 |
lifeless | back to check for a bit then signoff | 07:24 |
* vila teach himself: heron is the background means no menu bar at the top of the screen | 07:25 | |
igc | hi vila | 07:34 |
vila | hi Ian | 07:34 |
vila | BB is down | 07:39 |
* lifeless halt()s | 08:14 | |
Peng_ | lifeless: Good night. :) | 08:14 |
poolie | vila: can you try using lp reviews for some things? | 08:19 |
poolie | you may get less outages | 08:19 |
vila | poolie: sure, old habits... but in that case it's a bzr-gtk critical bug that got affected to bzr instead | 08:20 |
poolie | oh ok | 08:22 |
poolie | i just meant in general | 08:22 |
vila | poolie: sure, my last submission(s?) to BB were followed by a 'damn it, use lp reviews ! You already pushed your branch ! You just have to use lp-open instead of bzr send !!!' :) | 08:31 |
vila | spiv: I noticed that you have added some 'if token is not None: xxx.leave_lock_in_place()' at the *end* of one (may be two so far) tests, | 08:33 |
vila | spiv: Am I right thinking that you forgot to delete them after having written more focused tests ? | 08:33 |
spiv | vila: hmm, which tests? | 08:41 |
vila | spiv: bzrlib/tests/per_repository/test_write_group.py test_abort_write_group_does_not_raise_when_suppressed | 08:42 |
vila | spiv: bzrlib/tests/test_pack_repository.py test_abort_write_group_does_not_raise_when_suppressed and test_abort_write_group_does_raise_when_not_suppressed | 08:43 |
spiv | vila: those two lines are there to suppress "object was locked when gc'd" warnings when possible | 08:45 |
vila | spiv: haaa, so if I get rid of the warning you din't mind me deleting them then ? | 08:46 |
spiv | vila: I suppose we could also achieve that by renaming foo back to repo and doing an unlock. | 08:46 |
vila | yup: self.addCleanup(t.rename, 'foo', 'repo') | 08:46 |
spiv | I don't mind you deleting them, but how are you going to get rid of the warning? | 08:46 |
spiv | Ok. | 08:46 |
=== serg_ is now known as serg | ||
* igc dinner | 09:15 | |
vila | lifeless: I know you're aware of the problem but I thought I'll share the fun anyway: Ran 1 test in 0.027s | 09:54 |
vila | FAILED (errors=2) | 09:54 |
vila | observed with an error in a cleanup hook :) | 09:55 |
lifeless | yes, its by design ugly though it is | 09:56 |
lifeless | vila: feel free to fix; though I think its low priority - its cosmetic not functional | 10:34 |
vila | lifeless: naah, just surprising, I think the fix could be a bit hard to get rigth though and not worth the effort right now (test errors should be fixed anyway) | 10:35 |
vila | and it's true that there was 2 errors... | 10:35 |
jelmer_ | mwhudson: what does lp run, dapper or hardy? | 12:01 |
jelmer_ | vila, lifeless: do you know perhaps? | 12:11 |
vila | jelmer: I'd say dapper but since I'm not sure, you'd better check with a LOSA | 12:12 |
elmo | jelmer_: hardy | 12:12 |
vila | elmo: do you when it was upgraded ? | 12:13 |
vila | yeah, know is missing of course :) | 12:13 |
elmo | vila: not offhand; over 6 months ago? I can find out exactly, if you really need to know | 12:15 |
jelmer_ | elmo: thanks | 12:15 |
vila | elmo: thanks, that's precise enough :) | 12:15 |
vila | abentley: BB is down | 13:04 |
vila | abentley: but hi first, sorry :) | 13:04 |
abentley | vila: Restarted. | 13:05 |
abentley | vila: hi :-) | 13:05 |
vila | abentley: how strange... For http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/<m2tz3x6rw6.fsf%40free.fr>, I got an ack email to bazaar@list.canonical.com, which was wrong since it's for bzr-gtk, yet, on BB, it's correctly affected to bzr-gtk... | 13:09 |
abentley | vila: Any reviewer can reassign a merge request to the correct project. | 13:10 |
vila | but as soon as I got the ack email I tried to do that, BB has been down since | 13:10 |
vila | and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2tz3x6rw6.fsf%40free.fr%3E is also valid 8-) | 13:11 |
vila | BB is too magick :) | 13:11 |
vila | jelmer: any change you can review the abvove ? | 13:45 |
jelmer_ | vila: sure, one sec | 14:10 |
cornucopic | vila, Hello | 16:18 |
vila | cornucopic: hi, how is your patch for #372800 going ? | 16:21 |
cornucopic | vila, Just resumed looking at it. To make sure, that I am in sync with you on the bug, can you please take a look the bug report? | 16:22 |
cornucopic | vila, the description: https://bugs.launchpad.net/bzr/+bug/372800 | 16:23 |
ubottu | Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress] | 16:23 |
vila | cornucopic: I,m pretty we are sync, how about you submit a patch so we can discuss on concrete code :) | 16:23 |
vila | s/pretty/pretty sure/ | 16:23 |
cornucopic | vila, Hmm..Okay :) As you suggest.. ! | 16:24 |
rbriggsatuiowa | I tried to shelve a delete and the unshelve failed miserably | 16:28 |
rbriggsatuiowa | the ticket here https://bugs.launchpad.net/bzr/+bug/319790 seems to indicate this is fixed in later versions - what version will work (ie: is this in a release or dev version?) | 16:29 |
ubottu | Ubuntu bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Fix released] | 16:29 |
vila | rbriggsatuiowa: 1.13 should include it AFAICS | 16:32 |
vila_ | rbriggsatuiowa: 1.13 should include it AFAICS (just got a crash here, don't know if you got that) | 16:35 |
rbriggsatuiowa | I'm building 1.14 right now and can't find a --prefix option for setup.py ... | 16:35 |
rbriggsatuiowa | I was running 1.10 | 16:35 |
vila_ | rbriggsatuiowa: you know you can run from source right ? | 16:36 |
=== vila_ is now known as vila | ||
rbriggsatuiowa | ahh - thanks | 16:37 |
cornucopic | vila, I can safely use a string function to extract the port number from smtp_server ? | 16:40 |
vila | cornucopic: yes, use split() | 16:41 |
SamB | you mean .split(':'), yes ? | 16:41 |
cornucopic | SamB, vila, yes | 16:42 |
* SamB meant that question for vila ;-) | 16:42 | |
rbriggsatuiowa | vila: 1.14 worked for me - thanks | 16:42 |
vila | rbriggsatuiowa: always happy to help (TM) | 16:43 |
SamB | rbriggsatuiowa: you maybe want --home ~ | 16:43 |
SamB | that's what I use | 16:43 |
rbriggsatuiowa | yeah - that's what I found once I read the FAQ (:)) | 16:43 |
SamB | It was used in some example in the Python documentation | 16:44 |
rbriggsatuiowa | I'm too used to the --prefix configure option | 16:44 |
SamB | hehe | 16:46 |
SamB | I was pleased to see that git's build system defaults to installing in $HOME | 16:47 |
rbriggsatuiowa | weird - I've always been a big fan of installing into /opt/app and fixing PATH when I do source installs | 16:48 |
rbriggsatuiowa | makes it easy to hose old versions without hurting other apps - but a pain to maintain (have to set pythonpath as well) | 16:48 |
vila | rbriggsatuiowa: old SunOS user maybe ? :-) | 16:54 |
vila | rbriggsatuiowa: what os/version are you using right now ? | 16:54 |
rbriggsatuiowa | gentoo | 17:02 |
rbriggsatuiowa | the bzr version is way out of date | 17:02 |
rbriggsatuiowa | 1.9 | 17:03 |
rbriggsatuiowa | I started using /opt when running rocks clustering stuff at work | 17:04 |
vila | rbriggsatuiowa: rocks clustering, I see :) | 17:05 |
rbriggsatuiowa | yeah - it's supposed to simplify clustering stuff - I found it a little binding | 17:05 |
rbriggsatuiowa | I haven't used it in four years though, so it might be better | 17:06 |
=== r00t_ is now known as amit | ||
amit | vila, can you please take a look at http://pastebin.com/m6a72d8ad? Is this on the correct road? | 17:12 |
=== amit is now known as Guest98791 | ||
Guest98791 | vila, amit here.. | 17:13 |
vila | Guest98791: please, send a proper submission to the list or do a merge proposal from launchpad, it's far easier and efficient to review code in context than in pastebin/IRC, thanks in advance :) | 17:14 |
Guest98791 | vila, Ok. cool. Thanks. | 17:16 |
=== Guest98791 is now known as cornucopic | ||
cornucopic | the bzr-email plugin replaces the bzr installation's 'smtp_connection.py' ? | 17:36 |
cornucopic | apparently, it uses its own copy of smtp_connection | 17:42 |
cornucopic | and not the globally installed one | 17:43 |
jelmer_ | jam: hi | 18:22 |
jelmer_ | jam: when you talk about chk stacking you mean chk stacked on chk right? | 18:22 |
jam | jelmer_: yes | 18:22 |
jam | I think I have it all working | 18:23 |
jam | I'm just doing testing | 18:23 |
jelmer_ | nice | 18:23 |
jam | and uncovering stuff like: bug #375019 | 18:23 |
ubottu | Launchpad bug 375019 in bzr "auto-stack logic selects wrong repo format" [Undecided,New] https://launchpad.net/bugs/375019 | 18:23 |
jam | hey vila... you know, we really should start chatting more often | 18:26 |
jam | I got out of the habit with multiple conferences, and getting sick, but I'd like to catch up sometime | 18:27 |
jelmer_ | jam: whoops | 18:30 |
jelmer_ | jam: what about chk stacking on 1.9 and vice versa? | 18:31 |
jelmer_ | jam: 1.9-rr on chk I mean | 18:31 |
jam | jelmer_: ATM we can't stack across serialization formats | 18:31 |
jam | so no stacking 1.9-rr <=> dev6 | 18:32 |
jam | or svn <=> bzr anything | 18:32 |
jam | etc | 18:32 |
jelmer_ | ah, ok | 18:32 |
jelmer_ | jam: svn <=> bzr has worked for quite a while :-) | 18:32 |
jam | jelmer_: how did you manage that? | 18:32 |
jelmer_ | jam: bzr-svn provides fake VersionedFiles implementations | 18:32 |
jam | Given that I get: | 18:33 |
jam | bzr: ERROR: CHKInventoryRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr/.bzr/repository/') | 18:33 |
jam | is not compatible with | 18:33 |
jam | KnitPackRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr-b-stacked/.bzr/repository/') | 18:33 |
jam | different serializers | 18:33 |
jelmer_ | that call Repository.get_revision() under the hood | 18:33 |
=== beuno_ is now known as beuno | ||
jelmer_ | and serialize again using the serialization format that 1.9-rich-root uses | 18:33 |
jam | jelmer_: so it would fail for dev6, because you are explicitly casting to 1.9-rr ? | 18:33 |
jelmer_ | jam: yeah | 18:34 |
jam | (also, you can stack 0.92 => 1.9 because the serializer didn't change) | 18:34 |
jelmer_ | jam: ok, so I guess we'll need something more generic at some point anyway | 18:39 |
vila | jam: definitely, I was hoping to call you today but... so many things to do :) | 19:01 |
jam | vila: not a big deal. I just saw your email, and realized we haven't talked in a while. Maybe tomorrow. | 19:03 |
vila | jam: sure | 19:04 |
Peng_ | Space Shuttle! :D | 19:10 |
Tak | couldn't see very well from here | 19:17 |
Peng_ | I couldn't see it at all. It was cloudy, and the trajectory may have interfered. | 19:21 |
beuno | jam, w0000000t! | 20:09 |
* beuno dances | 20:09 | |
LarstiQ | beuno: you received some lettuce in the mail? :) | 20:10 |
beuno | jam, EVEN BETTER! | 20:10 |
beuno | a patch for stacking on brisbane-core | 20:10 |
Kissaki | yo, can you with bzr commit -m "" how can I add newlines? | 20:11 |
Kissaki | aka line breaks | 20:12 |
beuno | Kissaki, I think you need to drop the -m, and jump into an editor | 20:12 |
LarstiQ | it can be done with -m | 20:13 |
Kissaki | hm, ok | 20:13 |
Kissaki | thx | 20:13 |
Kissaki | can=can't ? ^^ | 20:13 |
LarstiQ | Kissaki: what I do is bzr ci -m 'Added foo.<hit enter>Added bar.' | 20:13 |
LarstiQ | Kissaki: ie, let my shell handle the newlines | 20:13 |
LarstiQ | Kissaki: can | 20:14 |
Kissaki | tried \n, but that didn't work :/ | 20:14 |
LarstiQ | Kissaki: have you tried an actual literal enter? | 20:14 |
Kissaki | hm? | 20:14 |
LarstiQ | Kissaki: use the enter key. | 20:14 |
Kissaki | pressing it will exec the cmd ofc | 20:15 |
Peng_ | Kissaki: Depending on your shell, if you're inside quote marks, it won't. | 20:15 |
Kissaki | using windows cmd right now | 20:15 |
LarstiQ | ah. windows cmd | 20:15 |
LarstiQ | Kissaki: I don't know if the windows shell has support for multiline editing | 20:16 |
LarstiQ | Kissaki: I'd leave off -m and spawn a commit editor then. | 20:17 |
Kissaki | well, I'll try copy paste for comment next time | 20:17 |
Kissaki | commit editor? is that something special? | 20:17 |
LarstiQ | I doubt tricks like bzr ci -m `cat` will work on windows? | 20:17 |
Kissaki | yeah | 20:17 |
LarstiQ | Kissaki: it looks at $VISUAL or $EDITOR, and will spawn notepad on windows if it can't find anything else | 20:18 |
LarstiQ | Kissaki: also, you configure what editor to use for commit messages, see `bzr help configuration` | 20:18 |
sidnei | is there an argument for reading the commit message from a file? in svn you can do svn ci -F <filename> or something | 20:18 |
LarstiQ | which might come in handy on windows | 20:18 |
LarstiQ | sidnei: oooh, good one! | 20:18 |
LarstiQ | that was even my first patch for bzr, shame I don't remember :/ | 20:18 |
LarstiQ | Kissaki: as sidnei said, you can use -F | 20:18 |
luks | Kissaki: have you tried bzr qci | 20:19 |
Kissaki | no | 20:19 |
luks | it might not be what you want, but just in case | 20:19 |
sidnei | qci is cool too | 20:19 |
Kissaki | don't even know what ci is | 20:19 |
luks | commit | 20:19 |
Kissaki | ah | 20:19 |
luks | (and qcommit) | 20:19 |
Kissaki | what's the difference? | 20:20 |
luks | it opens a dialog window | 20:20 |
GaryvdM | nothing - qcli is an alias | 20:20 |
luks | where you can type the commit messages, select files, see diffs, etc. | 20:20 |
GaryvdM | qcli is an alias for qcommit | 20:20 |
luks | *message | 20:20 |
LarstiQ | GaryvdM: qcli or qci? | 20:20 |
GaryvdM | err qci | 20:21 |
Kissaki | oh, nice | 20:22 |
Peng_ | jam: You left a "bork" in bzrlib/repofmt/groupcompress_repo.py in the dev6 stacking patch. :P | 20:22 |
Kissaki | qcommit indeed does open a commit window/dialog/editor thingy | 20:22 |
Kissaki | thx | 20:22 |
jam | Peng nice catch :) | 20:35 |
jam | though that would hint that the code isn't exercised (as I thought it wasn't) | 20:35 |
Peng_ | :D | 20:37 |
LeoNerd | Uhh... Where'd 'bzr revert' move my file to? | 20:38 |
LeoNerd | It always used to keep a backup | 20:38 |
beuno | LeoNerd, ~filename~ | 20:39 |
LeoNerd | I don't see one | 20:40 |
beuno | LeoNerd, ls -la? | 20:40 |
LeoNerd | In the directory it used to live, or in the treeroot? | 20:40 |
LeoNerd | Well. it's absent either way | 20:40 |
LarstiQ | LeoNerd: it doesn't leave backups if it can be constructed otherwise, afaik. | 20:40 |
LeoNerd | Hrm... | 20:41 |
LeoNerd | it was locally modified | 20:41 |
=== awilcox_ is now known as awilcox | ||
eka | hi all | 22:04 |
eka | is there any way to work using bzr with a git repo? | 22:05 |
mwhudson | eka: yes, 'bzr-git' | 22:05 |
eka | mwhudson: it's stable? | 22:07 |
mwhudson | eka: it's moving quite quickly, but mostly in a positive direction :) | 22:08 |
mwhudson | eka: it works pretty well, in my testing | 22:08 |
eka | mwhudson: thanks for the tip | 22:09 |
mwhudson | (launchpad will be using it to import git repositories into bzr soon) | 22:09 |
jam | lifeless: ping | 22:10 |
jelmer | mwhudson: so, bzr-git now supports using tdb to store its cache data | 22:24 |
jelmer | mwhudson: which is significantly faster than sqlite | 22:24 |
adamfast | I've got a question - a while back I upgraded via the installer to 1.13.2 (and then today to 1.14.1) but I keep getting a "bzr: WARNING: bzrlib version doesn't match the bzr program." the bzrlib version is 1, 14, 1, 'final' and bzr --version tells me it's 1.14.1. Has anyone seen this before? | 22:28 |
adamfast | (I should mention I'm using a Mac with the Leopard Python 2.5) | 22:28 |
thumper | adamfast: my guess is that the bzr executable isn't the one you installed | 22:29 |
adamfast | any idea what the/a possible fix could be? Try to delete all the files and run the installer again? | 22:30 |
mwhudson | jelmer: tdb? | 22:30 |
mwhudson | jelmer: is it packaged for hardy? | 22:31 |
jelmer | mwhudson: yep | 22:31 |
thumper | jelmer: is it chosen automagically? | 22:31 |
mwhudson | jelmer: hmm, where is the cache stored between runs? | 22:31 |
jelmer | thumper: yep, we also still support sqlite | 22:31 |
jelmer | thumper: and if tdb is not there sqlite is used like it was before, it'll just be slower | 22:32 |
jelmer | thumper: (slower than tdb, not slower than it is with sqlite now obviously) | 22:32 |
jelmer | mwhudson: it's in .bzr/repository/git.[t]db | 22:32 |
mwhudson | jelmer: does push preserve it? | 22:33 |
Peng_ | Can you upgrade a repo from sqlite to tdb? | 22:33 |
jelmer | mwhudson: no, but if it's not there bzr-git will regenerate it | 22:33 |
mwhudson | jelmer: how bad is that, relatively speaking? | 22:34 |
mwhudson | (because it seems with the system we have in place we'll regenerate it each time) | 22:34 |
jelmer | mwhudson: one sec, I'll try on a bzr.dev repo | 22:34 |
thumper | lifeless: you up yet? | 22:35 |
jelmer | mwhudson: I guess it would be nice if push could preserve it I guess but we'd need better hooks for that | 22:37 |
jelmer | mwhudson: also, if you don't keep this database around you'll hit problems when there are revisions that contain characters that can't be represented in XML | 22:37 |
mwhudson | jelmer: well, it would be easy enough to preserve it by hand, esp if bzr-git can tell me where it should go for a branch | 22:38 |
thumper | jelmer, mwhudson: well that is a handy thing to know | 22:38 |
mwhudson | thumper: indeed | 22:38 |
Peng_ | Why's lp:dulwich a remote branch? | 22:40 |
jelmer | mwhudson: regenerating the sha map takes 16 seconds for 1000 revisions (bzr-git) | 22:40 |
jelmer | mwhudson: try 'bzr git-object' in any bzr branch to generate a full map | 22:41 |
mwhudson | jelmer: will it need to do that for a pull where the remote tip hasn't changed? | 22:41 |
jelmer | mwhudson: I'm not entirely sure | 22:42 |
jelmer | mwhudson: it shouldn't need to, but I don't know what it does atm | 22:42 |
jelmer | mwhudson: only one way to find out :-) | 22:42 |
mwhudson | jelmer: :) | 22:43 |
lifeless | thumper: yes | 22:43 |
lifeless | thumper: but I'm doing bio stuff | 22:43 |
thumper | lifeless: I've just done mine :) | 22:44 |
thumper | lifeless: why does pack take so long with bbc? | 22:48 |
thumper | packing launchpad with packs took under 3m | 22:48 |
thumper | packing launchpad in bbc took over 3 hours | 22:48 |
thumper | although packing packs went from 1.1G to 1.1G (not much change :) | 22:49 |
thumper | packing bbc went from 248M to 137M | 22:49 |
thumper | for the pack dir at least | 22:50 |
lifeless | for xml based formats all pack does is reduce latency | 22:50 |
lifeless | for the chk formats, we recompress | 22:50 |
thumper | lifeless: is this going to happen automatically when combining packs? | 22:50 |
thumper | lifeless: because if it does, it will make for very slow pushes :) | 22:50 |
lifeless | thumper: 'bzr pack' recombines all history. of course its slow | 22:51 |
mwhudson | jelmer: it seems maybe not | 22:51 |
thumper | lifeless: but what about the autopack? | 22:51 |
lifeless | autopack doesn't do a full pack | 22:51 |
thumper | so it will still be fast? | 22:52 |
lifeless | yes | 22:52 |
lifeless | kindof an obvious question :) | 22:52 |
thumper | cool | 22:52 |
jelmer | lifeless: is it right that running 'bzr pack' in a dev6 repo multiple times gives "Pack already exists ..." after the first time ? | 22:52 |
thumper | just making sure :) | 22:53 |
lifeless | jelmer: file a bug please | 22:53 |
lifeless | jelmer: its because we don't short-circuit pack and avoid doing it in dev6 | 22:53 |
jelmer | lifeless: I guess that's a "no" | 22:53 |
lifeless | jelmer: its not the desired behaviour :) | 22:54 |
lifeless | thumper: autopack has a exponential backoff on frequency for a given text | 22:55 |
=== phinze_ is now known as phinze | ||
lifeless | thumper: 10 autopacks of 10 revs in the first 99 commits, then one of 100 revs, and so on | 22:55 |
lifeless | if you've got 100K commits, it will be a very long time before autopack decides to rewrite the 100K pack when you push a single revision | 22:56 |
thumper | lifeless: just saying "yes it'll be fast" is good enough for me | 22:56 |
lifeless | thumper: sure, but you may as well understand it too ;) | 22:57 |
beuno | lifeless, https://pastebin.canonical.com/17459/ bug? | 22:57 |
thumper | lifeless: however your explination doesn't help me understand because I'm missing too much context :) | 22:57 |
lifeless | thumper: ok. In short - autopack may do a full pack, but its very rare, and becomes more rare thelarger the repo | 22:58 |
lifeless | thumper: theres a heuristic, which seems to work well. | 22:58 |
lifeless | beuno: bug | 22:59 |
beuno | lifeless, danke. What does --default-rich-root default to in bzr.dev? 0.92 still? | 22:59 |
lifeless | I'm not sure. that was on branch anyhow | 23:00 |
jelmer | beuno: rich-root-pack | 23:00 |
beuno | ah, lh is 1.9 | 23:00 |
beuno | so I guess it's trying to do 1.9 -> rich-root-pack | 23:01 |
beuno | so failing | 23:01 |
lifeless | beuno: its the branch object thats failing | 23:01 |
lifeless | nothing to do with roots | 23:01 |
beuno | oh | 23:01 |
beuno | k, bug files | 23:03 |
beuno | and filed | 23:03 |
jelmer | heh, dpush from svn into git works (-: | 23:04 |
jelmer | secretly bzr is just tailor Done Right [tm] ;-) | 23:05 |
lifeless | jelmer: lol; scary, and 'No' | 23:06 |
beuno | nice. Loggerhead in bbc is ~40% smaller, and "bzr log -v" takes less than half the time | 23:11 |
beuno | (compared to 1.9) | 23:12 |
luks | beuno: out of curiosity, how long is that? :) | 23:14 |
luks | I'd expect that to still be unusable | 23:14 |
beuno | luks, 3.7sec to 1.6sec | 23:15 |
lifeless | beuno: be sure to bzr check ;; bzr reconcile before migrating | 23:15 |
beuno | pretty usable | 23:15 |
luks | what? log -v does still all the deltas? | 23:15 |
lifeless | beuno: I encourage you to migrate to rich roots soon; see the thread on bzrtools which has migrated to rich roots already | 23:15 |
beuno | lifeless, I will, although I'm just fooling around now, to try and hash out any obvious problems | 23:15 |
beuno | lifeless, I'm more than happy to, if we can get mwhudson and Peng_ on board | 23:16 |
jam | lifeless: I have to go now, but if I get some time, I'd like to chat after a few hours | 23:16 |
lifeless | beuno: thats part of the process; read my mails ;) | 23:16 |
lifeless | jam: sure | 23:16 |
lifeless | jam: ping me | 23:16 |
lifeless | jam: I'm going to be poking at check, then presentations | 23:16 |
mwhudson | beuno: sure, no problems at all with going to rich root | 23:17 |
beuno | lifeless, both check and reconcile? | 23:17 |
lifeless | beuno: yes, or just reconcile | 23:17 |
beuno | mwhudson, what happens with the existing stacked branches? | 23:17 |
Peng_ | beuno: My position on rich-roots hasn't changed. I'm on board, pending that email from a few weeks ago about changing how converting worked. | 23:17 |
beuno | they all break? | 23:17 |
lifeless | beuno: with a check afterwards | 23:17 |
mwhudson | beuno: well that's the fun part :) | 23:17 |
Peng_ | Or whatever it was about. | 23:17 |
mwhudson | beuno: i'm sure lifeless talks about that too in his mails | 23:17 |
lifeless | beuno: 1) read my mails about this; 2) reply with anything unclear so we can capture it and improve - please | 23:18 |
beuno | Peng_, mwhudson, ok, I may attempt to upgrade trunk later today then | 23:18 |
beuno | check and reconcile looked ok on lh bbc | 23:18 |
lifeless | beuno: read the mail first; doing it today would pretty much break all the rules | 23:19 |
beuno | even when going from plain 1.9 -> bbc | 23:19 |
beuno | ok, *today* I may read lifeless's email more carefully | 23:19 |
beuno | and see where that takes me | 23:19 |
lifeless | Peng_: noone has altering the conversion process in their queue that I know of | 23:19 |
beuno | lifeless, any hint on how to find that email? | 23:22 |
lifeless | Subject: [DRAFT][RFC] Migrating to rich roots | 23:23 |
beuno | loggerhead is very spify on bbc: http://bazaar.launchpad.net/~beuno/%2Bjunk/loggerhead-bbc/changes | 23:23 |
lifeless | spify? | 23:23 |
lifeless | do you mean fast or pretty? | 23:24 |
beuno | fast | 23:24 |
lifeless | 3 seconds to toggle a > | 23:24 |
lifeless | :< | 23:24 |
beuno | not sure what that means | 23:25 |
lifeless | in the changes pge | 23:25 |
lifeless | there are > beside each rev | 23:25 |
lifeless | if I click one, its about 3 seconds, sometimes up to 5, before the expanded content is complete | 23:25 |
beuno | I clicked on expand all | 23:25 |
beuno | and it took ~2-3 seconds to bring all of them in | 23:26 |
Peng_ | lifeless: I dunno. There was some email about somehting or other. I still don't know what it was about. :P | 23:27 |
lifeless | beuno: 10 seconds to do that for me | 23:28 |
lifeless | beuno: where are you at the moment | 23:28 |
lifeless | Peng_: I do | 23:28 |
beuno | lifeless, argentina | 23:28 |
lifeless | strange :-) | 23:28 |
beuno | lifeless, so upgrading to rich-roots breaks stacked branches. Can they be upgraded as well, or are they just discarded? | 23:28 |
Peng_ | Whoever did it first had to wait for the cache to be generated. | 23:28 |
lifeless | Peng_: I did it second | 23:28 |
lifeless | beuno: clean your eyes | 23:29 |
lifeless | 3) Users migrate their own branches before this time, including lp | 23:29 |
lifeless | hosted branches and particularly stacked branches. | 23:29 |
beuno | lifeless, I don't follow | 23:29 |
lifeless | Peng_: its possible its slower now its cached | 23:29 |
beuno | current branches stacked can be upgraded to rich-root, even though the stacked-on branch isn't rich-root? | 23:30 |
Peng_ | Stupid question that I can figure out on my own: is it possible to push to a lightweight checkout on a remote server, where the branch is stored on the same server? | 23:30 |
Peng_ | s/can/should/ | 23:30 |
lifeless | beuno: yes, they will break after the upgrade; then when the stacked on is a matching format again, they will work again | 23:30 |
beuno | lifeless, gotcha | 23:30 |
lifeless | Peng_: it should be yes, unless the the server is chrooted so as to divide them | 23:31 |
lifeless | Peng_: but it may not work dependign on the path in iuse in the checkout | 23:31 |
Peng_ | lifeless: In this case, no chroot, but they're totally different paths. | 23:31 |
Peng_ | Maybe I should use a stacked branch instead. | 23:32 |
lifeless | Peng_: there's always a chroot | 23:32 |
lifeless | Peng_: ChrootTransportDecorator | 23:32 |
Peng_ | Eh. | 23:32 |
beuno | it pretty much sucks that all branches tied to merge proposals will break, unless we hunt down each and upgrade (which takes ages remotely) | 23:32 |
lifeless | Peng_: and the jail | 23:32 |
awilcox | okay it has been a few days so I think I will reask my question. Is there any way to utilise Bazaar in XCode? | 23:32 |
Peng_ | Yeah, I love the jail. | 23:32 |
lifeless | Peng_: the jail works with the chroot decorator | 23:32 |
lifeless | awilcox: no idea sorry; have you checked the IDE page? | 23:33 |
awilcox | lifeless: I have and it said that CVS, SVN, and Perforce are supported natively, but others can use a plug-in interface | 23:33 |
lifeless | awilcox: I mean our one | 23:33 |
lifeless | on bazaar-vcs.org | 23:33 |
awilcox | I googled, and some people mentioned projects for a plug-in, but I haven't found the actual code. | 23:33 |
Peng_ | The situation is, I have branches of one project in 3 different locations, with a checkout in 1 of them, and want to get rid of one of the duplicate repositories. (The other can stay, I guess. Although I could convert it to a stacked branch too, hmm.) | 23:33 |
awilcox | ohhhh sorry. | 23:33 |
awilcox | http://bazaar-vcs.org/IDEIntegration doesn't even have XCode listed. | 23:39 |
lifeless | :( | 23:39 |
lifeless | care to add it? | 23:39 |
awilcox | I don't see a way to edit the page | 23:42 |
lifeless | bottom of the page is an edit link | 23:43 |
lifeless | if you're logged in | 23:43 |
awilcox | ah. I don't have an account. | 23:43 |
lifeless | if you don't have an account you can just create one, or I can add xcode to it for you (but I don't know anything about xcode which is why I asked you to add it :)) | 23:43 |
* beuno -> off for a while | 23:45 | |
Raim | hi | 23:56 |
Peng_ | Hello | 23:56 |
Raim | I am trying to branch using bzr 1.9 as client from a server with bzr 1.5 using the bzr+ssh:// protocol | 23:57 |
Raim | are these versions known to be incompatible? | 23:58 |
mwhudson | Raim: no | 23:58 |
Raim | so I am seeing these messages and it fails: http://pbot.rmdir.de/0347a921ae170e1ba6dfb075de29c6d0 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!