Re: Koji build gets consistently stuck
On Tue, Feb 18, 2020 at 5:40 PM Kevin Fenzi wrote: > I wonder if it's some kind of loop in qt5 headers? > > So, I'd say try and duplicate it in a i686 mock chroot on a x86_64 > machine and see if you can gather enough info for a c++ or qt5 bug. Meanwhile, I've got an mscore build running (https://koji.fedoraproject.org/koji/buildinfo?buildID=1463853) that normally takes about 25 minutes, but has been going on i386 for over 8 hours now. It also is a Qt application. However, when I try the build in mock, what I'm seeing is 4 g++ invocations, with 4 /usr/bin/as invocations as subprocesses, and it is the assembler that doesn't seem to be finishing. I filed a binutils bug about that: https://bugzilla.redhat.com/show_bug.cgi?id=1804431 but maybe I didn't dig deep enough. If I can scrape together a little time tonight, I will try to debug it a bit more. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Koji build gets consistently stuck
On Tue, 18 Feb 2020 at 19:40, Kevin Fenzi wrote: > > So, I'd say try and duplicate it in a i686 mock chroot on a x86_64 > machine and see if you can gather enough info for a c++ or qt5 bug. > > Hope that helps. Thanks Kevin, Strangely, as I was attempting to try out what you suggested I got a "build complete" notification email. I took a glance at the logs to find a possible clue of what happened and I found the following in build.log: --- [100%] Built target muse < 20 hour break (this line is not in the log) > In file included from /usr/include/string.h:495, from /usr/include/qt5/QtCore/qarraydata.h:44, from /usr/include/qt5/QtCore/qbytearray.h:46, from /usr/include/qt5/QtCore/qstring.h:49, from /usr/include/qt5/QtCore/qdir.h:43, from /usr/include/qt5/QtCore/QDir:1, from /builddir/build/BUILD/muse-3.0.2/synti/deicsonze/deicsonzegui.cpp:30: In function 'char* strncpy(char*, const char*, size_t)', inlined from 'void DeicsOnzeGui::setInitSetPath(const QString&)' at /builddir/build/BUILD/muse-3.0.2/synti/deicsonze/deicsonzegui.cpp:2522:10: /usr/include/bits/string_fortified.h:106:34: warning: 'char* __builtin_strncpy(char*, const char*, unsigned int)' specified bound 256 equals destination size [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~ --- Seems to me like a valid warning, however it doesn't explain the delay. Another interesting observation that I forgot to add to the original post was, the scratch build in koji went through fine before I tried the actual build. Maybe your magic touch helped? :) Thanks, Orcan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Koji build gets consistently stuck
On Tue, Feb 18, 2020 at 06:46:05PM -0500, Orcan Ogetbil wrote: > In an effort to update the fluidsynth library version, which comes > with a soname bump, in rawhide (F33) I created a side tag > f33-build-side-19396. All but one dependent packages are rebuilt. The > last dependent is the muse package. > > I tried to rebuild muse in the side tag three times. In all of the > attempts the i686 target build gets stalled at the end of %build. Here > is the latest build, which still ongoing for 18 hours as I'm writing > this email: > https://koji.fedoraproject.org/koji/taskinfo?taskID=41579850 > As a comparison, the slowest builder (s390x) finishes the build in > about 15 minutes. > > How do I debug this? Where to file a ticket? Well, if you just want info on what the builder is stuck on, an infrastructure ticket. Since I am already here: It seems to be using 100% of 1 cpu running: kojibui+ 3203495 99.3 2.4 388244 372724 ? RFeb18 1127:51 /usr/libexec/gcc/i686-redhat-linux/10/cc1plus -quiet -I /builddir/build/BUILD/muse-3.0.2/i686-redhat-linux-gnu/synti/deicsonze | `-rpmbuild,3201583 -bb --target i686 --nodeps /builddir/build/SPECS/muse.spec | `-sh,3201611 -e /var/tmp/rpm-tmp.cEJyaS | `-make,3201975 -j6 | `-make,3201978 -f CMakeFiles/Makefile2 all | `-make,3203442 -f synti/deicsonze/CMakeFiles/deicsonze.dir/build.make ... | `-c++,3203494 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_UITOOLS_LIB .. . | |-cc1plus,3203495 -quiet -I ... | `-as,3203496 -I /builddir/build/BUILD/muse-3.0.2/i686-redhat-linux-gnu/synti/deicso nze -I ... strace of that process doesn't show anything happening. Looking at open files: ... lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 11 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /c++/10/bits/std_function.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 12 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /qt5/QtCore/qmap.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 13 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /qt5/QtCore/qvariant.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 14 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /qt5/QtCore/qset.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 15 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu ild/BUILD/muse-3.0.2/muse/memory.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 16 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu ild/BUILD/muse-3.0.2/muse/evdata.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 17 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu ild/BUILD/muse-3.0.2/muse/mpevent.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 18 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu ild/BUILD/muse-3.0.2/synti/libsimpleplugin/simpler_plugin.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 19 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /qt5/QtWidgets/qstyleoption.h lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 20 -> /var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include /qt5/QtGui/qtextformat.h I wonder if it's some kind of loop in qt5 headers? So, I'd say try and duplicate it in a i686 mock chroot on a x86_64 machine and see if you can gather enough info for a c++ or qt5 bug. Hope that helps. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Koji build gets consistently stuck
In an effort to update the fluidsynth library version, which comes with a soname bump, in rawhide (F33) I created a side tag f33-build-side-19396. All but one dependent packages are rebuilt. The last dependent is the muse package. I tried to rebuild muse in the side tag three times. In all of the attempts the i686 target build gets stalled at the end of %build. Here is the latest build, which still ongoing for 18 hours as I'm writing this email: https://koji.fedoraproject.org/koji/taskinfo?taskID=41579850 As a comparison, the slowest builder (s390x) finishes the build in about 15 minutes. How do I debug this? Where to file a ticket? Thanks, Orcan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
