* maxb crosses fingers, declares a possible solution to dh_python2 backports, and waits for the build farm to get on with it00:07
* spiv wonders what's up with https://bugs.launchpad.net/bzr/+bug/74566400:10
ubot5Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed]00:10
jelmermaxb: what's your solution?00:16
maxbjelmer: pretty much what I was outlining this morning00:21
maxbshim packages that lead to dh_pysupport/central being invoked00:21
jelmermaxb: ah, right00:22
jelmerI hadn't expected you to actually've implemented it since then :)00:22
maxbhmm, the web UI no longer permits copying packages to jaunty00:23
jelmerdoes anybody still care about jaunty ? :)00:24
maxbI think it might be time to officially drop ~bzr/ppa support00:26
jelmermaxb: in favor of up to date distro packages and the daily builds?00:32
jelmermaxb: I think that's sensible, though perhaps we should check with the people currently using it00:32
maxboh, I meant drop ~bzr/ppa support for Jaunty00:36
maxberr, what?! Really weird build failure from bzr-daily/maverick: https://launchpadlibrarian.net/67748861/buildlog_ubuntu-maverick-i386.bzr_2.4~bzr5744~ppa3921.3921~maverick1_FAILEDTOBUILD.txt.gz00:38
maxbgcc errors compiling pyrex .c files00:39
* maxb has a look at loggerhead recipe conflict00:46
spivmaxb: r5731 changed that code00:51
spivmaxb: but the change seems to work on my maverick system00:52
spivmaxb: although, huh00:53
spivmaxb: I don't see the *_pyx.c files being regenerated in that buildlog00:54
spivmaxb: shouldn't pyrex be run at some point?00:55
maxbbut, puzzling why it should work on natty00:58
spivmaxb: http://bazaar.launchpad.net/~debian-bazaar/bzr/unstable-2.4/files/head:/bzrlib/ appears to have stale .c files00:58
maxbjelmer: Do you know why dulwich-daily is set to exclude karmic?00:59
maxbspiv: The packaging branches usually pick up .c files from the previously imported tarball. It's normally OK. I guess we've found a situation where it is not00:59
spivmaxb: it seems weird to me that we don't run pyrex at build time01:00
spivmaxb: python-pyrex is even listed as a build-depends01:00
maxbThe bzr/daily PPA is doing quite a thorough job of saturating the PPA/i386 buildds right now :-)01:18
poolie__maxb, wow01:30
poolie__where is that shown?01:30
=== poolie__ is now known as poolie
spivpoolie: https://launchpad.net/builders I guess01:32
bignosewhere is a good channel to ask about the ‘testtools’ package?04:12
lifelesshere, #subunit #testtools04:13
lifelesserm, the last is fiction04:13
lifelessalso #python-testing or whatever its called04:13
bignoselifeless: okay, meet you there? :-)04:16
lifelessbignose: ping me from whatever channel you choose ;)04:17
pooliehi jam06:07
danielshlast week I started storing my dotfiles in bzr06:09
danielshnow I'd like one dotfile to different between my desktop/laptop06:09
danielsh(different font size in the terminal emulator)06:10
danielshhow can I do that?06:10
danielshif I change the config file on the laptop, then I can't seem to ignore that change on the desktop, any pull/merge requires a commit which then the laptop wants to pull,06:10
danielshlather, rinse, repeat06:11
* danielsh hopes his explanation is clear enough...06:12
jammorning poolie06:13
pooliehi danielsh06:15
danielshpoolie: morning06:16
pooliethere's a few options06:16
poolieone would be to make that file a symlink into a machine-specific directorie06:16
pooliehi jam06:16
* danielsh (oh, forgot to say, I checked with the latest stable version before I /joined here.)06:16
danielshunfortunately the file is a plain .ini file, there's no easy way to do 'source `hostname`/foo.conf' or similar06:19
danielshas to storing all the different versions in the history everywhere,06:20
danielshthat doesn't seem nice, I'm not sure where to start,06:20
danielshit offloads the problem of diverging changes to me, rather than to the tool,06:21
danielshI'm not sure that it scales well (think N machines),06:21
poolie how would you like it to work?06:22
danielshon laptop: edit file. commit.  on desktop: merge that commit while making an edit that the laptop won't try to pull.06:23
danielshend result: laptop has font size 11, desktop has font size 12,06:23
spivI think "have one master template, and then N local variations, and when the master updates help merge those updates into the local variations" is something bzr doesn't really cater to directly, but you could build on top of bzr.06:23
danielshand I can keep bzr push/pull between them06:24
danielsh(and yes I may run into conflicts sometimes)06:24
spivIn bzr terms these would all be separate branches06:24
poolieso you want to make a "don't merge this" commit?06:24
poolieyes, you could have a separate branch for stuff that is meant to be common06:24
danielshpoolie: I'm not sure what is the bzr term for what I want.06:24
spivAnd when you update the master you'd then merge that into the local branches, but typically not merge the other way.06:24
spivI know there are tools like etckeepr that can use bzr, but I don't know if they cater to this specific use case or not06:25
danielshso in that case I'd have on each box two branches:06:25
danielsh* the master branch (shared, identical everywhere)06:25
danielsh* a local branch (only pulls from master, never pushes)06:25
spivYou wouldn't have to have a copy of master on each box, but it may be convenient to do so.06:26
pooliemerges from master06:26
spivBut basically, yes.06:26
danielshOkay, I see.06:26
danielshI'd have to propagate changes from ~/.foorc to ~/master.bzr/foorc manually, though06:27
pooliejam i wonder if i can just do without <BLANKLINE> or give an option to do without it06:27
pooliei agree it is a bit ugly06:27
danielsh(or cherry-pick them..)06:27
danielshspiv, poolie: thanks for discussion, I've learnt something :-)06:28
jampoolie: yeah, something. I'm back to family time, now that everyone is waking up. Be back in about 2 hrs06:29
* danielsh will check out etckeeper, too.06:29
pooliesure :)06:29
pooliei was a bit surprised to see you06:29
lifelessjam: I'm sorry if you feel unhappy about my backing out the lp-runs-loggerhead tests06:35
lifelessjam: I hope I've explained well enough on the bug, but if not I'm happy to discuss further here06:36
pooliejam, it turns out it is happy without the blankline markers06:45
vilahi all !07:26
jamhi vila09:00
jamlifeless: I'd be happy to discuss it with you. I can see some of your points, but I have some of my own09:00
jamright now, I have to finish moving out of the apartment, though09:00
jamSo maybe late tonight (early your morning, I think)09:01
vilahey jam !09:01
spivjam: please do take up that push regression, that'd be great09:01
vilajam: good luck with your move, don't break too many things ;)09:01
vilajam: and enjoy your new place !09:01
* spiv → afk09:02
jamthanks vila09:04
jamhave a good evening spiv09:04
jamvila: I would enjoy it more if we had furniture09:04
jamCustoms has delayed it for 1 month so far, and are currently saying "you don't have proof that you didn't live in EU for 12 months"09:05
jamso they want to charge us as though we are bringing it to sell, or something.09:05
vilajam: naaah, give a try to a more zen-like attitude, just sell your stuff !09:05
jamand by default, online statements only go back 12 months from today09:05
jamwhich doesn't go back to Jan, 201009:05
jamvila: right. Of course, sleeping on hardwood floors is the real Zen challenge09:05
vilajam: welcome to Europe :D09:06
lifelessjam: ugh09:06
vila. o O (Keeping the balance between sarcasm and true compassion is hard)09:06
pooliehiya vila, jam09:06
vilapoolie: heya !09:06
lifelessjam: sure, can chat whever09:06
jamWe could get a hotel room, but extended hotel room stays and 3-year olds don't go very well together.09:07
jamwe bought some air mattresses, but the people on the box must be midgets. I clearly overhang the end by about 30cm, and I'm not all that tall.09:08
jamhey poolie09:08
vilawelcome to Eur... err already made that one, but there is a long tradition of jokes around here about US making bigger "things", looks like mattresses fit the category :D09:09
jamvila: yeah. "Everything is bigger in Texas". I was actually a bit disappointed that things in Dallas weren't bigger. They just seemed US-sized. :)09:11
pooliethe cars were pretty big09:12
poolieoh and the guns09:12
poolieand the food09:12
jampoolie: but not particularly bigger than elsewhere in the US09:12
jamwe have the statement *in the US* that "Everything is bigger in Texas"09:12
jamI guess the Hats are usually bigger09:12
poolieyeah, and Queensland is bigger than Texas :)09:12
poolievila, i may be just missing the point, but the config stuff seems eminently split-able09:15
vilapoolie: except for the deployment part...09:15
vilamay be *I'm* missing the point :)09:15
pooliefor instance we can add a better api without changing anything much else09:15
vilathe sore point is BranchConfig and its relationship with remote configs09:16
vilaso may be I should just start with GlobalConfig...09:16
pooliewhy is it sore?09:18
vilapoolie: have a look at set_option (name, value, section=None) and _set_option(self, value, name default) and _set_option(self, section_name, option_name, value)09:20
vilaand the various classes involved starting from BranchConfig and including TreeConfig, TransportConfig BzrDirConfig09:21
vilaso while each of the proposed classes are easy to implement in isolation (that was the goal), using them requires to handle the transition path and while I know that it will be ok at the feature level, I fear some evil details when migrating from the existing files09:24
vilaone option is to use *new* file names, but this means updating the docs and our user brains (the later being far harder ;)09:24
vilabut neither being cheap09:25
vilaso I feel more comfortable landing the new features well tested but not used and *then* focus on the migration09:25
vilamy last failed attempt has been to address bug #491196 :-/09:26
ubot5Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/49119609:26
vilathe proposed design makes it trivial, but only after deploying the new design...09:27
pooliei do kind of feel like it should be possible to have an api that stacks just the dynamic config on what we have now09:28
pooliebut i guess the proof is in actually trying to do it09:28
vilayeah, I share*d* the feeling :-/09:29
vilaHave a look at ConfigStack in iconfig.py in lp:udd: I needed a ugly hack to get usable ConfigStack09:34
vilasame goes for expand_options, basically if I fear that going incremental will end up with a code full of hacks from the start when the goal is instead to get (hopefully) a clean implementation that will be easier to enhance09:36
vilas/if I fear/I fear/09:36
vila            if hasattr(c, 'get_user_option') and not hasattr(c, 'get'):09:37
vila                c.get = types.MethodType(compatible_get, c, c.__class__)09:37
pooliei saw that09:37
vilais the ugly hack I'm referring to: it injects a bound method09:37
pooliewhat's the main motivation for expansions?09:38
vilamay be it's a useful technique to handle compatibility if we can find clearer helpers to use it, but...09:38
vilapush_location = lp:~{launchpad_unsername}/{project}/{nick}09:39
vilabzr.xxx.action = {script} with {script} being 'ask' for interactive use and True/False otherwise09:40
vilamore generally sharing more default values09:40
vilaby allowing references09:40
poolieand where does that get set?09:41
poolieit just seems strange to add it before doing the other refactorings09:41
vilaexpand you mean ? I'm already using 'bzr push `bzr config mypush`/`bzr nick`' quite often09:42
poolieyeah, i meant internal expansion09:42
pooliei'm not complaining09:42
poolieit may sound like i am :)09:42
vilawell, more than quite often in fact, almost always09:42
pooliei just cared more about -Ofoo09:42
vilano no09:42
vilahehe, mee too :D09:43
vilaoh, and expand is good for command templates or log templates as seen recently on the ml09:43
vilathe main limitation actually is the single config scope09:44
vilawhich can't be addressed without ConfigStack09:44
vilaI'm pretty sure we also have as-yet un-triggered bugs when remote configs are involved09:45
vilalike: what if I define a bazaar.conf and a locations.conf on a server09:45
vilado we have the same behavior between smart and dumb servers ?09:46
vilaI suspect nobody tried to fiddle with that so far ;)09:46
vilaand I'm in no hurry to open the can of worms ;)09:47
vilabut abentley raised 'control.conf' used by launchpad and.... that's another can of worms...09:48
vilanow, if you look at https://bugs.launchpad.net/bzr/+bugs?field.tag=config , we have 26 bugs there, most of them will be easy to address... if we had this new design09:51
poolie ok09:51
vilabut trying to address them *now* and finding the minimal path to get one them fixed... I failed09:52
vilaso I finally concluded that this was too hard and that I should try a different approach, hence the proposal09:53
vilawell, the 26 above does not include some more general ideas we've been talking about like getting rid of many constants in bzrlib, trying to handle bzr-colo in branch.conf instead of .bzr/branches, etc09:54
vilaon the other hand, I don't want to end up with a massive >2000 proposal either09:55
vilaso I tried to test-bed things in the package importer... only to realize that other issues were coming in the way there09:56
pooliei think this will fix things09:56
pooliefix many bugs09:56
vilaoh, and I forgot about resolve default actions too for udd09:56
pooliei am just desirous of smallers proposals along the way09:56
vilathe plan is to propose the various classes, well tested, one by one09:57
vilapreparing the deployment as best as I can doing that09:57
vilaanother sore point has been the infamously long review of doxxx regarding mergetools (which was also a motivating factor for expand)09:58
vilaas was abentley appendir proposal09:59
vila(and still is since he's still blocked because we don't provide a solution for his need)09:59
vilaI'm reasonably confident that the proposed design *can* support additions for all known needs (so far) even if things aren't clear enough yet10:00
vilaThe Store abstraction has enough constraints defined to propose tests reusable for daughter implementations, section selection should address various context definitions *without* forcing too much constraints (regexps, globs, path (relative or absolute)), Option definitions should provide an optional basis for online help10:02
vilaI don't think I invented too many new concepts there and I tried to think hard about trivial basis implementations10:04
vilanow I need some code to verify that the design is sound or I may as well keep thinking about it for years10:04
vilaoh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis)10:05
jamvila: Windows works just fine with env vars "set foo=bar"10:06
jamhowever, it is a bit hard to get to from Guis10:06
vilajam: tell that to my mom...10:06
vilaI mean, for most users the workflow just never involves being able to 'set foo=bar'10:07
vilathey want something in a file10:07
vilaeven 'bzr -Ofoo-bar xxx ...' won't work for them10:07
pooliewe should just define options that have an environment variable as a way to set them, but also a regular name10:08
poolieanyhow, that's enough for me for today10:08
pooliejam, thanks for the reviews10:08
pooliei might add tests for some of them tomorrow10:08
pooliei may be being a bit lazy10:08
vilapoolie: right, but what's the point of having both 'foo=bar bzr ...' *and* 'bzr -Ofoo=bar ...' ?10:08
pooliethings like <https://code.launchpad.net/~mbp/bzr/733136-lock_url/+merge/55706> where in other languages a compiler error would pick it up, i'm not sure how much it's worth adding a test10:09
poolievila, if we could handle everything through the second case i think the first would be unnecessary in almost all cases10:09
vilapoolie: +1, not worth the trouble to add a test10:09
poolieit does have one advantage which is that it inherits10:09
vilaoh, good point10:09
poolieie you can set the plugin path in your .bash_env10:09
vilamay be -O should propagate to subprocesses ;D10:10
vilaplugin_path is trickier (as are some other options)10:10
jamvila: other than being able to do "export BZR_FOO=bar" and have it valid for the lifetime of your session10:11
pooliei mean you can set it in the shell and it will pass through emacs down to bzr10:11
pooliefor instance10:11
vilaI'm contemplating a [__init__] section in bazaar.conf :D10:11
jam-Ofoo=bar doesn't persist10:11
vilajam: sure, but that still doesn't work for windows newbies10:12
vilai.e. the ones that don't know how to setup env vars for their session10:12
jamvila: set works just fine, and if they are newbies they are (a) prob not on the command line, (b) not going to know about -Ofoo=bar either.10:12
vilajam: indeed, but they still want to set some default values10:12
poolielet's try to get there10:12
pooliei'll try to comment on your api examples tomorrow10:13
jamvila: I would hesitate to expect that there is someone who doesn't know how to set their env vars who also *does* know how to set -Ofoo.10:13
jam*my* point is just that "no env vars" isn't somewhere we actually want to be10:13
jamwe might want fewer10:13
jambut I don't think that value is 010:13
jampoolie: have a good evening10:13
pooliewe want a way to have per-process settings that don't use the environment10:13
vilajam: I'm not saying we should *not* support them, I'm saying that if one feature is available thru env vars *only*, then some users won't be able to use it10:14
pooliethat's the main reason people would add them today10:14
poolieagree with that10:14
jam(11:05:33 AM) vila: oh, and an hidden assumption is also that we should get rid of all env vars (if only because they can't be easily used on windows or for guis)10:14
jamvila: which is what I was rebutting. It sounds like we agree10:14
vilajam: yeah, re-read it with ... yeah10:14
vilabadly phrased10:14
vilaerr, is 'phrased' english ? formulated ? expressed ?10:15
jamvila: phrased or expressed10:15
jam"we don't want to require users to use env vars"10:15
jamwould be a better way10:16
jamvila: stuff like default plugin path, etc, certainly belongs in a config. Though being able to override it easily gets tricky10:16
vilajam, poolie : Thanks for the constructive feedback anyway, I don't want to sound to defensive on this proposal. Just trying to make sure the ideas behind it aren't lost because I didn't explain them well enough10:17
vilajam: yeah, I'm beginning to accept that even the plugin path and the config files should somehow be specified into a config file. But for bootstrap reasons, I'm inclined to restrict their use to bazaar.conf only (so far)10:18
vilajam: and until then, I won't delete BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT :D10:18
vilabut these aren't the most pressing bugs either10:19
lifelessvila: FWIW, wearing my user hat, I'd be much more interested in package importer stuff, or colocated branches, or build form branch, than config changes10:20
vilalifeless: funnily enough, all of the mentioned areas will benefit from that by making changes easier to implement10:21
lifelessvila: I've learnt to be wary of budgeting work on that basis; you may be entirely right, or it may be less than break even10:29
vilalifeless: and you're damn right there10:29
lifelessvila: The only thing I took away that would be easier would be a command line tool to set options, which didn't seem particularly relevant to $aforementioned10:30
vilalifeless: bzr config foo=bar ?10:30
vilalifeless: try bzr/2.310:30
vilawith a bunch of limitations so far10:31
lifelesswhat I mean10:31
lifelessis I don't see the connection from that to e.g. the importer10:31
vilabug #719888 and the hurdles to test locally10:31
ubot5Launchpad bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,Fix released] https://launchpad.net/bugs/71988810:31
vilaor a better way to specify options for imports on a package, series, pocket basis10:32
vilaor the ability to specify post-merge resolve actions on a dir/file basis in a persistent way10:33
lifelessthese still don't seem connected10:33
lifelessto config foo=bar10:34
lifelessI'm not saying they aren't nice10:34
lifelessI just don't understand the relevance10:34
lifelessfor instance10:34
lifelessLP has configuurable log dirs10:34
lifelessand doesn't have a tool to set config variables10:34
vilawe aim at making all options be specified either in a config file or from the command line10:35
vilaconfig files providing various ways to set default values for various contexts10:35
lifelessyou're describing a design10:35
lifelesswhat problem are you solving10:36
vilaso either you set the option in a config file or you specify it from the command line10:36
lifelessand how is that problem relevant to the importer10:36
vilathe losa want a way to decide where the log files are stored, the importer should respect that10:36
lifeless[meta: I don't mean to criticise :- but I don't understand the links, and I suspect other observers also won't.]10:36
vilathe log dir was a hard-coded constant10:37
lifelessvila: could they not just edit ~/.bazaar/bazaar.conf10:37
vilalifeless: only if the code even try to look there10:37
vilawhich it wasn't10:37
lifelessok, so perhaps if I now draw a comparison:10:38
lifelessA: implement a system to do arbitrary config option setting10:38
vilaand still don't because there is no way to keep bazaar.conf in the same branch as the importer scripts (so far)10:38
jelmermaxb: those bzr-git test failures are due to an old dulwich10:38
lifelessB: Fix the packaging importer code to ask global config for theoption10:38
lifelessvila: ~/.bazaar/bazaar.conf doesn't need to be in said branch, does it ?10:38
maxbjelmer: Ah, hi. I wanted to ask you what you thought about migrating from cdbs to dh7 for dulwich and subvertpy10:39
vilalifeless: if you keep a default value in the scripts, no10:39
maxbjelmer: The motivation is that the current Build-Depends on cdbs is on a version only available in natty, and I REALLY do not want to backport cdbs10:39
lifelessvila: I don't understand why a default value would be needed10:39
jelmermaxb: Hmm, I thought I already did that10:40
lifelessas in, config = GlobalConfig(); logfir = config.get_user_config('pkg importer log dir')10:40
vilalifeless: to keep track of what options need to be defined10:40
lifelessvila: you've just switched problem statements I think.10:41
lifelessvila: you said 'the losa want a way to decide where the log files are stored, the importer should respect that'10:41
maxbjelmer: Not for those two, apparently (dh_python2 yes, dh7 no)10:42
jelmermaxb: ah, just not pushed10:42
maxbjelmer: I love it when fixes are that easy :-)10:42
vilalifeless: well, we start with a python file where a bunch of dirs are built from a common base and we want to get to the point where the production site can override them and the testers can also override them10:43
vilalifeless: going there incrementally without a perfect knowledge of the scripts (which I haven't) requires some care10:43
lifelessvila: let me ask a different way10:44
lifelesshow many constants did you want to change in the package importer10:44
lifelessand/or how many constants did you see?10:44
vilalifeless: so I didn't want to get rid of the relationships between these various dirs being entirely defined outside of the scripts10:44
vilalifeless: roughly 20 say10:44
lifeless20 *different unrelated log dirs* ?10:45
vilathere was one log dir that also contained the files served with apache10:46
vilawe now have to different base dirs for that10:46
lifelessso thats 210:47
lifelesshow does that connect to 'config foo=bar'10:47
vilalifeless: http://paste.ubuntu.com/587731/10:47
vilapart of icommon.py imported by all scripts10:47
vilaoh wait, let me add some lines there: http://paste.ubuntu.com/587733/10:48
vilaso, yes, the dirs are created unconditionally10:48
vilabut the log dir itself now contain two more dirs 'driver' and 'packages' which are create more lazily10:49
lifelessok, but again10:49
lifelesshow does this connect to a command line tool to write config files to disk10:49
lifelessit seems to me that:10:50
lifeless - using global config10:50
vilaerr, modify a config file you mean ?10:50
lifeless - reading 2 or 3 values from there10:50
lifeless - and then putting them in as the relevant base dirs while you split things apart10:50
vilaright, that's the final plan10:50
lifelesswould meet the losa constraint10:50
vilaan incremental step has been to introduce pkgimporter.conf: http://paste.ubuntu.com/587734/10:51
lifelessI feel like I'm not connecting on this10:51
lifelessit must be frustrating you10:51
vilano, no, go ahead, I appreciate10:52
lifelessso I'll put it directly10:52
lifelessit seems like a 2-3 hour direct and simple change10:52
lifelessbecame a large scale software engineering problem10:52
vilaI can understand that10:53
lifelessthats *perception*10:53
vilabut I didn't spent as much time in it as it may seem10:53
vilaI've been *thinking* about that for a long time, but I don't account my in-bed-thinking as work time ;)10:53
vilanow, for the package importer, the main issue is that I can't *test* properly such changes which means I need to be cautious when I introduce them10:54
lifelessvila: the thing that is confusing10:54
lifelessis that you say 'bzr config foo=bar' is connected to improving the importer10:55
lifelessand I don't understand that at all10:55
vilaoh, sorry, no I was replying to 'can we set that from the command line'10:56
vilafor the package importer the issue is to keep such config options under control while allowing losas/testers to do their work without modifying scripts by nahd10:57
lifelessvila: ok; so why is that more complex than 'read the options from bazaar.conf'10:57
vilaand using bazaar.conf wasn't adequate10:57
vilabecause I didn't want the definition and the (unclear yet) dependencies to disappear from the branch10:58
vilaso maybe it's overcautious rather than overengineering ;) But maybe both...10:59
lifelessvila: so rather than leave the old value commented #was foo=bar\nfoo=config.get_user_option('pkg_importer_foo')11:00
vilalifeless: keep in mind that I *learned* about which files were served over http while addressing the log issue...11:00
lifelessyou built a bunch of infrastructure11:00
vilawhich one ?11:00
lifelessvila: well, the bzr config foo=bar that you mentioned11:00
lifelessevelyette: hi11:00
evelyettedoes bazaar have a plugin which scans for file modifications in certain folder and updates the tree automatically11:01
evelyettekindda like inotify in linux11:01
vilalifeless: oh no, that was already built, I didn't built it for the importer11:01
lifelessevelyette: I think someone built something to do that (using inotify)11:02
evelyettelifeless, I would very much like to use that: can you tell me more, maybe provide a link ?11:03
vilalifeless: what I built for the importer is only iconfig.py (~80 lines) so locations.conf can be used to override pkgimporter.conf (which itself just build on top of config.IniBasedConfig11:03
lifelessevelyette: sorry no, google can tell you all I can11:03
lifelessevelyette: Its just a vague memory11:03
lifelessvila: so to backtrack; you say that the package importer will be easier to write with the config overhaul; whats the connection ?11:05
vilaand then tester just have to override pkgimport.base_dir11:07
vilaand since I keep bumping into, damn why can't I just fu.. do it this way (in so many different places, the importer being the last one)... I thought the threshold was reached11:08
lifelessI can see it being useful11:10
evelyettebtw: I just heard of bazaar and had to check it out. I've been using svn/git for now: so how is bazaar different from the svn/git, is it better?11:10
vilalifeless: so, yeah, I try to keep it light and I'd like it to be easy and fast to implement, but I'm tired of working around the lack of it ;D11:12
lifelessvila: fwiw I would just have kept the relative defn's relative and defined two variables in configs11:13
vilaevelyette: that's a big vague to be properly answered, especially if you want an answer applying to both svn and git which are rather different ;D11:13
evelyetteok just git then11:13
evelyettesvn is crap :)11:13
lifelessvila: by preference I mean - I find overly parameterisable code gets harder to maintain and permits config bugs11:13
vilalifeless: yeah, and use makedirs instead of mkdir, but there is still the risk to create dirs in the wrong place etc11:13
vilalifeless: indeed !11:14
vilalifeless: which means the true and perfect solution is to re-design the importer scripts which I don't want to do ;)11:14
vilalifeless: or at least not upfront, I'd prefer to go incrementally there even if I can't find a way to do the same for the new config design (or at least not as far as landing simple feature that requires a bit of infrastructure)11:15
lifelessvila: well, you can treat the current structure as being only configurable to the extent you add it11:15
lifelessvila: avoiding both a redesign and overly-configurable code issues11:15
lifelessevelyette: git and bzr are similar in lots of ways11:16
vilalifeless: yup, I'm learning the scripts design as I go11:16
lifelessevelyette: key differences are: bzr tracks file identity, git tracks tree snapshots only; git has an index which is great for code review and confusing for everything else11:16
vilalifeless: (and also collect relevant files like the crontab, the apache config and so on, too)11:16
lifelessevelyette: bzr is written in C and python, git in C and perl11:17
evelyetteI've also installed bzg-gtk and qbzr  but there's no gui anywhere ?11:17
evelyetteI'm on gentoo btw11:17
vilaand try 'bzr qlog' in a branch11:18
evelyettethere is no such command11:18
evelyetteI don't have a branch11:18
vilabzr-explorer is a plugin, 'qlog' is a command from qbzr11:18
evelyettedoes that plugin have tray as well ?11:19
evelyettebecause that is what I really miss11:19
evelyetteand the inotify stuff, so the client automatically updates its stuff11:19
vilawell, qbzr provides a GUI for many operations on a branch, so you can't see it in action without a branch11:19
evelyetteyes I got that :)11:19
vilabzr-explorer mostly relies on qbzr11:19
vila'have tray' ?11:20
vilayou mean an icon .. ok11:20
vilawell, you alsmot always need to interact with some file on disk so a tray icon is not a high priority ;)11:20
evelyetteah :)11:21
vilawhen you say update, you mean update a working tree from a branch ?11:21
evelyetteI mean commit the working directory to master bzr server11:22
evelyetteand the other way around11:22
vilaI don't know about many cases where you want to commit automatically (automatic messages being meaningless most of the time)11:24
evelyetteyes meaningless ... I don't need them11:25
vilabut nothing (nor nobody) can stop you to call 'bzr commit -m "auto"' from an inotify hook11:25
evelyetteI just want to sync11:25
evelyetteyes that's what I want ... is it already written or will I have to write it by myself11:25
vilayou probably need to write it, I don't know of an existing plugin to do that (bug google may know better ;)11:26
evelyettedoes bazaar have any API I can use instead of "bzr commit -m "test""11:26
vilakeep in mind though that rsync or other backup tools may be more appropriate if you don't care about the history of the changes11:27
evelyetteyes I do care11:27
evelyettejust don't care about the -m option :)11:27
vilabzrlib provides a python API but while this gives greater control this won't be as short as 'bzr commit -m "test"'11:28
evelyettehow are the plugins written, in bzrlib ?11:28
vilaon top of bzrlib, in python11:28
evelyetteso if I write that module in python, can I submit it ... and you'll keep it in the next versions of bazarr11:29
evelyettebecause I would only like to write it once and have it available with bazaar installation, not by copying the .py files around11:29
vilayou can write a plugin without it being part of bzr core11:29
evelyetteyes that's what I mean11:29
evelyetteare you in charge of keeping that in plugins dir or whatever11:30
vilathe core carries only a few plugins, most of them are packaged independently for various platforms11:30
vilas/most of them/most of the existing plugins/11:30
evelyetteis there any good tutorial on bzrlib11:31
vilalike qbzr, bzr-gtk, bzr-explorer11:31
vilayup, certainly a good starting point, have a look as existing plugins too, there are a lot of good practices that aren't documented in the url above11:32
jamspiv: From what I can tell, bug #745664 is because your "fetch all tags" code also fetches all tagged revisions into a stacked branch.12:46
ubot5Launchpad bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed] https://launchpad.net/bugs/74566412:46
maxbI think it's likely to be what has caused my bzr-svn fetching of kdesupport to start taking aaaaages iterating tags too12:54
jelmermaxb: are you fetching into a stacked branch?13:13
maxbjelmer: no13:25
jelmermaxb: I'm not sure I understand how it's related in that case13:26
maxbabnormal amount of excessive work relating to tags, only occurring in bzr.dev, appearing at about the same time13:26
jelmermaxb: bzr-svn was recently changed to fetch all revisions referenced by tags, as was bzr.dev13:27
spivjam: ah :/13:51
spivjam: and I think that bzr-svn import has some particularly bad tags13:51
jelmerspiv: which bzr-svn import ?13:52
spivjelmer: twisted13:52
spivActually, not so sure about the tag13:52
jelmerah, I see13:52
spivI know the set of branches was a bit confused (because they had some directories of branches inside branches/)13:53
spivAt a glance there's only one tag that looks obviously wrong, 'releases', again I think that's a subdirectory of more tags in the actual svn repo13:54
spivBut then, my local repo doesn't have the revision, neither I guess does the lp repo, so what are all the get_parent_maps about?13:56
spivtags that are ghosts on both sides should cause one get_parent_map with no result and then give up.13:57
spivSo I wonder which revisions it is checking?13:58
spivAnd it's also weird that it doesn't happen on the initial push13:58
spivAnd the set of tags that aren't ghosts are the same in lp:twisted and locally14:00
spiv(just 3 of them)14:00
spivjam: so, I'm still confused! :)14:01
vilajelmer: try 'bzr qblame bzrlib/config.py' around like 285 (which is how I discover the issue)14:27
vilajelmer: something seems wrong in the way you've done this merge :-/14:27
vilajelmer: and yes, *I* am the one who forgot the pdb.set_trace() (though I doubt it can be triggered now)14:28
jelmervila: that looks weird indeed, I don't recall ever touching that much in bzrlib.config :-/14:28
vilajelmer: you didn't, look at the file graph (click the line 285)14:28
vilait's as if you cherry picked my changes14:29
vilajelmer: no big deal, I'm just curious about how you end up with this and where the bug is14:30
vilabzr ? wrong workflow ? In any case if *you* got tricked, many other can probably be to14:31
jelmervila: I never meant to take credit for your changes..14:31
vilauneless you did something really exotic14:31
jelmerI'm also not sure what's going wrong there14:31
* jelmer tries to remember what sort of workflow he was using there14:31
vilahehe, no worries, anybody looking at the history will understand that anyway, just one step away14:32
vilaand my point is not about who to blame for a bug there ;)14:32
jelmervila: I merged another branch which hadn't landed on mainline yet, perhaps that is related?14:33
vilabut your commit message says: 'merge bzr.dev' oooh, you mean, you merged my branch while it was processed by pqm ?14:34
vilabut then ... annotate is bogus ?14:34
vilaurgh, ha, wrong tool, qblame shows a weird graph if the nodes are opened, qlog should know better14:35
vilajelmer: right, so revno 5676.1.4 revid:jelmer@samba.org-20110224160947-e7kqclxnjif28v5q says it merged bzr.dev but there is a single parent there14:38
vilajelmer: cherry-pick ?14:38
vilaovezealous cherry-pick ? ;D14:39
jelmervila: I never cherrypick from bzr.dev, perhaps there was some other magic I did that went wrong14:39
vilajelmer: anyway, I've fixed the pdb14:39
jelmerdon't you mean pb ? :-P14:40
vilajelmer: don't lose time on it, I was just curious14:40
jelmerI'm curious about it now, too :)14:40
vilalol, no, pdb as in 'import pdb; pdb.set_trace()'14:40
vilaleft-over while debugging a nasty bug14:40
jelmerAnyway, let's keep an eye on similar things in case it wasn't me screwing up a merge.14:41
vilayeah, but a merge with a single parent... my bet is on some switch or something, a forgotten commit, a revert --forget-merge (doubtly)14:42
vilahttp://babune.ladeuil.net:24842/job/selftest-osx-10.6/174/ and http://babune.ladeuil.net:24842/job/selftest-freebsd/14:43
vilajelmer: what did you do ? Something bsd-hostile ? While resetting lazy hooks ?14:43
vilajelmer: don't search, the root cause was a transient lp connectivity failure :D14:44
jelmervila: heh, ok14:44
vilabut I had a wtf moment when only freebsd and osx failed with the same 3 tests :D14:44
jelmervila: I guess that's what we get for connecting to lp from the testsuite >-)14:45
vilajelmer: indeed14:45
jelmerbtw, if anybody has a chance to have a look at https://code.launchpad.net/~jelmer/bzr/more-lazy-hooks/+merge/55523 that'd be great; it would mean I can land / propose for merging several other branches14:48
vilajelmer: seems pretty mechanical, will feel better if tests pass on all platforms (running)14:54
vilajelmer: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-hardy/84/testReport/junit/bzrlib.tests.test_branch/TestHooks/test_constructor/14:59
jamspiv: I'm still a bit confused myself. But it looks like the initial push pushes up something ~ correct. But then subsequent pushes see "you are missing basis inventories for these extra revisions you pushed"15:01
evelyettehow can I start qbzr module ?15:18
evelyettebtw: is these something in bazaar that enables me to have centralized overview on all of my bazaar's repositories ... I'll have more of them on the same computer (an overview over these would be great to have), but an overview over all of the repositories over all of my computers would be great15:30
evelyetteit can be tunneled in ssh or something secure15:31
evelyetteis that possible ?15:31
evelyetteor a better question: does such a tool exist15:31
vilaqlog accepts several branches as arguments, some of them can be remote15:33
evelyettewell I need more than just a log ...15:35
vilaI have no idea what you call an overview :D15:35
evelyettelet's say: for now I would only like to know where the gits are located15:36
evelyetteso I don't miss some repository when backing up15:36
vilagits ? Did you planned to ask the question in #git ? Anyway, if you need to find where you created branches, there is no such tool to find them for you (except for find(1)). Finding the branches you defined in a given repository is different, 'bzr branches' will tell you.15:39
evelyettesorry ... not gits15:40
vilahttp://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief briefly defines the most often used words in bazaar (it often helps people coming from different backgrounds so we all refer to the same objects)15:42
vilabut out of the blue, if you have no idea where your branches are (or need to check where they are), a '.bzr' directory is generally a good indication15:43
vilabut I've never heard about a tool to give an overview of all branches (launchpad.net kind of answer the need but it's more than a tool)15:44
vilawell, unless you count bzr-explorer which (AIUI) helps you keep track of your branches by defining bookmarks and even providing a view with all of them, but you still have to define them to start with15:45
maxb"All version control objects existing on this computer" does not feel like a useful categorization to me. Why do you care?15:45
maxbFor the backup scenario, that's not what you want - there's little point backing up local copies of open source software15:46
evelyetteit's not open source15:46
evelyetteI would like to have let's say 3 bzr repositories on my computer ...15:47
evelyettebut I have to keep track what are their locations15:47
vilarepositories or branches and/or working trees ?15:47
evelyetteI guess working trees15:48
vilawhy do you need to keep track of where they are ?15:48
evelyetteif someone else joins the group I have to provide them with a link like ssh://bazaar/repo in order to checkout15:49
evelyetteso I have to know the path on the remote system of where the bazaar working tree is15:50
evelyetteI just read that15:50
vilait's very rare to have working trees on servers15:50
vilaespecially when all people need to share are branches15:50
vilaand you can have a working tree (wt) on a client and the branch on the server15:51
evelyetteyes that's what I want15:52
viladepends on your workflow15:52
evelyettesorry for confusion15:52
evelyetteso I have to know the location of a branch on the server15:52
evelyettethat's what I want to keep track of15:52
vilahmmm, I'm still confused, I have hundreds of branches on my computers organized in several hierarchies and that's good enough to keep track of all of them, what are you searching for exactly ?15:54
evelyettehow do you keep them organized15:55
evelyettelet's say I have a repositories (branches - whatever) of a project A, B, C ... so they are totally different projects...15:55
vila~/src/<project> and under that 'trunk' for.. the upstream trunk branch, and them subdirectories named bugs, reviews, experimental, integration, releases, packaging and branches below that or even more subdirectories15:56
evelyetteand I create the branches on a remote server in locations /tmp/A, /tmp/B, /tmp/C, and then completely forget about hwo I've set them15:56
evelyetteso then after a year I would like to checkthem out (pull from them or whatever), but since I forgot the paths where I've set them, I cannot15:56
vilabzr log <url> ; bzr info <url>; will give you some hints, but a tool can't replace organization ;)15:57
evelyettethat's true15:58
evelyetteI just want to check that I'm not doing something stupid, and overcomplicating things15:58
evelyetteso the projects are fine the way I described them, I just have to remember the urls15:58
evelyettethe paths to them15:59
vilawell, use a well defined name space and make evolve with your needs, define one you can reuse with several projects15:59
evelyetteI think I'm just gonna create a new folder and have all the bazaars branches in it15:59
evelyettefor ALL of the projects15:59
vilahost:/<project>/<zero or several meaningful dir names>/branch_name16:00
vilahave a look at http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/16:01
vilaor even http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/distributed_intro.html16:03
evelyettecan you also tell me how can I start bazaar explorer16:08
vilabzr explorer16:08
evelyetteI tried, it gives me error16:09
vila'bzr help explorer'16:09
vilameh, file a bug against your distribution, something is borked there16:10
vilaI don't use bzr-explorer myself so I don't know exactly which versions are compatible with which, but clearly there is a problem there16:12
vilabzr-explorer uses qbzr which itself relies on Qt and there is a version mismatch here16:12
=== deryck is now known as deryck[lunch]
jelmer"time bzr ls" on a small bzr tree -> from 0.404 in 2.3 now down to 0.207 in bzr.dev16:39
jelmermainly due to plugins being able to register their stuff more efficiently (this is with 35 plugins loaded)16:40
vilaworth the tedious work !16:41
jelmer(for the pedantic, those numbers are in seconds)16:41
vilaelapsed times too then ;)16:41
jelmerthe other two remaining heavy imports that we should be able to avoid on normal runs are the xml modules and knit repositories16:46
vilajelmer: what is your timing with 'bzr ls --no-plugins' ?16:48
fullermd'knit' includes knitpack, I presume?16:48
jelmervila: 0.185s16:48
jelmerfullermd: yes, that's how it gets imported (the 2a repository class is based on the knitpack repository class)16:49
jelmervila: I get a similar number (0.003 or something like that more) for 2.316:50
vilajelmer: worth a small summary on the mailing list so plugin authors get an insight about what lazy loading is about (INHO)16:51
vilameh M16:51
fullermdpack-0.92 you mean?16:51
jelmerfullermd: pack-0.92 instead of which one?16:52
fullermdYou said '2a'16:52
jelmervila: good idea16:52
jelmerfullermd: Yes, I mean '2a' too :)16:52
fullermdSo, ANY repo format (well, excluding weave :p) requires loading the knit stuff?16:52
vilafor some value of stuff...16:53
jelmerfullermd: and for some value of requires16:53
vilaC & C !16:53
viladamn, never laugh while drinking, or rather drink and *then* read IRC16:54
* fullermd falls over, battered and bruised from the tag-teaming.16:54
jelmerfullermd: so, because of the way imports are structured at the moment any non-weave format ends up triggering the import of bzrlib.knit (and its dependencies)16:55
=== deryck[lunch] is now known as deryck
=== hunger_ is now known as hunger
jelmerlifeless, hi20:38
jelmerlifeless: did you see my last comment to lp:~jelmer/bzr-search/lazy-xml20:42
lifelessjust been busy20:43
lifelesswe've had a couple of very disrupted weeks in lp land20:43
jelmerlifeless: np, I'll ping again a bit later20:44
jelmerI'm not in a hurry :)20:44
jelmerlifeless, (also, kudos on the performance improvements... it's becoming a joy to use lp)20:46
rodrigobhello people in the IRC channel20:56
lifelessjelmer: cool; I can't take much credit - cast of thousands :)20:57
rodrigobthe channel seems very silent, is it here where I can ask weird questions ?20:57
lifelessjust ask:)20:59
rodrigobI am using bzr with cruisecontrol.rb for automated integration of a web application21:01
rodrigobI have discovered that cruisecontrol.rb has a bug21:01
rodrigobbecause it assumes that the bzr versions will only increase with each commit21:02
rodrigobbut when merging branches21:02
rodrigobthe version can increase or decrease21:02
rodrigobso the question is21:02
rodrigobis it there a way to make bzr always make the version number increase ?21:02
rodrigobor put in a different way21:02
lifelessthere is an option you can set in the branch's branch.conf21:02
lifelessits in bzr help configuration21:03
rodrigobbranch.conf ?21:03
jelmerlifeless: aren't you supposed to be the architect ? ;-)21:03
lifelessjelmer: yes, which means I get to point and guide and take no credit :)21:03
rodrigobwhich option should it be ?21:05
rodrigobappend_revisions_only ?21:05
rodrigobif I had revision 40021:07
rodrigoband after merge I am at revision 35021:07
rodrigobhow can I get to revision 401 ?21:07
rodrigob(without loosing modifications, obviously)21:08
lifelessrodrigob: cd or switch to the trunk, merge the source branch commit21:08
lifelessmerging into a branch never rewinds the revno21:09
lifelessits only when you push from another branch with different left-hand-path that that happens21:09
lifelessyes, append_revisions_only is the option21:09
rodrigobwhat is left-hand-path ?21:09
lifelessrodrigob: every commit has a list of parents - a merge has 2 (or more), regular commits have just one21:10
lifelessthe left hand path is the path through the parents of each commit, following the left hand side only21:10
rodrigobok I see21:11
rodrigobI do not get the21:12
rodrigob"rodrigob: cd or switch to the trunk, merge the source branch commit"21:12
rodrigobI am at the trunk21:12
rodrigobat revision 35021:12
rodrigoband before it was 40021:12
rodrigobwhen looking at21:13
rodrigob bzr log -l15 -n021:13
rodrigobI see multiple merges in the last versions21:13
rodrigobwhat can I do21:15
rodrigobto get to 40121:15
rodrigobinstead of 351 ?21:15
rodrigobI know my problem is weird21:17
lifelessits straight forward21:17
rodrigobbut I am kinda lost with this21:17
lifelessI need to run though - sorry!21:17
lifelessperhaps jelmer is still around and can help out21:17
* jelmer wakes up21:17
jelmerlifeless: thanks for not pointing the lp devs in the wrong direction >-)21:18
rodrigobttyl ?21:19
jelmertalk to you later21:19
* jelmer reads up on rodrigob's question21:19
jelmerrodrigob, hi21:41
jelmerrodrigob: you'd like to redo the merge so it will be r401 rather than r351?21:42
rodrigobhow could I do such re-merge ?21:48
vilaamazing, I never saw the guy asking the question bringing the one would will answer in his disconnection...22:09
vila. o O (Where are they gone ?)22:09
pooliehi all23:29
* maxb ponders hardy backport of debhelper23:47
spivHi all23:58

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