| bignose | I have a Bazaar checkout from a Git repository | 00:54 |
|---|---|---|
| bignose | and then a Bazaar branch from that. | 00:54 |
| bignose | but the branch fails to ‘diff’ or most other commands: | 00:55 |
| bignose | $ bzr diff | 00:55 |
| bignose | === modified file 'po4a/po/devscripts.pot' | 00:55 |
| bignose | bzr: ERROR: Revision {('po4a/po/devscripts.pot', 'git-v1:343d00558577b9bc12c381850cdb804658547bb8')} not present in "CHKInventoryRepository('file:///home/bignose/Projects/debian/devscripts/.bzr/repository/')". | 00:55 |
| bignose | the traceback from the log file is at <URL:http://pastebin.ca/2011597> | 01:19 |
| spiv | bignose: possibly the same as https://bugs.launchpad.net/bzr-git/+bug/649531 | 01:22 |
| ubot5` | Ubuntu bug 649531 in Bazaar Git Plugin "mesa incremental import fails with bzrlib.errors.RevisionNotPresent" [Medium,Triaged] | 01:22 |
| spiv | bignose: probably needs jelmer to diagnose it | 01:23 |
| spiv | If it's an import originally from an older bzr/bzr-git, then *maybe* making a fresh import would help. | 01:24 |
| bignose | spiv: how about if I just upgraded the repository from rich-root-pack to 2a format? | 01:25 |
| bignose | it's a shared repository. should it be enough to blow away the checkout and get it again, or will I need to trash the whole repository? | 01:26 |
| spiv | The whole repository, it's a problem in the repository, not the checkout. | 01:30 |
| spiv | Upgrading shouldn't resolve the problem, upgrading can't fill in the missing data. | 01:30 |
| spiv | It just copies the records from the old format into the new format. | 01:31 |
| bignose | okay, thanks. I'll try it. | 01:31 |
| spiv | If you do make a new import, I'd definitely suggest making it in 2a format though :) | 01:31 |
| spiv | My guess is its a bzr-git bug. | 01:32 |
| bignose | yes, my Bazaar is new enough to make 2a format by default :-) | 01:34 |
| bignose | the repository is a couple of years old though. | 01:35 |
| bignose | s/is/was/ blown it away now and starting afresh. | 01:35 |
| bignose | spiv: fixed, thank you. whatever the problem was in the old repository, it's gone now. | 01:37 |
| spiv | Glad I could help. | 01:38 |
| glyph | spiv: My blog post got absolutely no reaction! I guess the problem is not as common as I thought :-) | 04:53 |
| spiv | glyph: That seems about right to me :) | 04:57 |
| vila | hi all ! | 07:04 |
| vila | spiv: did your patch about the uninitialized https socket got merged upstream ? | 07:05 |
| poolie | hi vila | 07:05 |
| vila | poolie: hey ! | 07:05 |
| vila | poolie: did you get any news from Gary ? | 07:05 |
| poolie | not recently | 07:09 |
| vila | I noticed that we have ~35 New bugs in the 'bzr (Ubuntu)' project, I haven't checked which ones are really packaging ones but I think we should have a look there (I think there is still no way to just re-affect them to 'bzr' itself). | 07:09 |
| poolie | correct, you can't mark them against only upstream :/ | 07:10 |
| vila | I mailed him last week but got no reply :-/ | 07:10 |
| spiv | vila: I don't even remember that patch... | 07:10 |
| poolie | you can make them either invalid or just leave them open and then close when they're finished | 07:10 |
| spiv | vila: oh, yes I do | 07:10 |
| vila | spiv: the one that takes care.. :) | 07:10 |
| vila | poolie: I meant, bugs that are not targeted at 'bzr' itself and as such unknown to us | 07:11 |
| spiv | vila: and it was merged upstream, and the patch added to the ubuntu package too | 07:11 |
| vila | spiv: really ? Great ! Which python version ? | 07:11 |
| poolie | vila, i know, i'm just talking about the options after we look at them | 07:12 |
| poolie | i thought i was subscribed to ubuntu/bzr | 07:12 |
| poolie | we could probably do with a poll every so often to clean them out | 07:12 |
| poolie | my laptop filesystems died again on the weekend :/ | 07:12 |
| poolie | i think the SSD is dying | 07:12 |
| spiv | vila: 2.7 I believe. http://bugs.python.org/issue9729 | 07:12 |
| vila | I still encounter it at least on jaunty and osx recently and wanted to work around it (it occurs during client shutdown so we can catch the TypeError exception without too much risk) | 07:12 |
| vila | spiv: thanks | 07:13 |
| vila | poolie: urgh, that sucks | 07:13 |
| vila | poolie: how old is it ? Do you have /tmp or swap on it ? | 07:15 |
| poolie | it's about 18m old | 07:16 |
| poolie | i did have a swap partition, because otherwise there is too much of a cliff when you run out of ram | 07:17 |
| vila | weird, mine is far older than that and I had /tmp on it for months before realizing it | 07:17 |
| poolie | but i had /tmp in a tmpfs, and atimes turned off etc | 07:17 |
| poolie | it's still showing 97% erase life left | 07:17 |
| poolie | however, reading the error logs give a checksum error, which some people think means the controller is failing | 07:17 |
| vila | ouch | 07:18 |
| poolie | so, i'm going to try to return it under warranty, and if they won't swap it i'll stick with the magnetic disk | 07:18 |
| poolie | that originally came in my laptop | 07:18 |
| vila | 97% erase like left ? Where do you get that ? | 07:18 |
| poolie | 'smartctl -A /dev/sda' shows (at least on this drive) that, amongst other things | 07:18 |
| vila | I don't even this command :-/ | 07:19 |
| vila | Oh, from the smart data ? | 07:19 |
| vila | ha yes, endurance remaining: N/A, I guess mine is too old to even implement that... | 07:20 |
| vila | in fact, everything is N/A, all I have is: 'Disk is healthy'... I'm glad I asked... | 07:21 |
| vila | :) | 07:21 |
| vila | having another look at these 'bzr (ubuntu)' bugs: 35 New, 70 Open... | 07:22 |
| vila | I am subscribed though as many of them rings a bell, it's just that I forget about them because I never see them again when going to lp... | 07:23 |
| lifeless | vila: does the link in the UI help ? | 07:24 |
| vila | lifeless: which one ? | 07:33 |
| vila | lifeless: 'also affects project' ? | 07:33 |
| vila | my problem here is that I didn't realize these bugs were existing as I always look at the 'bzr' bugs on lp, never at the 'bzr (Ubuntu)' ones, so they are abandoned | 07:35 |
| vila | that's not as bad as I thought, though, many of them are targeted at both | 07:36 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.copingeling aboutm/ | Patch pilot: vila | 2.3b4 is frozen, installers build time ! (rm vila) | ||
| lifeless | vila: vila the link at the top of https://bugs.launchpad.net/bzr | 07:49 |
| lifeless | "Ubuntu also tracks bugs for packages derived from this project: bzr in ubuntu." | 07:49 |
| vila | ooooh, shiny, yup, exactly, thanks | 07:50 |
| sobersabre | hi. I have bzr repository of version 2a on machine A | 08:56 |
| sobersabre | and I have a machine B with older version of bzr installed. | 08:56 |
| sobersabre | should I expect any problem by pulling the machine A's repo to machine B ? | 08:56 |
| sobersabre | would bzr manage to do the conversion from 2a to 1* ? | 08:57 |
| bob2 | how old is it? | 08:57 |
| sobersabre | bob2: let's speak in bzr versions. | 08:57 |
| bob2 | so 'absurdly'? :) | 08:57 |
| sobersabre | the 2a one has version of bzr 2.3b1 | 08:58 |
| sobersabre | the older has bzr v 1.5-1.1 | 08:58 |
| spiv | sobersabre: bzr can convert from 2a to some older formats, the oldest compatible one is rich-root-pack which was introduced in bzr 1.0. | 08:59 |
| * sobersabre has 'absurdly' missed the humor. would still like an explanation. | 08:59 | |
| mwhudson_ | that's pretty old | 08:59 |
| spiv | Obviously you need to use a bzr new enough to read 2a to do the conversion :) | 08:59 |
| sobersabre | so, shall I maybe install a backport of 2.x for lenny ? is there one ? | 08:59 |
| sobersabre | spiv: maybe you're so close to 2a, it is obvious for you. but it is sure not obvious for me. | 09:00 |
| sobersabre | I mean internal repo structure is one thing, and pulling it via an API is another... which is obvious for me. | 09:00 |
| spiv | Basically "bzr init-repo --format=rich-root-pack repo-for-bzr-1.0; bzr branch your-repo/foo repo-for-bzr-1.0/foo" | 09:00 |
| sobersabre | and incidentally both API and the repo structure can collide. only incidentally.. | 09:00 |
| spiv | sobersabre: I don't quite follow you. | 09:01 |
| sobersabre | I mean the bzr operation doesn't have to expose repository structure AS IS to the bzr puller. | 09:01 |
| sobersabre | and API can be transparent to the internal structure. | 09:01 |
| sobersabre | so this would allow interoperability between various versions of bzr pullers. | 09:02 |
| spiv | sobersabre: I'd expect e.g. MS Word 2010 to be able to read MS Word 2010 format docs, and save them as MS Word 2007 format. But I wouldn't expect MS Word 2007 to be able to do that. | 09:02 |
| sobersabre | still not with me ? | 09:02 |
| sobersabre | spiv: you are the one who started with "obvious"ities. :) | 09:02 |
| sobersabre | I gave you mine.... ... ... | 09:02 |
| sobersabre | anyway.. thanks, It's good I asked. | 09:03 |
| spiv | I don't know what you mean when you say "bzr operation" and "bzr puller", especially when you talk about them as separate things. | 09:03 |
| vila | sobersabre: in theory yes, in practice no, if you try to pull from a branch/repository in an unknown (to your local bzr) format, bzr shold tell you (the format string includes the minimal bzr version needed) | 09:06 |
| vila | sobersabre: i.e. : Bazaar repository format 2a (needs bzr 1.16 or later) | 09:07 |
| sobersabre | spiv: I must explain: let's call the machine I'm pulling from "S" (source), and the machine I'm pulling to "D" (destination). | 09:07 |
| sobersabre | if S has bzr 2.3 and D has bzr 1.5, we have "a situation". | 09:07 |
| sobersabre | unless user specifies instruction to his bzr to do something special. | 09:08 |
| sobersabre | instead it would be transparent to develop a "sharing API", i.e. something with no regards to repository structure, but rather to files, revisions, comments, without the bits of which storage, which fs is used, etc. | 09:09 |
| sobersabre | and it would render bzr to be less cumbersome for its users. | 09:09 |
| sobersabre | look at me - I'm spending about an hour or two to make sure I manage to pull :) maybe I should've pulled with error already.... | 09:10 |
| vila | sobersabre: this works as long as both bzrs know enough about the format used... and that's what bzr does | 09:11 |
| spiv | sobersabre: well, use an older format that both bzr versions have in common. | 09:11 |
| spiv | sobersabre: in this case rich-root-pack. | 09:11 |
| vila | sobersabre: for new formats, old bzrs should give the right messages, if not that's a bug... hopefully fixed in newer versions :-P | 09:11 |
| spiv | sobersabre: there are more complex possiblities, like using export/import tools. | 09:12 |
| vila | sobersabre: if I read http://packages.debian.org/search?keywords=bzr correctly, lenny-backports should give you 2.0.3 which is good enough to handle 2a | 09:12 |
| vila | sobersabre: I'm not a debian expert by far though :) | 09:13 |
| vila | sobersabre: we try to preserve backward compatibility as much as we can, but we also want to make bzr better, so far all formats ever used by bzr can still be read by the current bzr. We only remove support for some development formats recently but these ones were highly publicized as being supported for a short period of time and the migration to the supported formats as always been implemented. Just mentioning that we *do* care about compa | 09:19 |
| vila | tibility and interoperability. | 09:19 |
| vila | that sentence was too long :) | 09:19 |
| fullermd | It didn't have any good tpyos in it either. Two strikes. | 09:21 |
| vila | :) | 09:21 |
| sobersabre | guys, thanks, I'm just a bit trolling. don't take it too seriously. I'm not a seasoned bzr user. still picking up it's bzr-speak. | 09:45 |
| vila | sobersabre: no problem :) Self-proclaimed trolls are ok ;) As long as we can help you find your way, feel free to ask ! | 09:51 |
| mgolisch | does bzr support kerberos authentication? | 10:26 |
| jelmer | mgolisch: only over ftp | 10:27 |
| mgolisch | too bad | 10:27 |
| jelmer | actually, http might work too | 10:29 |
| * jelmer recalls working on it but isn't sure whether it actually landed | 10:29 | |
| mgolisch | basicaly id like to host stuff in a bzr repo, provide some shiny webinterface for browsing the branches/projects and somehow enable sso authentication | 10:30 |
| mgolisch | so youd not have to type a password all the time | 10:30 |
| mgolisch | managing ssh keys seems like a pain in the butt | 10:31 |
| vila | mgolisch: ssh agents *are* the best sso engine I know of ;) You should try them IMHO | 10:32 |
| mgolisch | that still requires generating ssh keys | 10:33 |
| mgolisch | and to deploy them to the users | 10:33 |
| vila | But they allow defining a single user on the server reducing the maintenance to a single file there (containing the allowed ssh keys) | 10:35 |
| mgolisch | how would i differenciate between them then? | 10:36 |
| vila | by their ssh key ? | 10:36 |
| mgolisch | oh yeah | 10:36 |
| mgolisch | whatever guess thats what ill do then | 10:37 |
| vila | ftp is not the best protocol for bzr as far as performances are concerned too, using a smart server scales far better | 10:38 |
| vila | mgolisch: you can have a look into the crontrib directory for bzr_access and bzr_ssh_path_delimiter for various approaches at finer grained control access too | 10:38 |
| mgolisch | is there some easy way to predefine the host it tries to connect to? | 10:39 |
| vila | you mean in a centralized workflow ? | 10:39 |
| mgolisch | or defining somekind of shorthand/shortcut notation like with launchpad? | 10:39 |
| vila | yes you can, the simplest being via the bookmarks plugin (lp:bzr-bookmarks) | 10:40 |
| mgolisch | there will only be used that one server anyways, its for inhouse development of apps and scripts and whatnot | 10:40 |
| mgolisch | so id would be easier of the users would not have to type the full repository url all the time | 10:41 |
| vila | you can also have a look at the launchpad plugin itself (in bzrlib/plugins) for a more sophisticated approach, that's where the lp:, ubuntu: and debian: shortcuts are handled (in lp_directory.py specifically) | 10:42 |
| mgolisch | cool ill look into that | 10:42 |
| vila | mgolisch: but note that they need to type the full URL only once, bzr will remember it from there | 10:42 |
| mgolisch | thx alot | 10:42 |
| vila | well, once for branch/chekout/push/merge, i.e. once for every operation that will need to use the same URL repeatedly (look for the --remember parameter in the commands) | 10:43 |
| vila | the first command use remembers the URL provided so you don't have to specify it for further incantations | 10:44 |
| vila | mgolisch: 'bzr info' will summarize the urls already known in a given branch | 10:45 |
| piranha | hi. Is it possible to downgrade 2.0 format to 0.92 format? | 10:56 |
| piranha | I thought about exporting patches as text and then applying it to newly created repository, but I can't find how to create text patches... | 10:56 |
| spiv | piranha: no, although you can downgrade to rich-root-pack, which works with bzr 1.0 | 10:57 |
| piranha | hm, ok, I'll try | 10:57 |
| piranha | eh | 10:58 |
| piranha | spiv: this doesn't work, my server wants 0.92 :( | 10:58 |
| spiv | piranha: if you want to export/import, there's the fastimport plugin, but it will generate a new, unrelated revision history you can't merge from, etc. | 10:58 |
| piranha | I don't care about merging for this repository, so ok, I'll try it | 10:58 |
| piranha | thanks | 10:58 |
| spiv | 0.92 is over 3 years old. | 10:58 |
| piranha | I know | 10:59 |
| piranha | I can't do anything about it :( | 10:59 |
| spiv | That's a shame. The 2a format is much smaller and faster :( | 11:00 |
| piranha | heh, python-fastimport is registered on PyPI, but that's not possible to install it from there. That's dumb :\ | 11:03 |
| jelmer | piranha: the python-fastimport is not the fastimport plugin for bzr | 11:04 |
| piranha | I know, but it is required by bzr-fastimport | 11:04 |
| jelmer | right | 11:05 |
| piranha | yahoo | 11:05 |
| piranha | it worked | 11:05 |
| piranha | spiv: thank you | 11:05 |
| === init is now known as GiantEnemyCrab | ||
| === GiantEnemyCrab is now known as Elizabeth | ||
| === Elizabeth is now known as init | ||
| mgolisch | is there some way to get information about repositories on a dumb server? | 13:24 |
| Peng | mgolisch: "bzr info" can take a remote location. | 13:24 |
| mgolisch | like i know the base path is /bzr/ can i have a list of all directories found under that? or maybe even which of those are actual bzr repositories? | 13:24 |
| Peng | mgolisch: If the dumb server supports directory listings (HTTP may not, since they're unstandardized pages), you can use the "bzr branches" command from the bzrtools plugin. If you want to find all .bzr directories or all repositories, it's simple enough to do via bzrlib in the python prompt. | 13:27 |
| Peng | (Usual disclaimer: This is all six-month-old information. I haven't been paying attention recently.) | 13:28 |
| mgolisch | thx | 13:45 |
| mgolisch | thanks that bzr branches thing seems to do what i wanted | 13:53 |
| mgolisch | thx alot | 13:54 |
| mgolisch | wow theres a custom_url_schemes plugin | 14:13 |
| mgolisch | that looks like exactly what i was looking for | 14:13 |
| mgolisch | to get rid of those endlessly long sftp urls | 14:14 |
| awilkins | Can you do the opposite of `bzr revert --forget-merges` ; ie, revert all the changes back to the HEAD of the merge-target without forgetting the merge status? | 14:16 |
| Peng | awilkins: bzr revert . | 14:17 |
| awilkins | Aha | 14:17 |
| === Ursinha is now known as Ursinha-lunch | ||
| awilkins | Did the merge in git - bless it, one tree is the same as another to it, even if the user deleted all the files then put them back again | 14:18 |
| Peng | Blasphemer. :P | 14:19 |
| awilkins | Doesn't go over so well in Bazaar though - "AAARGHH, EVERYTHING is a merge conflict!!!11"" | 14:19 |
| mgolisch | sweet that custom_url_schemes thing seems to work | 14:19 |
| mgolisch | now iam all set | 14:19 |
| mgolisch | :) | 14:19 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === deryck is now known as deryck[lunch] | ||
| jam | morning all | 15:40 |
| Peng | Good morning. :) | 15:41 |
| jelmer | hi jam | 15:41 |
| vila | morning jam ! | 15:41 |
| === beuno is now known as beuno-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| === Ursinha is now known as Ursinha-brb | ||
| === Ursinha-brb is now known as Ursinha | ||
| dobey | hi all | 21:13 |
| mwhudson | hello dobey | 21:17 |
| dobey | any idea why ssh would be held open when doing a bzrlib.branch.Branch.open() on a lightweight checkout? | 21:20 |
| lifeless | opening a working tree opens its branch and repository objects | 21:22 |
| lifeless | by design | 21:22 |
| lifeless | a lightweight co is a working tree and remote branch and repo | 21:22 |
| mkanat | dobey: There was a thread about it on the mailing list a little while back. | 21:31 |
| poolie | hi mkanat | 21:31 |
| poolie | hi jam? | 21:31 |
| jam | hi poolie | 21:32 |
| mkanat | Hey poolie. :-) | 21:32 |
| poolie | hi there | 21:32 |
| dobey | i mean, why it would get held open after the python script that imports bzrlib exits (causing a hang due to waitpid somewhere in bzrlib) | 21:32 |
| jam | dobey: IIRC, paramiko uses background threads, there was also a recent bug about sftp connections not getting close | 21:32 |
| jam | closed | 21:32 |
| jam | dobey: bug #659590 | 21:34 |
| ubot5` | Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590 | 21:34 |
| mkanat | poolie: I'm totally waiting on MPs, at the moment. | 21:35 |
| mkanat | poolie: That is, on reviews. | 21:35 |
| poolie | mkanat: oops, i'll try to unblock you, and i hope spiv can help too | 21:36 |
| spiv | Good morning. | 21:36 |
| * poolie moves it to the top of my list | 21:36 | |
| spiv | I can take a look too. | 21:36 |
| mwhudson | huh, i can't approve https://code.edge.launchpad.net/~mkanat/loggerhead/launchpad/+merge/42338 | 21:37 |
| dobey | jam: interesting. thanks | 21:43 |
| mkanat | There are two MPs I have up--one for loggerhead and one for the launchpad branch of loggerhead. | 21:43 |
| poolie | mwhudson: me either; i guess only ~launchpad-pqm can approve them? | 21:45 |
| poolie | (the rules here are a bit opaque) | 21:45 |
| mwhudson | yeah, maybe the review team needs setting on the target branch? | 21:45 |
| mwhudson | of course, launchpad code hackers can twiddle all of these things | 21:45 |
| poolie | how? | 21:48 |
| jam | phenominal cosmic powers | 21:52 |
| jam | Would be my guess | 21:52 |
| === Ursinha is now known as Ursinha-afk | ||
| dobey | jam: hrmm, that fix doesn't seem to work for where i'm seeing the problem; but adding proc.terminate before proc.wait in the funcs list in _close_ssh_proc() does | 21:56 |
| jam | dobey: that would indicate that the ssh session itself is expecting something to happen | 21:57 |
| jam | killing it isn't the nicest thing, though I don't know *what* it is waiting for | 21:57 |
| dobey | yeah me either | 21:58 |
| spiv | dobey: hmm, I would have thought that closing stdin/stdout to the ssh process would be enough to encourage it to close cleanly. | 21:58 |
| spiv | OpenSSH? | 21:58 |
| jam | os.kill(SIGINT) would be nicer | 21:58 |
| dobey | yes openssh | 21:58 |
| jam | hey spiv | 21:58 |
| jam | I was wondering if you'd get a chance to look at https://code.launchpad.net/~jameinel/bzr/2.3-commit-to-stacked/+merge/42698 | 21:58 |
| spiv | jam: I glanced at it very quickly last night :) | 21:58 |
| spiv | jam: It's smaller than I thought it would be! | 21:59 |
| jam | yeah, same here | 21:59 |
| jam | basically, we already had "fill in parent inventories" verb because of stacking | 21:59 |
| jam | just needed to use it at the right time | 21:59 |
| lifeless | \o/ | 21:59 |
| spiv | I vaguely recall thinking that would be a cheap way to fix that bug, then hitting some problem that stopped me from doing it. | 21:59 |
| lifeless | hey | 21:59 |
| dobey | spiv: any ideas why ssh would be waiting for something? | 21:59 |
| lifeless | poolie: I have a wishlist for bzr | 21:59 |
| jam | and the verb already handled stuff like needing chk entries, etc | 21:59 |
| lifeless | dobey: do you have connection pooling on ? | 22:00 |
| spiv | lifeless: oh, ew, good point :/ | 22:00 |
| jam | spiv: chained fallbacks are potentially a problem, so far it is working, but it feels like it shouldn't | 22:00 |
| jam | so I'm investigating | 22:00 |
| lifeless | dobey: a 'master connection' that is created implicitly blocks until all other connections have closed. | 22:00 |
| jam | a bit hard to set up proper Remote objects in the test suite | 22:00 |
| lifeless | dobey: terminating that connection hard will break all other connections (which will be through other processes) | 22:00 |
| lifeless | poolie: I would deeply deeply deeply love to be able to show the content of a shelf | 22:01 |
| dobey | lifeless: not as far as i know | 22:02 |
| spiv | lifeless: I am really looking forward to OpenSSH 5.6's ControlPersist feature. | 22:02 |
| spiv | jam: yeah, I can imagine. | 22:02 |
| dobey | lifeless: but i presume not, unless it's a default | 22:02 |
| spiv | dobey: it's not a default | 22:02 |
| jam | spiv: urljoin(base, '../new') seems to work, since it forces the target to be on the remote url. But then you have to manually create a local lightweight checkout so you can commit, etc. | 22:04 |
| lifeless | dobey: grep ControlMaster in ~/.ssh/config | 22:04 |
| dobey | lifeless: it's not on | 22:04 |
| lifeless | kk | 22:04 |
| mwhudson | lifeless: unshelve --preview? | 22:05 |
| dobey | does bzr dump ssh stdout/stderr to log/stderr? | 22:05 |
| mwhudson | stderr, yes | 22:05 |
| mwhudson | ssh stdout is the communication channel bzr is actually using | 22:05 |
| mwhudson | i guess it's not so much that it dumps stderr either, it just doesn't do anything wrt stderr so it ends up on the terminal | 22:06 |
| poolie | lifeless: 'unshelve --preview'+ | 22:06 |
| poolie | ? | 22:06 |
| lifeless | ah | 22:06 |
| lifeless | I miss the old ui | 22:06 |
| spiv | Hmm. I wonder if having a live stderr fd is enough to keep the ssh subprocess alive sometimes. | 22:06 |
| lifeless | it had a query interface that felt more consistent | 22:06 |
| lifeless | shelve --list + unshelve --preview feels odd | 22:07 |
| spiv | I guess we really should try calling proc.terminate before proc.wait :/ | 22:07 |
| poolie | spiv: if the other end didn't close it, maybe | 22:07 |
| mgz | proc.terminate is pretty rude on windows (and doesn't exist till 2.6 or something) | 22:07 |
| spiv | mgz: yeah | 22:08 |
| jam | spiv: problem is that proc.terminate() is SIGKILL as I understand it | 22:08 |
| spiv | jam: no, it's SIGTERM on posix | 22:09 |
| spiv | jam: but TerminateProcess on Win32, which is more like kill. | 22:09 |
| poolie | lifeless: what's "the old ui"? | 22:10 |
| spiv | I think it's reasonable to resort to SIGTERM after closing the fds we control | 22:10 |
| jam | well, we are less likely to actually have a real spawned process on Win32, as well. so maybe .terminate is ok. Though IIRC, it is not available in py2.4 | 22:10 |
| lifeless | poolie: it was a subcommand ui rather than flags to make things behave differently | 22:10 |
| jam | I think that is 2.5 or even 2.6 | 22:10 |
| spiv | Hmm, /topic looks a bit mangled | 22:10 |
| spiv | jam: yes, 2.6 only | 22:10 |
| dobey | hrmm, i added ssh -v; but nothing especially useful that i see, outside of it just being extremely slow | 22:10 |
| mgz | jam has me on ignore! | 22:10 |
| jam | mgz: well, not explicitly | 22:11 |
| mgz | :P | 22:11 |
| lifeless | poolie: bzr shelve/unshelve/shelf list/shelf show/shelf delete IIRC | 22:11 |
| spiv | dobey: which server are you connected to? Launchpad? | 22:11 |
| dobey | yes | 22:11 |
| spiv | Very odd then. | 22:12 |
| lifeless | going direct or through an ssh proxy | 22:12 |
| dobey | and by slow i mean "the ssh -v output is probably just off because it was 50 seconds until i killed the process" | 22:12 |
| dobey | direct | 22:12 |
| dobey | ie, only the screwy connection seems slow | 22:13 |
| dobey | normal "bzr nick" is fast | 22:13 |
| dobey | well as fast as doing anything with ssh -v is i guess | 22:15 |
| spiv | dobey: I can't quite explain what's causing you to see this issue (when no-one else has reported it), but I think the proc.terminate workaround is probably a good idea for bzr (when running in a Python that supports it). Please file a bug. | 22:22 |
| jam | spiv: why for the RemoteRepositoryFormat-default permutation, is the remote repo a KnitPack6 format, and not a 2a format? | 22:22 |
| lifeless | spiv: lsof might tell us | 22:23 |
| lifeless | dobey: are you on natty? | 22:23 |
| lifeless | spiv: also possibly an openssh change | 22:24 |
| spiv | jam: for no good reason, probably | 22:24 |
| dobey | lifeless: yes | 22:24 |
| dobey | lifeless: but also seeing the same issue on lucid | 22:24 |
| spiv | jam: possibly at the time it was hard to spell "default format" in that bit of the scenario-building code? | 22:25 |
| spiv | jam: there's a bit too many parts of the test suite that explicitly select old formats that should probably use 2a :/ | 22:26 |
| jam | spiv: the scenario code that I can see just does "RemoteRepositoryFormat()" | 22:27 |
| dobey | hrmm, i don't see 2.2.1 packaged for lucid anywhere. is it going to be in backports at all? | 22:27 |
| spiv | jam: perhaps it's due to the test and not the scenario then? | 22:28 |
| spiv | dobey: ppa:bzr/archive | 22:30 |
| jam | spiv: thanks. per_repository_reference the permutation forces RepositoryFormatKnit6 | 22:30 |
| spiv | jam: ah! | 22:30 |
| jam | per_repository just uses the default | 22:30 |
| spiv | jam: that would be one of the "too many parts of the test suite" :) | 22:30 |
| jam | _reference customizeses it, presumably because originally we needed to | 22:31 |
| spiv | jam: right | 22:31 |
| jam | and if you just remove that, it breaks | 22:32 |
| jam | self._ensure_real fails because self._custom_format is None, and repository.network_format_registry has no default key | 22:32 |
| spiv | dobey: I think for lucid we intend to keep putting updates to bzr 2.1.x in lucid-updates. I'm not sure if anyone is doing anything with putting bzr in the backports repository specifically, PPAs are a bit more flexible. | 22:34 |
| spiv | jam: RemoteRepositoryFormat does need an explicit format set, IIRC. It's not normally instantiated without there being an associated remote repo. | 22:35 |
| dobey | ok | 22:35 |
| jam | spiv: sure, but when *creating* one... | 22:35 |
| spiv | jam: when creating a repo the client knows what it is creating... | 22:36 |
| jam | spiv: the point of per-repository tests is to test against something which is remote. But it doesn't know what it is creating | 22:36 |
| jam | at least, I can't find where in bzrlib/tests/per_repository/__init__.py it is setting the format | 22:36 |
| jam | it is obvious in per_repository_reference/__init__.py where _custom_format is getting set | 22:37 |
| spiv | jam: you mean it fails in external_reference_test_scenarios where it tests supports_external_lookups? | 22:40 |
| spiv | jam: the difference is that per_repository scenario setup, unlike per_repository_reference, never interrogates the format instances about their capabilities | 22:41 |
| spiv | jam: and you can't interrogate a RemoteRepositoryFormat with no network_name and no remote repo about its capabilities, because there's no remote repository to have or not have those capabilities. | 22:42 |
| jam | spiv: then how does it call "initialize()" on them? | 22:42 |
| jam | so, I'm still not sure how it knows about external, but otherwise I see your point | 22:43 |
| jam | sorry, I don't know how it initializes | 22:43 |
| jam | but I can see how calling 'support_external_lookups' would fail without a custom format | 22:43 |
| dobey | spiv: https://bugs.launchpad.net/bzr/+bug/686224 | 22:44 |
| ubot5` | Ubuntu bug 686224 in Bazaar "Call proc.terminate before proc.wait when possible" [Undecided,New] | 22:44 |
| spiv | dobey: thanks | 22:45 |
| spiv | jam: because RemoteBzrDirFormat's initialize and RemoteRepositoryFormat's initialize do have default formats | 22:46 |
| dobey | thank you for helping me figure out most of the problem at least :) | 22:46 |
| spiv | (RemoteBzrDirFormat appears to hardcode BzrDirMetaFormat1, RemoteRepositoryFormat grabs the default format from the bzrdir format_registry) | 22:47 |
| jam | spiv: so what you're saying is that while initialize() will fall back to bzrdir.format_registry.get(), ensure_real() will not | 22:47 |
| spiv | jam: yes, and I think it's correct that ensure_real will not | 22:48 |
| jam | anyway, I can find another thing to do here, thanks for the tip | 22:48 |
| jam | anyway, the tests pass | 22:48 |
| jam | just need to make sure I'm testing enough :) | 22:48 |
| spiv | ensure_real should certainly fail if there's no real object! | 22:48 |
| fullermd | Unless you mistype it as "ensur_real" maybe :> | 22:49 |
| spiv | fullermd: actually the method is “_ensure_real” :P | 22:50 |
| fullermd | Is it a virtual method? :p | 22:53 |
| mgz | it's an imaginary method. | 22:54 |
| fullermd | That sounds pretty complex. | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!