[01:12] hi all [02:18] need newbie help on bzr, this is my first day with bzr. already did a svn dump, and used svn2bzr.py to create a bzr repository. now I need to know how to "commit" [02:19] suppose that I want to have a central repository in 192.168.1.1 via ssh. how can I specify bzr to commit to this machine? [02:20] pzn, so, you may want to use bazaar in a distributes manner [02:20] hi beuno [02:20] instead of centralises, like svn [02:20] poolie! [02:20] heya [02:20] beuno, no, I want to use it centralized, for everyone at my work to have a center place to commit [02:20] pzn, have you seen http://doc.bazaar.canonical.com/bzr.2.4/en/mini-tutorial/index.html? [02:21] or, I guess, http://doc.bazaar.canonical.com/bzr.2.4/en/tutorials/centralized_workflow.html [02:23] beuno, thanks! it seems exactly what I need! [02:27] hooray [04:46] hi [06:15] hi all ! === vila is now known as babune [06:15] on 8 slaves, 3 are failing, 1 is hanging spuriously [06:16] 2 are hanging "reliably" freeBSD and OSX, maverick is hanging spuriously === babune is now known as vila [06:17] poolie: and that's after filtering the failure for launchpad appearing dead while making tea locally ;) [06:19] hi vila [06:19] poolie: _o/ [06:32] poolie: feedback on library_state use wanted: https://code.launchpad.net/~vila/bzr/491196-cmdline-options/+merge/77003 [06:34] Well, stop making tea, if it's breaking launchpad :p [06:34] fullermd: ok, back to coffee then :) [06:35] I was only waiting for someone to mention it ;) [06:35] Good thing I'm around. So many people are just so unwilling to embrace the obvious solutions. [06:37] poolie: the ip route add/del trick was a good idea despite the babune fallout (unrelated to the hangs though) [07:15] bbiab === AuroraBorealis is now known as Aurora|sleep [07:41] vila, hey i'm glad to hear it [07:54] poolie, jam, jelmer, Riddell, mgz: standup in five minutes ? [07:55] stand up, clap hands, shout bzr [07:55] yup [07:55] mgz your mission is to get linux audio working in 5 minutes [07:57] poolie: hehe, I think he still needs to join :) [08:02] mgz, hi? [08:02] mgz: hey ! Join us on mumble ! [08:15] jam, for "i don't understand the encoding" byte strings there's also the option of doing what py3 does [08:16] poolie: sure. We just need to figure out how we want to represent them internally in bzr, especially how that gets encoded into long-term storage. [08:16] yeah [08:16] I don't know what happens if you try to create a file from that, etc. === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam [08:28] i see http://babune.ladeuil.net:24842/view/%20High/job/selftest-osx-10.6/305/console has failed [08:28] the meaning of the failure is not obvious [08:39] ok [08:39] so, vila, could you please propose about two sessions for uds? [08:39] on, i would guess bfbia and bzr/lp/udd [08:39] and other topics, if you want [08:39] vila: I see this failure on Maverick: http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/222/testReport/junit/bzrlib.plugins.launchpad.test_lp_directory/TestDebuntuExpansions/test_bogus_distro/ [08:40] perhaps one specifically about merging quilts? [08:40] which indicates it is actually trying to connect to Launchpad [08:40] jam: forget about that one [08:40] lp_directory.py", line 99, in _resolve_via_xmlrpc [08:40] poolie: it would be interesting to get feedback about what people actually expect that to mean [08:40] jam: I was redirecting lp requests to a blackhole at that point in time while testing the make tea stuff [08:41] vila: k. Well, we shouldn't be contacting lp during the test suite in general, it is sort of ugly. I wonder if we can easily do it better. [08:41] certainly, we should be able to run the test suite without an internet connection at all. [08:41] jam, 'that' meaning quilt merging? [08:42] poolie: yes. [08:42] jam: yeah, this has been discussed in the past [08:42] There are a lot of possible results from merging quilts. [08:42] vila: I think those tests were written by barry, who probably didn't realize [08:42] jam: yes it was and that's when it was discussed [08:43] anyway, thats the only 'failure' for maverick I found, which we certainly could fix. [08:43] silly jenkins doesn't show the killed builds anymore [08:43] I realize you have more knowledge about what is going on than in exposed via the babune webpage, though. [08:44] jam, ok, so a session about it would probably be good [08:44] probably better if we go in with an idea about how it ought to work [08:44] vila, btw, you're pp this week [08:44] poolie: you mean next week ? [08:44] oops, i meant jam [08:45] you're fine [08:46] poolie: yep, I updated the IRC topic [08:46] I saw your wiki update [08:46] is there anything you need me to do or prepare for the UDS sessions poolie? [08:50] poolie: which track did you use at the last UDS ? Fundations ? Other ? [08:52] vila: yep, foundations though I think the track leads will shuffle things around as they see fit [08:52] mgz, hm, perhaps you could pair with vila on the proposals? [08:52] that will give you some mental framework for it [08:52] jelmer: ok, is there a process documented somewhere to do a proposal ? (poolie, mgz, good idea ;) [08:53] there's some ubuntu discussion in https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-September/012901.html [08:53] cool, I will follow along [08:54] vila: I think jono or jorge posted a "how to do a UDS session" thing to the ubuntu-devel list last UDS [08:55] poolie: do you think we should try to close the 'server-read' side after SIGHUP? [08:55] (shutdown(SHUT_RD), etc) [08:55] I don't know if that is going to help us on detecting server-side-wants-to-be-done earlier. [08:56] hm [08:57] as you said there's a lot of buffering [08:57] i think shutdown also has different win32 behaviour [08:58] poolie: looking here: http://msdn.microsoft.com/en-us/library/ms740481%28VS.85%29.aspx [08:58] It seems to say, the local process can no longer '.recv()' [08:58] however, TCP will still queue things up [08:58] so it is only a in-process flag [08:58] so yeah, it does nothing [08:58] ah, I guess shutdown(SEND) will send a FIN packet. [08:59] That may be better than just close() [08:59] > For TCP sockets, if there is still data queued on the socket waiting to be received, or data arrives subsequently, the connection is reset [09:00] so the client gets a ECONNRESET [09:00] this is a bit alarming if the server has in fact read the whole stream [09:00] and it also breaks the other side of the connection [09:00] so istr this is pretty useless on windows [09:02] poolie: sure. Also, the most important reconnect to get working is bzr+ssh IMO [09:02] so whatever we do has to cope with how ssh will treat the signal [09:02] but you have a very good point [09:02] so [09:02] we can't just stop the read side, because the current request may be reading from the client. [09:03] so the server's going to finish its current request then close the socket? [09:03] there is one option [09:03] i forget how the server's actually hooked up [09:03] on lp [09:03] poolie: i'm pretty familiar with it :). [09:03] but if stdin and stdout are different fds, eg if they are pipes, then you can simply just close stdin [09:04] and that will give a clean message to the ssh server that it has closed, which it can pass backto the client [09:04] :) [09:04] poolie: right, you could close stdin, except that the "current request" may be pushing a stream of data from the client. [09:04] right [09:04] you can close it at the point you've decided you're not going to read anything more [09:04] right [09:05] that has to be done pretty much on a per RPC level, though I'm pretty sure all of them are defined as "read for a while" then "write for a while" then done. [09:05] So you could notice "I transitioned to the 'write' phase, and I'm requested to stop after this, close the read side." [09:05] yep [09:06] so you said originally 'do i think we should do this' [09:06] i don't think it's totally necessary [09:06] it seems like a thing that could be done later [09:06] it's not clear to me it will actually help, because i'm not sure the client will not get a very clear message that the server's not prepared to read any more [09:07] i'm not sure it will be any more clear, or helpful, than the server just sending the response to the current rpc and then simply closing the sockte [09:12] poolie: right. Digging into it feels like something we can try in the future, but in reality we have to just handle that we can't reliably detect server has shutdown before we start trying to send the new rpc. [09:12] vila, poolie: Who's sending the standup notes to the list? [09:13] jam: please do [09:13] will do [09:15] jelmer: can't find that in ubuntu-devel, do you have an URL ? [09:16] sent [09:17] vila: hmm, not sure [09:18] vila: I thought it might have been linked from summit.ubuntu.com, but that appears to be down atm [09:20] vila: one of the ubuntu community team members should be able to point you at it [09:20] +1 [09:21] for instance dholbach [09:21] jelmer: I'll try that too, I'm trying to get touch with slangasek ATM [09:21] it would be worth engaging with him even if there are documents [09:21] * vila nods [09:22] both pinged [09:27] jam: jenkins hiding the killed builds seems to be a very recent change, in the mean time, I've started builds for OSX and FreeBSD which are longer than usual indicating a hang: http://babune.ladeuil.net:24842/job/selftest-freebsd/buildTimeTrend http://babune.ladeuil.net:24842/job/selftest-osx-10.6/buildTimeTrend [09:28] vila: is there a way to get the raw subunit output? [09:28] or something that can give individual test times? [09:29] jam: with parallel builds there are multiple subunit streams which complicates things [09:29] only on success AFAIR [09:29] if all goes correctly babune can show the build times [09:30] ...but yeah, what vila said [09:30] and parallel are the first line of defense against hangs :-/ [09:30] there's no good option when something goes really wrong, having to kill thw whole job without any feedback on where the problem was is... troublesome [09:30] or leaks leading to slave crashes or whatnot [09:31] vila: Steve's in Portland I think, so not likely to be up at this hour :) [09:32] so, I did add a flush at test start to subunit a while back, so if all streams get to disk there's some hope a test name could be obtained [09:32] whether that would actually be enough to repro is another matter [09:32] mgz: parallel use pipes no ? [09:32] oh you mean, the main one [09:33] jelmer: thanks for the heads-up, I'll retry later today [09:33] ah, yeah, the concurrent reporter might defeat us. hm. [09:33] mgz: but the main one is what jenkins collect so... [09:34] vila: submitted a review to your cmdline-options MP, btw [09:35] jelmer: thanks, let me see that [09:49] jelmer: pushed a new version with some fixes, will look at hiding the option but see my remark [09:54] jelmer, did your bfbia db patch get unblocked? [09:54] poolie: sortof, it's now a trivial one-liner that's not particularly important [09:54] francis reminded me today that unless you specifically need review from robert, you can probably get a faster answer from stub [09:54] oh right, i saw it shrunk [09:54] ok [09:54] poolie: I'll take it off +needsreview, thanks for the reminder [09:55] poolie: It will most likely still be necessary, but I'd rather get the other stuff landed first; if I have to do more database changes I'd rather do them together [09:56] no problem, just wanted to see if you were blocked [09:56] robert gets some kind of prize for bugspam [09:56] heh, of the kind jelmer used to do :) [09:59] jelmer: hidden options are still shown in the help ! So I've pushed a new fix to hide it. [09:59] poolie: :) [09:59] vila: ah, cool [10:04] vila: I don't think anybody will use --override-config (vs -O), which is also why I'm a bit hesitant to penalize all help texts when adding it. [10:05] vila: I'm surprised hidden options are still shown in help though, isn't not showing them there the whole point of hidden? [10:05] uh, hidden? [10:05] i would think it should be a global option [10:06] that was my thought reading the mp [10:06] showing it in the help for every command seems... unnessersary [10:06] does bazaar@canonical .com go anywhere? [10:07] it might be less discoverable, but as you have to go off and find the config option names anyway... [10:07] doesn't global options require each command to declare it ? [10:07] poolie: reminds me, I have another 75 bugs to triage today [10:08] lifeless: you're insane :) [10:08] lifeless, is spamming ~40 people really worth the clarity? [10:08] mgz: we're closing a lot that are stale/done/clearly-wont-fix [10:08] poolie: they are welcome to unsubscribe :) [10:08] i refer specifcally to changes that are only mid->low [10:08] poolie: and yes, its well worth it [10:10] yawn [10:10] launchpad isn't quite smart enough to not send mail for trivial changes yet [10:10] yeah [10:10] that would be nice [10:10] as would having an internal activity view so i could turn off mail [10:11] one day [10:11] good night all [10:12] poolie, mgz, jelmer : Right, hidden options should be ouput in help, that's indeed the point, so there is a bug there [10:13] have a great night poolie [10:13] *evening [10:13] and both standard and global options seem to be affected [10:15] jelmer: bug 860424 filed [10:15] Launchpad bug 860424 in Bazaar "standard and global options don't respect their hidden attribute and are shown in help" [Medium,Confirmed] https://launchpad.net/bugs/860424 [10:15] jelmer: so, the consensus seem to be this should be fixed ? [10:16] jelmer: should I put the -O proposal as wip in the mean time ? [10:19] jam: jenkins hiding interrupted builds seems to be a very recent change, in the mean time, there are two builds hanging right now for FreeBSD and OSX ( http://babune.ladeuil.net:24842/job/selftest-osx-10.6/buildTimeTrend and http://babune.ladeuil.net:24842/job/selftest-freebsd/buildTimeTrend) [10:20] jam: I killed the previous ones this morning and they were showing up at the same place, I also did a jenkins upgrade which may have introduced this behavior change but... that's not mentioned in the changelog) [10:29] yeah, the console output isn't very useful because it's been syncronised to make sure all parts of a test appear together [10:33] vila: Yeah, I think this should be fixed first [10:33] haa, haa, haa, haaaa, shaving the yack, shaving the yack [10:34] let's do that after lunch :) [10:34] well, the problem otherwise is that we'd have to update the help texts and then change them when that bug gets fixed [10:34] jelmer: oh, if it's hidden, is that ok with you to keep --override-config or do you have (yeah I know) [10:35] vila: if it's hidden I don't mind there being a --override-config [10:35] or do you have a less ambiguous proposal than --option (or am I the only one feeling it's ambiguous ?) [10:35] ok [10:35] cool, thanks [10:55] vila: btw, have you seen the config system used in bzr-builddeb? [10:56] It's also something that could very well use stacks [10:56] jelmer: not in detail, but I mailed you a question about option expansion long ago :) [10:56] jelmer: do you see missing features in the stack based design for builddeb > [10:56] ? [10:58] vila: not as far as I can tell [10:58] \o/ [10:58] :) [11:34] jelmer: hmm, there is a possible workaround for -O: handle it as --builtin, --profile, --lsprof, --coverage and so on and just forget about making it a standard option and its fallouts [11:35] vila, that's a choice between `bzr -O... command ...` and bzr command -O... ...` is it? [11:35] wow, dunno, let me check [11:36] doh ! [11:36] indeed, that's a side-effect of the implementation but it's not a choice, *both* are handled [11:37] I don't think that was a conscious choice when implemented but thanks for solving that puzzle ;) [11:38] the implementation just remove such options from the argv *before* calling cmd.run() no matter where they appear [11:40] jelmer: ^ ? [11:40] ah [11:41] vila: I think it should indeed be a global option [11:42] err, as in forcing all commands to declare it ? Or as in those pseudo-globals I mentioned above ? [11:43] pseudo-globals mentioned above (how are they pseudo?) [11:43] the distinction is quite blurry as some are registered as globals, some not.. ha, and I think the pseudo-ones are documented in help_topics._global_options *-) [11:43] 8-) even [11:44] right, the help there makes that clearer [11:49] hmm, my upload for 2.2.5 is being rejected [11:51] ghaa, my lp-propose crashed :( [11:51] (2.2.5 seems to have only 3 bugs that are actually relevant for ubuntu, btw) [11:51] jelmer: should be the moon, let's retry :) [11:51] vila: already tried twice, not sure what's wrong [11:52] jelmer: yeah, I was kidding [11:52] I didn't think you seriously meant it could be the moon >-) [11:52] jelmer: but bug #715000 and #710410 sound good to release though and the last release was looong ago [11:52] Launchpad bug 715000 in Launchpad itself "Stacking is not fully transitive" [Critical,Fix released] https://launchpad.net/bugs/715000 [11:52] Launchpad bug 710410 in QBzr "ConfigObj is able to write bad branch.conf which is not possible to read back" [Medium,Confirmed] https://launchpad.net/bugs/710410 [11:53] huh ? [11:53] bug #609187 [11:53] Launchpad bug 609187 in bzr (Ubuntu) "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Fix released] https://launchpad.net/bugs/609187 [11:53] vila: bzr uses the system configobj so bug 710410 isn't relevant [11:53] yeah, read the bad number [11:53] but yeah, those other two are still nice to get fixed in maverick [11:53] I really meant 609187 [11:54] I actually meant 805809 rather than 609187 [11:54] I doubt there are any Ubuntu developers who are still on Maverick [11:54] yeah, I was about to mention that this one is pita [11:56] jelmer: anyway, I'll ask oulder for more feedback next time I'm about to cut a release for SRUs but... 2.2.5 is ready to release, no bugs are targeted to 2.2.6... [11:57] louder not oulder [12:00] jelmer: and I won't object about a discussion of what we should do we all our series, I don't have objections either about EOL'ing 2.0 (planned for 2011/11 so far, will not be SRUed imho), keeping 2.1 for lucid [12:01] for 2.2 the plan is 2.2.6 in 2012-02 and 2.27 in 2012-09 (if bugs justify that) and EOL too [12:01] the plan for 2.1 is not that clear in my mind ;) But it's an LTS so we may have to support it longer [12:05] vila: I think this is still enough to do a release for, but I do think we should consider whether releases are necessary (especially for old series) [12:05] full agreemnt [12:06] I *always* ask for feedback before doing releases for old series, may be I should do that earlier and *louder*, but I'm pretty sure this one was discussed [12:09] jelmer: 瑨灴㩳⼯潣敤氮畡据灨摡渮瑥縯楶慬戯牺㠯〶㈴ⴴ楨摤湥漭瑰潩獮⬯敭杲⽥㜷㔱 [12:09] grrrr [12:09] vila: ehh.. sure? [12:09] jelmer: I swear, I pasted: https://code.launchpad.net/~vila/bzr/860424-hidden-options/+merge/77159 [12:10] :) [12:18] jam: http://paste.ubuntu.com/697835/ is what I found on the OSX slave, not sure it's related but the smart server being involved in all cases is suspicious in itself [12:19] jam: http://paste.ubuntu.com/697836/ is for the FreeBSD one (not clearly related to the OSX one, so... both may not be valid starting points) [12:24] phew, enough starting at pyrex generated C, have reproduced the right error [12:32] mgz: its not so bad once you learn to ignore _pyx_v_ :) [12:34] vila: what I really don't understand is why one parallel subprocess would cause another one to hang. Or is it just that things are *slow* not that things aren't working? [12:34] and can I get ssh access to those machines? [12:36] well, probably the main process is waiting for a hung children [12:37] but as mentioned this morning, I've never been able to debug the jenkins runs themselves, far too many layers involved there [12:38] you can use jenkins (notably the *subset* jobs) to restrict the tests and better identify the culprits but in the end you need to know which race it's about to fix it [12:44] Riddell: I reviewed your i18n-plugins branch [12:45] Riddell: I wonder if we need some sort of mechanism to prevent loading all po files for all plugins all the time [13:16] vila: are you sure message is a 'global option' ? [13:16] I don't think you can do "bzr status --message" [13:16] I think of global as more "--verbose", etc. [13:16] And your proposed "-O" would certainly be global. [13:16] jam: see option.py [13:17] jam: and see cmd_log which hides it [13:17] jam: and try 'bzr help log' [13:19] vila: cmd_log just implements a regular Option(message, hidden=True) [13:19] I think you want to look at "_standard_option" in option.py [13:19] So, to use better terms. [13:19] that's where I came from :) [13:20] _global_option is just a defined option that Commands can reference by string, rather than having to use the Option class [13:20] _standard_option is an option that is available to all commands without them doing *anything* [13:20] and those probably can't be hidden [13:20] your -O should be a _standard_option and you want it to be hidden. [13:21] no, it's just asking for trouble, it's far easier to make an option similar to --lsprof and the like, read the irc log [13:21] vila, from your patch: [13:21] +_standard_list_option('override-config', short_name='O', type=unicode, + help='Override a configuration option value,' + ' e.g. -Oname=value') [13:22] sorry about the bad paste, but it is *clearly* a "_standard_option" [13:22] not a global one [13:22] jam: yes, that's a wrong approach, read the other comments and the irc log [13:23] and my last push on this proposal (which lp should be displaying rsn jelmer ;) [13:23] vila: I don't see anything in the "other comments" that it shouldn't be a standard option [13:23] I think it *should* be a standard option [13:23] try the irc log ? [13:23] vila: where ? [13:23] here [13:23] it was discussed earlier [13:23] today, yesterday, 3 hours ago? [13:24] I guess when should have been a better question [13:24] jam: certainly not before the additional revisions on the mo :) [13:24] s/mo/mp [13:24] vila: before or after the standup? [13:25] vila: I'm pretty sure poolie meant to say "standard_option" not global option [13:25] he meant global as in, applies to every command [13:26] which is what I originally thought the bug was, etc. [13:26] jelmer: I think plugins can choose to not load the gettext file until needed if they so wish [13:26] jam: from 11:34 my time [13:26] jam: read the log, global options are opt-in for all commands [13:27] vila: I don't think "-O" should be opt-in [13:27] I don't think poolie thought so either [13:27] he never commented [13:27] I'm 75% sure when he said: "i would think it should be a global option" he meant that it should apply to all commands [13:27] not be opt-in [13:27] but of course it shouldn't be opt-in which is why it shouldn't be a global option [13:28] vila: so from what I can tell, the *real bug* is that _standard_options don't respect hidden, which you haven't fixed [13:28] and would thus still block landing -O [13:29] right, if your point is to block landing, I'm sure you can find a way to get there [13:29] i'm not specifically trying to block landing. Jelmer asked that -O be hidden [13:29] you said "global options don't respect hidden" [13:29] but they do [13:29] you noticed that [13:29] you haven't handled "standard options don't respect hidden" [13:29] I'm not trying to block you [13:30] just pointing out that the bug is still there [13:30] now, would you mind reading the log and having a look at bug #860424 and the assiciated mp we may have some progress [13:30] Launchpad bug 860424 in Bazaar "standard and global options don't respect their hidden attribute and are shown in help" [High,In progress] https://launchpad.net/bugs/860424 [13:30] vila: I've read all of that [13:30] when ? [13:31] vila: I've read them 2 times while we've been discussing it [13:31] ha, you commented on the mp, why didn't you start with that ? [13:32] vila: I was poking you on IRC to point out the MP, I could have linked it, I guess [13:32] right, anyway, for https://code.launchpad.net/~vila/bzr/860424-hidden-options/+merge/77159 [13:33] I think message and log are still appropriate since they show that a global option can be hidden by a specific command [13:33] vila, so yes, global options are already hidden. That doesn't fix the full bug, though, does ti? [13:33] that _standard options are not hidden? [13:33] but my point is: do we really want to hide a standard option ? [13:33] So to start with, yes, I was a bit confused because "global option" isn't a global option [13:33] which of the existing ones would you hide ? [13:33] vila: -O [13:33] as discussed [13:33] which started this whole thing [13:33] you miss the point [13:33] -O is *not* a standard option anymore [13:34] vila: why not? (i think everyone has actually said it should be) [13:34] (caveat the confusion between global_option and standard_option) [13:34] expect it should be hidden which standard options doesn't allow [13:34] which is a bug [13:34] really ? Which use case do you have ? [13:34] vila: I feel like we are talking past eachother. [13:34] Do you feel that -O should be explicitly stated for every command? [13:35] no [13:35] k [13:35] That makes it a standard_option, right? [13:35] no [13:35] see my last revision [13:36] jam: is 'coverage' a global option ? [13:36] jam: is 'coverage' explicitly stated for every command ? [13:36] vila: 'master options' as they are listed were implemented before we had standard_option [13:36] I really think standard_option is a better framework for it [13:37] same goes for a bunch of them, the confusion is that *some* of them are still declared in option.py [13:37] All of the ones in run_bzr should be removed, IMO [13:37] it is a *really* bad argument parser that I wrote way back when [13:37] before we integrated with optparse and made it possible to do nice things [13:37] like "--lsprof-file foo" doesn't work. [13:37] sorry [13:37] '--lsprof-file=foo' doesn't work [13:37] fell free to fix it :) In the mean time it's out of scope for bug #491196 [13:37] Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196 [13:38] You have to spell it "--lsprof-file foo" [13:38] vila: I feel you did it the right way the first time [13:38] we just want to allow hidden=True to work [13:38] jam: hehe, thanks, me too [13:38] which doesn't seem very hard [13:38] jam: yeah, I tried that and saw this wasn't trivial *at all* so I found an alternate way [13:38] vila: Once stacks are generally supported, I think it should stop being hidden. [13:39] everybody is telling me I try too hard but when I use shortcuts you complain, take your pick ;) [13:39] jam: well, I can turn it into a standard option then ;) [13:42] vila: well, different people are saying different things, we are allowed to have different opinions [13:44] sure, but in this case there is a separate bug for the standard option that can't be hidden and that's not blocking bug #491196 anymore [13:44] Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196 [13:44] in my mp regarding the former I said I don't think hidding a standard option makes sense [13:45] vila: I think lsprof, etc should probably be turned into standard options, at which point we probably would want them hidden as well. [13:45] and I'd rather spend time on migrating the remaining options than implementing a feature nobody needs [13:46] digging into it, I'm having a hard time determining why they aren't hidden [13:46] exactly [13:46] given they seem to go through the same "is_hidden" code paths [13:46] there seems to be agreement on the basic goal of -O everywhere but not in help [13:46]