Re: Annobin: "causes a section type conflict with..."
On 07/07/18 16:21 -0600, Jerry James wrote: On Fri, Jul 6, 2018 at 2:14 PM Jonathan Wakely wrote: I'm seeing this in Boost too, and given my schedule I'm going to abandon the Boost update for f29. Ugh, that's unfortunate. I wonder if we should perhaps postpone the mass rebuild until this issue has been fixed. It would be interesting to know if turning off annobin fixes the boost problem, too. That would lend credence to the idea that annobin has something to do with the issue. I did try that of course. Turning off annobin fixed the section conflict, but building Boost still failed for a different reason (because they've changed the drokking build system again and our solution for building various libs once for python2 and again for python3 stopped working ... again). Since I was on holiday all last week I decided not to spend my weekend fighting with Boost's spugging build system. I had a much nicer holiday as a result. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F6GGXNZ6HHDA3BBWWSTG65L6NDNLPQPM/
Re: Annobin: "causes a section type conflict with..."
On Mon, 9 Jul 2018, Florian Weimer wrote: > > Can the compiler team just merge the bloody plugin sources into the > > gcc source package so that it doesn't randomly break anymore? > > This change would add roughly 18 hours to the delivery of every annobin change > because that's the time required for building gcc. surely this can be conditionalized in the ./configure, and simply fire off a single local checking build instance daily on non-production builder, or if one ** 'needs' ** it every build [I sort of doubt it with the GCC build constellation], 'mock out' and only test the known pain points -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MQ6VPNXR5DQXLUAHJPBCPFFZKDWDKOXZ/
Re: Annobin: "causes a section type conflict with..."
Neal Gompa wrote: > Can the compiler team just merge the bloody plugin sources into the > gcc source package so that it doesn't randomly break anymore? I don't think that doing that is going to solve all the problems with Annobin. I'd rather they just turn this off by default. Annotated builds for analysis can be done in a side tag that never gets delivered to users, or even in a scratch build. I still have not seen any rationale for delivering packages containing annotated binaries to our users. If you want to know whether a package is missing compiler flags, just do a scratch rebuild of the SRPM with annobin enabled and analyze that. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NW33M5VD7VUMDXDCLHZXS7GKKD2SRQF/
Re: Annobin: "causes a section type conflict with..."
On 07/09/2018 02:56 AM, Kevin Kofler wrote: Annobin is causing so many issues, and its main goal of finding packages that were not built with the correct linker flags has already been achieved (bugs have been filed for all of them), so do we really need to keep dragging this thing along all the time? The missing linker flags were detected by something else, not annobin/annocheck (and I filed bugs for only a subset of the affected packages). annobin is about missing *compiler* flags. It's a difficult problem to solve. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QKWMV27HSFDLL6BNUALT62YFCUBIY4Q2/
Re: Annobin: "causes a section type conflict with..."
On Mon, 2018-07-09 at 09:11 +0200, Florian Weimer wrote: > On 07/09/2018 03:33 AM, Neal Gompa wrote: > > Can the compiler team just merge the bloody plugin sources into the > > gcc source package so that it doesn't randomly break anymore? > > This change would add roughly 18 hours to the delivery of every > annobin > change because that's the time required for building gcc. Let us know when "new" gcc is ready . In these cases , just asking , can't we disable %check , as it takes 90% of the time ? > Florian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin > es > List Archives: https://lists.fedoraproject.org/archives/list/devel@li > sts.fedoraproject.org/message/2DXP7WE2TY2Q2ZTW4L5R5WO5UJVKXESB/ -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TPSNY2SW7ZWPWORK53WRDFHGLCRFCQZT/
Re: Annobin: "causes a section type conflict with..."
On 07/09/2018 03:33 AM, Neal Gompa wrote: Can the compiler team just merge the bloody plugin sources into the gcc source package so that it doesn't randomly break anymore? This change would add roughly 18 hours to the delivery of every annobin change because that's the time required for building gcc. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2DXP7WE2TY2Q2ZTW4L5R5WO5UJVKXESB/
Re: Annobin: "causes a section type conflict with..."
On Sun, Jul 8, 2018 at 8:57 PM Kevin Kofler wrote: > > Annobin is causing so many issues, and its main goal of finding packages > that were not built with the correct linker flags has already been achieved > (bugs have been filed for all of them), so do we really need to keep > dragging this thing along all the time? IMHO, it is causing more problems > than it solves and so should be disabled from the default builds. It would > always be possible to enable it in a temporary side tag and do a scratch > mass-rebuild in there if there is a need for it (e.g., to recheck for > missing linker flags at some point). > > Why does this debugging tool have to be enabled by default in our production > builds? > I'm increasingly annoyed by annobin these days. On top of the problems caused by annobin _still_ being a separate source package from gcc and breaking compilation, I'm not even sure what value it even provides. Ordinarily, I'd be going "meh" to changes like this, but now I can't even count on being able to build software in Rawhide anymore, and potentially even in stable releases! Can the compiler team just merge the bloody plugin sources into the gcc source package so that it doesn't randomly break anymore? *grumbles about not having auto-rebuilding+submitting of reverse deps so this wouldn't be a problem anymore...* -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LK54VE2BC3N2NCCGVDUHZGF3CDGLFS2D/
Re: Annobin: "causes a section type conflict with..."
Annobin is causing so many issues, and its main goal of finding packages that were not built with the correct linker flags has already been achieved (bugs have been filed for all of them), so do we really need to keep dragging this thing along all the time? IMHO, it is causing more problems than it solves and so should be disabled from the default builds. It would always be possible to enable it in a temporary side tag and do a scratch mass-rebuild in there if there is a need for it (e.g., to recheck for missing linker flags at some point). Why does this debugging tool have to be enabled by default in our production builds? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TKCJKL3C4SKLZ7RFF7JRKXDNJ4CNOYDK/
Re: Annobin: "causes a section type conflict with..."
On Fri, Jul 6, 2018 at 2:14 PM Jonathan Wakely wrote: > I'm seeing this in Boost too, and given my schedule I'm going to > abandon the Boost update for f29. Ugh, that's unfortunate. I wonder if we should perhaps postpone the mass rebuild until this issue has been fixed. It would be interesting to know if turning off annobin fixes the boost problem, too. That would lend credence to the idea that annobin has something to do with the issue. Another data point: the first time I saw this problem was just after annobin-8.3-1 landed in Rawhide. I see that annobin-8.4-1 is in there now, but another build attempt for openfst with that version still shows the issue. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KVSSMDG7LFSKFFK3OGOO6HJSHPC4GX6P/
Re: Annobin: "causes a section type conflict with..."
On 06/07/18 13:52 -0600, Jerry James wrote: On Thu, Jul 5, 2018 at 4:01 PM Jerry James wrote: This afternoon, I received email from koschei, telling me that polymake's builds have started to fail: Here is another one, with a shorter build time than polymake, for anybody trying to track this down: https://apps.fedoraproject.org/koschei/package/sphinxtrain?collection=f29 It is kind of worrisome that this is happening just a few days before the mass rebuild is set to begin. I'm seeing this in Boost too, and given my schedule I'm going to abandon the Boost update for f29. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BWBNS6Z7Z6QBY33KXIX2GL3WMLEPAMT7/
Re: Annobin: "causes a section type conflict with..."
On Thu, Jul 5, 2018 at 4:01 PM Jerry James wrote: > This afternoon, I received email from koschei, telling me that > polymake's builds have started to fail: Here is another one, with a shorter build time than polymake, for anybody trying to track this down: https://apps.fedoraproject.org/koschei/package/sphinxtrain?collection=f29 It is kind of worrisome that this is happening just a few days before the mass rebuild is set to begin. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4NFZERAE5WXX5I4TQYXBOZZJXC5E7NJB/
Annobin: "causes a section type conflict with..."
This afternoon, I received email from koschei, telling me that
polymake's builds have started to fail:
https://apps.fedoraproject.org/koschei/package/polymake?collection=f29
The failure is due to this:
/builddir/build/BUILD/polymake-3.2/include/core/polymake/internal/shared_object.h:410:9:
error: ‘void pm::shared_object::leave() [with Object
= pm::sparse2d::Table; TParams =
{pm::AliasHandlerTag}]’ causes a section
type conflict with ‘const pm::perl::RegistratorQueue&
polymake::common::get_registrator_queue(polymake::mlist,
std::integral_constant) [with
Tag = polymake::common::GlueRegistratorTag;
pm::perl::RegistratorQueue::Kind kind =
(pm::perl::RegistratorQueue::Kind)1]’
void leave()
^
"Huh," I thought, "that's weird. Well, I'll look into that after I
kick off this mock build of openfst 1.6.8". Then the openfst build
also failed with the same kind of "section type conflict" error.
On a hunch, I added this to openfst.spec and tried again:
%undefine _annotated_build
The mock build succeeded. Did somebody just do something to annobin
today? If so, can you please undo it?
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A637TVN7ZGMRFJ6YSGZL6TCIBEELBW3N/
