[00:23] <maxb> Ugh
[00:24] <maxb> It seems that the most annoying part of producing packages for the bzr ppa is just wrestling the debian/changelog into sanity across five distroseries
[00:24] <maxb> I really need to come up with a way to automate this
[00:26] <poolie> hi maxb
[00:26] <poolie> it is annoying
[00:26] <poolie> a tool for it would be great
[00:27] <maxb> There are several parts
[00:28] <maxb> One part is the changelog merge hook needs to understand not to sort entries in version number order when ~foo suffixes are involved
[00:28] <maxb> Another part is that when doing PPA builds, often the right way to merge an entry is to s/lucid/karmic/g the header line, rather than listing all versions involved
[02:41] <poolie> mwhudson, spiv do you recall how to get pyflakes to work with lazy_import?
[02:41] <mwhudson> poolie: install it from lp:~mwhudson/pyflakes/support-lazy_import
[02:42] <poolie> or comment out the lazy import :)
[02:42] <poolie> thanks though
[02:42] <mwhudson> well that works too, but my version is a bit more automatic :)
[02:43] <poolie> is that url right?
[02:44] <poolie> and the related question is: is pyflakes still the best static checker?
[02:44] <poolie> nm, found it: 'support-lazy-imports'
[02:46] <mwhudson> ah oops
[02:46] <mwhudson> it's still the best i know of
[02:46] <mwhudson> pylint does more, but requires assloads of configuration to be useful and is slow
[02:47]  * mwhudson attempts to merge trunk into his branch
[03:01] <mwhudson> so...
[03:01] <mwhudson> what do people use to handle difficult conflicts?
[03:02] <mwhudson> (the problem i have here is that the merge has resulted in the conflicting sections being broken up in unhelpful ways)
[03:02] <poolie> vimdiff or meld
[03:04] <mwhudson> does anything know how to parse the conflict markers out of the file and start from there?
[03:06] <spm> mwhudson: 'rm <file>'
[03:07] <poolie> how do you mean?
[03:07] <poolie> i think emacs has a mode that specially recognizes herringbones
[03:10] <poolie> spiv, is https://bugs.launchpad.net/bzr/+bug/603395 now fixed?
[03:10] <poolie> can you please update it either way?
[03:11] <mwhudson> i guess i'm not sure what i mean
[03:11] <mwhudson> kdiff3 seems quite nice, if a bit obscure
[03:19] <mwhudson> hm yes, pretty good
[03:19]  * mwhudson pushes up his new branch
[03:25] <spm> is there an easy way to discover which branch a certain chunk of text was added to a file? I have the text, would just like to track the context/when it was added as it looks... odd.
[03:25] <spm> bah. try #2. not which branch, *when* a certain chunk of text.
[03:26] <poolie> spm: two ways
[03:26] <poolie> 'bzr log -p |less'
[03:26] <poolie> then search
[03:26] <poolie> or 'bzr grep  -r 1.. PATTERN'
[03:27] <poolie> ah bug 388437 is the one about ascii in error messages
[03:27] <spm> kk, ta muchly.
[03:30] <spiv> spm: or look at that the "bzr annotate" output (preferably with "bzr gannotate" or "bzr qannotate", depending on your GTK vs. Qt preference)
[03:30] <spm> worked perfectly, with one rider. search from bottom up. the text was about every 3rd change recently. :-)
[03:30] <spm> spiv: ah, k. I'll try that just to see. the problem - this is on prasé, but I suppose I can branch locally. yay for VCS. :-)
[03:31] <spm> yay for *D*VCS.
[03:33] <poolie> oh, if it's still present that's a more obvious way to do it
[04:34] <poolie> would appreciate your thoughts on https://bugs.launchpad.net/bzr/+bug/388437 too
[04:52] <spiv> Before I look at that bug my thought is "can __str__ return a unicode object?"
[04:53] <spiv> mgz probably knows the esoteric ins and outs here.
[05:16] <spiv> poolie: your comment on 388437 sounds ok to me
[05:17] <spiv> poolie: if nothing else, I doubt your suggestions can be worse than the status quo ;)
[07:12] <vila> hi all !
[07:22] <spm> hey vila
[07:23] <vila> spm: hey there !
[07:24] <vila> spm: regarding your mail about lp/pqm, I only have one GPG key, but possible two emails attached to it differing only by '+lp' (the one I use most of the time) which is also the one I use for bzr, I should be able to use it right ?
[07:24] <vila> s/possible//
[07:24] <spm> mayeb....
[07:25] <spm> pqm is *really* fussy over the order of keys in the key itself. so generally whichever is the default is the one you must use.
[07:25] <vila> spm: right, so if it works for bzr, it should work for lp
[07:25] <spm> try it and we'll find out :-)
[07:26] <vila> hehe
[12:58] <RenatoSilva> I have a single file from a given upstream version. I patched it and now I want to merge upstream changes. But it's a single file, and they don't even use Bazaar. Is it possible to somehow automate this?
[12:59] <beuno> RenatoSilva, they don't use bzr, but you do?
[12:59] <RenatoSilva> beuno: of course, I'm managing the patch with bazaar
[13:00]  * beuno was just checking  :)
[13:00] <RenatoSilva> ok
[13:00] <jelmer> RenatoSilva: they're using a foreign VCS or something like that, or did you import a tarball manually?
[13:00]  * beuno waves at jelmer 
[13:00] <RenatoSilva> jelmer: it's just a single file
[13:00] <jelmer> hey Martin
[13:01] <jelmer> RenatoSilva: you could create a separate branch with their version of the file in it and then use "bzr merge" to pull in new changes
[13:04] <RenatoSilva> jelmer: ok will try it
[13:19] <RenatoSilva> jelmer: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[13:19] <jelmer> RenatoSilva: yeah, your original branch needs to derive from the upstream branch
[13:19] <jelmer> sorry
[13:19] <jelmer> RenatoSilva: yeah, your branch needs to derive from the upstream branch
[13:36] <RenatoSilva> jelmer: bzr branch -r 1 mypatch temp; mv upstream-changes temp; cd temp; bzr commit -m "New upstream rev hg:123"; cd ../mypatch; bzr merge --preview ../temp
[13:37] <RenatoSilva> jelmer: this seems to work
[13:41]  * AfC wonders why people do merge --preview ... just merge and then commit or revert
[14:02] <RenatoSilva> is there any way of qlog or qdiff ignoring whitespace?
[14:05] <vila> jelmer, beuno: bzr-upload 1.0.0 has been officially released
[14:06] <jelmer> vila: \o/ Congrats :-)
[14:06] <vila> I'm all ears for feedback on my last tweaks and what is needed for this release to reach the distributions ;)
[14:06] <jelmer> vila: Does it fix the test suite?
[14:06] <vila> jelmer: I hope so, feedback welcome
[14:07] <vila> jelmer: bug #671964 ?
[14:09] <vila> jelmer: I added a info.py file and according tweaks (by looking at bzr-svn and bzr-gtk), I probably broke something there or in the setup.py (I also added a MANIFEST.in)... Monkey see, monkey do. Monkey welcomes feedback to do better too ;)
[14:09] <jelmer> vila: Cool
[14:09] <beuno> vila, woooooooooooooooooooooooooooooooooooooooooooooooooo \o/
[14:10] <beuno> pitty it's too early to drink
[14:10] <vila> n'ver too 'rly
[14:11] <beuno> vila, and we started this what... 3 years ago?
[14:11] <beuno> maybe a but more?
[14:11] <vila> beuno: the release doesn't include all the shimy features we've dreamed about, but at least it's out :)
[14:12] <vila> beuno: OMG, I have no idea, too bad we didn't take notes or use a VCS :)
[14:12] <beuno> vila, well, it was born during the bzr community sprint
[14:12] <beuno> so we should be able figure out when that was
[14:12] <vila> beuno: I remember precisely the restaurant we were in :)
[14:13] <vila> first commit on 2008-03-07
[14:14] <beuno> 2 years and 3/4  :)
[14:15] <vila> I find it interesting that a VCS made this project possible, a few hours here and here stretched across ~3 years... and still a useful piece of code
[14:17] <RenatoSilva> is there any tool for exporting an hg branch to bazaar?
[14:17] <beuno> RenatoSilva, fast-import, I think
[14:19] <RenatoSilva> http://wiki.bazaar.canonical.com/BzrFastImport, can't grok
[14:20] <RenatoSilva> I just want something like bzr import --hg $hgbranch
[14:20] <vila> RenatoSilva: bzr-hg ?
[14:22] <RenatoSilva> vila: thanks
[14:24] <RenatoSilva> Unable to load plugin u'hg'. It requested API version (2, 0, 0) of module <module 'bzrlib' from 'c:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1)
[14:25] <vila> >-/
[14:27] <RenatoSilva> also, "This plugin requires recent versions of Bazaar **and Mercurial** to be installed to work."
[14:27] <vila> RenatoSilva: yeah, looks like it needs love
[14:28] <vila> RenatoSilva: next bet would be to search in hg for a fast-export path then
[14:28] <RenatoSilva> or use hg at all :P
[14:29] <RenatoSilva> I was trying to avoid installing and touching hg
[14:30] <vila> it's a bit surprising though, there are launchpad imports for hg branches, so there should be a version around that is at least compatible with bzr-2.2
[14:30] <jelmer> RenatoSilva: that's not really possible
[14:30] <jelmer> RenatoSilva: as far as I know hg itself is the only thing that can read mercurial repositories
[14:31] <RenatoSilva> jelmer: so how about bzr-hg?
[14:31] <jelmer> RenatoSilva: bzr-hg depends on mercurial itself
[14:32] <RenatoSilva> vila: is that LP import accessible to regular users?
[14:32] <jelmer> RenatoSilva: yes
[14:33] <vila> AFAIK if the branch is public you can request its import. You may need the corresponding project created on lp first though (unless it already exists of course)
[14:34] <RenatoSilva> no automated way?
[14:35] <jelmer> RenatoSilva: the request handling is automated
[14:35] <vila> RenatoSilva: ? Once the import is defined, it will run periodically
[14:35] <RenatoSilva> will the imported branch keep in sync with external version?
[14:36] <RenatoSilva> will new commits be automatically imported into the local bzr branch?
[14:36] <RenatoSilva> what if there are conflicts?
[14:36] <RenatoSilva> how do I request an import?
[14:36] <jelmer> RenatoSilva: they won't automatically be imported into the local Bazaar branch, only to the branch on Launchpad
[14:37] <jelmer> RenatoSilva: In theory new revisions will be pulled in automatically twice a day or so, but there have been some issues with the Mercurial imports
[14:37] <jelmer> RenatoSilva: So I wouldn't rely on them beyond the initial import at the moment.
[14:38] <RenatoSilva> by local I mean Launchpad
[14:38] <jelmer> RenatoSilva: the launchpad branch would be owned by Launchpad, you can't change it (so there is no possibility of conflicts)
[14:39] <RenatoSilva> I don't understand
[14:39] <RenatoSilva> I can't change it?
[14:40] <jelmer> RenatoSilva: no; it's a mirror of the remote mercurial repository
[14:40] <RenatoSilva> but see, I want to maintain a patch to a project but without using hg
[14:40] <jelmer> RenatoSilva: you can clone the import and make the changes in your clone
[14:41] <RenatoSilva> jelmer: so the imported branch behaves like upstream was really using bzr, and I can't touch it as I'm not upstream dev. So I branch it and merge chnages normally, that's it?
[14:42] <jelmer> RenatoSilva: yep
[14:58] <RenatoSilva> ok trying right now, is this the right url, http://hg.guifications.org/purple-plugin-pack ?
[15:00] <RenatoSilva> how to associate the mirrored branch with a given project? https://code.launchpad.net/~renatosilva/+junk/purple-plugin-pack
[15:10] <RenatoSilva> "New code import created. The code import operators             have been notified and the request will be reviewed shortly."
[15:10] <RenatoSilva> but you said it was automated :(
[15:11] <beuno> RenatoSilva, I'll review it for you
[15:11] <jelmer> beuno, RenatoSilva: it is
[15:11] <jelmer> RenatoSilva: it's auto-approved
[15:11] <RenatoSilva> so message needs to be updated
[15:12] <RenatoSilva> or the operators are bots
[15:12] <jelmer> RenatoSilva: there's a bug about that in launchpad-code
[15:12] <RenatoSilva> ok
[15:13] <RenatoSilva> it was said here that the imports happen once or twice a day but that there has been problems with hg, can I manually request an update?
[15:13] <beuno> RenatoSilva, what's the branch's url?
[15:13] <RenatoSilva> https://code.launchpad.net/~renatosilva/purple-plugin-pack/trunk
[15:13] <RenatoSilva> beuno: ^^^
[15:14] <beuno> http://launchpadlibrarian.net/60435984/renatosilva-purple-plugin-pack-trunk.log
[15:14] <beuno> it failed to import
[15:14] <beuno> jelmer, ^
[15:16] <jelmer> looks like that host has broken 404 handling :-/
[15:19]  * jelmer looks a bit further
[15:47] <jelmer> RenatoSilva: sorry, got distracted by some failing tests.
[15:47] <jelmer> RenatoSilva: https://bugs.launchpad.net/bzr-hg/+bug/670870 exists for this issue
[15:48] <RenatoSilva> thanks, subscribed
[15:49] <RenatoSilva> about manual import, there's a button "import now" :)
[16:07] <RenatoSilva> :(
[16:11] <jelmer> RenatoSilva: ?
[16:17]  * RenatoSilva sad for the branch import not working
[16:18] <jelmer> RenatoSilva: ah
[16:18] <jelmer> RenatoSilva: It doesn't appear to be a hard issue to fix, I might have a look at doing so after work
[16:19] <RenatoSilva> thanks jelmer
[17:07] <fabio_kreusch> Hi there, I want to have subprojects inside a project, is that possible?
[17:10] <RenatoSilva> fabio_kreusch: #launchpad ?
[17:10] <RenatoSilva> fabio_kreusch: no, but you can request a project group
[17:12] <fabio_kreusch> no, I mean, I have a bzr repository, and I want to have subrepositories inside that
[17:13] <fabio_kreusch> these subrepositories would contain code shared by other projects
[17:16] <beuno> fabio_kreusch, no, bzr doesn't support nested trees at the moment
[17:16] <beuno> there is working going on to support it, but I don't know the state of it
[18:15] <ankurd> a quick repo-organization question:
[18:16] <ankurd> i hv a bzr project in a dir A. Now i want to create a project such that root is dir B and A is sub-dir of B.
[18:16] <ankurd> So, do i create a new project? coz I want to maintin the old log.
[18:16] <ankurd> or do I extend this project somehow
[18:17] <abentley> So you want to have a new project B that contains your existing project, A?
[18:17] <ankurd> no I want the same project A to contain A and B both
[18:18] <abentley> How can A be a subdir of B and contain B?
[18:18] <ankurd> i mean the project should now hv B as root dir
[18:18] <abentley> B is the root dir, and contains A?
[18:18] <ankurd> yeah
[18:19] <abentley> That sounds like what I said before: a new project, B, that contains your existing project, A.  What am I not getting?
[18:21] <ankurd> any ideas?
[18:22] <abentley> ankurd, I don't understand what you want, so I don't know how to help you get it.
[18:22] <ankurd> k lemme restate my problem
[18:22] <abentley> You may have missed this: "That sounds like what I said before: a new project, B, that contains your existing project, A.  What am I not getting?"
[18:23] <ankurd> i hv a project that has A as root dir
[18:23] <ankurd> I want this project to hv B as root dir now
[18:23] <ankurd> B is parent dir of A
[18:24] <ankurd> is that clearer?
[18:24] <abentley> ankurd, You can do "cd B; bzr init .; bzr join A."
[18:24] <ankurd> ohh
[18:25] <ankurd> cool. thnx.
[18:25] <ankurd> i was looking for this join command
[18:25] <abentley> ankurd, np.
[18:27] <abentley> ankurd, You might need to do a commit in B before joining A.
[18:28] <ankurd> oh
[18:28] <ankurd> i dint do a commit.
[18:28] <ankurd> and did join
[18:28] <ankurd> now wat?
[18:31] <abentley> ankurd, do a commit, and see if you get what you wanted.
[18:33] <ankurd> k. i wil try
[18:44] <ankurd> hey, i did what you said but now i have lost all logs from dir A
[18:44] <ankurd> ?
[19:06] <abentley> ankurd, does your last revision show as a merge?  If you do "log -n0", do you see all your old history?
[19:08] <ankurd> bzr: ERROR: An inconsistent delta was supplied involving 'bzrm.bzrignore', 'bzrignore-20100601133919-09b2wh8pcslnnrih-1'
[19:08] <ankurd> reason: working tree does not contain new entry
[19:08] <ankurd> i get this error wen i try to commit after join
[19:10] <abentley> ankurd, if you run "bzr status", it should show a pending merge.  Does it?
[19:10] <ankurd> working tree is out of date, run 'bzr update'
[19:10] <ankurd> renamed:
[19:10] <ankurd>   / => bzrm/
[19:11] <ankurd> i dont think this is a pending merge!?
[19:13] <abentley> ankurd, bzrm is "A" in your description, right?  The project you wanted to be inside B?
[19:13] <ankurd> yeah
[19:16] <abentley> ankurd, please run "bzr revision-info --tree".
[19:17] <ankurd> 0 legalos.lotr@gmail.com-20101210184654-5ry4l7wlfg90x8cu
[19:17] <ankurd> this is the output
[19:17] <ankurd> ?!?
[19:17] <abentley> ankurd, right, great.
[20:45] <lifeless> mgz: https://bugs.launchpad.net/testtools/+bug/688719 https://bugs.launchpad.net/testtools/+bug/688724
[20:47] <millun> hi
[20:47] <millun> my repo is atm called "src". how can i change that? in bzr explorer
[21:51] <ryanprior> I want to share some code with a friend who's on Windows. He's only a beginning programmer and I don't want to overwhelm him with instructions for pulling code from a repository. How easy is the setup procedure for bzr on Windows?
[21:51] <ryanprior> (I'm on Ubuntu and bzr is, thankfully, easy as pie over here =D)
[21:53] <mkanat> ryanprior: It's an installation package, on Windows.
[21:54] <ryanprior> mkanat: does it manage all the dependencies for you, or will I have to walk him through dependency building?
[21:54] <mkanat> ryanprior: It should handle everything.
[21:55] <ryanprior> mkanat: thanks, we're going to give it a go.
[21:55] <mkanat> ryanprior: Okay, cool.
[22:00] <millun> my repo is atm called "src". how can i change that? in bzr explorer
[22:01] <Peng> millun: As long as you don't break the structure, you can usually rename stuff to your heart's content through the OS's renaming tools.
[22:03] <millun> ok
[22:10] <ryanprior> I'm trying to share my code using "bzr push lp:~ryanprior/+junk/mycode" but I'm getting this error: bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[22:11] <ryanprior> Google tells me that might be a Launchpad or bzr bug, but I'm still suspicious that I'm doing something wrong. Any ideas?
[22:12] <mkanat> ryanprior: Did you log in with your LP id in bzr?
[22:12] <ryanprior> I did "bzr launchpadlogin ryanprior" and it gave no output, so I assumed it worked.
[22:12] <james_w> ryanprior, what does "ssh ryanprior@bazaar.launchpad.net" say?
[22:13] <ryanprior> Permission denied (publickey). So I suppose I need to get my crypto in order somehow.
[22:52] <mgz> lifeless: is that not just one aspect of bug 675327? the branch I proposed should fix it.
[22:55] <mgz> spiv/poolie: yeah, storing the url on the exception then using a __unicode__ method would be best, but getting it all matched up to handle the issues poolie mentioned in the bug will be the fun bit.
[23:01] <lifeless> mgz: perhaps it is
[23:02] <lifeless> mgz: I've done an audit/fixup of the testtools bug db
[23:02] <lifeless> mgz: in your mp, jml says there is more to go to be fixed
[23:02] <mgz> I've just looked at my emails and seen it, going through now.
[23:02] <mgz> there isn't in the branch, but I think trunk may have broken something else in the mean time
[23:02] <mgz> I'll look into it now.