Hi all,
Per the Fedora Linux 38 schedule[1] we started a mass rebuild for Fedora Linux 38 on 1. 18, 2023. We did a mass rebuild for Fedora 38 for:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distributio... https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer https://fedoraproject.org/wiki/Changes/GNUToolchainF38
As per the maintainer's request[4] we have skipped all Haskell packages from this rebuild.
The mass rebuild was done in a side tag (f38-rebuild) and moved over to f38. Failures can be seen at https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
20996 builds have been tagged into f38, there are currently 840 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list[2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure[3]
Regards, Tomas Hrcka Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ [4] https://pagure.io/releng/issue/11217 _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jan 23, 2023 at 10:24 AM Tomas Hrcka thrcka@redhat.com wrote:
Hi all,
Per the Fedora Linux 38 schedule[1] we started a mass rebuild for Fedora Linux 38 on 1. 18, 2023. We did a mass rebuild for Fedora 38 for:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distributio... https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer https://fedoraproject.org/wiki/Changes/GNUToolchainF38
As per the maintainer's request[4] we have skipped all Haskell packages from this rebuild.
The mass rebuild was done in a side tag (f38-rebuild) and moved over to f38. Failures can be seen at https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
20996 builds have been tagged into f38, there are currently 840 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list[2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure[3]
Regards, Tomas Hrcka Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ [4] https://pagure.io/releng/issue/11217
Can somebody cancel the bigloo build? It's been running for several days and is obviously off in the weeds. I'll investigate.
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
Rich.
On Mon, 23 Jan 2023 18:44:00 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
this situation usually means the build failed in the "create SRPM from dist-git" phase
Dan
On Mon, Jan 23, 2023 at 07:50:19PM +0100, Dan Horák wrote:
On Mon, 23 Jan 2023 18:44:00 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
this situation usually means the build failed in the "create SRPM from dist-git" phase
Looking at my own packages, e.g. yaksa had a build attempt that seems to hang: https://koji.fedoraproject.org/koji/buildinfo?buildID=2135007
Zbyszek
On Mon, 2023-01-23 at 19:58 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 23, 2023 at 07:50:19PM +0100, Dan Horák wrote:
On Mon, 23 Jan 2023 18:44:00 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
this situation usually means the build failed in the "create SRPM from dist-git" phase
Looking at my own packages, e.g. yaksa had a build attempt that seems to hang: https://koji.fedoraproject.org/koji/buildinfo?buildID=2135007
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Yes, I have canceled all those now.
kevin
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
I must patch sources now? sed -i 's|stdint.h|cstdint|' include/tins/ip_address.h
вт, 24 янв. 2023 г. в 05:52, Kevin Fenzi kevin@scrye.com:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Yes, I have canceled all those now.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
Jakub
On 1/24/23 00:16, Jakub Jelinek wrote:
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
intel-igc j4-dmenu-desktop julia jd jigdo mtxclient openclonk texlive-base tcpflow synergy R-svglite rstudio rssguard rpi-imager rocm-opencl rocksdb qucs parzip root openmsx openlierox openexr openexr2 openms mongo-cxx-driver kakoune
I'm sure there's more, I've probably looked at about 20% of the packaged I'd flagged as needing further analysis. But that might help folks chase these things down.
Jeff
On 24/01/2023 07:28, Jeff Law wrote:
On 1/24/23 00:16, Jakub Jelinek wrote:
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
mapnik was affected as well but I fixed it last night.
Tom
On Tue, Jan 24, 2023 at 08:13:56AM +0000, Tom Hughes via devel wrote:
On 24/01/2023 07:28, Jeff Law wrote:
On 1/24/23 00:16, Jakub Jelinek wrote:
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
mapnik was affected as well but I fixed it last night.
dolfin had the same issue and I fixed it now. Thanks for the hint.
Zbyszek
On Tue, 24 Jan 2023 at 07:29, Jeff Law jeffreyalaw@gmail.com wrote:
On 1/24/23 00:16, Jakub Jelinek wrote:
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
intel-igc j4-dmenu-desktop julia jd jigdo mtxclient openclonk texlive-base tcpflow synergy R-svglite rstudio rssguard rpi-imager rocm-opencl rocksdb qucs parzip root openmsx openlierox openexr openexr2 openms mongo-cxx-driver kakoune
I'm sure there's more, I've probably looked at about 20% of the packaged I'd flagged as needing further analysis. But that might help folks chase these things down.
The header cleanups will continue until morale improves!
The point of these changes is to speed up compilation. Removing unnecessary headers means the compiler has less work to do, so koji builds use less time and less power. The fixed package also becomes more portable and more standard conforming. The <cstdint> header isn't expensive to compile, but what changed is actually that <stdexcept> and <string> are no longer included in so many places, and those were transitively including <cstdint>. Not including <string> where it isn't needed removes thousands of lines of code. Most code seems to remember to include <string> to use std::string, but everybody forgets to include <cstdint> for std::int32_t etc.
Looks like these have that issue and need to include <cstdint>:
widelands warzone2100 uhd usd tcpflow synergy snapper safeint rstudio rocksdb rocm-opencl prusa-slicer plug pingus paraview openms openmsx
I didn't look at any packages starting with the letters A-N so there are probably more.
Similarly, supertuxkart is missing <stdio.h> or <cstdio>.
pdns is missing <stdexcept>
openvdb failed but should work OK now as there's been an updated tbb.
<somewhat_offtopic>
On Tue, Jan 24, 2023 at 7:29 AM Jeff Law jeffreyalaw@gmail.com wrote:
On 1/24/23 00:16, Jakub Jelinek wrote:
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
I am in favor of header cleanups, and moving forward with new(er) gcc versions, but I wonder that if in the future the Fedora gcc change proposal can reference the porting changes rather than referring only to the main gcc docs as an additional heads up (in this case, I skimmed the gcc 13 changes page, but you had to follow yet another link for porting issues to see the library header changes (and I did not go looking there, my bad)).
While it may take me only a minute to recognize the issue when I see the compile failure for a missing header ("and there they go again..."), writing PRs for upstreams and getting those fixes into their release cycle may take somewhat longer (and I prefer not to carry local patches in packages when possible).
Had I seen cstdint I like to think that I would have tried a rebuild with gcc 13 earlier to see what (if any) upstream(s) needed some encouragement for support gcc 13.
Thanks for the consideration.
</somewhat_offtopic>
On 1/24/23 15:52, Gary Buhrmaster wrote:
Had I seen cstdint I like to think that I would have tried a rebuild with gcc 13 earlier to see what (if any) upstream(s) needed some encouragement for support gcc 13.
I actually did stuff like this in the past -- build all of Fedora with the new compiler as early as possible and then proceeded to fix as many of these trivial things as I could.
It was mostly done to keep the noise down in the tester so that the vast majority of the failures were actually compiler issues the team needed to address and to find deeper issues earlier in the cycle.
I've since moved on from Red Hat and don't even worry about any of the significant Fedora platforms anymore (I'm in risc-v land). The mass rebuild testing I did was looking for something completely different, hence I didn't get through analysis of generic build failures as I was focused on a specific issue.
jeff
On Tue, 24 Jan 2023 at 22:53, Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
<somewhat_offtopic>
On Tue, Jan 24, 2023 at 7:29 AM Jeff Law jeffreyalaw@gmail.com wrote:
On 1/24/23 00:16, Jakub Jelinek wrote:
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
I've got a partial list of packages affected by the ongoing header cleanups in libstdc++:
I am in favor of header cleanups, and moving forward with new(er) gcc versions, but I wonder that if in the future the Fedora gcc change proposal can reference the porting changes rather than referring only to the main gcc docs as an additional heads up (in this case, I skimmed the gcc 13 changes page, but you had to follow yet another link for porting issues to see the library header changes (and I did not go looking there, my bad)).
I think linking to that page would be a good idea. My only reservation is that a lot of the content of that page gets written *after* we do a mass rebuild with the new gcc, because that is when we find which changes cause the biggest porting headaches. When the change proposal gets written the porting-to page isn't very well populated. But we could still link to it, even if it's not very useful until closer to the mass rebuild.
While it may take me only a minute to recognize the issue when I see the compile failure for a missing header ("and there they go again..."), writing PRs for upstreams and getting those fixes into their release cycle may take somewhat longer (and I prefer not to carry local patches in packages when possible).
Had I seen cstdint I like to think that I would have tried a rebuild with gcc 13 earlier to see what (if any) upstream(s) needed some encouragement for support gcc 13.
Well if it would encourage people to try the new GCC earlier, we should definitely link to that page in the change proposal :-)
Il 24/01/23 08:16, Jakub Jelinek ha scritto:
On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included <cstdint> in older versions as an implementation detail but no longer do.
Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include <cstdint>.
Jakub
I think rawtherapee is FTB for this as well:
/builddir/build/BUILD/rawtherapee-5.9/rtengine/dcraw.h:187:13: error: 'uint32_t' does not name a type
and
/builddir/build/BUILD/rawtherapee-5.9/rtengine/dcraw.h:24:1: note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
Should I patch dcraw.h to have '#include <cstdint>'?
Mattia
On Tue, 24 Jan 2023 at 07:01, Vascom vascom2@gmail.com wrote:
I have some packages failed. One of them libtins. Problem is that:
error: 'uint32_t' is not a member of 'std';
Is it normal? Is it GCC 13 change?
I must patch sources now? sed -i 's|stdint.h|cstdint|' include/tins/ip_address.h
std::uint32_t is defined in <cstdint>. If the sources don't include that header, that is a bug.
This is the same thing we have mass rebuild: C and C++ code must include the headers for the features it uses.
If you get an error saying something is not declared, make sure the right header is included.
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Yes, I have canceled all those now.
I started builds for all of those now.
Zbyszek
On Tue, Jan 24, 2023 at 09:42:10AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Yes, I have canceled all those now.
I started builds for all of those now.
All of them have hung again after running since you started them.
I think someone is going to need to try and build them in local mock and see where they are getting stuck.
Can you cancel them again? Or would you like me to try and look and see what they are hung on?
kevin
On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:
On Tue, Jan 24, 2023 at 09:42:10AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1ff)
Yes, I have canceled all those now.
I started builds for all of those now.
All of them have hung again after running since you started them.
I think someone is going to need to try and build them in local mock and see where they are getting stuck.
Can you cancel them again? Or would you like me to try and look and see what they are hung on?
I cancelled them now. All five were still hung. It's up to the maintainers to figure out what is going. E.g. yaksa was hanging in tests…
Zbyszek
On Tue, 2023-01-31 at 12:03 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:
On Tue, Jan 24, 2023 at 09:42:10AM +0000, Zbigniew Jędrzejewski- Szmek wrote:
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1f f)
Yes, I have canceled all those now.
I started builds for all of those now.
All of them have hung again after running since you started them.
I think someone is going to need to try and build them in local mock and see where they are getting stuck.
Can you cancel them again? Or would you like me to try and look and see what they are hung on?
I cancelled them now. All five were still hung. It's up to the maintainers to figure out what is going. E.g. yaksa was hanging in tests…
Any news about these packages that hang on koji ? we may include opencv package on this list.
Last lines of build opencv on ppc64le are [1] and after we got 55385703 (55 millions) of lines with "mashing detected" message, the log file have 2,30G !
Also I see "buffer overflow detected ***: terminated cat: /symlink2- fakechroot: No such file or directory " on fakechroot
Best regards,
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=97209133
/usr/include/c++/13/bits/stl_vector.h:1142: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](size_type) const [with _Tp = float; _Alloc = std::allocator<float>; const_reference = const float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 08 Feb 2023 15:24:47 +0000 Sérgio Basto sergio@serjux.com wrote:
On Tue, 2023-01-31 at 12:03 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:
On Tue, Jan 24, 2023 at 09:42:10AM +0000, Zbigniew Jędrzejewski- Szmek wrote:
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote:
I found more 5 with https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&...
96481236 build (f38-rebuild, /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa)
96474133 build (f38-rebuild, /rpms/trace- cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080)
96404064 build (f38-rebuild, /rpms/perl- SDL.git:347cf3fb5ac90e14b96381722bc335744077e967)
96383273 build (f38-rebuild, /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d
96368979 build (f38-rebuild, /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1f f)
Yes, I have canceled all those now.
I started builds for all of those now.
All of them have hung again after running since you started them.
I think someone is going to need to try and build them in local mock and see where they are getting stuck.
Can you cancel them again? Or would you like me to try and look and see what they are hung on?
I cancelled them now. All five were still hung. It's up to the maintainers to figure out what is going. E.g. yaksa was hanging in tests…
Any news about these packages that hang on koji ? we may include opencv package on this list.
Last lines of build opencv on ppc64le are [1] and after we got 55385703 (55 millions) of lines with "mashing detected" message, the log file have 2,30G !
Also I see "buffer overflow detected ***: terminated cat: /symlink2- fakechroot: No such file or directory " on fakechroot
this looks weird, I am trying a local build
Dan
Best regards,
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=97209133
/usr/include/c++/13/bits/stl_vector.h:1142: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](size_type) const [with _Tp = float; _Alloc = std::allocator<float>; const_reference = const float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** longjmp causes uninitialized stack frame ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated *** stack smashing detected ***: terminated
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Sérgio M. B. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 8 Feb 2023 17:37:09 +0100 Dan Horák dan@danny.cz wrote:
On Wed, 08 Feb 2023 15:24:47 +0000 Sérgio Basto sergio@serjux.com wrote:
On Tue, 2023-01-31 at 12:03 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 30, 2023 at 04:45:37PM -0800, Kevin Fenzi wrote:
On Tue, Jan 24, 2023 at 09:42:10AM +0000, Zbigniew Jędrzejewski- Szmek wrote:
On Mon, Jan 23, 2023 at 06:52:30PM -0800, Kevin Fenzi wrote:
On Mon, Jan 23, 2023 at 10:26:18PM +0000, Sérgio Basto wrote: > > I found more 5 with > https://koji.fedoraproject.org/koji/tasks?owner=releng&state=active&... > > 96481236 build (f38-rebuild, > /rpms/yaksa.git:528d57e3c954abfedba6f530f5ac09abaa9170fa) > > 96474133 build (f38-rebuild, /rpms/trace- > cmd.git:d9631ac81ad4f30b7ca5ed8a7d3b57131c545080) > > 96404064 build (f38-rebuild, /rpms/perl- > SDL.git:347cf3fb5ac90e14b96381722bc335744077e967) > > 96383273 build (f38-rebuild, > /rpms/octave.git:93e5fb4a813805c66ec7107da26be2d52039106d > > 96368979 build (f38-rebuild, > /rpms/libtracecmd.git:121d11cfd26c3a0d61671b83f32b0be1ec75f1f > f)
Yes, I have canceled all those now.
I started builds for all of those now.
All of them have hung again after running since you started them.
I think someone is going to need to try and build them in local mock and see where they are getting stuck.
Can you cancel them again? Or would you like me to try and look and see what they are hung on?
I cancelled them now. All five were still hung. It's up to the maintainers to figure out what is going. E.g. yaksa was hanging in tests…
Any news about these packages that hang on koji ? we may include opencv package on this list.
Last lines of build opencv on ppc64le are [1] and after we got 55385703 (55 millions) of lines with "mashing detected" message, the log file have 2,30G !
Also I see "buffer overflow detected ***: terminated cat: /symlink2- fakechroot: No such file or directory " on fakechroot
this looks weird, I am trying a local build
and they confirm the observation from koji, both a small and a big machine produce tons of the error messages, but the build itself finishes successfully. I will keep looking further.
Dan
On Mon, Jan 23, 2023 at 07:50:19PM +0100, Dan Horák wrote:
On Mon, 23 Jan 2023 18:44:00 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
this situation usually means the build failed in the "create SRPM from dist-git" phase
Got it, thanks.
I updated it to the latest version and submitted a build and indeed the buildroot can't be built:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96590546
The error is some Python / dbus / glib2 / gnutls dependency failure which makes no sense because the package is using none of those.
Rich.
On Mon, Jan 23, 2023 at 08:09:24PM +0000, Richard W.M. Jones wrote:
On Mon, Jan 23, 2023 at 07:50:19PM +0100, Dan Horák wrote:
On Mon, 23 Jan 2023 18:44:00 +0000 "Richard W.M. Jones" rjones@redhat.com wrote:
On Mon, Jan 23, 2023 at 05:44:16PM +0100, Tomas Hrcka wrote:
Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html
What is the significance of packages that appear on this list?
ocaml-mysql appears there, and it does not look like a rebuild was attempted: https://koji.fedoraproject.org/koji/packageinfo?packageID=ocaml-mysql
this situation usually means the build failed in the "create SRPM from dist-git" phase
Got it, thanks.
I updated it to the latest version and submitted a build and indeed the buildroot can't be built:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96590546
The error is some Python / dbus / glib2 / gnutls dependency failure which makes no sense because the package is using none of those.
I just saw Kevin's reply elsewhere in the thread. I will try again a bit later.
Rich.
I wanted to resubmit one of my failed builds, but the buildroot seems to be broken currently:
Problem 1: package python3-dnf-4.14.0-2.fc38.noarch requires libmodulemd >= 2.9.3, but none of the providers can be installed
- package libmodulemd-2.14.0-5.fc38.x86_64 requires libglib-2.0.so.0()(64bit), but none of the providers can be installed
- package libmodulemd-2.14.0-5.fc38.x86_64 requires libgobject-2.0.so.0()(64bit), but none of the providers can be installed
- package dnf-4.14.0-2.fc38.noarch requires python3-dnf = 4.14.0-2.fc38, but none of the providers can be installed
- package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libunistring.so.2()(64bit) needed by gnutls-3.7.8-11.fc38.x86_64
Problem 2: package python3-dnf-plugins-core-4.3.1-2.fc38.noarch requires python3-dbus, but none of the providers can be installed
- package python3-dbus-1.3.2-2.fc38.x86_64 requires libglib-2.0.so.0()(64bit), but none of the providers can be installed
- package dnf-plugins-core-4.3.1-2.fc38.noarch requires python3-dnf-plugins-core = 4.3.1-2.fc38, but none of the providers can be installed
- package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libunistring.so.2()(64bit) needed by gnutls-3.7.8-11.fc38.x86_64
A.FI.
I'm seeing the same errors on rawhide buildroot right now.
On Mon, Jan 23, 2023 at 1:34 PM Artur Frenszek-Iwicki < suve@fedoraproject.org> wrote:
I wanted to resubmit one of my failed builds, but the buildroot seems to be broken currently:
Problem 1: package python3-dnf-4.14.0-2.fc38.noarch requires libmodulemd = 2.9.3, but none of the providers can be installed
- package libmodulemd-2.14.0-5.fc38.x86_64 requires
libglib-2.0.so.0()(64bit), but none of the providers can be installed
- package libmodulemd-2.14.0-5.fc38.x86_64 requires
libgobject-2.0.so.0()(64bit), but none of the providers can be installed
- package dnf-4.14.0-2.fc38.noarch requires python3-dnf =
4.14.0-2.fc38, but none of the providers can be installed
- package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit),
but none of the providers can be installed
- conflicting requests
- nothing provides libunistring.so.2()(64bit) needed by
gnutls-3.7.8-11.fc38.x86_64
Problem 2: package python3-dnf-plugins-core-4.3.1-2.fc38.noarch requires
python3-dbus, but none of the providers can be installed
- package python3-dbus-1.3.2-2.fc38.x86_64 requires
libglib-2.0.so.0()(64bit), but none of the providers can be installed
- package dnf-plugins-core-4.3.1-2.fc38.noarch requires
python3-dnf-plugins-core = 4.3.1-2.fc38, but none of the providers can be installed
- package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit),
but none of the providers can be installed
- conflicting requests
- nothing provides libunistring.so.2()(64bit) needed by
gnutls-3.7.8-11.fc38.x86_64
A.FI. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jan 23, 2023 at 01:36:10PM -0600, Jonathan Wright via devel wrote:
I'm seeing the same errors on rawhide buildroot right now.
The problem was libunistring-1.1-3.fc38 (again).
We untagged it in december, but looks like no one followed up to get dependent packages rebuilt:
https://pagure.io/releng/issue/11175
I have untagged it (again) for now.
kevin
On Mon, Jan 23, 2023 at 8:56 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Jan 23, 2023 at 01:36:10PM -0600, Jonathan Wright via devel wrote:
I'm seeing the same errors on rawhide buildroot right now.
The problem was libunistring-1.1-3.fc38 (again).
We untagged it in december, but looks like no one followed up to get dependent packages rebuilt:
https://pagure.io/releng/issue/11175
I have untagged it (again) for now.
I see that the ELN buildroot is broken in the same way, can you Kevin or Stephen untag the libunistring from ELN?
Tom
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
done.
$ koji list-tagged eln libunistring Build ---------------------------------------- libunistring-1.0-2.eln120 libunistring-1.0-2.fc37
On Tue, Jan 24, 2023 at 11:59 AM Tomáš Popela tpopela@redhat.com wrote:
On Mon, Jan 23, 2023 at 8:56 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Jan 23, 2023 at 01:36:10PM -0600, Jonathan Wright via devel wrote:
I'm seeing the same errors on rawhide buildroot right now.
The problem was libunistring-1.1-3.fc38 (again).
We untagged it in december, but looks like no one followed up to get dependent packages rebuilt:
https://pagure.io/releng/issue/11175
I have untagged it (again) for now.
I see that the ELN buildroot is broken in the same way, can you Kevin or Stephen untag the libunistring from ELN?
Tom
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
hobbes1069 (9): cqrlog - Fails for some weird lazbuild issue I don't understand flnet - Spec conditional oops. Fixed. flrig - Needed cstdint. Fixed freecad - Needs cstdint. Working on it. gmsh - Needed cstdint. Fixed. openCOLLADA - error: possibly dangling reference to a temporary. Don't know how to fix this one. opencascade - error: declaration of 'tbb::task& tbb::internal::task_prefix::task()' changes meaning of 'task' openexr - Needed cstdint. Fixed. spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30
Thanks, Richard
Need help with rebuilding doublecmd.
вт, 24 янв. 2023 г. в 16:21, Richard Shaw hobbes1069@gmail.com:
hobbes1069 (9): cqrlog - Fails for some weird lazbuild issue I don't understand flnet - Spec conditional oops. Fixed. flrig - Needed cstdint. Fixed freecad - Needs cstdint. Working on it. gmsh - Needed cstdint. Fixed. openCOLLADA - error: possibly dangling reference to a temporary. Don't know how to fix this one. opencascade - error: declaration of 'tbb::task& tbb::internal::task_prefix::task()' changes meaning of 'task' openexr - Needed cstdint. Fixed. spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30
Thanks, Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
cqrlog - Fails for some weird lazbuild issue I don't understand
This is most likely my fault, since Lazarus seems to be quite tightly coupled to specific FPC versions. Historically, whenever we updated/rebuilt FPC, we'd also rebuilt Lazarus. This time, when I rebuilt FPC as part of the repackaging change [1], I completely forgot about rebuilding Lazarus as well.
Since Lazarus eventually got rebuilt as part of the Mass Rebuild, I expect that once lazarus-2.2.4-2.fc38 becomes available in the rawhide buildroot, it should be possible to just re-submit the failed builds and they'll work this time.
Sorry about the mess. A.FI.
[1] https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging
On Tue, Jan 24, 2023 at 7:20 AM Richard Shaw hobbes1069@gmail.com wrote:
hobbes1069 (9): cqrlog - Fails for some weird lazbuild issue I don't understand flnet - Spec conditional oops. Fixed. flrig - Needed cstdint. Fixed freecad - Needs cstdint. Working on it. gmsh - Needed cstdint. Fixed. openCOLLADA - error: possibly dangling reference to a temporary. Don't know how to fix this one. opencascade - error: declaration of 'tbb::task& tbb::internal::task_prefix::task()' changes meaning of 'task' openexr - Needed cstdint. Fixed. spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30
I think I've gotten everything situated except openCOLLADA.
Thanks, Richard
On Tue, Jan 24, 2023 at 02:01:39PM -0600, Richard Shaw wrote:
On Tue, Jan 24, 2023 at 7:20 AM Richard Shaw hobbes1069@gmail.com wrote:
hobbes1069 (9): cqrlog - Fails for some weird lazbuild issue I don't understand flnet - Spec conditional oops. Fixed. flrig - Needed cstdint. Fixed freecad - Needs cstdint. Working on it. gmsh - Needed cstdint. Fixed. openCOLLADA - error: possibly dangling reference to a temporary. Don't know how to fix this one. opencascade - error: declaration of 'tbb::task& tbb::internal::task_prefix::task()' changes meaning of 'task' openexr - Needed cstdint. Fixed. spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30
I think I've gotten everything situated except openCOLLADA.
See https://gcc.gnu.org/PR107532 and https://gcc.gnu.org/pipermail/gcc-patches/2023-January/thread.html#610188 It is a new warning, which has some false positives and some further work is being done on that, but whether openCOLLADA triggers a false positive or has a real bug is something that somebody needs to analyze. E.g. -fsanitize=address should diagnose similar use after scope bugs at runtime. Of course, packages which use -Werror need to be prepared to deal with new warnings at any time.
Jakub
On Mon, Jan 23, 2023 at 6:23 PM Tomas Hrcka thrcka@redhat.com wrote:
The mass rebuild was done in a side tag (f38-rebuild) and moved over to f38. Failures can be seen at https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html
pamix fixed in pamix-1.6-7.fc38.
P
On Mon, Jan 23, 2023 at 7:43 PM Petr Šabata psabata@redhat.com wrote:
On Mon, Jan 23, 2023 at 6:23 PM Tomas Hrcka thrcka@redhat.com wrote:
The mass rebuild was done in a side tag (f38-rebuild) and moved over to f38. Failures can be seen at https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html
FYI:
memkind failure (aarch64) seems to be koji/mock related:
This package was updated and sucessfully built in rawhide and f37 a week ago (01/13)
---8<---
EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M b67a9ff69f3540e9bb559e45f9dafdf5 -D /var/lib/mock/f38-build-40444675-4981555/root -a -u mockbuild --capability=cap_ipc_lock --bind=/tmp/mock-resolv._3nfqeom:/etc/resolv.conf --bind=/dev/btrfs-control --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --noclean --target aarch64 --nodeps /builddir/build/SPECS/memkind.spec\n', 1)] Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py", line 93, in trace result = func(*args, **kw)
--->8---
-- Rafael
On Mon, Jan 23, 2023 at 08:11:03PM -0500, Rafael Aquini wrote:
FYI:
memkind failure (aarch64) seems to be koji/mock related:
This package was updated and sucessfully built in rawhide and f37 a week ago (01/13)
---8<---
EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M b67a9ff69f3540e9bb559e45f9dafdf5 -D /var/lib/mock/f38-build-40444675-4981555/root -a -u mockbuild --capability=cap_ipc_lock --bind=/tmp/mock-resolv._3nfqeom:/etc/resolv.conf --bind=/dev/btrfs-control --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --noclean --target aarch64 --nodeps /builddir/build/SPECS/memkind.spec\n', 1)] Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py", line 93, in trace result = func(*args, **kw)
--->8---
Very odd failure. :(
It looks like it finished linking and then somehow systemd-nspawn crashed, but I don't see in the logs any reason why. :(
I'd say try a scratch build and if that works, just resubmit it?
kevin
On Mon, Jan 23, 2023 at 9:49 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Jan 23, 2023 at 08:11:03PM -0500, Rafael Aquini wrote:
FYI:
memkind failure (aarch64) seems to be koji/mock related:
This package was updated and sucessfully built in rawhide and f37 a week ago (01/13)
---8<---
EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M b67a9ff69f3540e9bb559e45f9dafdf5 -D /var/lib/mock/f38-build-40444675-4981555/root -a -u mockbuild --capability=cap_ipc_lock --bind=/tmp/mock-resolv._3nfqeom:/etc/resolv.conf --bind=/dev/btrfs-control --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --noclean --target aarch64 --nodeps /builddir/build/SPECS/memkind.spec\n', 1)] Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py", line 93, in trace result = func(*args, **kw)
--->8---
Very odd failure. :(
It looks like it finished linking and then somehow systemd-nspawn crashed, but I don't see in the logs any reason why. :(
I'd say try a scratch build and if that works, just resubmit it?
Kevin,
A local mock build helped identifying what seems to be the issue -- that only happens with recent rawhide (as I mentioned, I had the RPM successfully built last week, see [1]):
---8<--- libtool: link: gcc -shared -fPIC -DPIC src/.libs/hbwmalloc.o src/.libs/heap_manager.o src/.libs/memkind.o src/.libs/memkind_arena.o src/.libs/memkind_bitmask.o src/.libs/memkind_capacity.o src/.libs/memkind_dax_kmem.o src/.libs/memkind_default.o src/.libs/memkind_fixed.o src/.libs/memkind_gbtlb.o src/.libs/memkind_hbw.o src/.libs/memkind_hugetlb.o src/.libs/memkind_interleave.o src/.libs/memkind_local.o src/.libs/memkind_log.o src/.libs/memkind_memtier.o src/.libs/memkind_mem_attributes.o src/.libs/memkind_pmem.o src/.libs/memkind_regular.o src/.libs/tbb_wrapper.o -ldl -lrt -ldaxctl jemalloc/lib/libjemalloc_pic.a -lm -lpthread -lnuma -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -mno-omit-leaf-frame-pointer -fstack-protector -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,-z -Wl,relro -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,libmemkind.so.0 -o .libs/libmemkind.so.0.0.1 gcc: fatal error: environment variable 'RPM_ARCH' not defined compilation terminated. make: *** [Makefile:2426: libmemkind.la] Error 1 --->8---
and this seem to be exactly what was reported at https://bugzilla.redhat.com/show_bug.cgi?id=2142119
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2110820
-- Rafael
On 07. 02. 23 15:12, Miro Hrončok wrote:
On 23. 01. 23 17:44, Tomas Hrcka wrote:
FTBFS bugs will be filed shortly.
Is there an estimated date when this will happen?
There is now a ticket with the same question:
https://pagure.io/releng/issue/11295
-
Artur Frenszek-Iwicki -
Dan Horák -
Gary Buhrmaster -
Jakub Jelinek -
Jeff Law -
Jerry James -
Jonathan Wakely -
Jonathan Wright -
Kevin Fenzi -
Mattia Verga -
Miro Hrončok -
Petr Šabata -
Rafael Aquini -
Richard Shaw -
Richard W.M. Jones -
Sérgio Basto -
Tom Hughes -
Tomas Hrcka -
Tomáš Popela -
Vascom -
Zbigniew Jędrzejewski-Szmek