Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1187557 > unrolled thread

Bug#1059264: qbs: ftbfs on riscv64: test timeout

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1059264: qbs: ftbfs on riscv64: test timeout Dmitry Shachnev <mitya57@debian.org> - 2024-02-26 10:00 +0100
    Bug#1059264: qbs: ftbfs on riscv64: test timeout Bo YU <tsu.yubo@gmail.com> - 2024-02-29 08:10 +0100
      Bug#1059264: qbs: ftbfs on riscv64: test timeout Bo YU <tsu.yubo@gmail.com> - 2024-03-03 08:20 +0100
        Bug#1059264: qbs: ftbfs on riscv64: test timeout Dmitry Shachnev <mitya57@debian.org> - 2024-03-03 15:50 +0100
          Bug#1059264: qbs: ftbfs on riscv64: test timeout Bo YU <tsu.yubo@gmail.com> - 2024-03-11 09:10 +0100

#1187557 — Bug#1059264: qbs: ftbfs on riscv64: test timeout

[Multipart message — attachments visible in raw view] — view raw

Hi!

On Fri, Dec 22, 2023 at 05:25:52PM +0800, Bo YU wrote:
> Package: qbs
> Version: 1.24.1+dfsg-2
> Severity: important
> Tags: ftbfs patch
> User: debian-riscv@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: debian-riscv@lists.debian.org
> 
> Dear Maintainer,
> 
> qbs has ftbfs on riscv64 since 2.1.1-2(2023/08) on sid. The problem is
> due to timeout on buildd machines for riscv64 now:
>
> [...]
> 
> So we can see the timeout on tst_blackbox-qt suite mainly. But the
> question is that failed test function cases are randomized. So I have
> captured a few cases to temporarily skip over riscv64 buildd(holpe this
> works). And I would like to suggest that we keep opening the reportbug
> until we have more powerful buildd machines to close it as expected
> it. I can build it on vf2 without any patch but it has not been tested
> many times. 
> 
> So could you apply it on next upload or any ideas?

I would prefer increasing the timeout to disabling the test.

The blackbox tests start qbs in a subprocess and wait for it to finish in a
reasonable time [1]. The value of testTimeoutInMsecs() can be configured by
QBS_AUTOTEST_TIMEOUT environment variable, which specifies time in seconds and
is 600 by default, which is 10 minutes.

However, Qt test library has its own timeout: any test function call is
interrupted in 5 minutes [2]. This can be configured by QTEST_FUNCTION_TIMEOUT
variable, which is in milliseconds. It looks like this is the timeout that
occurs in the log fragments you provided.

Do you have any way to check if increasing QTEST_FUNCTION_TIMEOUT helps to
get it built on slow riscv64 machines. And if yes, to what value it should
be increased?

[1]: https://sources.debian.org/src/qbs/2.1.2-2/tests/auto/blackbox/tst_blackboxbase.cpp/#L100
[2]: https://doc.qt.io/qt-6/qtest-overview.html#increasing-test-function-timeout

--
Dmitry Shachnev

[toc] | [next] | [standalone]

#1188337

Hi!

On Mon, Feb 26, 2024 at 4:52 PM Dmitry Shachnev <mitya57@debian.org> wrote:
>
> Hi!
>
> On Fri, Dec 22, 2023 at 05:25:52PM +0800, Bo YU wrote:
> > Package: qbs
> > Version: 1.24.1+dfsg-2
> > Severity: important
> > Tags: ftbfs patch
> > User: debian-riscv@lists.debian.org
> > Usertags: riscv64
> > X-Debbugs-Cc: debian-riscv@lists.debian.org
> >
> > Dear Maintainer,
> >
> > qbs has ftbfs on riscv64 since 2.1.1-2(2023/08) on sid. The problem is
> > due to timeout on buildd machines for riscv64 now:
> >
> > [...]
> >
> > So we can see the timeout on tst_blackbox-qt suite mainly. But the
> > question is that failed test function cases are randomized. So I have
> > captured a few cases to temporarily skip over riscv64 buildd(holpe this
> > works). And I would like to suggest that we keep opening the reportbug
> > until we have more powerful buildd machines to close it as expected
> > it. I can build it on vf2 without any patch but it has not been tested
> > many times.
> >
> > So could you apply it on next upload or any ideas?
>
> I would prefer increasing the timeout to disabling the test.
>
> The blackbox tests start qbs in a subprocess and wait for it to finish in a
> reasonable time [1]. The value of testTimeoutInMsecs() can be configured by
> QBS_AUTOTEST_TIMEOUT environment variable, which specifies time in seconds and
> is 600 by default, which is 10 minutes.
>
> However, Qt test library has its own timeout: any test function call is
> interrupted in 5 minutes [2]. This can be configured by QTEST_FUNCTION_TIMEOUT
> variable, which is in milliseconds. It looks like this is the timeout that
> occurs in the log fragments you provided.
>
> Do you have any way to check if increasing QTEST_FUNCTION_TIMEOUT helps to
> get it built on slow riscv64 machines. And if yes, to what value it should
> be increased?

