[00:20] <mkanat> lifeless: Merging that sourcedeps.conf update that I just proposed should fix the KeyError.
[00:22] <lifeless> thank you
[00:25] <maxb> Hrm... help?  I'm hacking on bzr-svn, and I'm getting exceptions a lot.... and every time, bzr fires up apport needlessly
[00:25] <maxb> How do I stop it?!
[00:25] <poolie> hi maxb
[00:26] <poolie> ah
[00:26] <poolie> turn on the no_apport debug flag
[00:26] <mkanat> lifeless: I'll fix that revision number one, too.
[00:26] <poolie> if you check the "don't show this again" that ought to work
[00:26] <poolie> for the particular bzr script in question
[00:26] <maxb> poolie: seems to work on the command line, but not in bazaar.conf
[00:26] <maxb> and I don't have any 'don't show this again'
[00:27] <poolie> really not in bazaar.conf?
[00:27] <poolie> debug_flags = no_apport
[00:27] <poolie> i think i've used that myself so i'm surprised if it's failing
[00:28] <maxb> hmm. I think I may have assumed debug_flags was a space-separated list erroneously...
[00:28] <maxb> :-)
[00:28] <poolie> commas
[00:28] <poolie> or ', '
[00:28] <maxb> Still, it does seem a bit quirky that bzr does not honour the systemwide apport enabled status
[00:28] <poolie> mm
[00:29] <poolie> maybe
[00:29] <poolie> that one flips as ubuntu goes into release mode, meaning "ubuntu no longer wants so many crash reports"
[00:29] <poolie> i see that as a bit orthogonal to whether we want them in bzr
[00:31] <maxb> I suppose.
[00:32] <maxb> ugh, this is mad. bzr-svn is calling svn's get_dir on various things, some of which are files, and only some of the files trigger a SubversionException: ("Can't get entries of non-directory", 160016)
[00:33] <jml> poolie: you still in #516?
[00:33] <poolie> yes
[00:34]  * jml goes to rock a small part of the world.
[00:38] <mkanat> lifeless, poolie: Okay, proposed a merge for the "no such revision" oops.
[00:38] <poolie> nice
[00:39] <mkanat> It actually was good to fix, because it fixes it for every page, since the code is centralized for reading the revno from the URL.
[01:16] <maxb> huh, novel. bzr-svn just managed to eat 4GB of RAM and drive my machine so much into swap death that I had to kill it from a text console :-/
[03:29] <jelmer> maxb: what were you trying to do with it?
[05:34] <AfC> Hi
[06:40] <gthorslund> morning #drizzle! happy bugs week!
[06:41] <gthorslund> hehe... morning #bzr
[06:41]  * gthorslund little buggy today :D
[08:54] <maxb> jelmer: Run a svn-import with a custom layout class which involved importing a repository with unusually many branches
[10:30] <neaj> 'lo all -- I have a bunch of config files in .../configs , now i want to 'bzr merge configs/a configs/b'. bzr tells me "Nothing to do", but that's not true. What am I missing?
[10:31] <sobersabre> hi.
[10:32] <sobersabre> is it possible to see when the last operation of format conversion of a repository has happened ? (local bzr upgrade call)
[10:32] <neaj> also, i want to 'bzr get configs/b', but bzr tells me: "bzr: ERROR: Not a branch:"
[10:32] <neaj> 'bzr get configs' works, but i don't want all the configs here.
[10:33] <kgoetz> sobersabre: ~/.bzr.log might carry it
[10:33] <bob2> neaj: bzr doesn't currently support checking out part of branches, afaik
[10:33] <bob2> I don't think any modern vcs does
[10:34] <neaj> i believe with svn you can checkout any dir in the repo ..
[10:34] <bob2> right
[10:34] <bob2> 'modern' :-)
[10:34] <neaj> heh OK
[10:35] <bob2> bzr split is a thing, but I don't know how well it works nowadaus
[10:35] <neaj> OK so how to merge configs/a configs/b ?
[10:35] <neaj> i can do diff and patch, but that's hardly modern ;-)
[10:39] <neaj> bzr has no support for merging within a branch?
[10:51] <neaj> making config/a a branch of config/b just to enable merging wouldn't make sense. they're just configs that happen to be mostly similar.
[11:54] <catphish_> is is possible to specify the local path to a branch in bzr commands?
[11:55] <catphish_> ie a path to cwd to before executing the command
[11:56] <bob2> pretty sure you can just use a normal path and it'll find the bzr repo above that
[11:56] <catphish_> how do you specify that path?
[11:57] <bob2> bzr add /who/cares/long/path
[11:57] <catphish_> that's useful for add
[11:57] <catphish_> but for example 'cat'
[11:57] <bob2> it's also useful for cat
[11:57] <catphish_> i'll try it
[11:57] <bob2> less useful for ci
[11:58] <catphish_> so there's no global cwd option?
[11:58] <bob2> dunno
[11:58] <catphish_> but you can specify it on individual commands as part of the filename
[11:58] <catphish_> ok
[11:59] <catphish_> it works for cat :)
[12:16] <maxb> There is no global option, which is quite annoying sometimes. Many commands support -d / --directory, but not all
[12:18] <catphish_> ok
[12:19] <catphish_> it's useful that you can specify it as part of a filename
[12:19] <catphish_> but i might just cd to the path before each command
[13:01] <quicksilver> anyone understand bzr merge internals well enough to tell me what it does in this case here? : http://web.archive.org/web/20070603113858/zooko.com/badmerge/simple.html
[13:25] <quicksilver> bzr also gets it "wrong".
[13:25] <quicksilver> FWIW.
[13:53] <Odd_Bloke> quicksilver: bzr has several merge algorithms, tried them all?
[13:53] <quicksilver> Odd_Bloke: I tried default and weave
[15:12] <jelmer> maxb: find_branches() in svn-import has known memory usage issues
[15:12] <maxb> I think those are what I saw
[15:15] <maxb> jelmer: oh, there was something else I was struggling with, that confused me intensely. The repository I was working with had some doc files at the hierarchy level where branches were.
[15:15] <maxb> bzr-svn seemed to be attempting to interpret the paths as branches, and was calling conn.get_dir(...) on them
[15:15] <maxb> Much to my complete confusion, for *some of them only*, this would cause libsvn to error "Can't get directory entries for a non-directory"
[15:16] <maxb> Does anything like that sound at all familiar to you?
[15:16] <jelmer> vaguely, yeah. IIRC this was a svn server bug
[15:18] <maxb> Does bzr-svn mostly rely on people not having files at places in the hierarchy where it's looking for branches, or did I miss some detail when I went to implement the custom layout class?
[15:19] <maxb> The layout call that seemed to be involved doesn't get passed a revno, so checking in the repo is not feasible
[15:25] <maxb> Oh, actually, it looked more like finding *tags* was what killed it for me
[15:26] <catphish_> what would be the most lightweight way to detect if a repo is empty, and how many commits exist in it?
[15:26] <catphish_> *branch
[15:27] <maxb> cat .bzr/branch/last-revision     ? :-)
[15:33] <catphish_> does last-revision always == number of revisions?
[15:33] <catphish_> i assume it does
[15:33] <maxb> the number in there is the number of *mainline* revisions
[15:33] <catphish_> mainline? (excuse my ignorance)
[15:33] <maxb> i.e. bzr merge bighugebranch; bzr commit will cause it to go up by 1
[15:34] <catphish_> that's merging from a totally separate branch right?
[15:35] <maxb> depends what you mean by "totally separate", but probably yes
[15:36] <catphish_> i'm easily confused because i come from a number of SCMs where one repository has multiple branches
[15:36] <catphish_> and while that is true in bzr, the branches are almost entirely separated
[15:37] <catphish_> i'm trying to git bzr into an environment where one repository has multiple branches
[15:37] <catphish_> which is true of bzr :)
[15:37] <catphish_> but in a way i'm not used to
[15:38] <catphish_> for example to switch branches, one has to switch to a different location on the filesystem
[15:38] <jml> do you guys know about this warning in natty?
[15:38] <jml> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
[15:38] <jml> /usr/lib/python2.6/dist-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
[15:38] <jml>   RandomPool_DeprecationWarning)
[15:43] <maxb> jml: It's been around for aaaages, but you don't see it normally because warnings are suppressed in bzr final releases. But natty currently has a beta.
[15:43] <jml> maxb: ahh, I see.
[15:43] <maxb> IIRC it's waiting for the paramiko team to merge the fix
[15:44] <jml> maxb: Isn't the paramiko team just Robey?
[15:44] <maxb> could be, I don't know
[15:44] <jml> :)
[15:44] <jml> maxb: I guess it's safe for me to ignore the warning for now.
[16:23] <spiv> jml: yeah, it's safe
[16:31] <poolie> maxb, around?
[16:31] <maxb> hi
[16:32] <poolie> maxb i think our 2.2.2 SRU should now be unblocked
[16:33] <poolie> per https://lists.ubuntu.com/archives/technical-board/2010-December/000632.html
[16:34] <poolie> what do you think?
[16:34] <maxb> I think *technically* we were also waiting for 2.3b4/5 in natty
[16:34] <maxb> (Because fixes are supposed to enter natty first)
[16:35] <poolie> hm, really?
[16:35] <poolie> even with a MRE?
[16:35] <poolie> if we were backporting particular patches that would make sense,
[16:35] <poolie> but if we've generally said "2.2.x is acceptable"
[16:38] <maxb> yeah, but we're being quite odd by shipping a beta in natty currently
[16:38] <maxb> most packages wouldn't do that
[16:38] <poolie> why?
[16:38] <poolie> i mean why odd?
[16:38] <poolie> because they're kinda counting on it becoming stable before release?
[16:39] <maxb> Well, it's relatively rare for packages to have beta versions in the archive, that's all
[16:45] <poolie> right, though not unprecedented
[16:45] <poolie> is this a concern to asking for an sru?
[16:45] <poolie> i'd just like to get them actually out, now we've done the releases
[17:01] <maxb> poolie: Understood, I just don't much feel like requesting a SRU whilst we're violating point 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[17:01] <poolie> i see what you mean
[17:01] <poolie> i think that procedure doesn't really allow for the existence of MREs though
[17:01] <poolie> in fact it pretty much contradicts it
[17:02] <poolie> so, i'd like to persuade you to request one and have the conversation with them
[17:28] <quicksilver> is there a way to "resurrect" a deleted file in a way that bzr will actually see as an undeleted?
[17:28] <quicksilver> of course I can just extract it from an old revision and re-add it, but I'm curious
[17:28] <fullermd> revert it to a rev it was in.
[17:28] <quicksilver> ah
[17:28] <quicksilver> I always forget you can revert single files
[17:28] <quicksilver> I always think of doing bzr operations on whole trees
[17:28] <quicksilver> thanks
[17:30] <poolie> quicksilver, i think there's actually a plugin that adds a 'resurrect' command
[17:30] <quicksilver> bzr can't track the case where a file 'becomes two files', can it?
[17:33] <maxb> no
[17:33] <maxb> Hence wailing and gnashing of teeth in the bugtracker concerning 'bzr cp' :-)
[17:36] <poolie> so, maxb, about the sru?
[17:37] <poolie> do you have reservations yourself about proceeding with it, or do you just think it will be rejected, or ..?
[17:38] <maxb> poolie: two things: I'm not happy to push this ahead myself without an explicit waiver on point 1 from ubuntu-sru (because my enthusiasm for this SRU is low and I don't see worth in pushing the borders of policy), and additionally, it's not ubuntu-sru's job to upload packages, so you need to speak to ubuntu-sponsors first, I think
[17:39] <poolie> ok
[17:39] <poolie> your enthusiasm for this SRU is low because...
[17:39] <poolie> the bug fixes in it aren't exciting enough?
[17:40] <maxb> I feel it's taken so long, that most people who care are probably on ~bzr/ppa already
[17:43] <poolie> hm
[17:43] <poolie> well, in general i do want to get updates out
[17:44] <poolie> i want to fix up the sru process so that it there aren't such long delays in future
[17:44] <maxb> hmm, actually I'd forgotten the dput hang is in there
[17:44] <poolie> i wonder if everybody affected by these things has really upgraded to the ppa
[17:44] <poolie> i know, fixed by you even
[17:44] <poolie> it's actually the lead bug for the request
[17:44] <maxb> See, my mind is on 2.3 these days, 2.2 seems so old :-)
[17:44] <poolie> :)
[17:45] <poolie> we were just saying this morning that if we're not going to push them all the way through the process, we almost might as well not do bugfix releases
[17:46] <poolie> i can ask -sponsors to upload it to -proposed
[17:46] <poolie> that might be good practice for me
[17:46] <poolie> i just wanted to understand how you thought about it
[17:46] <maxb> Alright, so I take back my concerns about it not being SRU-worthy, but I'm still reluctant to press the SRU without conforming to the process w.r.t. fixing in natty first
[17:58] <lifeless> james_w: so _export_iter_entries does not permit including . bzrignore
[17:58] <lifeless> james_w: one way to fix things would be to provide a flag to control that
[18:02] <nekohayo> hey there, I did      echo "the revision ID I got from bzr viz" > .bzr-upload.revid        on my remote host because the files are already there and I don't want to reupload them again
[18:02] <nekohayo> but when I try to bzr upload, it says that my local repository has no such revision
[18:03] <beuno> nekohayo, and you're sure you didn't put in the revno, but the actual revid?
[18:03] <nekohayo> yeah, it's foo@bar.com-20110111174334-cg5oj39oq3piua8c
[18:04] <poolie> i wonder if it's unhappy about whitespace or something?
[18:04] <nekohayo> hm, what whitespace?
[18:05] <nekohayo> oh
[18:05] <nekohayo> maybe there's a \n at the end of the file and it doesn't like that
[18:05] <nekohayo> poolie, do you have a trick to remove the trailing \n  ?
[18:05] <poolie> yes
[18:06] <poolie> echo -n FOO > file
[18:06] <nekohayo> that worked
[18:06] <nekohayo> wondering if I should file a bug though
[18:07] <james_w> lifeless, that would work
[18:07] <poolie> nekohayo, hm, generally speaking hacking internal files isn't documented
[18:07] <poolie> s//isn't a bug
[18:08] <poolie> but you could put up a merge proposal that adds it to the documentatino
[18:08] <nekohayo> but for some use cases like this, I presume it can't hurt to strip out the trailing \n ?
[18:11] <nekohayo> oh well
[21:07] <nmendes> hi, can anyone help me? I'm having this problem:
[21:07] <nmendes> bzr branch "svn://localhost/[delphi] dws gestor de licenças/trunk" C:\[dataworks]\Repositórios\test
[21:07] <nmendes> ERROR: Unsupported protocol for url "svn://localhost/[delphi] dws gestor de licenÃ§as/trunk"
[21:07] <maxb> vila: Really, Won't Fix, on bug 701581? I'd say Importance Wishlist, give us a branch if you care
[21:08] <maxb> nmendes: Do you have bzr-svn installed? Run 'bzr plugins' and see
[21:08] <nmendes> k, gonna try, tx
[21:08] <vila> maxb: well.... what will be the point of making the plugin *less* robust ?
[21:09] <maxb> vila: Lots of bzr internal files are line based. I wouldn't begrudge a .strip() call in there
[21:10] <vila> maxb: but this can only happen if the file has been... tampered ?
[21:11] <maxb> true, but people are encouraged to tamper with ~/.bazaar/*, .bzr/branch/branch.conf, so it's not that great a leap for people to try this
[21:11] <vila> maxb: bzr-upload runs on a rather thin ice relying on this file to make sure it was the one doing the upload, editing this file will never be recommended so I don't want to encourage it either
[21:12] <maxb> Basically I agree it's not worthy of yours or my time to make bzr-upload more tolerant here, but I was surprised at the implication we'd refuse a branch even if offered
[21:13] <vila> maxb: well, I'm not ready to accept such a branch so instead of saying no if one is proposed, I thought it was more honest to say upfront: "no, this is not a desired feature"
[21:14] <maxb> fair enough. I'd have suggested it was an acceptable change, but I doubt I'll ever use the plugin, so I don't have strong feelings on it
[21:14] <vila> maxb: and it's probably the first time I used WontFix
[21:15] <vila> maxb: not mentioning that rsync will probably does a better job reagrding bandwith than the plugin, so...
[21:15] <maxb> ok :-)
[21:16] <nmendes> I have the bzr-svn plug in installed, the problem is the special char "ç" on the svn path, looks like it is tanslated  to "Ã§" and so the command fails
[21:17] <nmendes> same command with svn paths without those king of chars work as expeted
[21:18] <maxb> That is odd. I would not have expected " Unsupported protocol for url " even if there was a charset bug of that sort
[21:20] <nmendes> just did it:
[21:20] <nmendes> C:\Users\Nuno Mendes>bzr branch "svn://localhost/[delphi] dws meteo/trunk" "C:\U sers\Nuno Mendes\Desktop\[delphi] dws meteo" Branched 13 revision(s).
[21:21] <nmendes> C:\Users\Nuno Mendes>bzr branch "svn://localhost/[delphi] dws gestor de licenças /trunk" "C:\Users\Nuno Mendes\Desktop\[delphi] dws gestor de licenças" bzr: ERROR: Unsupported protocol for url "svn://localhost/[delphi] dws gestor de  licen├ºas/trunk"
[21:23] <nmendes> looks like a bug, right?
[21:23] <maxb> Indeed, that looks like a bug
[21:23] <maxb> Could you try creating a bzr branch with an accented character in its name, to discover whether it is a bzr or bzr-svn bug?
[21:24] <nmendes> k
[21:24] <jelmer> nmendes: what version of bzr-svn?
[21:26] <nmendes> C:\Users\Nuno Mendes>bzr init-repo --format=default "C:\Users\Nuno Mendes\Deskto p\a name with a ç just to test" Shared repository with trees (format: 2a) Location:   shared repository: Desktop/a name with a ç just to test
[21:27] <nmendes> init -repo works ok
[21:28] <nmendes> Tortoise Bazaar 0.5.8
[21:28] <nmendes> bzr-svn 1.0.4
[21:32] <nmendes> bzr branch "svn://localhost/[delphi] dws meteo/trunk" "C:\Users\Nuno Mendes\Desktop\brance_with_a_ç_to_test" Branched 13 revision(s).
[21:33] <nmendes> looks like it's on bzr-svn
[21:35] <poolie> hi vila, all
[21:35] <poolie> i'm still upstairs
[21:40] <jam> poolie: be that way, then
[21:40] <jam> :)
[21:42] <lifeless> its all me :P
[21:42] <lifeless> jelmer: ncommander in the arm room would benefit from some 1:1 on bzr-builddeb - how to get it going on existing source+packaging branches that don't have import revisions etc
[21:42] <jelmer> lifeless: hey
[21:43] <poolie> i'm going to see about getting lifeless some help for his stiff neck^Wback
[21:43]  * jelmer goes by the arm room
[21:46] <vila> poolie: don't worry we're waiting for you to open the door
[21:47] <poolie> ?
[21:47] <poolie> seriously? didn't i give you the card?
[21:47] <vila> :)
[21:47] <vila> sorry
[21:47] <poolie> :)
[21:47] <vila> of course you did, we're in, just teasing you for making my laptop ring :)
[22:35] <TheTinyToon> Hi Everyone - a collegue and me are testing Bazaar in a partner workflow and have a question regarding the steps to get started
[22:36] <TheTinyToon> From what I get, I first initialize a local repo, make some changes and commits and send a tarball over to my collegue
[22:36] <TheTinyToon> he then branches from my tarball, makes some changes himself while I work on my local branch
[22:36] <TheTinyToon> our changes are then send by mail via bzr send and merged in our local branches
[22:37] <TheTinyToon> however, every time I try to send a mail after making some changes, I always the the warning "Bundling 0 revision(s)"
[22:37] <TheTinyToon> Any hints?
[22:39] <lifeless> you probably are not holding a mirror of your partner's branch
[22:39] <lifeless> bzr send wants to compare two branches to see what needs to be sent
[22:40] <TheTinyToon> lifeless: I tried it locally by branching my repo into another directory, made some changes in the new branch and tried to send those back to myself - same error.
[22:40] <TheTinyToon> "bzr status" shows me the correct parent branch path
[22:40] <lifeless> you may need to show a pastebin of your commands or something
[22:41] <TheTinyToon> k, one sec
[22:44] <TheTinyToon> http://pastebin.com/Z4QLz77s
[22:45] <lifeless> jam: might be interesting to run http://draketo.de/proj/hg-vs-git-server/test-results.html agains bzr
[22:45] <TheTinyToon> we are currently evaluating Bazaar as a method for our students to get them used to effectively work in teams
[22:46] <maxb> TheTinyToon: It's often more convenient to use some shared server than email to pass around changes. Is there a particular reason you are focussing on 'bzr send' ?
[22:47] <TheTinyToon> maxb: no particular reason - we just want to start without a central server
[22:47] <TheTinyToon> ... or public repos at all
[22:49] <spiv> jam: http://paste.ubuntu.com/552997/
[22:49] <maxb> OK, well the two arguments to bzr send are the submit branch and the public branch
[22:49] <maxb> The submit branch is the branch you are submitting the changes to - or a mirror thereof
[22:50] <TheTinyToon> aah, switched the arguments
[22:50] <maxb> The public branch is a public location holding a copy of the branch you are currently in - it's optional unless --no-bundle is in use
[22:52] <maxb> The problem with having no central server is that it is hard for a group to have a good collective idea of what the latest master version is. Use of sent bundles generally works best when there's a clear hierarchy of how changes flow from person to person, which there generally isn't in a student project
[22:52] <maxb> Unless the project has deliberately been structured to exemplify this workflow
[22:53] <TheTinyToon> maxb: yes, we are thinking about showing several workflows, one of which should be the "manual one"
[22:54] <maxb> NB that even when using 'bzr send' to send changes *up*stream, there's usually a read-only public location from which people can fetch changes downstream
[22:55] <maxb> i.e. developer A sends in a merge request to the project leader, developer B later pulls/merges from the project leader's public branch
[22:56] <TheTinyToon> yeah, classic human gatekeeper workflow - will definetly be shown.
[22:57] <maxb> In which case it's pretty much "cd mybranch && bzr send ../gatekeeper-mirror"
[22:57] <TheTinyToon> jup - thanks for the help. We're testing it now...
[23:00] <vila> maxb: just thought I'd mention your fix for the ssh leak associated with socketpair is about to land and the next submission in the queue should address the last failure with py27 on natty
[23:01] <maxb> aha
[23:02] <vila> :)
[23:32] <jml> btw
[23:32] <jml> really like seeing shelf status from 'bzr st'
[23:32] <jml> thanks.
[23:34] <jelmer> jml: Blame Parth :-)
[23:34] <jml> jelmer: ok
[23:40] <jml> hmm
[23:40] <jml> how do I see the diff for a shelved item?
[23:40] <mwhudson> bzr unshelve --preview
[23:41] <spiv> wot 'e said.
[23:41] <jml> ahh yes
[23:41] <jml> I don't know how I missed thta
[23:41] <jml> mwhudson, spiv: thanks.
[23:41] <lifeless> I missed it the other day
[23:42] <spiv> Perhaps because you didn't look at unshelve because you specifically didn't want to unshelve yet :)