[00:14] <niemeyer> Hello everybody
[00:15] <niemeyer> Is there any way to tell bzr pull something like --overwrite-my-local-tags-only
[00:15] <niemeyer> ?
[00:22] <wgz> I can't quite guess from the name...
[00:23] <wgz> ah, you maybe mean, no new revisions, just get the tags updated?
[00:23] <niemeyer> wgz: Yeah, don't do something crazy with my branch, but overwriting tags that point to different revisions is fine
[00:24] <wgz> `bzr pull -r0 BRANCH` should work.
[00:24] <wgz> -r1 might be safer as it'd tell you before pulling in tags from an unrelated branch
[00:26] <niemeyer> wgz: Not sure I see where you're coming from
[00:26] <niemeyer> wgz: This doesn't really pull the tag changes?
[00:26] <niemeyer> wgz: I mean conflicting tags
[00:27] <niemeyer> wgz: Which are currently only pulled down with --overwrite
[00:27] <niemeyer> wgz: Which unfortunately has other side effects well beyond pulling tag replacements
[00:29] <wgz> hm, the check for tags may happen at a later stage
[00:29] <wgz> and tag conflicts are another fun thing altogether
[00:31] <wgz> hm, no does work
[00:31] <wgz> so, it's only the conflicts case then to worry about
[00:32] <niemeyer> wgz: Yeah, that's exactly the problem I'm trying to solve :(
[00:33] <niemeyer> wgz: I need to overwrite tags commonly, but using --overwrite all the time is not nice
[00:33] <niemeyer> It's just waiting for the day it will _actually_ overwrite something, unintendedly
[00:36] <wgz> file a bug, it doesn't seem quite as rabbit hole-ish as other tag related requests.
[00:39] <fullermd> You could just make an alias that deletes all your tags, then pulls   8-}
[00:41] <niemeyer> wgz: Thanks, will do
[00:41] <niemeyer> fullermd: This is part of the Go language's standard installation tooling
[00:41] <niemeyer> fullermd: I'm not keen on putting such an ugly hack there
[00:42] <niemeyer> It's what enables people to use Bazaar to host Go packages
[00:42] <niemeyer> The reason they have to override the tags is that Go allows people to tag which revision of the branch a given release of Go should pull
[00:42] <niemeyer> and this of course means the tags have to be overwritten every now and then
[00:44] <wgz> how about replacing .bzr/branch/tags with an empty file as an ugly hack? :)
[00:45] <fullermd> Are you sure you need the pull to update the tags?  I mean, you don't really care about the tags locally, as long as you have the right rev, right?
[00:46] <niemeyer> fullermd: It pulls the changes, and updates to the given revisoin
[00:46] <fullermd> And I think -r on pull resolve the rev as the remote side things of it.  So maybe "yeah, my local tags list is out of date, but the rest still works" is a usable step.
[00:46] <wgz> and yeah, does seem like there should be a neater solution to that particular issue, which I'll leave to fullermd
[00:46] <fullermd> Oh, neat solutions are _totally_ not my baliwick   8-}
[00:47] <fullermd> Unless you mean neat in the sense of "Hey, neat, I didn't know my elbow bent that way!"
[00:47] <niemeyer> fullermd: It doesn't pull from remote until requested.. it may shift revisions around multiple times though
[00:47] <niemeyer> LOL
[00:47] <niemeyer> fullermd: We can talk eyebrows later, but I have to find a solution to that first. :)
[00:48] <fullermd> Right, but I think the resolution would happen on the far side's view.
[00:48] <fullermd> So, e.g. `bzr pull -rtag:FOO where://ever` would look at that remote side for tag 'FOO', turn that into a revid, then pull that revid down and set the tree to it.
[00:48] <jelmer_> niemeyer: bug 681792  ?
[00:48] <ubot5`> Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Medium,In progress] https://launchpad.net/bugs/681792
[00:48] <niemeyer> jelmer_: YES
[00:49] <fullermd> (tag FOO existing locally pointing to some other rev would make it kvetch about the tags not matching, but that would be after it set everything to the 'right' rev anyway)
[00:49]  * niemeyer +1s.. or subscribes.. or thumbs ups, or whatever the me too of the day is
[00:50] <wgz> +affectsmetoo
[00:50] <niemeyer> jelmer_: Man, and it's in your plate too
[00:50] <wgz> has the plus, and affects, and me too.
[00:50] <niemeyer> jelmer_: I'm afraid you won't want to see my name anymore.. ;-)
[00:51] <jelmer_> niemeyer: hehe
[00:51] <jelmer_> niemeyer: at least you're not adding more bugs to the list this way.. ;-)
[00:52] <jelmer_> niemeyer: so, that bug actually has a branch attached that fixes it (IIRC the emacs folks asked about it). It just lacks tests, but we can add those and make sure it ends up in 2.5/precise.
[00:54] <jelmer_> niemeyer: IOW, it shouldn't be more than an hour of two of work additional. How much do you need it?
[00:55] <niemeyer> jelmer_: Just added the explanation to the bug
[00:55] <niemeyer> jelmer_: I need it badly.. everybody that is using the "go" or "goinstall" standard tools now from Go are running "--overwrite" on their branches often
[00:56] <niemeyer> Without even realizing
[00:56] <jelmer_> niemeyer: ok
[01:02] <wgz> meh, nearly got to bed an hour ago
[01:02] <niemeyer> wgz: :)
[01:03] <niemeyer> Btw, on a half-related side note, how do I check if e.g. http://launchpad.net/project has a branch associated with it programatically? Can I poke in lp.net/project/.bzr or something?
[01:03] <jelmer_> niemeyer: you can use the Launchpad API to see if it's got a development focus branch
[01:04] <niemeyer> jelmer_: Is there a non-api way with a trivial http get?
[01:04] <niemeyer> jelmer_: E.g. if /project/.bzr/location.conf 404s it's not there
[01:04] <niemeyer> jelmer_: Or is it more magic than that?
[01:04] <jelmer_> niemeyer: I guess something like that would work too. Perhaps http://code.launchpad.net/PROJECT/.bzr/branch-format ?
[01:05] <jelmer_> (assuming the project is public, etc)
[01:05] <niemeyer> jelmer_: Perfect
[01:05] <niemeyer> jelmer_: Thanks
[01:06] <niemeyer> That's for the go tool as well.. I have to improve the handling of series
[01:06] <jelmer_> ah, no launchpad API library for go yet ? :)
[01:06] <niemeyer> jelmer_: Oh, we have a fairly complete one actually :)
[01:07] <niemeyer> jelmer_: http://goneat.org/lp/lpad
[01:07] <jelmer_> ah
[01:07] <jelmer_> neat
[01:07] <niemeyer> jelmer_: The documentation is a bit messy because they've made a change in godoc that is mixing up some methods, but that's being fixed already
[01:07] <niemeyer> jelmer_: But the reason I'm looking for something simpler is that it'd be too much to use that in the go tool
[01:08] <niemeyer> jelmer_: I just want to disambiguate the case of lp.net/project/a/b/c
[01:08] <jelmer_> ah, I see
[01:08] <niemeyer> jelmer_: It could be a branch at lp.net/project with /a/b/c, or a series branch at lp.net/project/a, with a /b/c directory
[01:09] <niemeyer> jelmer_: A quick get on the branch-format you pointed to solves the question
[01:40] <niemeyer> Profit!
[02:29] <AfC> Just filed a UX bug; is there a tag I should add?
[03:27] <achiang> hello, can someone please remind me how to bypass bzr's builtin ignore file and force it to commit binary .so files?
[03:29] <achiang> oh, i just edit ~/.bazaar/ignore
[03:29] <achiang> i wonder if that is auto-created the first time i use bzr?
[03:33] <AfC> If you add & commit an ignored file, it won't be ignored
[03:41] <achiang> bzr init ; bzr add ; bzr commit in an existing directory with foo.so files will skip the .so files (obviously due to ~/.bazaar/ignore)
[03:41] <achiang> i haven't tried directly doing: bzr add foo.so
[03:58] <mwhudson> achiang: directly doing bzr add foo.so will add the file
[04:00] <achiang> mwhudson: thx. i was just being lazy, i suppose. :)
[07:33] <vila> hey guys !
[09:25] <mgz> morning!
[09:32] <vila> mgz: hey !
[09:48] <vila> mgz: ping, pm ?
[09:49] <mgz> thanks vila
[10:12] <wgz> http://stackoverflow.com/questions/4145123/whats-the-right-way-for-a-python-twisted-program-to-validate-an-ssl-certificate
[10:14] <LeoNerd> Mmmm.. async. SSL. Always fun
[10:23] <vila> wgz: this doesn't really give an easier solution for windows than getting the curl bundle (as far as my reading went)
[10:23] <vila> so far
[10:23] <mgz> indeed, that's the point.
[10:24] <mgz> and (without bothering the man in here) if that's what g-lyph says I'm inclined to believe it's true
[10:42] <vila> mgz: err, not sure I follow, you conclusion is to do what ?
[10:42] <vila> s/you/your/
[10:46] <mgz> cry?
[10:47] <mgz> well, add the nix style certs to the all-in-one installer at least
[10:47] <vila> I don't get it, with the code we have already in place, all we need is a single bundle with all the cert roots in there, ha ok
[10:48] <vila> I agree it's not a super clean solution but it will at least avoid blocking everybody
[10:48] <vila> paranoiac users can still chose to opt-out trivially and we'll find a better way later
[10:56] <mgz> I'm not sure I know of any good twisted introductions
[10:57] <mgz> has always been obtuse, despite the reasonable amount of documentation and such like
[11:28] <mgz> 2.5 needs from __future__ import with_statement right?
[11:28] <mgz> ...yes, check it yourself lazy
[11:34] <mgz> morning jelmer
[12:07] <jelmer_> ohai mgz
[12:08] <jelmer_> my irssi highlights seems to be b0rked :(
[12:08]  * mgz strips jelmer_'s underscore
[12:09] <jelmer_> hah, good point
[12:09] <mgz> having the same nick and name is simple at least
[12:10] <mgz> realised in mp comment I have confusing style by referring to John and Vincent... but then also Larstiq. Mixing up names and nicks is bad form.
[12:11] <jelmer> mgz: I think you'll find it's LarstiQ :P
[12:11]  * jelmer stops being pedantic
[12:12]  * LarstiQ cringes
[12:12] <mgz> larsty-queue?
[12:13] <mgz> I wonder what the most painful way to pronounce it is :)
[12:13] <LarstiQ> mgz: oh there are many
[12:13] <mgz> can't top qt and gnome whatever.
[12:15] <LarstiQ> jelmer: one of these I might switch to all lowercase, but I'm afraid that won't stop people from occasionally capitalising the l
[12:18] <jelmer> :)
[12:19] <mgz> jelmer: so, I'm doing review stuff now (though vila has already bashed a fair bit), want to hop on mumble or similar?
[12:26] <sidnei> hi folks, i'm seeing a traceback with tarmac in precise, which smells like maybe some api change: http://paste.ubuntu.com/818744/
[12:28] <mgz> sidnei: bug 917733
[12:28] <ubot5`> Launchpad bug 917733 in Tarmac "AttributeError: 'NoneType' object has no attribute 'cmdline_overrides'" [Medium,In progress] https://launchpad.net/bugs/917733
[12:29] <sidnei> aha
[12:29] <mgz> ...which has actually been merged into 2.5
[12:30] <mgz> there's also a tarmac branch though, which explains the in progress
[12:30] <sidnei> i guess it wasn't released in precise yet though?
[12:32] <jelmer> mgz: sounds good - mumble it is
[12:32] <mgz> nope. there are also enough things like this that I'm wondering if leaving it to 2.5 final won't be a bit long
[12:51] <mgz> ha, talking to myself.
[12:51]  * mgz goes back to humming
[13:01] <jelmer> mgz: sorry
[13:01] <jelmer> mgz: I was talking to myself too
[13:01] <jelmer> mgz: my laptop (which I was using solely for mumble) suspended because it hit ten minutes of "inactivity"
[13:12] <jelmer> argh,not again
[13:13] <mgz> jelmer: sus... right
[13:13] <jelmer> I was talking about the same thing as last time too :)
[13:13] <mgz> :D
[13:13] <mgz> it's a curse!
[14:05] <mgz> jelmer: that might be sign for lunch
[14:05] <jelmer> heh
[14:05] <jelmer> good point
[14:05] <jelmer> back in a bit
[15:13] <mgz> hm, cake might be a bit too lemony
[15:16] <mgz> bug 903696 is pretty popular
[15:16] <ubot5`> Launchpad bug 903696 in bzr-gtk (Ubuntu) "bzr-notify crashed with SIGSEGV in g_return_if_fail_warning()" [Medium,Confirmed] https://launchpad.net/bugs/903696
[15:30] <jelmer> WHY am I in three independent IRC channels where people are talking about cake?
[15:30]  * jelmer feels like he has missed a memo, or something
[15:30] <mgz> :)
[15:30] <mgz> it's all gone now
[15:34] <mgz> jelmer: mumble again?
[15:44] <mgz> heh:
[15:45] <mgz>     def destroy_branch(self, name=None):
[15:45] <mgz>         """See BzrDir.create_branch."""
[15:46] <jelmer> mgz: okay
[15:46] <jelmer> mgz: hehe
[15:47] <mgz> neither BzrDir.create_branch nor BzrDir.destroy_branch actually exist any more
[15:48] <mgz> as they've been moved up to ControlDir
[15:59] <mgz> so, the current error message for the destroy branch no branch branch branch branch branch
[15:59] <mgz> sorry, got carried away
[15:59] <mgz> is: 'Not a branch: "": location is a repository.'
[16:00] <mgz> and destroy_branch is documented as taking None (that should be 'the empty string' now, right?)
[16:01] <mgz> for name for the default branch
[16:01] <mgz> same in create_branch
[16:36] <vila> jelmer, mgz : pfew, finally, I think I found the pristine-tar last blocking issue: pbzip2 needs to be upgraded on jubany...
[16:38] <mgz> jemler: https://lists.ubuntu.com/archives/bazaar/2012q1/074286.html
[16:38] <vila> yeah jemler, no wonder his filters won't catch it ;)
[16:57] <mgz> jelmer: ;_;
[16:57] <hariom> I want to download a repository that is password protected. Is there any way to send username and password in a single command (eg: username:password@someserver/repo)
[16:58] <mgz> hariom: in the context of what protocol? http?
[16:59] <hariom> mgz: https. I am currently using something like: bzr branch bzr+https:// ...          I want to add username and password also
[17:01] <mgz> hariom: what you probably want is to add the details to your authentication.conf
[17:03] <hariom> mgz: Actually I am doing it to automate my program pulling the repo and setup the system. I can't expect my user to modify authenticate.conf
[17:04] <hariom> mgz: bzr branch <scheme>://<user>:<password>@host:port/path
[17:04] <hariom> I guess this should do. Just read the doc
[17:05] <mgz> it does work, bar possibly a few edge cases you probably won't hit
[17:06] <mgz> but putting the auth in the location isn't really ideal
[17:27] <jelmer> vila: hi
[17:27] <jelmer> vila: is there an easy way to do RegistryOption perhaps?
[17:29] <dandrader> hello! how can I merge two commits into one in bzr? Like the equivalent to "git commit --amend" or "git rebase -i" and then selecting "squash"
[17:33] <mgz> LarstiQ: yell when you've pulled in the change for the bzr-pypy branch and I'll land it
[17:34] <mgz> dandrader: if they're the two you've just done, you can uncommit twice then commit
[17:34] <mgz> otherwise there's the bzr-rebase plugin for more complex stuff
[17:35] <dandrader> mgz, ok, thanks!
[19:17] <SpamapS> When using merge-upstream, I got some of these:
[19:17] <SpamapS>   Conflict adding files to plugins-src.  Moved to root.
[19:17] <SpamapS> I'm a bit confused how to deal with them
[19:18] <LarstiQ> SpamapS: is merge-upstream from bzr-builddeb?
[19:18] <SpamapS> yes
[19:20] <LarstiQ> SpamapS: do you have some more context on those conflicts? Maybe `bzr status` output?
[19:21] <SpamapS> These look like just new files, not sure why there is a conflict
[19:21] <SpamapS> http://paste.ubuntu.com/819191/
[19:21] <SpamapS> theres the full bzr status
[19:23] <SpamapS> I'm inspecting the contents of the branch.. cmp'ing to an untar of the imported tarball.. and it all looks good
[19:23] <SpamapS> so maybe this is just a weirdness of merge-upstream ?
[19:27] <LarstiQ> SpamapS: for the plugins-src conflict, the only thing I could think of is that in one tree a file got added with the same path (but different file-id) as a file in the other tree
[19:27] <LarstiQ> but for the license files that doesn't make sense
[19:28] <SpamapS> LarstiQ: whats odd to me is that the resulting contents are perfect, so I don't know why it thinks there is any conflict
[19:29]  * LarstiQ looks at the code
[19:32] <LarstiQ> oh hey, there is `bzr help conflict-types`
[19:34] <LarstiQ> SpamapS: it's the Missing parent conflict
[19:36] <SpamapS> LarstiQ: ahh so merge expected that there would be a revision for that file, but there wasn't?
[19:37] <SpamapS> I'm pretty sure its ok.. and won't break.. much. :)
[19:38] <LarstiQ> SpamapS: no, the file is added to a directory in branchA and deleted in branchB
[19:38] <LarstiQ> SpamapS: that is, that _directory_ has been deleted
[19:39] <SpamapS> ah, ok, so there's no parent for the directory itself.
[19:39] <SpamapS> this sort of makes sense. :)
[19:39] <LarstiQ> SpamapS: if you look at the history you can probably figure out which dir those files got added to that is now gone
[19:40] <SpamapS> LarstiQ: from what I'm seeing, they all got added to the root
[19:40] <SpamapS> LarstiQ: unless rsync is broken too.. it verifies that the contents of the tarball, and the contents of my working copy, are identical
[19:40] <LarstiQ> SpamapS: but if you're happy with their current location that would mainly be to satisfy your curiosity
[19:40] <LarstiQ> SpamapS: yeah
[19:42] <LarstiQ> wgz: pulled, confirmed it's fine under pypy, and pushed
[19:42] <LarstiQ> wgz: should I not change writes to build_tree_contents?
[19:49] <wgz> LarstiQ: I wouldn't bother, as generally there are also bigger things that would be worth changing with old tests
[19:49] <wgz> and then you're rewriting it, which risks breaking the test
[19:49] <LarstiQ> wgz: right
[19:49]  * LarstiQ nods
[19:53] <wgz> LarstiQ: sent. now, off to quiz, bye!
[19:54] <LarstiQ> wgz: ciao!
[19:55] <LarstiQ> wgz: oh, and thanks :)
[20:16] <sidnei> jelmer, filed bug #922800 about the bzr-git vs github issue, before i forget
[20:16] <ubot5`> Error: Launchpad bug 922800 could not be found
[20:22] <jelmer> sidnei: thanks
[20:22] <jelmer> sidnei: is there a particular reason it's private?
[20:22] <sidnei> jelmer, launchpad decided so? i didn't pick private.
[20:23] <jelmer> sidnei: ok, just checking
[20:23]  * jelmer changes to public
[20:48] <Noldorin_> hi jelmer
[21:09] <jelmer> hi Noldorin_
[21:09] <jelmer> how's it going?
[21:23] <Noldorin_> good thanks...
[21:23] <Noldorin_> you?
[21:25] <jelmer> alright too
[21:28] <Noldorin_> jelmer, how's progress on... things? :-)
[21:49] <LarstiQ> jelmer: ehm, get_get_config should be test_get_config?
[22:00] <jelmer> LarstiQ: whoops
[22:00] <jelmer> LarstiQ: I noticed it in the per_branch tests, and then I still copy-n-paste it incorrectly..
[22:31] <jelmer> Noldorin_: Hacking on colocated branches, mostly
[23:11] <wgz> came third.
[23:19] <Noldorin_> jelmer, ah okay :-)
[23:19] <Noldorin_> jelmer, will they be in 2.5 final then?
[23:19] <Noldorin_> they look pretty mature now