* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
> > wrote:
> >
> > > On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> > > > On 07/03/2022 11.06,
Hi
On Thu, Mar 10, 2022 at 3:35 PM Daniel P. Berrangé
wrote:
> On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
> > wrote:
> >
> > > On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> > > > On 07/03/
On Thu, Mar 10, 2022 at 03:50:58PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Thu, Mar 10, 2022 at 3:35 PM Daniel P. Berrangé
> wrote:
>
> > On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
> > > wrote:
>
Hi
On Thu, Mar 10, 2022 at 3:35 PM Daniel P. Berrangé
wrote:
>
> Removing either 'assert' or g_assert would be a massive amount of code
> churn, for no real functional benefit.
>
>
Well, a few thousands of lines that are trivially regexp. And we can make
use of git blame ignore-rev (https://mich
On 10/03/2022 12.35, Daniel P. Berrangé wrote:
On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
Hi
On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
wrote:
On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
On 07/03/2022 11.06, Daniel P. Berrangé wrote:
On Mon,
On Thu, Mar 10, 2022 at 03:11:08PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
> wrote:
>
> > On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> > > On 07/03/2022 11.06, Daniel P. Berrangé wrote:
> > > > On Mon, Mar 07, 2022 at 02:51:23
Hi
On Thu, Mar 10, 2022 at 2:56 PM Daniel P. Berrangé
wrote:
> On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> > On 07/03/2022 11.06, Daniel P. Berrangé wrote:
> > > On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
> > > > On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel
On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> On 07/03/2022 11.06, Daniel P. Berrangé wrote:
> > On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
> > > On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel P. Berrangé wrote:
> > > > The QMP commands have a trailing newline, but
On Mon, Mar 07, 2022 at 11:09:37AM +0100, Thomas Huth wrote:
> On 07/03/2022 11.06, Daniel P. Berrangé wrote:
> > On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
> > > On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel P. Berrangé wrote:
> > > > The QMP commands have a trailing newline, but
On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
> On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel P. Berrangé wrote:
> > The QMP commands have a trailing newline, but the response does not.
> > This makes the qtest logs hard to follow as the next QMP command
> > appears in the same line
On 07/03/2022 11.06, Daniel P. Berrangé wrote:
On Mon, Mar 07, 2022 at 02:51:23PM +0800, Peter Xu wrote:
On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel P. Berrangé wrote:
The QMP commands have a trailing newline, but the response does not.
This makes the qtest logs hard to follow as the next
On Wed, Mar 02, 2022 at 05:49:18PM +, Daniel P. Berrangé wrote:
> The QMP commands have a trailing newline, but the response does not.
> This makes the qtest logs hard to follow as the next QMP command
> appears in the same line as the previous QMP response.
>
> Signed-off-by: Daniel P. Berran
The QMP commands have a trailing newline, but the response does not.
This makes the qtest logs hard to follow as the next QMP command
appears in the same line as the previous QMP response.
Signed-off-by: Daniel P. Berrangé
---
tests/qtest/libqtest.c | 3 +++
1 file changed, 3 insertions(+)
diff
13 matches
Mail list logo