#bzr 2008-04-01 <poolie> dhi <schierbeck> jelmer: still awake? <schierbeck> hey guys, is anybody besides me having trouble opening the bzr mainline with the viz in bzr-gtk trunk? <fullermd> It does seem to be working very hard at doing nothing... <fullermd> No CPU, no IO... <fullermd> Oh, wait. <fullermd> That may be that error in bzr with ghosts; not bzr-gtk. <schierbeck> okay * fullermd doesn't really know; just guessing. <schierbeck> well, i'm hoping :) <schierbeck> i've got enough work already! <fullermd> It works on other trees, and the backtrace looks like a place a ghost could cause cliff-off-falling. <schierbeck> in Repository.sign_revision(), what the heck does gpg_strategy mean? <schierbeck> can i just leave it as None? it's not scottashley@example.org... <mw-home> 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. <mw-home> Do I need to run sudo python setup.py install first? <mw-home> cd - <lifeless> mw-home: I think you have a version mismatch <mw-home> lifeless: between the plugin and my base bzr? <lifeless> yes <mw-home> I'm running bzr 1.0 and bzr-svn 0.4.10dev0. <lifeless> mw-home: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show#releases <mw-home> so i clearly need something different than bzr 1.0. lifeless, thanks for straightening me out. <fullermd> 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. <lifeless> igc: ping <lifeless> mw-home: or an older bzr-svn :) <igc> hi lifeless <lifeless> igc: I really want to nuke that cache <lifeless> igc: our discussion seems to have petered out <igc> the one in fastimport for the inv_vf? <lifeless> yes <igc> no problem <justdave> 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) <justdave> bzr up doesn't seem to take a revision as an argument <lifeless> justdave: revert <igc> lifeless: as long as you're aware that it was helping, I'm ok with it going ... <justdave> that works going forward I assume, too? <mw-home> do most people in here use a distribution pkg for bzr, or download some other way? <lifeless> igc: it doesn't seem to help enough to justify its existence to me. <justdave> 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... <fullermd> justdave: bug 45719 <fullermd> https://bugs.launchpad.net/bzr/+bug/45719 <justdave> yeah, looks like that does work. :) <justdave> the name of the command just makes it confusing :) <igc> lifeless: understood. I think the stuff you're doing is more important than the short term gain I'm getting <fullermd> Name of the command? <fullermd> Oh, you mean using revert? <justdave> 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" <fullermd> Well, not really. It needs to update -r. The option just doesn't exist. <fullermd> Of course, if it's a branch by itself, you can use pull -r; that may be the best solution in that case. <justdave> using pull just tells me "No revisions to pull." <justdave> no matter what revision I specify <mw-home> thanks for all the help. <fullermd> Well, if that rev is already the head, that's what you expect. <igc> lifeless: removed and pushed to lp <justdave> doesn't seem to matter. <justdave> I can bzr revert -r(older rev), and then bzr pull -r(current) and it still says that <fullermd> Don't do the revert beforehand. * fullermd sighs. <fullermd> Pulling 1 rev of bzr.dev: <fullermd> Now on revision 3320. <fullermd> 5.352u 0.434s 1:29.75 6.4% 114+147k 274+19io 7pf+0w <fullermd> Pulling 4 months of mutt changes (hg): <fullermd> added 199 changesets with 417 changes to 121 files <fullermd> 119 files updated, 0 files merged, 10 files removed, 0 files unresolved <fullermd> 5.813u 0.396s 0:12.90 48.0% 124+161k 459+32io 0pf+0w <justdave> # bzr up <justdave> Tree is up to date at revision 5181. <justdave> # bzr pull -r5179 <justdave> No revisions to pull. <fullermd> You need --overwrite to step backward. <fullermd> (or sideways) <justdave> bingo <justdave> All changes applied successfully. <justdave> Now on revision 5179. <fullermd> (of course, that pull if you had the files reverted might do some wacky things...) <justdave> ok, so "bzr pull --overwrite -rtag:production" is what I want on my cron job then <sssslang> hi there, could some one give me an advise about which gui to use under windows. i'm a newbee, thanks. <fullermd> Noop pull on bzr.dev takes as long as that whole hg pull. Sigh. * fullermd wants smarts. <fullermd> 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. <fullermd> (all that AIUI; I don't really use either one) <sssslang> fullermd: thanks. what about TortoiseBzr? i heard of it before when using cvs. <fullermd> I think it's still more "proof of concept" than "use this to get work done". <sssslang> i don't use gui, but i just want to select one for my partner. <sssslang> i see. thank you. <fullermd> (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) <mwhudson> is there bzrlib for 'delete the branch at this url' ? <mwhudson> i guess i want transport.rmtree, which doesn't seem to exist * igc lunch <lifeless> mwhudson: there is <lifeless> mwhudson: delete_tree <mwhudson> oh yay <mwhudson> (i was looking in the wrong place) <lifeless> pydoc bzrlib.transport.Transport :> <AfC> 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://? <AfC> (right now, of course, I'm ssh'ing to the server, cd'ing, and doing rm -r. Hm) <lifeless> AfC: well, 'python -c "import bzrlib.transport; bzrlib.transport.get_transport('url').delete_tree()"' ? <AfC> Let me get right on that <lifeless> AfC: ssh is simpler :) <AfC> The case I am interested in is where you have ssh access to run bzr commands but not an remote shell. <AfC> (which is what we offer our users) <AfC> (I gather Launchpad is the same? Anyway) <AfC> I have to delete their obsolete branches for them. Kinda ugly. You're saying I should ask them to run that snippet? Very well. <mwhudson> launchpad allows sftp, which somewhat allows the same <spiv> Launchpad offers no shell, although it does offer a web UI that can delete branches. <Peng> There's no need to delete obsolete branches.. <spiv> Peng: it is useful if you like to browse branches to get a sense of what's being worked on. <Peng> Yeah. <spiv> (presupposing a mechanism to browse collections of branches, of course) <Peng> I leave my branches around forever, using Launchpad to mark them as merged or abandoned or whatever. <lifeless> AfC: no really saying that that snippet is a good answer; just thats the only answer in bzrlib today <lifeless> I hate test_35_wait_lock_changing <Peng> 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. :) <Peng> So what's the status of bzr.dev and http://bazaar.launchpad.net/, what with bug 207558? <lifeless> bug 207558? <jdong> lol <jdong> seveas upgraded to hardy. <jdong> hilarity ensues. <spiv> Peng: I'm working on it atm <fullermd> spiv: Hey, I had a Q about that root_client_path thing you merged in today... <fullermd> 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? <Peng> spiv: Ok. <Peng> Oh, ubotu isn't here? <spiv> 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 <fullermd> spiv: I have the [recreational] desire to get the smart server in bed with UserDir's... <spiv> 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. <fullermd> Hm. So that wouldn't really apply... <lifeless> fullermd: ~ translation just needs a transport adapter I think <spiv> fullermd: what lifeless said :) * fullermd gets his Greek-to-English dictionary out... <spiv> 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 <spiv> So instead of having a SmartWSGIApp that publishes '/home/code/project-x', it could publish "userdir:///". <lifeless> spiv: well, I was thinking something that looks for ~ and does userdir expansion <lifeless> spiv: but yeah <fullermd> 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. <lifeless> always need more help fullermd <fullermd> Well, my port of bzrlib to perl is a little stalled... <lifeless> I said help :) <fullermd> I am helping; it's stalled ;) <mdke> lifeless: thanks very much for your email <fullermd> It's kinda odd that 'missing' doesn't have --remember, and doesn't remember by default either. And doesn't use the submit branch... <james_w> sounds like the start of a soppy song... "oh, if only I could remember all those missing revisions..." <fullermd> Hm. Yeah. Simon and Garfunkel. <igc> night all <james_w> night igc <james_w> igc: thanks for the proposed new hook, it could well make bzr great for use with ikiwiki <james_w> does anyone understand this? <james_w> http://release.debian.org/migration/testing.pl?package=bzr-builddeb <james_w> it seems to be a bit of a circular argument. <james_w> it might be http://release.debian.org/migration/testing.pl?package=bzr-svn that is the root of it then <siretart> james_w: we need to ask the release team to add a hint that the bzr related package need to go in together <siretart> james_w: or we could just prod dato, since he is a member of the debian release team ;) <james_w> ah, I see, thanks siretart <dato> siretart, james_w: I added a hint, should be done in a couple days, when bzr-svn is ready to migrate <james_w> dato: thanks <schierbeck> jelmer: hi <jelmer> schierbeck: hey <schierbeck> have a look at lp:~bzr-gtk/bzr-gtk/seahorse-integration <schierbeck> it's rocking. <schierbeck> i've got key fingerprints and trust down nown <schierbeck> *now <schierbeck> though i still need to fix some bugs <jelmer> cool <jelmer> schierbeck: any chance you can review my other two patches I sent to the list? <jelmer> ([MERGE] Signatures tab and [MERGE] Split identity settings out of main preferences window.) <jamesh> jelmer: thanks for looking at my commit-notify patch <schierbeck> jelmer: sure <jamesh> now I just need to get lifeless to review the bzr-dbus bits <jamesh> :) <jelmer> schierbeck: thanks <schierbeck> okay <schierbeck> looked over the settings branch, looks good! <schierbeck> jelmer: btw, do you think we should rename the "signature" tab label to "trust"? <schierbeck> i think it makes more sense <schierbeck> since a signature doesn't really mean anything if you don't trust it. <jelmer> schierbeck: I'd rather call it signature for now <jelmer> Since trust can mean different things here <jelmer> 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? <schierbeck> that could be differentiated in the tab ui <schierbeck> i.e. [x] Trust that this revision was committed by 'John Doe' <schierbeck> and [x] Trust the validness of this revision <schierbeck> where validness would be replaced with a proper word... <jamesh> jelmer/schierbeck: if you want to do signature verification, maybe try pygpgme <jamesh> I haven't done much work on it recently, but it works pretty well <schierbeck> jamesh: we're looking at using the seahorse dbus service right now, but i'll take a look <james_w> I don't know if you guys know, but we had a discussion on signatures at the sprint <jelmer> schierbeck: The problem is that bzr can only store signatures at the moment and afaik it's not really clear what they mean <schierbeck> jup, that's been an issue for a while <james_w> it's not clear that what we have now is the best approach, so it may be re-evaluated. <schierbeck> remember discussing it a few months ago <jamesh> schierbeck: okay. From memory, seahorse is built on top of gpgme, so they should be mostly equivalent <jamesh> it just changes who forks and exec's gpg <schierbeck> jamesh: i think a review system integrated into bzr would be nice <james_w> I've been tasked with writing a spec about it <jelmer> schierbeck: that's why I'd rather stay away from assigning trust, etc for now <schierbeck> jelmer: i see your point <jamesh> bzr has enough hooks now that the jam's old signing plugin could be extended to do useful things now <james_w> 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 <jamesh> like refuse merges that aren't signed by a trusted key <schierbeck> what about having review keywords, like "approve", and then just sign the keyword and sha1-sum? <schierbeck> bzr review <approve|reject|...> -r <revision> <schierbeck> the idea would be that all history up to that revision would then be "approved" <schierbeck> just an idea, though <schierbeck> jelmer: okay, i've pushed some further changes to lp <schierbeck> the new implementation now exceeds the old in functionality <schierbeck> jamesh: does pugpgme have any documentation? <schierbeck> *py* <jamesh> schierbeck: not really. The API is mostly the same as the C one though. <jamesh> and the tests cover pretty much all the entry points <schierbeck> jamesh: okay <schierbeck> perhaps i'll switch to it later on <schierbeck> also depends on distribution stuff <jelmer> schierbeck: I'd rather use seahorse than pygpgme since seahorses password prompting will always be gtk based <jamesh> schierbeck: whatever you do, don't use pyme <jamesh> it is one of the worst kinds of swig generated Python extension <ubotu> New bug: #210053 in bzr "no way to edit subject when using bzr send builtin editor" [Medium,Confirmed] https://launchpad.net/bugs/210053 <ubotu> New bug: #210092 in bzr "Bazaar raises AssertionError in TreeTransformBase.version_file: 'file_id is not None'" [High,Confirmed] https://launchpad.net/bugs/210092 <jelmer> schierbeck: the seahorse-integration branch gives me list out of range exceptions <ubotu> New bug: #209849 in bzr "Bazaar chokes when running commands over SFTP" [Undecided,New] https://launchpad.net/bugs/209849 <ubotu> New bug: #209948 in bzr "bzr log failure (possible regression)" [High,Confirmed] https://launchpad.net/bugs/209948 <ubotu> New bug: #209998 in bzr-gtk "Should integrate with Seahorse" [Medium,In progress] https://launchpad.net/bugs/209998 <ubotu> New bug: #209912 in bzr "--hardlink option produce traceback on Windows" [Undecided,New] https://launchpad.net/bugs/209912 <g0nzal0> hello there, I'm trying use bazaar to do personal version control of a little django project <g0nzal0> using Ubuntu 7.10 <g0nzal0> I get this: http://dpaste.com/42536/ :( <g0nzal0> when doing commit <g0nzal0> for the first time <AfC> g0nzal0: you really want to be using a version of Bazaar that is not 6 versions old. <AfC> g0nzal0: upgrade to bzr >= 1.3 <g0nzal0> AfC: OK! <bob2> g0nzal0: 'bzr commit -q' might succeed <james_w> g0nzal0: what's your locale? <bob2> if that error is from trying to print the filename <AfC> g0nzal0: 0.90 is ancient <g0nzal0> AfC: I thougth so.., thanks <g0nzal0> james_w: es_AR.UTF-8 <schierbeck> jelmer: yeah, i noticed <james_w> g0nzal0: there is a PPA you can use to get the latest version <schierbeck> jelmer: it's if you don't have the key <g0nzal0> AfC: I thougth apt-get install bzr would get it <james_w> https://launchpad.net/~bzr/+archive <g0nzal0> james_w: thanks * AfC is a bit shocked that Ubuntu doesn't publish updates of things, but that's ever been the Debian way. <siretart> AfC: ubuntu does update software, even in released version. the updating policy is documented on wiki.ubuntu.com <AfC> Uh huh <schierbeck> jelmer: is it still giving off noise? <jelmer> schierbeck: let me try <jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: <schierbeck> jelmer: you're at revision 427? <jelmer> schierbeck: yes <schierbeck> hmm <schierbeck> i'll see if i'm running an old version of seahorse <schierbeck> i'm running 2.20.1 <jelmer> GNOME seahorse 2.22.0 <schierbeck> you're running hardy, right? <jelmer> no, Sid <schierbeck> okay <schierbeck> i'm not sure what's changed in the api <schierbeck> can you try using self.get_id() instead of self.key in GetKeyField() et al? <jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: <schierbeck> what method is throwing it? <schierbeck> is it discover() or one of the getters? <jelmer> not sure, the machine I was runnig it on just crashed :-( <sabdfl> is bzr.dev having a crisis of identity? <sabdfl> peregrine% ./bzr pull ~/software/bzr.dev <sabdfl> Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/ <sabdfl> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/". <Peng> sabdfl: >= r3309? <Peng> sabdfl: https://bugs.edge.launchpad.net/bzr/+bug/207558 <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] <sabdfl> 3323 <Peng> ubotu: When did you get back? <Peng> Fuck! X-Chat's dying again. <Peng> Or, some less-obscene variant of that sentence. <schierbeck> jelmer: still no luck? <ubotu> New bug: #210142 in bzr "Log comments cannot be changed/edited/annotated" [Undecided,New] https://launchpad.net/bugs/210142 <mtaylor> is there a way to change a repository from --with-trees to --without-trees without recreating it? <dato> mtaylor: there is `touch .bzr/repository/no-working-trees` <mtaylor> dato: nice :) <schierbeck> hmm, perhaps i should work on my exam assignment today... <schierbeck> i always get so god damned productive when i have exams! <schierbeck> just in the wrong areas... <jelmer> schierbeck: one sec <jelmer> schierbeck: http://pastebin.org/26636 <jelmer> schierbeck: yeah, I always get that as well.. the more you have to do, the more interesting other things become :( <ubotu> New bug: #210218 in bzr ""bzr send" fails if branch nick contains a slash" [Undecided,New] https://launchpad.net/bugs/210218 <aantn> hello <aantn> can I get bzr merge to ignore two revisions from the merge source? <aantn> I'd like it to merge all revisions after revision number x <aantn> and permanently ignore the revisions before that <aantn> The man page explains that "If you specify two revisions, the first will be used as a BASE, <aantn> and the second one as OTHER." <aantn> I'm not sure what the 'other' means <luks> you would need to cherry-pick those revisions <luks> which has it's disadvantages <luks> regular merge will only merge the whole branch <luks> 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 <luks> what you can do is a full merge, and then revert those X revisions with a reversed merge <aantn> I'm not sure I follow... <luks> which part? <luks> or the whole monologue? :) <aantn> luks: why a regular merge beginning from a specific number wont work <luks> because revisions in bzr have some identifiers and have defined their parent revisions <luks> if you merge from some specific revisions, you would break the original revision parent<->children chain <luks> bzr allows you to do that, but it will look differently from a regular merge <luks> (it's called cherry-picking) <luks> what is your use case for this? <aantn> hmm... <aantn> I run my own branch that really is probably going to split from the trunk <aantn> I've already added the feature that those revisions add to the trunk <aantn> And I like the way I implemented it more than the way it was done in trunk <aantn> I think I'll just merge it in and then restore it to what it was before <luks> yes, that's the best solution I think <luks> do a full merge, and revert those specific changes <aantn> luks: is there a command to do that, or should I just do it by hand? <luks> well, if they are touching the same code, you will have conflicts on the merge <luks> so you will probably have to do manually anyway <aantn> luks: probably <aantn> thanks <luks> `bzr shelve` could help probably <luks> that is, in case you don't have textual conflicts, but want to revert specific changes <luks> if those changes affect whole files, you can simply use `bzr revert path/to/file` <aantn> luks: that should work <Peng> What's that simple POST to see if an HTTP smart server is alive, that just returns "ok2"? <james_w> Peng: there's a hello plugin <james_w> so I think you can do bzr hello bzr+http://wherever <ubotu> New bug: #210280 in bzr "unable to obtain lock after push failure" [Undecided,New] https://launchpad.net/bugs/210280 <Peng> james_w: That's true. I've even downloaded it, but never installed it. <Peng> I've got it. <Peng> $ echo hello | POST http://.../.bzr/smart <Peng> bzr-hello is neat too. <cody-somerville> What is the command to build a debian package from a repository? <LeoNerd> apt-get source foo; debuild ? <Peng> There's bzr-builddeb. <cody-somerville> Thanks Peng <LeoNerd> Oh.. that :) <cody-somerville> Are you sure thats the command? <cody-somerville> oh, I guess I don't have it installed * cody-somerville thought he did. <Peng> Yeah, it's a package. I don't know what the command is. <cody-somerville> fun <james_w> cody-somerville: try without the - <james_w> bzr builddeb <beuno> poolie, lifeless, did you manage to send in the paper for debconf? <james_w> hi besonen_mobile2 <james_w> and beuno, hi to you too <beuno> hey james_w! how are you? <james_w> good, how are you? <beuno> pretty good, finally caught up with most of the stuff I had left fall behind :) <beuno> how's your new work? <james_w> it's going great thanks. <beuno> I'm glad :) <jelmer> hi james_w <jelmer> james_w: Did you see the bug report I filed on bzr-builddeb's timestamps? <jelmer> james_w: Took me a while to figure out what was causing those differing checksums... <james_w> jelmer: yeah I did <james_w> I haven't had time to look at though I'm afraid <dato> is it going to work by just using the same timestamps? <james_w> I don't know <jelmer> dato: yep, a diff on the tarfile showed that was the only thing that differed <dato> fwiw joeyh wrote pristine-tar for stuff like this <dato> jelmer: aha <jelmer> dato: that's the other way around though <james_w> dato: i'd like to integrate it, but there's no easy place to stash the diff in bzr <dato> james_w: true... <jelmer> james_w: Hmm, looks like that's actually a bug deep inside the bzr export code... <james_w> jelmer: that it doesn't set the timestamps, or something else? <jelmer> james_w: it explicitly sets the timestamp to time() <jelmer> the exporting happens from a revision tree, when there is no revision object around anymore <jelmer> bzrlib/export/tar_exporter.py:33 <james_w> I can get the revision object in builddeb and set the timestamp then <jelmer> you mean avoid the standard bzr export code? <james_w> no, just set the timestamp after <james_w> if I could do it with the bzr export code that would be better obviously <james_w> a timestamp= parameter or something <jelmer> james_w: there is no generic timestamp argument passed to the argument code at the moment <jelmer> though one could be added, I guess <james_w> yeah, I don't know if it could be done without breaking other exporters, I'm not looking at the code at the moment. <james_w> that would probably be the cleanest way though. <jdong> james_w: any hints on http://launchpadlibrarian.net/13012802/buildlog_ubuntu-hardy-i386.bzr-builddeb_0.93_FAILEDTOBUILD.txt.gz? <james_w> Unable to load plugin 'builddeb' from '/build/buildd/bzr-builddeb-0.93/build/lib/bzrlib/plugins' <james_w> that's annoying <james_w> we need a -Dplugin_loading or something <james_w> it means that I want the ~/.bzr.log to debug it <james_w> 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 <james_w> so I don't know what the fix is exactly. <james_w> perhaps just to disable the testsuite during the build. <james_w> though I don't like doing that <jdong> james_w: odd enough it worked in my pbuilder too.... <jdong> 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 <james_w> thanks <james_w> the other alternative is to cat ~/.bzr.log if that command fails, just so we can debug it properly <schierbec1> jelmer: ping <jelmer> schierbec1: pong <schierbec1> jelmer: i'm tweaking the sig tab labels <schierbec1> i'm thinking: a bold headline and a longer description <schierbec1> such as: <schierbec1> *Authenticity unknown* <schierbec1> This revision has not been signed; it may be forged. <schierbec1> etc. <schierbec1> what do yuo think? <schierbec1> *you <jelmer> schierbec1: The fact there is a signature doesn't say the revision is or isn't forged <jelmer> schierbec1: I can forge one of your revisions and sign it. <schierbec1> jelmer: yeah, but signed + trusted key => not forged, right? <jelmer> schierbec1: no, that implies you trust all people whose keys you've signed to not forge revisions <schierbec1> well, okay then <schierbec1> but then the whole idea of signatures kind of goes away <schierbec1> if you can't even trust your trusted friend to f00k you over <jelmer> schierbec1: right, but that's what the whole discussion about signatures in bzrlib was about <schierbec1> jelmer: what if we match the signature name + email with the committer's? <jelmer> schierbec1: yeah, that would make some sense <schierbec1> so a revision signed by its author is authentic if the key is trusted? <jelmer> schierbec1: yeah <mdke> quick question. When I upgrade a branch from dirstate-with-subtree to rich-root-pack (on Launchpad), what will the other users of the branch need to do to get the changes? upgrade their branches too or get them again? <jelmer> mdke: afaik they should be able to continue pulling if they have bzr >= 1.0 <mdke> jelmer: and pushing? <jelmer> mdke: pushing will still be possible too <mdke> cool, thanks. but to get the benefits they need to upgrade right? <jelmer> mdke: it'll be slower than it can be though, so I would highly encourage them to also upgrade to --rich-root-pack <mdke> fine, thanks a lot <jelmer> schierbec1: so I think we have 4 situations then: <jelmer> or rather 5 <schierbec1> jelmer: so we have four cases: (unsigned), (signed - trusted), (signed + trusted - committer), and (signed + trusted + committer) ? <schierbec1> oh <schierbec1> what's the fifth? <schierbec1> well, (signed + committer - trusted) <jelmer> yeah, 4 <jelmer> schierbec1: no signature, signed by trusted author, signed by untrusted party, signed by trusted person (not author) <mw-home> does bzr have keywords like $Id: $ ? <jelmer> okay, that matches what you said <jelmer> mw-home: nope, not yet <schierbec1> i think we should only handle unsigned, signed+trusted+committer and signed-trusted+committer <jelmer> mw-home: there is an open specification about it but nobody working on it yet afaik <schierbec1> that's all related to authenticity <jelmer> schierbec1: I think we should show if somebody who's trusted but not the author has signed <schierbec1> jelmer: yeah, but perhaps delay that a bit <jelmer> schierbec1: We should clearly state that that person is not the author <jelmer> schierbec1: ok <jelmer> schierbec1: We should be checking against committer email btw, not author email <schierbec1> jelmer: i think we should have an 'Authenticity' section <schierbec1> okay <jelmer> schierbec1: also, if the revision is signed by somebody untrusted it's not relevant if that key's email matches the committer email <jelmer> since we can't trust the email on the key to be valid <schierbec1> exactly <schierbec1> jelmer: but we may like to provide the user with the option of trusting the key <jelmer> schierbec1: we should leave that to specific apps such as seahorse imo <schierbec1> if he's spoken with the committer and knows the revision is authentic, we can then trust it (marginally) <schierbec1> jelmer: seahorse is meant to be integrated like that -- no ordinary user will open up a key manager <jelmer> schierbec1: I think we should allow launching a key details dialog or something from seahorse <mw-home> jelmer: thanks for the information. <jelmer> but we shouldn't have a "trust this person" key, that's really outside of the scope of bzr-gtk <schierbec1> jelmer: i'm not sure -- if that's the way the user extends his trust network? <jelmer> schierbec1: signing keys should involve identity verification and the like <jelmer> schierbec1: also, seahorse already deals with this task, let's not reimplement that bit <jelmer> afaik the key information diaog from seahorse has buttons for trusting the key <schierbec1> jelmer: allright, but perhaps we can have a look at it in the future <schierbec1> jelmer: does it still throw exceptions at you? <schierbec1> i talked with a seahorse dev, he said the api didn't change <schierbec1> jelmer: btw, i've pushed to lp, you can check out the new headings <jelmer> schierbec1: yep, still errors <jelmer> Invalid key id: <schierbec1> can you print out the key? <jelmer> this is on your signed revisions <schierbec1> it should be of the format "openpgp:<key>" <jelmer> it works fine for my own signed revisions <jelmer> such as 14.1.1 (in bzr-gtk) <jelmer> schierbec1: The "Authenticity confirmed" bit is incorrect until we're checking the author email == key email <schierbec1> jelmer: yeah, this is just the ui bits, i'll add the comparison asap <schierbec1> jelmer: can you add a print in crypt.py so i can see what the key looks like? <jelmer> sure <jelmer> what/where? <schierbec1> just in Key.__init__() <schierbec1> print key <schierbec1> jelmer: it may also be that my key is not fetched from the server <jelmer> schierbec1: We should not rely on seahorse being able to fetch a key <jelmer> schierbec1: since you may be offline, for example <jelmer> schierbec1: I think I also have automatic key fetching turned off in gpg since it is slow <schierbec1> jelmer: i'm not completely sure what the protocol is, but the docs mention that a key may be "missing" at first <schierbec1> jelmer: but that may very well be the problem <schierbec1> jelmer: i'd like to try something: in __init__(), replace "discover(key)" with "discover(self.get_id())" <schierbec1> that's just to see if the api's changed <jelmer> schierbec1: that changes the error back to the list index out of range exception <jelmer> schierbec1: what does DiscoverKeys() do exactly? <jelmer> does that try to fetch the key from the web? <schierbec1> yup, or the local network <schierbec1> i'd like to see the value of "key" -- can you print it out? <jelmer> schierbec1: key is an empty string <schierbec1> it sounds like VerifyText returns something stupid <schierbec1> hmm <jelmer> schierbec1: seahorse also has an option to automatically discover keys as they are requested <schierbec1> what about cleartext in crypt.verify() ? <jelmer> schierbec1: I'd rather rely on that <jelmer> schierbec1: cleartext does indeed contain the testament <schierbec1> that's funny -- the "key" return value is just empty?! <jelmer> schierbec1: dbus.String(u'') <schierbec1> ? <jelmer> schierbec1: "print repr(key)" prints dbus.String(u'') <schierbec1> 3 seconds, on the phone <schierbec1> jelmer: sorry, my mom called <schierbec1> hehe, a bit hard to just hang up... <schierbec1> jelmer: but yeah, it's returning an empty string -- i'll just make a test for that and mark the key as invalid then <jelmer> schierbec1: s/invalid/unknown? <jelmer> since it could be trusted <jelmer> schierbec1: it's a bit odd though that it doesn't return anything at all, it should known the key id even if it doesn't have the key <schierbec1> jelmer: exactly, but i guess we'll just mark it as unsigned or what? <jelmer> schierbec1: unknown should be a separate thing imho <schierbec1> jelmer: okay, like "error verifying key"? <schierbec1> oh, the seahorse guy is responsive now, i'll ask him <jelmer> schierbec1: ah, cool <jelmer> schierbec1: it would be nice if seahorse could actually return the key id there <jelmer> schierbec1: and it would be nice if a command could be added to the DBus API to display the key information dialog for a particular key <schierbec1> yup <schierbec1> jelmer: could i get you to pastebin the crypttext of a revision that doesn't work? <schierbec1> in crypt.verify() <jelmer> http://pastebin.org/26731 <schierbec1> yeah, that looks like it should <schierbec1> i'm talking with the seahorse guy, it seems that it's because the key is not in your keyring <jelmer> schierbec1: right, and it shouldn't have to be <jelmer> I mean, seahorse should be able to return the key idea <jelmer> and we could print something like "signature from unknown key YYYY" <schierbec1> jelmer: exactly <schierbec1> right now, i think we should just write "Authenticity cannot be verified -- Key not available" <jelmer> right, that makes sense <schierbec1> jelmer: okay, pushing a fix to lp <schierbec1> let's see if this works <jelmer> schierbec1: yep, works now - thanks <schierbec1> cool <jelmer> schierbec1: This should not be marked as Authentication error imho <schierbec1> i was just about to ask <schierbec1> what do you think? "Authenticity cannot be verified"? <schierbec1> s/verified/confirmed/ <jelmer> yep, that sounds good <schierbec1> jelmer: ok, it's pushed <schierbec1> jelmer: just one last thing -- try replacing VerifyText with DecryptText <schierbec1> it could be an error in the VerifyText implementation <jelmer> "No data" <schierbec1> hmm, well, ok then <schierbec1> jelmer: i think i'll rewrite the descriptions <jelmer> schierbec1: we shouldn't be calling discover() imho <schierbec1> we're not anymore <jelmer> my bad, it's just the function that's still there <jelmer> sorry <schierbec1> "The revision has been signed by a person you trust" ? <schierbec1> s/The/This/ ? <jelmer> and which person, if possible :-) <schierbec1> or rather "... signed with a trusted key" ? <schierbec1> jelmer: yeah :) <jelmer> I'd prefer "signed with a trusted key " <schierbec1> okay <schierbec1> and then "This revision has been signed, but you do not trust the authenticity of the key." <jelmer> what about "This revision has been signed with an untrusted key" ? <schierbec1> jelmer: i think it's perhaps too close to the trusted version <schierbec1> just two letters apart <schierbec1> we should emphasize that it's not trusted, as a signature in itself means nothing <jelmer> we need more colored icons :-) <Kinnison> Is bzr currently unable to branch from launchpad? <Kinnison> I was trying to get the gedit plugin and bzr says it's not a branch <schierbec1> jelmer: always :) <schierbec1> jelmer: i'm working out a seahorse patch with the dev guy <jelmer> schierbec1: cool * Kinnison hrms, also can't bzr pull from the bzr-svn branch <Kinnison> perhaps launchpad is moosed <jelmer> Kinnison: I think there was a regression in bzr.dev that breaks it with launchpad or something <Kinnison> jelmer: arse <Kinnison> oh well <Kinnison> no bzr-svn for me until that's fixed :-) <james_w> Kinnison: you should be able to pull over bzr+ssh:// <schierbec1> jelmer: what about "This signature has been signed, but the authenticity of the signature cannot be trusted."? <Kinnison> james_w: from a branch I don't own? <james_w> Kinnison: yeah, you don't need write permission to pull <Kinnison> schierbec1: "...signature has been signed..." ? <Kinnison> james_w: I was more incredulous about having ssh access to branches I didn't own * Kinnison didn't know that was allowed <Kinnison> I thought launchpad virtual-chrooted you <schierbec1> Kinnison: bzr-gtk ui bits for signed revisions <schierbec1> oops, s/signature/revision/ <Kinnison> schierbec1: aah, suddenly it makes more sense :-) <schierbec1> hehe <schierbec1> jelmer: could i get you to check out a patch for seahorse? <schierbec1> svn://svn.gnome.org/svn/seahorse/trunk/ <schierbec1> only if you have time <jelmer> schierbec1: sure <jelmer> schierbec1: or http://people.samba.org/bzr/jelmer/seahorse/jelmer :-) <schierbec1> :) <schierbec1> http://pastebin.com/d24eb0110 <schierbec1> here's the patch <schierbec1> jelmer: "This revision has been signed, but the authenticity of the key has not been established"? <schierbec1> perhaps s/key/signature/? <schierbec1> just chime in, everybody! <jelmer> schierbec1: I'd rather just say that the key is unknown or untrusted <schierbec1> ok <schierbec1> jelmer: "... but the key is not trusted."? <jelmer> schierbec1: yep <schierbec1> jelmer: have you tried out the patch? <jelmer> working on it <schierbec1> cool <beuno> vila, I've got 2 hours separated for the upload plugin today, so I'll give you the feedback I owe you :) <vila> beuno: great ! <mwhudson> beuno: hi! <jelmer> schierbec1: yep, that patch fixes it <schierbec1> jelmer: awesome! <beuno> hey mwhudson! welcome back :) <ubotu> New bug: #210422 in bzr-gtk "gpg signer should be part of ui_factory" [Undecided,New] https://launchpad.net/bugs/210422 <schierbec1> jelmer: well, now we just have to wait 6 months until the next stable is released! :) <jelmer> :-) <chell> hi <chell> hey <emgent> http://nopaste/p/aMZkktaSw <emgent> some idea? <emgent> bzr locked. <chell> emgent: nope sorry <chell> "locked 123 hours, 27 minutes ago" sounds a bit weird <jelmer> try bzr break-lock <emgent> jelmer: same error.. <emgent> :| <beuno> emgent, try a few times more (sometimes LP locks it a few times) <emgent> beuno: to push or brack-lock ? <beuno> emgent, break lock <beuno> emgent: bzr break-lock bzr+ssh://scottashley@example.org/~emgent/ubuntu-cve-tracker/universe-security-updates <beuno> 3 or 4 times should do it :) <emgent> yes i know <emgent> but same problem <emgent> ok :) <beuno> emgent, still nothing? <emgent> ok now work :) <beuno> emgent, :) <emgent> thanks * beuno wonders when LP will fix that bug <schierbec1> jelmer: okay, now we just need to figure out what to do if seahorse isn't installed <jelmer> schierbec1: hide the signature tab :-) <schierbec1> jelmer: yeah, but we should add a check for seahorse :) <schierbec1> the branch is in the team repo, so you can just commit changes if you wish to <schierbec1> jelmer: what do you think about left-aligning the table "keys"? <schierbec1> i.e. the bold labels <mdke> how can I make changes to the details of my "parent" or "submit" branch? <beuno> mdke, what kind of changes? <mdke> beuno: well, remove them or specify another branch <beuno> mdke, just use bzr push/pull/merge new_location --remember <mdke> thanks * jdong investigates bzr mailing list... did he break bzrtools? <beuno> :) <jdong> it worksforme.... <beuno> jdong, he probably has pycentral b0rked <jdong> beuno: also see bug 210452 though <ubotu> Launchpad bug 210452 in bzrtools "error updating bzrtools" [Undecided,New] https://launchpad.net/bugs/210452 <jdong> it seems like a different reporter <jdong> perhaps it only happens on an update? <james_w> jdong: there's a load of bugs filed with this error <james_w> on different packages <james_w> I can't remember the fix offhand, I think it might have been rebuilds, but that doesn't make sense here <james_w> https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/197840 is one <ubotu> Launchpad bug 197840 in bzr-svn "bzr-svn fails to install (Ubuntu Hardy, with ppa bzr)" [Undecided,Fix released] <james_w> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/197692 <ubotu> Launchpad bug 197692 in python-central "package ubuntu-desktop 1.94 failed to install/upgrade: problemas de dependencias - se deja sin configurar" [Undecided,Fix released] <james_w> that's the one <jdong> odd <james_w> jdong: yeah <james_w> jdong: passing it on to python-central may be the right thing to do, I don't know <james_w> I don't really know what bzrtools might have done to provoke this <james_w> although, hang on, bzrtools was a merge, so maybe something was dropped <james_w> or maybe not dropped, but needs to be improved. <xma> 'lo <xma> why does bb crash so often ? <lifeless> does it ? <xma> :) <xma> each time I want to read patch entries => no luck (500 internal error) <lifeless> xma: whats the last couple of lines of the traceback? <xma> each time I have seen it, it was a SQL query <poolie> hello xma <lifeless> let abentley know, probably via the list <poolie> i think it crashes pretty often <xma> poolie: hello <poolie> all things considered <poolie> i still love it deeply <xma> yes it is very valuable <xma> (when it works :)) <abentley> It crashes so often mainly because I don't know why it crashes so often :-) <xma> I learnt many python related things when reading people's patches <xma> abentley: hey aaron <xma> 00:04 <lifeless> let abentley know, probably via the list <xma> ;) <xma> so it is down now: OperationalError database is locked <xma> gotta go now <xma> see ya all <poolie> hello abentley <abentley> poolie: hi <poolie> there was a recent bug report of a failure in treetransform <poolie> if you get a sec could you comment on it, if you have not already? <abentley> Okay <poolie> it should still be in the recent list <igc> morning all #bzr 2008-04-02 <igc> poolie, spiv: call on today? <poolie> igc, yes, but i can't get in <poolie> still trying <igc> poolie: I'll hang up in case that helps * spiv hangs up too <schierbec1> jelmer: ping <igc> poolie: I got straight back in ok <igc> is it your local phone maybe? <poolie> it might be my phone <poolie> when i tried i got through to varying extents <poolie> anyhow <poolie> let's just catch up here on irc? <spiv> Sounds good. <igc> me too <poolie> so i think the PPA stuff is all settled now <igc> today, I'm planning to review patches, particularly the xml8 serializer one <poolie> i'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking <igc> I need to learn more about that so reviewing that patch will help me <poolie> i'd like to suggest the whole project do a bug day tomorrow, will send mail about that <poolie> also i seem to have some Ubuntu bugs atm <poolie> so will file them <igc> poolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak <poolie> i'll do that <igc> thanks <poolie> also when lifeless is back i'll call him re his conference submission <poolie> and i owe thumper a call or sketch of the branch listing page <igc> if you get a chance, I'd like some feedback on my hook patch/rfc too <spiv> I've sent off the core bits of the fix for bug 207558. I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done. <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558 <poolie> ok <poolie> i'll try to read that for you spiv <poolie> what is next for you? <spiv> So today will be mainly server-side hooks. <igc> poolie: another thing for me today - kill & resume the OOo import <igc> it's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow <igc> I took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps <poolie> ok, good <lifeless> igc: We should find what the cache was masking and fix it. <lifeless> igc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer <lifeless> igc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist. <igc> lifeless: maybe. commit-builder currently does things much slower than the importer does <igc> it simply can't make some of the assumptions than an importer can <igc> which make big differences to speed <lifeless> igc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be. <lifeless> igc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :> <lifeless> I'm going to do a couple of spikes today <lifeless> and get back to VF this afternoon <lifeless> I chatted with benno last night about python performance <lifeless> and he concurred with my import analysis, gave some commentary on os call performance readdir etc <lifeless> so I'm going to do this long threatened import hook <spiv> lifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time). I'll be interested to see if the reality is different. <lifeless> spiv: strace doesn't show how much time python spends marshalling <lifeless> spiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook <lifeless> holy cow 'import bzrlib' hits a lot of shit <lifeless> 34 modules <poolie> yes, i know <lifeless> many are demand load stubs I think <lifeless> or something strange <lifeless> -weird <lifeless> >>> type(sys.modules['bzrlib.struct']) <lifeless> <type 'NoneType'> <spiv> That's expected. <spiv> When a module inside the bzrlib package tries "import struct", python first treats it as a relative import. <spiv> And when an import fails, it caches misses as well as hits in sys.modules. <lifeless> ah good <spiv> (Bring on python 2.5...) <lifeless> 12 real modules imported then <spiv> lifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev. (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...) <spiv> (as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)") <lifeless> spiv: what does your faster-startup branch do ? <lifeless> spiv: (I am only planning to alter the behaviour of bzrlib specific imports) <spiv> lifeless: basically, various hackery to defer unnecessary imports <spiv> (or avoid) <spiv> lifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get. <lifeless> has anyone tried running freeze on bzr ? <spiv> Oh, and specifically also reducing the amount of the universe that "import bzrlib" imports :) <lifeless> e.g. making *everything* import and running freeze <lifeless> spiv: so my thesis is that we should make importing everything fast <lifeless> because in the general case most of the code is needed <lifeless> spiv: what do you mean about 2.5? <mwhudson> i don't think he meant 2.5 <mwhudson> at some point, imports written the normal way will be absolute <mwhudson> which means less looking for things like bzrlib.struct <spiv> I meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html <spiv> 2.5 introduces "from __future__ import absolute_import" <mwhudson> oh, heh <mwhudson> shows when i stopped paying microscopic attention to python development <lifeless> damn, pkgutil doesn't exist in 2.4 <lifeless> so, I'm saving 130/4900 open calls <lifeless> all of which look like failures <LaserJock> question, how do I change the "parent branch" of a branch? <poolie> igc, is there a BB enttry for the patch from james_w you mentioned before? <poolie> igc, i take it you were referring to the one to give a warning when getting a readonly transport? <igc> poolie: that's right * igc looks <igc> http://bundlebuggy.aaronbentley.com/request/%3C1205831646.7247.295.camel@flash%3E <igc> poolie: ^^^ <poolie> thanks <lifeless> LaserJock: pull --remember <LaserJock> lifeless: awesome * igc lunch * mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes <spiv> mwhudson: there was a thread about that on the list recently <spiv> mwhudson: it shouldn't complain, IIRC <mwhudson> there was? must have missed that in my catchup <lifeless> mwhudson: it should tell you, and take your changes as part of the merge <lifeless> mwhudson: IMO <mwhudson> i guess that makes sense <lifeless> ok, I now have my code being called consistently <abentley> lifeless: well, I'm not convinced. <abentley> It's not a very accurate preview that way. <lifeless> abentley: why is it less accurate? <abentley> because merge won't make any of those changes. It will barf. <poolie> abentley: thanks for the review ofthe help change <abentley> np <abentley> Something else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca <abentley> Even though those algorithms handle criss-cross better. <abentley> So perhaps it should say not to remerge if you're already using --lca or --weave. <poolie> so would you overall suggest using remerge, or revert and merge again? <lifeless> back in a few minutes; getting lunch <abentley> poolie: I'd suggest revert and merge. <abentley> Fewer commands to learn that way. <lifeless> abentley: when is remerge a good thing to learn and use then ? <abentley> I generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can. <abentley> If there are basic, intermediate, and advanced commands, I'd consider it intermediate. <lifeless> ok <lifeless> one thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down. <lifeless> I think we may have something similar here. <poolie> that is basically when i use remerge too <poolie> rarely on the whole tree <poolie> could we at least make it fail safe on looms - like give an error rather than mess things up? <abentley> lifeless: are you familiar with the problem? <lifeless> abentley: no, I've never used remerge like that <lifeless> oh, you mean with looms - I've seen the bug report <abentley> So the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent. <abentley> but with up-thread, it is actually the rightmost parent. <lifeless> I think the things are about-face for performance <lifeless> I didn't want to transform; then merge <abentley> I'm not sure your approach is wrong. A different approach might lead to more conflicts. <lifeless> its on my long todo to teach bzr's merge the ability to be told different file suffixes <lifeless> so we can drop the 'right files' in the right places <lifeless> and give better herringbone labels <abentley> You'd also want to swap the conflict markers. <abentley> :-) <lifeless> I'd actually like to call them by their thread names <fullermd> Speaking of merge, did --reprocess stop doing its thing sometime? Or did it just never really cut things down a lot? <abentley> Sure. <lifeless> fullermd: I think it became default <poolie> abentley: could you suggest some better help text? <poolie> should we say "use remerge FILE, or revert and merge again?" <abentley> Let's say "revert and merge again". <abentley>
{'channel': 'bzr', 'month': 4}