Thanks for the hint. It seems it works once I enable
QTEST_FUNCTION_TIMEOUT. The value of it I just follow the [2] to set
`900000` milliseconds (15 mins). But I am not sure the value is okay
for you.:)

I do not attend one debdiff file because now I have trouble to build
it on sid-riscv64-sbuild. Once done, I will update it here.

Thnak you,
BR,
Bo
>
> [1]: https://sources.debian.org/src/qbs/2.1.2-2/tests/auto/blackbox/tst_blackboxbase.cpp/#L100
> [2]: https://doc.qt.io/qt-6/qtest-overview.html#increasing-test-function-timeout
>
> --
> Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1188875

[Multipart message — attachments visible in raw view] — view raw

Hi,
On Sat, Mar 02, 2024 at 09:47:08PM +0300, Dmitry Shachnev wrote:
>Hi!
>
>On Thu, Feb 29, 2024 at 02:59:28PM +0800, Bo YU wrote:
>> Thanks for the hint. It seems it works once I enable
>> QTEST_FUNCTION_TIMEOUT. The value of it I just follow the [2] to set
>> `900000` milliseconds (15 mins). But I am not sure the value is okay
>> for you.:)
>
>Well, a test running for 15 minutes is not good, but as I said, it is
>better than disabling it completely.

Thanks. The situation should be improved if we have more power riscv64
buildd, but unfortunately, we have to wait this for time.

>
>> I do not attend one debdiff file because now I have trouble to build
>> it on sid-riscv64-sbuild. Once done, I will update it here.
>
>Looking forward to that.

Due to 2.1.2-2.1 was t64 transition related, so I have to generate
debdiff based on 2.1.2-2. So please let me know if any issue.

I should wait the 64 trsansition to finish but not sure how long it will
to achive this.
>
>--
>Dmitry Shachnev

-- 
Regards,
--
   Bo YU

[toc] | [prev] | [next] | [standalone]

#1188916

[Multipart message — attachments visible in raw view] — view raw

Hi!

On Sun, Mar 03, 2024 at 03:14:58PM +0800, Bo YU wrote:
> Due to 2.1.2-2.1 was t64 transition related, so I have to generate
> debdiff based on 2.1.2-2. So please let me know if any issue.
>
> I should wait the 64 trsansition to finish but not sure how long it will
> to achive this.

Right. I committed the patch so it will be part of the next upload, but
I am not uploading it until the current version migrates to testing.

Also, our debian/rules includes /usr/share/dpkg/default.mk which in turn
includes architecture.mk, so $(DEB_BUILD_ARCH_CPU) is defined and there is
no need to call dpkg-architecture explicitly. I have updated the patch
based on that.

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1189889

Hi!

On Sun, Mar 3, 2024 at 10:43 PM Dmitry Shachnev <mitya57@debian.org> wrote:
...
>
> Right. I committed the patch so it will be part of the next upload, but
> I am not uploading it until the current version migrates to testing.

Thanks.:)
>
> Also, our debian/rules includes /usr/share/dpkg/default.mk which in turn
> includes architecture.mk, so $(DEB_BUILD_ARCH_CPU) is defined and there is
> no need to call dpkg-architecture explicitly. I have updated the patch
> based on that.

Ah, okay, TIL.

BR,
Bo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web