poolie | dhi | 00:03 |
---|---|---|
schierbeck | jelmer: still awake? | 00:56 |
schierbeck | hey guys, is anybody besides me having trouble opening the bzr mainline with the viz in bzr-gtk trunk? | 01:06 |
fullermd | It does seem to be working very hard at doing nothing... | 01:07 |
fullermd | No CPU, no IO... | 01:07 |
fullermd | Oh, wait. | 01:08 |
fullermd | That may be that error in bzr with ghosts; not bzr-gtk. | 01:08 |
schierbeck | okay | 01:09 |
* fullermd doesn't really know; just guessing. | 01:09 | |
schierbeck | well, i'm hoping :) | 01:09 |
schierbeck | i've got enough work already! | 01:09 |
fullermd | It works on other trees, and the backtrace looks like a place a ghost could cause cliff-off-falling. | 01:10 |
schierbeck | in Repository.sign_revision(), what the heck does gpg_strategy mean? | 01:12 |
schierbeck | can i just leave it as None? it's not documented at all... | 01:12 |
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. | 01:36 |
mw-home | Do I need to run sudo python setup.py install first? | 01:37 |
mw-home | cd - | 01:37 |
lifeless | mw-home: I think you have a version mismatch | 01:38 |
mw-home | lifeless: between the plugin and my base bzr? | 01:38 |
lifeless | yes | 01:39 |
mw-home | I'm running bzr 1.0 and bzr-svn 0.4.10dev0. | 01:39 |
=== kiko is now known as kiko-zzz | ||
lifeless | mw-home: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show#releases | 01:40 |
mw-home | so i clearly need something different than bzr 1.0. lifeless, thanks for straightening me out. | 01:44 |
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. | 01:45 |
lifeless | igc: ping | 01:45 |
lifeless | mw-home: or an older bzr-svn :) | 01:45 |
igc | hi lifeless | 01:46 |
lifeless | igc: I really want to nuke that cache | 01:46 |
lifeless | igc: our discussion seems to have petered out | 01:46 |
igc | the one in fastimport for the inv_vf? | 01:46 |
lifeless | yes | 01:46 |
igc | no problem | 01:46 |
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) | 01:47 |
justdave | bzr up doesn't seem to take a revision as an argument | 01:47 |
lifeless | justdave: revert | 01:47 |
igc | lifeless: as long as you're aware that it was helping, I'm ok with it going ... | 01:47 |
justdave | that works going forward I assume, too? | 01:47 |
mw-home | do most people in here use a distribution pkg for bzr, or download some other way? | 01:47 |
lifeless | igc: it doesn't seem to help enough to justify its existence to me. | 01:47 |
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... | 01:48 |
fullermd | justdave: bug 45719 | 01:48 |
fullermd | https://bugs.launchpad.net/bzr/+bug/45719 | 01:48 |
justdave | yeah, looks like that does work. :) | 01:48 |
justdave | the name of the command just makes it confusing :) | 01:49 |
igc | lifeless: understood. I think the stuff you're doing is more important than the short term gain I'm getting | 01:49 |
fullermd | Name of the command? | 01:50 |
fullermd | Oh, you mean using revert? | 01:51 |
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" | 01:51 |
fullermd | Well, not really. It needs to update -r. The option just doesn't exist. | 01:52 |
fullermd | Of course, if it's a branch by itself, you can use pull -r; that may be the best solution in that case. | 01:52 |
justdave | using pull just tells me "No revisions to pull." | 01:53 |
justdave | no matter what revision I specify | 01:53 |
mw-home | thanks for all the help. | 01:53 |
fullermd | Well, if that rev is already the head, that's what you expect. | 01:53 |
igc | lifeless: removed and pushed to lp | 01:54 |
justdave | doesn't seem to matter. | 01:54 |
justdave | I can bzr revert -r(older rev), and then bzr pull -r(current) and it still says that | 01:54 |
fullermd | Don't do the revert beforehand. | 01:55 |
* fullermd sighs. | 01:56 | |
fullermd | Pulling 1 rev of bzr.dev: | 01:56 |
fullermd | Now on revision 3320. | 01:56 |
fullermd | 5.352u 0.434s 1:29.75 6.4% 114+147k 274+19io 7pf+0w | 01:56 |
fullermd | Pulling 4 months of mutt changes (hg): | 01:56 |
fullermd | added 199 changesets with 417 changes to 121 files | 01:56 |
fullermd | 119 files updated, 0 files merged, 10 files removed, 0 files unresolved | 01:56 |
fullermd | 5.813u 0.396s 0:12.90 48.0% 124+161k 459+32io 0pf+0w | 01:56 |
justdave | # bzr up | 01:57 |
justdave | Tree is up to date at revision 5181. | 01:57 |
justdave | # bzr pull -r5179 | 01:57 |
justdave | No revisions to pull. | 01:57 |
fullermd | You need --overwrite to step backward. | 01:57 |
fullermd | (or sideways) | 01:57 |
justdave | bingo | 01:57 |
justdave | All changes applied successfully. | 01:57 |
justdave | Now on revision 5179. | 01:57 |
fullermd | (of course, that pull if you had the files reverted might do some wacky things...) | 01:58 |
justdave | ok, so "bzr pull --overwrite -rtag:production" is what I want on my cron job then | 01:58 |
sssslang | hi there, could some one give me an advise about which gui to use under windows. i'm a newbee, thanks. | 01:58 |
fullermd | Noop pull on bzr.dev takes as long as that whole hg pull. Sigh. | 01:58 |
* fullermd wants smarts. | 01:58 | |
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. | 01:59 |
fullermd | (all that AIUI; I don't really use either one) | 02:01 |
sssslang | fullermd: thanks. what about TortoiseBzr? i heard of it before when using cvs. | 02:02 |
=== mw is now known as mw|out | ||
fullermd | I think it's still more "proof of concept" than "use this to get work done". | 02:03 |
sssslang | i don't use gui, but i just want to select one for my partner. | 02:03 |
sssslang | i see. thank you. | 02:04 |
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) | 02:05 |
mwhudson | is there bzrlib for 'delete the branch at this url' ? | 02:57 |
mwhudson | i guess i want transport.rmtree, which doesn't seem to exist | 03:00 |
* igc lunch | 03:08 | |
lifeless | mwhudson: there is | 03:09 |
lifeless | mwhudson: delete_tree | 03:09 |
mwhudson | oh yay | 03:10 |
mwhudson | (i was looking in the wrong place) | 03:10 |
lifeless | pydoc bzrlib.transport.Transport :> | 03:11 |
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://? | 03:13 |
AfC | (right now, of course, I'm ssh'ing to the server, cd'ing, and doing rm -r. Hm) | 03:14 |
lifeless | AfC: well, 'python -c "import bzrlib.transport; bzrlib.transport.get_transport('url').delete_tree()"' ? | 03:15 |
AfC | Let me get right on that | 03:15 |
lifeless | AfC: ssh is simpler :) | 03:15 |
AfC | The case I am interested in is where you have ssh access to run bzr commands but not an remote shell. | 03:16 |
AfC | (which is what we offer our users) | 03:16 |
AfC | (I gather Launchpad is the same? Anyway) | 03:16 |
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. | 03:17 |
mwhudson | launchpad allows sftp, which somewhat allows the same | 03:17 |
spiv | Launchpad offers no shell, although it does offer a web UI that can delete branches. | 03:18 |
Peng | There's no need to delete obsolete branches.. | 03:18 |
spiv | Peng: it is useful if you like to browse branches to get a sense of what's being worked on. | 03:20 |
Peng | Yeah. | 03:21 |
spiv | (presupposing a mechanism to browse collections of branches, of course) | 03:21 |
Peng | I leave my branches around forever, using Launchpad to mark them as merged or abandoned or whatever. | 03:21 |
lifeless | AfC: no really saying that that snippet is a good answer; just thats the only answer in bzrlib today | 03:25 |
lifeless | I hate test_35_wait_lock_changing | 03:31 |
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. :) | 03:48 |
Peng | So what's the status of bzr.dev and http://bazaar.launchpad.net/, what with bug 207558? | 04:57 |
lifeless | bug 207558? | 04:59 |
jdong | lol | 05:01 |
jdong | seveas upgraded to hardy. | 05:01 |
jdong | hilarity ensues. | 05:01 |
spiv | Peng: I'm working on it atm | 05:03 |
fullermd | spiv: Hey, I had a Q about that root_client_path thing you merged in today... | 05:07 |
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? | 05:08 |
Peng | spiv: Ok. | 05:08 |
Peng | Oh, ubotu isn't here? | 05:09 |
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 | 05:11 |
fullermd | spiv: I have the [recreational] desire to get the smart server in bed with UserDir's... | 05:12 |
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. | 05:13 |
fullermd | Hm. So that wouldn't really apply... | 05:13 |
lifeless | fullermd: ~ translation just needs a transport adapter I think | 05:13 |
spiv | fullermd: what lifeless said :) | 05:14 |
* fullermd gets his Greek-to-English dictionary out... | 05:14 | |
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 | 05:15 |
spiv | So instead of having a SmartWSGIApp that publishes '/home/code/project-x', it could publish "userdir:///". | 05:17 |
lifeless | spiv: well, I was thinking something that looks for ~ and does userdir expansion | 05:17 |
lifeless | spiv: but yeah | 05:17 |
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. | 05:18 |
lifeless | always need more help fullermd | 05:19 |
fullermd | Well, my port of bzrlib to perl is a little stalled... | 05:19 |
lifeless | I said help :) | 05:20 |
fullermd | I am helping; it's stalled ;) | 05:20 |
=== BasicMac is now known as BasicOSX | ||
=== doko_ is now known as doko | ||
mdke | lifeless: thanks very much for your email | 08:19 |
=== cprov is now known as cprov-afk | ||
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... | 09:13 |
james_w | sounds like the start of a soppy song... "oh, if only I could remember all those missing revisions..." | 09:14 |
fullermd | Hm. Yeah. Simon and Garfunkel. | 09:16 |
=== cprov-afk is now known as cprov | ||
igc | night all | 09:32 |
james_w | night igc | 09:34 |
james_w | igc: thanks for the proposed new hook, it could well make bzr great for use with ikiwiki | 09:42 |
james_w | does anyone understand this? | 09:48 |
james_w | http://release.debian.org/migration/testing.pl?package=bzr-builddeb | 09:48 |
james_w | it seems to be a bit of a circular argument. | 09:48 |
james_w | it might be http://release.debian.org/migration/testing.pl?package=bzr-svn that is the root of it then | 09:49 |
siretart | james_w: we need to ask the release team to add a hint that the bzr related package need to go in together | 09:50 |
siretart | james_w: or we could just prod dato, since he is a member of the debian release team ;) | 09:51 |
james_w | ah, I see, thanks siretart | 09:54 |
dato | siretart, james_w: I added a hint, should be done in a couple days, when bzr-svn is ready to migrate | 10:15 |
james_w | dato: thanks | 10:16 |
schierbeck | jelmer: hi | 10:38 |
jelmer | schierbeck: hey | 10:43 |
schierbeck | have a look at lp:~bzr-gtk/bzr-gtk/seahorse-integration | 10:44 |
schierbeck | it's rocking. | 10:44 |
schierbeck | i've got key fingerprints and trust down nown | 10:44 |
schierbeck | *now | 10:44 |
schierbeck | though i still need to fix some bugs | 10:44 |
jelmer | cool | 10:52 |
jelmer | schierbeck: any chance you can review my other two patches I sent to the list? | 10:52 |
jelmer | ([MERGE] Signatures tab and [MERGE] Split identity settings out of main preferences window.) | 10:53 |
jamesh | jelmer: thanks for looking at my commit-notify patch | 10:55 |
schierbeck | jelmer: sure | 10:55 |
=== AnMaster_ is now known as AnMaster | ||
jamesh | now I just need to get lifeless to review the bzr-dbus bits | 10:59 |
jamesh | :) | 10:59 |
jelmer | schierbeck: thanks | 11:01 |
schierbeck | okay | 11:02 |
schierbeck | looked over the settings branch, looks good! | 11:02 |
schierbeck | jelmer: btw, do you think we should rename the "signature" tab label to "trust"? | 11:02 |
schierbeck | i think it makes more sense | 11:03 |
schierbeck | since a signature doesn't really mean anything if you don't trust it. | 11:03 |
jelmer | schierbeck: I'd rather call it signature for now | 11:04 |
jelmer | Since trust can mean different things here | 11:04 |
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? | 11:05 |
schierbeck | that could be differentiated in the tab ui | 11:05 |
schierbeck | i.e. [x] Trust that this revision was committed by 'John Doe' | 11:06 |
schierbeck | and [x] Trust the validness of this revision | 11:06 |
schierbeck | where validness would be replaced with a proper word... | 11:07 |
jamesh | jelmer/schierbeck: if you want to do signature verification, maybe try pygpgme | 11:07 |
jamesh | I haven't done much work on it recently, but it works pretty well | 11:07 |
schierbeck | jamesh: we're looking at using the seahorse dbus service right now, but i'll take a look | 11:07 |
james_w | I don't know if you guys know, but we had a discussion on signatures at the sprint | 11:08 |
jelmer | 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 |
schierbeck | jup, that's been an issue for a while | 11:08 |
james_w | it's not clear that what we have now is the best approach, so it may be re-evaluated. | 11:09 |
schierbeck | remember discussing it a few months ago | 11:09 |
jamesh | schierbeck: okay. From memory, seahorse is built on top of gpgme, so they should be mostly equivalent | 11:09 |
jamesh | it just changes who forks and exec's gpg | 11:09 |
schierbeck | jamesh: i think a review system integrated into bzr would be nice | 11:09 |
james_w | I've been tasked with writing a spec about it | 11:09 |
jelmer | schierbeck: that's why I'd rather stay away from assigning trust, etc for now | 11:09 |
schierbeck | jelmer: i see your point | 11:09 |
jamesh | bzr has enough hooks now that the jam's old signing plugin could be extended to do useful things now | 11:10 |
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 | 11:10 |
jamesh | like refuse merges that aren't signed by a trusted key | 11:10 |
schierbeck | what about having review keywords, like "approve", and then just sign the keyword and sha1-sum? | 11:10 |
schierbeck | bzr review <approve|reject|...> -r <revision> | 11:11 |
schierbeck | the idea would be that all history up to that revision would then be "approved" | 11:13 |
schierbeck | just an idea, though | 11:13 |
schierbeck | jelmer: okay, i've pushed some further changes to lp | 11:20 |
schierbeck | the new implementation now exceeds the old in functionality | 11:20 |
schierbeck | jamesh: does pugpgme have any documentation? | 11:21 |
schierbeck | *py* | 11:21 |
jamesh | schierbeck: not really. The API is mostly the same as the C one though. | 11:22 |
jamesh | and the tests cover pretty much all the entry points | 11:22 |
schierbeck | jamesh: okay | 11:22 |
schierbeck | perhaps i'll switch to it later on | 11:23 |
schierbeck | also depends on distribution stuff | 11:23 |
jelmer | schierbeck: I'd rather use seahorse than pygpgme since seahorses password prompting will always be gtk based | 11:25 |
jamesh | schierbeck: whatever you do, don't use pyme | 11:25 |
jamesh | it is one of the worst kinds of swig generated Python extension | 11:26 |
ubotu | 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 |
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 | 11:26 |
jelmer | schierbeck: the seahorse-integration branch gives me list out of range exceptions | 11:27 |
ubotu | New bug: #209849 in bzr "Bazaar chokes when running commands over SFTP" [Undecided,New] https://launchpad.net/bugs/209849 | 11:28 |
ubotu | New bug: #209948 in bzr "bzr log failure (possible regression)" [High,Confirmed] https://launchpad.net/bugs/209948 | 11:28 |
ubotu | New bug: #209998 in bzr-gtk "Should integrate with Seahorse" [Medium,In progress] https://launchpad.net/bugs/209998 | 11:28 |
ubotu | New bug: #209912 in bzr "--hardlink option produce traceback on Windows" [Undecided,New] https://launchpad.net/bugs/209912 | 11:30 |
g0nzal0 | hello there, I'm trying use bazaar to do personal version control of a little django project | 11:36 |
g0nzal0 | using Ubuntu 7.10 | 11:36 |
g0nzal0 | I get this: http://dpaste.com/42536/ :( | 11:36 |
g0nzal0 | when doing commit | 11:36 |
g0nzal0 | for the first time | 11:36 |
AfC | g0nzal0: you really want to be using a version of Bazaar that is not 6 versions old. | 11:37 |
AfC | g0nzal0: upgrade to bzr >= 1.3 | 11:37 |
g0nzal0 | AfC: OK! | 11:37 |
bob2 | g0nzal0: 'bzr commit -q' might succeed | 11:37 |
james_w | g0nzal0: what's your locale? | 11:37 |
bob2 | if that error is from trying to print the filename | 11:37 |
AfC | g0nzal0: 0.90 is ancient | 11:37 |
g0nzal0 | AfC: I thougth so.., thanks | 11:38 |
g0nzal0 | james_w: es_AR.UTF-8 | 11:38 |
schierbeck | jelmer: yeah, i noticed | 11:38 |
james_w | g0nzal0: there is a PPA you can use to get the latest version | 11:38 |
schierbeck | jelmer: it's if you don't have the key | 11:39 |
g0nzal0 | AfC: I thougth apt-get install bzr would get it | 11:39 |
james_w | https://launchpad.net/~bzr/+archive | 11:39 |
g0nzal0 | james_w: thanks | 11:39 |
* AfC is a bit shocked that Ubuntu doesn't publish updates of things, but that's ever been the Debian way. | 11:46 | |
siretart | AfC: ubuntu does update software, even in released version. the updating policy is documented on wiki.ubuntu.com | 11:48 |
AfC | Uh huh | 11:48 |
=== weigon__ is now known as jan | ||
=== jan is now known as weigon | ||
schierbeck | jelmer: is it still giving off noise? | 11:55 |
jelmer | schierbeck: let me try | 12:04 |
jelmer | dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: | 12:04 |
schierbeck | jelmer: you're at revision 427? | 12:06 |
jelmer | schierbeck: yes | 12:07 |
schierbeck | hmm | 12:07 |
schierbeck | i'll see if i'm running an old version of seahorse | 12:07 |
schierbeck | i'm running 2.20.1 | 12:08 |
jelmer | GNOME seahorse 2.22.0 | 12:08 |
schierbeck | you're running hardy, right? | 12:10 |
jelmer | no, Sid | 12:10 |
schierbeck | okay | 12:11 |
schierbeck | i'm not sure what's changed in the api | 12:11 |
schierbeck | can you try using self.get_id() instead of self.key in GetKeyField() et al? | 12:12 |
jelmer | dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id: | 12:14 |
schierbeck | what method is throwing it? | 12:16 |
schierbeck | is it discover() or one of the getters? | 12:17 |
jelmer | not sure, the machine I was runnig it on just crashed :-( | 12:18 |
sabdfl | is bzr.dev having a crisis of identity? | 12:32 |
sabdfl | peregrine% ./bzr pull ~/software/bzr.dev | 12:32 |
sabdfl | Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/ | 12:32 |
sabdfl | bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/". | 12:32 |
Peng | sabdfl: >= r3309? | 12:33 |
Peng | sabdfl: https://bugs.edge.launchpad.net/bzr/+bug/207558 | 12:33 |
ubotu | Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] | 12:34 |
sabdfl | 3323 | 12:34 |
Peng | ubotu: When did you get back? | 12:34 |
Peng | Fuck! X-Chat's dying again. | 12:34 |
Peng | Or, some less-obscene variant of that sentence. | 12:34 |
schierbeck | jelmer: still no luck? | 12:43 |
ubotu | New bug: #210142 in bzr "Log comments cannot be changed/edited/annotated" [Undecided,New] https://launchpad.net/bugs/210142 | 12:48 |
mtaylor | is there a way to change a repository from --with-trees to --without-trees without recreating it? | 12:50 |
dato | mtaylor: there is `touch .bzr/repository/no-working-trees` | 12:50 |
mtaylor | dato: nice :) | 12:51 |
schierbeck | hmm, perhaps i should work on my exam assignment today... | 12:54 |
schierbeck | i always get so god damned productive when i have exams! | 12:54 |
schierbeck | just in the wrong areas... | 12:55 |
jelmer | schierbeck: one sec | 13:12 |
jelmer | schierbeck: http://pastebin.org/26636 | 13:13 |
jelmer | schierbeck: yeah, I always get that as well.. the more you have to do, the more interesting other things become :( | 13:14 |
=== mrevell is now known as mrevell-lunch | ||
=== kiko-zzz is now known as kiko | ||
ubotu | New bug: #210218 in bzr ""bzr send" fails if branch nick contains a slash" [Undecided,New] https://launchpad.net/bugs/210218 | 13:46 |
=== abentle1 is now known as abentley | ||
=== mrevell-lunch is now known as mrevell | ||
aantn | hello | 14:51 |
aantn | can I get bzr merge to ignore two revisions from the merge source? | 14:51 |
aantn | I'd like it to merge all revisions after revision number x | 14:51 |
aantn | and permanently ignore the revisions before that | 14:52 |
aantn | The man page explains that "If you specify two revisions, the first will be used as a BASE, | 14:54 |
aantn | and the second one as OTHER." | 14:54 |
aantn | I'm not sure what the 'other' means | 14:54 |
luks | you would need to cherry-pick those revisions | 14:55 |
luks | which has it's disadvantages | 14:55 |
luks | regular merge will only merge the whole branch | 14:55 |
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 | 14:56 |
luks | what you can do is a full merge, and then revert those X revisions with a reversed merge | 14:57 |
aantn | I'm not sure I follow... | 14:58 |
luks | which part? | 14:58 |
luks | or the whole monologue? :) | 14:58 |
aantn | luks: why a regular merge beginning from a specific number wont work | 14:58 |
luks | because revisions in bzr have some identifiers and have defined their parent revisions | 14:59 |
luks | if you merge from some specific revisions, you would break the original revision parent<->children chain | 14:59 |
luks | bzr allows you to do that, but it will look differently from a regular merge | 14:59 |
luks | (it's called cherry-picking) | 15:00 |
luks | what is your use case for this? | 15:03 |
aantn | hmm... | 15:03 |
aantn | I run my own branch that really is probably going to split from the trunk | 15:03 |
aantn | I've already added the feature that those revisions add to the trunk | 15:04 |
aantn | And I like the way I implemented it more than the way it was done in trunk | 15:04 |
aantn | I think I'll just merge it in and then restore it to what it was before | 15:04 |
luks | yes, that's the best solution I think | 15:04 |
luks | do a full merge, and revert those specific changes | 15:04 |
aantn | luks: is there a command to do that, or should I just do it by hand? | 15:05 |
luks | well, if they are touching the same code, you will have conflicts on the merge | 15:05 |
luks | so you will probably have to do manually anyway | 15:07 |
aantn | luks: probably | 15:07 |
aantn | thanks | 15:07 |
luks | `bzr shelve` could help probably | 15:07 |
luks | that is, in case you don't have textual conflicts, but want to revert specific changes | 15:07 |
luks | if those changes affect whole files, you can simply use `bzr revert path/to/file` | 15:07 |
aantn | luks: that should work | 15:09 |
Peng | What's that simple POST to see if an HTTP smart server is alive, that just returns "ok2"? | 15:12 |
=== mw|out is now known as mw | ||
james_w | Peng: there's a hello plugin | 15:21 |
james_w | so I think you can do bzr hello bzr+http://wherever | 15:22 |
ubotu | New bug: #210280 in bzr "unable to obtain lock after push failure" [Undecided,New] https://launchpad.net/bugs/210280 | 15:51 |
Peng | james_w: That's true. I've even downloaded it, but never installed it. | 15:53 |
Peng | I've got it. | 15:53 |
Peng | $ echo hello | POST http://.../.bzr/smart | 15:54 |
=== kiko is now known as kiko-phone | ||
Peng | bzr-hello is neat too. | 16:06 |
cody-somerville | What is the command to build a debian package from a repository? | 17:09 |
LeoNerd | apt-get source foo; debuild ? | 17:10 |
Peng | There's bzr-builddeb. | 17:10 |
cody-somerville | Thanks Peng | 17:10 |
LeoNerd | Oh.. that :) | 17:10 |
cody-somerville | Are you sure thats the command? | 17:10 |
cody-somerville | oh, I guess I don't have it installed | 17:11 |
* cody-somerville thought he did. | 17:11 | |
Peng | Yeah, it's a package. I don't know what the command is. | 17:13 |
cody-somerville | fun | 17:14 |
james_w | cody-somerville: try without the - | 17:24 |
james_w | bzr builddeb | 17:24 |
beuno | poolie, lifeless, did you manage to send in the paper for debconf? | 17:47 |
james_w | hi besonen_mobile2 | 17:51 |
james_w | and beuno, hi to you too | 17:51 |
beuno | hey james_w! how are you? | 17:51 |
james_w | good, how are you? | 17:52 |
beuno | pretty good, finally caught up with most of the stuff I had left fall behind :) | 17:52 |
beuno | how's your new work? | 17:52 |
james_w | it's going great thanks. | 17:53 |
beuno | I'm glad :) | 17:54 |
jelmer | hi james_w | 18:06 |
jelmer | james_w: Did you see the bug report I filed on bzr-builddeb's timestamps? | 18:06 |
jelmer | james_w: Took me a while to figure out what was causing those differing checksums... | 18:06 |
james_w | jelmer: yeah I did | 18:06 |
james_w | I haven't had time to look at though I'm afraid | 18:07 |
dato | is it going to work by just using the same timestamps? | 18:07 |
james_w | I don't know | 18:07 |
jelmer | dato: yep, a diff on the tarfile showed that was the only thing that differed | 18:07 |
dato | fwiw joeyh wrote pristine-tar for stuff like this | 18:07 |
dato | jelmer: aha | 18:07 |
jelmer | dato: that's the other way around though | 18:07 |
james_w | dato: i'd like to integrate it, but there's no easy place to stash the diff in bzr | 18:08 |
dato | james_w: true... | 18:08 |
jelmer | james_w: Hmm, looks like that's actually a bug deep inside the bzr export code... | 18:19 |
james_w | jelmer: that it doesn't set the timestamps, or something else? | 18:21 |
jelmer | james_w: it explicitly sets the timestamp to time() | 18:22 |
jelmer | the exporting happens from a revision tree, when there is no revision object around anymore | 18:23 |
jelmer | bzrlib/export/tar_exporter.py:33 | 18:24 |
james_w | I can get the revision object in builddeb and set the timestamp then | 18:24 |
jelmer | you mean avoid the standard bzr export code? | 18:25 |
james_w | no, just set the timestamp after | 18:26 |
james_w | if I could do it with the bzr export code that would be better obviously | 18:27 |
james_w | a timestamp= parameter or something | 18:27 |
jelmer | james_w: there is no generic timestamp argument passed to the argument code at the moment | 18:29 |
jelmer | though one could be added, I guess | 18:29 |
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. | 18:30 |
james_w | that would probably be the cleanest way though. | 18:31 |
jdong | james_w: any hints on http://launchpadlibrarian.net/13012802/buildlog_ubuntu-hardy-i386.bzr-builddeb_0.93_FAILEDTOBUILD.txt.gz? | 18:36 |
james_w | Unable to load plugin 'builddeb' from '/build/buildd/bzr-builddeb-0.93/build/lib/bzrlib/plugins' | 18:37 |
james_w | that's annoying | 18:37 |
james_w | we need a -Dplugin_loading or something | 18:37 |
james_w | it means that I want the ~/.bzr.log to debug it | 18:38 |
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 | 18:38 |
james_w | so I don't know what the fix is exactly. | 18:39 |
james_w | perhaps just to disable the testsuite during the build. | 18:39 |
james_w | though I don't like doing that | 18:39 |
jdong | james_w: odd enough it worked in my pbuilder too.... | 18:40 |
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 | 18:40 |
james_w | thanks | 18:40 |
james_w | the other alternative is to cat ~/.bzr.log if that command fails, just so we can debug it properly | 18:41 |
=== kiko-phone is now known as kiko-afk | ||
schierbec1 | jelmer: ping | 19:02 |
jelmer | schierbec1: pong | 19:06 |
schierbec1 | jelmer: i'm tweaking the sig tab labels | 19:08 |
schierbec1 | i'm thinking: a bold headline and a longer description | 19:08 |
schierbec1 | such as: | 19:09 |
schierbec1 | *Authenticity unknown* | 19:09 |
schierbec1 | This revision has not been signed; it may be forged. | 19:09 |
schierbec1 | etc. | 19:09 |
schierbec1 | what do yuo think? | 19:09 |
schierbec1 | *you | 19:09 |
jelmer | schierbec1: The fact there is a signature doesn't say the revision is or isn't forged | 19:10 |
jelmer | schierbec1: I can forge one of your revisions and sign it. | 19:10 |
schierbec1 | jelmer: yeah, but signed + trusted key => not forged, right? | 19:11 |
jelmer | schierbec1: no, that implies you trust all people whose keys you've signed to not forge revisions | 19:11 |
schierbec1 | well, okay then | 19:11 |
schierbec1 | but then the whole idea of signatures kind of goes away | 19:12 |
schierbec1 | if you can't even trust your trusted friend to f00k you over | 19:12 |
jelmer | schierbec1: right, but that's what the whole discussion about signatures in bzrlib was about | 19:12 |
schierbec1 | jelmer: what if we match the signature name + email with the committer's? | 19:13 |
jelmer | schierbec1: yeah, that would make some sense | 19:14 |
schierbec1 | so a revision signed by its author is authentic if the key is trusted? | 19:14 |
jelmer | schierbec1: yeah | 19:14 |
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? | 19:14 |
jelmer | mdke: afaik they should be able to continue pulling if they have bzr >= 1.0 | 19:15 |
mdke | jelmer: and pushing? | 19:15 |
jelmer | mdke: pushing will still be possible too | 19:15 |
mdke | cool, thanks. but to get the benefits they need to upgrade right? | 19:16 |
jelmer | mdke: it'll be slower than it can be though, so I would highly encourage them to also upgrade to --rich-root-pack | 19:16 |
mdke | fine, thanks a lot | 19:16 |
jelmer | schierbec1: so I think we have 4 situations then: | 19:16 |
jelmer | or rather 5 | 19:16 |
schierbec1 | jelmer: so we have four cases: (unsigned), (signed - trusted), (signed + trusted - committer), and (signed + trusted + committer) ? | 19:16 |
schierbec1 | oh | 19:17 |
schierbec1 | what's the fifth? | 19:17 |
schierbec1 | well, (signed + committer - trusted) | 19:17 |
jelmer | yeah, 4 | 19:17 |
jelmer | schierbec1: no signature, signed by trusted author, signed by untrusted party, signed by trusted person (not author) | 19:17 |
mw-home | does bzr have keywords like $Id: $ ? | 19:18 |
jelmer | okay, that matches what you said | 19:18 |
jelmer | mw-home: nope, not yet | 19:18 |
schierbec1 | i think we should only handle unsigned, signed+trusted+committer and signed-trusted+committer | 19:18 |
jelmer | mw-home: there is an open specification about it but nobody working on it yet afaik | 19:18 |
schierbec1 | that's all related to authenticity | 19:18 |
jelmer | schierbec1: I think we should show if somebody who's trusted but not the author has signed | 19:18 |
schierbec1 | jelmer: yeah, but perhaps delay that a bit | 19:19 |
jelmer | schierbec1: We should clearly state that that person is not the author | 19:19 |
jelmer | schierbec1: ok | 19:19 |
jelmer | schierbec1: We should be checking against committer email btw, not author email | 19:19 |
schierbec1 | jelmer: i think we should have an 'Authenticity' section | 19:19 |
schierbec1 | okay | 19:19 |
jelmer | schierbec1: also, if the revision is signed by somebody untrusted it's not relevant if that key's email matches the committer email | 19:20 |
jelmer | since we can't trust the email on the key to be valid | 19:21 |
schierbec1 | exactly | 19:21 |
schierbec1 | jelmer: but we may like to provide the user with the option of trusting the key | 19:22 |
jelmer | schierbec1: we should leave that to specific apps such as seahorse imo | 19:22 |
schierbec1 | if he's spoken with the committer and knows the revision is authentic, we can then trust it (marginally) | 19:22 |
schierbec1 | jelmer: seahorse is meant to be integrated like that -- no ordinary user will open up a key manager | 19:23 |
jelmer | schierbec1: I think we should allow launching a key details dialog or something from seahorse | 19:23 |
mw-home | jelmer: thanks for the information. | 19:24 |
jelmer | but we shouldn't have a "trust this person" key, that's really outside of the scope of bzr-gtk | 19:24 |
schierbec1 | jelmer: i'm not sure -- if that's the way the user extends his trust network? | 19:25 |
jelmer | schierbec1: signing keys should involve identity verification and the like | 19:26 |
jelmer | schierbec1: also, seahorse already deals with this task, let's not reimplement that bit | 19:27 |
jelmer | afaik the key information diaog from seahorse has buttons for trusting the key | 19:27 |
schierbec1 | jelmer: allright, but perhaps we can have a look at it in the future | 19:27 |
=== kiko-afk is now known as kiko | ||
schierbec1 | jelmer: does it still throw exceptions at you? | 19:29 |
schierbec1 | i talked with a seahorse dev, he said the api didn't change | 19:29 |
schierbec1 | jelmer: btw, i've pushed to lp, you can check out the new headings | 19:29 |
jelmer | schierbec1: yep, still errors | 19:30 |
jelmer | Invalid key id: | 19:30 |
schierbec1 | can you print out the key? | 19:30 |
jelmer | this is on your signed revisions | 19:30 |
schierbec1 | it should be of the format "openpgp:<key>" | 19:31 |
jelmer | it works fine for my own signed revisions | 19:31 |
jelmer | such as 14.1.1 (in bzr-gtk) | 19:31 |
jelmer | schierbec1: The "Authenticity confirmed" bit is incorrect until we're checking the author email == key email | 19:33 |
schierbec1 | jelmer: yeah, this is just the ui bits, i'll add the comparison asap | 19:33 |
schierbec1 | jelmer: can you add a print in crypt.py so i can see what the key looks like? | 19:34 |
=== mw is now known as mw|food | ||
jelmer | sure | 19:34 |
jelmer | what/where? | 19:34 |
schierbec1 | just in Key.__init__() | 19:34 |
schierbec1 | print key | 19:34 |
schierbec1 | jelmer: it may also be that my key is not fetched from the server | 19:35 |
jelmer | schierbec1: We should not rely on seahorse being able to fetch a key | 19:37 |
jelmer | schierbec1: since you may be offline, for example | 19:37 |
jelmer | schierbec1: I think I also have automatic key fetching turned off in gpg since it is slow | 19:37 |
schierbec1 | jelmer: i'm not completely sure what the protocol is, but the docs mention that a key may be "missing" at first | 19:38 |
schierbec1 | jelmer: but that may very well be the problem | 19:38 |
schierbec1 | jelmer: i'd like to try something: in __init__(), replace "discover(key)" with "discover(self.get_id())" | 19:39 |
schierbec1 | that's just to see if the api's changed | 19:39 |
jelmer | schierbec1: that changes the error back to the list index out of range exception | 19:42 |
jelmer | schierbec1: what does DiscoverKeys() do exactly? | 19:43 |
jelmer | does that try to fetch the key from the web? | 19:43 |
schierbec1 | yup, or the local network | 19:45 |
schierbec1 | i'd like to see the value of "key" -- can you print it out? | 19:45 |
jelmer | schierbec1: key is an empty string | 19:45 |
schierbec1 | it sounds like VerifyText returns something stupid | 19:45 |
schierbec1 | hmm | 19:45 |
jelmer | schierbec1: seahorse also has an option to automatically discover keys as they are requested | 19:46 |
schierbec1 | what about cleartext in crypt.verify() ? | 19:46 |
jelmer | schierbec1: I'd rather rely on that | 19:46 |
jelmer | schierbec1: cleartext does indeed contain the testament | 19:47 |
schierbec1 | that's funny -- the "key" return value is just empty?! | 19:48 |
jelmer | schierbec1: dbus.String(u'') | 19:48 |
schierbec1 | ? | 19:50 |
jelmer | schierbec1: "print repr(key)" prints dbus.String(u'') | 19:50 |
schierbec1 | 3 seconds, on the phone | 19:51 |
schierbec1 | jelmer: sorry, my mom called | 19:56 |
schierbec1 | hehe, a bit hard to just hang up... | 19:56 |
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 | 19:57 |
jelmer | schierbec1: s/invalid/unknown? | 19:58 |
jelmer | since it could be trusted | 19:58 |
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 | 19:58 |
schierbec1 | jelmer: exactly, but i guess we'll just mark it as unsigned or what? | 20:00 |
jelmer | schierbec1: unknown should be a separate thing imho | 20:00 |
schierbec1 | jelmer: okay, like "error verifying key"? | 20:02 |
schierbec1 | oh, the seahorse guy is responsive now, i'll ask him | 20:02 |
jelmer | schierbec1: ah, cool | 20:03 |
jelmer | schierbec1: it would be nice if seahorse could actually return the key id there | 20:03 |
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 | 20:04 |
schierbec1 | yup | 20:04 |
schierbec1 | jelmer: could i get you to pastebin the crypttext of a revision that doesn't work? | 20:09 |
schierbec1 | in crypt.verify() | 20:09 |
jelmer | http://pastebin.org/26731 | 20:11 |
schierbec1 | yeah, that looks like it should | 20:11 |
schierbec1 | i'm talking with the seahorse guy, it seems that it's because the key is not in your keyring | 20:12 |
jelmer | schierbec1: right, and it shouldn't have to be | 20:12 |
jelmer | I mean, seahorse should be able to return the key idea | 20:13 |
jelmer | and we could print something like "signature from unknown key YYYY" | 20:13 |
schierbec1 | jelmer: exactly | 20:14 |
schierbec1 | right now, i think we should just write "Authenticity cannot be verified -- Key not available" | 20:14 |
jelmer | right, that makes sense | 20:15 |
=== mwhudson_ is now known as mwhudson | ||
schierbec1 | jelmer: okay, pushing a fix to lp | 20:20 |
schierbec1 | let's see if this works | 20:21 |
jelmer | schierbec1: yep, works now - thanks | 20:22 |
schierbec1 | cool | 20:22 |
jelmer | schierbec1: This should not be marked as Authentication error imho | 20:22 |
schierbec1 | i was just about to ask | 20:22 |
schierbec1 | what do you think? "Authenticity cannot be verified"? | 20:23 |
schierbec1 | s/verified/confirmed/ | 20:23 |
jelmer | yep, that sounds good | 20:24 |
=== mw|food is now known as mw | ||
schierbec1 | jelmer: ok, it's pushed | 20:25 |
schierbec1 | jelmer: just one last thing -- try replacing VerifyText with DecryptText | 20:25 |
schierbec1 | it could be an error in the VerifyText implementation | 20:26 |
jelmer | "No data" | 20:26 |
schierbec1 | hmm, well, ok then | 20:27 |
schierbec1 | jelmer: i think i'll rewrite the descriptions | 20:27 |
jelmer | schierbec1: we shouldn't be calling discover() imho | 20:28 |
schierbec1 | we're not anymore | 20:28 |
jelmer | my bad, it's just the function that's still there | 20:28 |
jelmer | sorry | 20:28 |
schierbec1 | "The revision has been signed by a person you trust" ? | 20:28 |
schierbec1 | s/The/This/ ? | 20:28 |
jelmer | and which person, if possible :-) | 20:29 |
schierbec1 | or rather "... signed with a trusted key" ? | 20:29 |
schierbec1 | jelmer: yeah :) | 20:29 |
jelmer | I'd prefer "signed with a trusted key " | 20:29 |
schierbec1 | okay | 20:29 |
schierbec1 | and then "This revision has been signed, but you do not trust the authenticity of the key." | 20:30 |
jelmer | what about "This revision has been signed with an untrusted key" ? | 20:32 |
schierbec1 | jelmer: i think it's perhaps too close to the trusted version | 20:33 |
schierbec1 | just two letters apart | 20:33 |
schierbec1 | we should emphasize that it's not trusted, as a signature in itself means nothing | 20:33 |
jelmer | we need more colored icons :-) | 20:35 |
Kinnison | Is bzr currently unable to branch from launchpad? | 20:35 |
Kinnison | I was trying to get the gedit plugin and bzr says it's not a branch | 20:35 |
schierbec1 | jelmer: always :) | 20:36 |
schierbec1 | jelmer: i'm working out a seahorse patch with the dev guy | 20:36 |
jelmer | schierbec1: cool | 20:36 |
* Kinnison hrms, also can't bzr pull from the bzr-svn branch | 20:38 | |
Kinnison | perhaps launchpad is moosed | 20:38 |
jelmer | Kinnison: I think there was a regression in bzr.dev that breaks it with launchpad or something | 20:43 |
Kinnison | jelmer: arse | 20:45 |
Kinnison | oh well | 20:45 |
Kinnison | no bzr-svn for me until that's fixed :-) | 20:45 |
james_w | Kinnison: you should be able to pull over bzr+ssh:// | 20:46 |
schierbec1 | jelmer: what about "This signature has been signed, but the authenticity of the signature cannot be trusted."? | 20:46 |
Kinnison | james_w: from a branch I don't own? | 20:46 |
james_w | Kinnison: yeah, you don't need write permission to pull | 20:46 |
Kinnison | schierbec1: "...signature has been signed..." ? | 20:46 |
Kinnison | james_w: I was more incredulous about having ssh access to branches I didn't own | 20:47 |
* Kinnison didn't know that was allowed | 20:47 | |
Kinnison | I thought launchpad virtual-chrooted you | 20:47 |
schierbec1 | Kinnison: bzr-gtk ui bits for signed revisions | 20:47 |
schierbec1 | oops, s/signature/revision/ | 20:47 |
Kinnison | schierbec1: aah, suddenly it makes more sense :-) | 20:47 |
schierbec1 | hehe | 20:47 |
schierbec1 | jelmer: could i get you to check out a patch for seahorse? | 20:49 |
schierbec1 | svn://svn.gnome.org/svn/seahorse/trunk/ | 20:49 |
schierbec1 | only if you have time | 20:49 |
jelmer | schierbec1: sure | 20:50 |
jelmer | schierbec1: or http://people.samba.org/bzr/jelmer/seahorse/jelmer :-) | 20:52 |
schierbec1 | :) | 20:53 |
schierbec1 | http://pastebin.com/d24eb0110 | 20:53 |
schierbec1 | here's the patch | 20:53 |
schierbec1 | jelmer: "This revision has been signed, but the authenticity of the key has not been established"? | 20:56 |
schierbec1 | perhaps s/key/signature/? | 20:56 |
schierbec1 | just chime in, everybody! | 20:56 |
jelmer | schierbec1: I'd rather just say that the key is unknown or untrusted | 21:00 |
schierbec1 | ok | 21:02 |
schierbec1 | jelmer: "... but the key is not trusted."? | 21:02 |
jelmer | schierbec1: yep | 21:03 |
schierbec1 | jelmer: have you tried out the patch? | 21:05 |
jelmer | working on it | 21:05 |
schierbec1 | cool | 21:05 |
beuno | vila, I've got 2 hours separated for the upload plugin today, so I'll give you the feedback I owe you :) | 21:05 |
vila | beuno: great ! | 21:06 |
mwhudson | beuno: hi! | 21:09 |
jelmer | schierbec1: yep, that patch fixes it | 21:09 |
schierbec1 | jelmer: awesome! | 21:11 |
beuno | hey mwhudson! welcome back :) | 21:12 |
ubotu | New bug: #210422 in bzr-gtk "gpg signer should be part of ui_factory" [Undecided,New] https://launchpad.net/bugs/210422 | 21:12 |
schierbec1 | jelmer: well, now we just have to wait 6 months until the next stable is released! :) | 21:16 |
jelmer | :-) | 21:17 |
chell | hi | 21:17 |
chell | hey | 21:18 |
emgent | http://nopaste/p/aMZkktaSw | 21:18 |
emgent | some idea? | 21:18 |
emgent | bzr locked. | 21:18 |
chell | emgent: nope sorry | 21:18 |
chell | "locked 123 hours, 27 minutes ago" sounds a bit weird | 21:19 |
jelmer | try bzr break-lock | 21:19 |
emgent | jelmer: same error.. | 21:19 |
emgent | :| | 21:20 |
beuno | emgent, try a few times more (sometimes LP locks it a few times) | 21:22 |
emgent | beuno: to push or brack-lock ? | 21:24 |
beuno | emgent, break lock | 21:24 |
beuno | emgent: bzr break-lock bzr+ssh://emgent@bazaar.launchpad.net/~emgent/ubuntu-cve-tracker/universe-security-updates | 21:25 |
beuno | 3 or 4 times should do it :) | 21:25 |
emgent | yes i know | 21:25 |
emgent | but same problem | 21:25 |
emgent | ok :) | 21:25 |
beuno | emgent, still nothing? | 21:25 |
emgent | ok now work :) | 21:27 |
beuno | emgent, :) | 21:27 |
emgent | thanks | 21:28 |
* beuno wonders when LP will fix that bug | 21:28 | |
schierbec1 | jelmer: okay, now we just need to figure out what to do if seahorse isn't installed | 21:30 |
jelmer | schierbec1: hide the signature tab :-) | 21:35 |
schierbec1 | jelmer: yeah, but we should add a check for seahorse :) | 21:41 |
schierbec1 | the branch is in the team repo, so you can just commit changes if you wish to | 21:42 |
schierbec1 | jelmer: what do you think about left-aligning the table "keys"? | 21:51 |
schierbec1 | i.e. the bold labels | 21:51 |
mdke | how can I make changes to the details of my "parent" or "submit" branch? | 22:07 |
beuno | mdke, what kind of changes? | 22:07 |
mdke | beuno: well, remove them or specify another branch | 22:08 |
beuno | mdke, just use bzr push/pull/merge new_location --remember | 22:08 |
mdke | thanks | 22:08 |
* jdong investigates bzr mailing list... did he break bzrtools? | 22:09 | |
beuno | :) | 22:09 |
jdong | it worksforme.... | 22:10 |
beuno | jdong, he probably has pycentral b0rked | 22:11 |
jdong | beuno: also see bug 210452 though | 22:11 |
ubotu | Launchpad bug 210452 in bzrtools "error updating bzrtools" [Undecided,New] https://launchpad.net/bugs/210452 | 22:11 |
jdong | it seems like a different reporter | 22:12 |
jdong | perhaps it only happens on an update? | 22:12 |
james_w | jdong: there's a load of bugs filed with this error | 22:12 |
james_w | on different packages | 22:12 |
james_w | I can't remember the fix offhand, I think it might have been rebuilds, but that doesn't make sense here | 22:12 |
james_w | https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/197840 is one | 22:13 |
ubotu | Launchpad bug 197840 in bzr-svn "bzr-svn fails to install (Ubuntu Hardy, with ppa bzr)" [Undecided,Fix released] | 22:13 |
=== mwhudson_ is now known as mwhudson | ||
james_w | https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/197692 | 22:13 |
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] | 22:13 |
james_w | that's the one | 22:13 |
jdong | odd | 22:14 |
james_w | jdong: yeah | 22:27 |
james_w | jdong: passing it on to python-central may be the right thing to do, I don't know | 22:28 |
james_w | I don't really know what bzrtools might have done to provoke this | 22:28 |
james_w | although, hang on, bzrtools was a merge, so maybe something was dropped | 22:28 |
james_w | or maybe not dropped, but needs to be improved. | 22:29 |
xma | 'lo | 22:59 |
xma | why does bb crash so often ? | 23:00 |
lifeless | does it ? | 23:01 |
xma | :) | 23:04 |
xma | each time I want to read patch entries => no luck (500 internal error) | 23:04 |
lifeless | xma: whats the last couple of lines of the traceback? | 23:10 |
xma | each time I have seen it, it was a SQL query | 23:11 |
poolie | hello xma | 23:11 |
lifeless | let abentley know, probably via the list | 23:11 |
poolie | i think it crashes pretty often | 23:11 |
xma | poolie: hello | 23:11 |
poolie | all things considered | 23:12 |
poolie | i still love it deeply | 23:12 |
xma | yes it is very valuable | 23:12 |
xma | (when it works :)) | 23:12 |
abentley | It crashes so often mainly because I don't know why it crashes so often :-) | 23:12 |
xma | I learnt many python related things when reading people's patches | 23:12 |
xma | abentley: hey aaron | 23:13 |
xma | 00:04 <lifeless> let abentley know, probably via the list | 23:13 |
xma | ;) | 23:13 |
xma | so it is down now: OperationalError database is locked | 23:13 |
xma | gotta go now | 23:14 |
xma | see ya all | 23:14 |
poolie | hello abentley | 23:18 |
abentley | poolie: hi | 23:19 |
poolie | there was a recent bug report of a failure in treetransform | 23:19 |
poolie | if you get a sec could you comment on it, if you have not already? | 23:19 |
abentley | Okay | 23:19 |
poolie | it should still be in the recent list | 23:19 |
igc | morning all | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!