/srv/irclogs.ubuntu.com/2009/12/09/#bzr.txt

* poolie looks00:01
poolieok00:13
mwhudsonthe bzr-builder "parser" is a little sad making00:25
james_woi!00:30
mwhudsonjames_w: hi :-)00:31
mwhudsonit'00:31
james_whi mwhudson :-)00:31
james_woutput from "bzr merge":00:32
james_wdeleted misc00:32
james_w...00:32
james_wPath conflict: misc / misc00:32
james_w"bzr st":00:32
james_wremoved:00:32
james_w  misc/00:32
james_w...00:32
james_wconflicts:00:32
james_w  Path conflict: misc / misc00:32
james_wls misc*:00:33
james_wNo matches: misc*00:33
james_wwhat sort of conflict is that?00:33
spivjames_w: exciting?  confusing?  There are lots of adjectives ;)00:35
james_wmwhudson: I don't have anything specifically against using a "proper" parser, I'd just like it to pass the tests, or equivalent ones00:35
james_wIt's not inexperience that led to that implementation00:36
james_wspiv: I'd say both of those apply00:36
james_wI've no idea how to resolve it, or even why I thinks I need to00:36
mwhudsonjames_w: it would be nice if there was a grammar for recipes i think00:36
james_wyes00:37
mwhudsonit's not that the current parser is bad, but it's a bit of a blob00:37
mwhudsonseparate lexing and parsing might be nice00:37
james_wand then it would be nice if the parser was generated from that, so it was confirmed to be nice00:37
mwhudsonbut maybe that's ott for something simple00:37
mwhudsonjames_w: my use case is wanting to rewrite the branch references in a recipe00:38
james_wlexing is hard in this case00:38
mwhudsoni guess line.split() is a fair approximation of what's possible actually :)00:39
james_wyes00:40
james_wplus, "bzr tag 'a tag'" would lead to some issues00:40
james_wand spaces in URIs may be a bit of a pain with bzrlib00:40
mwhudson%20 ftw i guess00:41
mwhudsonbut you can't put a space in the url of a branch on launchpad so...00:41
james_wtrue00:42
james_wthe issue is that bzr transports take strings, and there's no way to tell if whether it is escaped or not00:42
james_we.g. https://bugs.edge.launchpad.net/bzrtools/+bug/31063100:44
ubottuUbuntu bug 310631 in bzrtools "bzr patch doesn't understand query strings in URLs" [Undecided,New]00:44
mwhudsonjames_w: i think bzrlib generally assumes that urls are escaped00:45
mwhudsonso that looks like a straight up bug00:46
mwhudsonhm, i guess you're right, it's a bit muddled00:53
james_wbzrtools is doing urlutils.normalize_url() on the path, which might be wrong00:55
james_wnot doing it might give other problems though00:55
mwhudsonno, it's the split path and get that's messing things up00:56
mwhudson>>> urlutils.normalize_url('http://python.org/?arg=value')00:56
mwhudson'http://python.org/?arg=value'00:56
james_wah00:57
james_wthat bug's all over the place in my code then00:58
mwhudsonwell00:58
mwhudsoni don't know what the right fix is00:58
mwhudsoni guess httptransport's .get() is broken00:59
mwhudsonbut fixing it might break other stuff00:59
mwhudsonjames_w: bzrlib.transport.Transport._unsplit_url says in the docstring01:02
mwhudson        Build the full URL for the given already URL encoded path.01:03
mwhudsonbut then escapes the path anyway01:03
=== r0bby_ is now known as r0bby
lifelessjam: https://ec2-sshd.dev.java.net/02:26
mwhudsonjames_w: still here?02:46
james_wyep02:47
mwhudsonjames_w: where in the world are you at the moment? ;)02:49
james_whome02:49
james_wphysically, if not temporally.02:49
mwhudsonyikes02:49
mwhudsonjames_w: we have this need to rewrite the branch urls in a recipe02:49
james_wyes02:50
mwhudsonpartly this relates to the way we plan to store the recipe for the moment, but we'll also need it to inject the credentials for building from private branches02:50
mwhudsonjames_w: i think it makes sense for this code to be part of bzr-builder02:51
james_wyep, in some form02:51
mwhudsonjames_w: i'm not sure whether the input to this functionality should be the recipe text or the BaseRecipeBranch02:52
mwhudsonthe problem with starting with the latter (and attacking the manifest generating code i guess) is that you'll lose comments and formatting02:52
james_wnot sure offhand02:52
james_wit would be possible to preserve that02:53
james_wfugly, but possible02:53
mwhudsonunless you make the parser smarter02:53
mwhudsonyeah02:53
james_wpreserving comments is probably something we should do anyway02:53
mwhudsonif you take the text as input, you can probably just remember where the branch urls came from and string manipulate them out02:54
mwhudsonjames_w: preserving comments in the manifest, you mean?02:54
james_wyeah02:54
mwhudsonok02:54
mwhudsonwell that's an argument towards making my changes more "core" and less of a parallel hack i guess02:54
mwhudsonwhich is probably a good thing02:55
james_wyeah02:55
james_wI dread the code to preserve though02:56
james_wI think we might need to change the model to make it palatable02:56
james_wor maybe not too much02:56
mwhudsonit's not clear to me where you'd put comments in the model02:57
james_wperhaps a new instruction that's a null, but stores the comment?02:58
mwhudsonjames_w: i guess03:02
mwhudsonjames_w: edge cases galore though03:03
mwhudsonjames_w: spot the difference! http://pastebin.ubuntu.com/337738/03:03
james_wthem the rules! :-)03:04
spivmwhudson: makes perfect sense ;)03:04
james_wwe could fix that case if you want to file a bug though03:04
james_wtry putting 3 spaces in the middle line though :-)03:05
mwhudsonoh and you can't have comments at the end of significant lines03:05
mwhudsonjames_w: i noticed the mandatory two space indent, at least that gets around some of python's complexity here :)03:06
james_wthat's one of Mark's :-)03:06
mwhudsonheh heh03:06
mwhudsonjames_w: is not being able to put comments at the end of a line a feature?03:09
mwhudsonit leads to some slightly strange error messages03:10
james_wI don't think it is03:10
mwhudsonok03:10
* mwhudson gets his bug filing hat on03:11
mwhudsonjames_w: https://bugs.edge.launchpad.net/bzr-builder/+bug/487174 reminds me to ask you what the branch ids are for03:12
ubottuUbuntu bug 487174 in bzr-builder "Doesn't enforce uniqueness of branch ids" [High,Triaged]03:12
james_wrevno:<id>03:15
james_wand derivation when we implement that03:15
mwhudsonjames_w: oh, in the debversion?03:19
james_wyeah03:19
mwhudsonmakes sense03:20
mwhudsonjames_w: i filed three bugs, i guess you got emailed about them03:22
james_wI do, thanks03:23
treeform1rit keeps asking me for password how can i unbind03:24
treeform1rif it says i am unbound?03:24
treeform1ri type "bzr unbind" - it asks me for passwrod - why?03:26
treeform1ri type it in03:26
treeform1rit says i am unbound allready03:26
treeform1rhow can i just work locally?03:26
mwhudsonjames_w: i worry a bit about the interaction of # and the run command03:29
mwhudsontreeform1r: what does bzr info say?03:29
* igc lunch03:47
gbbzranybody know why bzr is stuck at 1.x in the Fedora repos, even though the package was updated in June of this year?05:00
pooliegbbzr: no, but you could ask on the list05:27
poolieabadger i think is involved with it but he's not here now05:27
jmlhello05:36
jmldoes Gordon Tyler hang out on IRC?05:37
spivjml: I think he does, sometimes05:39
spivjml: nick is dOxxx I think, maybe +/- an x05:40
jmlspiv, thanks.05:41
bignoseI see references to “No handlers could be found for logger "bzr"” in various search results06:30
bignosebut no real clue as to why it would suddenly start happening.06:30
bignoseI gather it's to do with the fact that logging hasn't been properly initialised, but why would that suddenly start happening without a change in Bazaar for several weeks?06:31
spivbignose: perhaps because bzr couldn't open ~/.bzr.log?06:37
spiv(or wherever 'bzr --version' says the log file ought to be)06:37
bignoseargh06:38
spivbignose: IIRC a relatively common cause is 'sudo bzr'06:38
bignosewhy does that file occasionally get owned by root06:38
bignosewell, grumble mumble bumble.06:38
spivI *think* there's a bug report about that somewhere, although off the top of my head I'm not sure what bzr can do about it.06:39
bignoseperhaps a FAQ entry would be good on that.06:39
spivWell, I suppose bzr could emit a clearer warning.06:39
bignoseyes, that too.06:39
bignoseit would be good to say explicitly that Bazaar doesn't have the permission it needs to its own log file.06:40
spmspiv: so THAT's what that means. I've been happily ignoring it till now. face? please meet palm. Gah. I should have just asked... lala me06:46
spivspm: heh06:48
* spm emails losas with this fine tidbit of info06:48
spivIt's bug 354843 FWIW06:50
ubottuLaunchpad bug 354843 in bzr "better handle failure to open ~/.bzr.log - Bzr should be smart about who owns ~/.bzr.log" [Medium,Triaged] https://launchpad.net/bugs/35484306:50
spiv(And I just marked two other bugs as dupes of that!)06:50
spivOh hmm we have two 'Critical' bugs, I hadn't noticed that.06:56
jmlI really, really want to depend on launchpadlib.uris07:28
spivjml: sounds a bit like an ad campaign for a cleaning product... "launchpadlib... you can depend on it!"07:36
jmlheh07:36
vilahi all07:37
vilaspiv: I don't think #461992 is critical, a 700MB *VM* that can't co a 1GB file... gee, increase the VM ram...07:39
vilajml: ECONTEXT, I'm sure launchpadlib.uris is great why advertising it here ? :D07:41
vilas/great why/great BUT why/07:41
vilaHere I go, ruining my first joke of the day with stupid typos... not even a good joke...07:42
jmlvila, because I could delete code from bzrlib.plugins.launchpad07:42
vilaha! And you fear the consequences :)07:42
jmlvila, well, bzr can't have a hard dep on launchpadlib, realistically07:42
vilayeah, but I thought the plan was to make it a soft one07:42
jmlvila, also, launchpadlib.uris was added to launchpadlib mere hours _after_ the last version of launchpadlib was released07:43
vilaLOL07:43
vilaGimme the new toys !07:44
jmlit was released last in October07:44
vilaargh07:44
jmlthere's been a whole release of Ubuntu since then.07:44
vilajml: don't get me wrong, there are very good reasons to use the new toys :)07:45
MvGHi! Is there some public official way to have bzrlib determine the relation between two revisions? I'm thinking along the lines of Branch._revision_relations, preferably with the caching Repository.__heads as the backend graph.07:47
spivMvG: I guess doing g = repo.get_graph();  heads = g.heads([revA, revB]) gives you that info with reasonable caching.07:52
spivMvG: I think it would be reasonable to promote _revision_relations to a public API somewhere, although it probably doesn't belong on branch.07:53
MvGI think so, too.07:53
MvGI guess I'll write a mail requesting that. Last time I wrote such a mail, I was told the function I requested already exists (Repository.iter_reverse_revision_history), so I thought I'd ask here first this time. :-)07:54
spivMvG: so what I'd do then is rely on _revision_relations and file a bug about promoting it07:54
spivHeh.07:54
spivWell, it's possible that it already does and I just haven't thought of it :)07:54
spivIf it does, then presumably I can remove _revision_relations and cut down on duplicated code ;)07:54
spivHmm, I think it probably makes sense a method on Graph.07:55
spivI suppose Graph.find_difference sort of gives you the same thing.07:56
spivDunno what the performance of that is lie.07:57
spivlike, rather.07:57
spivThere's Graph.is_ancestor, which gives you part of the info.07:58
MvGGraph.find_difference does much more: it seems to list all revisions which are ancestor of one head but not of the other. Way too much overhead.07:58
spivBut no equivalent method that I can see.07:59
MvGGraph.is_ancestor is implemented in terms of heads, so using heads directly to determine both directions should cut my costs by hald at least.07:59
spiv_revision_relations is also implemented in terms of heads.07:59
MvGYes, that's how I found it.07:59
spivBut only makes a single heads call, of course.07:59
spivAnyway, a patch to move _revision_relations to Graph with a public name makes sense to me.  I'd happily review a patch to do that, presumably we'd want to add unit tests for it though.08:00
MvGspiv: Why to graph, not to repository? Repository.__heads is a special caching graph instance, and reusing that instance seems benificial to me.08:07
spivMvG: Repository.get_graph() should already be caching, so I don't think there's a practical difference08:12
MvGRepository.get_graph() does cache the graph itself, while Repository._heads does cache results from heads requests directly.08:13
spivWell, I suppose __heads is specially optimised for heads() lookups.08:13
spivBut if it's that useful I would think it should be cached on graph rather than the repository.08:14
spivMvG: Actually Repository doesn't have __heads/_heads, you're looking at CommitBuilder I think08:15
spivMvG: which probably explains why there's no code that resets the _heads cache during Repository.unlock, and probably also ensures the memory impact of that cache will be small :)08:16
MvGspiv: You're right. I guess I'm too used to Java, with its one class per file paradigm.08:17
jmlOn https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth/+merge/15853, poolie points out that the patch will cause launchpadlib to be loaded whenever bzr is loaded08:18
MvGOK, so we assume that caching all heads requests might be too expensive, and furthermore that we can get at a reasonable caching graph using Repository.get_graph(). In this case a method in Graph would really be the better alternative, I guess, yes.08:18
spivMvG: right08:18
jmlI thought plugins were loaded lazily08:18
jmlif they aren't, how can I do a conditional lazy import?08:19
spivMvG: if you find with that that performance isn't good enough, then we can always try to think of ways to do better :)08:19
spivjml: they can't be; otherwise how can a plugin e.g. decorate a builtin command the way bzr-loom does?08:19
spivjml: however, plugins can and should use lazy_import themselves08:19
jmlspiv, ok. that's good to know.08:20
jmlspiv, how do I do a lazy import that behaves like the one in the patch?08:20
spivjml: in my ideal world, a plugin's __init__ would register commands or hooks or whatever it needs to do, and have the rest of the code lazy imported.08:20
* spiv looks08:20
spivjml: so, you want lp-mirror to only exist if the dependency is available?08:21
spivjml: why not make it always exist, but give an error if the dependency is missing?08:21
spivjml: I think that might be a nicer UI too, it seems more discoverable to me08:22
jmlspiv, I guess I could do that.08:22
spiv"Why don't I have lp-mirror, I have the launchpad plugin!"08:22
spivjml: and in that case, the lazy import can just be a good ol' fashioned local import in the run method of that Command if you like.08:22
jmlspiv, I can imagine it being a little confusing to have lots of available commands that you can't actually use.08:22
spivWell, let's worry about that when we have lots rather than one?08:23
* igc dinner08:23
spivI can imagine making some infrastructure for that, maybe provide something like "bzr plugins --check-deps" that plugins can hook into?08:24
spivBut we already have this situation with e.g. SFTP support without causing much drama.08:24
spiv(If you don't have paramiko I believe attempts to use sftp:// URLs will give you a relatively friendly error about needing paramiko)08:25
spivAnyway, I'd argue it's no more confusing than commands simply not existing even though you think you've installed the plugin that provides it.08:26
jmlOK08:26
spiv(Or with a bundled plugin, that you think you've installed the version bzr that bundles the plugin that provides it... see, confusing ;)08:27
spivjml: I'll add a brief note about my opinion to the review for posterity08:28
MvGspiv: I guess I'd rather return a number (e.g. -1, 0, 1) instead of a string, as numbers are cheaper to compare. Opinions?08:31
spivMvG: strings are almost as cheap to compare, especially if they are literals that contain strings that can be Python identifiers, because those strings are interned08:32
spivMvG: so the comparison in that case is basically just a pointer comparison08:33
spivMvG: I'd be happy have module-global constants for those strings, I think.08:33
spivMvG: but I really doubt that the cost of that comparison will be significant compared to the cost of the underlying heads call!08:33
MvGProbably true, yes.08:34
spivMvG: If you measure a performance problem, I'd be very happy to look at the measurement and figure out improvements, though :)08:34
spivMvG: but I strongly advise against micro-optimisations that impact code clarity without evidence that they'll have a significant effect.08:34
MvGAgreed. Didn't know about Python cheaply comparing such things.08:35
MvGspiv: would you agree that the plural in "_revision_relations" is wrong? There is only one possible relation between any two given revisions.08:36
spivMvG: yes08:37
spivMvG: I've no idea why I never noticed that before :)08:37
spivMvG: as far as Python cheaply comparing such things, I've skipped over a bunch of mostly unimportant details about how CPython compares ints and how it compares strs... But the general rule of measure before guessing about optimisations certainly applies :)08:39
spivMvG: I'll happily chat about CPython implementation trivia sometime if you like, but not tonight :)08:40
MvGspiv: I guess I also had some concerns about typos in literals on the part of the caller, but constants take care of this. By the way, is there some python idiom to declare a constant as opposed to a variable?08:42
spivMvG: CONSTANT = 'value'08:48
spivMvG: rather than: variable = 'value' :)08:49
MvGBut python doesn't enforce constantness on these, does it?08:49
spivNo, but it doesn't enforce constantness on anything, more or less :)08:49
spivExcept the evaluation of 1+1, and I've seen an extension module to change that ;)08:50
MvGspiv: By the way, I sent my mail requesting the method: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/6462208:50
spivMvG: thanks!08:50
sjamaanI'd like to make a checkout (or branch) of only a subdirectory in a repo. Is that possible?09:14
MvGsjamaan: I'm no expert, but I'd guess no. I assume you'd have to branch the whole tree, then you could split of a subdirectory into a separate project if you want to.09:17
MvGAlthough I assume that if you split, changes to that subdir are at least more difficult to merge back into the whole tree. Dunno, though.09:18
sjamaanCan I keep updating the subtree from the main repo?09:25
sjamaan(I've never used SPLIT before)09:25
sjamaanie, can pull fetch data from a subdir in a branch?09:26
jmlspiv, I'm pushing up a new version that makes the change you've suggested.09:29
jmlvery. solwly.09:29
jml(well, after I upgrade it. man, isn't that just the gift that keeps on giving?)09:30
jmlspiv, pushed.09:46
=== weigon_ is now known as weigon
TeTeTI run into a problem on karmic when pushing to LP, http://pastebin.ubuntu.com/337892/10:02
TeTeTit says different rich-root support10:02
TeTeTI assume I need to upgrade the LP branch10:17
=== jelmer_ is now known as jelmer
spivTeTeT: right10:43
spivTeTeT: generally "bzr upgrade lp:FOO" should Just Work.10:44
TeTeTspiv: can I still access the branch from hardy then with the new format?10:57
=== gdmfsob is now known as mishok13
spivTeTeT: you need bzr 2.0 (or at least 1.18), which I don't think is in hardy's backports yet, but we have a backport in the PPA: https://edge.launchpad.net/~bzr/+archive/ppa11:40
TeTeTspiv: ok, so I rather branch on merge on hardy then, so it stays compatible, thanks11:42
spivTeTeT: if you create your repo with --pack-0.92, it'll be the same format as that branch on Launchpad11:49
TeTeTspiv: I do that for init-repo?11:51
spivTeTeT: yep11:58
TeTeTspiv: thanks for your help!12:06
spivTeTeT: not a problem, glad I could help.12:07
spivjml: are you sure you pushed?  I don't see any new revisions12:19
spivjml: oh, it's stacked on the old, non-rich-root, bzr trunk, so boom: https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth12:20
spivjml: I think bzr and launchpad can take equal credit for that snafu ;)12:20
=== Meths_ is now known as Meths
vilajam, jam1, jam*: ping13:32
=== CardinalXiminez_ is now known as CardinalFang
=== thunderstruck is now known as gnomefreak
jamvila: pong14:47
jamsorry, pidgin disconnected and didn't want to reconnect until I restarted it14:47
vilabad pidgin :)14:48
vilajam: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 is up for windows tests14:50
vila./bzr selftest -s bt.test_osutils.TestTerminal should now pass14:50
vilabut see cover letter for my requests ;-)14:51
__monty__Is it a good idea to have a hand at some low priority bugs to get more python experience?14:51
vila__monty__: sure14:51
rubbs__monty__: sure. The devs here are really good at helping you through the process of getting it included too.14:52
jam__monty__: you might look for the "easy" tag14:52
jamif people haven't grabbed them all already14:52
jamI think there might also be "trivial" ?14:52
jamvila: so, one of the primary reasons to use stderr is because progress bars go to ... stderr14:52
jamso even if you redirect stdout14:53
jamyou still would like to know the term width, to draw a progress bar14:53
__monty__Thanks for the quick replies.14:53
jamthat said, I guess the test suite wants to have stdout width14:53
jamwhich means... it sounds like we should have a flag14:53
rubbs__monty__: I would suggest a trivial tag at first. just to get your first patch in. Then once you get the hang of how to get something in go for something bigger.14:53
rubbsthat's what I did at least14:53
vilajam: bzr help also needs the terminal width but outputs on stdout...14:54
vilaand so does log --line14:55
jamsure14:55
jamthough what should those do when redirected to a file?14:55
jamlog --line, I would probably expect to go full width14:55
vilause None and not cut lines14:55
jambzr help... probably we want to keep it wrapped at a reasonable width14:55
vilayup14:55
jamsince otherwise the full help texts becomes super long14:55
jamor the text editor wraps it in an ugly way14:56
vilalong story short, that's what BZR_COLUMNS is for14:56
vilato come back to windows, using stderr or stdout shouldn't matter since it should not be called anymore14:57
vilayou had some tests with and without redirection, how do they behave now ?14:58
vilawith --subunit and tee IIRC14:58
jamvila: but that is an ugly way to do it14:58
jamBZR_COLUMNS=20 bzr command foo >14:58
jamespec on windows14:58
jamwhere you can't inline it14:59
jamset BZR_COLUMNS=4014:59
jambzr command foo >14:59
jamset BZR_COLUMNS=14:59
jamI would like to have a better answer than that14:59
jambut yes, I'll run the tests14:59
vilayeah I know, poolie filed a bug about using -O to set options without polluting the global options namespace. Fom there having some rules to go from env variables to options should filled the gap. At least for things like BZR_PLUGIN_PATH and BZR_COLUMNS15:00
vilaso you can use say bzr -OBZR_COLUMNS=46 command15:01
vilaor bzr -OBZR_PLUGIN_PATH=-site selftest \o/15:01
jamvila: test suite passes on windows when run manually and when run redirected15:01
jamoops15:01
jamspoke too soon15:01
jamtest_falls_back_to_COLUMNS15:02
jamfails15:02
jamwhen redirected15:02
jam42 != None15:02
jamvila: you have: getattr(sys.stdout, 'isatty', None) before the COLUMNS check15:03
jamso I think that test would fail on Linux when redirected as well15:03
vilayeah, so that test is bogus15:03
vilaCOLUMNS makes sense only for a tty15:04
jamvila: as said before, stderr may be a tty even if stdout isn't15:04
jam... :)15:05
vilahmm15:05
vilaI;m tempted to reply ESCOPE :-)15:06
=== vds1 is now known as vds
jamso, I want my test suite to pass15:08
jamI don't really care about the answer here15:09
jamwhat we've had has been just fine for me for a long time15:09
vilajam: pushing a fix15:09
jamI would be a little concerned about fixing something that isn't broken15:09
jambut apparently for others it is ?15:09
vilawell, the main problem was pagers and the lack of overriding solution15:10
vilaI think the proposed fix make things clearer15:10
vilato address the stdout/stderr I think we need yet another pass on all uses and disambiguate the API by explicitly requesting for either stdout or stderr, the windows heuristic sounds brittle otherwise15:11
vilawhat if stderr is redirected and not stdout ?15:12
jamvila: right, so 'bzr log --line | less' is different than 'bzr log --line > file', but I don't think there is a way to detect the difference15:12
jamvila: unlikely to have stderr redirected and not stdout15:12
jamand if it does, then progress bars do crazy things15:12
vilaOMFG how did they implement pipes 8-/15:12
vilajam: never say unlikely on IRC, fullermd is never far away....15:13
jamwe've had similar issues with encodings based on "| less" versus "> file"15:13
jambecause on windows15:13
jamstandard file encoding15:13
jam!= standard terminal encoding15:13
ubottuError: I am only a bot, please don't think I'm intelligent :)15:13
jamwhich is crazy15:13
jamoh, and it isn't filesystemencoding either15:13
vila!triggers ubottu ?15:13
ubottuError: I am only a bot, please don't think I'm intelligent :)15:13
jamvila: yeah15:14
jamso you can say !paste15:14
jambut only at the beginning15:14
jam!paste15:14
ubottuFor posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic15:14
jam!pastebinit15:14
ubottupastebinit is the command-line equivelent of !pastebin - Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output - To use pastebinit, install the « pastebinit » package from a package manager - Simple usage: command | pastebinit15:14
jaminteresting15:14
jamhard to parse "pastebin it"15:14
jamI thought it was "pastebin init" at first15:14
jamanyway15:14
jamvila: do what feels good to get things passing15:15
jamwe've probably spent far too much time versus the utility already15:15
jam(my feeling is, we're going to get it wrong, probably fairly often. whatever decision we choose)15:15
vilajam: agreed, fix pushed, can you check it works for you15:15
jamvila: all tests pass15:16
vilaon the other hand, people have complained regularly about the lack of pager support, now we have *some* support15:16
vilajam: Courtesy url for votes: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/1585815:17
vila:D15:17
vilayou assigned bzr core devs on #154129 , what do you mean by that ?15:17
jamwe all worked together on implementing 2a15:19
jamso we all get credit15:19
jambug #15412915:19
ubottuLaunchpad bug 154129 in bzr "pack should recompress objects, optimise layout, etc" [Medium,Fix released] https://launchpad.net/bugs/15412915:19
jamwell, at least I didn't feel I should be the only one getting credit, and once the number is greater than 1, there isn't a clear value to put three15:19
vilajam: nevermind, I thought it was still open15:19
jamvila: merge approved, witha bit of a mini rant for posterity15:23
vilalol15:23
vilajam: good summary.... I'll put https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 in some commit message so you'll get true posterity :^)15:25
__monty__Would this: https://bugs.launchpad.net/bzr/+bug/257170 be a good bug for a beginner?15:26
ubottuUbuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]15:26
fullermdHmm?  Somebody summon me with an 'unlikely'?   :p15:30
jam__monty__: probably. I think it is already slightly fixed when there is an exception, but it probably would be good to write out "bzrlib.__version__" on startup always.15:30
jamfullermd: your summoning time has gotten slow recently :)15:31
jamwell, today at least15:31
__monty__jam: By startup you mean?15:31
fullermdWell, you've never met me, so you'll have to take my word for it, but TRUST me; I NEED my beauty sleep   :p15:31
vilafullermd: sleep  is for ?15:32
jam__monty__: the bug is that when the bzr process starts, we log the command line arguments, but we don't put version info into the log file15:32
jamfullermd: sort of a Shrek1 sort of thing? (by night one way, by day another)15:32
__monty__jam: So it doesn't have anything to do with bzr log ?15:33
jam__monty__: correct15:33
jamthis is about .bzr.log15:33
jamnot 'bzr log'15:33
fullermdOf course, in this case I won't contest the unlikely.  Being a csh user, I don't get to adjust stderr without touching stdout   :p15:33
__monty__To work on bzr bugs, which source release should I get?15:35
=== beuno is now known as beuno-lunch
Pilkyouch: http://www.reddit.com/r/programming/comments/acsad/bazaar_blows_goats/15:49
PilkyI sort of agree with the gist of his launchpad comment and the cold start slowness, but the rest of it sounds like "It isn't what I'm used to, waaah"15:50
=== abentley1 is now known as abentley
jamfullermd: why is that the case on csh?16:32
__monty__Should I get the stable or the developer release of the source code to work on bugs?16:38
=== beuno-lunch is now known as beuno
jelmer__monty__, the code from bzr.dev ideally16:43
fullermdjam: You mean historically?  Dunno.  Just how it is.16:45
jamfullermd: is it just that the syntax doesn't let you?16:45
jam__monty__: for this, the stable code would be ok, but bzr.dev is fine, too16:45
fullermdOh, yes.  It's one of the standard csh-whynot-isms.16:45
fullermdYou can dup it onto stdout, and that's about it.16:46
NfNitLoopso... I seem to get the impression that bzr-svn stores more metadata than git-svn when you push back into the upstream svn repo...16:47
NfNitLoopis that true?  Anyone know off-hand?16:48
NfNitLoopOk, I'll ask Google. :)16:49
jelmerNfNitLoop: yes, that's true - bzr has more metadata than git16:51
NfNitLoopI know bzr stores the non-linear history metadata as svn properties...   is that what's missing in git?16:52
NfNitLoopIt may be a bit academic.  If git-svn lets me work with our SVN repo that bzr-svn won't (because at some point in its history there was a file with backslashes in its name)...  I may just suffer through using git.16:57
Takbzr-git < git-svn < svn ? ;-P16:59
NfNitLoopya, ew.17:00
NfNitLoop:p17:00
jelmerNfNitLoop: That's one thing17:00
jelmerNfNitLoop: Other things are: file ids, revision ids and revision properties (none of which git has)17:00
PilkyTak: why not throw hg in there and do bzr-hg < hg-git < git-svn < svn :p17:00
NfNitLoopah, I knew git didn't do file IDs...  it doesn't even store the revision ID!?17:01
NfNitLoopthat seems odd.17:01
PilkyTak: if you tried hard enough you might be able to get cvs in there somewhere17:01
fullermdgit revision id's are entirely derivable from the contents of the revision.17:01
NfNitLoopso if you then do an update you might start getting conflicts with branches that have already merged the changes?17:01
NfNitLoopaaah.17:01
NfNitLoopok, that's fine then.17:01
jelmerNfNitLoop: I'm not sure what the status of backslash support is17:01
NfNitLoopin git?  I guess I'll see when git gets to that revision. :p17:02
TakPilky: I guess that would depend on whether hg or git have a cvs wrapper17:02
Takspeaking of which, I pulled down someone's inadvertent commit of an RCS dir to our svn repo the other day17:03
jelmerNfNitLoop: in bzr17:03
jelmerNfNitLoop, bzr-svn supports backslashes fine17:03
NfNitLoopjelmer: ah, I'm subscribed to the bug about it.  haven't seen any traffic lately.17:03
=== deryck is now known as deryck[lunch]
__monty__Is there a bug which you would advise for a newb?17:58
jelmer__monty__: try looking for bugs triaged trivial in launchpad18:09
__monty__Any of them?18:10
__monty__Such as: https://bugs.launchpad.net/bzr/+bug/23952318:10
ubottuUbuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed]18:10
jelmeryeah, all bugs tag trivial *should* be doable for people looking to contribute to bzr for the first time18:12
jelmerfeel free to ask for mentoring here or on the mailing list18:12
RenatoSilvaverterok: hi18:13
__monty__What are the responsibilities of a mentor?18:13
jam__monty__: it isn't quite an official thing. Just that you can ask for help/questions and we'll try to help you18:19
__monty__Oh ok.18:19
RenatoSilvaverterok: ok np :)18:30
=== deryck[lunch] is now known as deryck
jam__monty__: I should also mention our PatchPilot program: http://wiki.bazaar.canonical.com/PatchPilot19:19
jamWhich is where we have people specifically working on helping people land their patches19:19
johnjosephbachirhello19:47
__monty__hi19:47
johnjosephbachirhow do i make a new remote branch? this equivalent from subversion does not work: bzr branch http://example.com/foo http://example.com/bar19:48
johnjosephbachirdo i make the new branch locally and then push it?19:48
beunojohnjosephbachir, yes19:48
johnjosephbachirthere isn't a more direct way?19:48
beunojohnjosephbachir, bzr init REMOTE_LOCATION19:49
beunobut you can't do it via http19:49
beunoyou will need ssh19:49
johnjosephbachirhow about webdav?19:49
johnjosephbachirbueno what would be the command for ssh?19:49
johnjosephbachirokay, i just did it the push-from-local way, and it worked in seconds -- so i guess bzr was smart about using the remote repo, hoorary19:52
johnjosephbachirsorry for the newb question19:52
rubbsjohnjosephbachir: don't be sorry for newb questions. If anything it gives those of us on the doc team something to consider19:55
rubbs;)19:55
johnjosephbachirthanks19:55
rubbsnp19:55
=== EdwinGrubbs is now known as Edwin-lunch
jmlspiv, I don't supposed you fixed it?20:09
=== BasicPRO is now known as BasicOSX
dOxxx*sigh* cable outages suck :P20:43
=== SteveA_ is now known as SteveA
rubbsdOxxx: yes, cable outages do suck. What caused yours?21:08
dOxxxwe've had a bit of a winter storm here, so I guess it's causing trouble with the wires21:08
dOxxxdon't know for certain though21:08
rubbsah, you in the midwest?21:09
rubbsI used to live in Iowa21:09
dOxxxnope, Toronto21:09
rubbsah, gotcha.21:10
rubbsI live in Ohio now so we're about to get one too.21:10
dOxxxEnjoy! :)21:12
dOxxxhmmm... might be cutting out again soon21:12
dOxxxominous pauses21:13
rubbshaha21:14
fullermdWinter...   yeah, I remember hearing about that, years ago...21:15
phinzeack! my shelf! http://gist.github.com/25286121:49
phinzehmm looks like it's bug 38967421:50
ubottuLaunchpad bug 389674 in bzr "exception encountered when unshelving" [Undecided,New] https://launchpad.net/bugs/38967421:50
phinzeThis is because the conflict handling code has not been fully updated to avoid using Tree.inventory. -- abentley21:51
phinzei'm looking at the shelf-1 file, which is in 'Bazaar pack format 1'21:54
phinzei feel like i know where the evil conflict is, but i don't know how many lines to delete :P21:55
phinzeeh, feels like i'm about 10 minutes short of finding docs on the format, but it's small enough that it's faster for me to manually re-apply the changes21:58
phinzesure21:59
phinzethat worked21:59
jelmerwhat exactly are the release plans for bzr 2.1? Should lucid have 2.1?22:11
spivjml: at 11pm?  No :)22:11
jmlspiv, what are you replying to, excatly?22:11
spivjml: <jml> spiv, I don't supposed you fixed it?22:11
jmlspiv, oh ok. I wasn't online at 11pm, so I was a bit confused.22:12
pooliehi all22:28
mdtI'd like to back up my repositories (weekly using a cron script) to a remote backup service.   Anybody know how to do this?  With CVS I just copied the files in the central repository to the remote server using rsync.22:43
gioelemdt: you can do that with bzr as well22:45
mdtNew to Bazaar so don't rly know how/where data is kept, even22:46
gioelejust rsync the .bzr directory of the repository22:46
gioeleI have a repository at /srv/backup/22:47
gioelethat directory contains a .bzr sub directory22:47
gioeleI use rsync --archive --partial --partial-dir=.rsync-partial --delete-delay --progress -i /srv/backup/ remote:~/backup-bzr22:49
fijalhi22:49
fijalI'm looking for bzr benchmarks22:49
pooliefijal: http://bazaarvcs.wordpress.com/tag/benchmark/22:49
poolieto start with22:49
fijaler22:50
fijalok22:50
fijallet's be more specific22:50
fijalI look for bzr performance benchmarks22:50
spivpoolie: fijal is a pypy dev, I think22:50
fijalcorrect22:50
poolieyou want to test bzr under pypy vs elsewhere?22:50
fijalyop22:50
pooliecheck out https://launchpad.net/bzr-usertest22:51
spivAnd thus wants to make C extensions for performance obsolete ;)22:51
pooliewhich runs various macrobenchmarks22:51
poolieooh, welcome :)22:51
fijaldoes it come with "a standard repository"?22:51
pooliethere are some in-tree microbenchmarks but they tend to rot22:51
pooliefijal: no, it runs on your choice of repository22:51
pooliesince the test data would be large22:51
pooliepossibly we should put some snapshots in its download files22:51
fijalcan I have one large repository please :)22:51
spivfijal: lp:mysql :)22:52
pooliebzr branch lp:mysql22:52
poolie:)22:52
fijalok22:52
pooliehi spiv too22:52
spivGood morning :)22:52
fijalwell, it's sort of hard to look for pure-python benchmarks22:52
fijalwhich are *not* template languages22:52
spivHaha22:52
spivI can believe that :)22:52
mdtso does the .bzr directory contain all the info required to reproduce all the files in my project?  I mean if I simply copy that dir recursively onto a brand new machine somewhere I'll be able to check out my project from it?22:53
fijalfor example mostly everybody moved to C22:53
fijalside question - what's the ratio of oldstyle vs newstyle classes in bzr?22:53
fijal(I'm too lazy to check)22:53
spivPractically all new.22:53
fijalgood22:54
fijalthis is completely unlike twisted22:54
spivIndeed :)22:54
fijalwhich has practically all old22:54
spivWe've depended on python >= 2.4 since bzr began.22:54
spivTwisted didn't have that luxury :)22:54
fijalright22:55
spiv(glyph just cited some 1.5.2 docs at me in a recent review of a patch I just did for Twisted!)22:55
mdt@gioele ty22:56
igcmorning22:57
fijalok22:58
fijalsince it22:58
fijal's midnight I'll actually go to bed22:58
fijalI'll try to make some benchmarks tomorrow then22:59
gioelejust wondering, how long does it take to branch lp:mysql?22:59
spivfijal: oh, lp:mysql-server is actually the large branch I think, I'm not sure there's actually a lp:mysql23:04
spivgioele: well, lp:mysql-server is ~450M of history, although it's still in 1.9 format23:11
Penggioele: You didn't make the destination repo 2a, did you?23:13
gioelePeng: everything is pack-0.9223:13
gioelePeng: couldn't I do that with 2a? I don't see why23:22
* jelmer waves to igc, spiv, Peng and gioele23:22
igchi jelmer!23:23
gioelelifeless: ping23:23
lifelesshi?23:24
gioelelifeless: may I ask you something (in a query) about the la_AU locale?23:24
gioelehi jelmer23:25
jelmerla_AU... is that what I think it is?23:25
lifelessjelmer: lingua latina23:25
spivjelmer: hi :)23:25
lifelessthe AU is a nonsense due to posix being naffed23:25
lifelessgioele: sure, or you can ask here.23:25
gioeleoh, well, OK23:25
Penggioele: It's just that trying to convert lp:mysql-server to 2a over the network ends in unhappiness.23:26
lifelessits not particularly private :>23:26
gioeleI'm trying to create a locale as well (English language with European LC_*)23:26
gioelehow did you test it?23:26
lifelessbuilt packages, installed, ran shit.23:27
lifelessuhm, the xlib thing is the most tricky bit - gnome apps *ignore* xlib's locale support23:27
gioeledid you sudo cp la_AU into /usr/lib/locales?23:27
lifelessso23:27
lifelessno23:27
gioeleok, I suppose I'll have to bzr-debuild some packages :)23:28
lifelessI patched gdm, libc6, libx1123:28
gioelelemme write that down23:28
lifelessthese days you shouldn't need to patch gdm23:28
gioelethese days? why?23:28
lifelessits been rewritten and no longer has a whitelist of locales.23:28
gioeleah, ok, one down23:28
gioelewhat should be done in libx11?23:29
lifelessthere is a long list of keyboard processing stuff23:29
lifelessso you will need to pick a locale that works, find all references to it, and clone them to your new one.23:30
lifelesslocales: why conflating data with different dimensions is a bad idea.23:30
lifelessbreakfast time23:32
lifelessgioele: I blogged about this at the time, with links to my patches23:32
lifelesstwo separate blog posts I think, cause I realised libx11 was broken after the first patch.23:33
gioelelifeless: I read those, this is the reason I'm here asking these questions :)23:33
gioelethe fact is I can't find a link to the libx11 issue23:33
lifelesshmm23:33
spivpoolie: no, I'm not on emacs-devel23:34
lifelessgioele: https://bugs.edge.launchpad.net/ubuntu/+source/libx11/+bug/423569 https://lists.ubuntu.com/archives/karmic-changes/2009-June/002209.html https://edge.launchpad.net/ubuntu/+archive/primary/+files/libx11_1.2.1-1ubuntu1.diff.gz23:35
ubottuUbuntu bug 423569 in libx11 "la locale support was reverted in merge from debian" [Undecided,Confirmed]23:35
lifelesspoolie: you pung on a patch; I'll probably look at it in the new year.23:35
pooliek23:35
poolieis not urgent23:35
pooliejust shows up in my activereviews page23:35
lifelessits bzr-email, right? get jam to review23:35
lifelesshe has done a lot in that plugin as well23:35
lifelessor andrew :) - its a team branch I think, and I feel no special urge to control it23:36
gioelelifeless: thank you, the libx11 part does not look difficult at first sight (now that you dig into it ;))23:38
johnjosephbachiranyone here have much experience with split/join/ nested trees ?23:40
xnoxDoes a "$bzr checkout lp:project" have full branch history?23:42
spivxnox: yes23:42
xnoxBut it is bound?23:42
spivRIght.23:42
spivIf you run "bzr info", you'll see that the repository for it is local rather remote.23:43
xnoxOk. And I can run $bzr reconfigure to change from a regular branch to bound23:43
xnoxCan a checkout still have :parent, :push and :submit?23:44
xnoxOr bound to two places?23:44
spivIt can only be bound to one place.23:46
spivOtherwise you'd have to deal with confusing situations like "bzr commit" successfully updating one place but failing on the other.23:46
xnoxget it =) and confusing23:47
spivWell, I guess in that case lock_write() each place first might be ok... but you get the idea :)  It's complex enough! :)23:47
spivI believe a checkout "has" :parent etc, because actually those belong to the branch, so they are looked up on the bound branch if you have a checkout.23:48
spivSo they work, but I think they belong to the branch rather than checkout itself.23:49
spivI'm not 100% certain about that.23:49
xnoxI'll try to make a :parent :push and then reconfigure as bound23:50
gioelegoodnight23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!