SmileyChrishow do I set up the default maintainer email so that "bzr send" doesn't need an email address?00:03
lifelessSmileyChris: according to the help, submit_to is the configuration key to set00:06
SmileyChrislifeless: yep, i got that far... how do you set configuration keys00:06
SmileyChristhe help wasn't very clear on that00:07
lifelessthe user guide has documentation about that00:07
lifelessbasically just edit a config file depending on where you want the setting to apply00:08
lifelessglobally/url/branch are the three choices00:08
SmileyChrislifeless: thanks for the explanation. So I can attach this setting to the branch itself or is it a client-side only configuration?00:12
jelmerHmm, that reminds me00:13
jelmerI wonder if it makes sense to have a UI command for modifying the branch configuration?00:13
jelmerincluding some way to list the available settings00:13
SmileyChrishrm... i see there's a .bzr/branch/branch.conf - i wonder if that's where it should go00:14
SmileyChristhe guide isn't very clear on this00:15
jelmerSmileyChris, yep, that's where it should be00:17
SmileyChrisjelmer: cheers00:17
SmileyChrisjelmer: does it need to be in a [DEFAULT] block?00:17
jelmerSmileyChris, yep00:17
SmileyChrisgood to know00:17
SmileyChrisactually, i see in my local branch.conf there isn't a default block00:21
SmileyChrisprobably doesn't need it, it's a branch specific conf anyway00:21
SmileyChris:(   bzr: ERROR: No mail-to address specified.00:25
SmileyChrisseems it can't be server-side, unless i'm doing something wrong00:25
SmileyChriswhich is more than likely :P00:25
jelmerSmileyChris, it can be server side00:25
jelmerset child_submit_to on the server side00:25
lifelessonly affects new branches though I believe00:34
mwhudsonhow do i create a branch of a particular format in a test?00:36
mwhudsonmake_branch only takes a format for the bzrdir, unless i'm misreading things00:36
mwhudsoni guess make a bzrdir and initialize a branch of the desired format on it?00:38
lifelessmwhudson: format=knits etc00:42
lifelessmwhudson: tests/test_repository.py shows nearly every variation00:43
lifelesssome fugly, some not00:43
* mwhudson reads00:45
mwhudsonbzrdir.format_registry.get('knit')() seems reasonably clear for this purpose00:46
lifelessself.make_branch('foo', formamt='knit') is the most pithy00:46
markhThe bzr user's guide says "Checkouts are source trees that are connected to a branch" - is that strictly accurate?  Isn't a checkout a "bound branch"?00:57
markh(it doesn't qualify with 'lightweight')00:57
lifelessmarkh: its strictly accurate01:00
lifelessbound branches are still connected to a branch01:00
markh"source tree" implied "working tree" to me01:01
markhwhat is a "source tree"?01:01
lifelessI'd guess a tree you edit your code in ?:)01:01
lifelessnote that a bound branch with no tree object is not a checkout of any shape or form01:01
markhhrmph - the docs for "bound branches" define it as being exactly a "checkout"01:02
markh(I'm trying to get my head around a few of the subtleties I've been happily glossing over)01:02
markhso I'm not trying to be painfully pedentic.  Given that http://bazaar-vcs.org/BzrUsingBoundBranches defines "bound branch==checkout", I'd expect the user's guide to be stated as "Checkouts are branches that are connected (or "bound") to another branch"01:04
bob2bound branch + working tree = checkout01:06
markhright.  So the users guide is slightly misleading ("source tree" is vague) and BzrUsingBoundBranches is also slightly misleading (makes no reference to working trees) ;)01:08
markhis there a ane usecase for a bound branch without a working tree?01:08
lifelessmarkh: yes01:22
lifelessmarkh: one in particular is quite fun:01:23
markhhow about s/sane/common/?01:23
lifelessmirror bound master (no tree)01:23
lifelesslightweight checkout of mirror01:23
lifelessI think that one is quite common for shared trunks01:23
lifelesson C style projects where you want only one tree and to reuse build products01:23
markhright - so I'm thinking of "bound" as being mainly useful for checkins.  Why would 'mirror' use a bound branch, rather than just pulling from masteR?01:26
lifelessmarkh: so that you can checkin to trunk when you want to, but still access what trunk looks like offline01:29
markhright - "mirror" is writable.01:30
teratorndoes anyone use graphical diff/merge tools w/ bzr? if so, which ones?02:13
AfCteratorn: Not very often, but `meld` comes in handy once in a while.02:14
teratornwas just looking at meld.. gotta try it out02:14
teratornideally I would like a tool that can also let me do cherry-picking and then shelve or commit those selections02:14
teratornhuh what that's crazy talk02:40
markhI see 'info' agrees that a bound-branch must have a tree to be reported as a 'checkout'.  On a similar vein, when would be come across a 'branchless tree'?03:37
lifelessa branchless tree does not exist03:39
lifelessto open a branch you must have a reository object03:39
lifelessto open a tree you must have a branch object03:39
markhright - "info" explicitly handles that case, but it should never hit it in real life?03:43
markhor only upon misused of that api I guess...03:44
lifelessthe API won't let you construct this03:49
lifelesscheckout --lightweight generates a branch references03:49
markhI mean misuse of 'info.describe_layout(), which takes the repo, branch and tree as 3 sep args. but thanks for confirming that isn't another state I need to worry about :)03:54
Verterokmarkh: ping05:00
markhVerterok: hi05:00
Verterokmarkh: hi05:00
Verterokmarkh: are you building the standalone bzr.exe?05:01
Verterokmarkh: I'm wondering if it's possible to include SimpleXXMLRPCServer in it05:03
markhVerterok: I'm sure it would be for 1.7 I guess.05:04
Verterokmarkh: some bzr.exe users, also use bzr-eclipse and xmloutput plugin (that need SimpleXMLRPCServer)05:04
* Verterok dances05:04
Verterokmarkh: if I can help, just drop me a line. I'll be glad to ;)05:06
markhhow will I know if it works? :)  I can add that line to the 'includes' option to py2exe, but I'm not sure what to do after that...05:06
markhI know - once 1.6 is out, just ping me and I'll hack up a binary and you can test it ;)05:07
Verterokmarkh: bzr branch lp:bzr-xmloutput and bzr start-xmlrpc :-D05:08
markhheh - ok05:08
Verterokmarkh: if that is the only py2exe trick, I can try to build a binary and run some tests05:08
markhits likely to also need 'xmlrpxlib' nominated in 'packages'05:09
markhit would help if you could do that - then just submit a merge request and I won't need to do anything at all ;)05:09
markhbut if you don't and I remember, I'll have a go when 1.7 is getting closer05:10
Verterokmarkh: I can try :). do I need a custom enviroment to build bzr.exe?05:10
Verterokmarkh: easier, any wiki/doc telling how to build it? :)05:11
markhtheoretically not :)  It might complain about a few things missing, but should succeed05:11
markh'make installer' if you are *really* lucky ;)05:11
markhobviously need py2exe installed, but most other things are optional05:12
* Verterok fires up virtualbox and waits05:12
markhxmlrpclib appears to be a simple module and is already in the package.05:13
markhas is SocketServer - so if you are extremely lucky, you could just stick SimpleXMLRPCServer.pyo in library.zip and it would work ;)05:13
Verteroknice :)05:14
VerterokI'll give py2exe a try, if I'm lucky enough...I'll send the patch05:17
Verterokmarkh: thanks for the guidance :)05:20
Spazdoes bzr support checkouts of only portions of a source tree? or do you have to get the whole thing?05:56
Spazi haven't been able to get a straight answer :/05:56
bob2where source tree = branch05:56
Spazwe host multipule projects in our suppository, it would be possible to create branches for each of the projects, right?05:58
Spazi genuinely typo'd that >_>05:58
Spazah i see.05:59
Spazbob2, and you can check out each branch independently if my understand is correct, right?05:59
Verterokmarkh: bzr.exe with xmloutput, worked like a charm :D06:26
markhVerterok: excellent ;)06:27
* Verterok sends the patch06:27
lifelessVerterok: cool06:28
Verterokindeed :-D06:28
* Verterok heads to bed07:04
Verterokseeya later07:05
lifelessabada abada abada, thats all folks07:54
vilafinally, hi all10:43
LeonidasHow to get the changes from the initial revision?10:43
Leonidas(using the bzrlib api)10:43
lifelessLeonidas: current tree vs revision 1?10:45
Leonidaslifeless: but that does not show me what was added in revision 1. I need to use something like:10:45
Leonidasbzr diff -r ..110:45
Leonidasso I need the first revtree and the revision 1 revtree10:46
Leonidasahh! Where is NULL_REVISION defined?10:47
Leonidasbzrlib.revision.NULL_REVISION, ok10:49
=== mark1 is now known as markh
=== mark1 is now known as markh
jpdsHello all, can someone please tell me what's happening here? http://paste.ubuntu.com/40393/11:21
Kamping_Kaiserbad stuff :P11:25
Kamping_Kaiser(hi mate)11:25
jpdsKamping_Kaiser: hi.11:25
RAOFjpds: You can't upgrade over bzr+ssh11:34
jpdsRAOF: So what do I do?11:35
RAOFjpds: You can over sftp, but that takes quite some time; there's an open bug on the bzr-launchpad integration for a "upgrade this branch" button.11:35
RAOFBe warned: remote upgrades over sftp aren't exactly lightning fast.  Bring a packed lunch :(11:36
Stavroswhenever i do bzr upgrade i get this error and a corrupted repo: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.11:44
luksyou want to upgrade to --rick-root-pack (probably)11:48
luksand corrupted repo in what way?11:48
Stavrosluks: i move .bzr.backup back to .bzr and it doesn't recognise it as a repo11:50
Stavrosso my only option then is to delete the whole thing11:50
luks"doesn't recognise" isn't very specific11:51
Stavrosbzr: ERROR: Not a branch11:51
luksit upgrade corrupts anything it's a serious bug11:51
Stavroslet me do it again11:51
lukswhat's inside the .bzr directory?11:51
Stavroslet me reupgrade to tell you for sure11:52
Stavrosoh it works now11:52
Stavrosthat's odd11:52
Stavroswell, not the upgrade, but the backup11:52
Stavrosis rich root pack better than the one i have currently?11:53
Stavrosi don't understand why it fails, though11:53
Stavrosit succeeded upgrading to that, if i push will the other repo also get upgraded?11:53
bob2it isn't better11:54
Stavroswhy upgrade to that then?11:54
bob2but if you need to support branches from bzr-svn, you need to use it11:54
Stavrosis it worse?11:54
Stavrosah, okay then11:55
bob2it just supports a feature needed by bzr-svn11:55
bob2eventually the default format will support something like that too and everyone will stop getting confused :)11:55
luksStavros: and no, push will not upgrade it11:55
Stavrosluks: ah, thanks11:56
=== mark1 is now known as markh
Spazi'm made a branch trunk/foo, but when i go to do something like bzr co http://example/trunk, foo doesn't show up12:15
lifelessif your branch is trunk/foo, you should checkout trunk/foo :)12:16
Spazlifeless, i want the whole thing though (trunk/foo included)12:16
luksno, it doesn't work like svn12:17
Spazis there any way i can make a branch that behaves that way?12:17
lifelessSpaz: you want a branch that contains other branches?12:17
Spazlifeless, yes, but i want those branches to also be able to be checked out not just individually, but all at once12:17
lifelessSpaz: bzr really isn't gear to do that12:18
lifeless(none of the modern DVCS's are)12:18
RAOF"bzr multi-pull" can help.12:18
RAOFOn the client side, at least.12:19
SpazRAOF, is this a plugin of sorts?12:19
lukslifeless: well, git and hg can do that, but it's not as streamlined as in svn12:20
RAOFIt's in bzrtools, I believe.12:20
RAOFbzr multi-pull will pull all the branches under the current directory.  At least that's how I use it :)12:20
lukshaving a bzr extension that does something like http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html would be nice12:20
RAOFIsn't that subtree support?12:20
Spazanother question12:20
lifelessluks: they don't do the same thing12:21
RAOFI may have got that wrong, though.12:21
lifelessluks: gits nested tree is similar to bzr's, hg's is very different12:21
Spazwait nvm12:21
lifelessluks: and none are analagous to svn's system12:21
Spazi was going to ask if bzr had plans for arbitrary checkouts, but i'll just use nested branches for now12:21
lukslifeless: git's submodules are not bound to specific revision, as far as I know12:21
lifelessluks: they are refs12:22
luksso it works kind of like svn:externals12:22
RAOFAh, so submodules appear to be svn externals.  Which isn't what he's after, anyway.12:22
Spazbzr multi-pull works :)12:22
lifelessluks: "Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit."12:22
luksuh oh12:22
lukssorry then12:22
lifelessits ok :)12:22
luksso it's the same principle as bzr subtrees, but not as integrated12:23
Spazwhile it's kind of an "argh >_<" thing for me, it's not like "argh let's go back to svn" kind of thing12:23
lifelessbut I'm not prone to random wrong statements:>12:23
lifelessactually I think git and bzr subtrees/submodules will be nearly identical12:23
lifelesswe've got very similar model in this regard12:23
luksI'd like more something like svn externals12:23
lifelessyeah, we have a second iteration planned that will be closer12:24
lifelessSpaz: we have plans for arbitrary checkouts12:24
luksshouldn't be hard to do as a plugin using git submodule's UI though12:24
Spazlifeless, :o12:24
lifelessSpaz: 'views' is what we'll call them12:24
Spazhrm views?12:25
Spazsounds like it's read-only12:25
lifelessno more than any other operation12:25
Spazoh nice12:25
lifelessit will just select a subset of the tree to put on disk12:26
lifelessthe same amount of history will be needed locally etc etc12:26
Spazah ok12:26
lifelessbecause to merge full trees you need access to the full tree metadata12:26
Spazany clue about what version this might happen? (i'm asking for mere speculation, i'm not asking for "when will it be done" etc.)12:26
lifelessits *why* DVCS works efficiently12:26
Spazah ok12:27
enquestcan somebody quickly help... I installed bzr on my server. I can commit my files... But an other user when he want to commit gets  "Cannot lock LockDir" How can I solve this?12:33
lifelessenquest: permissions I would say12:35
lifelessenquest: does he have write permission ?12:35
enquestI made a group "admin" and added him and me to that group12:35
enquestwhat should I do more?12:36
lifelesscheck the permissions on the contents of .bzr/12:36
lifelessI bet its wrong group or some such12:36
enquestlifeless, the permissions on the .bzr is drwxr-xr-x12:37
enquestand enquest:admin12:38
enquestso I should give write permissions to admin?12:38
enquestis that correct lifeless12:39
lifelessI would say so :)12:42
staniThe bzr faq says that there are other version control systems better suited for binary files (such as images), but it gives no references. Does anyone has a good suggestion?12:53
luksI don't know of anything that has a smart delta compression of compressed data12:54
staniluks: thanks. Just the way the FAQ is written, it suggest that such tools exist. I use bazaar for coding, but I want something similar for my projects which consist of only images.12:59
luksthere are systems that handle binary data better in general13:00
luksbut for compressed content, such as images or video, it doesn't help much13:00
staniluks: are some of these systems free? could you give some names?13:02
lukssvn does binary xdelta compression13:02
luksbut what exactly are you doing?13:03
staniwell, I am a visual artist, so the result of my projects consist of images13:04
stanisome are generated by self written code, some are manipulated in gimp, ...13:04
lukswhat format are they in?13:05
staniI mostly use png for generated images, as it is compressed without quality loss13:06
luksanyway, I don't think you will see any significant differences between most VCSes13:06
stanibut some are also in svg13:06
bob2are svg files typically gzipd?13:07
staniI generate svg through pycairo13:08
luksI'd personally just use bzr if you already know it13:09
luksI wouldn't use bzr only if the files are huge13:10
luksit doesn't handle that well13:10
=== andreas__ is now known as ahasenack
bjacquesHi. I have a local branch from a shared repository and I would like to add the branch to the main repository, while keeping it a branch. How do I do that?13:26
luksnot sure what do you mean by that13:28
luksthat is 'the main repository'?13:28
bjacquesby main repository I mean the remote, shared repository which contains the trunk branch13:29
luksjust push it there13:29
luksif you push it to a location under the repository, it will automatically use it13:29
bjacquesI see, thank you13:29
bjacquesSo do I specify bzr push sftp://remote/reporoot/mynewbranch or do I omit "mynewbranch"?13:31
luksincluding mynewbranch, the command is correct13:31
bjacquesthanks again13:32
=== thunderstruck is now known as gnomefreak
cfchris6I have a problem using bzr-gtk, namely the visualize command, on my gentoo box. I am using bazaar 1.1.0 with bzr-gtk 0.94.0 I installed it by extracting the tarball into /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk Error is pasted here: http://rafb.net/p/P9TdMc24.html14:16
luksyou need newer bzr14:17
cfchris6luks: Ok, I will try, just thought it should work with these versions cause http://bazaar-vcs.org/bzr-gtk said bzr-gtk 0.94.0 should work with >=1.014:18
luks1.5, probably14:18
lukslooks like a lie :)14:18
lukshm, no14:19
cfchris6looks like the personal taste of gentoo developers prevented a stable program to get into stable tree, once more :/14:19
luksiter_ancestry was added earlier14:19
luksstill worth a try to upgrade14:19
luksthere is a bzr overlay for gentoo14:19
cfchris6bzr 1.5 is already in the portage tree, but tagged as ~x86 not x8614:21
pickscrapeEasy to just add it to portage.keywords14:21
cfchris6I know gentoo, and I did so, but it is not a nice solution because mixing arch with ~arch sometimes breaks things14:22
pickscrapeMy package.keywords is as long as my arm :)14:23
pickscrapeI prefer to use stable generally, but push certain things along as I need them.14:23
lukswhat does the ~ mean?14:24
pickscrapeEffectively the 'unstable' branch14:24
luksso, "doesn't work on x86"?14:24
pickscrapeMore like they're not confident, not sufficiently tested, they can't be arsed etc14:25
pickscrapegnome basically stays in ~ for about six months after release14:26
cfchris6pickscrape: it's more a question of the maintainers taste. e.g. pidgin 2.4 was already very long in portage (~x86) but it became x86 not because it was said to be stable enough but just because 2.3 did not work anymore14:26
pickscrapecfchris6: == can't be arsed :)14:27
Freakyjust ~x86? what about all the other platforms?14:27
cfchris6Freaky: In general it was ~arch, for more exotic ones I don't know14:28
pickscrapeOther arches could be quicker or slower. They have dedicated arch teams, so it depends on how on the ball they are when compared to the maintainer of the package itself.14:29
cfchris6anyway, with bzr-1.5 it works now, thank you14:30
pickscrapeThe only downside of the bzr gentoo overlay is that it includes beta packages. It would be nice to have a stable version of the overlay14:32
* vila wonders who put water into his gusty -> hardy upgrade after midnight14:50
jamvila: I put sugar in the tank, but I didn't have time to get water. Must have been someone else.14:50
vilaI guess so, but the last gremlin needed a .xmodmaprc to get killed. though one :-/14:51
pickscrapeCheck the power cord to your clock.14:52
vilalightbulb ! The clock damn it ! Skewed again !14:52
jamvila: I'm just waiting for your next hhtp patch14:53
jamhm... it seems beuno isn't around yet14:53
jamtime to get the 1.6-final out the door14:53
jamanyone have any blockers?14:53
jamLast chance14:53
vilathe last days were all about reorganizing my hardware and the associated softs, I just have to commit now.14:55
jelmersiretart, thanks, much appreciated :-)15:02
* jelmer hopes this is also the first step towards loggerhead on bzr.debian.org..15:03
james_wjelmer: well, we almost got webserve on there, but it missed etch, and then the project seemed to stall, so I refrained from packaging it15:06
jelmerso it looks like we'll be out of luck again, since we're already past freeze time :-/15:09
james_wyeah, though they may be willing to use a backport once it is actually in15:09
=== cody-somerville_ is now known as cody-somerville
jelmerjames_w: ah, cool, that's definitely worth asking for15:15
james_wI agree15:16
siretartjelmer: I think they prefer packages from backports.org, but asking might be a good idea anyway15:17
jelmerbug 516:07
ubottuLaunchpad bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] https://launchpad.net/bugs/516:07
=== cody-somerville_ is now known as cody-somerville
=== jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.6-final is out !!! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
luksyay :)17:50
luksno more RCs17:50
Peng_Wait, so there was no rc7? Damn!17:51
Peng_Congrats on the release. :)17:51
* Peng_ has to run.17:51
RichWI'm trying to merge this branch https://code.launchpad.net/~richies/hypernucleus/richie into this branch https://code.launchpad.net/~manuq/hypernucleus/manuq but the two branches have different revision histories (I creaed mine wrong!). How do I merge them?17:58
RichWIt gives me this error: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.17:58
jelmerRichW, the two branches you're trying to merge are not related18:10
jelmerRichW, are you really sure you'd like to merge them?18:11
jelmerRichW, if so, just specify -r0..-1 to "bzr merge"18:11
* mw starts his bzr 1.6 for opensuse packages18:14
jamSo... what is the proper debian string for the 1.6 release?18:14
jam"1.6~bazaar1" sorts before "1.6~rc5..."18:15
jamShould it be "1.6-1~bazaar1"18:15
jamor "1.6~1~bazaar1" ?18:15
jamthanks luks18:15
luks1.6~bazaar1 would mean a native debian package18:16
elmoerr, surely it's just 1.6-1 ?18:16
luksyes, but not for ppa packages18:16
elmooh, right, PPA18:17
RichWjelmer: ok il try it, some things happened and it all went wrong :)18:19
luksRichW: honestly, with such branches I think diff/patch is the best you can do18:20
jamluks: ok, I tried your method to build the package, care to try it out?18:23
jamIt is in my ppa18:23
luksone sec18:23
luksdid you upload the packages?18:23
* luks doesn't see them18:24
jamjelmer, james_w: If you want to give it a poke, too. I'm using bzr-debbuild for this18:24
jamluks: upload just finished18:24
luksah, it will take a moment then18:24
jelmerjam: I just uploaded 1.6-1 to Debian sid18:24
jelmerjam: What branch is the ppa build created from? I can't instal the package here, but I can look at the changes.18:25
jamjelmer: it is built from the tarball18:26
jamOr you mean the "debian" branch?18:26
jamI just have that locally18:26
jelmerjam: yeah, the debian branch18:26
jamIt is originally branched from luks work18:27
jambecause I'm just playing with it for now18:27
jamI'll switch to the "official" ones later18:27
jamjelmer: I'll push it real quick18:27
lukswell, I didn't change anything but fixing the watch files18:27
jamjelmer: when it finishes: lp:~jameinel/+junk/packaging-hardy18:28
* jelmer wonders if the ppa branch shares any ancestry with the pkg-bazaar debian team branch18:28
jamluks: well, and you "released" ~bazaar218:28
jelmerjam, thanks18:28
luksoh, yes :)18:28
jelmerah, looks like it was based on the Debian packaging branch, it's just diverged since then18:29
jamluks: LP has just accepted my submission and is building now18:29
jamjelmer: seems like we should mostly keep them in sync18:29
jamlamont: I know you had concern about our earlier packaging, would you care to take a look at my attempt at a 1.6-final package?18:30
lamontjam: my build just finished. :-)18:30
jamluks: Would you know why, export FOO="a b c"; for foo in $FOO; do echo $foo; done always gives them all at the same time?18:31
jamluks: I'm trying to use your documentation18:31
jambut it seems ZSH doesn't do "for" like bash/sh18:31
lamontjam: gives me 3 lines of output....18:32
jelmerjam, package looks good to me18:32
jamlamont: I don't know if that is good or bad18:33
lamontjam: it's correct. :-)18:34
lamontand yeah, package looks fine18:34
jamyay \o/18:34
lamontthe 3 lines was wrt $FOO above18:34
jelmerjam, there's not a lot of differences with the debian debian package18:34
jamlamont: using zsh or bash?18:34
jelmerjam, (try diffing with http://bzr.debian.org/pkg-bazaar/bzr/unstable to see)18:34
jamjelmer: I see a lot of differences in the changelog, but I guess that is because you don't actually include the upstream release information in changelog18:36
jamSo it only has your changes18:36
jamjelmer: also, do you still have the "contrib/bash/bzr" bug?18:37
jamI see this line: contrib/bash/bzretc/bash_completion.d/18:37
jamin your unstable branch18:37
jelmerno, that's been fixed (though differently from the ppa branch)18:38
jamah, ok18:38
jamah, and you don't remove ones that are already there18:38
jamas part of post-install18:38
jelmerWe never uploaded a package with the broken file in it, so there's no need to do that for us18:39
jamjelmer: should we be merging your changes for stuff like "overrides/bzr" which sets "script not executable" on a few files18:39
jelmerjam: Yeah - the overrides are no longer necessary18:40
lamontjam: bash18:40
jelmeryou may also want to import the change to the watch file, which makes sure that betas for a release are not considered newer than the release itself18:40
jamso for changelog, is it meant to be only the changes for that "branch" of packaging?18:40
jamjelmer: I think luks did a similar change18:41
jamopts="uversionmangle=s/(rc|b)/~$1/" \18:41
jelmerah, right18:41
jelmerjam: I'm not sure what the right policy is wrt merging changelogs18:41
radixdoes anyone know if launchpad supports stacked branches now? (no response in #launchpad)18:41
lamontjam: IOW, zsh isn't posix.18:41
lamontsee also the behavoir of dash18:42
jamlamont: it seems like it, though it is a bit odd18:42
jamlamont: it prints it out 3 times for me18:42
jamIt prints "a b c" 3 times18:42
jamwhich is a bit silly18:42
jamah no, that was because I was using: FOO='a b c'18:43
jamand bash does the same18:43
jamThis is just strange: bash -c "FOO='a b c'; for x in $FOO; do echo $x; done"18:43
lamontin zsh I get 'a b c'18:44
lamontin dash and bash, I get a\nb\nc\n18:44
jamyeah, same here lamont, except for the one I just posted, where I get "a b c\na b c\na b c\n"18:44
lamontscripts shouldn't use zsh :-)18:45
fullermdUnless they're zsh scripts  ;)18:45
lamontif you need that rich a language, you don't belong in a shell18:46
jelmerradix, I think so18:46
jelmerradix, It is running bzr 1.6 IIRC18:46
jamlamont: Well the specific issue was that it is a "step by step of what to do to release" not a real script, and I couldn't follow it because zsh is my interactive shell. I can always workaround that18:47
jamsuch as by turning it *into* a script :018:48
gourcongrats to all devs for 1.6!18:48
gourjelmer: bzr-svn will follow-up shortly?18:49
jelmergour, 0.4.11~rc1 is already in Debian18:49
jelmeror do you mean the 0.4.11 release?18:49
jamjelmer: can we get 0.4.11 into the bzr ppa/beta ppa?18:50
gourjelmer: 0.4.1118:50
jelmergour, In the next couple of dayus18:50
gourgreat. ta18:50
gourit no longer requires svn-1.5?18:51
jelmerno, just svn 1.4 or higher18:51
jelmerno patches18:51
gourthat's great18:51
jelmerjam: Sure, I'm happy to help with that18:51
jamWe'd also like to get bzr-gtk put there18:52
gourfinally, one will be able to completely replace fetching all svn repos with bzr-svn :-)18:52
jamwhatever works with 1.618:52
jam lamont: so do you know about "merging changelog" files? I would like to sync up our various packaging branches, and don't want to do something stupid. I can just revert "changelog" when I merge in the other changes.18:53
gourbzr will return to monthly-releases now?18:53
jamgour: well I'm in charge of 1.7, so *it* will be a time-release, I can't say beyond that :)18:53
jamI do believe everyone wants to return18:53
lamontjam: increasing chunks in time is always a good merge there... shame to lose history, unless it's pointless history18:54
jelmerjam: I would rather not do the uploads myself though, since I can't promise I'll be able to upload regularly18:54
lamontfor my packages, I tend to just not change debian/changelog, and then generate it at release time... less pain that way18:54
lamontsince debian/changelog _never_ merges cleanly18:54
gourjam: thank you for great work. i'm (slowly) learning python..hopefully be able to help a bit in the future18:54
lamont(for values of never approaching zero)18:54
jamjelmer: well, if we can streamline the process, I'm fine with documenting it and having a standard "release 1.X" include packaging the important plugins.18:54
jamlamont: well all of our "debian/changelog" entries are "* New upstream release"18:55
jelmerjam, should we have a look at doing that now?18:55
gourit's interesting experience to switch between haskell & python...18:55
jamAnd we have one entry for each ~hardy1, ~gutsy1, etc.18:55
jamjelmer: That would be nice. I'd like to get bzr-1.6 and associated plugins18:55
jamEveryone complains when they go to upgrade bzr and lose all of their deps18:55
lamontjam: all of the "package for $SUITE" are (IMO) boring and can be tossed - pretty much any ~ debian version (as opposed to ~upstream versions, which are interesting)18:57
lamontalthough more so if they have more meat to them than "new upstream release"18:57
jamlamont: that is what "bzr log --short" is for :) [or NEWS]18:58
jelmerjam: Pushing to ~bzr/bzr-svn/ppa-hardy18:59
=== fta_ is now known as fta
jelmerjam: Can you see if that uploads correctly to ppa?18:59
lamontjam: bzr log19:00
lamontbzr: ERROR: Not a branch: "/home/lamont/chroots/a/bzr-1.6~rc5/".19:00
lamontchangelogs _should_ have some history in them.  source packages _shouldn't_ have VCS trees in them.19:01
jamjelmer: so you want me to package that? or just check if a package shows up in ~bzr/+archive ?19:02
lamontthen again, I expect that the upstream changelog is in the binary package19:02
jelmerjam: It should already be packaged for hardy in the ppa19:02
jamjelmer: the only package I see is: https://edge.launchpad.net/ubuntu/hardy/+source/bzr-svn19:04
jelmerjam: It's finished now, lp:~bzr/bzr-svn/hardy-ppa19:04
jamand ~bzr-svn doesn't have a ppa19:05
jelmerjam: Sorry, I meant I hadn't uploaded it yet, but all the right bits are in the bzr branch I pushed to19:05
jamjelmer: so you want me to "bzr debbuild -S" it ?19:06
jelmerjam, yep, please19:06
jam(currently grabbing it)19:06
jamshould I be uploading to the ~bzr-beta-ppa or is it ready for ~bzr ?19:07
jelmerTo whatever you uploaded 1.6 I think19:07
jamjelmer: sure I just wanted to know if it was "stable" enough for the official ppa19:08
jamI haven't uploaded anything to a public ppa yet19:08
jelmerjam: Probably beta for now then19:10
jamand that is a regular bzr-svn branch right, not just a packaging branch19:10
jamhow do you manage that across multiple targets?19:10
jelmerjam: It's a regular bzr-svn branch that includes the debian/ dir19:10
jelmermakes it easier to do debian-specific source changes19:10
radixI guess the bzr deb packages aren't built yet?19:28
jelmerradix, jam is working on uploads to the ppa19:32
radixthank you jam :)19:33
jelmerradix, I've uploaded packages to debian experimental19:33
radixcan't wait to try it out with lp19:33
james_wjelmer: did you file a sync request as well by any chance?19:33
jelmerjames_w, not yet - shouldn't I wait for it to actually hit experimental?19:34
james_wjelmer: it's normally safe as they have to get a sponsor's ACK first19:34
jelmerjames_w, ah, cool - I'll request one then19:35
* jelmer hugs ubuntu-dev-tools19:35
jelmernow if only somebody would package it for debian...19:35
jelmerjames_w: I've modified "bzr mu" to support merging from branches rather than just tarballs/directories20:05
jelmerjames_w, It'll now also default to using the export-upstream location if in export-upstream mode20:06
jelmerjames_w, and retrieve the upstream version number automatically from tags and revnos20:07
jelmerjames_w, It would be nice though if it could automatically add a draft entry to debian/changelog though20:07
ToyKeeperIs there a recommended bzr way to include one project inside another?  (for example, project/mylib/ has its history tracked separately)20:12
jelmerToyKeeper, "bzr join" can import one project in another and makes merging in the future easier20:12
jelmerToyKeeper, there's no way to reference another project by location yet - that's what nested branches will bring20:13
ToyKeeperI have a common library I'd like to include with other projects, and basically would like 'bzr branch lp:myproject' to include the shared lib if possible.20:14
ToyKeeperBringing the lib in at 'make dist' time is trivial, at least.20:14
jamYou could also look at the "bzr-merge-into" plugin. As long as the merge is "1-way" (you do the devel in the plugin branch, and then merge it into the project branches) it works pretty well.20:16
james_wjelmer: yeah, it doesn't do that for any mode20:18
james_wI stayed away from writing more code20:18
ToyKeeperI could just 'bzr export' the lib into a subdir and pretend it's part of the base project, until nested trees are working.20:18
jelmerjames_w: It suggests the right command to run, but I'm getting very lazy :-)20:19
ToyKeeperHmm, I've used merge-into for one-time imports, but it doesn't seem to like merging a second time when the original branch changes.20:24
jelmerToyKeeper, if it's a subdir, I would recommend using bzr join20:25
ToyKeeperYeah, I'm just trying to figure out how to merge changes after the initial join.20:28
jelmerjust "bzr merge <location>" should work I think20:28
ToyKeeperMaybe it's supposed to, though.  I'm getting a traceback when I try.20:30
lamontjam: mutter.'  and here I thought you'd just uploaded rc5-1~mumble, not that the release was out and that the sources weren't in the ppa yet.20:32
ToyKeeperlooks like the same thing as bug 20337620:53
ubottuLaunchpad bug 203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/20337620:53
ToyKeeperWeird.  Some of the paths listed in the traceback don't exist.  It's printing a different path than the file it's using.20:57
ToyKeeperIt seems like it's been broken since bzr 1.2 or maybe earlier.20:59
=== maw_ is now known as mw
jamlamont: :) no, have a couple other things I'm trying to get out, and then I'll upload21:04
jamjelmer: hardy-ppa wants to sign the archive with *your* key, does that matter?21:04
lamontjam: no worries... if you happen to feel like it, poke me with something pointy when you upload, eh?21:05
lamontjam: debsign -m$yourkey foo_ver_source.changes21:05
jamlamont: well, there is one in https://launchpad.net/~jameinel/+archive but I should have 1.6 final uploaded to ~bzr in about an our21:05
jam *hour*21:05
jelmerjam: You should probably just sign it with yours21:05
jamjelmer: builddeb doesn't like that21:05
lamontjam: -m21:05
jamjelmer: And I'm not enough of a deb guru to really know the point to do it at.21:06
lamontto override the maintainer in debuild21:06
jelmerjam, Perhaps just change the name in the last entry in debian/changelog21:06
lamontjelmer: or pass in "-uc -us" and then manually "debsign -m$MYID foo_ver_source.changes"21:06
* lamont usually does the last of those, so he could be completely wrong about debbuild taking a -m argument :-(21:07
jamWell, builddeb defaults to -uc -us21:08
jamBut the config that luks suggested has me configure it to actually sign them.21:08
jamDoes LP require signing?21:08
jamI know it doesn't sign the binary packages21:08
jelmerjam, it requires signing on uploaded source packages I think21:08
=== toytoy_ is now known as toytoy
jamjelmer: hm... it seems to actually connect to lp:bzr-svn, is there any way to get it to use my local repo instead?21:10
jelmerjam: Yep, use --export-upstream=../path/to/local21:11
jamjelmer: thanks, that helps a lot. Now... what about APR?21:12
jamIt seems to cause a warning21:12
jambut doesn't actually fail the build process21:12
jelmerjam: What sort of warning?21:12
jamjelmer: "make" seems to be failing21:12
jelmerin what way?21:13
jamException: apr-config not found. Please set APR_CONFIG environment variable21:13
jammake: [python-clean-2.5] Error 1 (ignored)21:13
jamcd . && python2.4 setup.py clean -a21:13
jamsh: apr-config: not found21:13
jamjelmer: but it doesn't actually stop the build21:13
jamI'm installing libapr1-dev now21:13
jelmerjam, Oh, that's actually correct21:14
jelmerit should be a little bit less verbose21:14
jamnow, of course, it needs the svn devel files21:14
jelmerthere's different names the apr config utility can have21:14
jelmerthe first name in the list doesn't exist on your system, but the second one probably does21:14
jamjelmer: well, I didn't have the libapr1-dev at all21:14
jaminstalling it made it happy21:14
jammy bigger problem is that the build should *fail*21:15
jelmerjam, You do have libapr-dev probably21:15
jamif it can't actually build21:15
jamI didn't have libsvn-dev or libapr1-dev21:15
jamI don't know if you still need svn-dev21:15
jambut the build process *thinks* it does21:15
jelmeryeah, you need libsvn-dev21:15
jamjelmer: so there seems to be a problem that "make" isn't causing the builddeb process to fail21:16
jamso I would probably have built a bogus patch if I didn't check the traceback21:16
jelmerjam: I don't think it should've failed21:16
jelmerjam: It searches for apr-config first, then apr-1-config21:16
jamjelmer: why is that, or more importantly, why do you need to do make if you don't need it to succeed21:17
jamjelmer: I didn't have svn-dev either. I'm pointing out that "make" failed, but builddeb did not21:17
jamIt seemed to think the package was fine21:17
jelmerjam, it was the clean step that failed21:18
jelmerthat's probably allowed by cdbs21:18
jelmerjam, not the build step21:18
jamwell, installing libapr1-dev and libsvn-dev and it builds "cleanly" so I'll stick with that for now21:19
jamlamont, jelmer: 'dput' requires the file to be signed. Thanks for giving me the "debsign -mXXXX" command21:21
lamontjam: dput, and the backend processing both. :-21:21
jamjelmer: your .debs have been uploaded to ~jameinel/+archive, I imagine it will be a little while for them to build and be available21:21
jelmerjam: cool21:22
jamjelmer: I can copy them to ~bzr-beta-ppa if you want to give them a once over and make sure they are valid21:22
lamontand clean failing isn't necessarily an error... although it does bear wondering about21:22
jamjelmer: also, what about builds for ~gusty and ~intrepid?21:22
jamand even ~dapper21:22
jelmerjam: sounds like a good idea to me :-)21:23
jamjelmer: I just don't know what it actually *entails* I get the branches handed to me for bzr21:23
jammy deb-fu is *very* week21:23
jelmerjam: it should be a matter of just taking the ppa-hardy branch and replacing hardy with intrepid/dapper/gutsy in the top-level entry of debian/changelog21:24
jamjelmer: ppa just accepted my submission21:25
jamalso, what do you guys think. Should these be ~bzr/bzr/packaging-hardy, or should they be ~bzr/bzr-packaging/hardy branches?21:26
jamAs it is just the "debian" directory, they seem like they should be separate branches21:26
jamBut someone mentioned that most of the "ubuntu" packages are not done that way.21:26
jam(separate projects)21:26
jelmerin the case of bzr-svn, it really is a bzr-svn branch21:28
jelmerin the case of bzr, I would prefer seeing that move to the same approach as bzr-svn >-)21:29
jamjelmer: "packages failed to build" for amd6421:29
jam /bin/sh: python2.4: not found21:30
jelmerhmm same thing for which a debian bug was filed21:30
jamSeems hard to build packages when you don't have python21:30
jelmerlooks like a cdbs problem to me..21:30
jelmerjam, it installs python2.5 but then tries to run python2.421:30
jelmerLarstiQ, probably21:31
jelmerjames_w, does the bzr-builddeb testsuite fail for you atm as well?21:35
james_wjelmer: which branch?21:35
jelmerjames_w, the main one21:35
james_wwhat's the failure?21:35
jelmera bunch of failures in the changelog parsing bits - apparently there's now two extra spaces and a newline21:36
jelmerand index out of range errors parsing the version21:37
james_wwhat's your python-debian version?21:38
jelmerii  python-debian                        0.1.11                              Python modules to work with Debian-related data formats21:38
james_wjelmer: yeah, I see that too21:42
jelmerjames_w, thanks for checking, I'll submit a fix for it21:43
jelmer... once I figure out what's actually going wrong21:53
jamjelmer: i386 just failed as well, do you want the log?21:55
jelmerjam: No, thanks. I just need to figure out how to fix this21:55
jelmerjam: Please merge again21:58
jelmerjam: I think the fix I applied now should take care of this21:59
jamjelmer: what am I merging?22:00
jamthe ~bzr/bzr-svn/hardy-ppa branch doesn't seem to have anything new yet22:00
jelmerjam: the bzr-svn debian branch, http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable22:00
jelmerjam: Ah, sorry22:00
jamah, I haven't merged that one yet22:00
jelmerthe hardy-ppa branch is based on it22:01
jamjelmer: well, merging that brought in about 50+ revisions22:06
jamis that expected?22:06
jamthough it only had 1 conflict in "changelog"22:06
jelmerjam: It's harmless, though not intentional22:07
jelmerI was playing with "bzr mu" in that branch22:07
jam"mu" ?22:09
jam(maintainer upload?)22:09
jamOr the Godel Escher Bach "not an op" mu22:09
LarstiQis that the same as the zen mu?22:10
jamGEB mu is the 'zen mu', yes22:10
jamIIRC, it has been a long time since I read it.22:11
jelmerjam: "bzr mu" is an alias for "bzr merge-upstream" from bzr-builddeb22:12
jamjelmer: So... I seem to be still exporting the same bzr-svn revision_id, is that correct?22:13
jelmerjam: Yep22:13
jamwhere is that set, by the way22:13
beunojam, hi!  Congrats on the 1.6 release!22:14
jamthanks beuno22:14
jamI'm putting together new docs that use bzr-builddeb22:14
jamShould be a lot easier22:14
beunodid you manage to package it?22:14
jamas it ends up being "run these 4 scripts"22:14
jambeuno: documenting as I package22:14
jamso I don't forget anything :)22:14
jambeuno: I have it in ~jameinel/+archive22:14
jamBut I'm documenting a proper version for ~bzr-beta-ppa22:15
beunojam, very cool. Let me install that and give it a spin...22:15
jamjelmer: I'm trying to upload again. Will I need to repackage with a foo....~2 ?22:16
jam(aka, bump the packaging number?)22:16
jelmerjam, not sure if ppa requires that22:16
jelmerjam, can't really hurt though22:16
jamwell, so far nobody has complained22:16
jambut I'll wait for ppa to tell me22:16
* jelmer has now reduced packaging a new upstream version to: "bzr mu -d <path> && bzr tag && bzr builddeb"22:17
mwhudsonso branching stacked branches over the hpss appears to have issues :(22:17
jammwhudson: good thing it isn't set up in the default branch format :)22:18
jammwhudson: is it because of format inconsistencies?22:18
jamthat the Smart Server always says it is the default format?22:18
jamor something along those lines22:18
mwhudsonjam: maybe, but i don't think so22:18
mwhudsonjam: let me set up a test again and -Dhpss it22:19
nanderssonSwedish Techmag TechWorld Open Source congrats on the 1.6 release :) Hope to see it in Hardy soon22:20
jamjelmer: I need to bump the number, otherwise the "md5" sum does not match one already in the archive22:20
jelmerjam: You'll need to bump the upstream version number actually22:21
jelmerjam, That's because of a bug in bzr export (which uses now() as the timestamp for all the files in the tarball)22:21
jelmerjam: Alternatively, you can use debuild rather than "bzr builddeb"22:21
jamjelmer: so I need to make rc1-2 ?22:23
jelmerjam: +1 probably ("-" is special)22:23
mwhudsonjam: http://pastebin.ubuntu.com/40506/22:24
jelmerso something like rc1+122:24
jamjelmer: can you spell it out for me22:24
jelmersomething like 0.4.11~rc1+1~bazaar1~hardy122:24
mwhudsonit seems maybe the fetch logic is busticated ?22:25
jammwhudson: of course, there you have 2 bzr processes fighting to log to ~/.bzr.log, which makes it a bit ugly22:25
mwhudsonjam: huh, indeed22:26
jamI would have thought that fetch() wouldn't actually fetch anything for a stacked branch22:26
jamso I'm not sure what is broken.22:26
mwhudsonwell, no, bzr branch stacked-branch local22:27
mwhudsonshould copy all the revision data into local22:27
jammwhudson: ah, you are branching *from* a stacked, and expecting it to pull everything from both22:27
mwhudsonjam: yes22:28
mwhudsonmaybe it's just a missing activate_fallback_repositories somewhere, i dunno22:28
jamwell, after I actually get these packages built, maybe I can poke at it a bit22:29
jelmerjam: sorry, something like 0.4.11~rc1+1-1~bazaar1~hardy122:32
jamjelmer: not rc1-1+1 ?22:32
jamI would think the official upstream number would come first22:32
jelmerjam: You need to update the upstream version number since every time you run "bzr builddeb" the timestamps in the upstream tarball change22:35
jamjelmer: I understand that, I'm just trying to understand debian version numbering22:35
jamand it seems like "rc1-1+1" would be better than "rc1+1-1"22:35
jambut my knowledge is *very* weak22:35
jelmereverything after the - is debian-specific22:36
jelmerthe stuff before the - refers to the upstream version22:36
jamand you need a new upstream version22:36
jamjelmer: of course now I get "no such tag ..." but i'll shove one in22:39
jamI assume we should use the same version again, right?22:39
jelmerjam: or specify --export-upstream-revision=tag:0.4.11~rc122:39
jelmersorry, --export-upstream-revision=tag:bzr-svn-0.4.11~rc122:39
jamjelmer: well, I went the tag route, since it makes it obvious what version is uploaded since the numbers don't match anymore.22:41
jamKind of odd to do "bzr tag -r tag:XXX XXX-1" :)22:41
jelmerheh :-)22:41
jamanyway, new packages are built and uploaded22:41
jamagain to ~jameinel/+archive, LP hasn't responded yet22:42
jamok, I'm currently uploading the bzr packages to ~jameinel/+archive22:48
jamUnfortunately, I'm likely to be done for the night (have to pick up my son now)22:48
jamSo if someone can play with them to make sure they are good22:49
jamand then I'll copy them to ~bzr-beta-ppa and ~bzr22:49
jambeuno: you may want to check out http://bzr.arbash-meinel.com/branches/bzr/1.7-dev/packaging22:50
jelmerlooks like it built succesfully22:50
jamjelmer: that is probably the one I uploaded this morning22:51
jamI'm doing all of gutsy/feisty/intrepid/etc right now22:51
jamI'm a bit worried about multple .orig.tar.gz uploads22:51
jelmerjam, I mean the new bzr-svn uploaded successfully22:51
jambut at least the md5 sum should match22:51
jamjelmer: ah yeah, I think that did22:51
jamit should be building22:51
jelmerjam: the export-upstream option in bzr-builddeb is the only bit that generates different tarballs each time22:52
jelmerjam: if you don't use that, you should not have any problems22:52
beunojam, the branch is enourmous. Does that include the bzr branch?22:57
beunoanyway, off to bed n' stuff22:59
jelmerbeuno, g'night23:00
jelmerbeuno, loggerhead is in NEW, btw, thanks to siretart23:00
beunojam, scripts look good  :)23:00
beunojelmer, really?  yay!23:01
beunodid -search get re-uploaded?23:01
beunojam, just need to feed the scripts the information instead of hard-coding it, and we're in business23:01
jelmerbeuno, no, Ididn't see a re-upload of search23:02
beunojelmer, I'll keep on insisting then. Thanks for the lh packaging  :)  I may upload it to bzr's PPA too, so we can update it more frequently23:03
jelmerhey lifeless23:15
mwhudsonhi lifeless23:17
jambeuno: what information is hard-coded in the scripts? You supply the version number23:24
jamI just give some help text so *I* can remember what format they should be in23:24
jamI guess I hardcode lp:~bzr/bzr/packaging-XXX23:28
jambut that is because those are the official locs23:28
jamthe files have been copied to ~bzr-beta-ppa, if people like them, I'll put them in ~bzr tomorrow (except bzr-svn)23:41
jelmerjam: cool23:41
ronnyi just started a merge, now i got some files with conflicts, is there any nice wrapper around fireing up kdiff3 or something like that23:48
bob2there's a plugin23:55
bob2merge-tool or something23:55
bob2oen sec23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!