=== kiko__ is now known as kiko === Verterok-laptop is now known as Verterok [05:16] Hey all... anyone up? [05:19] Maybe. [05:29] Anyone with experience intalling to ubuntu/debian from source? [05:32] "python setup.py install"? [05:33] * Peng wanders off. [12:10] hi all [12:12] i'm using bzr to be able to work disconnected from a subversion repo. after fetching the sources i did a bzr unbind. worked a little bit on them, committed stuff and i just did a bzr bind + bzr update as to update from the central repository. now I have a bunch of pending merges mixed with a few not yet merged changes to the code. [12:12] is there anyway to commit only the pending merges? === cprov is now known as cprov-afk [15:14] how can i upgrad bazaar? downloading the newest sources and running "setup.py install" failed. [15:15] my previous installation was bazaar v1.0 [15:15] Well, you'd usually want to blow away the old install instead of just installing over it. [15:15] hmm, bzr now gives me an error message... [15:15] But that wouldn't cause it to error out. [15:15] well, the setup ran fine [15:15] but bzr now give me an error: [15:15] from django.utils.translation import ugettext as _ [15:15] oops [15:16] bzr: WARNING: bzrlib version doesn't match the bzr program.This may indicate an installation problem.bzrlib from ['/usr/lib/python2.5/site-packages/bzrlib'] is version (1, 0, 0, 'final', 0) [15:16] That suggests that the install put bzrlib somewhere else. [15:17] Do you have any plugins installed system-wide (as opposed to in ~/.bazaar/plugins/)? [15:17] but both times i just ran "sudo python setup.py install" [15:17] no plugins. [15:18] 'k. Then blowing away the 'bzr' executable and the 'bzrlib/' dir in site-packages should be all you need to deinstall. [15:18] k. tryin it [15:18] (plugins install system-wide under bzrlib/, so you'd have to be more discriminating if you had them) [15:18] That'll give you a nice clean slate to work from. === deepjoy is now known as deepjo1 === deepjo1 is now known as deepjoy [15:21] ok, that did it === Verterok-laptop is now known as Verterok [18:21] Is there any particular reason why the deb packages are lagging behind the other binaries in being released? [18:22] aklaver, what other binaries? [18:22] or what deb packages [18:23] It surprises me that you guys don't get debs and whatnot out at the same time as releases when you're so good at everything else. [18:23] * Peng shrugs. [18:23] The 1.1 installer for Windows and Mac. [18:24] There are no deb packages for 1.1 for either Dapper or Fiesty. [18:24] There's a 1.1 deb for Gutsy? [18:24] no [18:24] Exactly. [18:25] there is for hardy, and for debian unstable [18:25] (well, 1.1rc1, but the code is the same) [18:25] Oh, huh. [18:25] aklaver: the 1.1 for Mac is *experimental* and only for ppc [18:26] It would seem a project sponsored by Canonical would have the resources to keep its own distribution up to date. [18:27] aklaver, the packaging is done by volunteers actually [18:27] (most of it) [18:27] so it really depends on who has time [18:27] beuno: but robert is in "charge" of the gutsy/feisty/dapper/whatnot backports [18:27] http://bazaar-vcs.org/releases/debs/dapper/bzr_1.0~rc1-3bazaar1_i386.deb [18:28] dato, right, just not sure if it's part of "his job" or if it's more of a volunteer thing [18:28] what about PPA? https://launchpad.net/~bzr/+archive - http://ppa.launchpad.net/bzr/ubuntu [18:28] but I don't see a 1.1. [18:28] some ubuntu person should step up and say, "I will take care of uploading from debian unstable to PPA as soon as the deb is out" [18:28] the situation would improve a lot with that, it's my opinion [18:29] dato: It's not the PPA that's the problem [18:29] dato: It's the fact that there's only one person with access to the debs on bazaar-vcs.org [18:29] I've already stated that I'd be happy to help with problems in those backports [18:29] jelmer: yes, but there was talk on the list to move from debs on b-v.o, to ppa, completely [18:30] dato: afaik that plan was never accepted though [18:30] and we all have access to ppa [18:30] Ooh, 1.1 debs are in PPA. [18:30] jelmer: I think poolie has 60% happy about it, and robert wasn't [18:30] well, there is this email: https://lists.ubuntu.com/archives/bazaar/2008q1/036620.html [18:31] beuno: I completely missed that mail [18:31] same here [18:32] I poked the list for the same issue [18:32] I got that answer [18:32] if the ppa is going to be used, it would be nice to have the old location marked as deprecated somehow [18:32] but no actual debs :D [18:32] no [18:32] that mail doesn't say ppa is going to be used [18:32] ? [18:33] but it seems that it is [18:33] nope, I think he meant uploading to bazaar-vcs.org [18:33] yeah, but https://launchpad.net/~bzr/+archive [18:33] but neither has happened, so I don't know [18:33] what Peng said [18:33] aaaaah [18:33] right [18:34] then we're using PPA, and it hasn't been made public I guess [18:35] So how do I go about setting up PPA as a repository to get packages from? [18:35] but then http://bazaar-vcs.org/DistroDownloads needs updating [18:35] aklaver: go to https://launchpad.net/~bzr/+archive, select your distro in the combo box [18:36] yeap, which is what my original email stated https://lists.ubuntu.com/archives/bazaar/2008q1/036608.html [18:36] I think dapper's is broken [18:37] right, https://launchpad.net/~bzr/+archive/+build/493851 [18:37] aklaver, did all this help? :D [18:39] Yes. I think the repository issue needs to be resolved. This is a project that is heavily promoted by Canonical. [18:39] There should be a clear path to Ubuntu updates. [18:39] aklaver: seems that it has been already, it's only the wiki page that needs updating [18:42] re-sent an email to the list to try and finally close this issue [18:42] whoops, I just sent one as well [18:43] ah well, it won't hurt to make some noise on the subject :p [18:53] :-) [19:06] Is there a frontend of bzr for KDE? [19:06] Flare183: QBzr? [19:07] hi y'all! [19:07] Peng: thanks [19:07] schierbeck: hey. hope you don't mind I bug you: I was using bzr viz yesterday, and I was missing a tooltip somewhere indicating the branch nick. [19:08] schierbeck: I think it could be useful to have it somewhere. [19:09] hi dato, no not at all. i've actually been working on improving the tooltips in the viz, but i'd like to use the gtk API introduced in a later version of pygtk than is currently required by bzr-gtk [19:10] it's introduced in 2.12 [19:10] but even with that version i find it a bit tricky -- it'll need some work [19:11] aha [19:12] schierbeck: and will that bump the requirement of the version, or can its presence be detected, and just disable that feature if it is not? (which I think it would be good) [19:13] data: it is entirely possible to do that, but i find that it increases the complexity of the code tremendously [19:14] i'd like to look in to the possibility of bumping the required version of pygtk to 2.12 [19:14] i mean, is bzr-gtk even used on legacy systems? [19:15] well, 2.12 is pretty recent, isn't it? [19:15] well, "pretty" [19:15] personally I do not care, since *I* have it, but seeing how many people ask for bzr debs schierbeck: if there's a good reason, I don't think it'd be a problem to require newer versions [19:17] jelmer: it would really help me implement advanced tooltips in the viz === brilliantnu1 is now known as brilliantnut [20:02] dato: i've pushed a *very* early implementation of the new tooltips to: [20:05] schierbeck: The requested URL /00/00/21/a0 was not found on this server. [20:06] deepjoy: you have to use bzr branch http://bazaar.launchpad.net/~dasch/bzr-gtk/tooltips [20:07] the just symlink from .bazaar/plugins/gtk to the branch [20:07] *then [20:07] sorry [20:07] schierbeck: ok. info looks good, only, tooltips should only appear over the node, not over anywhere in the line, no? (but I'm sure you're already aware ;) [20:07] np :) [20:07] ya figured that out [20:07] dato: yeah, i've tried to make it appear where i want, but i'm having some difficulties [20:08] gtk.TreeView.set_tooltip_row() doesn't seem to cut it [20:11] dato: fixed it! [20:11] you should be able to pull the new revision [20:13] jelmer: could i get you to take a look at a few patches sometime tonight? [20:13] i've sent them to the ml [20:13] schierbeck: sure, will do [20:13] thanks :) [20:16] schierbeck: I see. well, what I meant is that hovering the mouse *anywhere* in the line pops up a tooltip, which IMHO is not desirable. I think tooltips should show only over specific parts of the line, eg. the colored node. [20:16] dato: hmm [20:16] schierbeck: try to move the cursor around a bit, slowly. [20:17] i disagree -- each row represents a single revision, and it's only natural that the tooltip for a row show the metadata for that revision [20:17] dato: i think that behavior is desirable [20:18] ok, then let's just disagree [20:18] ok :) [20:19] it's just that people don't always understand why only some parts of a row has a tooltip -- it's better to help them out [20:19] Does anyone have any suggestions on how to use 'version-info' in a rails project? [20:19] I don't see a '--format=ruby', for example. [20:21] misaka: but there is --template [20:21] Is that in 1.x? [20:21] yes [20:21] I've only got 0.9* here, don't see --template with version-info. [20:21] at least [20:22] misaka: it's 1.1, sorry [20:22] *nod* [20:22] Well, that's a good start, but ... hrm. === brilliantnu1 is now known as brilliantnut [20:23] How about an automatic way to keep a file up-to-date with the latest version-info? [20:23] I saw the suggestion about using it in 'make' but it'd be nice if that was up-to-date with each update ... [20:23] * misaka hasn't looked into what kind of hooks bzr might expose yet. [20:25] misaka: have you tried parsin it as YAML? [20:25] *parsing [20:25] it looks compatible [20:26] then you'll get a nice Hash object to work with [20:26] Huh, there's a point. [20:26] I'll give that a go. [20:26] Thanks, nice one. [20:26] no problem [20:28] misaka: you could also use an autogen script to write the version info to a YAML file [20:28] bzr --version-info > version-info.yml [20:28] and then read it at runtime [20:30] Not familiar with autogen ... [20:30] it's just a bash script in the root of your project dir [20:30] called autogen.sh [20:32] hi all [20:32] any plans to have tags displayed in bzr visualize ? [20:32] scheirbek - Thanks, will check it out. [20:32] asabil: yes [20:32] asabil: have you tried out trunk? [20:32] schierbeck: any branch already providing this [20:32] no didn'y do yet [20:33] I just checked out the code to try to implement it [20:33] is it already implemented ? [20:33] asabil: some aspects of it [20:33] can you elaborate please ? [20:34] try "mkdir -p .bazaar/plugins && cd .bazaar/plugins && bzr branch http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk gtk" [20:34] scheirbeck - About autogen.sh, is this something bzr or rails would run, or would it be by hand? [20:35] asabil: well, there's a menu that lets you go to a revision by tag name, and the revision info pane displays the associated tags [20:35] misaka: it's something you run before releasing [20:35] Right. [20:35] it's customary on autotools projects [20:35] Ya, this being a rails project I'd probably make that a rake task, that's one way to do it. [20:36] misaka: but if it's a ruby project, you might as well make it a Rake target [20:36] :) [20:36] is there a "release" task in Rails? [20:36] But I'm going to check out the bzr hooks to see if I can try to keep it up-to-date automagically. [20:36] wow [20:36] schierbeck - No, not really. [20:36] the new bzr vis is awesome [20:36] scheirbeck - You'd be more likely to put it into capistrano, or whatever deployment/release process you use. [20:36] misaka: well, okay [20:37] misaka: tell me about it :D [20:37] sorry, asabil: * [20:37] heh, why sorry ? [20:38] asabil: the message was meant for you, not misaka [20:38] :) [20:38] oh I just like the UI [20:38] looks better and more user friendly [20:39] I would however try to add something to the graph [20:39] for example having a big dot inside tagged revisions can be better [20:43] re: plugins, do I understand right that bzrlib/plugins can exist in the project root? [20:48] asabil: yeah, i'm thinking that, too [20:48] misaka: no. It's user wide or system wide. [20:48] i've got a branch where there's an icon on the row if the revision is tagged [20:49] jelmer: fuck, i've forgotten my username for bundle buggy -- is it your email or what? [20:50] schierbeck: it's "dasch", apparently [20:50] then what the hell is my password... [20:50] i'll just keep trying [20:50] see privmsg [20:54] schierbeck: can you point me to that branch ? [20:54] asabil: 1 min. [20:59] asabil: it's at http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-tags [20:59] asabil: cd .bazaar/plugins/gtk && bzr merge http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-tags [21:00] schierbeck: seems like the branch is ... gone [21:01] no is ok forget it [21:01] :) [21:02] hmmm, that's not exactly how I saw it [21:02] i'm not sure changing the revision graph nodes will be enough [21:03] (oh, by the way, the icon is way off -- we'll need a real "tag" icon) [21:05] why would it not be enough ? [21:05] the tag column is ... I don't know [21:08] schierbeck: Have you seen how giggle displays tags? [21:09] That's the sort of thing I'd prefer to see for viz as well [21:10] let me see if I can add a screenshot [21:10] i've got it right here [21:11] yeah, they have a treeview column with icons [21:11] hmm, maybe I'm confusing it with something else then [21:11] and a tooltip displaying the tags when hovering the icon [21:12] i think gitk has small labels on the revision graph indicating the tags [21:12] ah, I think gitk is the one I mean then [21:12] that's how I would prefer it as well :D [21:13] yeah, that's pretty cool [21:13] man, giggle has gotten slow [21:14] yup [21:14] http://www.jrock.us/branching.png [21:14] well, i definitely think we should go the gitk way regarding tags, but it'll take some work [21:15] but dear god gitk is ugly [21:15] it's almost unbelievable [21:18] well, it's a tk app [21:18] they're bound to be ugly [21:18] :-P [21:23] yup [21:30] Hey all... I have an SVN repo that looks like /projA/[trunk|branches|tags} /projB etc. I want to convert just projA into bzr... can I do that by using bzr2svn on a SVN working directory ? [21:31] * svn2bzr [21:32] bzr-svn is more popular now. [21:32] Not that that's very helpful. [21:32] You could always just try it. At worst, you'll waste some bandwidth and time. [21:34] Peng: Ah... so I'd use bzr-svn to create a bzr branch and then work from there? [21:35] Yes. [21:35] bzr-svn is a bit of a pain to install though. [21:36] peng: That heavily depends on your platform [21:37] Well, here goes. [21:37] it should be quite easy for SuSE, Debian, Ubuntu, Gentoo Linux and Windows. Other platforms may be harder [21:38] jelmer: is there a package for ubuntu? [21:38] awmcclain: yes, in universe [21:38] jelmer: The svn bindings have been patched? [21:38] jelmer: Do you know offhand if it's compatible w/ bzr 1.1? [21:39] Peng: Yes, Ubuntu feisty was the first that included the patches [21:39] hmm, doesn bzr-svn still have the huge memory leak ? [21:39] asabil: that's been fixed although the fix is not included in the python-subversion packages yet [21:40] ok nice to hear :) [21:40] jelmer: Cool. [21:40] still, last time I tried (on gutsy), I found bzr-svn still quite slow :/ [21:40] asabil: an updated version will be uploaded to hardy in the next couple of days [21:42] Is bzr-svn a pure python package? Can i get 0.4.6 using easy_install? [21:42] awmcclain: There is a package for bzr-svn compatible with bzr 1.0 in my debian repository at http://samba.org/~jelmer/debian/ [21:43] jelmer: I just install 1.1, will that matter? [21:43] *installed [21:44] awmcclain: yes, it'll work with 1.1 [21:46] jelmer: Fantastic. Thank you === tchan2 is now known as tchan [21:53] schierbeck: http://ifaedi/~asabil/bzr-viz-tags.png [21:53] asabil: you got a proper URL? :) [21:54] oups sorry [21:54] np [21:55] oups [21:55] * asabil wonders why ctrl+a behaves like ctrl+q sometimes [21:55] schierbeck: http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png [21:56] asabil: is that working code? [21:56] yes [21:56] it looks pretty good [21:56] I just cooked up something quickly [21:57] can you try drawing a square instead of a circle, and remove the dot? [21:57] I was more thinking about putting a pixbuf next to it [21:57] with a small tag icon [21:57] and remove the dot [21:58] asabil: even better [21:58] especially if you can write the tag text inside it [21:59] not sure it is a good idea [21:59] because technically speaking a revision can have multiple tags [21:59] but let me try :D [22:00] jelmer: I should follow the key installation instructions @ http://samba.org/~jelmer/debian/ in order to use apt-get on ubuntu, correct? [22:00] asabil: they should be stacked next to each other [22:01] ok will try [22:01] awmcclain: without works as well, but apt will give warnings about using untrusted packages [22:03] jelmer: Ok, that's fine. Do I just add your url to my sources list? (Sorry, I'm not familiar with getting packages from other sources on apt-get) [22:03] awmcclain: See the instructions at that url [22:04] add the following line to /etc/apt/sources.list: [22:04] deb http://samba.org/~jelmer/debian/ unstable/ [22:04] Ahhhh [22:04] Ok, sorry [22:07] Ah, ok. perfect. gpg is giving me "no option --export-keys" [22:07] awmcclain: just use --export [22:07] done [22:07] ty [22:07] np [22:12] ug, of course, since I installed bzr 1.1 from source it's complaining i don't have the package installed. Prehaps I'll just go from source. :) === mmkassem is now known as mahmoud_ [22:52] schierbeck: http://ifaedi.insa-lyon.fr/~asabil/bzr-viz-tags.png [23:07] poolie: call on now? [23:07] igc, hi [23:07] i'm at the sprint... [23:07] sorry [23:07] will call you [23:07] np [23:08] If we're implementing a mainline workflow, it makes sense to serve a shared-repository, right? [23:11] will call back [23:11] awmcclain, yes, [23:12] poolie:dropped out ... [23:12] poolie: I'm reading http://bazaar-vcs.org/SharedRepositoryTutorial now. Do I need to do something special if I've just created a branch from an SVN server using bzr-svn? [23:12] Lots of bzr-svn questions lately... [23:23] Is it good practise to have one bzr-repo per package? Or is that overkill? Im working on a project that I want to divide in 3 .deb - would you suggest I set up a x-repo/x-trunk for each of the .deb? [23:25] Niklas_TechWorld: I have a directory structure like ~/Projects/ProjectName/{trunk,other_branches}, and each ProjectName is its own bzr repository [23:25] Niklas_TechWorld: I'm not sure how this matches up with your use case of .deb packaging, but I would generally just build a .deb from a particular revision of trunk. [23:26] radix: Ok, so I guess you suggest me to split it up! Thanks for that. I thought that would be the best as well after having a look at the documentation. Thanks a lot! [23:26] Niklas_TechWorld, i think either way would be ok [23:26] if they're closely related i'd have just one, otherwise split it up [23:27] radix: I agree. One project = one deb = one repository. [23:27] poolie: Yeah, I was just wondering for consistency sake :) === Verterok-laptop is now known as Verterok