| SmileyChris | how do I set up the default maintainer email so that "bzr send" doesn't need an email address? | 00:03 |
|---|---|---|
| lifeless | SmileyChris: according to the help, submit_to is the configuration key to set | 00:06 |
| SmileyChris | lifeless: yep, i got that far... how do you set configuration keys | 00:06 |
| SmileyChris | the help wasn't very clear on that | 00:07 |
| lifeless | the user guide has documentation about that | 00:07 |
| lifeless | basically just edit a config file depending on where you want the setting to apply | 00:08 |
| lifeless | globally/url/branch are the three choices | 00:08 |
| SmileyChris | lifeless: thanks for the explanation. So I can attach this setting to the branch itself or is it a client-side only configuration? | 00:12 |
| jelmer | Hmm, that reminds me | 00:13 |
| jelmer | I wonder if it makes sense to have a UI command for modifying the branch configuration? | 00:13 |
| jelmer | including some way to list the available settings | 00:13 |
| SmileyChris | hrm... i see there's a .bzr/branch/branch.conf - i wonder if that's where it should go | 00:14 |
| SmileyChris | the guide isn't very clear on this | 00:15 |
| jelmer | SmileyChris, yep, that's where it should be | 00:17 |
| SmileyChris | jelmer: cheers | 00:17 |
| SmileyChris | jelmer: does it need to be in a [DEFAULT] block? | 00:17 |
| jelmer | SmileyChris, yep | 00:17 |
| SmileyChris | good to know | 00:17 |
| SmileyChris | actually, i see in my local branch.conf there isn't a default block | 00:21 |
| SmileyChris | probably doesn't need it, it's a branch specific conf anyway | 00:21 |
| SmileyChris | :( bzr: ERROR: No mail-to address specified. | 00:25 |
| SmileyChris | seems it can't be server-side, unless i'm doing something wrong | 00:25 |
| SmileyChris | which is more than likely :P | 00:25 |
| jelmer | SmileyChris, it can be server side | 00:25 |
| jelmer | set child_submit_to on the server side | 00:25 |
| SmileyChris | ah | 00:25 |
| lifeless | only affects new branches though I believe | 00:34 |
| mwhudson | how do i create a branch of a particular format in a test? | 00:36 |
| mwhudson | make_branch only takes a format for the bzrdir, unless i'm misreading things | 00:36 |
| mwhudson | i guess make a bzrdir and initialize a branch of the desired format on it? | 00:38 |
| lifeless | mwhudson: format=knits etc | 00:42 |
| lifeless | mwhudson: tests/test_repository.py shows nearly every variation | 00:43 |
| lifeless | some fugly, some not | 00:43 |
| mwhudson | thanks | 00:45 |
| * mwhudson reads | 00:45 | |
| mwhudson | bzrdir.format_registry.get('knit')() seems reasonably clear for this purpose | 00:46 |
| lifeless | self.make_branch('foo', formamt='knit') is the most pithy | 00:46 |
| mwhudson | ok | 00:49 |
| markh | The 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 |
| lifeless | markh: its strictly accurate | 01:00 |
| lifeless | bound branches are still connected to a branch | 01:00 |
| markh | "source tree" implied "working tree" to me | 01:01 |
| markh | what is a "source tree"? | 01:01 |
| lifeless | I'd guess a tree you edit your code in ?:) | 01:01 |
| lifeless | note that a bound branch with no tree object is not a checkout of any shape or form | 01:01 |
| markh | hrmph - 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 |
| markh | so 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 |
| bob2 | bound branch + working tree = checkout | 01:06 |
| markh | right. 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 |
| markh | is there a ane usecase for a bound branch without a working tree? | 01:08 |
| markh | sane | 01:08 |
| lifeless | markh: yes | 01:22 |
| lifeless | markh: one in particular is quite fun: | 01:23 |
| lifeless | master | 01:23 |
| markh | how about s/sane/common/? | 01:23 |
| lifeless | mirror bound master (no tree) | 01:23 |
| lifeless | lightweight checkout of mirror | 01:23 |
| lifeless | I think that one is quite common for shared trunks | 01:23 |
| lifeless | on C style projects where you want only one tree and to reuse build products | 01:23 |
| markh | right - 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 |
| lifeless | markh: so that you can checkin to trunk when you want to, but still access what trunk looks like offline | 01:29 |
| markh | right - "mirror" is writable. | 01:30 |
| teratorn | does anyone use graphical diff/merge tools w/ bzr? if so, which ones? | 02:13 |
| AfC | teratorn: Not very often, but `meld` comes in handy once in a while. | 02:14 |
| teratorn | was just looking at meld.. gotta try it out | 02:14 |
| teratorn | ideally I would like a tool that can also let me do cherry-picking and then shelve or commit those selections | 02:14 |
| bob2 | emacs! | 02:15 |
| teratorn | huh what that's crazy talk | 02:40 |
| markh | I 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 |
| lifeless | a branchless tree does not exist | 03:39 |
| lifeless | to open a branch you must have a reository object | 03:39 |
| lifeless | to open a tree you must have a branch object | 03:39 |
| markh | right - "info" explicitly handles that case, but it should never hit it in real life? | 03:43 |
| markh | or only upon misused of that api I guess... | 03:44 |
| lifeless | the API won't let you construct this | 03:49 |
| lifeless | checkout --lightweight generates a branch references | 03:49 |
| markh | I 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 |
| Verterok | markh: ping | 05:00 |
| markh | Verterok: hi | 05:00 |
| Verterok | markh: hi | 05:00 |
| Verterok | markh: are you building the standalone bzr.exe? | 05:01 |
| markh | yep | 05:01 |
| Verterok | markh: I'm wondering if it's possible to include SimpleXXMLRPCServer in it | 05:03 |
| markh | Verterok: I'm sure it would be for 1.7 I guess. | 05:04 |
| Verterok | markh: some bzr.exe users, also use bzr-eclipse and xmloutput plugin (that need SimpleXMLRPCServer) | 05:04 |
| Verterok | great! | 05:04 |
| * Verterok dances | 05:04 | |
| Verterok | markh: if I can help, just drop me a line. I'll be glad to ;) | 05:06 |
| markh | how 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 |
| markh | I know - once 1.6 is out, just ping me and I'll hack up a binary and you can test it ;) | 05:07 |
| Verterok | markh: bzr branch lp:bzr-xmloutput and bzr start-xmlrpc :-D | 05:08 |
| markh | heh - ok | 05:08 |
| Verterok | markh: if that is the only py2exe trick, I can try to build a binary and run some tests | 05:08 |
| markh | its likely to also need 'xmlrpxlib' nominated in 'packages' | 05:09 |
| markh | rpclib | 05:09 |
| markh | it 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 |
| markh | but if you don't and I remember, I'll have a go when 1.7 is getting closer | 05:10 |
| Verterok | markh: I can try :). do I need a custom enviroment to build bzr.exe? | 05:10 |
| Verterok | markh: easier, any wiki/doc telling how to build it? :) | 05:11 |
| markh | theoretically not :) It might complain about a few things missing, but should succeed | 05:11 |
| markh | 'make installer' if you are *really* lucky ;) | 05:11 |
| markh | obviously need py2exe installed, but most other things are optional | 05:12 |
| * Verterok fires up virtualbox and waits | 05:12 | |
| markh | xmlrpclib appears to be a simple module and is already in the package. | 05:13 |
| markh | as is SocketServer - so if you are extremely lucky, you could just stick SimpleXMLRPCServer.pyo in library.zip and it would work ;) | 05:13 |
| Verterok | nice :) | 05:14 |
| Verterok | I'll give py2exe a try, if I'm lucky enough...I'll send the patch | 05:17 |
| Verterok | markh: thanks for the guidance :) | 05:20 |
| markh | np | 05:20 |
| Spaz | hello | 05:55 |
| Spaz | does bzr support checkouts of only portions of a source tree? or do you have to get the whole thing? | 05:56 |
| Spaz | i haven't been able to get a straight answer :/ | 05:56 |
| bob2 | no | 05:56 |
| bob2 | where source tree = branch | 05:56 |
| Spaz | we host multipule projects in our suppository, it would be possible to create branches for each of the projects, right? | 05:58 |
| Spaz | *repository | 05:58 |
| Spaz | i genuinely typo'd that >_> | 05:58 |
| bob2 | yes | 05:59 |
| Spaz | ah i see. | 05:59 |
| Spaz | bob2, and you can check out each branch independently if my understand is correct, right? | 05:59 |
| bob2 | yup | 05:59 |
| Spaz | horray | 05:59 |
| Spaz | thanks | 05:59 |
| Verterok | markh: bzr.exe with xmloutput, worked like a charm :D | 06:26 |
| markh | Verterok: excellent ;) | 06:27 |
| * Verterok sends the patch | 06:27 | |
| lifeless | Verterok: cool | 06:28 |
| Verterok | indeed :-D | 06:28 |
| * Verterok heads to bed | 07:04 | |
| Verterok | seeya later | 07:05 |
| lifeless | abada abada abada, thats all folks | 07:54 |
| vila | finally, hi all | 10:43 |
| Leonidas | How to get the changes from the initial revision? | 10:43 |
| Leonidas | (using the bzrlib api) | 10:43 |
| lifeless | Leonidas: current tree vs revision 1? | 10:45 |
| Leonidas | lifeless: but that does not show me what was added in revision 1. I need to use something like: | 10:45 |
| Leonidas | bzr diff -r ..1 | 10:45 |
| Leonidas | so I need the first revtree and the revision 1 revtree | 10:46 |
| lifeless | repository.revision_tree(NULL_REVISION) | 10:46 |
| Leonidas | ahh! Where is NULL_REVISION defined? | 10:47 |
| Leonidas | bzrlib.revision.NULL_REVISION, ok | 10:49 |
| === mark1 is now known as markh | ||
| === mark1 is now known as markh | ||
| jpds | Hello all, can someone please tell me what's happening here? http://paste.ubuntu.com/40393/ | 11:21 |
| Kamping_Kaiser | bad stuff :P | 11:25 |
| Kamping_Kaiser | (hi mate) | 11:25 |
| jpds | Kamping_Kaiser: hi. | 11:25 |
| RAOF | jpds: You can't upgrade over bzr+ssh | 11:34 |
| jpds | RAOF: So what do I do? | 11:35 |
| RAOF | jpds: 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 |
| RAOF | Be warned: remote upgrades over sftp aren't exactly lightning fast. Bring a packed lunch :( | 11:36 |
| Stavros | hello | 11:43 |
| Stavros | whenever 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 |
| luks | you want to upgrade to --rick-root-pack (probably) | 11:48 |
| luks | and corrupted repo in what way? | 11:48 |
| Stavros | luks: i move .bzr.backup back to .bzr and it doesn't recognise it as a repo | 11:50 |
| Stavros | so my only option then is to delete the whole thing | 11:50 |
| luks | "doesn't recognise" isn't very specific | 11:51 |
| Stavros | bzr: ERROR: Not a branch | 11:51 |
| luks | it upgrade corrupts anything it's a serious bug | 11:51 |
| Stavros | let me do it again | 11:51 |
| luks | what's inside the .bzr directory? | 11:51 |
| luks | *if | 11:51 |
| Stavros | let me reupgrade to tell you for sure | 11:52 |
| Stavros | oh it works now | 11:52 |
| Stavros | that's odd | 11:52 |
| Stavros | well, not the upgrade, but the backup | 11:52 |
| Stavros | is rich root pack better than the one i have currently? | 11:53 |
| Stavros | i don't understand why it fails, though | 11:53 |
| Stavros | it succeeded upgrading to that, if i push will the other repo also get upgraded? | 11:53 |
| bob2 | it isn't better | 11:54 |
| Stavros | why upgrade to that then? | 11:54 |
| bob2 | but if you need to support branches from bzr-svn, you need to use it | 11:54 |
| Stavros | oh | 11:54 |
| Stavros | is it worse? | 11:54 |
| bob2 | no | 11:54 |
| Stavros | ah, okay then | 11:55 |
| bob2 | it just supports a feature needed by bzr-svn | 11:55 |
| Stavros | ah | 11:55 |
| bob2 | eventually the default format will support something like that too and everyone will stop getting confused :) | 11:55 |
| luks | Stavros: and no, push will not upgrade it | 11:55 |
| Stavros | luks: ah, thanks | 11:56 |
| === mark1 is now known as markh | ||
| Spaz | hello | 12:14 |
| Spaz | i'm made a branch trunk/foo, but when i go to do something like bzr co http://example/trunk, foo doesn't show up | 12:15 |
| lifeless | if your branch is trunk/foo, you should checkout trunk/foo :) | 12:16 |
| Spaz | lifeless, i want the whole thing though (trunk/foo included) | 12:16 |
| luks | no, it doesn't work like svn | 12:17 |
| Spaz | :( | 12:17 |
| Spaz | is there any way i can make a branch that behaves that way? | 12:17 |
| lifeless | Spaz: you want a branch that contains other branches? | 12:17 |
| Spaz | lifeless, yes, but i want those branches to also be able to be checked out not just individually, but all at once | 12:17 |
| lifeless | Spaz: bzr really isn't gear to do that | 12:18 |
| lifeless | *geared* | 12:18 |
| Spaz | :( | 12:18 |
| lifeless | (none of the modern DVCS's are) | 12:18 |
| RAOF | "bzr multi-pull" can help. | 12:18 |
| RAOF | On the client side, at least. | 12:19 |
| Spaz | RAOF, is this a plugin of sorts? | 12:19 |
| luks | lifeless: well, git and hg can do that, but it's not as streamlined as in svn | 12:20 |
| RAOF | It's in bzrtools, I believe. | 12:20 |
| RAOF | bzr multi-pull will pull all the branches under the current directory. At least that's how I use it :) | 12:20 |
| luks | having a bzr extension that does something like http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html would be nice | 12:20 |
| RAOF | Isn't that subtree support? | 12:20 |
| Spaz | another question | 12:20 |
| lifeless | luks: they don't do the same thing | 12:21 |
| RAOF | I may have got that wrong, though. | 12:21 |
| lifeless | luks: gits nested tree is similar to bzr's, hg's is very different | 12:21 |
| Spaz | wait nvm | 12:21 |
| lifeless | luks: and none are analagous to svn's system | 12:21 |
| Spaz | i was going to ask if bzr had plans for arbitrary checkouts, but i'll just use nested branches for now | 12:21 |
| luks | lifeless: git's submodules are not bound to specific revision, as far as I know | 12:21 |
| lifeless | luks: they are refs | 12:22 |
| luks | so it works kind of like svn:externals | 12:22 |
| RAOF | Ah, so submodules appear to be svn externals. Which isn't what he's after, anyway. | 12:22 |
| Spaz | bzr multi-pull works :) | 12:22 |
| lifeless | luks: "Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit." | 12:22 |
| luks | uh oh | 12:22 |
| luks | sorry then | 12:22 |
| lifeless | its ok :) | 12:22 |
| luks | so it's the same principle as bzr subtrees, but not as integrated | 12:23 |
| Spaz | while it's kind of an "argh >_<" thing for me, it's not like "argh let's go back to svn" kind of thing | 12:23 |
| lifeless | but I'm not prone to random wrong statements:> | 12:23 |
| lifeless | actually I think git and bzr subtrees/submodules will be nearly identical | 12:23 |
| lifeless | we've got very similar model in this regard | 12:23 |
| luks | I'd like more something like svn externals | 12:23 |
| lifeless | yeah, we have a second iteration planned that will be closer | 12:24 |
| lifeless | Spaz: we have plans for arbitrary checkouts | 12:24 |
| luks | shouldn't be hard to do as a plugin using git submodule's UI though | 12:24 |
| Spaz | lifeless, :o | 12:24 |
| lifeless | Spaz: 'views' is what we'll call them | 12:24 |
| Spaz | hrm views? | 12:25 |
| Spaz | sounds like it's read-only | 12:25 |
| Spaz | >_> | 12:25 |
| lifeless | no more than any other operation | 12:25 |
| Spaz | oh nice | 12:25 |
| lifeless | it will just select a subset of the tree to put on disk | 12:26 |
| Spaz | :D | 12:26 |
| lifeless | the same amount of history will be needed locally etc etc | 12:26 |
| Spaz | ah ok | 12:26 |
| lifeless | because to merge full trees you need access to the full tree metadata | 12:26 |
| Spaz | any 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 |
| lifeless | its *why* DVCS works efficiently | 12:26 |
| lifeless | 1.8/1.9 | 12:26 |
| Spaz | ah ok | 12:27 |
| enquest | can 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 |
| lifeless | enquest: permissions I would say | 12:35 |
| lifeless | enquest: does he have write permission ? | 12:35 |
| enquest | I made a group "admin" and added him and me to that group | 12:35 |
| enquest | what should I do more? | 12:36 |
| lifeless | check the permissions on the contents of .bzr/ | 12:36 |
| lifeless | I bet its wrong group or some such | 12:36 |
| enquest | lifeless, the permissions on the .bzr is drwxr-xr-x | 12:37 |
| enquest | and enquest:admin | 12:38 |
| enquest | so I should give write permissions to admin? | 12:38 |
| enquest | is that correct lifeless | 12:39 |
| lifeless | I would say so :) | 12:42 |
| stani | hi | 12:51 |
| stani | The 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 |
| luks | I don't know of anything that has a smart delta compression of compressed data | 12:54 |
| stani | luks: 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 |
| luks | there are systems that handle binary data better in general | 13:00 |
| luks | but for compressed content, such as images or video, it doesn't help much | 13:00 |
| stani | luks: are some of these systems free? could you give some names? | 13:02 |
| luks | svn does binary xdelta compression | 13:02 |
| luks | but what exactly are you doing? | 13:03 |
| stani | well, I am a visual artist, so the result of my projects consist of images | 13:04 |
| stani | some are generated by self written code, some are manipulated in gimp, ... | 13:04 |
| luks | what format are they in? | 13:05 |
| stani | I mostly use png for generated images, as it is compressed without quality loss | 13:06 |
| luks | anyway, I don't think you will see any significant differences between most VCSes | 13:06 |
| stani | but some are also in svg | 13:06 |
| bob2 | are svg files typically gzipd? | 13:07 |
| luks | no | 13:07 |
| stani | I generate svg through pycairo | 13:08 |
| luks | I'd personally just use bzr if you already know it | 13:09 |
| luks | I wouldn't use bzr only if the files are huge | 13:10 |
| luks | it doesn't handle that well | 13:10 |
| === andreas__ is now known as ahasenack | ||
| bjacques | Hi. 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 |
| luks | not sure what do you mean by that | 13:28 |
| luks | that is 'the main repository'? | 13:28 |
| luks | *what | 13:28 |
| bjacques | by main repository I mean the remote, shared repository which contains the trunk branch | 13:29 |
| luks | just push it there | 13:29 |
| luks | if you push it to a location under the repository, it will automatically use it | 13:29 |
| bjacques | I see, thank you | 13:29 |
| bjacques | So do I specify bzr push sftp://remote/reporoot/mynewbranch or do I omit "mynewbranch"? | 13:31 |
| luks | including mynewbranch, the command is correct | 13:31 |
| bjacques | thanks again | 13:32 |
| === thunderstruck is now known as gnomefreak | ||
| cfchris6 | I 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.html | 14:16 |
| luks | you need newer bzr | 14:17 |
| cfchris6 | luks: 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.0 | 14:18 |
| luks | 1.5, probably | 14:18 |
| luks | looks like a lie :) | 14:18 |
| luks | hm, no | 14:19 |
| cfchris6 | looks like the personal taste of gentoo developers prevented a stable program to get into stable tree, once more :/ | 14:19 |
| luks | iter_ancestry was added earlier | 14:19 |
| cfchris6 | hm... | 14:19 |
| luks | still worth a try to upgrade | 14:19 |
| luks | there is a bzr overlay for gentoo | 14:19 |
| pickscrape | https://launchpad.net/bzr-gentoo-overlay/ | 14:20 |
| cfchris6 | bzr 1.5 is already in the portage tree, but tagged as ~x86 not x86 | 14:21 |
| pickscrape | Easy to just add it to portage.keywords | 14:21 |
| cfchris6 | I know gentoo, and I did so, but it is not a nice solution because mixing arch with ~arch sometimes breaks things | 14:22 |
| pickscrape | My package.keywords is as long as my arm :) | 14:23 |
| pickscrape | I prefer to use stable generally, but push certain things along as I need them. | 14:23 |
| luks | what does the ~ mean? | 14:24 |
| pickscrape | arch-masked | 14:24 |
| pickscrape | Effectively the 'unstable' branch | 14:24 |
| luks | so, "doesn't work on x86"? | 14:24 |
| pickscrape | More like they're not confident, not sufficiently tested, they can't be arsed etc | 14:25 |
| pickscrape | gnome basically stays in ~ for about six months after release | 14:26 |
| cfchris6 | pickscrape: 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 anymore | 14:26 |
| pickscrape | cfchris6: == can't be arsed :) | 14:27 |
| Freaky | just ~x86? what about all the other platforms? | 14:27 |
| cfchris6 | Freaky: In general it was ~arch, for more exotic ones I don't know | 14:28 |
| pickscrape | Other 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 |
| cfchris6 | anyway, with bzr-1.5 it works now, thank you | 14:30 |
| pickscrape | The only downside of the bzr gentoo overlay is that it includes beta packages. It would be nice to have a stable version of the overlay | 14:32 |
| * vila wonders who put water into his gusty -> hardy upgrade after midnight | 14:50 | |
| jam | vila: I put sugar in the tank, but I didn't have time to get water. Must have been someone else. | 14:50 |
| vila | I guess so, but the last gremlin needed a .xmodmaprc to get killed. though one :-/ | 14:51 |
| pickscrape | Check the power cord to your clock. | 14:52 |
| vila | lightbulb ! The clock damn it ! Skewed again ! | 14:52 |
| jam | vila: I'm just waiting for your next hhtp patch | 14:53 |
| vila | :-) | 14:53 |
| jam | hm... it seems beuno isn't around yet | 14:53 |
| jam | time to get the 1.6-final out the door | 14:53 |
| jam | anyone have any blockers? | 14:53 |
| jam | Last chance | 14:53 |
| vila | the last days were all about reorganizing my hardware and the associated softs, I just have to commit now. | 14:55 |
| jelmer | siretart, thanks, much appreciated :-) | 15:02 |
| * jelmer hopes this is also the first step towards loggerhead on bzr.debian.org.. | 15:03 | |
| james_w | jelmer: well, we almost got webserve on there, but it missed etch, and then the project seemed to stall, so I refrained from packaging it | 15:06 |
| jelmer | ahh | 15:08 |
| jelmer | so it looks like we'll be out of luck again, since we're already past freeze time :-/ | 15:09 |
| james_w | yeah, though they may be willing to use a backport once it is actually in | 15:09 |
| === cody-somerville_ is now known as cody-somerville | ||
| jelmer | james_w: ah, cool, that's definitely worth asking for | 15:15 |
| james_w | I agree | 15:16 |
| siretart | jelmer: I think they prefer packages from backports.org, but asking might be a good idea anyway | 15:17 |
| jelmer | bug 5 | 16:07 |
| ubottu | Launchpad bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] https://launchpad.net/bugs/5 | 16: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/ | ||
| luks | yay :) | 17:50 |
| luks | no more RCs | 17:50 |
| radix | whoah | 17:50 |
| Peng_ | Woah. | 17:51 |
| Peng_ | Wait, so there was no rc7? Damn! | 17:51 |
| Peng_ | Congrats on the release. :) | 17:51 |
| * Peng_ has to run. | 17:51 | |
| RichW | I'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 |
| RichW | It gives me this error: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 17:58 |
| jelmer | RichW, the two branches you're trying to merge are not related | 18:10 |
| jelmer | RichW, are you really sure you'd like to merge them? | 18:11 |
| jelmer | RichW, if so, just specify -r0..-1 to "bzr merge" | 18:11 |
| * mw starts his bzr 1.6 for opensuse packages | 18:14 | |
| jam | So... what is the proper debian string for the 1.6 release? | 18:14 |
| jam | "1.6~bazaar1" sorts before "1.6~rc5..." | 18:15 |
| jam | Should it be "1.6-1~bazaar1" | 18:15 |
| luks | 1.6-1~bazaar1 | 18:15 |
| jam | or "1.6~1~bazaar1" ? | 18:15 |
| jam | thanks luks | 18:15 |
| luks | 1.6~bazaar1 would mean a native debian package | 18:16 |
| elmo | err, surely it's just 1.6-1 ? | 18:16 |
| luks | yes, but not for ppa packages | 18:16 |
| elmo | oh, right, PPA | 18:17 |
| RichW | jelmer: ok il try it, some things happened and it all went wrong :) | 18:19 |
| luks | RichW: honestly, with such branches I think diff/patch is the best you can do | 18:20 |
| jam | luks: ok, I tried your method to build the package, care to try it out? | 18:23 |
| jam | It is in my ppa | 18:23 |
| luks | one sec | 18:23 |
| jam | https://launchpad.net/~jameinel/+archive | 18:23 |
| luks | did you upload the packages? | 18:23 |
| * luks doesn't see them | 18:24 | |
| jam | jelmer, james_w: If you want to give it a poke, too. I'm using bzr-debbuild for this | 18:24 |
| jam | luks: upload just finished | 18:24 |
| luks | ah, it will take a moment then | 18:24 |
| jelmer | jam: I just uploaded 1.6-1 to Debian sid | 18:24 |
| jelmer | s/sid/experimental | 18:25 |
| jelmer | jam: What branch is the ppa build created from? I can't instal the package here, but I can look at the changes. | 18:25 |
| jam | jelmer: it is built from the tarball | 18:26 |
| jam | Or you mean the "debian" branch? | 18:26 |
| jam | I just have that locally | 18:26 |
| jelmer | jam: yeah, the debian branch | 18:26 |
| jam | It is originally branched from luks work | 18:27 |
| jam | because I'm just playing with it for now | 18:27 |
| jam | I'll switch to the "official" ones later | 18:27 |
| jam | jelmer: I'll push it real quick | 18:27 |
| luks | well, I didn't change anything but fixing the watch files | 18:27 |
| jam | jelmer: when it finishes: lp:~jameinel/+junk/packaging-hardy | 18:28 |
| * jelmer wonders if the ppa branch shares any ancestry with the pkg-bazaar debian team branch | 18:28 | |
| jam | luks: well, and you "released" ~bazaar2 | 18:28 |
| jam | etc | 18:28 |
| jelmer | jam, thanks | 18:28 |
| luks | oh, yes :) | 18:28 |
| jelmer | ah, looks like it was based on the Debian packaging branch, it's just diverged since then | 18:29 |
| jam | luks: LP has just accepted my submission and is building now | 18:29 |
| jam | jelmer: seems like we should mostly keep them in sync | 18:29 |
| jam | lamont: 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 |
| lamont | jam: my build just finished. :-) | 18:30 |
| jam | luks: 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 |
| jam | luks: I'm trying to use your documentation | 18:31 |
| jam | but it seems ZSH doesn't do "for" like bash/sh | 18:31 |
| lamont | jam: gives me 3 lines of output.... | 18:32 |
| jelmer | jam, package looks good to me | 18:32 |
| jam | lamont: I don't know if that is good or bad | 18:33 |
| lamont | jam: it's correct. :-) | 18:34 |
| lamont | and yeah, package looks fine | 18:34 |
| jam | yay \o/ | 18:34 |
| lamont | the 3 lines was wrt $FOO above | 18:34 |
| jelmer | jam, there's not a lot of differences with the debian debian package | 18:34 |
| jam | lamont: using zsh or bash? | 18:34 |
| jelmer | jam, (try diffing with http://bzr.debian.org/pkg-bazaar/bzr/unstable to see) | 18:34 |
| jam | jelmer: 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 changelog | 18:36 |
| jam | So it only has your changes | 18:36 |
| jam | jelmer: also, do you still have the "contrib/bash/bzr" bug? | 18:37 |
| jam | I see this line: contrib/bash/bzretc/bash_completion.d/ | 18:37 |
| jam | in your unstable branch | 18:37 |
| jelmer | no, that's been fixed (though differently from the ppa branch) | 18:38 |
| jam | ah, ok | 18:38 |
| jam | ah, and you don't remove ones that are already there | 18:38 |
| jam | as part of post-install | 18:38 |
| jelmer | We never uploaded a package with the broken file in it, so there's no need to do that for us | 18:39 |
| jam | jelmer: should we be merging your changes for stuff like "overrides/bzr" which sets "script not executable" on a few files | 18:39 |
| jelmer | jam: Yeah - the overrides are no longer necessary | 18:40 |
| lamont | jam: bash | 18:40 |
| jelmer | you 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 itself | 18:40 |
| jam | so for changelog, is it meant to be only the changes for that "branch" of packaging? | 18:40 |
| jam | jelmer: I think luks did a similar change | 18:41 |
| jam | opts="uversionmangle=s/(rc|b)/~$1/" \ | 18:41 |
| jelmer | ah, right | 18:41 |
| jelmer | jam: I'm not sure what the right policy is wrt merging changelogs | 18:41 |
| radix | does anyone know if launchpad supports stacked branches now? (no response in #launchpad) | 18:41 |
| lamont | jam: IOW, zsh isn't posix. | 18:41 |
| lamont | see also the behavoir of dash | 18:42 |
| jam | lamont: it seems like it, though it is a bit odd | 18:42 |
| jam | lamont: it prints it out 3 times for me | 18:42 |
| jam | It prints "a b c" 3 times | 18:42 |
| jam | which is a bit silly | 18:42 |
| jam | ah no, that was because I was using: FOO='a b c' | 18:43 |
| jam | and bash does the same | 18:43 |
| jam | This is just strange: bash -c "FOO='a b c'; for x in $FOO; do echo $x; done" | 18:43 |
| lamont | in zsh I get 'a b c' | 18:44 |
| lamont | in dash and bash, I get a\nb\nc\n | 18:44 |
| jam | yeah, 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 |
| lamont | scripts shouldn't use zsh :-) | 18:45 |
| fullermd | Unless they're zsh scripts ;) | 18:45 |
| lamont | if you need that rich a language, you don't belong in a shell | 18:46 |
| jelmer | radix, I think so | 18:46 |
| jelmer | radix, It is running bzr 1.6 IIRC | 18:46 |
| jam | lamont: 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 that | 18:47 |
| lamont | heh | 18:47 |
| jam | such as by turning it *into* a script :0 | 18:48 |
| lamont | FTW! | 18:48 |
| gour | congrats to all devs for 1.6! | 18:48 |
| gour | jelmer: bzr-svn will follow-up shortly? | 18:49 |
| jelmer | gour, 0.4.11~rc1 is already in Debian | 18:49 |
| jelmer | or do you mean the 0.4.11 release? | 18:49 |
| jam | jelmer: can we get 0.4.11 into the bzr ppa/beta ppa? | 18:50 |
| gour | jelmer: 0.4.11 | 18:50 |
| jelmer | gour, In the next couple of dayus | 18:50 |
| gour | great. ta | 18:50 |
| gour | it no longer requires svn-1.5? | 18:51 |
| jelmer | no, just svn 1.4 or higher | 18:51 |
| jelmer | no patches | 18:51 |
| gour | that's great | 18:51 |
| jelmer | jam: Sure, I'm happy to help with that | 18:51 |
| jam | We'd also like to get bzr-gtk put there | 18:52 |
| gour | finally, one will be able to completely replace fetching all svn repos with bzr-svn :-) | 18:52 |
| jam | whatever works with 1.6 | 18: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 |
| gour | bzr will return to monthly-releases now? | 18:53 |
| jam | gour: well I'm in charge of 1.7, so *it* will be a time-release, I can't say beyond that :) | 18:53 |
| jam | I do believe everyone wants to return | 18:53 |
| lamont | jam: increasing chunks in time is always a good merge there... shame to lose history, unless it's pointless history | 18:54 |
| jelmer | jam: I would rather not do the uploads myself though, since I can't promise I'll be able to upload regularly | 18:54 |
| lamont | for my packages, I tend to just not change debian/changelog, and then generate it at release time... less pain that way | 18:54 |
| lamont | since debian/changelog _never_ merges cleanly | 18:54 |
| gour | jam: thank you for great work. i'm (slowly) learning python..hopefully be able to help a bit in the future | 18:54 |
| lamont | (for values of never approaching zero) | 18:54 |
| jam | jelmer: 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 |
| jam | lamont: well all of our "debian/changelog" entries are "* New upstream release" | 18:55 |
| jelmer | jam, should we have a look at doing that now? | 18:55 |
| gour | it's interesting experience to switch between haskell & python... | 18:55 |
| jam | And we have one entry for each ~hardy1, ~gutsy1, etc. | 18:55 |
| jam | jelmer: That would be nice. I'd like to get bzr-1.6 and associated plugins | 18:55 |
| jam | Everyone complains when they go to upgrade bzr and lose all of their deps | 18:55 |
| lamont | jam: 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 |
| lamont | although more so if they have more meat to them than "new upstream release" | 18:57 |
| jam | lamont: that is what "bzr log --short" is for :) [or NEWS] | 18:58 |
| jelmer | jam: Pushing to ~bzr/bzr-svn/ppa-hardy | 18:59 |
| === fta_ is now known as fta | ||
| jelmer | jam: Can you see if that uploads correctly to ppa? | 18:59 |
| lamont | jam: bzr log | 19:00 |
| lamont | bzr: ERROR: Not a branch: "/home/lamont/chroots/a/bzr-1.6~rc5/". | 19:00 |
| lamont | changelogs _should_ have some history in them. source packages _shouldn't_ have VCS trees in them. | 19:01 |
| jam | jelmer: so you want me to package that? or just check if a package shows up in ~bzr/+archive ? | 19:02 |
| lamont | then again, I expect that the upstream changelog is in the binary package | 19:02 |
| jelmer | jam: It should already be packaged for hardy in the ppa | 19:02 |
| jam | jelmer: the only package I see is: https://edge.launchpad.net/ubuntu/hardy/+source/bzr-svn | 19:04 |
| jelmer | jam: It's finished now, lp:~bzr/bzr-svn/hardy-ppa | 19:04 |
| jam | and ~bzr-svn doesn't have a ppa | 19:05 |
| jelmer | jam: Sorry, I meant I hadn't uploaded it yet, but all the right bits are in the bzr branch I pushed to | 19:05 |
| jam | jelmer: so you want me to "bzr debbuild -S" it ? | 19:06 |
| jelmer | jam, yep, please | 19:06 |
| jam | (currently grabbing it) | 19:06 |
| jam | should I be uploading to the ~bzr-beta-ppa or is it ready for ~bzr ? | 19:07 |
| jelmer | To whatever you uploaded 1.6 I think | 19:07 |
| jam | jelmer: sure I just wanted to know if it was "stable" enough for the official ppa | 19:08 |
| jam | I haven't uploaded anything to a public ppa yet | 19:08 |
| jelmer | jam: Probably beta for now then | 19:10 |
| jam | and that is a regular bzr-svn branch right, not just a packaging branch | 19:10 |
| jam | how do you manage that across multiple targets? | 19:10 |
| jelmer | jam: It's a regular bzr-svn branch that includes the debian/ dir | 19:10 |
| jelmer | makes it easier to do debian-specific source changes | 19:10 |
| radix | I guess the bzr deb packages aren't built yet? | 19:28 |
| jelmer | radix, jam is working on uploads to the ppa | 19:32 |
| radix | sweet | 19:33 |
| radix | thank you jam :) | 19:33 |
| jelmer | radix, I've uploaded packages to debian experimental | 19:33 |
| radix | can't wait to try it out with lp | 19:33 |
| james_w | jelmer: did you file a sync request as well by any chance? | 19:33 |
| jelmer | james_w, not yet - shouldn't I wait for it to actually hit experimental? | 19:34 |
| james_w | jelmer: it's normally safe as they have to get a sponsor's ACK first | 19:34 |
| jelmer | james_w, ah, cool - I'll request one then | 19:35 |
| * jelmer hugs ubuntu-dev-tools | 19:35 | |
| jelmer | now if only somebody would package it for debian... | 19:35 |
| Spaz | night | 19:45 |
| jelmer | james_w: I've modified "bzr mu" to support merging from branches rather than just tarballs/directories | 20:05 |
| jelmer | james_w, It'll now also default to using the export-upstream location if in export-upstream mode | 20:06 |
| jelmer | james_w, and retrieve the upstream version number automatically from tags and revnos | 20:07 |
| jelmer | james_w, It would be nice though if it could automatically add a draft entry to debian/changelog though | 20:07 |
| ToyKeeper | Is there a recommended bzr way to include one project inside another? (for example, project/mylib/ has its history tracked separately) | 20:12 |
| jelmer | ToyKeeper, "bzr join" can import one project in another and makes merging in the future easier | 20:12 |
| jelmer | ToyKeeper, there's no way to reference another project by location yet - that's what nested branches will bring | 20:13 |
| ToyKeeper | I 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 |
| ToyKeeper | Bringing the lib in at 'make dist' time is trivial, at least. | 20:14 |
| jam | You 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_w | jelmer: yeah, it doesn't do that for any mode | 20:18 |
| james_w | I stayed away from writing more code | 20:18 |
| ToyKeeper | I 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 |
| jelmer | james_w: It suggests the right command to run, but I'm getting very lazy :-) | 20:19 |
| ToyKeeper | Hmm, 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 |
| jelmer | ToyKeeper, if it's a subdir, I would recommend using bzr join | 20:25 |
| ToyKeeper | Yeah, I'm just trying to figure out how to merge changes after the initial join. | 20:28 |
| jelmer | just "bzr merge <location>" should work I think | 20:28 |
| ToyKeeper | Nope. | 20:29 |
| ToyKeeper | Maybe it's supposed to, though. I'm getting a traceback when I try. | 20:30 |
| lamont | jam: 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 |
| ToyKeeper | looks like the same thing as bug 203376 | 20:53 |
| ubottu | Launchpad bug 203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376 | 20:53 |
| ToyKeeper | Weird. 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 |
| ToyKeeper | It seems like it's been broken since bzr 1.2 or maybe earlier. | 20:59 |
| === maw_ is now known as mw | ||
| jam | lamont: :) no, have a couple other things I'm trying to get out, and then I'll upload | 21:04 |
| jam | jelmer: hardy-ppa wants to sign the archive with *your* key, does that matter? | 21:04 |
| lamont | jam: no worries... if you happen to feel like it, poke me with something pointy when you upload, eh? | 21:05 |
| lamont | jam: debsign -m$yourkey foo_ver_source.changes | 21:05 |
| jam | lamont: well, there is one in https://launchpad.net/~jameinel/+archive but I should have 1.6 final uploaded to ~bzr in about an our | 21:05 |
| jam | *hour* | 21:05 |
| jelmer | jam: You should probably just sign it with yours | 21:05 |
| jam | jelmer: builddeb doesn't like that | 21:05 |
| lamont | jam: -m | 21:05 |
| jam | jelmer: And I'm not enough of a deb guru to really know the point to do it at. | 21:06 |
| lamont | to override the maintainer in debuild | 21:06 |
| jelmer | jam, Perhaps just change the name in the last entry in debian/changelog | 21:06 |
| lamont | jelmer: 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 | |
| jam | Well, builddeb defaults to -uc -us | 21:08 |
| jam | But the config that luks suggested has me configure it to actually sign them. | 21:08 |
| jam | Does LP require signing? | 21:08 |
| jam | I know it doesn't sign the binary packages | 21:08 |
| jelmer | jam, it requires signing on uploaded source packages I think | 21:08 |
| === toytoy_ is now known as toytoy | ||
| jam | jelmer: 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 |
| jelmer | jam: Yep, use --export-upstream=../path/to/local | 21:11 |
| jam | jelmer: thanks, that helps a lot. Now... what about APR? | 21:12 |
| jam | It seems to cause a warning | 21:12 |
| jam | but doesn't actually fail the build process | 21:12 |
| jelmer | jam: What sort of warning? | 21:12 |
| jam | jelmer: "make" seems to be failing | 21:12 |
| jelmer | in what way? | 21:13 |
| jam | Exception: apr-config not found. Please set APR_CONFIG environment variable | 21:13 |
| jam | make: [python-clean-2.5] Error 1 (ignored) | 21:13 |
| jam | cd . && python2.4 setup.py clean -a | 21:13 |
| jam | sh: apr-config: not found | 21:13 |
| jam | jelmer: but it doesn't actually stop the build | 21:13 |
| jam | I'm installing libapr1-dev now | 21:13 |
| jelmer | jam, Oh, that's actually correct | 21:14 |
| jelmer | it should be a little bit less verbose | 21:14 |
| jam | now, of course, it needs the svn devel files | 21:14 |
| jelmer | there's different names the apr config utility can have | 21:14 |
| jelmer | the first name in the list doesn't exist on your system, but the second one probably does | 21:14 |
| jam | jelmer: well, I didn't have the libapr1-dev at all | 21:14 |
| jam | installing it made it happy | 21:14 |
| jam | my bigger problem is that the build should *fail* | 21:15 |
| jelmer | jam, You do have libapr-dev probably | 21:15 |
| jam | if it can't actually build | 21:15 |
| jam | I didn't have libsvn-dev or libapr1-dev | 21:15 |
| jam | I don't know if you still need svn-dev | 21:15 |
| jam | but the build process *thinks* it does | 21:15 |
| jelmer | yeah, you need libsvn-dev | 21:15 |
| jam | jelmer: so there seems to be a problem that "make" isn't causing the builddeb process to fail | 21:16 |
| jam | so I would probably have built a bogus patch if I didn't check the traceback | 21:16 |
| jelmer | jam: I don't think it should've failed | 21:16 |
| jelmer | jam: It searches for apr-config first, then apr-1-config | 21:16 |
| jam | jelmer: why is that, or more importantly, why do you need to do make if you don't need it to succeed | 21:17 |
| jam | jelmer: I didn't have svn-dev either. I'm pointing out that "make" failed, but builddeb did not | 21:17 |
| jelmer | ahhh | 21:17 |
| jam | It seemed to think the package was fine | 21:17 |
| jelmer | jam, it was the clean step that failed | 21:18 |
| jelmer | that's probably allowed by cdbs | 21:18 |
| jelmer | jam, not the build step | 21:18 |
| jam | ah | 21:19 |
| jam | ok | 21:19 |
| jam | well, installing libapr1-dev and libsvn-dev and it builds "cleanly" so I'll stick with that for now | 21:19 |
| jam | lamont, jelmer: 'dput' requires the file to be signed. Thanks for giving me the "debsign -mXXXX" command | 21:21 |
| lamont | jam: dput, and the backend processing both. :- | 21:21 |
| lamont | ) | 21:21 |
| jam | jelmer: your .debs have been uploaded to ~jameinel/+archive, I imagine it will be a little while for them to build and be available | 21:21 |
| jelmer | jam: cool | 21:22 |
| jam | jelmer: I can copy them to ~bzr-beta-ppa if you want to give them a once over and make sure they are valid | 21:22 |
| lamont | and clean failing isn't necessarily an error... although it does bear wondering about | 21:22 |
| jam | jelmer: also, what about builds for ~gusty and ~intrepid? | 21:22 |
| jam | and even ~dapper | 21:22 |
| jelmer | jam: sounds like a good idea to me :-) | 21:23 |
| jam | jelmer: I just don't know what it actually *entails* I get the branches handed to me for bzr | 21:23 |
| jam | my deb-fu is *very* week | 21:23 |
| jam | weak | 21:23 |
| jelmer | jam: 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/changelog | 21:24 |
| jam | jelmer: ppa just accepted my submission | 21:25 |
| jam | also, what do you guys think. Should these be ~bzr/bzr/packaging-hardy, or should they be ~bzr/bzr-packaging/hardy branches? | 21:26 |
| jam | As it is just the "debian" directory, they seem like they should be separate branches | 21:26 |
| jam | But someone mentioned that most of the "ubuntu" packages are not done that way. | 21:26 |
| jam | (separate projects) | 21:26 |
| jelmer | in the case of bzr-svn, it really is a bzr-svn branch | 21:28 |
| jelmer | in the case of bzr, I would prefer seeing that move to the same approach as bzr-svn >-) | 21:29 |
| jam | jelmer: "packages failed to build" for amd64 | 21:29 |
| jam | http://launchpadlibrarian.net/17067514/buildlog_ubuntu-hardy-amd64.bzr-svn_0.4.11%7Erc1-1%7Ebazaar1%7Ehardy1_FAILEDTOBUILD.txt.gz | 21:29 |
| jam | /bin/sh: python2.4: not found | 21:30 |
| jelmer | hmm same thing for which a debian bug was filed | 21:30 |
| jam | Seems hard to build packages when you don't have python | 21:30 |
| jelmer | looks like a cdbs problem to me.. | 21:30 |
| jelmer | jam, it installs python2.5 but then tries to run python2.4 | 21:30 |
| jam | weird | 21:30 |
| LarstiQ | python-central/foo? | 21:31 |
| jelmer | LarstiQ, probably | 21:31 |
| jelmer | james_w, does the bzr-builddeb testsuite fail for you atm as well? | 21:35 |
| james_w | jelmer: which branch? | 21:35 |
| jelmer | james_w, the main one | 21:35 |
| james_w | what's the failure? | 21:35 |
| jelmer | a bunch of failures in the changelog parsing bits - apparently there's now two extra spaces and a newline | 21:36 |
| jelmer | and index out of range errors parsing the version | 21:37 |
| james_w | what's your python-debian version? | 21:38 |
| jelmer | ii python-debian 0.1.11 Python modules to work with Debian-related data formats | 21:38 |
| james_w | jelmer: yeah, I see that too | 21:42 |
| jelmer | james_w, thanks for checking, I'll submit a fix for it | 21:43 |
| jelmer | ... once I figure out what's actually going wrong | 21:53 |
| jam | jelmer: i386 just failed as well, do you want the log? | 21:55 |
| jelmer | jam: No, thanks. I just need to figure out how to fix this | 21:55 |
| jelmer | jam: Please merge again | 21:58 |
| jelmer | jam: I think the fix I applied now should take care of this | 21:59 |
| jam | jelmer: what am I merging? | 22:00 |
| jam | the ~bzr/bzr-svn/hardy-ppa branch doesn't seem to have anything new yet | 22:00 |
| jelmer | jam: the bzr-svn debian branch, http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable | 22:00 |
| jelmer | jam: Ah, sorry | 22:00 |
| jam | ah, I haven't merged that one yet | 22:00 |
| jelmer | the hardy-ppa branch is based on it | 22:01 |
| jam | jelmer: well, merging that brought in about 50+ revisions | 22:06 |
| jam | is that expected? | 22:06 |
| jam | though it only had 1 conflict in "changelog" | 22:06 |
| jelmer | jam: It's harmless, though not intentional | 22:07 |
| jelmer | I was playing with "bzr mu" in that branch | 22:07 |
| jam | "mu" ? | 22:09 |
| jam | (maintainer upload?) | 22:09 |
| jam | Or the Godel Escher Bach "not an op" mu | 22:09 |
| LarstiQ | is that the same as the zen mu? | 22:10 |
| jam | GEB mu is the 'zen mu', yes | 22:10 |
| jam | IIRC, it has been a long time since I read it. | 22:11 |
| jelmer | jam: "bzr mu" is an alias for "bzr merge-upstream" from bzr-builddeb | 22:12 |
| jam | jelmer: So... I seem to be still exporting the same bzr-svn revision_id, is that correct? | 22:13 |
| jelmer | jam: Yep | 22:13 |
| jam | where is that set, by the way | 22:13 |
| beuno | jam, hi! Congrats on the 1.6 release! | 22:14 |
| jam | thanks beuno | 22:14 |
| jam | I'm putting together new docs that use bzr-builddeb | 22:14 |
| jam | Should be a lot easier | 22:14 |
| beuno | did you manage to package it? | 22:14 |
| jam | as it ends up being "run these 4 scripts" | 22:14 |
| jam | beuno: documenting as I package | 22:14 |
| jam | so I don't forget anything :) | 22:14 |
| jam | beuno: I have it in ~jameinel/+archive | 22:14 |
| jam | But I'm documenting a proper version for ~bzr-beta-ppa | 22:15 |
| beuno | jam, very cool. Let me install that and give it a spin... | 22:15 |
| jam | jelmer: 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 |
| jelmer | jam, not sure if ppa requires that | 22:16 |
| jelmer | jam, can't really hurt though | 22:16 |
| jam | well, so far nobody has complained | 22:16 |
| jam | but I'll wait for ppa to tell me | 22:16 |
| * jelmer has now reduced packaging a new upstream version to: "bzr mu -d <path> && bzr tag && bzr builddeb" | 22:17 | |
| mwhudson | so branching stacked branches over the hpss appears to have issues :( | 22:17 |
| jam | mwhudson: good thing it isn't set up in the default branch format :) | 22:18 |
| mwhudson | yeah | 22:18 |
| jam | mwhudson: is it because of format inconsistencies? | 22:18 |
| jam | that the Smart Server always says it is the default format? | 22:18 |
| jam | or something along those lines | 22:18 |
| mwhudson | jam: maybe, but i don't think so | 22:18 |
| mwhudson | jam: let me set up a test again and -Dhpss it | 22:19 |
| nandersson | Swedish Techmag TechWorld Open Source congrats on the 1.6 release :) Hope to see it in Hardy soon | 22:20 |
| jam | jelmer: I need to bump the number, otherwise the "md5" sum does not match one already in the archive | 22:20 |
| jelmer | jam: You'll need to bump the upstream version number actually | 22:21 |
| jelmer | jam, That's because of a bug in bzr export (which uses now() as the timestamp for all the files in the tarball) | 22:21 |
| jelmer | jam: Alternatively, you can use debuild rather than "bzr builddeb" | 22:21 |
| jam | jelmer: so I need to make rc1-2 ? | 22:23 |
| jelmer | jam: +1 probably ("-" is special) | 22:23 |
| mwhudson | jam: http://pastebin.ubuntu.com/40506/ | 22:24 |
| jelmer | so something like rc1+1 | 22:24 |
| jam | jelmer: can you spell it out for me | 22:24 |
| jelmer | something like 0.4.11~rc1+1~bazaar1~hardy1 | 22:24 |
| mwhudson | it seems maybe the fetch logic is busticated ? | 22:25 |
| jam | mwhudson: of course, there you have 2 bzr processes fighting to log to ~/.bzr.log, which makes it a bit ugly | 22:25 |
| mwhudson | jam: huh, indeed | 22:26 |
| jam | I would have thought that fetch() wouldn't actually fetch anything for a stacked branch | 22:26 |
| jam | so I'm not sure what is broken. | 22:26 |
| mwhudson | well, no, bzr branch stacked-branch local | 22:27 |
| mwhudson | should copy all the revision data into local | 22:27 |
| jam | mwhudson: ah, you are branching *from* a stacked, and expecting it to pull everything from both | 22:27 |
| jam | sure | 22:27 |
| mwhudson | jam: yes | 22:28 |
| mwhudson | maybe it's just a missing activate_fallback_repositories somewhere, i dunno | 22:28 |
| jam | well, after I actually get these packages built, maybe I can poke at it a bit | 22:29 |
| mwhudson | thanks | 22:29 |
| jelmer | jam: sorry, something like 0.4.11~rc1+1-1~bazaar1~hardy1 | 22:32 |
| jam | jelmer: not rc1-1+1 ? | 22:32 |
| jam | I would think the official upstream number would come first | 22:32 |
| jelmer | jam: You need to update the upstream version number since every time you run "bzr builddeb" the timestamps in the upstream tarball change | 22:35 |
| jam | jelmer: I understand that, I'm just trying to understand debian version numbering | 22:35 |
| jam | and it seems like "rc1-1+1" would be better than "rc1+1-1" | 22:35 |
| jam | but my knowledge is *very* weak | 22:35 |
| jelmer | everything after the - is debian-specific | 22:36 |
| jelmer | s/debian/packaging/ | 22:36 |
| jelmer | the stuff before the - refers to the upstream version | 22:36 |
| jam | and you need a new upstream version | 22:36 |
| jam | sure | 22:36 |
| jam | ok | 22:36 |
| jam | jelmer: of course now I get "no such tag ..." but i'll shove one in | 22:39 |
| jam | I assume we should use the same version again, right? | 22:39 |
| jelmer | jam: or specify --export-upstream-revision=tag:0.4.11~rc1 | 22:39 |
| jelmer | sorry, --export-upstream-revision=tag:bzr-svn-0.4.11~rc1 | 22:39 |
| jam | jelmer: well, I went the tag route, since it makes it obvious what version is uploaded since the numbers don't match anymore. | 22:41 |
| jam | Kind of odd to do "bzr tag -r tag:XXX XXX-1" :) | 22:41 |
| jelmer | heh :-) | 22:41 |
| jam | anyway, new packages are built and uploaded | 22:41 |
| jam | again to ~jameinel/+archive, LP hasn't responded yet | 22:42 |
| jam | ok, I'm currently uploading the bzr packages to ~jameinel/+archive | 22:48 |
| jam | Unfortunately, I'm likely to be done for the night (have to pick up my son now) | 22:48 |
| jam | So if someone can play with them to make sure they are good | 22:49 |
| jam | and then I'll copy them to ~bzr-beta-ppa and ~bzr | 22:49 |
| jam | beuno: you may want to check out http://bzr.arbash-meinel.com/branches/bzr/1.7-dev/packaging | 22:50 |
| jelmer | looks like it built succesfully | 22:50 |
| jam | jelmer: that is probably the one I uploaded this morning | 22:51 |
| jam | I'm doing all of gutsy/feisty/intrepid/etc right now | 22:51 |
| jam | I'm a bit worried about multple .orig.tar.gz uploads | 22:51 |
| jelmer | jam, I mean the new bzr-svn uploaded successfully | 22:51 |
| jam | but at least the md5 sum should match | 22:51 |
| jam | jelmer: ah yeah, I think that did | 22:51 |
| jam | it should be building | 22:51 |
| jelmer | jam: the export-upstream option in bzr-builddeb is the only bit that generates different tarballs each time | 22:52 |
| jelmer | jam: if you don't use that, you should not have any problems | 22:52 |
| beuno | jam, the branch is enourmous. Does that include the bzr branch? | 22:57 |
| beuno | anyway, off to bed n' stuff | 22:59 |
| jelmer | beuno, g'night | 23:00 |
| jelmer | beuno, loggerhead is in NEW, btw, thanks to siretart | 23:00 |
| beuno | jam, scripts look good :) | 23:00 |
| beuno | jelmer, really? yay! | 23:01 |
| beuno | did -search get re-uploaded? | 23:01 |
| beuno | jam, just need to feed the scripts the information instead of hard-coding it, and we're in business | 23:01 |
| jelmer | beuno, no, Ididn't see a re-upload of search | 23:02 |
| beuno | jelmer, 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 frequently | 23:03 |
| lifeless | moin | 23:13 |
| jelmer | hey lifeless | 23:15 |
| mwhudson | hi lifeless | 23:17 |
| jam | beuno: what information is hard-coded in the scripts? You supply the version number | 23:24 |
| jam | I just give some help text so *I* can remember what format they should be in | 23:24 |
| jam | I guess I hardcode lp:~bzr/bzr/packaging-XXX | 23:28 |
| jam | but that is because those are the official locs | 23:28 |
| jam | the files have been copied to ~bzr-beta-ppa, if people like them, I'll put them in ~bzr tomorrow (except bzr-svn) | 23:41 |
| jelmer | jam: cool | 23:41 |
| ronny | hi | 23:47 |
| ronny | i just started a merge, now i got some files with conflicts, is there any nice wrapper around fireing up kdiff3 or something like that | 23:48 |
| bob2 | there's a plugin | 23:55 |
| bob2 | merge-tool or something | 23:55 |
| bob2 | oen sec | 23:55 |
| bob2 | extmerge | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!