/srv/irclogs.ubuntu.com/2010/04/20/#bzr.txt

igcmorning01:28
pooliespiv, hi01:55
poolieigc, spiv, so in looking at the codebrowse stats it's interesting that the tags file is very hot01:56
pooliewe may be accessing it too much over plain http01:56
spivHuh, that is interesting.01:57
spivSeparately, I've noticed the get_tags_bytes RPC sometimes gets called more than is strictly necessary, perhaps due to the same root cause.01:58
poolieprobably01:59
pooliewhile i was at the hospital cafe the other day i started adding the test-factory concept01:59
pooliei might call it test subjects to avoid touching any sore points about lp test factories01:59
luke-jrjelmer: my bzr-svn problem seems to be rooted in it deciding old-old paths are not branches03:15
luke-jris it possible to tell it *tags* are tags and anything else is a branch? :/03:15
mwhudsonluke-jr: you can set up a custom layout in ~/.bazaar/subversion.conf03:17
luke-jrmwhudson: bzr-svn doesn't like it03:18
luke-jrbranches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*03:18
luke-jrtags = armagetronad/tags/*/armagetronad;armagetron/tags/*;armagetronad/tags/*;armagetronad/armagetronad/tags/*03:18
mwhudsonah i see you're ahead of me then :-)03:19
lifelesspoolie: so what are you and igc hacking on ?03:34
lifelesspoolie: re test-factories, I wish you could explain better what you mean there.03:34
igclifeless: a few things ... poolie is helping me get lp running in a chroot03:41
lifelessigc: I found a VM was much easier03:42
lifelessFWIW03:42
igclifeless: and we're hoping to clean out the loggerhead merge queue as well03:42
poolielifeless: there was a thread from about september last year03:42
poolie'rfc testfactory' or something like that03:42
lifelesspoolie: yes, I remember that thread03:42
pooliebasically i was going to get around to doing the consensus position from that03:43
lifelessah, I didn't remember a consensus other than 'caring about test quality matters'03:43
pooliewhich was to make setup of test data "shorter, standardized and declarative"03:43
pooliei think that was aaron's description03:43
igclifeless: and poolie's explaining hydrazine and the nice work you're doing on improving lp-pqm integration - sounds really promising IMO03:44
lifelessigc: its fixes some process bugs for us03:45
lifelessshould let us add more committers more easily03:45
lifelessand makes it easier to migrate to tarmac if/when we do that03:45
igclifeless: right. I'd like to leverage all the above to make it easier to land stuff from Explorer03:46
poolielifeless: where does the failure message go to?03:46
lifelesspoolie: subunit-filter -> lp merge proposal03:46
lifelesspoolie: bugs filed about getting binary safe attachments on mp's03:47
igclifeless: IIUIC, if a user can toggle the status of a MP from inside Explorer via launchpadlib, then your magic will take care of landing the associated branch from there?03:47
pooliek03:47
poolieigc, yes, it should03:47
poolieand it should be trivial to set it03:48
pooliefinding the right mp may be slightly harder03:48
igcpoolie: for a given repository, I'll simply list the MPs for the matching lp project in a panel03:49
igcwith some action buttons next to each one say03:49
lifelessigc: yes03:51
lifelessfinding the right mp is pretty easy.03:51
lifelessyou can crib from pqm/queue/lp.py - take you ~ 5 minutes03:51
lifelesslisting all the mp's makes sense though, to let them choose the branch03:51
lifelessigc: one [important] thing is to show the diff, because NEWS in particular will often require a manual fixup before PQM submission, to move entries to the right stanza03:52
igclifeless: good point03:53
lifelessthis is a significant sticking point on using MP's to control things03:54
lifelesswe kindof end up having to:03:54
lifelessmake a new branch03:55
lifelessfixup03:55
lifelesssubmit that as an mp03:55
lifelessself approve as 'fixup for xxx'03:55
lifelessqueue03:55
igclifeless: so having an integration branch remains a part of the workflow puzzle03:56
lifelessigc: when releases happen, or things sit for a while, yes.03:56
=== mnepton is now known as mneptok
* igc lunch04:13
lifelessspiv: btw your branch is pretty certain to be erroring, its just blowing up in the exception handler handler04:14
lifelessspiv: I think its fixed [reporting] now - this run should do better04:14
mkanatmwhudson: Hey hey. Any chance of getting the logs that I wanted?04:25
mwhudsonmkanat: do you have the times to hand?04:26
mkanatmwhudson: They're in the attachment, I could go find them.04:28
mwhudsoni guess i can too04:28
mwhudsonyay i think the times in the attachment are in NZST04:34
lifelessrot12 is fun ? :)04:35
mwhudsonah, actually not04:38
luke-jrhmm, one-liner patch to svn-bzr likely to get in as a bugfix? :p04:40
luke-jrlp:~luke-jr/bzr-svn/bzr-svn-longest-branch-path04:42
lifelessluke-jr: submit that via launchpad ;)04:42
luke-jrany way to go back and add parent revids to revisions?04:45
luke-jrI can add revprops on the svn end if needed, I think04:45
lifelesshttp://bouillon.math.usu.ru/articles/ctre.pdf04:50
lifeless^- rev ctrl geek alert04:50
lifelessluke-jr: in general, no.04:50
luke-jr:/04:50
lifelessyou could rebase/rewrite04:50
=== napster is now known as Guest51203
mwhudsonmkanat: i commented on the bug report04:51
mkanatmwhudson: Thanks.04:51
mwhudsonmkanat: i hope it's useful04:52
=== Guest51203 is now known as napster
luke-jrlifeless: I don't want to rebase or write anything04:57
luke-jrjust add missing metadata04:57
lifelessluke-jr: so bzr revisions are immutable04:57
luke-jrlifeless: why?05:18
luke-jrI'm going to have to change all the file-ids sometime too05:18
lifelesswhy?05:19
=== Garen_ is now known as Garen
pooliespiv, thanks for the tribunal mp06:06
pooliehow did it work aside from that?06:06
luke-jrlifeless: to maintain compatibility with existing branches if possible06:13
lifelessluke-jr: but existing branches will have the current file ids06:14
lifelessluke-jr: so I don't follow06:15
luke-jrlifeless: the existing branches are all based on a bzr-svn screwup06:18
luke-jrI am trying to recreate our Bazaar HEADs properly06:18
lifelessah06:19
luke-jrso we can actually merge between stable and trunk06:19
luke-jrand useful things like that06:19
luke-jrright now, the Bazaar HEADs start revision 1 at the import to Subversion06:20
luke-jrrather than at the original import into CVS06:20
luke-jralso, side note: I will need to ensure I can repeat this again later, since Bazaar STILL can't mirror Subversion losslessly at the moment :/06:21
luke-jrso a third import will be needed when Bazaar *can* losslessly contain the history06:21
spivpoolie: it's pretty slow when fed a full test run from bzr06:22
spivpoolie: I haven't got to the point of profiling06:22
spivpoolie: I've got some other changes in https://code.edge.launchpad.net/~spiv/tribunal/experimental that I'm less certain about, but made it a little nicer for me06:24
poolieyeah it does seem a bit slow06:24
poolieor like it gets stuck06:24
spivpoolie: io_add_watch seems to basically be a wrapper around poll(2) on an fd, and so feeding it a file doesn't really work well because they always report as ready for reading06:24
pooliefor me it works to give it a plain file but not a pipe atm06:25
spivpoolie: So I ripped that out (although it might be more appropriate for reading from a pipe?), and also used add_idle or something instead of timeout_add(1, ...)06:25
pooliefolding together "neither success nor failure" probably makes sense06:26
spivpoolie: and borrowed some progress code from subunit2gtk to give more info in the statusbar06:26
pooliei see06:26
pooliethat looks nice06:26
spivOh, and changed it to filter xfails with skips06:26
poolieright that's what i meant about folding them together06:27
spivAnd added a separate filter for unknowns (which in my use were just flickering on/off as tests loaded)06:27
pooliemm06:27
spivAlthough I don't think that's a great change.06:27
pooliethat actually needs to be handled a different way i think06:27
spivBut it did prove I knew how the ui.glade file worked :)06:27
pooliei mean if we're really getting unknown test results that's one thing06:28
* luke-jr mutters.06:28
pooliebut the case of a test just being in progress is different06:28
spivIt's really "incomplete" in this case, rather than "unknown"06:28
spivRight.06:28
poolieyou know there is a gui for glade? :)06:28
spivI do :)06:28
pooliei guess i'd be surprised but happy if the input code can be as simple as you have it06:28
spivBut it seemed quicker & easier to do this change via XML hacking, and I think I was right :)06:28
spivI'm not sure that the input code as I have it will cope well with a pipe that hasn't got the full stream ready to read yet.06:29
spivOne effect of removing the timeout_add calls is that Ctrl-C on the console now works as expected.06:31
lifelesspoolie: in case it wasn't clear, its safe to merge: approve in email/the web ui06:50
lifelesspoolie: pqm looks for merge: queue, not merge: approve06:50
pooliethat's what i understood now, but i think this is not clear to everybody06:50
poolieor whether that's going to start happening in the future06:51
lifelesspoolie: I'm going to update the merge docs once the glitches are gone06:51
lifelesspoolie: for now I want to keep email as the 'official' way to submit stuff06:51
poolieok06:51
pooliethat makes sense06:51
lifelesspoolie: so https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/2053706:56
lifelesspoolie: looking at it, I made it in progress because vila had decided to hand the writing of the tests back to INADA; I was following suit but setting the metadata06:58
vilahi all !07:23
fullermdEek!07:23
* fullermd hides.07:23
pooliehi vila07:25
poolielifeless, vila, so basically i think if someone has half a patch and doesn't seem to be getting the tests (or cleanups or whatever) finished07:29
pooliewe should actively help them07:29
poolieif necessary by writing the tests07:29
lifelessI think we should only do that after discussing with them unless we particularly want the patch07:30
vilapoolie: sure, I will look at it today (and to brian's append_revisions_only one)07:30
lifelesspoolie: particularly as you seem to mean this to apply to non-staff contributions [or something, I'm unclear what the heuristic you use is]07:31
vilalifeless: you seem to be patch piloting quite well so far, do you intend to make it official ? :)07:33
lifelessvila: I'm not patch piloting; if I was I'd be implementing stuff as needed; thats part of the pp definition atm07:33
=== vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.1 is out
vilawas worth a try :)07:34
lifelessvila: I'd be happy to if I wasn't moving house this weekend07:35
vilalifeless: thanks for the cleanup anyway !07:36
vilalifeless: tada ! Happy moving !07:36
lifelessparthm: we could use tempfile.mkstemp to make .bzr.log perhaps07:36
igchi vila!07:36
vilalifeless: I would have help if I wasn't that far :0)07:37
poolielifeless: if somebody's done some work on a patch, and it has value, and we think they won't finish it off themselves, we should finish it07:37
poolieyou can get an idea from someone's history of whether they can/will finish it07:38
vilapoolie: fully apply to brian's one, I'm a bit less comfortable with naoki's one but I think it's still a step in the right direction07:38
pooliefully apply?07:38
lifelesspoolie: I kindof agree, but I think your dials are overly sensitive, or something.07:39
vilapoolie: your comment " it has value"07:39
parthmlifeless: i thought of that earlier. rename is guaranteed to work on posix but not on windows (IIRC it errors on windows) so the update from martin_gz seemed good to me.07:39
vilafully applies ?07:39
pooliei see what you mean07:39
lifelessparthm: oh, right, we can't specify the full name. Ignore my suggestion :)07:39
poolieyes, we have a difference of opinion as to what's worth doing07:40
vilalifeless: Are there updates to your feed-pqm branch ? What is the consensus around it ?07:40
lifelesspoolie: I want to help folk over a hump they can't get over when any of a few conditions are true: they are likely to come back and do more; they are struggling and pointers won't be enough; we would be working on teh patch anyhow07:42
parthmlifeless: thanks for the review of bug #529930 mp. i have updated the testcase to use user_encoding.07:43
ubottuLaunchpad bug 529930 in bzr "bzr aliases don't support unicode characters" [Medium,In progress] https://launchpad.net/bugs/52993007:43
* parthm is new to unicode but dislikes unicode errors07:44
pooliejoin the club07:45
lifelessthat was incredibly bad reception - or transmission, can't tell07:48
lifelessI had 3 bars07:48
pooliesrsly07:48
lifelessyes, except more like07:49
lifelessssy07:49
lifelesspoolie: I'm thinking of either: changing the behaviour of pull --remember when there is a locations.conf, to remove configuration from locations.conf if it would override the --remember, or to have branch.conf win for local branches07:54
lifelessditto push --remember07:54
vilalifeless, poolie : Where are we with https://code.edge.launchpad.net/~lifeless/hydrazine/cron/+merge/23213 ?07:55
pooliesounds good07:55
lifelessvila: you can use it to submit things to pqm07:55
vilalifeless: I now I can, I'd like to know if I *should* :-)07:55
poolieheh, the last commit on the cron branch is "remove cron mode?"07:55
vilas/now/know/07:55
lifelessvila: sure; its merging robustly, but it has issues showing errors07:56
lifelessvila: debugging is a long winded thing (need a LP instance to talk to yada yada), so its high latency, even though its not high-staff-time07:56
poolieissues meaning it can't show them at all? :)07:56
lifelessvila: once the quirks are gone, I'm thinking to put the changes into bzrlib.plugins.launchpad07:56
lifelessvila: and have hydrazine call into that on a per-branch basis07:57
vilaIs it the 44M mail spiv was referring to ?07:57
lifelesspoolie: some of the time :(07:57
lifelessvila: no07:57
vilalifeless: that would be lovely for my use case :)07:57
lifelessvila: thats subunit07:57
poolievila: it gives you something like "IndexError: None"07:57
lifelesspoolie: thats on success ;)07:58
lifelesspoolie: but is, I think, fixed.07:58
poolieif that's success i'd hate to see failure :)07:58
poolie:)07:58
lifelesspoolie: indeed. Failure was spmdo tail pqm.log07:58
vilalifeless: I had failures last week and never got any mail, we tried to diagnose it with Chex, but never concluded, in the end I fixed the problem and sucessfully merged07:58
lifelesswhich is very suboptimal07:58
lifelessvila: that would be the 44M email07:58
vilalifeless: do you which server is blocking that ?07:59
lifelessvila: thats fixed, but the fix isn't robust yet; have just had spm rollout a pqm to gather the output and let us analyze for the reason of teh failure07:59
parthmdoes it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #56460507:59
ubottuLaunchpad bug 564605 in bzr "bzr should ignore java class files by default" [Undecided,New] https://launchpad.net/bugs/56460507:59
vilalifeless: ok cool07:59
lifelesspoolie: yes, --cron became obsolete with pqm.queue.lp07:59
poolielifeless: so atm i think i should merge that branch but give you a choice of two commands08:00
poolie'queue by email' and 'queue in launchpad'08:00
pooliesince you do in fact have these two options now08:00
spmyou should have a third : "queue by sheer awesomeness"08:00
lifelesspoolie: ok, I can reinstate a separate command, but I'm not really game to try and eliminate all the cruft08:01
lifelesspoolie: by which I mean there will be duplicate code08:01
vilalifeless: mark it as deprecated :-P08:01
vilalifeless: and spam the users about the alternative08:01
pooliei'll try08:02
lifelessvila: no, thats not reasonable when we're still supporting email submission08:02
poolietwo commands in one program seems better than two branches08:02
lifelesspoolie: I know what I changed, I'm happy to do it08:02
lifelesspoolie: it would be nice to have hydrazine look at the conflicts list too08:02
lifelesswhat I need is the self user id from launchpadlib08:08
parthmpoolie: does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #56460508:10
ubottuLaunchpad bug 564605 in bzr "bzr should ignore java class files by default" [Undecided,New] https://launchpad.net/bugs/56460508:10
poolielifeless: so in short, in case we don't catch up08:13
pooliei do want you to adjust that knob upwards08:13
lifelesspoolie: hydrazine 'e' command added and pushed to the cron branch.08:13
poolieok thanks08:14
lifelesspoolie: I want to discuss that with you; I'm pretty sure we will not be doing as best we can for the project by doing that08:14
pooliehappy to discuss it but please also just do it for now08:15
vilalifeless: lifeless missing ':' line 18208:16
lifelessvila: bah, thanks08:17
pooliegreat, thanks08:17
lifelessvila: pushed08:18
vilalifeless: pulled08:20
lifelessjelmer: what should format.open(name='xxx') raise on a non-supporting colocated-things format ?08:55
speakmanmorning folks09:17
james_wlifeless: how did this bzr-builddeb change work???09:18
james_wI even think we've discussed this change before09:19
lifelessjames_w: does it not work for you ?09:42
lifelessjames_w: oh right, global scope commands. bah09:43
lifelessclearly I have '' in my path inappropriately09:44
jelmerlifeless: NoColocatedBranchSupport09:57
=== radoe_ is now known as radoe
lifelessjelmer: and name!=None is thr right condition ?10:26
lifelesswell, is not10:27
MvGlifeless: wrt bug #560030, what exactly are you proposing? Should we get all major distros to provide a bzr-bash-completion package before we drop stuff from the bzr main tree?10:29
ubottuLaunchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/56003010:29
lifelessMvG: debian and redhat certainly10:30
jelmerlifeless: yeah10:30
lifelessMvG: not necessarily wait for them to be done, but have the maintainer ack and be prepared10:30
MvGlifeless: Do you want to contact them? If I do, it might seem like I'd simply trying to maneuver for a larger audience for my plugin. If you say that's the future, they are more likely to take it serious.10:31
lifelessMvG: the bug and review feedback are pretty clear10:32
lifelessMvG: I think they will take you seriously ;)10:32
MvGOK, got a point there.10:32
lifelessI'd just say something like10:35
lifeless'hi, this is a heads up, we're about to merge a branch deleting xxx, there are replacement, better, scripts at yyyy, we wanted to make sure that this is known now, rather than at the last minute'10:36
MvGDo you have contact addresses for maintainers of the RedHat package?10:36
lifelesshe hangs out here :P10:36
lifelessdon't remember the name offhand10:36
james_wabadger1999 will at least know who it is if it is no longer him10:37
spivOoh, I think my shiny new news_merge logic is working.  The prototype doesn't blow up in manual testing at least...10:39
MvGjelmer: How about Debian? Should I write to pkg-bazaar-maint@lists.alioth, or is it enough that you read the above?10:39
lifelessspiv: cool10:39
lifelessspiv: hey10:39
lifelessspiv: I have a further Commands cleanup issue10:39
spivTime to write some proper automated tests for it, but right now it's dinner time :)10:39
lifelessspiv: subclasses  - super().10:39
lifelessspiv: food for thought.10:39
spivSuper-duper.10:39
speakmanI've got yet another workflow question comming. Hold on. :-)10:40
spivlifeless: I guess the current answer is "don't upcall"?10:40
lifelessspiv: Not entirely sausagefestfactory10:40
MvGBy the way, I've got another merge request for which I'd like comments here: https://code.launchpad.net/~gagern/bzr/bug387117/+merge/23750 about ListOption(..., param_name=...) which is currently broken.10:41
spivAnyway, food time.10:41
spivlifeless: btw, the better-news-merge branch, while still rather messy, can read a template file from a configurable location (rather than using the hard-coded list).10:42
lifelessspiv: sounds nice10:42
spivlifeless: as well as having a more capable parser10:42
speakmanMe and my coworker are about to make a facelift to one of our application. The current stable version is in trunk, and we suppose all facelift work should be done in a separate branch of trunk. But how do we work together on this branch in best practice? Beside our own workstations we also have a bzr smart server set up on a dedicated server machine. Any recommendation how to proceed?10:43
lifelessspeakman: just do it ?10:44
MvGspeakman: I'd say create a branch off trunk on the smart server, and let contributors decide whether they want to check it out or branch from it.10:44
jelmerMvG: Sorry, I think I missed the context :-)10:46
speakmanWe're only two working on this, but we will be working with overlapping things i guess.10:46
MvGspeakman: In terms of http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html you two either use the centralized approach (with or without local commits) or the decentralized with shared mainline. In both cases, mainline would be the facelift branch, not trunk.10:47
MvGjelmer: Bug #560030 plans dropping bash completion scripts, and lifeless wants distros made aware of this upcoming change up front.10:47
ubottuLaunchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/56003010:47
speakmanSo the preffered workflow in this scenarios is the centralized (SVN) type?10:48
jelmerlifeless: still around?10:48
lifelessvery10:49
MvGspeakman: Depends on your personal preference. In particular whether you want to resolve possible merge conflicts and share your changes at almost every commit, or whether you'd rather keep your stuff to yourself until you decide it's ready for sharing.10:50
MvGjelmer: So I'd still like to know whether the people maintaining bzr for debian are now sufficiently aware of the fact that bash completions are about to go, and that there is my bzr-bash-completion plugin as suggested and superior solution. If not, I'd write a mail about it.10:52
speakmanI don't actually have any preference, and every time I just choose one workflow, I always hit issues one way or another :)10:52
speakmanThat's why I'm asking the pro's before starting the facelift project :)10:53
lifelessspeakman: don't don't choose one workflow - use many :)10:53
lifelessspeakman: seriously, different strokes for different issues10:53
lifelessspeakman: clearly you want a facelift branch; make one, work on it.10:53
MvGspeakman: In that case I assume that your edits overlap in a way that is bound to cause extra work unless you strictly serialize them. Might be an indication of bad code design or bad task assignments.10:54
speakmanEarlier I think I've seen something where each user had their own branches on the smart server, like /srv/bzr/ourproject/mybranch and /srv/bzr/ourproject/coworkerbranch10:54
lifelessIf you are getting lots of big conflicts, merge more often with each other (the ultimate example of that is per-commti)10:54
speakmanlifeless: but we will be two working on the same "feature" :-/10:54
lifelessspeakman: so ? I don't see why you feel that make a difference10:54
MvGlifeless: "don't choose one workflow" might apply to bzr usage in general, but for working on one specific task I'd prefer not to change workflow too often... :-P10:54
speakmanMvG: You're hitting the spot; it's *very* bad code design, but the facelife project is the last resort for that codebase though :)10:55
speakmanlifeless: but if we're supposed to merge often - then the checkout/centralized workflow is pretty much it?10:56
MvGspeakman: If edits overlap so often, then as lifeless points out, you might want to merge for almost every commit, in which case the centralized svn-stype approach would indeed be best.10:56
lifelessspeakman: the more often you merge, the smaller conflicts are; dial-up the number of merges you do to match the work you're doing.10:56
speakmanI think the centralized workflow will be it then. Thanks :-)10:57
speakmanAnd then - how "often" should one commit? Are there any rules of thumb?10:57
lifelessspeakman: often10:58
mathrickspeakman: merging doesn't necessarily imply a centralised workflow10:58
mathrickyou can just cross-merge from each other's branch10:58
lifelessspeakman: ifyou're using centralised to avoid conflicts, you want to be committing a lot, otherwise you're no different than just merging every now and then10:59
mathrickspeakman: how many people will *not* be working on the facelift?10:59
speakmanlifeless: ok, thanks alot!10:59
speakmanmathrick: not working? :-)10:59
lifelessby a lot, I mean multiple times an hour10:59
mathrickyeah, how many developers are there who don't participate in the facelift?10:59
speakmanmathrick: we're just two programmers, and both will be working on the facelift :)10:59
mathrickoh10:59
mathrickspeakman: then you just do bzr branch stable facelift; bzr branch facelift facelift-speakman; bzr branch facelift facelift-coworker11:00
jelmerMvG, lifeless: I'm not exactly sure what's expected of me here11:01
mathrickand then facelift becomes your integration branch, with stable still being there in case you need it11:01
jelmerMvG, lifeless: Does removing this completion script cause shell completion to break for existing users?11:01
lifelessjelmer: a decision about what to do in debian when bzr drops its included completion scripts; ideally package up the rplacement.11:01
lifelessjelmer: it depends, how do we deploy them at the moment?11:01
lifelesslike, do users have it on by default, or do they source it, or copy it, or ...11:02
mathricklifeless: wouldn't making their personal branches bound to the main facelift branch be best for merging here? This way they'll always be sure to have a single codebase11:02
MvGbzr deploys them in contrib, debian places them in /etc/bash_completion.d/ , from there on I'm less than sure.11:02
MvGBut I'd assume there is some kind of framework for selecting thise completion scripts you want to enable on a per-user basis.11:03
lifelessmathrick: doesn't really make any difference; regular merges are regular merges11:03
mathrickyeah, I mean just for code hygiene and not forgetting to push11:03
lifelessmathrick: whatever works for the individuals involved11:03
lifelessmathrick: I don't think there is a gold standard 'best' here11:03
mathricklifeless: the decision about completions is usually global, you either enable it and then get all installed completions, or not and then you don't.11:03
lifelessjelmer: ^11:03
mathricklifeless: fair enough11:04
MvGIn that case I wonder why Debian installs BOTH bash completion scripts, bzr and bzr.simple... :-/11:04
lifelessjelmer: ideally we'd have replacement packaged and recommended: on by the bzr package11:04
MvGI don't have a Debian/Ubuntu at my fingertips just now, otherwise I'd investigate this more thoroughly.11:04
mathrickspeakman: anyway, you can make your personal branches checkouts, this way every commit you do locally will be instantly mirrored on the integration branch. And ideally, you want to sit next to each other and inform clearly what you are about to commit and what you'll be working on next11:05
speakmanmathrick: that's pretty much how it works practically. We're sitting next to each other, and due to the (lack of) code design we really need to work tight on this.11:11
mathrickright11:12
speakmanfinal conclusion; bzr branch bzr://smartserver/ourproject/trunk bzr://smartserver/ourproject/facelift, and then "bzr checkout bzr://smartserver/ourproject/facelift" on each of our workstations.11:12
speakmanThen go buy intercom :)11:13
jelmerMvG, lifeless: ok, thanks11:13
mathrickspeakman: yup; you might also consider tagging the starting point of the facelift11:13
jelmerMvG, lifeless: I'll file a RFP when I do the next upload11:13
MvGjelmer: Please expand RFP.11:13
lifelessrequest for package11:14
MvGThx.11:14
MvGDebian done, Ubuntu by inheritance hopefully done as well. RedHat maintainer still unknown. I haven't even found a redHat package database online, only one for Fedora. https://admin.fedoraproject.org/pkgdb/acls/name/bzr lists 3 users with commit privileges, one of them the owner.11:15
jelmerMvG: abadger1999 is (one of?) the Fedora maintainer11:16
mathrickMvG: I thought RH doesn't have a non-fedora package list anymore, given how RH is basically fedora + support + very long release cycle11:16
lifelessMvG: redhat is fedora as far as we're concerned11:19
MvGSo we'll wait for abadger1999 to react.11:21
MvGIn the meantime I'll go for lunch.11:22
speakmanmathrick: hm... I don't get it - why tagging when working in a branch..?11:29
mathrickspeakman: to have an easy reference to the starting point11:30
mathrickspeakman: otherwise you'll have to remember the first revision you branched from11:30
speakmanoh yes, you're absolutely right! thanks!11:31
lifelessmathrick: I don't get the tag either11:32
lifelessmathrick: whats it for ?11:32
speakmanHm looking at the commit history my coworker seems to have commited with wrong email address (login@machine). Is there any way to change that retrospectively?11:32
mathricklifeless: seeing the full extent of what you've done for example11:32
mathrickspeakman: no11:32
speakmanok :(11:32
mathrickother than fast-replay11:32
mathrickerr, fast-import11:33
mathrickbut it'll be a different repository then11:33
lifelessor rewrite (in principle)11:33
speakmanok, it's okey as is :)11:33
speakmanabout tagging; when working explicitly in the facelift branch you can easily see which commit was the first in the new feature branch. I guess?11:34
mathricklifeless: in general I find having a clear idea of where I started useful. And if the trunk moves in the meantime (because of a critical bugfix say), you won't have any easy way to say "where I started"11:34
lifelessmathrick: well, bzr knows11:34
mathrickspeakman: depends, how do you define "first in the feature branch"? Revisions don't belong to any branch, branches contain them11:34
mathricklifeless: howso?11:34
lifelessmathrick: revisions in your branch not in trunk11:34
mathrickunless you backport / merge11:35
speakmanAbout trunk changing - is "merging" considered default about "rebase" in bzr?11:35
lifelessmathrick: the topologically oldest of them, has a single parent, the starting point.11:35
speakmanabout/above11:35
mathricklifeless: and how do you say that?11:35
lifelessmathrick: bzr missing --mine-only etc, I'm not sure there is a query for that rev at the moment11:36
mathricklifeless: but that's potentially a moving target. Tags by definition aren't11:39
mathrickand they're easy to spell as revspecs too11:40
lifelessmathrick: sure, if you're happy great. I've just never ever needed it ;P11:40
speakmanWe all learn something each day :)11:41
speakmanEach time I need to reach my smart server I have to type "bzr://servername.local/project/trunk" -- is there an easy way to make a alias, like "ss:project/trunk" (like launchpad "lp:") ?11:56
lifelessspeakman: instal bzr-bookmarks11:58
lifelessvila: ping11:59
lifelessvila: do you remember, does WeaveMerger write BASE files now ?11:59
lifelessit does12:08
vilalifeless: sorry, had lunch12:30
lifelessvila: tsk, eating now. What next? Breathing?12:30
vilaor sleeping :)12:30
speakmanI currently did a merge from trunk into a feature branch. Now "bzr missing" tells me that the merge commit is missing in trunk. How will this show in history when the feature branch is finally merged into trunk?12:47
lifelessspeakman: have a look at the bzr trunk log12:49
speakmanlifeless: bzr trunk log..? the log of my trunk branch?13:09
bialixno, lp:bzr13:10
=== mrevell is now known as mrevellunch
millunhi13:14
milluni am a noob. working on a project (colocated branch) and would like to create a copy of this project so i could have 2 repos and be working on both13:15
speakmanlifeless: changeset 5153?13:16
milluni guess i could 'cp -R stuff' and then delete .bzr dir?13:18
speakmanwhy not branch and work on both?13:19
speakmanwhat more specifically are you trying to do?13:19
MvG1abadger1999: ping?13:19
millunspeakman: just be able to separate 2 projects and then work on both without mixing anything13:20
=== MvG1 is now known as MvG
MvGmillun: Just because branches were made from a common ancestor doesn't mean you'll HAVE to mix anything in the future.13:21
MvGmillun: And doing a branch now will preserve full history for both new projects, which should be a good thing to have13:21
millunok13:22
=== salgado-afk is now known as salgado
=== gnomefreak76 is now known as gnomefreak
=== mrevellunch is now known as mrevell
=== gnomefreak76 is now known as gnomefreak
abadger1999MvG: pong14:36
MvGabadger1999: you're maintaining the bzr package for Fedora, right?14:45
abadger1999abadger1999 == toshio in the Fedora pkgdb btw14:46
abadger1999MvG: I am comainaining it -- hno handles the day-to-day these days.14:46
abadger1999MvG: What's up?14:46
MvGabadger1999: In response to bug #560030 we're gonna drop the bash completion script, and suggest the bzr-bash-completion plugin as replacement.14:46
ubottuLaunchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/56003014:46
MvGSo we'd like distros to provide a package for it, be ready for the time when the scripts disappear from the bzr source releases.14:47
abadger1999MvG: Okay.  No chance of getting that plugin into core?14:47
MvGNot up to me, I'm only developing the plugin and offering the off fix for inclusion.14:47
MvGI'd be happy to see it in core, but lifeless didn't exactly jump to that offer.14:48
MvGAnd I can think of a million places where bzr would be required but bash completion not, so it might make sense to keep things distinct.14:48
abadger1999Hmm... bzr-bash-completion doesn't need bash completion installed, though?  It just generates the script that would be used by bash completion?14:49
MvGabadger1999: Correct. but it does ship a lazy.sh that can be installed as bash completion script and generates the full completion function upon first invocation.14:50
MvGSo that's file is what I'd suggest as a replacement, in cases where the plugin is installed.14:50
abadger1999Ah.  Okay, we'd drop that into place without making a hard requirement on bash-completion so it wouldn't matter if it was in bzr core.14:52
MvGabadger1999: I was a bit imprecise: the script assumes that the plugin is installed. It is intended for cases where the plugin is installed, but doesn't check if that actually is the case, but will fail noisily if it isn't.14:53
abadger1999MvG: <nod>  I'm talking -- if it was in Core, bzr still wouldn't need to suck in a bash completion package.14:54
abadger1999MvG: A few years ago poolie wasa interested in getting more plugins into core.14:55
MvGAgreed. So suggestion would be for bzr to suggest but not require bzr-bash-completion, and for bzr-bash-completion to suggest but not require bash-completion, and for bzr-bash-completion to install lazy.sh under a file name that was provided by bzr so far.14:55
abadger1999I ask this because there's only two of us packagers who are interested in bzr in Fedora... so additional packages kinda suck.14:56
abadger1999Which is why we don't have bisect, pipelines, or a lot of other bzr plugins packaged :-(14:56
MvGabadger1999: I understand, but my package shouldn't be too complicated: simple distutils from proper release tarball, and the lazy.sh file installed via custom install command copied from the bzr package spec.14:57
MvGAnd if there is anything I can do to make life easier for you downstream, let me know.14:57
MvGabadger1999: BTW, is hno occasionally here on irc as well, and if so, using what nick?14:59
abadger1999MvG: <nod>  Yeah... but maintaining packages is the problem... The front end load is fairly simple, when free time > 0: create new package from template, submit for review, have bzr comaintainer review, commit to package SCM, build and release.14:59
abadger1999MvG: The maintainance is the problem: When New upstream release || new Fedora release || bug reported: stop other work to work on issue (minimal for updating package, much more for fixing bugs); submit patches upstream, build new packages, push to all relevant Fedora branches.15:01
abadger1999MvG: his nick is hno, so he's easy to spot15:01
abadger1999MvG: He's almost always on #fedora-devel if you need him.15:02
MvGabadger1999: bzr-bash-completion should in no scenario be mission-critical, so nothing should be urgent. For the "bug reported" case, I'd suggest reporting upstream first, waiting some amount of time for me to come up with a fix and release it (the benefit of independent package is that I can have short and independent release cycles), then simply bump the fedora package.15:03
abadger1999MvG: Hehe -- true.  I like to be an active packager that helps out, rather than just a packager that demands fixes, though :-)15:03
MvGI guess I'll include a comment in the bug report, stating that you are now aware of the situation, but not entirely happy with it, and see if that makes core devs reconsider the core inclusion.15:04
MvGabadger1999: And I'd welcome you to be, but I'd rather have a packager demanding fixes than no packager at all due to lack of time. :-)15:04
abadger1999yeah -- Just mention that getting more plugins into core will make bzr look better when people are comparing the features that bzr vs $OTHER_SCM has within a distro.15:05
abadger1999MvG: :-)  Thanks!15:05
abadger1999I'll try to get hno to package/maintain this as I use zsh rather than bash (or maybe I'll take a look at your plugin and try adding a zsh output as well).15:06
MvGabadger1999: zsh does ship a completion script for bzr. It's prety outdated as well, but not as much as the one in the bzr source tree.15:07
MvGI've had a look at it as well, and wondered whether augmenting my script might be feasible.15:07
abadger1999<nod>15:07
abadger1999The thing I miss most in the zsh script is no support for plugins -- a lot of commands from bzrtools don't have completions.15:08
MvGFor lists of options it should be easy. For registry option values it should be feasible. For help strings it might at times become difficult. For arbitrary argument type completions there isn't enough information in the bzr classes to provide completions the way the hardcoded zsh script currently does.15:08
MvGIn other words: all versions of bash completion currently complete option names and registry values, but leave everything else to standard file name completion. All versions of zsh completion try to be clever and complete much more, like revision numbers, versioned and unversioned files, and so on. The latter is diffiocult to do generically.15:09
MvGAnd expensive in terms of performance as well.15:10
abadger1999Okay.  That summary gives me a head start on what work would need doing, at least.15:10
MvGSo if I were using zsh, I'd drop most of the zsh cleverness, and instead have it do what the bash script does, except for perhaps a few more help messages. But I'd need a regular zsh user to work with me on that.15:11
abadger1999<nod>15:12
abadger1999MvG: Could you link to your plugin in the bug?  it'll make it easier for people to tell what they need to be packaging.15:13
MvGWill do. For you it's here: https://launchpad.net/bzr-bash-completion and http://pypi.python.org/pypi/bzr-bash-completion15:15
abadger1999Thanks!15:16
MvGabadger1999: In case you really wanna tweak the bzr-bash-completion plugin towards zsh, have a look at http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/Unix/Command/_bzr or your local installed copy of it. The format doesn't look too complicated.15:37
MvGabadger1999: I've just commented on bug #560030; maybe you and/or hno want to subscribe, so you stay in the loop.15:37
ubottuLaunchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/56003015:37
abadger1999MvG: Yeah -- hno hasn't responded to me yet -- waiting to see if he'll take the package.15:38
milluncan i set "/home/millun/work/bzr" as my default push directory for more projects?15:54
=== bac` is now known as BradCrittenden
millunoops. i obviously can't :)16:00
=== BradCrittenden is now known as bac
MvGmillun: It should be possible, though I'm not sure it would make a lot of sense, as you'd have diverging branches preventing pushes for all projects except one.16:04
vilaI need help from a losa16:41
vilalifeless: A funny one for you: pqm is looping...16:42
vilalifeless: I submitted with feed-pqm, got a failure (reported on lp, not by mail) but nothing to give me a clue about why16:43
vilalifeless: so I submitted by mail16:43
vilalifeless: no it appears that pqm is still failing but it keeps trying to process the same submission...16:43
Chexvila: hi there, what do you need help with?16:44
vilaChex: as explained above, it seems pqm is looping on the same submission and doesn't give me *any* hint about what is failing16:44
vilaChex: AIUI lifeless and spm have been working on pqm since last week, so be aware that things may have changed there16:45
Chexvila: ok, let me check the logs for you16:46
vilaChex: the urgency here is to kill this submission so that the other ones can be processed16:46
Chexvila: ah ok, thats easy, hang on16:46
=== salgado is now known as salgado-lunch
Chexvila: ok, I have cleared out your submission, and cleared the pqm-bzr procs, should restart now on a new submission17:02
vilaChex: any hint of *what* was failing ?17:03
vilaChex: http://pqm.bazaar-vcs.org/ says 50317:04
Chexvila: sorry, try now17:05
vilaChex: ok, it now says 0 scripts17:06
vilaChex: any hint about why my submission failed ?17:06
vilaChex: I briefly saw a summary saying 1 error but no details17:07
Chexvila: right,  that is what I am seeing in the pqm.log file, too.. let me pastebin for you17:08
Chexvila: https://pastebin.canonical.com/30964/17:10
vilaChex: and nothing after that ? There is not even an error mentioned there :-/17:11
ChexI know.. nothing17:11
Chexvila: I think we may want to try to turn on more logging, if possible to see whats going on17:11
Chexvila: but I am not sure how to go about doing that17:12
vilaChex: Isn't there a log file for each submission ?17:12
vilaChex: at least the other submissions are being processed right now...17:13
Chexvila: yes there are indiv. log files, but they dont seem to get created until the job is finished..17:14
Chexvila: and for some reason, your patches aren't.17:14
vilaChex: AIUI, my submission has been run 3 times, you killed the last one17:14
vilaChex: ooooh, if it's only mine, then .. fine, I'll  talk with pqm :)17:15
Chexvila: talk with.. pqm? you guys have a special friendship?17:15
vilaChex: joke aside, the first submission was from the lp queue while the second (and the others) came from a direct mail17:16
Chexvila: aha, ok, I see.17:16
lfaraoneCan I get a remote branch's history without branching it?17:16
vilacome to think of it, I wonder if the mail one didn't trigger *3* (and not 2) runs17:16
vilalfaraone: branching *is* getting the remote history17:17
lfaraonevila: sorry, I just want the log.17:17
vilaChex: doesn't the log mention several submissions for this patch ?17:17
vilalfaraone: bzr log should accept remote urls17:18
vilalfaraone: 'bzr log lp:bzr' works17:18
lfaraonevila: okay. that will work without using SSH, right?17:19
vilalfaraone: it depends on what protocol you're using to access the branch... http ?17:20
MvG1lp uses ssh if it knows a login name, http otherwise.17:20
lfaraonelooks like it works with http too, I just su'd to nobody, and it worked.17:21
lfaraonelooks like it works with http too, I just su'd to nobody, and it worked.17:23
=== MvG1 is now known as MvG
lfaraoneIf I have a lp: URI, how should I pass that to bzrlibb.branch.Branch in the way it expects it? ("a = bzrlib.branch.Branch('lp:ubuntu/lucid/gnome-do')" gives me an error()17:32
vilalfaraone: use Branch.open_containing()17:35
vilalfaraone: as a general rule: looking into bzrlib.builtins.py will give you many hints17:35
donriHow can I add to the last commit?17:39
=== beuno is now known as beuno-lunch
maxbdonri: By 'bzr uncommit'ing and then committing your modified commit17:43
donriuncommit wont touch my non-committed changes since the last commit?17:43
maxbcorrect17:45
donriThanks.17:46
=== salgado-lunch is now known as salgado
BoingoHello all.  I have done a bit of searching, but not a lot of finding.  I am having some very slow commits over FTP.  Even a single character change in a single file, with a fresh commit to a remote repo over FTP can take 30+ minutes.  Is there something I am doing wrong?18:18
jamBoingo: using FTP18:21
jamespecially if your server doesn't support APPE (append to an existing file)18:21
BoingoMy only real option is FTP in this case.18:22
BoingoI think.18:22
Boingogodaddy hosting.18:22
BoingoWhy does editing even a simple small file take that long though?18:25
dashBoingo: one reason is that bzr uses compressed files to store version history, so updating via ftp can involve replacing an entire file18:25
dashBoingo: which can be a good bit bigger than the one you edited18:26
BoingoOh.18:26
BoingoThat makes sense.18:26
BoingoIs there anything I can do then?18:26
dashthe easy thing to do is use some other host for your bzr repo, like launchpad or sourceforge or something :)18:27
BoingoI need something that is private.18:27
BoingoCan lp do that?18:27
BoingoWould sftp or ssh speed it up?18:27
jpdsBoingo: Yes, Launchpad offers commerical subscriptions.18:27
jpdsBoingo: https://launchpad.net/+tour/join-launchpad#commercial - not sure if it's what you want though.18:29
BoingoI am reasonably happy with what we have, minus the abysmal speed for commits.18:29
BoingoWill sftp or ssh speed it up?18:32
dashsftp might, ssh definitely will, if bzr is installed on the remote server18:32
BoingoIt would not be.18:33
BoingoWell, at least not in the current context.18:33
dashwell if you can ssh there you can install it18:33
=== khmarbaise_ is now known as khmarbaise
=== blueyed_ is now known as blueyed
=== beuno-lunch is now known as beuno
=== CardinalFang_ is now known as CardinalFang
lifelessvila: to stop it looping, you just unqueue it from launchpad22:13
lifelessvila: go to the merge proposal, click on the edit icon beside 'queued' and change to 'approved'22:14
=== salgado is now known as salgado-afk
=== iBasic_ is now known as iBasic

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