[00:00] mwhudson: I'm back [00:01] jam: i hate twisted.conch [00:01] I'll go handle make lint, and then ping you again [00:01] ok [00:01] mwhudson: can't say as I'm a huge fan :) [00:01] It doesn't seem terrible, but the adapter stuff is a bit "magical" for me, and the Interfaces would be interesting if they were actually a complete spec [00:04] it's inheritance graph is a bit wonky, and it blurs the distinction between protocol and transport in confusing ways [00:05] how would I print a stacktrace to the console so I can tell where a function is being called from? [00:06] ah nevermind, I think I found what I was looking for [00:07] mwhudson: I think make lint is a bit overzealous. It seems to be finding a ton of stuff in files I didn't touch [00:07] Is it meant to only run on the local branch modifications? [00:07] (I saw it ask something about "bzr: pipes unknown command" [00:07] jam: yeah, it's meant to do a st -r submit: and do it on the files reported changed, i think [00:08] jam: so about the 'blocking' code you added to session.py [00:09] (it seems to use "bzr info | sed..." to find the parent branch, but my parent is 'devel' but I've merged 'db-devel' and all hell has broken loose [00:09] jam: :( [00:09] jam: maybe just run pyflakes on the files you know you've changed [00:09] bzr pull --remember ../lp-branches/db-devel seems to sort it out [00:10] ah ok [00:10] still a lot of noise [00:10] (Makefile: line exceeds 78 chars, about 20 times) [00:11] yeah, i saw that [00:11] i don't think we care [00:11] and do we *really* want (foo, ) vs (foo,) ? [00:12] GaryvdM: any idea why run_app doesn't do the appropriate bzr executable substitution but relies on callers to do so? [00:12] gar, conch seems to conflate "a subprocess has been requested" with "a subprocess has been launched and is connected" [00:12] which is a very non-twistedy sort of thing [00:12] GaryvdM: this is in bzr-explorer, bug 656072 [00:12] Launchpad bug 656072 in Bazaar Explorer "explorer should invoke qbzr with same bzr (affected: 1, heat: 8)" [Undecided,In progress] https://launchpad.net/bugs/656072 [00:12] mwhudson: well, instantiating Process means it has forked [00:12] * GaryvdM opens code [00:12] GaryvdM: it seems like a logical DRY place to put it [00:13] jam: yeah, but it makes it hard for us to do the right thing in our execCommadn [00:14] mwhudson: what do you consider "the right thing"? [00:14] I guess I'm not sure where you think we shouldn't be blocking? Because of _spawn connecting to another service to request the fork? [00:14] jam: use twisted apis to do the communication with the forking service [00:15] mwhudson: right. And what you're finding is that "spawnProcess" wasn't a deferred, so we can't build up a new deferred based on responding to the socket interaction [00:15] Is that correct? [00:15] jam: something like that [00:16] well, it's not really "is a deferred", it's more that conch expects that by the time execCommand returns, it's ok to try to write data to the client [00:16] er [00:16] s/client/protocol/ [00:16] the thing is, there's _almost_ support in conch for doing the right thing [00:17] dOxxx: I agree that that makes sense, but I'm not sure that is the cause of the bug. [00:18] GaryvdM: indirectly it is. the edit_config_file function which invokes qconfig doesn't do the bzr executable subsitution, thus it just executes "bzr qconfig" [00:18] dOxxx: Where do we call run_app with out using _get_bzr_executable? [00:18] Ah - ok [00:18] I agree with you then [00:19] GaryvdM: and the bzr executable replacement is different at different call-sites. [00:19] GaryvdM: for example, the tool menu uses qrun --ui-mode sometimes [00:20] GaryvdM: hopefully I can make run_app handle all the cases [00:21] So maybe instead of having to call run_app(['bzr', 'qconfig']) make it so you just do run_app(['qconfig']) [00:21] DRY [00:21] dOxxx: ^ [00:22] GaryvdM: the tools menu can be anything, not necessarily a bzr command [00:22] Ah [00:23] def run_bzr [00:23] I don't actually know the BE code that well. [00:24] changing the way the app suites like qbzr are defined and executed, i.e. if I were to create a run_bzr_app funciton would be a somewhat disruptive change [00:24] I'm more inclined to make run_app more intelligent about replacing the executable [00:24] it's a more localized change [00:24] mwhudson: (well, given that spawnProcess returns an IProcessTransport, but Process isn't one, and conch expects it to support .write() which isn't part of IProcessTransport anyway...) [00:24] ok [00:24] I'll give it a shot and see how it goes [00:25] jam: whee [00:25] jam: it also turns out that twisted doesn't support connecting to a fifo [00:25] mwhudson: I don't know where, but before I implemented "def write" it didn't work [00:25] bzr is giving me connection errors trying ot use launchpad [00:25] mwhudson: it certainly does support it, read my code :) [00:26] jam: "in a non blocking way" [00:26] mwhudson: it is non-blocking, using the "dataReady" stuff [00:26] jam: os.open isn't! [00:26] mwhudson: it is selectable [00:26] jam: but the open syscall itself blocks, doesn't it? [00:27] so while the specific read is blocking, it won't be requested until the file descriptor says it is ready [00:27] you can supply O_NBLOCK, but yes, it is blocking [00:27] bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 111] Connection refused [00:27] anybody know what's going on with that? [00:27] (and you can't use O_NBLOCK for writing or it raises an exception, and if you do use it for reading it will force all future reads to be non-blocking) [00:28] mhall119: http proxy issue of some sort [00:28] mwhudson: how, in twisted, do you actually open a file without blocking? [00:28] oh nevermind, tried the command in a new terminal and it worked.... [00:28] hi spiv, care to join the lovely twisted conversation? [00:28] thanks spiv, but have some env variables set wrong [00:29] jam: good question [00:29] i think you don't basically [00:29] jam: been reading along, but not much to add [00:29] s/conversation/bashing/ whatever :) [00:29] Basically, mwhudson has been saying everything I would :) [00:29] Twisted in general has no support for non-blocking local disk IO [00:30] Because OSes generally don't support it, apart from "do it all in threads" [00:30] Mostly because it doesn't fit the POSIX F_NONBLOCK etc.. model [00:30] hi spiv [00:30] Most POSIXes do have an aio system but it's generally not integrated with the rest of the IO nonblock primatives (select et.al.) [00:30] So it generally sucks [00:30] LeoNerd: ...and is typically just "do it all in threads" under the hood anyway ;) [00:30] Er... [00:30] AIO is a real in-kernel system [00:31] Atleast, on Linux Solaris and *BSD [00:31] (and if you can name any other non-dead POSIXalike still alive today probably that too) [00:32] Twisted programs generally assume that disk IO is "fast enough", which is often true for many use cases. If it's not, well, threads, sorry :( [00:32] jam: although these calls "block" in some sense, they're not very likely to block for a noticeable length of time [00:32] spiv: so I should be doing "callInAThread(os.open)" ? :) [00:33] mwhudson: well, if the remote process does something bad, they'll block forever [00:33] What is it you are open()ing? [00:34] jam: sorry, I was off on a small tangent. This isn't disk IO IIUC? [00:34] The problem is that most of this logic was thought through before things like NFS, CIFS, etc... started moving people's local-looking files to be not so local, and thus dependent on network latency just like anything else [00:34] GaryvdM: looks like that's fixed it [00:34] spiv: it is connecting to the fifos for the newly spawned process [00:34] so 'disk-ish' [00:34] but open() will block until the other process has done the open() [00:35] dOxxx: Cool ! [00:35] That's what O_NONBLOCK is for, but also, why opening an on-disk pipe rather than calling pipe(2) ? [00:35] so if the forking service dies in the middle, (after accepting and returning the path, but before the child process has forked and opened the fifos) then it would hang the Conch process indefinitely [00:35] To share the pipe with a pre-existing process. [00:35] GaryvdM: I'll remove the adhoc executable replacement at the run_app callsites except I think I'll leave the tool menu one alone since it does some extra funky stuff according to tool type [00:36] GaryvdM: and since it will then be passing a executable which is not 'bzr' to run_app, it will just pass through the executable replacement logic I've added [00:36] Hrm.. Sharing ondisk pipes by more than one process each end doesn't sound too healthy; sounds like a recipe for mangled messages due to nonatomic write()s [00:36] the child can't open them before reporting the path, because... it blocks [00:36] jam: but if the forking service dies, the conch process arguably becomes useless [00:36] which is actually a way we get synchronization [00:36] mwhudson: except for whatever processes are currently active, yes [00:37] and if we implement fall-back-to-regular spawn [00:37] LeoNerd: *a* pre-existing process, not multiple :) [00:37] dOxxx: is _do_open_tool == ' tool menu one' [00:37] jam: true [00:37] Ahh [00:37] which I asked spm if that was something we should be doing, but I haven't gotten a response yet [00:37] GaryvdM: yes :) [00:37] Could you pass FDs over a UNIX socket? ;) [00:37] GaryvdM: just looking at it now, I think I might be able to adapt it to work with the modified run_app [00:37] GaryvdM: and still keep it's logic for using qrun [00:37] its* [00:38] LeoNerd: one bound to the filesystem? ;) [00:38] Sure [00:38] You can bind a UNIX socket to filesystem, then pass FDs across it [00:38] dOxxx: Yes, it's not that funky. [00:38] I'm surprised to this day there isn't a standard Linux service to do that anyway, so that e.g. ping could get an ICMP raw socket without having to bet setuid root... But now that's a complete tangent ;) [00:38] using sendmsg, right [00:39] jam: yeah sorry; I'm not too good at 3am replies :-P [00:41] GaryvdM: funky logic preserved :) [00:42] LeoNerd: sysadmins around the world would curse you when they couldn't ping anything because their socketserver wasn't running :-) [00:42] maxb: Admins around the world already curse that the LVM2 userland tools aren't in the initrd so they can't mount their rootfs on boot, or 10,000 other sorts of weird interdependencies anyway [00:43] Personally I'd love not having to start a bunch of services as root just so they can bind() a port, thne drop privs. [00:43] E.g. apache could run -as- wwwdata and obtain a port80 socket from the socketserver [00:43] spm: lazy, lazy man :) [00:44] something ilke that [00:44] spm: I assumed you were in another time zone, just mentioning that it was a question in the queue, good to see you around, btw [00:44] heh [00:44] and thanks for participating in the discussion [00:45] fwiw, we can use the makefile. i think some of the soyuz services start that way. generally the twisted stuff is "funky" so we have to control it betterer [00:46] generally, you tell us "here guys, do THIS to make it go" and we'll make it happen [00:46] monitoring and alerts is a fun topic. [00:47] mwhudson: now make lint (cleaner) [00:47] jam: great [00:47] Gist is: if you *need* a human to DO X to make it happy again; that's an alert state; if it's more "you should know about this" that's not. It may be a warning state; but oervwhelming us with essentially noise alerts is not a good thing™ [00:48] jam: the stuff in _sendMessageToService can definitely be done in a more twisted way [00:48] mwhudson: it can, but in the end you want to block before returning.... [00:48] yeah [00:49] that, and conch's interference makes me think we should be optimistic and assume the blocking won't be for very long [00:49] spm: well, there is a "functionality fallback activated, running at half-speed" alert that needs a human to fix it, and there is "fully dead" [00:49] if you don't distinguish them [00:49] then I won't bother trying to set it up :) [00:50] ha. no that's actually useful in a "this is broken (AAAA); but it's broken here vs totally" separation [00:51] spm: for a specific example, if the new service dies, we could fall back to the old code and it would be slower but working. But I don't want that state to remain for long, but "let the sysadmin do it when he wakes up" would most likely be fine [00:51] eg. if lpnet4 dies; that's bad; but we have lpnet1-15; so in the list of priority AAA's; lpnet4 being dead can be dropped in priority to focus on something more critical. [00:51] LeoNerd: i agree about lvm2; in fact last time i tried a boot cd it wasn't there either [00:51] jam: do you mean dies, as in we'd manually flip back to an older revno? or some smarts in the code? [00:52] you seem to be impling code, but to be clear? [00:52] i guess it depends where and how it dies [00:52] spm: currently both code paths exist, as part of a "feature flag rollout" [00:52] Oh I see! [00:53] mwhudson: :-) [00:53] if the conch machine can't connect to the forking service, it could switch code [00:54] jam: heh, interesting: Under Linux, opening a FIFO for read and write will succeed both in blocking and non-blocking mode. POSIX leaves this behavior undefined. This can be used to open a FIFO for writing while there are no readers available. [00:55] mwhudson: not in my testing [00:55] at least the python one raises EAGAIN [00:55] oh really? [00:55] boo [00:55] I can open for *reading* with O_NBLOCK and it succeeds (but sets the descriptor to non-blocking mode) [00:55] writing will fail right away [00:56] bah [00:56] LeoNerd: sounds a bit like authbind, although I don't known which mechanism that actually uses. [00:56] it's somewhat crazy that there are (lots and lots of) syscalls that block that don't take timeouts [00:56] I did spend a fair amount of time getting a handle on the various bits of this service in order to get it to work [00:57] jam: yeah, if i'm implying otherwise [00:57] mwhudson: write(fd, 100MB) will block [00:57] that certainly surprised me [00:57] (I think I was testing with 1GB or so, and you can't even kill it, at least not with ^C) [00:58] jam: if fd is a pipe and the pipe buffer is full right? [00:58] mwhudson: I'm not sure about with pipes for that one. that was for disk io [00:58] quick question - I'm looking for the bzr equivalent to hg's "outgoing" and "incoming" commands, which tell you what changes would be pushed or pulled to/from another repo. Is there such a beast? [00:58] but yes, write() to a pipe when the pipe is full will block, too [00:59] mmclark: 'bzr missing' [01:00] spm: so how would we tell nagios about the difference? [01:00] spiv: thanks much [01:00] or how could I make that information available to you so you can do whatever you want with it [01:01] jam: did you consider doing the 'pass fds over the socket' trick? [01:02] mwhudson: the most recent change was switching from a port socket to an AF_UNIX one, and you can't do the socket trick until then [01:02] I'm not 100% sure what that would actually gain you [01:02] well, it would get you away from having a potentially blocking open [01:03] mwhudson: I honestly think the hole is pretty small here. If we find it is serious, then we can do something about it. [01:03] remember that the service has to be running successfully until the exact point and then fail [01:03] It leaves the FS a little tidier ;) [01:03] which is possible [01:04] jam: right [01:04] jam: i think you should land the branch as is [01:04] spiv: the fs stays tidy all the time, I delete everything fairly persistently (killing the master process and not connecting to the child you requested can trigger it, I guess) [01:04] and then if we need to improve we can [01:05] mwhudson: well, I *do* need some help landing it, too [01:05] jam: oh ok [01:05] jam: grab nagios-plugins* as a how did they do it starter; the gist is "we" predetermine that THIS is OK, THAT is WARN and everything else is CRITICAL. kinda thing. sometimes we want to adjust params. so eg, 0.5 secs was ok, but is now warn, and we crit on 0.1 sec response times. [01:05] jam: "delete quickly" is still inferior to "never put on FS" [01:06] spiv: I thought the point in *nix was that everything was linked into the fs as a namespace [01:06] I mean otherwise, what is up with /proc and /dev [01:06] :) [01:08] jam: those at least tidy themselves ;) [01:08] spiv: so does /tmp if you enable temp reaper, or let the master forker do it :) [01:09] spm: are you someone who can make it so that when I create branches of lp-production-configs they are private? [01:10] spm: and is nagios-plugins private as well? [01:11] jam: they should private by default (lp-prod-configs) and nagios-plugins is the default ubuntu packages [01:12] spm: they *should* but going to "code.edge.launchpad.net/lp-production-configs" tells me that by default the branches will be public [01:13] gawd I hope not. [01:13] for mwhudson I think it says private [01:13] for *me* it said public [01:13] yep [01:13] still does [01:13] (I can screen shot it for you if you like) [01:14] i'm surprised it's not a private only policy [01:14] in which case you wouldn't be allowed to make branches [01:14] mwhudson: which would at least be better [01:14] he's been manually subscribed. ?? [01:14] spm: to trunk? yes [01:14] spm: I was manually subscribed to trunk [01:15] I at least had the forethought to wonder, and mwh showed me where to look [01:15] jam: so to be clear, you'd like me to throw https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 at ec2 land? [01:15] yeah. everyone else picks it up via ~launchpad [01:15] although i guess pqm is closing [01:15] mwhudson: well "lp:~jameinel/launchpad/lp-service", and make sure it is targetting db-devel, but yes, please [01:15] jam: ok, i think we'll have to wait until after the rollout [01:16] *sigh* since I was trying to get it in before... [01:16] (yay things getting in the way of development!) [01:16] but at least we could land it into 'devel' at that point [01:16] jam: sorry [01:16] i think we want at least a few weeks of battering it on staging [01:16] that's fine, but then again, that is what I was shooting for. [01:16] (though i'm not going to apologise too much, it's not like i'm in launchpad-code any more...) [01:16] the flag should make it safe enough to deploy whenever [01:16] right [01:21] ok i'm going to try to set up a hottest100 bot [01:22] on a web page, that is, not here [01:22] poolie: if I didn't know better, I would be really concerned [01:23] that certainly *sounds* naughty [01:23] :) [01:25] jam: in .au thats a collection of songs each year ;) [01:49] Looks like librsync can handle 25G binary diffs without eating all available memory. Maybe we should look at using it for very large files? [01:54] GaryvdM: thanks for the branch :-) [01:54] jbowtie: heh, I expect poolie knows a bit about librsync ;) [01:54] mwhudson: :-) [01:54] jbowtie: that could be very good, i'd be happy to see about that [01:54] ah [01:55] there's no pure-python version but we could cope without that [01:55] it might also make committing new versions faster [01:55] it may compress less well than groupcompress... maybe... [01:55] a naive use might be worse [01:56] poolie: I'd guess it's at least partly "it depends"... [02:04] poolie: I think it should definitely be considered for anything over, say, 250MB - that's where we start potentially breaking. [02:06] it would be interesting to try a new repo format that way [02:06] And is compression really an issue? Usually very large binaries are already compressed as far as they can go. [02:06] the other alternative is to just store them loose or gzipped [02:06] well, there is that [02:06] but the question is, do these things change (a) basically never; (b) totally, with no similarity from one to the next or (c) incrementally [02:07] if the first, you might as well store them unpacked [02:07] and the second for that matter true [02:07] b is likely to be true if they're already binary-compressed [02:07] but isos or large databases are likely to be like c [02:07] and there you do want delta compression [02:07] Generally if they're in version control it's because you expect c. [02:08] istm that in principle you could groupcompress c [02:08] and the limits are in code, not the format or the basic design [02:08] but perhaps not [02:09] I don't know about b, there are a few fair compression formats that do most of the changes at the end of the file. [02:11] I'm looking at, say, game development, where all the art assets are massive binary files. And you want to diff and merge those alongside the code. [02:11] Right now you can't even check them in because you break the repository. [02:12] And the memory usage for, say, merging looks totally unrealistic. [02:13] You can kind of sidestep it for diff/merge if you dump to the filesystem, but commit ATM requires you to read in the entire file. [02:31] hm, but it really shouldn't [02:31] those apis are designed to deal with iterators of chunks [02:31] obviously this is not being perfectly followed at the moment, but it should be a matter of adjusting them, not huge changes [02:35] i'm off to get some lunch, biab [03:24] I upgraded to Ubuntu 10.10 and bzr gcommit fails to commit now: http://paste.pocoo.org/show/272521/ [03:25] Is there anything I can do? [03:27] vadi2: hmm [03:27] vadi2: that paste only shows warnings [03:27] What else happens, i.e. how does it fail? [03:27] It gives me a dialog of "Unknown error" when I try to press Commit [03:28] So the commit action fails. It doesn't crash or anything, dialog is still there, but the button is non-funtional [03:29] Hmm. [03:33] vadi2: using 0.99.0-1ubuntu1 of bzr-gtk? [03:33] uh huh [03:33] Installed: 0.99.0-1ubuntu1 [03:36] I can't reproduce here with bzr-gtk 0.99.0 and latest bzr 2.2 (I have bzr installed from the PPA, so I can't easily install that bzr-gtk package...) [03:37] I don't get the warning, and the commit Just Works. [03:37] Are there any tracebacks or other hints in ~/.bzr.log? [03:38] Does 'bzr --version' and 'bzr plugins -v' report what you expect for bzr and bzr-gtk? (i.e. right versions, and using the system-wide installs?) [03:40] that file is big [03:41] no particular errors related to this time though [03:41] http://paste.pocoo.org/show/272558/ [03:41] Both versions correspond to package versions [03:44] Thanks for the screencast [03:45] Hmm, I have a theory, I'll just test it. [03:45] Alright [03:47] Ok, got it. [03:47] Run 'bzr whoami' in the terminal [03:48] You haven't told bzr who you are, so it can't commit because it has no committer name to record in the commit. [03:48] I did do launchpad-login! [03:48] And so bzr raises an error, and bzr-gtk tries to display that error [03:49] But because the error includes something that looks a bit like gtk-specific markup it breaks. [03:49] Thanks, it worked now. I guess that could be polished. [03:49] So the warnings were relevant. [03:49] Yes, definitely. [03:49] I'll file two bugs [03:49] Thanks for your help [03:49] One on bzr-gtk's handling of this error [03:49] RIght [03:50] And another about the "I did do launchpad-login!" aspect: you had reason to expect that this was already sorted, and so we should clearly do better there [03:50] The other about whoami to be auto-set from launchpad-login if whoami isn't set yet? [03:50] Right [03:50] Well, auto-setting *might* be hard [03:50] It could in principle use your name + email address as set in Launcphad [03:51] Yeah [03:51] But I couldn't say off the top of my head if there's any impediments with the LP API [03:51] And it probably shouldn't auto-set if you've already set it manually [03:51] Of course. [03:51] ...but maybe it should warn if the LP info doesn't match the manual? [03:51] etc :) [03:52] So a few issues to think about to make it fully polished, but in principle it's a good idea and straightforward :) [03:52] Thanks very much for the report [03:53] Sure, and thanks again for helping. See you later [03:56] New sphinx template nearly ready -- http://imgur.com/kmLGQ.png [03:56] Just need to adjust the top navigation a bit and place the search box correctly. [04:13] jbowtie: looks nice, although it looks completely different to the main website. [04:14] spiv: In theory it will line up with the main website overhaul. [04:14] spiv: It will of course live in a branch until that lands. [04:15] *nod* [04:16] Right now I'm just basing it off the Ubuntu branding guidelines, colors will ahve to be adjusted to whatever we actually end up using. [04:28] * spiv -> lunch === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [04:50] * poolie is going to fix the failures in his scriptrunner branch === Ursinha is now known as Ursinha-afk [05:42] does anyone here at the moment have experience with the trac plugin? [06:32] spiv, still here? [06:35] can anyone spot why https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/35386 would cause a failure in test_delta? [06:35] it seems totally unaffected [06:36] * spiv looks [06:37] it seems like i must be mutating some global state but i really can't spot what it would be [06:37] it doesn't fail when only the affected tests are run alone [06:38] poolie: wow, must be something obscure [06:38] pastebin the failure? [06:38] then you're not going to find the problem without some bisection (at least that's how I found the isolation problems myself) [06:38] * vila not there yet :) [06:39] http://pastebin.ubuntu.com/508536/ [06:39] i just changed it to make that failure more obvious [06:40] so i guess something is making the changereporter give the wrong results [06:47] poolie: is_quiet I think is the likely suspct [06:47] i see it does default to using trace.note and that could easily be staying intercepted when it shouldn't be [06:47] something like that [06:47] poolie: In fact I think it's almost certainly that: [06:47] 1) because the only obvious behaviour change in your patch is to add -q to some calls [06:47] so this test should probably get the results back as lines [06:48] and 2) because bzrlib.trace._verbosity_level is a global [06:48] mm i think so too [06:48] oh, and 3) because report checks the global is_quiet() first :) [06:48] vila: no bisection needed :P [06:48] well spotted [06:49] that's a bit gross [06:49] Yeah. [06:49] The bandaid I guess is to make TestCase reset it to some default every time. [06:49] hm, so probably run_bzr should reset verbosity when it's done [06:49] eventually we should get rid of it [06:49] That's probably a good idea too. [06:49] and thereby stop delta relying on it [06:49] +1 for eventually get rid of it [06:56] bug 656694 [06:56] Launchpad bug 656694 in Bazaar "should delete global is_quiet/is_verbose (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/656694 [07:01] so just an overrideAttr on _verbosity_level in TestCase [07:01] poolie: yup [07:01] probably run_bzr should be doing this too [07:01] it shouldn't carry over from one command in a script runner to another [07:01] Right. [07:02] Although probably each run through the run_bzr machinery would set it? [07:04] Yeah, Command.run_argv_aliases always calls trace.set_verbosity_level [07:04] Oh, ew. [07:04] Look at the _verbosity_level_callback in bzrlib/option.py [07:06] The level of quietness/verbosity might carry over between commands. [07:06] exactly, that's what i'm concerned about [07:06] I don't know that we ever treat -vv differently to -v (or -qq vs. -q) [07:06] i don't think so [07:07] some programs do of course but i don't think we ever have [07:07] But if we did, it's a clear problem :) [07:07] Plugins hypothetically could, I guess. [07:07] wow that is a bit of a messy [07:07] *mess [07:07] so, i think we should make sure it's reset after running a command [07:07] then i'll try to land this, then maybe delete it entirely [07:07] Anyway, to be strict, you have to deal with the global in bzrlib.option as well as bzrlib.trace [07:09] yuck [07:14]