[00:09] morning all [00:09] moening lifless, mwhudson [00:10] let's try that again ... [00:10] hi igc [00:10] morning lifeless, mwhudson [00:10] :) [00:21] lifeless: why doesn't aws-status read my access key from the same file as ec2test? [00:22] i.e. ~/.ec2/aws_id [00:23] it uses the same variables as bzr ec2test [00:23] and if it doesn't find it it will look in gnome-keyring too [00:24] 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] lifeless: ok. [00:24] lifeless: the real answer might be "Why does Launchpad's ec2test use a non-standard file" [00:24] * jml makes a note [00:26] of course, if the amazon toolchain does read a file, a bug on txaws is definitely in order [00:27] lifeless: yeah. I'll chase it up later. [00:28] thanks [00:36] lifeless: Robert, you're signing emails with a key that's not on the public keyservers. You might want to upload it somewhere. === AfC1 is now known as AfC [00:37] AfC: odd, I have. it just hasn't propogated >< [00:37] lifeless: It's not on subkeys.pgp.net or pgp.mit.edu [00:38] lifeless: I would have thought you would have uploaded to them directly, seeing as how they're the main ones [00:40] * igc working on branch-specific rules today [00:41] igc: you were going to mail about the issue; have I missed that ? [00:41] lifeless: nope - sending it today [00:54] good morning === _thumper_ is now known as thumper [00:57] how worried should I be about 2485 revisions missing parents in ancestry and 3547 inconsistent parents? [00:57] thumper: it will be affecting the output of annotate [00:58] the 2485 are the unimported arch revisions [00:58] 2645 ghost revisions [00:58] oh hmm [00:58] morning poolie [00:58] then its filled in ghosts [00:58] 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] you should reconcile anyhow [00:58] helol igc [00:58] bob2: confusing [00:58] will comment on your docs soon [00:59] bob2: as it already has a saved bound location [00:59] lifeless: what will reconcile do? [00:59] bob2: if it guaranteed to rebind just where it was last bound [00:59] what he said [00:59] it will rewrite the parents [00:59] to what? [00:59] to the correct value based on the data available in the repository [01:00] lifeless: hm, I meant, only if it didn't have a previously saved one [01:00] bob2: still confusing, no [01:00] ok [01:00] bob2: as in [01:00] bind (grabs parent) [01:00] pull x (sets parent in master and local) [01:00] unbind [01:00] bind [01:00] (does not grab parent) [01:14] with Loggerhead, browsing a file gives me the “annotate” view [01:14] what's the status of bzr-hg? [01:14] how can I just view the content of the file from head, without annotation? [01:15] i.e. the URL formed has …/trunk/annotate/head%3A/README [01:15] what URL should I use instead to just display the raw content of that revision of the file? [01:16] mwhudson: ^ [01:16] bignose: there is no view to display the raw content [01:16] :-( [01:17] bignose: because we're worried about xss attacks [01:17] bignose: there is a branch which adds it somewhere, but we need a way to turn it off [01:18] bignose: https://code.edge.launchpad.net/~intellectronica/loggerhead/view-file is one [01:19] mwhudson: thanks for the response. [01:19] mwhudson: 'if hacked(): disable_it_now()' ? [01:19] bignose: np [01:19] lifeless: yeah [01:20] it would be nice to be able to get at plain text versions [01:20] its a pity that browser authors are insane [01:20] mwhudson: actually on second thought: what XSS vulnerability? [01:20] [content sniffing] [01:20] bignose: I could upload arbitrary html to my branch [01:20] shouldn't it be just a matter of serving the file as ‘Content-Type: text/plain’? [01:21] ha, ha, yes, it should [01:21] bignose: many browsers sniff content and ignore content-type [01:21] bignose: and there is now a 'standard' under discussion for controlling when the do this. Its insane [01:21] haha [01:21] is it enabled via a meta tag? [01:22] lifeless: those broswers deserve to get pwned then :-) [01:22] hmm, though I guess in that case it's the site getting pwned. [01:22] its batshit insane [01:22] and es [01:22] *yes* [01:22] http://www.nabble.com/NEW-ISSUE:-content-sniffing-td22795699.html [01:23] I should raise this on the wg [01:23] yes, please. that's intentional brokenness [01:23] it's like Reply-To field munging, except with hideous security vulnerability [01:23] http://tools.ietf.org/html/draft-abarth-mime-sniff-00 is the spec [01:26] 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] I just followed the surface discussions [01:26] lifeless: that would be nice [01:26] eugh. ‘text/plain’ would be better [01:27] bignose: what would be? (no quotes please) [01:27] content which can't display well as ‘text/plain’ should be downloaded anyway IMAO [01:27] but the fact remains that it's going to require a lot more effort to get right than it should [01:27] lifeless: fix yer UTF-8 man :-) [01:27] lifeless: text/plain [01:27] bignose: I want to; its somewhere down in xlib [01:28] bignose: we don't know what the type is as bzr doesn't encode mime types in its store [01:28] (specifically in the context of showing content of a file under VCS) [01:28] bignose: so text/plain would be a guess, and work badly with showing a jpg, for instance [01:28] lifeless: yes, that's why I'm saying the common denominator should be text/plain [01:28] its also likely that text/plain is one of the ones browsers sniff-up to html [01:29] right, and application/octet-stream would be *just as bad* for non-text content [01:29] lifeless: this was in direct response to you saying if-the-sniffing-problems-are-resolved [01:30] bignose: oh; so they won't be. Browsers are out there (including FF as far as I know) [01:30] 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:31] * bignose deprecates stupid people. [01:31] 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] 'resist the temptation to guess' isn't something that ie or mozilla had heard, I guess. [01:38] 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:39] I was wondering if it's built in or if you need the bzr-git plugin to run: bzr branch git:// commands? [01:40] eferraiuolo: you need the git plugin [01:41] mwhudson: cool, well I'm about to branch it then :-) [02:17] eferraiuolo: bzr-git depends on dulwich as well. [02:32] poolie: I think a script is better than trying to get all devs to change their bug filing behaviour :) [02:33] it seems to me the importance needs to come from a human [02:33] i don't see how a script can generate it [02:33] it could make them all default to wishlist i guess [02:33] that might force people to dtrt [02:33] medium seems fine to me [02:34] anyhow, my previous comment was 'when I've thought about I do', which seems valid to me [02:35] * igc lunch [02:39] BB seems to be down.. [02:39] mondayitis [02:40] not a good day for servers apparaently [03:03] mwhudson: main improvement is that dpush to remote git repositories works now [03:04] mwhudson: and pull from remote git repositories only does one smart protocol command now === mlh_ is now known as mlh [03:20] jelmer_: so nothing very interesting from a launchpad pov [03:21] mwhudson: no, not really [03:21] cool, less work for me :) [03:23] jelmer_: i set up a samba import on staging :) [03:27] mwhudson: :-) [03:27] mwhudson: are there other git branches there yet that I can look at? [03:27] well, some on staging [03:28] which ones? [03:28] but staging has just gone *bang* [03:28] jelmer_: etckeeper, gedit, banshee === timchen119 is now known as nasloc__ [03:55] re [03:56] thumper: it can view history but that's it, no fetch [03:56] jelmer_: are you going to do some stuff to it? [03:57] lifeless: Don't have anything planned atm, would be interested in doing so [03:58] jelmer: what? [03:58] thumper: bzr-hg [03:58] jelmer: ah [03:59] jelmer: how big a repo can bzr-git handle right now? [03:59] thumper: I've imported samba on my desktop machine [03:59] jelmer_: how big is that? [04:00] in the big picture of things [04:00] say compared to the kernel [04:00] or evolution [04:01] thumper: IIRC it's ~70k revisions, about ~3k files in the tree on average [04:01] I'm not sure what the numbers are for the kernel [04:01] evolution is smaller than samba, at least [04:02] less commits more files for the kernel, IIRC [04:02] thumper: the #1 bottleneck is the inventory handling in bzr [04:03] jelmer_: in dev6 still? [04:03] Does CHK fix that? [04:04] lifeless: dev6 is significantly better, but afaik the lp imports are still using 1.9 [04:04] lifeless: with dev6 inventory handling accounts for 20% of the CPU time during git imports [04:04] jelmer_: thats good; should be lower though [05:26] where is the mainline commit message policy for bzr documented? [05:33] I didn't realize that NEWS conflicts can never auto-resolve. [05:46] lifeless, poolie, jam: status update & proposed direction for branch-specific rules sent to the list now [05:50] jelmer_: ^^^ [05:52] hi igc [05:53] igc re bug 345693 being closed [05:53] Launchpad bug 345693 in bzr-usertest "should test "bzr ls -r -1"" [Undecided,Fix released] https://launchpad.net/bugs/345693 [05:53] does that mean we should cross "Check performance of full inventory extraction" off the brisbane-core list? [06:05] * igc looks [06:06] ok so i see that means we now have a usertest for it [06:06] and iirc it didn't turn out to be too slow? [06:06] poolie: I think it was slower but it's not a major deal for ls [06:07] ok [06:07] it may be for other commands though [06:07] so, not too many of them should be using it [06:07] i'll cross it off for now [06:07] poolie: ok. I'll rerun the benchmark soon as well to see where it's at [06:08] poolie: on another topic, abentley has appointed you as the reviewer for his compositetree patch [06:08] poolie: that makes you the bottleneck :-) [06:08] poolie: he wants you to say wwhether the design doc is now sufficient or not to proceed [06:08] :) [06:08] ok [06:10] popping up to the chemist, back soon === abentley1 is now known as abentley [06:56] jelmer_: oh, I know why it was slow for you to push cross-format [06:56] jelmer_: it's john's changes to IDS [07:01] poolie: 374726 for vila [07:02] poolie: I suspect thats more than a day to have a good answer on [07:02] poolie: so I'll look for other things tomorrow === TheMuso_ is now known as TheMuso [07:16] bug 374726 [07:16] hi all [07:16] Launchpad bug 374726 in bzr "annotate performance on development-rich--root" [High,Triaged] https://launchpad.net/bugs/374726 [07:16] hello vila [07:17] hmm thanks for the gift lifeless :) [07:18] vila: anytime [07:19] vila: I know you've looked at annotate recently :) [07:19] lifeless: yup [07:20] and from what I recall before paging in I can't see why it could become slower... I'll see [07:21] well, if you bench a few juicy files from bzr and emacs and its fine, then we'll know :) [07:21] ...and mysql :) [07:22] indeed [07:22] I built drizzle on the weekend [07:22] ... and found [and fixed some] bugs :) [07:23] sheesh, wrong button [07:23] haha [07:24] poolie: I've done as much wiki gardening as I think is useful for a few days [07:24] back to check for a bit then signoff [07:25] * vila teach himself: heron is the background means no menu bar at the top of the screen [07:34] hi vila [07:34] hi Ian [07:39] BB is down [08:14] * lifeless halt()s [08:14] lifeless: Good night. :) [08:19] vila: can you try using lp reviews for some things? [08:19] you may get less outages [08:20] poolie: sure, old habits... but in that case it's a bzr-gtk critical bug that got affected to bzr instead [08:22] oh ok [08:22] i just meant in general [08:31] 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:33] 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] spiv: Am I right thinking that you forgot to delete them after having written more focused tests ? [08:41] vila: hmm, which tests? [08:42] spiv: bzrlib/tests/per_repository/test_write_group.py test_abort_write_group_does_not_raise_when_suppressed [08:43] 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:45] vila: those two lines are there to suppress "object was locked when gc'd" warnings when possible [08:46] spiv: haaa, so if I get rid of the warning you din't mind me deleting them then ? [08:46] vila: I suppose we could also achieve that by renaming foo back to repo and doing an unlock. [08:46] yup: self.addCleanup(t.rename, 'foo', 'repo') [08:46] I don't mind you deleting them, but how are you going to get rid of the warning? [08:46] Ok. === serg_ is now known as serg [09:15] * igc dinner [09:54] 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] FAILED (errors=2) [09:55] observed with an error in a cleanup hook :) [09:56] yes, its by design ugly though it is [10:34] vila: feel free to fix; though I think its low priority - its cosmetic not functional [10:35] 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] and it's true that there was 2 errors... [12:01] mwhudson: what does lp run, dapper or hardy? [12:11] vila, lifeless: do you know perhaps? [12:12] jelmer: I'd say dapper but since I'm not sure, you'd better check with a LOSA [12:12] jelmer_: hardy [12:13] elmo: do you when it was upgraded ? [12:13] yeah, know is missing of course :) [12:15] vila: not offhand; over 6 months ago? I can find out exactly, if you really need to know [12:15] elmo: thanks [12:15] elmo: thanks, that's precise enough :) [13:04] abentley: BB is down [13:04] abentley: but hi first, sorry :) [13:05] vila: Restarted. [13:05] vila: hi :-) [13:09] abentley: how strange... For http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/, 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:10] vila: Any reviewer can reassign a merge request to the correct project. [13:10] but as soon as I got the ack email I tried to do that, BB has been down since [13:11] and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2tz3x6rw6.fsf%40free.fr%3E is also valid 8-) [13:11] BB is too magick :) [13:45] jelmer: any change you can review the abvove ? [14:10] vila: sure, one sec [16:18] vila, Hello [16:21] cornucopic: hi, how is your patch for #372800 going ? [16:22] 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:23] vila, the description: https://bugs.launchpad.net/bzr/+bug/372800 [16:23] Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress] [16:23] cornucopic: I,m pretty we are sync, how about you submit a patch so we can discuss on concrete code :) [16:23] s/pretty/pretty sure/ [16:24] vila, Hmm..Okay :) As you suggest.. ! [16:28] I tried to shelve a delete and the unshelve failed miserably [16:29] 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] Ubuntu bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Fix released] [16:32] rbriggsatuiowa: 1.13 should include it AFAICS [16:35] rbriggsatuiowa: 1.13 should include it AFAICS (just got a crash here, don't know if you got that) [16:35] I'm building 1.14 right now and can't find a --prefix option for setup.py ... [16:35] I was running 1.10 [16:36] rbriggsatuiowa: you know you can run from source right ? === vila_ is now known as vila [16:37] ahh - thanks [16:40] vila, I can safely use a string function to extract the port number from smtp_server ? [16:41] cornucopic: yes, use split() [16:41] you mean .split(':'), yes ? [16:42] SamB, vila, yes [16:42] * SamB meant that question for vila ;-) [16:42] vila: 1.14 worked for me - thanks [16:43] rbriggsatuiowa: always happy to help (TM) [16:43] rbriggsatuiowa: you maybe want --home ~ [16:43] that's what I use [16:43] yeah - that's what I found once I read the FAQ (:)) [16:44] It was used in some example in the Python documentation [16:44] I'm too used to the --prefix configure option [16:46] hehe [16:47] I was pleased to see that git's build system defaults to installing in $HOME [16:48] weird - I've always been a big fan of installing into /opt/app and fixing PATH when I do source installs [16:48] makes it easy to hose old versions without hurting other apps - but a pain to maintain (have to set pythonpath as well) [16:54] rbriggsatuiowa: old SunOS user maybe ? :-) [16:54] rbriggsatuiowa: what os/version are you using right now ? [17:02] gentoo [17:02] the bzr version is way out of date [17:03] 1.9 [17:04] I started using /opt when running rocks clustering stuff at work [17:05] rbriggsatuiowa: rocks clustering, I see :) [17:05] yeah - it's supposed to simplify clustering stuff - I found it a little binding [17:06] I haven't used it in four years though, so it might be better === r00t_ is now known as amit [17:12] vila, can you please take a look at http://pastebin.com/m6a72d8ad? Is this on the correct road? === amit is now known as Guest98791 [17:13] vila, amit here.. [17:14] 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:16] vila, Ok. cool. Thanks. === Guest98791 is now known as cornucopic [17:36] the bzr-email plugin replaces the bzr installation's 'smtp_connection.py' ? [17:42] apparently, it uses its own copy of smtp_connection [17:43] and not the globally installed one [18:22] jam: hi [18:22] jam: when you talk about chk stacking you mean chk stacked on chk right? [18:22] jelmer_: yes [18:23] I think I have it all working [18:23] I'm just doing testing [18:23] nice [18:23] and uncovering stuff like: bug #375019 [18:23] Launchpad bug 375019 in bzr "auto-stack logic selects wrong repo format" [Undecided,New] https://launchpad.net/bugs/375019 [18:26] hey vila... you know, we really should start chatting more often [18:27] I got out of the habit with multiple conferences, and getting sick, but I'd like to catch up sometime [18:30] jam: whoops [18:31] jam: what about chk stacking on 1.9 and vice versa? [18:31] jam: 1.9-rr on chk I mean [18:31] jelmer_: ATM we can't stack across serialization formats [18:32] so no stacking 1.9-rr <=> dev6 [18:32] or svn <=> bzr anything [18:32] etc [18:32] ah, ok [18:32] jam: svn <=> bzr has worked for quite a while :-) [18:32] jelmer_: how did you manage that? [18:32] jam: bzr-svn provides fake VersionedFiles implementations [18:33] Given that I get: [18:33] bzr: ERROR: CHKInventoryRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr/.bzr/repository/') [18:33] is not compatible with [18:33] KnitPackRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr-b-stacked/.bzr/repository/') [18:33] different serializers [18:33] that call Repository.get_revision() under the hood === beuno_ is now known as beuno [18:33] and serialize again using the serialization format that 1.9-rich-root uses [18:33] jelmer_: so it would fail for dev6, because you are explicitly casting to 1.9-rr ? [18:34] jam: yeah [18:34] (also, you can stack 0.92 => 1.9 because the serializer didn't change) [18:39] jam: ok, so I guess we'll need something more generic at some point anyway [19:01] jam: definitely, I was hoping to call you today but... so many things to do :) [19:03] vila: not a big deal. I just saw your email, and realized we haven't talked in a while. Maybe tomorrow. [19:04] jam: sure [19:10] Space Shuttle! :D [19:17] couldn't see very well from here [19:21] I couldn't see it at all. It was cloudy, and the trajectory may have interfered. [20:09] jam, w0000000t! [20:09] * beuno dances [20:10] beuno: you received some lettuce in the mail? :) [20:10] jam, EVEN BETTER! [20:10] a patch for stacking on brisbane-core [20:11] yo, can you with bzr commit -m "" how can I add newlines? [20:12] aka line breaks [20:12] Kissaki, I think you need to drop the -m, and jump into an editor [20:13] it can be done with -m [20:13] hm, ok [20:13] thx [20:13] can=can't ? ^^ [20:13] Kissaki: what I do is bzr ci -m 'Added foo.Added bar.' [20:13] Kissaki: ie, let my shell handle the newlines [20:14] Kissaki: can [20:14] tried \n, but that didn't work :/ [20:14] Kissaki: have you tried an actual literal enter? [20:14] hm? [20:14] Kissaki: use the enter key. [20:15] pressing it will exec the cmd ofc [20:15] Kissaki: Depending on your shell, if you're inside quote marks, it won't. [20:15] using windows cmd right now [20:15] ah. windows cmd [20:16] Kissaki: I don't know if the windows shell has support for multiline editing [20:17] Kissaki: I'd leave off -m and spawn a commit editor then. [20:17] well, I'll try copy paste for comment next time [20:17] commit editor? is that something special? [20:17] I doubt tricks like bzr ci -m `cat` will work on windows? [20:17] yeah [20:18] Kissaki: it looks at $VISUAL or $EDITOR, and will spawn notepad on windows if it can't find anything else [20:18] Kissaki: also, you configure what editor to use for commit messages, see `bzr help configuration` [20:18] is there an argument for reading the commit message from a file? in svn you can do svn ci -F or something [20:18] which might come in handy on windows [20:18] sidnei: oooh, good one! [20:18] that was even my first patch for bzr, shame I don't remember :/ [20:18] Kissaki: as sidnei said, you can use -F [20:19] Kissaki: have you tried bzr qci [20:19] no [20:19] it might not be what you want, but just in case [20:19] qci is cool too [20:19] don't even know what ci is [20:19] commit [20:19] ah [20:19] (and qcommit) [20:20] what's the difference? [20:20] it opens a dialog window [20:20] nothing - qcli is an alias [20:20] where you can type the commit messages, select files, see diffs, etc. [20:20] qcli is an alias for qcommit [20:20] *message [20:20] GaryvdM: qcli or qci? [20:21] err qci [20:22] oh, nice [20:22] jam: You left a "bork" in bzrlib/repofmt/groupcompress_repo.py in the dev6 stacking patch. :P [20:22] qcommit indeed does open a commit window/dialog/editor thingy [20:22] thx [20:35] Peng nice catch :) [20:35] though that would hint that the code isn't exercised (as I thought it wasn't) [20:37] :D [20:38] Uhh... Where'd 'bzr revert' move my file to? [20:38] It always used to keep a backup [20:39]