On 12/18/13 11:53 AM, Erik Trauschke wrote:
On 12/18/13 11:43 AM, Xiaobo Shen wrote:
This one is almost on its way to put back. Could somebody send more
-------- Original Message --------
Subject: [pkg-discuss] Re: Review request -> 17734557 Bad
error text from pkg update command
Date: Fri, 15 Nov 2013 11:20:23 -0800
From: Xiaobo Shen
On 11/13/13 07:10 AM, Erik Trauschke wrote:
I did some change about the bootenv.py to allow it using
On 11/12/13 04:31 PM, Xiaobo Shen wrote:
On 11/12/13 01:22 PM, Erik Trauschke wrote:
I found that the msg "The running system has not been modified...." is
On 11/12/13 12:48 PM, Tim Foster wrote:
On 11/13/13 09:10 AM, Xiaobo Shen wrote:
On 11/11/13 01:40 PM, Tim Foster wrote:
That's the easiest way to fix the problem, but it's not the
to do it.
I found we might call flush() in exception handling. It works
output is the same as above.
That's much nicer - thanks. I'm happy with the changes as you have
As Bart is fond of saying, "all bugs have friends" - if you have
it could be interesting to have a quick scan through the rest of the
code in the gate to see if there's other places where we might run
the same issue with clients using the ProgressTracker. You don't
to fix them in this wad, but filing bugs against them would be
- if you don't have time, that's ok.
I'm wondering if we should put the flush into src/client.py:error().
The imageplan shouldn't be bothered with correct print-outs of error
messages, this should be the job of the CLI code.
from restore_image call in client/bootenv.py. This msg will be printed
before handling exception msgs in client.py. For instance,
If we press ctr_c, the latest place we need a "\n" is before
be.restore_image() at line 2682 in api.py.
I can add the flush() call at the beginning of this exception handling
and a couple of other ones. Let me
know if it is applicable. Otherwise we need to figure out some other
Ah, yes. This happens because it uses logger directly instead of
ProgressTracker. This looks like a good follow-on bug to fix.
However, seeing that all of bootenv.py uses logging instead of
exceptions and doesn't use ProgressTracker at all this could be a bit
I think in this case we'd have to print a "\n" before the message
since we have no access to the ProgressTracker. I'm also wondering if
we would run into the same issue with all the other logger.error()
calls in this class.
I'm not too familiar with the ProgressTracker but would it be anAfter flush(), The ProgressTracker will set the __need_nl in
to run a flush every time we print messages with error()?
into false. So I did not see a problem, but I can test it for sure.
progress_tracker flush() before
the log msgs are printed out. Let me know what you guys think. Thanks.
I'd think you only want to flush the progress tracker if you are
printing a message. But I'm not sure if that actually matters. And we
only call it if we have a failed install attempt. I just want to make
sure you don't get newlines where they are not intended.
Tested with multiple flush() calles at once. Only one newline is
produced. I think the printengine maintain
a status with a flag "__need_nl" which tells whether we need a new line.
After flush(), the flag is set to false.
So no matter how many flush() calles afterwards, only one newline is
It is set to true only if we use the printengine again. So we do not
need to worry about it in this case.
The default for progress_tracker is None, so just doing
self.progress_tracker = progress_tracker achieves exactly the same thing.
Otherwise I'd be ok with this.
[pkg-discuss] Re: Fwd: Re: Review request -> 17734557 Bad formatting of error text from pkg update command