mgzOOPS-2062AZ5 too late at night...01:55
mgzFourth time lucky, I wonder if putting "lp:" on the start of the prerequisite branch upset anything...01:57
lifelessmgz: bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout01:58
mgz77 results being the relevent thing? :)01:58
lifelessno, there is one for +merge-proposal in there ;)01:59
mgzbug 629087 looks likely.02:00
ubot5Launchpad bug 629087 in Launchpad itself "Branch:+register-merge timeout submitting merge proposal" [Critical,Triaged] https://launchpad.net/bugs/62908702:00
lifelessyeah thats the one02:00
* mgz metoos02:00
=== ScottK2 is now known as ScottK
pooliehi mgz, scottk04:00
ScottKhello poolie.04:07
ScottKpoolie: It's gone midnight, so I'm about to go to bed, but what's up?04:07
pooliejust saying hi04:07
pooliethanks for the suggestion04:07
poolieabout out of date branches04:07
ScottKAh.  OK.04:07
ScottKHello back poolie.04:08
AuroraBorealishow do i tell what gets called when you pass commands to bzr? like, bzr add, checkout, merge, etc04:28
lifelessAuroraBorealis: do you mean what python functions run?04:29
AuroraBorealisi see the Command class and that you have to register04:29
AuroraBorealissaid commands but i dunno where that gets done o.o04:29
lifelessfor plugins during the plugins __init__04:29
lifelessfor core commands by being in builtins.py04:30
lifelessor whatever the file is called :)04:30
AuroraBorealisah, thank you =)04:32
=== Topic unset by poolie on #bzr
AuroraBorealisoh gee.05:29
=== poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: JAM
vilahi all !06:18
AuroraBorealiswhere does the InventoryEntry object store its 'kind' variable?06:20
AuroraBorealisi keep seeing it referenced but i never see it created, its not created in __init__ and ctrl+f shows its not created anywhere else in inventory.py..06:21
AuroraBorealisnever mind i'm stupid, its in the subclasses. although said methods are calling that variable in the super class so they would throw errors if you called said method on the superclass o.o06:25
ChrisCauserHi Everyone, quick question. I'm reading up a lot about why you shouldn't push a feature branch directly upstream. I was just wondering if there was a way to enforce non changing id numbers so the people I work with don't accidentally do this08:30
poolieChrisCauser: yes, set append_revisions_only08:31
ChrisCauserBrilliant. Many thanks08:31
poolievila, so if you look at jam's recent get_parent_map work08:38
pooliei think there's a constant in it which he did some empirical work to change08:38
pooliei think i suggested it could be configurable and he opted not to08:38
vilafor backport reasons08:38
vilawhich is tangential but could become a concern if we never use new features by fearing backport issues, but that's not the main point here08:39
poolieso, i don't think going back and changing it to be configurable, which would potentially close 832061, would be especially useful in itself08:39
vilaI trust jam's work on setting the "best" value here, but that doesn't mean that for some setups this value will be far from optimal08:40
vilaif we can't try new values, we'll never know08:40
vilaand if the code evolves and the best value is not the best anymore, we'll never know either08:41
jampoolie: I also didn't want to introduce yet-another-read of something that doesn't-really-need-to-be-set08:41
vilaand if this constant turns out to be easily tweaked based on some (for the sake of the example) branch history property, we can't tweak either08:42
poolieso, basically08:42
vilajam: right, that's a performance issue08:42
pooliei like bugs that correspond to actual problems and where you can tell whether they're fixed or not08:42
poolieif you find a way to tweak that constant, or to dynamically configure it to make things faster, that's great08:43
vilawell, not being able to diagnose whether a constant is good or bad *is* the problem I'm referring to08:43
jamvila: so if it was something like "disable it completely" I would consider a config item. If it is just tweaking it, it really depends on how much effect it could have.08:43
jamSince my experiments said "very little" outside of edge cases08:43
poolieso, being able to change a thing when we don't have any actual reason to think we want to change it is Low08:44
pooliethere are a lot more important bugs than that08:44
vilawell, I won't ask you to extend your experiments to lp hosted code...08:44
jamvila: so in *this particular* case, I did a fair amount of analysis and testing (a couple days at least) to know that the setting was not going to be very optimizable. I don't know that it applies in every case08:44
jamvila: that was tested on lp hosted code08:44
vila*all* lp hosted code08:45
jamvila: I don't think we really care about the perf on lp:bzrtools as long as it is reasonable, and I tested against lp:gcc-linaro lp:mysql and lp:emacs08:45
poolieso, vila, if you had a good reason to suspect that by further tweaking we could get a big improvement, i'd say go for it08:45
jamI suppose I could do lp:launchpad08:45
jambut I did try to do different types of histories, etc.08:45
pooliebut that doesn't seem to be where we are08:45
jamYes, this experiment could be done again in a year, etc. But honestly, unless someone is going to spend the time analyzing the results, it won't help much.08:46
vilapoolie: it's not about *me* it's about anybody willing to try with its *own* know code08:46
jamAnd if they are doing that, they don't need a config setting08:46
vilawhat do they need then ? Modifying the code ?08:46
jamvila: sure, or a plugin that modifies the constant, or ...08:46
poolieso if someone is going to tune this, it's probably pretty easy for them to make it configurable at that point08:46
jamin the end, you need to write a script08:46
jamand that can fairly easily get at what you need08:47
vilaor just a fix for bug #491196...08:47
ubot5Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/49119608:47
pooliei think adding a command-line option is possibly the thing that would help them most08:47
poolieright, i would say that is far in advance of going back and making every thing configurable08:47
pooliei think too, many things that could be tuned don't want to be tuned by just changing an integer08:47
pooliebut possibly changing the algorithm, which is beyond what this can do08:47
vilaright, changing algorithms is better done via hooks08:48
vilabut hooks can also be configured08:48
poolieor experimenting with an actual patch08:48
jamvila: or you can write a plugin...08:48
jamor monkey patch, or.08:48
jamhonestly, if someone wants to experiment with the code, I really don't see a huge difference from them playing with the *code*08:49
vilajam: or set a command-line option, which one is the easiest for someone wanting to experiment without knowing the code base ?08:49
jamvila: someone who wants to tweak this is going to need to know a whole lot more than a command line option08:49
jamnote *this*08:49
jamSome other things would be good with a command line/environment var08:49
poolievila, a command line option would be great08:50
poolievery nice for interactively testing config related stuff, aside from anything else.08:50
jamvila: I agree that having a config item that can be set from a command line (env var, argument passed) is the easiest way to play with bulk behavior.08:51
jamIn this case, I think it is YAGNI.08:51
jamYou also want to avoid doing the whole fetch08:51
jamso you need to hack the code anyway08:51
poolievila do you see what i mean about prefering 'know you're done when' bugs?08:51
jamotherwise the 1-5min startup time is lost in the 30min transferring 600MB of data.08:51
poolievila do you see what i mean about prefering 'know you're done when' bugs, and why this isn't really one at the moment08:52
vilapoolie: yes, but we disagree on "it's done" :)08:54
pooliewhen would it be done?08:55
vilawe had many cases in the past where one setting (let's just say 'encoding') wasn't properly found (for whatever reasons) and users were blocked because there was no way to override this setting08:55
pooliei would certainly agree with that08:56
pooliein fact i think i have filed a bug about that particular case, or at least someone has08:57
vilaIf we can associate that kind of setting with a *config* setting, we can at least say: 'Look, we'll fix that in the latest stable series, in the mean time, just set it to x in this context)08:57
vilaI argue that whatever setting (constant or not) should be a config setting to cover these cases and I'd call it done when the know ones are08:58
poolieif it names some specific things that aren't configurable but should be i'd be totally fine with the bug08:58
poolie(bit questionable whether to have one bug or several but the simplest thing would be to start with one)08:59
poolieperhaps better to fix the bugs that are already filed though08:59
pooliesome of them, like fsenc, are nontrivial to change08:59
jamvila: we've had code bugs in the past that we couldn't fix in the stable release. If we could write some python config values we could say "write this config and it will fix the bug for now".09:00
jamoh, that is a plugin...09:00
jamI'll agree that 'config' seems a little better than a plugin.09:00
jammeaning "lighter for the user"09:00
vilaand doesn't require python knowledge09:00
vilaI argue that it it was that easy to write a plugin we'll have far more of them today09:01
jamvila: but does require to know the config value to set09:01
jamand if we have to give them something to use09:01
jamwe can give them the plugin09:01
vilaI'm not saying plugins are bad and should never be written, I'm saying that too few people can write them or even install them09:02
vilajam: look at bug #320593 and tell me how long the proposed plugin will work09:02
ubot5Launchpad bug 320593 in Sedot "nggak bisa buat file rrd setelah ganti system" [Undecided,Fix released] https://launchpad.net/bugs/32059309:02
jamvila: I'm arguing that the set.difference() between set(users_can_set_a_config_we_recommend).difference(set(users_that_can_install_a_plugin_we_recommend_on_a_bug)) is small09:03
vilajam: look at bug #302593 and tell me how long the proposed plugin will work09:03
ubot5Launchpad bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed] https://launchpad.net/bugs/30259309:03
pooliejam, could you review or maybe finish off https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381 some time?09:04
jamvila: longer than writing a config item for it09:04
jampoolie: it is in my "in progress" queue09:04
jamso yes09:04
pooliecool thanks09:04
vilajam: huh ? Turning a constant into a config item should be a one-liner (if you exclude the help which you need to write anyway)09:05
jamvila: "Reading options for a branch from locations.conf fails with bzr+ssh "09:05
jamare you sure you were on the right bug?09:05
poolievila, so09:05
poolielet's see if i understand09:05
poolieyou think that generally speaking we should have configs-with-defaults rather than magic numbers09:05
vilajam: https://bugs.launchpad.net/bzr/+bug/302593/+attachment/1157814/+files/fixLocationConfigForBzrSsh.py09:06
ubot5Ubuntu bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed]09:06
vilapoolie: yes09:06
pooliei agree with that, though i'd have some concern about the scalability of documentation if it includes lots of stuff most people should never change09:06
pooliesome of them should perhaps be debug flags with values09:06
jamvila: but you could never fix that with a config change09:06
vilapoolie: which is bug #74699309:06
ubot5Launchpad bug 746993 in Bazaar ""bzr help configuration" looks awful" [Medium,Confirmed] https://launchpad.net/bugs/74699309:06
poolieiiuc you also think we should go back and look for all things that could potentially be config options and change them09:06
jamso yes, the plugin is fragile, it works until you can upgrade to a newer release which has the bug fixed09:06
jamand the failure is so large in scope that it is completely outside of "tweaking a config item"09:07
pooliewell, it goes beyond that, into perhaps having an 'internal' or 'hidden' class of options09:07
pooliei don't think that's worth doing until there's actually a motivation to change them09:07
jampoolie, vila: We've also falling into the trap in the past of having configurable settings that people can tweak, but not providing a good default.09:07
jambecause we stop at "ok, they can configure it"09:08
pooliethat's a risk too09:08
jamand defaults really do matter09:08
vilaknow risk09:08
vilaknown risk, but I'm talking about the other end of the spectrum where there is *no* way to change it09:08
jamvila: I feel we got a bit off on the wrong foot, though. I agree that *in general* I'd rather have something exposed to the user easily in case something goes wrong.09:09
jamThis particular case, the reward / benefit was not high enough.09:09
jamWhen we have properly cached configs, that may change.09:09
vilajam: pfew, thanks09:09
jamvila: note that I was clear all along that *this case* was how I handled it.09:09
vilajam: right, I never said you did wrong given the existing code base 109:10
vilaI'm saying many problems we encountered *could* be far easier to address09:11
vilapoolie: yes, this may not be the first thing to work on *today* but I'd like us to keep it in mind and not punting every time09:11
poolieok, i just read https://bugs.launchpad.net/bzr/+bugs?field.tag=config09:12
vilapoolie: in that respect, I feel that 'low' is pretty close to 'wontfix'09:12
pooliei think the ones that are High are plausibly high09:12
vilawell, those are the ones I filed yesterday (except for the first one), I didn't touch the others but I took them into account when writing the devnotes/configuration.txt09:13
jamvila: the flip side of the argument is that you've spent a fair amount of time reworking the config stuff, which still isn't quite enough of a change, vs just fixing the bugs we run into that could have been easier with a better config system.09:14
jam(limited human time and all that)09:14
jamI really like where you are pushing config09:14
jamI'm not sure if it was the optimal use of time09:14
pooliejam, yeah, that's why i'm looking at that list09:15
poolieperhaps vila can finish up the High bugs there and any that naturally fall out from doing it and then move on for a bit09:16
poolieperhaps to udd09:16
vilajam: my counter-argument to that is that I didn't spent that much CPU time on it considering the results and that we are now with two designs in flight and that is already a concern09:16
jamvila: sure, I certainly think it has been started, it is in flight, we need a clear landing for it09:17
jamas poolie said, a clear "it is done"09:17
jambut I think you're at a point it can be ratcheted down09:17
jamrather than a primary focus. Perhaps not09:18
vilawell, it's certainly not the only thing I'm working on and I fail to see which of the ~10 mps landed in the last 15 days is not on the cirtical path09:18
poolieso, in <http://people.canonical.com/~mbp/kanban/vila-kanban.html> (which may be lossy)09:20
pooliei see 7 for the last month, and 3 are config related (of which 1 is my fdatasync bug, and fairly serious) and 4 are test suite failures09:21
vilapoolie: yup, definitely lossy because  I didn't file bugs I was fixing (at the some time slicing the features doesn't match filing bugs in my mind but I can change that (which I started yesterday))09:21
poolieanyhow, i think john and i are just keen to have config infrastructure and also to get your help on other things09:26
jamvila: poke about https://code.launchpad.net/~vila/bzr/missing-stacks/+merge/7191809:42
jamYou said "Remote branches ignore bazaar.conf and locations.conf" care to clarify?09:42
jamit sounds dangerously wrong09:43
jamas locations.conf is provided as a way to *override* settings in branch.conf for remote items.09:43
jamremote branches09:43
sorenHi. I'm hoping someone can help me decipher this error message:09:46
sorenbzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/%2Bbranch/nova/" and relative path "../../../~soren/nova/trunk/"09:46
sorenIt's in response to "bzr lp-propose-merge -m 'something'"09:46
sorenhttp://paste.ubuntu.com/673669/ is my ~/.bazaar/locations.conf09:46
sorenAnd I have *no* clue what ../../../~soren/nova/trunk/ is.09:47
sorenOh. It's from Launchpad.09:53
vila"it sounds dangerously wrong", see revno 5999, I'm not introducing that09:57
poolieoh, so i think your parent_branch config setting is wonky09:57
vilajam: "it sounds dangerously wrong", see revno 5999, I'm not introducing that09:58
pooliehm, or, which branch are you trying to propose?09:58
vilajam: I'm just formalizing the existing code09:58
pooliesoren, basically what's happening is that bzr is trying to infer which branch you intend to merge into, and getting an apparently impossible path09:58
sorenpoolie: Can you try this, please:09:58
sorenpoolie: bzr info lp:nova09:58
jamvila: that was *only* for reading *just* branch.conf to get the stacking location09:58
sorenJust for shits and giggles.09:58
jamnot *all* settings09:58
jamif that's what you've done, great.09:59
sorenpoolie: ...because I get that error doing that as well. ~soren/nova/trunk is something that only ever existed on Launchpad.09:59
sorenpoolie: Hang on, I'll post the .bzr.log.09:59
jam(we no longer support using locations.conf to override a stacked location, but we still support it for everything else)09:59
vilajam: it's not used yet but the plan is to use it only for this case if that's possible09:59
vilajam: and neither do we for default_stacking_on if I understand correctly10:00
sorenpoolie: http://paste.openstack.org/show/2269/10:00
jamvila: I think you're right about default_stacking_on but I have limited experience with it.10:00
sorenpoolie: It seems to get the ~soren/nova/trunk bit back from lp (no clue why, though) and tries to make sense of it locally.10:00
sorenpoolie: Or rather, ../../../~soren/nova/trunk which makes even less sense to me.10:00
vilajam: but thanks for the poke, I'll double-check (now that you mentioned it, I may have fall into a trap with that)10:01
sorenpoolie: This happens even if I explicitly specify the target branch.10:01
poolievila, can he fix this with bzr config to update the branch conf?10:01
vilajam: which in retrospect was my main concern with revno 5999 (even if I didn't make a funny face at the time ;)10:02
sorenpoolie: ..and with an empty locations.conf as well, apparently.10:02
vilapoolie: in theory yes, in practice there may be bugs with remote branches10:02
vila... they should be filed and fixed of course ;)10:02
pooliesoren, did you perhaps rename this branch from something else to be the trunk?10:03
jamsoren: it is a setting in .bzr/branch/branch.conf which is saying that the "parent" branch is ../../../~soren/...10:03
jamI'm not sure why we need the parent10:03
jamah, lp-propose is failing10:03
jambecause it is trying to auto-detect what branch you want to target10:03
poolieyes, that's what i said :)10:03
sorenjam: .bzr/branch/branch.conf:  http://paste.ubuntu.com/673676/10:04
jampoolie: yeah, your statements were intermixed around when I was chatting with vila, so I missed bits10:04
jamsilly conversation threading10:04
pooliesoren i think 'bzr config -d lp:nova --remove parent_location' should fix it10:04
sorenpoolie: Nope.10:04
sorenpoolie: I haven't referred to anything as trunk in over a year.10:04
jamsoren: it is the remote one that is probably the issues10:04
sorenI'm happy to try it, but:10:05
vilaI suspect we have been propagating parent_location from local to remote branches in the past (and we may still do so)10:05
jamsoren: the small issue is that launchpad changed how you access branches, from always being 3-parts (~user/project/branch) to sometimes just +branch/project10:05
sorenThere's no reference to anything called trunk.10:05
jamsoren: the issue is lp:nova10:05
soren~soren/nova/trunk was abandonded well over a year ago.10:05
sorenjam: Oh.10:05
jamsoren: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf10:06
sorenjam: That makes even less sense to me:10:06
* vila pesters about not being able to decipher /+branch-id/36222210:06
sorenjam: Oh, dear.10:06
sorenjam: That is so wrong.10:06
jamsoren: I'm guessing you created the branch by branching from soren all those years ago10:06
sorenjam: Yes, that's entirely likely.10:07
jamsoren: what version of bzr are you using?10:07
sorenBazaar (bzr) 2.4.010:07
jamsoren: bzr config -d lp:nova "parent_location="10:08
sorenI can't.10:08
jamshould get rid of that setting10:08
sorenI'm not ~hudson-openstack.10:08
soren...but I guess I could become him.10:08
jamsoren: we can get a sys-admin to do it if you can't10:08
jambut it takes a while10:08
* soren does so while whistling innocently.10:08
poolieyou're asking a sysadmin?10:09
vilaI think he's becoming ~hudson-openstack and can't answer from there ;)10:09
jampoolie: soren is doing it himself10:10
jamwell, at least for now10:10
poolieoh, really10:10
jamif he comes back saying it doesn't work, i'll contact a losa10:10
jampoolie: it sounds like ~hudson-openstack is a bot10:10
jam(hudson and all that)10:10
* vila scratches head...10:12
sorenI'm battling this right now: Unable to copy ownership from "/var/lib/jenkins/.bazaar" to "/var/lib/jenkins/.bazaar/locations.conf". You may want to set it manually.10:12
sorenGImme a minute.10:12
vilalaunchpad redirects lp:nova to https://code.launchpad.net/~hudson-openstack/nova/trunk but 'bzr config -d<xx>' doen't give the same result10:13
sorenWhat does this mean for me?10:13
sorenThat can't be good.10:14
poolievila ^^ ?10:15
sorenlp-propose-merge does seem to be happier, though.10:15
vilapoolie: wow, that is so wrong, lp urls are not even supposed to be supported... 'lp:novalp:nova' ... is wrong too but10:16
vilaand bug #832653 filed anyway10:17
ubot5Launchpad bug 832653 in Bazaar "bzr config -d lp:nova gives unexpected results" [Medium,Confirmed] https://launchpad.net/bugs/83265310:17
vilasoren: what's your 'bzr config' output in the branch you ran lp-propose ?10:18
sorenvila: http://paste.ubuntu.com/673692/10:19
jamsoren: still looks wrong here: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf10:21
sorenYes, ti does.10:21
sorenit, even.10:21
vilasoren: so you're not under /home/soren/src/openstack/nova ?10:21
sorenvila: I am.10:22
sorenvila: Oh, sorry.10:22
jamsoren: sftp bazaar.launchpad.net ; cd ~hudson-openstack/nova/trunk/.bzr/branch; rm branch.conf10:22
soren10:02 < soren> poolie: ..and with an empty locations.conf as well, apparently.10:22
sorenvila: I cleared out locations.conf to see if that was causing it.10:22
vilaha, ok, empty locations.conf was the missing bit10:22
jamsoren: though you can continue helping vila debug remote config issues if you want.10:23
vilasoren: keep in mind that locations.conf *overrides* branch.conf (but seem to act as a default value provider)10:23
sorenvila: Wow, really?10:23
sorenThat's... wow.10:23
sorenIs that by design?10:24
jamsoren: Users have access to locations.conf10:24
jambut may not have access to branch.conf10:24
sorenHow can they not have access to branch.conf?10:24
jamsoren: You can't write to *my* branch.conf10:24
jamthough you may read it when branching from me10:24
jamso locations.conf was designed as a way to override settings for your personal use10:24
jambut also grew globs10:25
vilasoren: see bug #83204610:25
ubot5Launchpad bug 832046 in Bazaar "needs a way to specify default values for config options by path" [High,Confirmed] https://launchpad.net/bugs/83204610:25
jamwhich meant that it started providing defaults as well as overrides10:25
jamwhich makes things messy10:25
jamyou need 3 layers, basically10:25
sorenDefaults, branch, overrides.10:25
jamdefaults get overridden by branch local config gets overriden by user specified overriedss10:25
sorenThat lp:novalp:nova thing... Is that going to cause troupble?10:26
sorenOr trouble?10:26
vilatyops welcome ;)10:26
fullermdRule 1: You always need 1 level more than you have.  Rule 2: The cognitive load limit is always 1 level less than you have    :p10:27
sorenvila: "tyops"?10:27
sorenvila: Oh. typos :)10:27
vilawell, I would be surprised if it applies to lp:nova urls anyway since urls are supposed to be translated already when dealing with locations.conf10:27
sorenvila: orly?10:27
vilasoren: yeah, I do less tyops once I invoked the tyop god10:28
vilabut it doesn't work everytime10:28
fullermdWell, maybe this time dog will simile on you.10:28
vilafullermd: smile ?10:31
pooliepqm might be having trouble?10:32
pooliei've asked the sysadmins10:32
vilajam: wow, you sent https://code.launchpad.net/~vila/bzr/824513-fadatasync-options/+merge/72454 to pqm *after* I did (lp is misleading, I did the send after the push)10:34
vilajam: still I didn't get any answer, did you ?10:34
jamvila: I was trying to submit one of mine, I just read the proposal wrong and submitted yours10:35
vilapoolie: blackbox.test_branch.TestBranch.test_branch_broken_pack FAIL is spurious, dunno if we have a bug for that though10:35
jelmerwe do10:35
poolieyes it's broken; will be fixed soon10:35
poolieo/ jelmer10:35
jelmerhey poolie :)10:35
vilajam: ha, ok, still did you get an answer or is indeed pqm borken, ha right10:35
vilajelmer: hey !10:36
pooliecan you guys re-feed them if necessary when the paper jam is cleared?10:36
jamvila: I didn't get any response and the web page is "0 scripts" for me10:36
jampoolie: certainly10:36
vilajam: ok, same here10:36
jamwant us to resubmit your "trivial" as well?10:36
poolieyes thanks, i have two or three approved10:37
pooliei have 10 assigned bugs and i think all but one or two are blocked10:37
jampoolie: in what channel did you ask the sysadmins? (Just trying to follow the thread)10:40
jelmerjam: #is10:42
jampoolie, jelmer: Are we doing the udd standup in 5 min?10:55
poolieno, it's on holiday for augest10:55
jamah, ok10:55
mgzafternoon all.11:10
* jelmer waves to mgz11:12
vilamgz: _o/11:19
pooliehi mgz11:21
* poolie fixes a package import, yay11:21
pooliehm, bug 832052 is interesting, if it was hit on 2.4.011:28
ubot5Launchpad bug 832052 in bzr (Ubuntu) "bzr crashed with ShortReadvError in _seek_and_read(): readv() read 0 bytes rather than 174 bytes at 0 for "469df00e67f848246f876663fb299e10.rix" (dup-of: 413430)" [Undecided,New] https://launchpad.net/bugs/83205211:28
ubot5Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/41343011:28
pooliewhich should have fdatasync on11:28
=== nyuszika7h is now known as somebody
=== somebody is now known as nyuszika7h
jelmerRiddell: thanks for backporting that i18n fix!11:49
Riddelljelmer: the rt got a reply so we should have access to PQM's 2.4 now11:49
jelmerRiddell: that was quick11:50
=== idnaria is now known as idnar
=== davi` is now known as Guest70489
mgzjam: ping13:05
jamhi mgz, I was wondering when you would show up13:05
mgzha, we were both waiting for each other to say something first?13:05
jamI guess so13:05
Riddellanybody object if I just turn on translations for the bzr project in launchpad?  I don't see a reason why not13:16
vilaRiddell: +1 (I thought it has been done :-/)13:16
jelmerRiddell: go for it13:17
vilaRiddell: what series will be impacted ?13:17
Riddellthat's the next question, do we want to point people at 2.4 or trunk13:17
jelmerRiddell: perhaps have it export to a different branch rather than directly to trunk13:17
jelmerRiddell: does 2.4 have enough support for translations for translations to actually be usable?13:18
vilaRiddell: if there is a way to point to trunk-only first that will allow us to debug the fallouts13:18
Riddelljelmer: yes, for most of the command help text13:19
vilajelmer: only command helps IIRC, so testable but not that useful13:19
jelmerI'd prefer targetting trunk in that case; we don't know what other fallout there may be from translations13:19
Riddelljelmer: what's your worry about exporting to trunk?13:30
jelmerRiddell: worried about a bot committing directly to one of our branches (and perhaps conflicts with pqm)13:41
Riddelllp:bzr-translations-export ?13:44
RiddellI wonder who should own it13:45
Riddell~bzr-core I guess13:45
jelmerRiddell: does it have to be a new project?13:56
Riddelljelmer: no, I've set it to lp:~bzr-core/bzr/bzr-translations-export13:56
jelmerRiddell: cool13:57
RenatoSilvais there a lp plugin command for listing all branches of a project or your junk?14:48
jelmerRenatoSilva: I believe someone wrote one, but I'm not sure where you can find it14:49
RenatoSilvawell, in the lp plugin, no?14:49
RenatoSilvaa separate lp plugin? ok14:50
jelmerRenatoSilva: there isn't anything in the standard lp plugin14:51
jelmerthough I think it would be an appropriate place for it14:51
RenatoSilvaok thanks jelmer14:53
=== jam1 is now known as jam
vilajelmer: on jubany, there are uncommitted changes to plugins/builddeb and we miss 41 revisions from  lp:builddeb15:08
vilajelmer: shouldn't we at least update a bit ?15:08
jelmervila: I have to admit, I've never looked at the bzr-builddeb on jubany15:08
jelmerwhat are the uncommitted changes?15:08
vilajelmer: (the uncommitted changes comment out installing the debian changelog merge hook)15:09
jelmerthat sounds reasonable15:10
vilajelmer: and the revno on jubany is 566 (607 on trunk)15:10
vilajelmer: what ? Not installing the hook ?15:10
jelmerwith regard to updating, I think it's a good idea but it would probably need some testing with current udd15:10
jelmervila: yeah, the previous hook didn't very wekll15:10
vilawork well , got that ;)15:11
vilaweird, I thought spiv was happy with it... I should have miss some episodes15:12
vilajelmer: what kind of testing ?15:12
jelmervila: Spiv added a new changelog merge hook15:12
jelmervila: but I'm pretty sure that was after r56615:12
vilajelmer: ha ! So it may be worth re-trying the new one right ?15:13
vilajelmer: yeah, looks like revno 59615:13
jelmervila: some internal APIs in bzr-builddeb have changed that udd might rely on15:15
jamjelmer, vila: Didn't we switch to the system installed versions? Or was that for python-debian?15:25
vilajelmer: devscripts is not installed on jubany but you said 'Add dependency on devscripts >= 2.10.59, required now that 'dch --15:26
vila    package' is used. LP: #783122' does that apply to jubany ?15:26
vilaha, crap15:28
vilajelmer: by internals API you meant DistributionBranch ?15:28
jelmervila: that would apply for the changelog merger15:30
jelmervila: though I'm surprised the changelog merger matters at all for jubany - where is that used?15:31
jelmervila: yep15:31
vilathe devscripts dep you mean ? It seems to require dpkg-dev instead but that one is installed15:32
vilajelmer: so for DistributionBranch, udd doesn't use kwargs so an update is probably required and also probably in lock-step with bzr-builddeb update :-/15:33
vilaok, harder than I thought, I'll file a bug15:34
vilabug #83309715:43
ubot5Launchpad bug 833097 in Ubuntu Distributed Development "bzr-builddeb needs to be updated on jubany" [High,Confirmed] https://launchpad.net/bugs/83309715:43
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
gdoubleuI'm seeing odd behavior trying to push to an svn repo: I make a change, commit it, and the dpush.  A commit gets recorded in the svn repo but it is empty, and my working tree returns to the state prior to the commit (i.e. bzr st/diff shows the file/change I had previously committed).  Any ideas?18:37
gdoubleuthis is with bzr 2.4.0 and bzr-svn 1.1.0dev18:38
gdoubleuI tried a fresh branch of the svn repo, but seeing the same behavior18:38
jelmergdoubleu: this is bug 82694618:40
ubot5Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/82694618:40
gdoubleuah, I searched for push and missed this one18:41
jelmergdoubleu: are you using http as well?>18:41
gdoubleuwell, https18:41
jelmerthis is actually the bug that is blocking the 1.1.0 release18:43
gdoubleujelmer, is there a previous, working version of bzr-svn that's still compatible with bzr 2.4.0?18:46
jelmergdoubleu: one of the earlier snapshots of lp:bzr-svn, but I'm not sure which one18:53
=== med_out is now known as medberry
gdoubleujelmer, fwiw using bzr-svn at revspec date:2011-07-01 works here19:33
yofelhey, is there are reason why bzr dailydeb substitutes {date} while fetching the source from bzr? Thanks to that it downloads the source every day I run it even if I already fetched the source already19:55
jelmeryofel: not sure I follow - if you don't want the date in there, why not use e.g. {revno} ?19:56
yofeljelmer: no, I want the date in there. What I wonder is why if I have '2+git{date}+r{revno}-{revno:packaging}' as version in the recipe. bzr dailydeb makes a stacked branch in like 'work/kdelibs-2+git20110824+r{revno}-{revno:packaging}' when building19:58
yofelwhy doesn't it leave {date} unsubstituted?19:58
yofellike that I need to fetch the branch every day19:59
jelmeryofel: it rebuilds if the version changes19:59
jelmeryofel: and the date changes every day :)19:59
jelmerit sounds like you want {revdate}, which is the latest bzr-builder that hasn't yet been deployed to lp20:00
yofeljelmer: this is running bzr builder by hand - not on launchpad20:00
yofelsince I still need to upload some by hand20:00
ubot5Ubuntu bug 793072 in bzr-builder "Provide deb-version variables for revision commit time/date" [Medium,Fix released]20:00
yofelwell, revdate would probably help - if it doesn't substitute it at branch time20:01
jelmeryofel: are you running 0.7.1?20:01
yofelhm, no, my server is on natty - so 0.6. Did that get fixed?20:02
jelmeryofel: no, {date} is still generated at branch construction time20:04
jelmeryofel: on launchpad these directories always get discarded so it doesn't really matter20:05
jelmeryofel: you're welcome to file a bug, and I'll see how hard it is to fix20:06
yofelok, I've got plenty of bandwidth myself, so it's not serious. Was just wondering why I have to download a few hundred MBs every day if I already have the branches on disk20:06
jelmeryofel: have you considered running it inside of a shared repository?20:07
yofelwhat's a shared repository? ^^20:08
jelmeryofel: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial20:09
yofelk, thanks for the pointer20:09
=== mwhudson__ is now known as mwhudon
=== mwhudon is now known as mwhudson
pooliehi all22:31
pooliehi there22:33
pooliethat is good news about mrevell22:41
=== medberry is now known as med_out
=== yofel_ is now known as yofel

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