[00:03] dhi [00:56] jelmer: still awake? [01:06] hey guys, is anybody besides me having trouble opening the bzr mainline with the viz in bzr-gtk trunk? [01:07] It does seem to be working very hard at doing nothing... [01:07] No CPU, no IO... [01:08] Oh, wait. [01:08] That may be that error in bzr with ghosts; not bzr-gtk. [01:09] okay [01:09] * fullermd doesn't really know; just guessing. [01:09] well, i'm hoping :) [01:09] i've got enough work already! [01:10] It works on other trees, and the backtrace looks like a place a ghost could cause cliff-off-falling. [01:12] in Repository.sign_revision(), what the heck does gpg_strategy mean? [01:12] can i just leave it as None? it's not documented at all... [01:36] I just install bzr-svn by running bzr branch in my home plugins dir. Now bzr won't do anything. Keeps complaining about cannot import CachingParentsProvider. [01:37] Do I need to run sudo python setup.py install first? [01:37] cd - [01:38] mw-home: I think you have a version mismatch [01:38] lifeless: between the plugin and my base bzr? [01:39] yes [01:39] I'm running bzr 1.0 and bzr-svn 0.4.10dev0. === kiko is now known as kiko-zzz [01:40] mw-home: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show#releases [01:44] so i clearly need something different than bzr 1.0. lifeless, thanks for straightening me out. [01:45] Trunk bzr-svn generally goes with trunk bzr.dev. It may still work with 1.3 currently, but 1.0 is back far enough now that it's not too surprising. [01:45] igc: ping [01:45] mw-home: or an older bzr-svn :) [01:46] hi lifeless [01:46] igc: I really want to nuke that cache [01:46] igc: our discussion seems to have petered out [01:46] the one in fastimport for the inv_vf? [01:46] yes [01:46] no problem [01:47] so maybe I'm just completely blind, but I'm not finding what I'm looking for in the docs... if I want to update a working directory to a revision that's older than the head of the branch, what do I do? (equiv of cvs/svn up -rREVSPEC) [01:47] bzr up doesn't seem to take a revision as an argument [01:47] justdave: revert [01:47] lifeless: as long as you're aware that it was helping, I'm ok with it going ... [01:47] that works going forward I assume, too? [01:47] do most people in here use a distribution pkg for bzr, or download some other way? [01:47] igc: it doesn't seem to help enough to justify its existence to me. [01:48] like if my working directory is on r5179 and I want to update it to r5185, while the repository I'm pulling from is actually on r5190... [01:48] justdave: bug 45719 [01:48] https://bugs.launchpad.net/bzr/+bug/45719 [01:48] yeah, looks like that does work. :) [01:49] the name of the command just makes it confusing :) [01:49] lifeless: understood. I think the stuff you're doing is more important than the short term gain I'm getting [01:50] Name of the command? [01:51] Oh, you mean using revert? [01:51] so if I'm updating a website based on a tag that gets moved periodically to the revision that we want to be live on the site, my cron job needs to do "bzr revert -rtag:production" [01:52] Well, not really. It needs to update -r. The option just doesn't exist. [01:52] Of course, if it's a branch by itself, you can use pull -r; that may be the best solution in that case. [01:53] using pull just tells me "No revisions to pull." [01:53] no matter what revision I specify [01:53] thanks for all the help. [01:53] Well, if that rev is already the head, that's what you expect. [01:54] lifeless: removed and pushed to lp [01:54] doesn't seem to matter. [01:54] I can bzr revert -r(older rev), and then bzr pull -r(current) and it still says that [01:55] Don't do the revert beforehand. [01:56] * fullermd sighs. [01:56] Pulling 1 rev of bzr.dev: [01:56] Now on revision 3320. [01:56] 5.352u 0.434s 1:29.75 6.4% 114+147k 274+19io 7pf+0w [01:56] Pulling 4 months of mutt changes (hg): [01:56] added 199 changesets with 417 changes to 121 files [01:56] 119 files updated, 0 files merged, 10 files removed, 0 files unresolved [01:56] 5.813u 0.396s 0:12.90 48.0% 124+161k 459+32io 0pf+0w [01:57] # bzr up [01:57] Tree is up to date at revision 5181. [01:57] # bzr pull -r5179 [01:57] No revisions to pull. [01:57] You need --overwrite to step backward. [01:57] (or sideways) [01:57] bingo [01:57] All changes applied successfully. [01:57] Now on revision 5179. [01:58] (of course, that pull if you had the files reverted might do some wacky things...) [01:58] ok, so "bzr pull --overwrite -rtag:production" is what I want on my cron job then [01:58] hi there, could some one give me an advise about which gui to use under windows. i'm a newbee, thanks. [01:58] Noop pull on bzr.dev takes as long as that whole hg pull. Sigh. [01:58] * fullermd wants smarts. [01:59] sssslang: I think the main choices are bzr-gtk and qbzr. bzr-gtk is more complete and seems to be a bit more work to get installed. qbzr looks more native. [02:01] (all that AIUI; I don't really use either one) [02:02] fullermd: thanks. what about TortoiseBzr? i heard of it before when using cvs. === mw is now known as mw|out [02:03] I think it's still more "proof of concept" than "use this to get work done". [02:03] i don't use gui, but i just want to select one for my partner. [02:04] i see. thank you. [02:05] (though again, I don't use either the GUI's or Windows, so I may be wrong. That's just what I've picked up watching IRC/mail) [02:57] is there bzrlib for 'delete the branch at this url' ? [03:00] i guess i want transport.rmtree, which doesn't seem to exist [03:08] * igc lunch [03:09] mwhudson: there is [03:09] mwhudson: delete_tree [03:10] oh yay [03:10] (i was looking in the wrong place) [03:11] pydoc bzrlib.transport.Transport :> [03:13] lifeless: is that exposed on the command line somehow? ie, is there a way to delete a remote branch which I'm accessing via bzr+ssh://? [03:14] (right now, of course, I'm ssh'ing to the server, cd'ing, and doing rm -r. Hm) [03:15] AfC: well, 'python -c "import bzrlib.transport; bzrlib.transport.get_transport('url').delete_tree()"' ? [03:15] Let me get right on that [03:15] AfC: ssh is simpler :) [03:16] The case I am interested in is where you have ssh access to run bzr commands but not an remote shell. [03:16] (which is what we offer our users) [03:16] (I gather Launchpad is the same? Anyway) [03:17] I have to delete their obsolete branches for them. Kinda ugly. You're saying I should ask them to run that snippet? Very well. [03:17] launchpad allows sftp, which somewhat allows the same [03:18] Launchpad offers no shell, although it does offer a web UI that can delete branches. [03:18] There's no need to delete obsolete branches.. [03:20] Peng: it is useful if you like to browse branches to get a sense of what's being worked on. [03:21] Yeah. [03:21] (presupposing a mechanism to browse collections of branches, of course) [03:21] I leave my branches around forever, using Launchpad to mark them as merged or abandoned or whatever. [03:25] AfC: no really saying that that snippet is a good answer; just thats the only answer in bzrlib today [03:31] I hate test_35_wait_lock_changing [03:48] Yay, I had a weird problem with bzr-svn (traceback trying to branch something, then "not a branch"), but I upgraded, and now it's ok. :) [04:57] So what's the status of bzr.dev and http://bazaar.launchpad.net/, what with bug 207558? [04:59] bug 207558? [05:01] lol [05:01] seveas upgraded to hardy. [05:01] hilarity ensues. [05:03] Peng: I'm working on it atm [05:07] spiv: Hey, I had a Q about that root_client_path thing you merged in today... [05:08] spiv: I'm not sure I understand its implications. Could that be useful in the case where the request paths aren't directly under a common root? [05:08] spiv: Ok. [05:09] Oh, ubotu isn't here? [05:11] fullermd: hmm, I'm not sure. It's just designed so that you can publish e.g. /home/code/project-x at bzr+http://host/bzr/repos/x-project [05:12] spiv: I have the [recreational] desire to get the smart server in bed with UserDir's... [05:13] So you can effectively designate some path in your public URL space as the root of the bzr-served area, and then have that consistently translated to an underlying transport. [05:13] Hm. So that wouldn't really apply... [05:13] fullermd: ~ translation just needs a transport adapter I think [05:14] fullermd: what lifeless said :) [05:14] * fullermd gets his Greek-to-English dictionary out... [05:15] fullermd: e.g. write a plugin that registers a transport for the "userdir:" URL scheme, and use that as the backing transport for your bzr+http server [05:17] So instead of having a SmartWSGIApp that publishes '/home/code/project-x', it could publish "userdir:///". [05:17] spiv: well, I was thinking something that looks for ~ and does userdir expansion [05:17] spiv: but yeah [05:18] Either way, it sounds like it classifies solidly as "bzr hackers might be able to get this working". So, I guess I'll leave that laying for a while yet. [05:19] always need more help fullermd [05:19] Well, my port of bzrlib to perl is a little stalled... [05:20] I said help :) [05:20] I am helping; it's stalled ;) === BasicMac is now known as BasicOSX === doko_ is now known as doko [08:19] lifeless: thanks very much for your email === cprov is now known as cprov-afk [09:13] It's kinda odd that 'missing' doesn't have --remember, and doesn't remember by default either. And doesn't use the submit branch... [09:14] sounds like the start of a soppy song... "oh, if only I could remember all those missing revisions..." [09:16] Hm. Yeah. Simon and Garfunkel. === cprov-afk is now known as cprov [09:32] night all [09:34] night igc [09:42] igc: thanks for the proposed new hook, it could well make bzr great for use with ikiwiki [09:48] does anyone understand this? [09:48] http://release.debian.org/migration/testing.pl?package=bzr-builddeb [09:48] it seems to be a bit of a circular argument. [09:49] it might be http://release.debian.org/migration/testing.pl?package=bzr-svn that is the root of it then [09:50] james_w: we need to ask the release team to add a hint that the bzr related package need to go in together [09:51] james_w: or we could just prod dato, since he is a member of the debian release team ;) [09:54] ah, I see, thanks siretart [10:15] siretart, james_w: I added a hint, should be done in a couple days, when bzr-svn is ready to migrate [10:16] dato: thanks [10:38] jelmer: hi [10:43] schierbeck: hey [10:44] have a look at lp:~bzr-gtk/bzr-gtk/seahorse-integration [10:44] it's rocking. [10:44] i've got key fingerprints and trust down nown [10:44] *now [10:44] though i still need to fix some bugs [10:52] cool [10:52] schierbeck: any chance you can review my other two patches I sent to the list? [10:53] ([MERGE] Signatures tab and [MERGE] Split identity settings out of main preferences window.) [10:55] jelmer: thanks for looking at my commit-notify patch [10:55] jelmer: sure === AnMaster_ is now known as AnMaster [10:59] now I just need to get lifeless to review the bzr-dbus bits [10:59] :) [11:01] schierbeck: thanks [11:02] okay [11:02] looked over the settings branch, looks good! [11:02] jelmer: btw, do you think we should rename the "signature" tab label to "trust"? [11:03] i think it makes more sense [11:03] since a signature doesn't really mean anything if you don't trust it. [11:04] schierbeck: I'd rather call it signature for now [11:04] Since trust can mean different things here [11:05] Does it mean you trust the person who made the signature to have made the commit, or does it mean you trust them to write good code without security bugs? [11:05] that could be differentiated in the tab ui [11:06] i.e. [x] Trust that this revision was committed by 'John Doe' [11:06] and [x] Trust the validness of this revision [11:07] where validness would be replaced with a proper word... [11:07] jelmer/schierbeck: if you want to do signature verification, maybe try pygpgme [11:07] I haven't done much work on it recently, but it works pretty well [11:07] jamesh: we're looking at using the seahorse dbus service right now, but i'll take a look [11:08] I don't know if you guys know, but we had a discussion on signatures at the sprint [11:08] schierbeck: The problem is that bzr can only store signatures at the moment and afaik it's not really clear what they mean [11:08] jup, that's been an issue for a while [11:09] it's not clear that what we have now is the best approach, so it may be re-evaluated. [11:09] remember discussing it a few months ago [11:09] schierbeck: okay. From memory, seahorse is built on top of gpgme, so they should be mostly equivalent [11:09] it just changes who forks and exec's gpg [11:09] jamesh: i think a review system integrated into bzr would be nice [11:09] I've been tasked with writing a spec about it [11:09] schierbeck: that's why I'd rather stay away from assigning trust, etc for now [11:09] jelmer: i see your point [11:10] bzr has enough hooks now that the jam's old signing plugin could be extended to do useful things now [11:10] or at least a document about the issues, and the fact that the point of a signature is not currently clear is the biggest problem with the current state for me [11:10] like refuse merges that aren't signed by a trusted key [11:10] what about having review keywords, like "approve", and then just sign the keyword and sha1-sum? [11:11] bzr review -r [11:13] the idea would be that all history up to that revision would then be "approved" [11:13] just an idea, though [11:20] jelmer: okay, i've pushed some further changes to lp [11:20] the new implementation now exceeds the old in functionality [11:21] jamesh: does pugpgme have any documentation? [11:21] *py* [11:22] schierbeck: not really. The API is mostly the same as the C one though. [11:22] and the tests cover pretty much all the entry points [11:22] jamesh: okay [11:23] perhaps i'll switch to it later on [11:23] also depends on distribution stuff [11:25] schierbeck: I'd rather use seahorse than pygpgme since seahorses password prompting will always be gtk based [11:25] schierbeck: whatever you do, don't use pyme [11:26] it is one of the worst kinds of swig generated Python extension [11:26] New bug: #210053 in bzr "no way to edit subject when using bzr send builtin editor" [Medium,Confirmed] https://launchpad.net/bugs/210053 [11:26] New bug: #210092 in bzr "Bazaar raises AssertionError in TreeTransformBase.version_file: 'file_id is not None'" [High,Confirmed] https://launchpad.net/bugs/210092 [11:27] schierbeck: the seahorse-integration branch gives me list out of range exceptions [11:28] New bug: #209849 in bzr "Bazaar chokes when running commands over SFTP" [Undecided,New] https://launchpad.net/bugs/209849 [11:28] New bug: #209948 in bzr "bzr log failure (possible regression)" [High,Confirmed] https://launchpad.net/bugs/209948 [11:28] New bug: #209998 in bzr-gtk "Should integrate with Seahorse" [Medium,In progress] https://launchpad.net/bugs/209998 [11:30] New bug: #209912 in bzr "--hardlink option produce traceback on Windows" [Undecided,New] https://launchpad.net/bugs/209912 [11:36] hello there, I'm trying use bazaar to do personal version control of a little django project [11:36] using Ubuntu 7.10 [11:36] I get this: http://dpaste.com/42536/ :( [11:36] when doing commit [11:36] for the first time [11:37] g0nzal0: you really want to be using a version of Bazaar that is not 6 versions old. [11:37] g0nzal0: upgrade to bzr >= 1.3 [11:37] AfC: OK! [11:37] g0nzal0: 'bzr commit -q' might succeed [11:37] g0nzal0: what's your locale? [11:37] if that error is from trying to print the filename [11:37] g0nzal0: 0.90 is ancient [11:38] AfC: I thougth so.., thanks [11:38] james_w: es_AR.UTF-8 [11:38] jelmer: yeah, i noticed [11:38] g0nzal0: there is a PPA you can use to get the latest version [11:39] jelmer: it's if you don't have the key [11:39] AfC: I thougth apt-get install bzr would get it [11:39] https://launchpad.net/~bzr/+archive [11:39] james_w: thanks [11:46] * AfC is a bit shocked that Ubuntu doesn't publish updates of things, but that's ever been the Debian way. [11:48] AfC: ubuntu does update software, even in released version. the updating policy is documented on wiki.ubuntu.com [11:48] Uh huh === weigon__ is now known as jan === jan is now known as weigon [11:55] jelmer: is it still giving off noise? [12:04] schierbeck: let me try [12:04] dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: [12:06] jelmer: you're at revision 427? [12:07] schierbeck: yes [12:07] hmm [12:07] i'll see if i'm running an old version of seahorse [12:08] i'm running 2.20.1 [12:08] GNOME seahorse 2.22.0 [12:10] you're running hardy, right? [12:10] no, Sid [12:11] okay [12:11] i'm not sure what's changed in the api [12:12] can you try using self.get_id() instead of self.key in GetKeyField() et al? [12:14] dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: [12:16] what method is throwing it? [12:17] is it discover() or one of the getters? [12:18] not sure, the machine I was runnig it on just crashed :-( [12:32] is bzr.dev having a crisis of identity? [12:32] peregrine% ./bzr pull ~/software/bzr.dev [12:32] Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/ [12:32] bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/". [12:33] sabdfl: >= r3309? [12:33] sabdfl: https://bugs.edge.launchpad.net/bzr/+bug/207558 [12:34] Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] [12:34] 3323 [12:34] ubotu: When did you get back? [12:34] Fuck! X-Chat's dying again. [12:34] Or, some less-obscene variant of that sentence. [12:43] jelmer: still no luck? [12:48] New bug: #210142 in bzr "Log comments cannot be changed/edited/annotated" [Undecided,New] https://launchpad.net/bugs/210142 [12:50] is there a way to change a repository from --with-trees to --without-trees without recreating it? [12:50] mtaylor: there is `touch .bzr/repository/no-working-trees` [12:51] dato: nice :) [12:54] hmm, perhaps i should work on my exam assignment today... [12:54] i always get so god damned productive when i have exams! [12:55] just in the wrong areas... [13:12] schierbeck: one sec [13:13] schierbeck: http://pastebin.org/26636 [13:14] schierbeck: yeah, I always get that as well.. the more you have to do, the more interesting other things become :( === mrevell is now known as mrevell-lunch === kiko-zzz is now known as kiko [13:46] New bug: #210218 in bzr ""bzr send" fails if branch nick contains a slash" [Undecided,New] https://launchpad.net/bugs/210218 === abentle1 is now known as abentley === mrevell-lunch is now known as mrevell [14:51] hello [14:51] can I get bzr merge to ignore two revisions from the merge source? [14:51] I'd like it to merge all revisions after revision number x [14:52] and permanently ignore the revisions before that [14:54] The man page explains that "If you specify two revisions, the first will be used as a BASE, [14:54] and the second one as OTHER." [14:54] I'm not sure what the 'other' means [14:55] you would need to cherry-pick those revisions [14:55] which has it's disadvantages [14:55] regular merge will only merge the whole branch [14:56] no easy way to workaround it, because it would mean that the newer revisions in the new branch have different parents than the same revisions in the old branch [14:57] what you can do is a full merge, and then revert those X revisions with a reversed merge [14:58] I'm not sure I follow... [14:58] which part? [14:58] or the whole monologue? :) [14:58] luks: why a regular merge beginning from a specific number wont work [14:59] because revisions in bzr have some identifiers and have defined their parent revisions [14:59] if you merge from some specific revisions, you would break the original revision parent<->children chain [14:59] bzr allows you to do that, but it will look differently from a regular merge [15:00] (it's called cherry-picking) [15:03] what is your use case for this? [15:03] hmm... [15:03] I run my own branch that really is probably going to split from the trunk [15:04] I've already added the feature that those revisions add to the trunk [15:04] And I like the way I implemented it more than the way it was done in trunk [15:04] I think I'll just merge it in and then restore it to what it was before [15:04] yes, that's the best solution I think [15:04] do a full merge, and revert those specific changes [15:05] luks: is there a command to do that, or should I just do it by hand? [15:05] well, if they are touching the same code, you will have conflicts on the merge [15:07] so you will probably have to do manually anyway [15:07] luks: probably [15:07] thanks [15:07] `bzr shelve` could help probably [15:07] that is, in case you don't have textual conflicts, but want to revert specific changes [15:07] if those changes affect whole files, you can simply use `bzr revert path/to/file` [15:09] luks: that should work [15:12] What's that simple POST to see if an HTTP smart server is alive, that just returns "ok2"? === mw|out is now known as mw [15:21] Peng: there's a hello plugin [15:22] so I think you can do bzr hello bzr+http://wherever [15:51] New bug: #210280 in bzr "unable to obtain lock after push failure" [Undecided,New] https://launchpad.net/bugs/210280 [15:53] james_w: That's true. I've even downloaded it, but never installed it. [15:53] I've got it. [15:54] $ echo hello | POST http://.../.bzr/smart === kiko is now known as kiko-phone [16:06] bzr-hello is neat too. [17:09] What is the command to build a debian package from a repository? [17:10] apt-get source foo; debuild ? [17:10] There's bzr-builddeb. [17:10] Thanks Peng [17:10] Oh.. that :) [17:10] Are you sure thats the command? [17:11] oh, I guess I don't have it installed [17:11] * cody-somerville thought he did. [17:13] Yeah, it's a package. I don't know what the command is. [17:14] fun [17:24] cody-somerville: try without the - [17:24] bzr builddeb [17:47] poolie, lifeless, did you manage to send in the paper for debconf? [17:51] hi besonen_mobile2 [17:51] and beuno, hi to you too [17:51] hey james_w! how are you? [17:52] good, how are you? [17:52] pretty good, finally caught up with most of the stuff I had left fall behind :) [17:52] how's your new work? [17:53] it's going great thanks. [17:54] I'm glad :) [18:06] hi james_w [18:06] james_w: Did you see the bug report I filed on bzr-builddeb's timestamps? [18:06] james_w: Took me a while to figure out what was causing those differing checksums... [18:06] jelmer: yeah I did [18:07] I haven't had time to look at though I'm afraid [18:07] is it going to work by just using the same timestamps? [18:07] I don't know [18:07] dato: yep, a diff on the tarfile showed that was the only thing that differed [18:07] fwiw joeyh wrote pristine-tar for stuff like this [18:07] jelmer: aha [18:07] dato: that's the other way around though [18:08] dato: i'd like to integrate it, but there's no easy place to stash the diff in bzr [18:08] james_w: true... [18:19] james_w: Hmm, looks like that's actually a bug deep inside the bzr export code... [18:21] jelmer: that it doesn't set the timestamps, or something else? [18:22] james_w: it explicitly sets the timestamp to time() [18:23] the exporting happens from a revision tree, when there is no revision object around anymore [18:24] bzrlib/export/tar_exporter.py:33 [18:24] I can get the revision object in builddeb and set the timestamp then [18:25] you mean avoid the standard bzr export code? [18:26] no, just set the timestamp after [18:27] if I could do it with the bzr export code that would be better obviously [18:27] a timestamp= parameter or something [18:29] james_w: there is no generic timestamp argument passed to the argument code at the moment [18:29] though one could be added, I guess [18:30] yeah, I don't know if it could be done without breaking other exporters, I'm not looking at the code at the moment. [18:31] that would probably be the cleanest way though. [18:36] james_w: any hints on http://launchpadlibrarian.net/13012802/buildlog_ubuntu-hardy-i386.bzr-builddeb_0.93_FAILEDTOBUILD.txt.gz? [18:37] Unable to load plugin 'builddeb' from '/build/buildd/bzr-builddeb-0.93/build/lib/bzrlib/plugins' [18:37] that's annoying [18:37] we need a -Dplugin_loading or something [18:38] it means that I want the ~/.bzr.log to debug it [18:38] jdong: there's no easy way to run the testsuite from debian/rules, I thought this way would be it, but it only seems to have built in mine and my sponsor's chroots [18:39] so I don't know what the fix is exactly. [18:39] perhaps just to disable the testsuite during the build. [18:39] though I don't like doing that [18:40] james_w: odd enough it worked in my pbuilder too.... [18:40] james_w: hmm I'll disable the test suite for now so we don't lose the bzr-builddeb binary entirely while we investigate a better fix [18:40] thanks [18:41] the other alternative is to cat ~/.bzr.log if that command fails, just so we can debug it properly === kiko-phone is now known as kiko-afk [19:02] jelmer: ping [19:06] schierbec1: pong [19:08] jelmer: i'm tweaking the sig tab labels [19:08] i'm thinking: a bold headline and a longer description [19:09] such as: [19:09] *Authenticity unknown* [19:09] This revision has not been signed; it may be forged. [19:09] etc. [19:09] what do yuo think? [19:09] *you [19:10] schierbec1: The fact there is a signature doesn't say the revision is or isn't forged [19:10] schierbec1: I can forge one of your revisions and sign it. [19:11]