| lifeless | jfroy|work: theres an option to log, I think | 00:04 |
|---|---|---|
| jfroy|work | Or API to get to it. I'm basically trying to write a plug-in that adds a --fixes scheme for my company's bug tracker and also a post-commit hook that will add a message to the bug if the commit includes the --fixes metadata. | 00:04 |
| jfroy|work | adding the --fixes scheme was trivial | 00:04 |
| jfroy|work | (just another UniqueIntegerBugTracker) | 00:04 |
| lifeless | the revision.properties | 00:05 |
| jfroy|work | well --long doesn't do it | 00:05 |
| lifeless | in your post commit hook | 00:06 |
| jfroy|work | nice | 00:06 |
| jfroy|work | I'm trying right now just to check if the metadata was recorded | 00:06 |
| lifeless | print branch.repository.get_revision(revision_id).properties | 00:06 |
| jfroy|work | There has to be a command to inspect a revision, even a debug command of some kind | 00:06 |
| jfroy|work | time to break out a python shell huh | 00:07 |
| jfroy|work | fair enough :) | 00:07 |
| lifeless | cat-revision | 00:07 |
| jfroy|work | ha, like the name :) | 00:07 |
| jfroy|work | huh, log doesn't print the revision ID | 00:13 |
| jfroy|work | --show-ids, nvm | 00:13 |
| jfroy|work | And right now, it seems the property value will be hardcoded to "$BUG_URL fixed" | 00:16 |
| jfroy|work | And stored with the key 'bugs' | 00:17 |
| jfroy|work | Which seems to be a magic constant in the builtin commit command, which has me worried one day someone will change that and the plug-in will break | 00:18 |
| KhaZ | Dumb question: currently when I want to add files to bzr, I basically run bzr st -S . | grep "^?" | awk '{print $2}' | xargs bzr add. Is there a better way of doing this, besides maybe aliasing said command? | 00:18 |
| lifeless | jfroy|work: its not part of commit; its part of the bug module | 00:25 |
| lifeless | pydoc bzrlib.bugtracker | 00:25 |
| lifeless | KhaZ: 'bzr add' | 00:26 |
| KhaZ | ... D'oh. It is quite possible I'm that much of an idiot. | 00:26 |
| jfroy|work | lifeless: the 'fixed' part yes | 00:27 |
| jfroy|work | but not the property name | 00:27 |
| lifeless | the property name won't change | 00:28 |
| lifeless | or if it did the query api in bugtracker would be adjusted to support reading from both | 00:28 |
| lifeless | I'm saying, its no more or less at risk of changing than any metadata | 00:29 |
| jfroy|work | I don't see any code in the bugtracker module that ever reads a revision property | 00:30 |
| lifeless | there's stuff in qbzr | 00:30 |
| lifeless | it will probably mgirate to the core at some point | 00:30 |
| jfroy|work | I see | 00:31 |
| spm | lifeless: 'kk (+trunk to 2.0 and 2.0.0) | 00:31 |
| lifeless | spm: 2.0 to 2.0, and 2.0.0 to 2.0.0 :) | 00:31 |
| lifeless | spm: pushing trunk to 2.0 would be bad ;P | 00:31 |
| jfroy|work | So it should be relatively safe for the hook to look for the 'bug' property (as a constant key value, not as a constant imported from bzrlib) | 00:32 |
| spm | heh. that's not what I meant :-) | 00:32 |
| lifeless | jfroy|work: yes | 00:32 |
| lifeless | jfroy|work: 'bugs' | 00:32 |
| jfroy|work | * 'bugs' | 00:32 |
| jfroy|work | damn, beat me to it :p | 00:32 |
| spm | lifeless: so. 2.0: 4665 pushed, vs 4664; 2.0.0: 4667 vs 4665. no changes needed to locations. | 00:39 |
| lifeless | spm: thanks | 00:39 |
| lifeless | jam: ^ | 00:39 |
| spiv | Good morning. | 01:03 |
| poolie | hi all | 01:17 |
| poolie | hi spiv, lifeless | 01:17 |
| poolie | maybe i should change the 'compiled extensions' warning to say "if you're running from a bzr source directory, run 'make'" | 01:18 |
| spiv | poolie: good morning. Thanks for starting the review of the hpss homedirs patch. I forgot to mention that part of the diff (mainly pathfilter.py) is in a separate review (which has been approved now). | 01:24 |
| poolie | np, i saw robert's verbal approval | 01:24 |
| poolie | of that | 01:24 |
| poolie | if you want me to read it too i can | 01:24 |
| spiv | I wouldn't bother if I were you :) | 01:25 |
| mkanat | Okay, assuming that I don't go to the 2a format right now, what's the best format for a repository that I will have to maintain well into the future, right now? | 01:45 |
| mkanat | And that random people, including our users, might be checking out from. | 01:45 |
| mkanat | (Which is why I don't want to go 2a right now--I need relatively good backwards-compatibility so that users can get at the repo.) | 01:46 |
| mkanat | I'm asking because Bugzilla picked bzr over Hg, BTW. | 01:46 |
| poolie | hi mkanat | 01:52 |
| poolie | that's great news btw | 01:53 |
| poolie | mkanat: i'd probably go for 1.9 | 01:53 |
| poolie | it's faster and smaller than earlier formats | 01:53 |
| poolie | and it'll be supported by bzr releases going back, of course, to 1.9 | 01:53 |
| mkanat | poolie: That sounds pretty good. And that will be upgradable to 2a in the future? | 01:54 |
| poolie | which is nearly a year ago now | 01:54 |
| poolie | yes | 01:54 |
| * mkanat nods. | 01:54 | |
| mkanat | Okay, cool. | 01:54 |
| poolie | and 2.0 will support it | 01:54 |
| poolie | so in your case i'd probably be suggesting people install 2.0.0 (or 2.0.x later) | 01:54 |
| poolie | which will be a bugfix-only series | 01:54 |
| poolie | but use 1.9, for interoperation with older releases | 01:55 |
| mkanat | Okay. | 01:55 |
| mkanat | Some people won't be able to install 2.0 very easily. | 01:55 |
| mkanat | But everybody should be able to get 1.9. | 01:55 |
| mkanat | At least. :-) | 01:55 |
| mkanat | (For example, Bugzilla still works on RHEL4, but that only has python 2.3.) | 01:55 |
| davidstrauss | mkanat: why would 2.0 be hard to install? | 01:56 |
| lifeless | mkanat: 1.9-rich-root | 01:56 |
| lifeless | mkanat: if you don't go 2a | 01:56 |
| lifeless | mkanat: the rich root will make moving to 2a easier | 01:56 |
| mkanat | poolie: Is there any way yet of reconciling two separate cvs imports and saying "these are actually the same, and these commits match to these commits and these files match to these files"? | 01:56 |
| davidstrauss | mkanat: no | 01:56 |
| lifeless | mkanat: bzr has only ever supported python 2.4 and up, FWIW | 01:57 |
| mkanat | lifeless: Hmm, ever? Okay. :-) | 01:57 |
| davidstrauss | mkanat: CVS -> bzr is non-deterministic | 01:57 |
| mkanat | davidstrauss: Yes, but it would be nice if I could re-do my import, because some of it's messed up. | 01:58 |
| mkanat | Due to the fact that we started it with an older bzr and an older cvsps_import. | 01:59 |
| davidstrauss | mkanat: There's also no way in bzr for a single file to have multiple UUID ancestors | 01:59 |
| mkanat | davidstrauss: But without breaking people who have already checked out from the existing bzr import (which is a lot of people including all my client work). | 01:59 |
| davidstrauss | mkanat: so merging two branches with the same files and different bzr ancestry is a non-starter | 01:59 |
| davidstrauss | mkanat: you could "merge" into the repo and resolve all conflicts in favor of the incoming files | 02:00 |
| davidstrauss | mkanat: then you'd pick up the file UUIDs from the branch being merged in | 02:00 |
| mkanat | davidstrauss: That would break merging back into the older checkouts, though, right? | 02:00 |
| mkanat | I mean, I don't see any advantage. | 02:00 |
| davidstrauss | mkanat: correct. you can't maintain ancestry in both directions | 02:00 |
| mkanat | Ah well. | 02:00 |
| davidstrauss | mkanat: it's an architectural limitation i've discussed with aaron bentley | 02:00 |
| poolie | mkanat: if you can get all your users to help switch, it may be feasible | 02:01 |
| poolie | you'd need to tell them to just cherrypick across from their existing branches into new ones based on the new import | 02:01 |
| mkanat | poolie: The actual user base is fairly small, so it might be possible. | 02:02 |
| mkanat | poolie: That is, my *main* concern is all the work I have in client branches. | 02:02 |
| lifeless | poolie: re the extensions nag | 02:02 |
| mkanat | And the work I did with NASA. | 02:02 |
| poolie | per-client forks | 02:02 |
| mkanat | poolie: Yeah. | 02:03 |
| lifeless | poolie: I suggest: make bzr --version show the full list of missing extensions, and have the nag be a one-liner: 'One or more C extensions could not be loaded. See bzr help C-extensions' | 02:03 |
| mkanat | poolie: So we'd do the import by basically just applying each patch of each revision individually, and copying the log message? | 02:04 |
| poolie | lifeless: i agree about the nag | 02:05 |
| SamB_XP | mkanat: you *might* be able to use rebase for some of it ? | 02:05 |
| poolie | mkanat: right, and bzr-rebase may be able to help | 02:05 |
| poolie | or, you can just fold them all up into one commit, depending how much resolution you want to keep | 02:05 |
| lifeless | rebase still follows fileids | 02:05 |
| mkanat | poolie: Okay. In that case, next question--is there a better existing CVS importer that can do branches and branch relations than cvsps_import now? | 02:05 |
| SamB_XP | lifeless: oh, right, dang | 02:05 |
| poolie | lifeless: the hard part is making --version show them: --version won't normally know all of the extensions we might want toload | 02:05 |
| mkanat | poolie: I heard something about cscvs from kiko once. | 02:06 |
| poolie | i know of the tool | 02:06 |
| lifeless | mkanat: cvsps-import or cvs2bzr | 02:06 |
| lifeless | mkanat: cscvs is not for conversions, its for ongoing mapping, and only really does trunk | 02:07 |
| mkanat | lifeless: Ah, okay. | 02:07 |
| mkanat | My problem with cvsps_import right now is that it wasn't correctly handling utf-8 in CVS log messages, and it wasn't deleting files under certain circumstances, it seemed. | 02:07 |
| lifeless | mkanat: it can do other branches, with fiddling, but unless you plan to stay on cvs, go for cvsps-import or cvs2bzr (which is fastimport based) | 02:07 |
| lifeless | poolie: so, seems to me that we don't really know that full list ever; so the current warning is also able to be incomplete. | 02:08 |
| lifeless | poolie: I don't think it would be overly ugly to have a module scoped list of expected extensions, and plugins could add to that list if they have extensions too. | 02:08 |
| poolie | right | 02:08 |
| poolie | or otherwise | 02:08 |
| poolie | just give the nag warning | 02:08 |
| poolie | put the missing list into the log file | 02:08 |
| poolie | it's probably actually rare that a non-developer will see just some things fail to load | 02:09 |
| lifeless | I desire --version to show the list because its a very easy thing to ask a Windows or new user to look at. | 02:09 |
| poolie | or see something that's not fixed by either running make, turning off the warning, or filing a bug | 02:09 |
| poolie | i don't object to it, i just think it's a different (filed) bug | 02:10 |
| lifeless | poolie: kk | 02:10 |
| poolie | good idea on the message though | 02:10 |
| mkanat | lifeless: Any particular preference between cvs2bzr and cvsps_import? | 02:12 |
| lifeless | mkanat: I suspect they will have different bugs ;) | 02:13 |
| mkanat | lifeless: Hahaha, okay. :-) | 02:13 |
| mkanat | Maybe I'll just stick with cvsps, then. | 02:13 |
| mkanat | So, if I want to make sure that people don't accidentally check in as somebody else, is the best way to require signatures? | 02:18 |
| mkanat | Well, actually, I'm not even sure that would work. | 02:18 |
| zsquareplusc | is someone here using bzr on sourceforge? do they support more than one branch per project? | 02:45 |
| mkanat | jam: I'm running into a problem with cvsps 2.2, importing Bugzilla into bzr: https://bugs.launchpad.net/bzr-cvsps-import/+bug/431127 | 02:56 |
| ubottu | Launchpad bug 431127 in bzr-cvsps-import "cvsps_import fails with cvsps 2.2" [Undecided,New] | 02:56 |
| aboSamoor1 | Hi, I use bzr in my personal branch in launchpad. I save my different projects under different folders, my friends found it hard to pull all the folder to pull one of them. Is there any way to split the folders under different branches without losing the history of the commits ? | 03:04 |
| zsquareplusc | aboSamoor1: last time i asked about that i was not given a direct solution. but the hint that you could use fast-import/export and filter. so it should be possible with 2 or 3 steps | 03:08 |
| aboSamoor1 | zsquareplusc: well, it is not only performance issue. I don't want to announce all my work once I send someone the address of branch. | 03:10 |
| aboSamoor1 | zsquareplusc: also I don't want make global commits history. so it will more clear to me the history of the commits of each project alone | 03:11 |
| zsquareplusc | aboSamoor1: "bzr help fast-import-filter" should give some insight | 03:17 |
| lifeless | aboSamoor1: just make separate branches now; e.g. | 03:18 |
| lifeless | if you have in your current branch /proj1 /proj2 /proj3 | 03:19 |
| lifeless | then bzr push ../new-proj2-branch | 03:19 |
| lifeless | cd ../new-proj2-branch | 03:19 |
| lifeless | bzr rm --remove proj1 proj3 | 03:19 |
| lifeless | bzr mv proj2/* . | 03:19 |
| lifeless | bzr rm proj2 | 03:19 |
| lifeless | bzr commit -m "Make this branch be for proj2 only." | 03:19 |
| lifeless | and push that to launchpad under an appropriate project | 03:20 |
| aboSamoor1 | lifeless: how will the history of the new branch look like ? I mean if the initial branch has commit till 100 and proj2 was last updated with commit 90 what will be situation ? | 03:21 |
| zsquareplusc | lifeless: --remove is not documented in my bzr's help rm, is that brand new? | 03:21 |
| lifeless | zsquareplusc: actualy its old I think :) | 03:28 |
| lifeless | aboSamoor1: try it and see ;) | 03:28 |
| lifeless | aboSamoor1: as it in a separate branch it won't impact your existing work :) | 03:28 |
| aboSamoor1 | lifeless: good point | 03:28 |
| aboSamoor1 | :) | 03:28 |
| lifeless | in short, it will have everything up to the point you do the rearrangement | 03:29 |
| lifeless | which is what 'preserve history' means, generally ;) | 03:29 |
| aboSamoor1 | bzr push ../new-proj2-branch ----this must be ---> bzr branch ? | 03:29 |
| lifeless | aboSamoor1: that makes a new branch at the path ../new-proj2-branch | 03:30 |
| zsquareplusc | lifeless: hm, if its old, it's undocumented. i can't find a word about in in "help rm" or "man bzr" | 03:30 |
| lifeless | zsquareplusc: as in removed | 03:30 |
| lifeless | zsquareplusc: ignore it ;) | 03:31 |
| zsquareplusc | aboSamoor1: its correct with push. you are in the directory of the current branch and push a copy to a fresh directory | 03:31 |
| zsquareplusc | hm.. with bzr 1.17: bzr rm --remove CVSROOT ... bzr: ERROR: no such option: --remove | 03:35 |
| lifeless | zsquareplusc: don't use the option is what I mean | 03:35 |
| zsquareplusc | ah, but with just rm you still have the history | 03:36 |
| lifeless | zsquareplusc: Of course, the question was how to keep the history, wasn't it?... | 03:36 |
| mkanat | In order to control commit access to a bzr repository, do I have to control the unix permissions of the repository .bzr directory, or just the unix permissions of the branch .bzr directory? | 03:37 |
| zsquareplusc | lifeless: what i understood was, how to make 3 separate branches from 3 folders in one, each with only the history of the respective folder | 03:37 |
| lifeless | zsquareplusc: to do that you need to break the history, rewrite it into a smaller form, which is what you'd use fast-export and fast-export-filter for | 03:38 |
| aboSamoor1 | lifeless: I did that for the first project it increased the commit number by one, now how can I view the history of the new branch without using launchpad ? | 03:41 |
| zsquareplusc | aboSamoor1: bzr log or bzr qlog or bzr vis, depending on which plugins you have installed | 03:42 |
| lifeless | aboSamoor1: bzr log | 03:42 |
| aboSamoor1 | lifeless: I am satisfied with the solution proposed, thanks very much :) | 03:57 |
| mkanat | Hey hey. Anybody got some feedback on my permissions question, above? | 03:58 |
| lifeless | aboSamoor1: cool | 03:58 |
| lifeless | mkanat: both | 03:59 |
| mkanat | lifeless: Okay. | 03:59 |
| mkanat | lifeless: That's what I thought; it's what I've been doing. | 03:59 |
| mkanat | lifeless: So basically if we have separate committer groups, we need separate repos? | 03:59 |
| lifeless | yes | 03:59 |
| mkanat | lifeless: Okay, that's what I thought. | 04:00 |
| lifeless | there are ways to avoid that; theres some stuff in contrib I believe | 04:00 |
| lifeless | but the most secure simple and robust way is one-capability per-repository | 04:00 |
| aboSamoor1 | lifeless: the only drawback of the solution, that if you split the old branch to 5 new branches you have 5 duplicate histories. 5*100 MB :( | 04:02 |
| lifeless | aboSamoor1: they won't grow at the same rate though | 04:02 |
| lifeless | aboSamoor1: and if you have a shared repository the deep history will be shared so you want have 500MB used on disk. | 04:02 |
| aboSamoor1 | lifeless: I will try bzr split later | 04:03 |
| aboSamoor1 | lifeless: I see | 04:03 |
| mkanat | Is there a config for setting up "bzr serve" as a init.d daemon that logs to syslog? | 04:06 |
| Drakeson | what is the bzr equivalent of git reset --hard origin/master ? | 04:07 |
| spiv | mkanat: no, unfortunately. | 04:08 |
| mkanat | Okay. | 04:08 |
| spiv | mkanat: it would be good to improve our logging to make that possible. | 04:08 |
| bob2 | Drakeson: what does that do? | 04:08 |
| mkanat | Yeah--I imagine running a constant "bzr serve" is faster than serving through inet. | 04:08 |
| Drakeson | git-reset resets current head to the speficied state (origin/master here). --hard matches both the working tree and the index to the state one asked for. | 04:10 |
| spiv | mkanat: yeah, most likely; it commonly takes a couple of hundred milliseconds to start a bzr serve process, assuming a warm system. A cold system and some plugins can make that much worse. | 04:11 |
| * mkanat nods. | 04:11 | |
| spiv | Drakeson: "bzr uncommit -r something && bzr revert", perhaps? | 04:12 |
| spiv | Or maybe just "bzr pull --overwrite -r something", I guess. | 04:12 |
| SamB_XP | spiv: how about an overheating system ? | 04:13 |
| Drakeson | leave that aside for moment. assume I do rm -Rf * in a working directory (that leaves .bzr intact). How can I get get back all the files? | 04:13 |
| spiv | I'm not sure exactly what the git jargon means. | 04:13 |
| spiv | SamB_XP: I don't overclock, so I couldn't say ;) | 04:13 |
| spiv | Drakeson: bzr revert | 04:13 |
| SamB_XP | spiv: oh, mine does that without being overclocked | 04:13 |
| Drakeson | spiv: thanks | 04:14 |
| SamB_XP | I had to clock it down to get it to stop rebooting -- probably there is some kind of problem with the cooling ... | 04:14 |
| === AfC1 is now known as AfC | ||
| Jemsquash | Does anyone know the timelines for 2.0? I see the release candidate has been pulled from the main page of bazaar-vcs.org. | 04:37 |
| lifeless | rc1 was pulled, rc2 is out and fine | 04:38 |
| lifeless | 2.0.0 is being assembled at the moment, no further changes | 04:38 |
| Jemsquash | thanks lifeless | 04:40 |
| mneptok | Jemsquash: just merging the animated .gif of poolie waving frantically that auto-displays during branch routines. stand by. | 04:42 |
| mneptok | lifeless: was the decision final on this one for weave merges? - http://birdhouse.org/~mnep/avatars/scream.gif | 04:43 |
| lifeless | heh | 04:44 |
| thumper | is anyone going to fix the hardlinking issue with WorkingTree6? | 05:01 |
| lifeless | thumper: eventually I guess? its fallout from content filtering, and theres a bunch of work needed in that area | 05:14 |
| thumper | ok | 05:15 |
| poolie | hey spiv, i may (if we're lucky) review your patch this afternoon | 06:02 |
| poolie | i was wondering what you thought too about the idea of the client inhibiting itself from sending requests to servers when the implementation is known to be broken | 06:03 |
| poolie | i think i asked before but didn't see (or remember :) your reply | 06:03 |
| lifeless | spiv: the 'extra' in smart tcp server for testing is flummoxing me | 06:08 |
| lifeless | spiv: got a minute for a chat | 06:08 |
| lifeless | spiv: for example: | 06:16 |
| lifeless | (Pdb) bzrlib.bzrdir.BzrDir.open(self.get_url() + '../') | 06:16 |
| lifeless | *** UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', "Invalid URL join request: Cannot go above root: '/' + ('../',)") | 06:16 |
| lifeless | bzrlib.bzrdir.BzrDir.open( "bzr://127.0.0.1:46829/") | 06:16 |
| lifeless | *** BzrError: Attempt to escape test isolation: 'bzr | 06:16 |
| lifeless | ... | 06:16 |
| lifeless | self.get_transport(self.get_url()) | 06:17 |
| lifeless | <bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:46829/extra/bzr%3A//127.0.0.1%3A46829/extra/> | 06:17 |
| poolie | lifeless: could you look at bug 430738 some time? | 06:17 |
| ubottu | Launchpad bug 430738 in bzr "Upgrade fails with NoSuchId in _iter_file_id_parents in add_inventory_by_delta" [Undecided,New] https://launchpad.net/bugs/430738 | 06:17 |
| lifeless | self.get_transport(self.get_url()).list_dir('.') | 06:17 |
| lifeless | poolie: does 'check' pass on that repository? | 06:17 |
| poolie | he doesn't say | 06:18 |
| poolie | he says reconcile passed | 06:18 |
| * thumper is helping some windows bound people with bzr | 06:26 | |
| spiv | lifeless: the last thing I would say is that if isinstance the for_testing server that you shouldn't hardcode /extra/; you can (and probably should) use server_obj.client_path_extra | 06:26 |
| thumper | what is the absolute easiest way to install bzr on windows that allows bzr+ssh usage? | 06:27 |
| spiv | thumper: windows on client, or server (or both)? | 06:27 |
| thumper | how much hoop jumping needs to be done for people without ssh keys? | 06:27 |
| thumper | spiv: windows client for sure | 06:27 |
| thumper | spiv: I was going to set up my desktop as the main code host | 06:28 |
| thumper | spiv: it is for a polytech project | 06:28 |
| thumper | 3 people collaborating | 06:28 |
| spiv | It should mostly just work, I think, now that we default to using paramiko on Windows. (IIRC) | 06:28 |
| thumper | spiv: as you may expect, my desktop is linux | 06:28 |
| thumper | spiv: the bazaar wiki page for windows installing isn't very helpful | 06:29 |
| mneptok | thumper: we know you still use an Amiga. | 06:29 |
| thumper | it says "download these 8 things..." | 06:29 |
| spiv | There's no requirement to have SSH keys, but they can help avoid the need to retype your password a lot :) | 06:29 |
| spiv | thumper: Huh, I thought it was just a case of "download and run the .exe installer" | 06:29 |
| thumper | spiv: I don't allow ssh with a password to my server :) | 06:29 |
| spiv | thumper: but I could easily be wrong. | 06:29 |
| thumper | which one? | 06:30 |
| thumper | I tried the py 2.6 one as I thought that ment "uses python 2.6" | 06:30 |
| thumper | but no | 06:30 |
| thumper | the standalone installers say 2.2 and 2.3, and I'm not sure if they are meaning python or what | 06:30 |
| spiv | Gosh, I'm out of date. I thought there was just one! | 06:30 |
| thumper | I'll ask again later tonight | 06:30 |
| mneptok | thumper: IIRC, PuTTY allows creation and use of ssh keys. | 06:30 |
| thumper | perhaps I'll get some windwos users | 06:30 |
| spiv | thumper: http://bazaar-vcs.org/Download has, next to "Windows installer", a link called "default 1.18.1 installer". | 06:31 |
| thumper | when is the 2.0 one going to be there? | 06:31 |
| spiv | thumper: I guess you're looking at the Launchpad page of download files? | 06:31 |
| thumper | yeah | 06:31 |
| spiv | When it's released, I assume ;) | 06:31 |
| thumper | :) | 06:31 |
| * thumper goes to make dinner | 06:31 | |
| spiv | thumper: I'm pretty sure you almost always want to be using the "Standalone" installers on Windows. | 06:32 |
| spiv | poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact? | 06:34 |
| spiv | poolie: You're thinking of looking at version string in the response headers, I guess? | 06:35 |
| spiv | poolie: the way we've dealt with this (or something similar, at least?) before is to create a new verb. | 06:36 |
| lifeless | uhm | 06:41 |
| lifeless | lp handles ~ fine | 06:41 |
| lifeless | so I beg the question, how would one tell? | 06:41 |
| bialix | hi all | 06:41 |
| bialix | how's 2.0 moving? | 06:41 |
| lifeless | spiv: | 06:49 |
| lifeless | I don't know about you, but I'm pretty good at ignoring yet another email, | 06:49 |
| lifeless | particularly email that comes from a cron job ;) | 06:49 |
| lifeless | bah | 06:49 |
| lifeless | copy paste fail | 06:49 |
| lifeless | I don't know about you, but I'm pretty good at ignoring yet another email, | 06:49 |
| lifeless | particularly email that comes from a cron job ;) | 06:49 |
| lifeless | and gain. | 06:49 |
| * lifeless stares at vim | 06:49 | |
| lifeless | elif isinstance(transport_server, server.SmartTCPServer_for_testing): | 06:50 |
| lifeless | # The smart server adds a path similar to work, which is traversed | 06:50 |
| lifeless | # up from by the client. But the server is chrooted - the actual | 06:50 |
| lifeless | # backing transport is not escaped from, and VFS requests to the | 06:50 |
| lifeless | # root will error (because they try to escape the chroot). | 06:50 |
| spiv | lifeless: sounds good | 06:52 |
| spiv | lifeless: what are you referring to with "lp handles ~ fine"? | 06:53 |
| lifeless | this should make you laugh: | 06:53 |
| lifeless | Attempt to escape test isolation: 'bzr://example.com/quack/' ['/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/', '/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/'] | 06:53 |
| spiv | :) | 06:53 |
| lifeless | bzr+ssh://bazaar.launchpad.net/~lifeless/... | 06:53 |
| spiv | I'm missing something. | 06:54 |
| spiv | What was that comment in reply to? | 06:54 |
| lifeless | 15:33 < spiv> poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact? | 06:54 |
| spiv | Oh, that was unrelated to ~ in URLs. | 06:54 |
| lifeless | ah ok | 06:54 |
| poolie | it was unrelated | 07:01 |
| poolie | it was about 1.17 sticking xml into chk streams | 07:01 |
| poolie | purportedly chk streams | 07:01 |
| poolie | spiv: we know now that 1.17 was broken | 07:02 |
| poolie | poolie: it was unrelated | 07:27 |
| poolie | poolie: it was about 1.17 sticking xml into chk streams | 07:27 |
| poolie | poolie: purportedly chk streams | 07:27 |
| poolie | poolie: spiv: we know now that 1.17 was broken | 07:27 |
| spiv | poolie: right | 07:28 |
| vila | hi all | 07:28 |
| vila | poolie: you're speaking to yourself ? .... Often ?.... :P | 07:28 |
| poolie | :) i think i fell off irc | 07:30 |
| poolie | i wasn't sure if it got through | 07:30 |
| poolie | what's the cleanest way to test things sent to trace.warning? | 07:40 |
| vila | poolie: nearly done with bug #430749, I still have one failure | 07:41 |
| ubottu | Launchpad bug 430749 in bzr ""Failed to load compiled extensions" warning breaks the test suite" [High,Confirmed] https://launchpad.net/bugs/430749 | 07:41 |
| poolie | ok | 07:41 |
| vila | poolie: just in case you're on it | 07:41 |
| poolie | i'm nearly done with giving a nicer message and am just trying to work out how to test it | 07:41 |
| poolie | i'm also going out in about 40 mins | 07:42 |
| poolie | oh btw, i forgot to say yesterday | 07:42 |
| vila | ok, I think there is another for that | 07:42 |
| poolie | i appreciated all your bug tidying | 07:42 |
| vila | ok, I think there is another bug for that | 07:42 |
| poolie | there is | 07:42 |
| poolie | bug 430529 | 07:42 |
| ubottu | Launchpad bug 430529 in bzr "missing extensions warning is unclear" [High,In progress] https://launchpad.net/bugs/430529 | 07:42 |
| vila | ok, so no problem, we'll review each other :) | 07:42 |
| vila | the way I address mine doesn't depend on the message only on the config variable | 07:43 |
| poolie | this is kind of annoying | 07:44 |
| vila | and last one fixed, running a full test suite to check | 07:44 |
| poolie | it's a stupid thing to get stuck on | 07:44 |
| poolie | the testing i mean | 07:44 |
| vila | pfewwww | 07:44 |
| vila | don't feel stupid, IME writing the first test of a new kind is always hard, far far harder than the code | 07:45 |
| poolie | the thing is it's not the first | 07:45 |
| poolie | it's just that trace really needs some cleaning up | 07:45 |
| poolie | at least now we can do it with less fear of compatibility | 07:45 |
| poolie | breakage | 07:45 |
| vila | worth spendng some time on it isn't it ? :D | 07:46 |
| vila | poolie: so what is it you're wanting to test exactly ? The text itself ? (Coincidentally I have test_config.py under my eyes, there is an assertWarning(warning) there | 07:54 |
| poolie | vila, the text, and it's no longer a python warning | 07:54 |
| poolie | https://code.edge.launchpad.net/~mbp/bzr/430529-extension-warnings/+merge/11950 | 07:54 |
| poolie | i might pull at the cruft in a separate branch | 07:54 |
| vila | ooh, it was a *python* warning, sorry I missed that | 07:57 |
| poolie | i'll pull out some uncontroversial stuff from trace.py and send mail about the rest | 07:59 |
| poolie | in short it's a question of whether we should still be using python logging | 07:59 |
| poolie | it's a bit conflicted with our ui factory stuff | 07:59 |
| poolie | it takes a little while to load | 07:59 |
| poolie | and it makes things a bit more complex to test | 07:59 |
| bialix | bonjour vila, good evening poolie | 08:26 |
| vila | hello bialix | 08:27 |
| vila | poolie: my vote is to unify under the ui banner | 08:27 |
| vila | poolie: but I still have to read your mail :) | 08:27 |
| naoki | commiting to stacked branch with bzr-2.0rc2 is OK on Ubuntu but failed on WinXP | 08:32 |
| spiv | naoki: that sounds bad, please file a bug. | 08:33 |
| naoki | https://bugs.launchpad.net/bzr/+bug/431223 | 08:37 |
| ubottu | Launchpad bug 431223 in bzr "bzr2.0rc2 fails commiting to stacked branch on WinXP" [Undecided,New] | 08:37 |
| spiv | naoki: Hmm. Sounds like bug 375013, but I don't know why you'd get different behaviour on Ubuntu vs. WinXP for that. | 08:39 |
| ubottu | Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged] https://launchpad.net/bugs/375013 | 08:39 |
| spiv | naoki: perhaps on Ubuntu you aren't using a lightweight checkout of the branch? | 08:40 |
| spiv | naoki: also, what version of bzr are you using on Ubuntu? | 08:41 |
| rojanu | I am trying to connect to a server through proxy on Windows; I have set http_proxy=http://my.proxy.server.com | 09:18 |
| rojanu | even tried to configure authentication.conf to no avail, any ideas? | 09:19 |
| vila | rojanu: try adding '-Dhttp' and look at your '.bzr.log' for clues | 09:19 |
| rojanu | vila: where do I find the log? | 09:21 |
| vila | 'bzr version' will tell you | 09:22 |
| rojanu | Ok. log has some traceback info and msg printed to stdout "bzr: ERROR: Connection error: failed to connect to bzr.bugzilla.org:4155: Operation timed out" | 09:25 |
| vila | Did you specify '-Dhttp' in your command ? | 09:26 |
| vila | Err, wait, you're connecting with a bzr+http:// url ? | 09:26 |
| rojanu | here is my command "bzr -Dhttp co bzr://bzr.bugzilla.org/selenium/3.4" | 09:28 |
| vila | rojanu: http is not involved here | 09:29 |
| naoki_ | spiv: I used bzr-2.0rc2 on Jaunty x86 | 09:33 |
| naoki_ | spiv: And I didn't use lightweight checkout on both. | 09:33 |
| naoki_ | I did use only stacked branch that stacked on standalone branch. | 09:34 |
| vila | rojanu: I meant, I don't know what proxy you're using but I'm not sure it will know how to transparently proxy the bzr protocol... | 09:35 |
| rojanu | vila: I don't know what proxy it is apart from the server address. In browsers, we have pac files specified!!! | 09:37 |
| vila | rojanu: browsers speak http, bzr can speak http too with http servers, here you're trying to speak to a bzr server in the bzr protocol | 09:38 |
| vila | rojanu: does bugzilla offers http access for that branch ? At a different address ? | 09:38 |
| vila | rojanu: you may want to contact *them* to know that | 09:39 |
| vila | s/know/answer/ | 09:39 |
| rojanu | vila: I will contact bugzilla to get a http address, Thanks | 09:41 |
| vila | rojanu: the alternative is to contact your admins to allow direct connection to bzr.bugzilla.org:4155 | 09:42 |
| spiv | naoki_: thanks! I'm still mystified, but I've updated the bug. | 10:00 |
| lifeless | grr | 10:01 |
| lifeless | "bzr: ERROR: Attempt to escape test isolation: 'file:///home/robertc/source/baz/pending/working/bzrlib/version.pyc/' ['/tmp/testbzr-laC87z.tmp/ | 10:01 |
| vila | lifeless: why grrr? Aren't you happy to catch one more ? :D | 10:02 |
| lifeless | vila: this is 'bzr version looks for a bzr source tree' | 10:02 |
| vila | haaa, GRRRRR instead | 10:03 |
| vila | indeed I mean | 10:03 |
| lifeless | vila: test root could be in ., and . is in the source tree, so permitting that means permitting all access within the source tree. | 10:03 |
| lifeless | thus grr :P | 10:03 |
| vila | lifeless: so that one test should be put in its own test class :) | 10:09 |
| lifeless | vila: there are many such. | 10:09 |
| lifeless | 400 tests to go | 10:10 |
| vila | wow, 400 good reasons to escape ? | 10:10 |
| vila | My remark was only for valid escape cases | 10:10 |
| lifeless | I have a list of 500 failing tests | 10:11 |
| lifeless | I've worked through finding causes the first 100 [and fixed] | 10:11 |
| lifeless | so there might be only 2 left to go. I don't know :) | 10:11 |
| vila | 8-/ | 10:11 |
| lifeless | 1;2c/win 20 | 10:13 |
| lifeless | vila: I know that you mean only valid cases, but when we open it up, that test can then misbehave, and we won't know | 10:14 |
| vila | we don't know *today*, so better guard most of them, the 'bzr version' one, if I remember correctly, requires access to the source tree and can't even pass if run from an installed version | 10:16 |
| lifeless | it should work when installed. | 10:16 |
| vila | by skipping ? | 10:17 |
| vila | or by conditional assertions ? | 10:18 |
| vila | lifeless: if you could review https://code.edge.launchpad.net/~vila/bzr/430749-no-extensions-warning/+merge/11951 , | 10:19 |
| vila | I'll be able to put some green on the botnet which is currently full red :-/ | 10:19 |
| vila | kind of small-red-button but also related to your reflexions about config-in-home-dir accesses :) | 10:21 |
| lifeless | vila: conditionals | 10:21 |
| lifeless | do you see a double header on that page? | 10:21 |
| vila | hoo, yes | 10:21 |
| vila | one with branches, one with branch | 10:21 |
| lifeless | thumper: ^ | 10:22 |
| lifeless | vila: reviewed | 10:28 |
| vila | lifeless: bug #431133 ;-P Welcome to my world :D | 10:28 |
| ubottu | Launchpad bug 431133 in bzr "blackbox.test_too_much.TestCommands.test_main_version in a checkout of bzr does network I/O" [High,Confirmed] https://launchpad.net/bugs/431133 | 10:28 |
| vila | lifeless: thanks ! Is that a tweak ? | 10:29 |
| lifeless | vila: yes | 10:32 |
| vila | lifeless: all impacted tests are based on TestCaseWithTransport and all use run_bzr_subprocess, are you sure you want TestCase ? | 10:32 |
| lifeless | vila: TCWT is fine | 10:33 |
| vila | ok | 10:33 |
| lifeless | the ExternalBase change is a no-op, you realise? | 10:33 |
| vila | not sure what you mean by that, I delete all uses of ExternalBase because I find the class useless | 10:34 |
| vila | and misleading | 10:35 |
| pygi | hi folks | 10:35 |
| lifeless | vila: ah | 10:36 |
| lifeless | vila: see my proposal for new test dirs? | 10:37 |
| vila | I don't think so | 10:37 |
| lifeless | checl the list mail | 10:37 |
| === thumper__ is now known as _thumper_ | ||
| lifeless | _thumper_: hi | 10:38 |
| _thumper_ | lifeless: hi | 10:38 |
| lifeless | _thumper_: https://code.edge.launchpad.net/~vila/bzr/430749-no-extensions-warning/+merge/11951 | 10:38 |
| _thumper_ | lifeless: what's that? | 10:39 |
| lifeless | do you see two headers there? Is that know/desired/a bug I should file? | 10:39 |
| _thumper_ | lifeless: I'm on windows :-| | 10:39 |
| _thumper_ | yes I know the two headers | 10:39 |
| _thumper_ | it is fixed in a branch I have in review | 10:39 |
| lifeless | _thumper_: you poor thing. | 10:39 |
| _thumper_ | for 3.0 | 10:39 |
| lifeless | [windows] | 10:39 |
| _thumper_ | there were many heading issues with the new 3.0 work | 10:39 |
| lifeless | whatever possessed you to do that? | 10:39 |
| _thumper_ | I'm trying to get bzr working on windows | 10:39 |
| _thumper_ | there are three different bzr standalone installers | 10:40 |
| _thumper_ | what is the difference between them? | 10:40 |
| _thumper_ | also, once I have them | 10:40 |
| _thumper_ | what do I need to talk to LP from a windows laptop? | 10:40 |
| _thumper_ | I need a local ssh key I guess | 10:40 |
| _thumper_ | are there docs on the bzr wiki on how to get this set up? | 10:40 |
| lifeless | http://bazaar-vcs.org/Download | 10:40 |
| lifeless | under windows | 10:40 |
| lifeless | the first link | 10:40 |
| _thumper_ | I've got the 2.0rc2 from LP | 10:41 |
| _thumper_ | not the 1.18.1 one | 10:41 |
| lifeless | theres a link to docs too | 10:41 |
| lifeless | which explains the differences | 10:41 |
| * _thumper_ looks again | 10:41 | |
| lifeless | yes, just need your ssh key; use pagent or putty or something like that | 10:41 |
| _thumper_ | lifeless: the download page isn't that helpful | 10:42 |
| _thumper_ | it doesn't mention the 2.0rc2 for windows | 10:42 |
| _thumper_ | nor the different stand alone installers | 10:42 |
| lifeless | _thumper_: uhm | 10:43 |
| vila | lifeless: amen for killing blackbox tests | 10:43 |
| _thumper_ | http://bazaar-vcs.org/WindowsDownloads has a wrong wildcard at the top | 10:43 |
| lifeless | _thumper_: taking those point by point; the page is tuned for end users; end users shouldn't be using 2.0rc2. | 10:43 |
| _thumper_ | :) | 10:43 |
| _thumper_ | bzr-2.0rc2-3-setup.exe, bzr-2.0rc2-2-setup.exe, bzr-2.0rc2-1-setup.exe - what's the difference? | 10:44 |
| lifeless | secondly, for end users the first link, the one that says default, is the right one | 10:44 |
| lifeless | where are you getting those links? Cause I have no idea. | 10:44 |
| _thumper_ | https://edge.launchpad.net/bzr/+download | 10:44 |
| lifeless | I would guess at build number | 10:44 |
| _thumper_ | I'm downloading the 1.18.1 standalone installer now | 10:45 |
| lifeless | jam: https://edge.launchpad.net/bzr/+download - are the -1- and -2- installers obsolete? if so lets delete em. | 10:46 |
| lifeless | jam: I would, but I'm not sure I can undelete on lp if I'm wrong:) | 10:46 |
| _thumper_ | the windows downloads instructions doesn't say anything about "getting the default" | 10:46 |
| * _thumper_ is being somewhat pedantic | 10:46 | |
| lifeless | _thumper_: s/pedantic/annoying/ | 10:46 |
| _thumper_ | :) | 10:46 |
| lifeless | _thumper_: where are you looking precisely please | 10:46 |
| lifeless | because on here | 10:46 |
| lifeless | http://bazaar-vcs.org/Download | 10:47 |
| _thumper_ | http://bazaar-vcs.org/WindowsDownloads | 10:47 |
| lifeless | I see a link that folk will just follow and will just work. | 10:47 |
| _thumper_ | I followed the instructions link | 10:47 |
| _thumper_ | on the Download page | 10:47 |
| _thumper_ | people like instructions | 10:47 |
| _thumper_ | the instructions it takes you to contradict those on the earlier page | 10:47 |
| lifeless | well the WindowsDownload page says 'most recent bzr-setup-*.exe' | 10:47 |
| _thumper_ | yes | 10:48 |
| _thumper_ | but that wildcard doesn't match | 10:48 |
| lifeless | which modulo the aforementioned question about what the -N- bit is | 10:48 |
| lifeless | right, so it should be fixed ;) | 10:48 |
| _thumper_ | bzr-*-setup.exe is right | 10:48 |
| lifeless | I think so | 10:48 |
| * _thumper_ ran the standalone installer | 10:49 | |
| _thumper_ | where is the effective .bazaar directory on windows? | 10:49 |
| _thumper_ | for the locations.conf et al? | 10:49 |
| lifeless | bzr --version | 10:49 |
| _thumper_ | 1.18.1 | 10:49 |
| lifeless | no | 10:49 |
| lifeless | run it | 10:49 |
| _thumper_ | I did | 10:50 |
| lifeless | it should have told you | 10:50 |
| _thumper_ | ha, didn't read that bit :) | 10:50 |
| _thumper_ | cool | 10:50 |
| lifeless | naoki: your bug is a duplicate of the one that the error tells you about | 10:59 |
| lifeless | naoki: you need a regular branch or checkout, pushing to or bound to respectively, to add data to a stacked branch. | 10:59 |
| ngnp | I have the same (local) repo as Related branches: push, parent and submit ... what have I done wrong | 11:00 |
| naoki | hmm, the error message tells me "Cannot commit from a lightweight checkout to a stacked branch.". | 11:01 |
| naoki | I didn't use a lightweight checkout. | 11:01 |
| lifeless | naoki: yes. there is more detail in the bug report it references | 11:01 |
| lifeless | naoki: a stacked branch where there is an in-place tree is equivalent | 11:02 |
| naoki | I see. | 11:02 |
| lifeless | ngnp: I don't know that you've done anything wrong. what would you like bzr to do differently? | 11:02 |
| naoki | OK. I mark my bug as duplicate. | 11:02 |
| lifeless | naoki: I've done that;) | 11:02 |
| lifeless | naoki: I was catching you here to explain | 11:03 |
| lifeless | we'd like to make it work but its really not trivial | 11:03 |
| ngnp | lifeless: I somehow did not expected these three ... just a push and parent? The weird this is that when committing the parent is sync immediately ... that's not what I wanted :( | 11:04 |
| ngnp | synced | 11:04 |
| lifeless | ngnp: do you mean repo or branch when you say they are the same? | 11:05 |
| ngnp | lifeless: I'm working on ~htdocs/mdc and when committing there my ~/Documents/bzr/mdc is updated too. I want to control _when_ that happens :( | 11:06 |
| lifeless | ngnp: which of those two did you create first? | 11:06 |
| lifeless | ngnp: and how did you create the second one? | 11:07 |
| ngnp | The ~Documents version | 11:07 |
| lifeless | if you don't remember, just run 'bzr info' in ~htdocs/mdc and pastebin the result | 11:07 |
| ngnp | first then dunno ... I guess a pull | 11:07 |
| lifeless | I bet you did 'bzr checkout' | 11:08 |
| lifeless | but the info will tell us | 11:08 |
| ngnp | lifeless: http://pastebin.ca/1569478 | 11:09 |
| lifeless | see this line: checkout of branch: ... | 11:11 |
| lifeless | that says 'when you commit, it will auto push to the ...' | 11:11 |
| lifeless | run 'bzr unbind' | 11:11 |
| lifeless | and then you'll need to use 'bzr push' to do the push | 11:11 |
| ngnp | lifeless: thanks :) | 11:12 |
| lifeless | vila: do you recall what bzrlib/tests/commands/ is for | 11:25 |
| lifeless | is that == the cli package I proposed? | 11:25 |
| lifeless | vila: it doesn't really seem to be, to me? | 11:25 |
| vila | not cli, quite the complement in fact | 11:26 |
| vila | ..bad word :-/ | 11:26 |
| lifeless | its not clear to me how the tests there differ from other ones in blackbox, other than that they create the command object directly. | 11:27 |
| lifeless | separately, InstrumentedTransport - that would be better as a decorator I think. | 11:28 |
| lifeless | HookedTransportDecorator, decorate any transport you want? | 11:28 |
| vila | wait a minute | 11:29 |
| vila | paging context in | 11:29 |
| lifeless | I ask, because the convolutions it goes through look to be precisely what chroot+ readonly+ etc all do already | 11:30 |
| lifeless | and if it was setup like that it wouldn't be failing with isolation errors | 11:30 |
| lifeless | BzrError: Attempt to escape test isolation: 'hooked://foo@localhost:37295/tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/work/' ['/tmp/testbzr-VVo9LS.tmp/', 'file:///tmp/testbzr-VVo9LS.tmp/', '/tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/', 'file:///tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/', ' | 11:30 |
| vila | So commands/__init__ says: Test the internal behaviour of the commands (the blackbox tests are intended to | 11:31 |
| vila | test the usage of the commands). | 11:31 |
| lifeless | well, blackbox tests internal behaviour for something like 90% of the tests in blackbox today ;) | 11:31 |
| lifeless | I'm not objecting to the commands test package | 11:32 |
| lifeless | just it was a bit of a spike you did, | 11:32 |
| lifeless | and its been left fallow since | 11:32 |
| vila | yeah, but nobody ever understood why it was named like that and even I am not sure :-/ | 11:32 |
| lifeless | The hooking stuff is spectacularly ugly though, and if I can get from you what you needed to achieve I'll do a separate branch to clean it up | 11:33 |
| vila | pff, it's quite old and I seem to remember that I needed to do that to minimize changes at that time | 11:33 |
| lifeless | vila: please think a bit about this | 11:34 |
| lifeless | from what I can see you wanted to hook into some behaviour | 11:34 |
| vila | may be it was to work around a bug fixed since like redirections bringing back pycurl transports instead or urllib ones | 11:34 |
| lifeless | you created a TransportHooks | 11:35 |
| vila | so I had to keep a tighter control than what decorators provided | 11:35 |
| lifeless | which doesn't work for all transports | 11:35 |
| lifeless | vila: I propose the following: | 11:36 |
| vila | It's intended to be used for ConnectedTransport only | 11:36 |
| lifeless | - we make that transport hooks official and public for all transports. | 11:36 |
| lifeless | non ConnectedTransports will simply never fire | 11:36 |
| lifeless | - we change the tests to just use SFTPTransport or FTPTransport directly | 11:36 |
| vila | That *sounds* good (i.e. that seem to address the initial aims whatever they were, while being cleaner) | 11:37 |
| lifeless | and finally, I'd be strongly inclined to consider these tests acceptance tests | 11:38 |
| vila | Looking at the code also seem to imply I wasn't very good at parameterizing the tests at that time | 11:38 |
| lifeless | if you wanted to do this overnight, I wouldn't complain :) | 11:39 |
| vila | hehe | 11:39 |
| vila | lifeless: don't count too much on it especially today, I need to finish early due to some light medical operation | 11:40 |
| lifeless | vila: ok | 11:41 |
| vila | lifeless: and that's really not today, tomorrow on the other hand... :-D SO maybe file a bug with the IRC discussion | 11:41 |
| lifeless | vila: bug filed | 11:51 |
| lifeless | vila: its kindof three bugs, I can file more specific ones when you run out of steam :) | 11:51 |
| vila | lifeless: it's ok | 11:52 |
| * vila fiddling with buildbot to add the timing run | 11:52 | |
| vila | lifeless: http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/1/steps/Non-regression tests/logs/stdio/text | 12:02 |
| vila | that one is still in progress but the next should run on a "quiet" host (or I'll tune the scheduler) and with incremented numbers (after the /builds/ part) | 12:03 |
| vila | lifeless: that way the archival is handled by buildbot and you can peek whatever suits your needs :) | 12:05 |
| lifeless | thanks! | 12:05 |
| vila | The format is correct ? | 12:05 |
| lifeless | no idea | 12:06 |
| vila | lifeless: on the other hand, we may want to integrate whatever processing you want in the botnet itself, that sounds quite its job after all | 12:07 |
| vila | no urgency, just a thought | 12:07 |
| lifeless | something is adding noise to it | 12:07 |
| lifeless | wget -O- 'http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/1/steps/Non-regression%20tests/logs/stdio/text' | subunit2gtk | 12:08 |
| vila | probably because you get both stout and stderr ? | 12:08 |
| lifeless | ugh | 12:08 |
| lifeless | can you squelch stderr then ? | 12:09 |
| vila | sure | 12:09 |
| vila | well, I'll try at least :) | 12:09 |
| lifeless | 2>/dev/null | 12:09 |
| lifeless | so the processing desired is 'analyse stuff' | 12:09 |
| lifeless | which could be the subunit-ls --times I posted to the list | 12:10 |
| lifeless | or 'how long are repo tests taking' etc | 12:10 |
| vila | progress: 0 | 12:10 |
| vila | time: 2009-09-17 11:10:20.952940Z | 12:10 |
| vila | program finished with exit code 0 | 12:10 |
| vila | elapsedTime=1.194652 | 12:10 |
| vila | that 2>/dev/null is quite a booster :D | 12:11 |
| lifeless | Ran 465 tests in 206.470s | 12:11 |
| lifeless | FAILED (errors=1, known_failure_count=18) | 12:11 |
| lifeless | nearly there | 12:11 |
| lifeless | more servers not supporting get_url :( | 12:11 |
| vila | probably interpreted as a test name | 12:11 |
| vila | there shouldn't be much left.. which ones ? | 12:12 |
| lifeless | RecordingServer | 12:12 |
| vila | haa | 12:12 |
| zyga-work | hello | 12:14 |
| zyga-work | I have a question about https://answers.launchpad.net/bzr/+question/71563 | 12:14 |
| zyga-work | how to use bzr join correctly | 12:14 |
| zyga-work | does bzr, today, support nested trees in a way that allows one to have a branch that contains other branches | 12:15 |
| zyga-work | and the inner branch can be still managed as a separate branch | 12:17 |
| james_w | zyga-work: only at an experimental level | 12:20 |
| zyga-work | great, do I need .dev tree or will 1.18 suffice? | 12:20 |
| james_w | I don't think there have been any changes in that area | 12:21 |
| lifeless | its not enabled for any supported repository format | 12:21 |
| zyga-work | if you could walk me thru using it to, say consolidate a "workspace" branch that contains "libfoo", "libbar" and "program" I could update the wiki in return | 12:21 |
| lifeless | zyga-work: ^ | 12:21 |
| zyga-work | :/ | 12:21 |
| lifeless | vila: bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/test-speed - shiny shininess | 12:55 |
| === mrevell is now known as mrevell-dejeuner | ||
| lifeless | oh bah | 13:04 |
| vila | lifeless: was grabbing some food | 13:04 |
| vila | lifeless: can't find a simple way to get a clean stdout :-/ | 13:07 |
| lifeless | ok, branch is actually pushed now | 13:08 |
| vila | lifeless: hmm, indeed, totally different beast :) | 13:11 |
| lifeless | so for --subunit | 13:13 |
| lifeless | how about | 13:13 |
| lifeless | selftest | tee subunit.log | subunit2pyunit | 13:13 |
| vila | lifeless: the problem seems to be that the redirections can't be handled... | 13:14 |
| vila | wow, the addition to start_server seems hackish, I'll have to test that against my local_test_server plugin asap | 13:16 |
| lifeless | what builder are you using? | 13:16 |
| vila | I created a new one (not committed yet if you're looking at the public branch0 | 13:16 |
| lifeless | vila: paste the relevant bit of the config here? | 13:21 |
| lifeless | presumably only a couple of lines... | 13:21 |
| lifeless | vila: start_server is hacky to the extent that tests depend on a directory *two levels up* from where they start to isolate them from the file system | 13:23 |
| vila | lifeless: http://paste.ubuntu.com/272782/ | 13:23 |
| lifeless | if you imagine (and its not where I'm going - wt wants real disk, reasonably so), that everything was in a memory file system, we'd need to change our server start locations and so forth to provide those two extra directories. | 13:24 |
| vila | lifeless: hmm, you mean xxx/work ? | 13:24 |
| lifeless | safetynet/testname/work | 13:24 |
| vila | yeah | 13:24 |
| vila | hmm | 13:24 |
| lifeless | so, you can argue that perhaps I should do that work first :) | 13:25 |
| lifeless | but I think there is a chicken and egg effect | 13:25 |
| vila | It will be clearer if that '../..' was obtained by a relpath calculation | 13:25 |
| lifeless | can't do that | 13:25 |
| lifeless | one url will be (say) sftp://, the other is file:// | 13:25 |
| lifeless | vila: try | 13:26 |
| vila | but that's exactly where I have a problem (or rather not me but well), we have a relation between the server root and the test working dir | 13:26 |
| lifeless | command = 'python ./bzr selftest --subunit 2>/dev/null' | 13:26 |
| vila | OSError: [Errno 2] No such file or directory | 13:29 |
| vila | Upon execvpe python ./bzr selftest --subunit 2>/dev/null ['python ./bzr selftest --subunit 2>/dev/null'] in environment id 48676992 | 13:30 |
| lifeless | urgh | 13:30 |
| lifeless | ok | 13:30 |
| lifeless | make a tiny little shell script | 13:30 |
| lifeless | put it on the slave. | 13:30 |
| lifeless | run that | 13:30 |
| vila | exactly what I wanted to avoid :-/ | 13:30 |
| === mrevell-dejeuner is now known as mrevell | ||
| vila | but well, certainly the easiest in the mean time | 13:30 |
| vila | lifeless: I'm tracking --usepty which is used at slave start and tie stdout and stderr, that may be a viable alternative | 13:32 |
| lifeless | vila: whatever is easiest | 13:43 |
| vila | done, try with 13 as number in the prvious url | 13:46 |
| vila | rats, wait, I changed a part of the path | 13:47 |
| vila | http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text | 13:48 |
| vila | lifeless: by the way, I went with the shell route, one more dependency but that's not a concern here | 13:52 |
| vila | lifeless: and the schedule is 11PM my time i.e. 9 hours from now | 13:54 |
| vila | approx your breakfast no ? :D | 13:54 |
| lifeless | wget -O- 'http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text' | subunit-ls --times | sort -n -k2 -r | head -n 20 | 14:19 |
| lifeless | :P | 14:19 |
| lifeless | gnight | 14:19 |
| === psynaptic is now known as psynaptic_afk | ||
| lifeless | vila: just confirming - thats not using --parallel | 14:23 |
| vila | lifeless: my god no ! :D | 14:24 |
| lifeless | cool, thanks | 14:24 |
| lifeless | bzrlib.tests.test_source.TestSource.test_no_asserts 24.874 | 14:24 |
| lifeless | bzrlib.tests.blackbox.test_breakin.TestBreakin.test_breakin 10.460 | 14:24 |
| lifeless | bzrlib.tests.test_hashcache.TestHashCache.test_hashcache_load 5.014 | 14:24 |
| lifeless | ... | 14:24 |
| lifeless | its working - great | 14:24 |
| lifeless | now, we just need a better QL for subunit | 14:24 |
| vila | committed and publish on lp, patches welcome the script name time-selftest.sh | 14:25 |
| lifeless | but I'm really really wiped, still sick & I meant to be in bed hours ago :( | 14:25 |
| * lifeless goes | 14:25 | |
| vila | lifeless: and don't take the actual timings are accurate ! Lots of things happending here (catching up the no extensions failures) | 14:25 |
| vila | s/are/as/ | 14:25 |
| vila | lifeless: sleep well ! | 14:26 |
| === psynaptic_afk is now known as psynaptic | ||
| === mario__ is now known as pygi | ||
| los | hi guys. Is there anything like: bzr diff --old XXX --new YYY --annotated ? | 15:42 |
| los | I was looking for something that would show the diff annotated with info from YYY | 15:42 |
| awilkins | bzr annotate YYY -r old-revision ? | 15:44 |
| awilkins | Oh wait | 15:44 |
| awilkins | Probably want the new revision number | 15:44 |
| awilkins | los: qannotate is pretty good :-) | 15:45 |
| los | awilkins, checking... | 15:45 |
| los | awilkins, sorry for delay. | 16:35 |
| los | awilkins, I need it text based and basically what I want is: diff between the two trees + annotation on diff with data from more recent tree | 16:35 |
| los | awilkins, any thoughts? | 16:41 |
| awilkins | los: What's the metadata you want in the annotation? | 16:51 |
| los | awilkins, committer would be enough, revno is optional | 16:52 |
| awilkins | los: You may have to implement that if you want it ; it supports diff between arbitrary revisions but it doesn't have the --annotate option and I can't think of a simple way of doing it | 16:53 |
| awilkins | But I'm not totally conversant with the innards | 16:53 |
| los | awilkins, yes, that's what I was suspecting as well. | 16:54 |
| los | awilkins, I was referring to the fact that I may need to implement it myself... :) | 16:55 |
| awilkins | los: At least it won't be as hard as it would be for git (although I bet git already has it) | 16:55 |
| awilkins | (and that's where your usage example is from) | 16:55 |
| los | awilkins, I was not aware of that. | 16:56 |
| awilkins | los: I don't know if git has it, TBH, I don't use git a lot | 16:57 |
| awilkins | los: But if you review the implementation of annotate and diff I'm sure it's not hard to concoct it | 16:57 |
| awilkins | Right, train time | 16:58 |
| los | awilkins, thx | 16:58 |
| sender | is there a way to ignore everything in /sites/default, except for /sites/default/files/showcase, without spelling out out all other directories? | 17:11 |
| sender | RE:(?!sites/default/files/showcase/*).* works but ignores too much, e.g. a new file in root | 17:11 |
| sender | RE:(?!sites/default/files/showcase/*).sites/default/**/* gives an python error ... | 17:12 |
| kothog | I am curious: I am looking for a way to mirror a remote bzr repository locally--like a git clone, or a hg clone, or svnsync. Is there a way to do this with bzr? I don't need a working copy: just a copy of the remote bzr repository data. | 17:22 |
| kothog | (I know I can pull a remote branch locally.. but does that get history and all other branches of the project, too?) | 17:23 |
| beuno | kothog, not at the moment, no | 17:25 |
| kothog | sad kothog. | 17:26 |
| kothog | anything experimental developers want a test monkey for? | 17:26 |
| beuno | kothog, I know there's a plugin called multi pull | 17:29 |
| beuno | that may do something similar | 17:29 |
| kothog | k..! thanks beuno, appreciate your time and answers. :) | 17:29 |
| maxb | Does anyone know why cvsps-import chooses to represent CVS tags as bzr branches? | 17:36 |
| phinze | i'm continually getting Contents conflict in features/support/env.rb when i merge from trunk to project branch... i keep doing cp features/support/env.rb.OTHER features/support/env.rb; bzr resolve; but then next merge with a change for that file says it again | 17:55 |
| phinze | what am i doing wrong here? | 17:55 |
| phinze | maxb: i would imagine that's because CVS's concept of a tag is really closer to a bzr branch than what bzr calls a tag | 17:57 |
| phinze | in bzr a tag is really more of a "revision nickname" | 17:57 |
| phinze | http://bazaar-vcs.org/Tag | 17:57 |
| phinze | whereas in cvs tag is really just a convention -- a branch you never write to that you call a "tag" | 17:57 |
| maxb | That is not really true | 17:58 |
| maxb | A CVS tag is a nickname for a tree-state | 17:58 |
| phinze | (i was assuming svn maps back to cvs in that way... entirely possible i was wrong) :) | 17:58 |
| maxb | In most cases one would hope and expect that the tree-state referred to a single point in time, i.e. a revision | 17:58 |
| maxb | It is, however, true that a CVS tag can indicate a horrendous mishmash which corresponds to no true single revision | 17:59 |
| phinze | ah, so it is like svn in that way, where each file can be at a different revision | 17:59 |
| phinze | can't speak for its devs, but i imagine that the cvs import was just taking the safe route? :) | 18:00 |
| phinze | so in CVS you cannot "commit" to a tag location? | 18:01 |
| phinze | because you could do that in SVN | 18:01 |
| phinze | okay getting somewhere: "(Bazaar currently relies | 18:05 |
| phinze | of content analysis to detect binary files for commands like ``diff``. | 18:05 |
| phinze | In the future, a ``binary = true`` rule may be added but it is not | 18:05 |
| phinze | supported yet.) | 18:05 |
| phinze | now to find the nature of that content analysis that is deciding my config file is binary | 18:06 |
| phinze | so if a NUL byte occurs in the first 1024 bytes | 18:07 |
| phinze | then bzr decided the file is binary | 18:07 |
| phinze | *decides | 18:07 |
| phinze | interesting | 18:07 |
| === BjornT_ is now known as BjornT | ||
| awmcclain | We're getting this error when trying to buld 1.18 from source and 2.0 from easy_install: Cannot build extension "bzrlib._annotator_pyx". | 18:27 |
| awmcclain | Use "build_ext --allow-python-fallback" to use slower python implementations instead. | 18:27 |
| awmcclain | *build | 18:27 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| === Edwin-lunch is now known as EdwinGrubbs | ||
| === EdwinGrubbs is now known as Edwin-lunch | ||
| kfogel | Anyone know why I'm getting this, having just upgraded to latest trunk bzr? http://paste.ubuntu.com/273029/ | 19:59 |
| pwolanin | anyone able to explain how bzr merging/tracking works in terms of different branches and history? I'm trying to understand what the best workflow would be for a set of inter-related branches | 20:00 |
| vila | kfogel: because you didn't run 'make' in your source directory | 20:01 |
| kfogel | vila: ah, thanks. 'python setup.py build' used to do it; I guess not anymore? | 20:01 |
| vila | build_ext you mean ? | 20:02 |
| kfogel | vila: that fixed it | 20:02 |
| kfogel | vila: I used to just do "python setup.py build" and get a trunk bzr that didn't give any warnings, and did use the C extensions. | 20:02 |
| kfogel | vila: apparently, that's no longer sufficient, and I should run "make" instead. | 20:02 |
| vila | kfogel: I never use build myself, always make, may be worth filing a bug | 20:02 |
| kfogel | abentley: is it a bug that "python setup.py make" no longer seems to build bzr with C extensions, and "make" must be used instead, or was the old behavior just a coincidence and "make" is the Official Way? | 20:03 |
| === Edwin-lunch is now known as Edwin-afk | ||
| === Edwin-afk is now known as EdwinGrubbs | ||
| abentley | kfogel: No, it was "python setup.py build". | 20:05 |
| sque | Hello I am trying to setup a multi-user server and I have really bad times with file permissions... I followed guides from here | 20:19 |
| sque | especially i the part tha says "Setting permissions" | 20:19 |
| sque | However.. the experiment failed. I created a folder named /bzr with 02770 permissions owned by root/bzr | 20:20 |
| sque | but when I create a repository inside this folder it is created with those permissions: http://pastebin.com/d2a0c903d and commit from a non-root fails as it cannot write inside .bzr/branch/lock | 20:21 |
| sque | can anyone advise me on what to do with file permissions? | 20:25 |
| kenichi_ | if you have a branch with no working-tree, how bad is it to create a branch of that branch, *under* the parent? | 20:58 |
| zsquareplusc | sque: don't you need write permissions for the group on the folder? it can't create the lock file otherwise | 21:01 |
| phinze | kenichi_: i have no idea, but that's a hilarious question ;) | 21:02 |
| kenichi_ | ha, thanks. i can't think of anything *technically* wrong with it... | 21:04 |
| === cprov is now known as cprov-afk | ||
| === doctormo_ is now known as doctormo | ||
| doctormo | Advice please, how easy is it to tie into bzrlib to do a checkout while keeping gtk mainloops from freezing? | 21:15 |
| sender | anyone the best way to resolve a "bzr: ERROR: KnitPackRepository('...')is not compatible withRemoteRepository('...')different rich-root support" error? I'm surprised as this comes up while pulling from the original repo... | 21:19 |
| sque | zsquareplusc: Either I am an idiot or this bzr is NON user-friendly at all | 21:28 |
| LarstiQ | sque: use posix acls | 21:29 |
| Tak | don't you need to set the default umask as well? | 21:30 |
| sque | LarstiQ: I am trying very hard! | 21:30 |
| sque | What I have till now for the best practise is to create a group (I named it "bzr") and add all potential users of repository in it | 21:30 |
| sque | Then i created a folder with 02770 permissions where it is my shared repository | 21:31 |
| LarstiQ | sque: don't use plain old unix permissions | 21:31 |
| sque | you mean ACL? | 21:31 |
| LarstiQ | setfacl -m group:developer:rwx /bzr | 21:31 |
| LarstiQ | setfacl -m default:group:developer:rwx /bzr | 21:31 |
| LarstiQ | sque: the default: will cause newly created directories to inherit the right permissions | 21:32 |
| sque | this is the best way? | 21:32 |
| LarstiQ | sque: plain unix permissions can not express that wish | 21:32 |
| LarstiQ | sque: yes | 21:32 |
| kfogel | abentley: sorry, that's what I meant (typo in IRC, not on the commandline) | 21:32 |
| spirov92 | hi, I'm kinda confused. I made some changes in one branch, commited, then tried to push it on another branch over sftp, but the actual files are not modified. any ideas why? | 21:32 |
| doctormo | Forget my last question, I'm stealing from bzr-gtk instead | 21:32 |
| sque | LarstiQ: I know and that's why I am banging my head at the wall. Didn't thought to use ACLs. To tell you the truth I only know that it exists never used before, but I am asap to read more about it. | 21:33 |
| LarstiQ | sque: https://bugs.edge.launchpad.net/bzr/+bug/50568/comments/9 | 21:33 |
| ubottu | Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] | 21:33 |
| LarstiQ | sque: they're very handy :) | 21:33 |
| abentley | kfogel: In revno 4640, "setup.py build" does build extensions. I haven't got a more recent bzr due to bug 430738 | 21:35 |
| ubottu | Launchpad bug 430738 in bzr "Upgrade fails with NoSuchId in _iter_file_id_parents in add_inventory_by_delta" [High,Confirmed] https://launchpad.net/bugs/430738 | 21:35 |
| spirov92 | when I make changes in one branch and bzr push from that branch to another, the changes should be copied to the other one, right? | 21:35 |
| spirov92 | anyone willing to help a n00b? | 21:40 |
| LarstiQ | spirov92: yes, the changes will then be in the other branch | 21:40 |
| spirov92 | but the actual files should be copied too? I don't see the actual files being modified | 21:41 |
| Tak | spirov92: pushing over sftp? | 21:42 |
| spirov92 | yes | 21:42 |
| LarstiQ | spirov92: if the other branch has a working tree, you will need to run `bzr update` for it to update the workingtree | 21:42 |
| LarstiQ | spirov92: but are you sure you need a working tree on it? | 21:42 |
| LarstiQ | spirov92: all bzr needs is in .bzr/ | 21:42 |
| spirov92 | yep, I need a working tree, since the sftp branch is a website | 21:46 |
| spirov92 | um...the server doesn't have bzr installed. how do I update the tree over sftp? | 21:47 |
| LarstiQ | spirov92: I recommend you use the bzr-upload plugin instead to do deployment | 21:48 |
| spirov92 | hmm...where do I actually get the upload plugin? can't find it in any openSUSE packages :( | 22:01 |
| LarstiQ | spirov92: lp:bzr-upload | 22:01 |
| LarstiQ | spirov92: so, `bzr branch lp:bzr-upload ~/.bazaar/plugins/upload` | 22:01 |
| spirov92 | thanks :) | 22:02 |
| * LarstiQ heads to bed | 22:02 | |
| spirov92 | yay, I now have the plugin :) | 22:03 |
| LarstiQ | spirov92: see `bzr help upload` and or the README for instructions | 22:03 |
| LarstiQ | night | 22:03 |
| spirov92 | night | 22:04 |
| spirov92 | hmmm....if I just copy the entire working tree and .bzr folder to another machine, it will still work, right? | 22:05 |
| sque | LarstiQ: Ty very much it worked perfectly with ACL :) | 22:37 |
| zsquareplusc | i'm using bzr cvsps-import and its creating thousands of notifications (bzr-notify). can i do something to clear the queue of notifications? | 23:05 |
| lifeless | oh heh | 23:06 |
| lifeless | kill the bzr-gtk process :) | 23:06 |
| thumper | why does windows suck so much | 23:06 |
| thumper | I got bzr working very easily | 23:07 |
| thumper | getting it to push over bzr+ssh to another machine still doesn't work | 23:07 |
| lifeless | is the other machine running a ssh daemon? | 23:07 |
| thumper | I think there is some firewall thing somewhere that is blocking port 22 | 23:07 |
| lifeless | are you @ home? | 23:07 |
| lifeless | there is a firewall in windows, configure it via control panel | 23:08 |
| thumper | lifeless: I talk from my laptop to the desktop from home and away using linux | 23:08 |
| thumper | lifeless: I was in windows on the same laptop failing last night | 23:08 |
| lifeless | ok | 23:08 |
| lifeless | see the control panel then :) | 23:09 |
| lifeless | why the need for windows though? | 23:09 |
| thumper | there is also norton internet security | 23:09 |
| thumper | lifeless: to iron out the instructions for 3 other people I'm trying to teach bzr | 23:09 |
| lifeless | brave man | 23:09 |
| zsquareplusc | lifeless: i don't see a bzr-gtk process but there is a bzr-notify which i killed now, but notifications keep displaying. there is a queue somewhere :/ | 23:23 |
| lifeless | vila: urgle, you left in imports of config, after tweaking to not use it! | 23:23 |
| lifeless | zsquareplusc: well, if you killed off the dbus reflector it will have spawned again | 23:24 |
| zsquareplusc | lifeless: hm, i don't know what that is. killing bzr-notify worked and it did not restart | 23:25 |
| lifeless | zsquareplusc: ok | 23:25 |
| zsquareplusc | lifeless: it's not much of a problem. i'd just wish bzr cvsps-import would not create notifications for each changeset it's converting :p | 23:27 |
| === Pilky_ is now known as Pilky | ||
| zsquareplusc | sorry to interrupt, poolie and/or lifeless, maybe one of you or someone with good bzr knowledge should probably check the instructions on sourceforge. i had problems understanding if they support multiple branches per project. maybe it's just me who did not understand but i think they should have a good description so that project admins feel confident to choose bzr over the other VCS they... | 23:57 |
| zsquareplusc | ...also offer. | 23:57 |
| zsquareplusc | that would be this page here: http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar | 23:57 |
| zsquareplusc | oh and they really do support multiple branches :-) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
