Very strange compiler/linker related build failures in rawhide

[Fabio Valentini]

Hi all,

I'm starting to see various very strange kinds of build failures in
rawhide, that seem to have started with either of these updates (or a
combination of them):

- annobin 9.21-1.fc33 → 9.22-1.fc33
- binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
- elfutils 0.179-2.fc33 → 0.180-2.fc33
- glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33

These rawhide updates all happened at roughly the same time, so it's
difficult to say which one of them is to blame (if any of them).

One error I've seen in libreoffice is a gcc / annobin segfault:

[build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
/builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
destructor 'virtual DemoWin::RenderThread::~RenderThread()':
/builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
internal compiler error: Segmentation fault
 1733 | join();
  |  ^

Other errors look like this one from switchboard-plug-onlineaccounts:

src/libonline-accounts.so.p/Authentification/Server.c: In function
‘online_accounts_server_on_bus_acquired’:
src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
function ‘__errno_location’ is initialized like a variable
  498 |  gint errno = 0;
  |  ^~~~

Where errno is neither __errno_location, nor a function, but a gint??

Other failures I've seen end up with linker failures, line these, from
postgresql:

ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'

Does somebody have a clue what's going on here? It's currently
blocking rawhide composes because libreoffice fails to build /
install.

See also: https://pagure.io/releng/failed-composes/issue/1571

Thanks,
Fabio
___
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: Very strange compiler/linker related build failures in rawhide

[Stephan Bergmann]

On 24/07/2020 10:31, Fabio Valentini wrote:

Other errors look like this one from switchboard-plug-onlineaccounts:

src/libonline-accounts.so.p/Authentification/Server.c: In function
‘online_accounts_server_on_bus_acquired’:
src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
function ‘__errno_location’ is initialized like a variable
   498 |  gint errno = 0;
   |  ^~~~

Where errno is neither __errno_location, nor a function, but a gint??


Note that, depending on what you include, errno may be a macro.


Does somebody have a clue what's going on here? It's currently
blocking rawhide composes because libreoffice fails to build /
install.


(The LibreOffice build failure is tracked at 
 "LibreOffice FTBFS 
with internal compiler error".)

___
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: Very strange compiler/linker related build failures in rawhide

[Fabio Valentini]

On Fri, Jul 24, 2020 at 10:45 AM Stephan Bergmann  wrote:
> > Does somebody have a clue what's going on here? It's currently
> > blocking rawhide composes because libreoffice fails to build /
> > install.
>
> (The LibreOffice build failure is tracked at
>  "LibreOffice FTBFS
> with internal compiler error".)

I am aware, since I've been blamed for this problem for some reason.

Fabio
___
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: Very strange compiler/linker related build failures in rawhide

[Hans de Goede]

Hi,

On 7/24/20 10:31 AM, Fabio Valentini wrote:

Hi all,

I'm starting to see various very strange kinds of build failures in
rawhide, that seem to have started with either of these updates (or a
combination of them):

- annobin 9.21-1.fc33 → 9.22-1.fc33
- binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
- elfutils 0.179-2.fc33 → 0.180-2.fc33
- glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33

These rawhide updates all happened at roughly the same time, so it's
difficult to say which one of them is to blame (if any of them).

One error I've seen in libreoffice is a gcc / annobin segfault:

[build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
/builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
destructor 'virtual DemoWin::RenderThread::~RenderThread()':
/builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
internal compiler error: Segmentation fault
  1733 | join();
   |  ^




I've been hitting something similar with dmraid:

https://koji.fedoraproject.org/koji/getfile?taskID=47692725&volume=DEFAULT&name=build.log&offset=-4000

Are you seeing this on s390x too ?

I was hopening the new gcc build which was started yesterday would fix this,
but that seems to be failing + hanging in its selftests on s390x :|   :

https://koji.fedoraproject.org/koji/getfile?taskID=47682083&volume=DEFAULT&name=build.log&offset=-4000

Regards,

Hans





Other errors look like this one from switchboard-plug-onlineaccounts:

src/libonline-accounts.so.p/Authentification/Server.c: In function
‘online_accounts_server_on_bus_acquired’:
src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
function ‘__errno_location’ is initialized like a variable
   498 |  gint errno = 0;
   |  ^~~~

Where errno is neither __errno_location, nor a function, but a gint??

Other failures I've seen end up with linker failures, line these, from
postgresql:

ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'

Does somebody have a clue what's going on here? It's currently
blocking rawhide composes because libreoffice fails to build /
install.

See also: https://pagure.io/releng/failed-composes/issue/1571

Thanks,
Fabio
___
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


___
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: Very strange compiler/linker related build failures in rawhide

[Fabio Valentini]

On Fri, Jul 24, 2020 at 11:23 AM Hans de Goede  wrote:
>
> Hi,
>
> On 7/24/20 10:31 AM, Fabio Valentini wrote:
> > Hi all,
> >
> > I'm starting to see various very strange kinds of build failures in
> > rawhide, that seem to have started with either of these updates (or a
> > combination of them):
> >
> > - annobin 9.21-1.fc33 → 9.22-1.fc33
> > - binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
> > - elfutils 0.179-2.fc33 → 0.180-2.fc33
> > - glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33
> >
> > These rawhide updates all happened at roughly the same time, so it's
> > difficult to say which one of them is to blame (if any of them).
> >
> > One error I've seen in libreoffice is a gcc / annobin segfault:
> >
> > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > *** WARNING *** there are active plugins, do not report this as a bug
> > unless you can reproduce it without enabling any plugins.
> > Event| Plugins
> > PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> > PLUGIN_START_UNIT| annobin: Generate global annotations
> > PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> > annotations
> > PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
> > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > internal compiler error: Segmentation fault
> >   1733 | join();
> >|  ^
> >
>
>
> I've been hitting something similar with dmraid:
>
> https://koji.fedoraproject.org/koji/getfile?taskID=47692725&volume=DEFAULT&name=build.log&offset=-4000
>
> Are you seeing this on s390x too ?
>
> I was hopening the new gcc build which was started yesterday would fix this,
> but that seems to be failing + hanging in its selftests on s390x :|   :
>
> https://koji.fedoraproject.org/koji/getfile?taskID=47682083&volume=DEFAULT&name=build.log&offset=-4000

Yes, this failure seems to be architecture independent.
For example, libreoffice also fails with the same gcc/annobin segfault
on all architectures ...

Fabio
___
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: Very strange compiler/linker related build failures in rawhide

[Petr Pisar]

On Fri, Jul 24, 2020 at 10:31:11AM +0200, Fabio Valentini wrote:
> Other failures I've seen end up with linker failures, line these, from
> postgresql:
> 
> ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'
>
.

-- Petr


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

Re: Bodhi 5.4.0 in production

[Miro Hrončok]

On 09. 07. 20 21:08, Mattia Verga via devel wrote:

Il 09/07/20 15:12, Miro Hrončok ha scritto:


Finally I got to testing this.

The bugzilla was added to the update:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-c1be13ded8

But it was not closed:

https://bugzilla.redhat.com/show_bug.cgi?id=1851519

Should I report this as a bug or am i doing something wrong? The commit is:

https://src.fedoraproject.org/rpms/python-tox/c/d154cf5aabe445914123b41239243811eeac93b7?branch=master

But the build was done from one clenaup commit above this. Is that relevant?


The feature is not completely working in Bodhi 5.4.0, a fix is ready [1]
and it will be deployed with the next bugfix (probably 5.4.1)

Mattia

[1] https://github.com/fedora-infra/bodhi/pull/4068


It worked this time, thanks!

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Modularity Improvements Objective

[Daniel Mach]

Hello everyone,
There's a Modularity Improvements Objective draft available[1].

The Objective summarizes the work that is in progress already as well as 
highlights our plans for Fedora 34.


We're planning to fix the current modularity in Fedora 33 and 34.
We may look into alternatives or bigger design changes in Fedora 35 and 
later.


You can find more details in the Objective document[1].

- Daniel


[1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
___
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: Modularity Improvements Objective

[Neal Gompa]

On Fri, Jul 24, 2020 at 7:44 AM Daniel Mach  wrote:
>
> Hello everyone,
> There's a Modularity Improvements Objective draft available[1].
>
> The Objective summarizes the work that is in progress already as well as
> highlights our plans for Fedora 34.
>
> We're planning to fix the current modularity in Fedora 33 and 34.
> We may look into alternatives or bigger design changes in Fedora 35 and
> later.
>
> You can find more details in the Objective document[1].
>
> - Daniel
>
>
> [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020

This looks pretty good. I'm excited to see these improvements as they come!


-- 
真実はいつも一つ！/ 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://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: Modularity Improvements Objective

[Petr Pisar]

On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
> There's a Modularity Improvements Objective draft available[1].
> 
> The Objective summarizes the work that is in progress already as well as
> highlights our plans for Fedora 34.
> 
> We're planning to fix the current modularity in Fedora 33 and 34.
> We may look into alternatives or bigger design changes in Fedora 35 and
> later.
> 
> You can find more details in the Objective document[1].
> 
> - Daniel
> 
> [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020

I hope that you find resources to properly maintain MBS. Currently (last two
weeks) it cannot build the modules
.

-- Petr


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

Orphaned perl-Boost-Geometry-Utils, perl-Data-Rmap, perl-Math-Expression-Evaluator

[Miro Hrončok]

Hello, I've orphaned:

perl-Boost-Geometry-Utils
perl-Data-Rmap
perl-Math-Expression-Evaluator

The packages used to be needed by slic3r, but apparently no longer are, they are 
leafs.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: PSA: dnf autoremove cleans fedora-repos-modular

[Miro Hrončok]

On 11. 07. 20 1:59, John M. Harris Jr wrote:

On Friday, July 10, 2020 2:53:30 PM MST Miro Hrončok wrote:

On 10. 07. 20 23:35, John M. Harris Jr wrote:


DNF should perform "dnf mark install fedora-repos-rawhide-modular"
action
on a system upgrade, because we want that package to be prensented on
the system. However I worry that DNF does not possess a capability for
doing it. (Except of injecting that command into some externally
executed
script.)




Can we amend dnf system-upgrade to do this?


Wouldn't that install modular repos on systems that end users have removed
it from? Is there a way around that?



My idea was:

if fedora-repos-modular is installed:
  dnf mark install fedora-repos-modular
else:
  pass


Ah, gotcha. Sounds like a plan.


Since there was no followup, I've created

https://bugzilla.redhat.com/show_bug.cgi?id=1860408

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

perl-Math-Expression-Evaluator license corrected

[Petr Pisar]

perl-Math-Expression-Evaluator license was correted from "GPL+ or Artistic"
to "(GPL+ or Artistic) and Public Domain".

-- Petr


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

Re: Modularity Improvements Objective

[Vít Ondruch]

Dne 24. 07. 20 v 14:25 Petr Pisar napsal(a):
> On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
>> There's a Modularity Improvements Objective draft available[1].
>>
>> The Objective summarizes the work that is in progress already as well as
>> highlights our plans for Fedora 34.
>>
>> We're planning to fix the current modularity in Fedora 33 and 34.
>> We may look into alternatives or bigger design changes in Fedora 35 and
>> later.
>>
>> You can find more details in the Objective document[1].
>>
>> - Daniel
>>
>> [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
> I hope that you find resources to properly maintain MBS.


+1

This document seems to focus on "DNF" side of thing, while completely
missing the infrastructure side. E.g. MBS, dist-git, mass rebuilds, etc.


Vít


>  Currently (last two
> weeks) it cannot build the modules
> .
>
> -- Petr
>
> ___
> 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


signature.asc
Description: OpenPGP digital 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

Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

[Vít Ondruch]

Just FTR, I don't think I am going to reveal too much saying that for
RHEL9, the sentiment is (at least in the context of Ruby, Node.js and
Python) that we are very likely not going to use default streams. Plain
old RPMs do mostly the same job.

In this context, I'd be more than happy if the documentation discouraged
use of the default streams. Something along these lines: "Modularity
have default stream feature, but use it with caution only if you know
what you do and what is the impact."


Vít


Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/ModularPolicy
>
> == Summary ==
> Establish a set of rules for Modular content in Fedora to ensure an
> optimal user and packager experience.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
>
> == Detailed Description ==
> Over the last several months, members of the Modularity WG and FESCo
> have been working to establish a policy for module inclusion in
> Fedora. We now have a proposal that FESCo requested be taken to the
> Fedora community via the Change Proposal.
>
> There is a preview of the new policy available at
> https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
>
>
> == Benefit to Fedora ==
> This policy makes explicit what packagers can and cannot do with
> Modules in Fedora, which should avoid future issues like those that
> were seen during the Fedora 31 and Fedora 32 cycles.
>
> == Scope ==
> * Proposal owners:
> The proposal is written, so minimal work remains. We may need to make
> revisions or clarifications based on public feedback.
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A
> N/A (not a System Wide Change)
>
> == How To Test ==
> N/A (not a System Wide Change)
>
> == User Experience ==
> N/A this is not a user-facing change.
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
>
> == Documentation ==
> N/A (not a System Wide Change)
>
>
___
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: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

[Mark Wielaard]

Hi,

On Thu, 2020-07-23 at 09:59 +0200, Fabio Valentini wrote:
> On Thu, Jul 23, 2020 at 1:25 AM Mark Wielaard 
> > I committed the removal of the two static subpackages and added an
> > Obsoletes: elfutils-devel-static%{depsuffix} < 0.180-5 to elfutils-
> > devel and an Obsoletes: elfutils-libelf-devel-static%{depsuffix} <
> > 0.180-5 to elfutils-devel.
> > 
> > But I haven't done a build yet to give people a chance to yell and
> > scream this is the wrong way to do it. If nobody complains I'll do
> > a build of elfutils-0.180-5 for rawhide on Friday.
> 
> The subpackage removal and addition of appropriate Obsoletes tags
> looks correct to me.

Thanks. I had to make one small adjustment, rpmbuild in rawhide doesn't
accept the depsuffix on an Obsoletes. It is unnecessary anyway (it is
required on the Requires, because the libraries are multilib).

I have now build elfutils-0.180-5 which drops the -static packages in
rawhide. This should only affect the kexec-tools (the maintainers are
aware of the BuildRequires change necessary). But if there is any other
fallout please yell and scream.

BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
because there used to be a different libelf implementation (with a dead
upstream these days). Can I remove that? Or is it better to keep it
"just in case"?

Thanks,

Mrk
___
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: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

[Florian Weimer]

* Mark Wielaard:

> BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
> 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
> because there used to be a different libelf implementation (with a dead
> upstream these days). Can I remove that? Or is it better to keep it
> "just in case"?

My rule of thumb is that if it's not possible to directly upgrade from
the last release which still had the package, it's okay to remove the
Obsoletes:.  It's derived from first principles (the intermediate update
step will remove the package); I don't know if it's an official
guideline.

Thanks,
Florian
___
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: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

[Fabio Valentini]

On Fri, Jul 24, 2020 at 4:56 PM Mark Wielaard  wrote:
>
> Hi,
>
> On Thu, 2020-07-23 at 09:59 +0200, Fabio Valentini wrote:
> > On Thu, Jul 23, 2020 at 1:25 AM Mark Wielaard 
> > > I committed the removal of the two static subpackages and added an
> > > Obsoletes: elfutils-devel-static%{depsuffix} < 0.180-5 to elfutils-
> > > devel and an Obsoletes: elfutils-libelf-devel-static%{depsuffix} <
> > > 0.180-5 to elfutils-devel.
> > >
> > > But I haven't done a build yet to give people a chance to yell and
> > > scream this is the wrong way to do it. If nobody complains I'll do
> > > a build of elfutils-0.180-5 for rawhide on Friday.
> >
> > The subpackage removal and addition of appropriate Obsoletes tags
> > looks correct to me.
>
> Thanks. I had to make one small adjustment, rpmbuild in rawhide doesn't
> accept the depsuffix on an Obsoletes. It is unnecessary anyway (it is
> required on the Requires, because the libraries are multilib).
>
> I have now build elfutils-0.180-5 which drops the -static packages in
> rawhide. This should only affect the kexec-tools (the maintainers are
> aware of the BuildRequires change necessary). But if there is any other
> fallout please yell and scream.
>
> BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
> 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
> because there used to be a different libelf implementation (with a dead
> upstream these days). Can I remove that? Or is it better to keep it
> "just in case"?

Obsoletes for removed / renamed packages can usually be safely removed
after two stable fedora releases had them.
So, in this case, the Obsoletes should be in place for fedora 33 and
fedora 34, and you can remove them after f34 is branched off from
rawhide (so it takes effect for f35+).
(This is because only upgrades from fedora N to N+1 and N+2 are
supported at any point in time, so anyone who keeps their system
around will hit either f34 or f35 if they stick to the supported
upgrade path, and have those obsoleted packages removed if they have
them installed for some reason.)

Fabio
___
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: Modularity Improvements Objective

[Mat Booth]

On Fri, 24 Jul 2020 at 13:26, Petr Pisar  wrote:
>
> On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
> > There's a Modularity Improvements Objective draft available[1].
> >
> > The Objective summarizes the work that is in progress already as well as
> > highlights our plans for Fedora 34.
> >
> > We're planning to fix the current modularity in Fedora 33 and 34.
> > We may look into alternatives or bigger design changes in Fedora 35 and
> > later.
> >
> > You can find more details in the Objective document[1].
> >
> > - Daniel
> >
> > [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
>
> I hope that you find resources to properly maintain MBS. Currently (last two
> weeks) it cannot build the modules
> .
>
> -- Petr

I opened this ticket more than two months ago. :-(

What's *worse* is that before I filed that infra ticket I filed this
ticket [1] at the MBS upstream project and that got *absolutely* no
response. Complete silence. In fact *no* ticket reported there haven't
seen any activity in months. Not exactly confidence inspiring for the
future of the project.

[1] https://pagure.io/fm-orchestrator/issue/1640

I've tried *so* hard to get on board with modularity but I think I'm
done with modules now in Fedora.

In the early days the people who maintained MBS were super helpful and
worked hard to fix the bugs I found in it, but now it feels like those
days are gone and still it's just hurdle after hurdle. All I want is
an easy life, and I thought modules were that, but it's impossible to
get anything done in a timely manner, builds have required so much
babysitting, the MBS requiring (already scarce) releng resources to
intervene periodically Honestly, it's been just exhausting and
demoralising how many man-hours have gone to waste. So I've pulled all
my packages back into mainline Fedora since that seems to be the path
of least resistance even though I will once again have to maintain
multiple branches of my whole stack of packages.

Interesting experiment, maybe, but if there's going to be no
commitment to pay the on-going cost of infra maintenance and fix the
design-flaws or whatever serious problem is currently holding back
MBS, then I have to end the experiment for my own sanity at least.

mbooth

-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
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: Very strange compiler/linker related build failures in rawhide

[Jeff Law]

On Fri, 2020-07-24 at 10:31 +0200, Fabio Valentini wrote:
> Hi all,
> 
> I'm starting to see various very strange kinds of build failures in
> rawhide, that seem to have started with either of these updates (or a
> combination of them):
> 
> - annobin 9.21-1.fc33 → 9.22-1.fc33
> - binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
> - elfutils 0.179-2.fc33 → 0.180-2.fc33
> - glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33
> 
> These rawhide updates all happened at roughly the same time, so it's
> difficult to say which one of them is to blame (if any of them).
> 
> One error I've seen in libreoffice is a gcc / annobin segfault:
> 
> [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> *** WARNING *** there are active plugins, do not report this as a bug
> unless you can reproduce it without enabling any plugins.
> Event| Plugins
> PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> PLUGIN_START_UNIT| annobin: Generate global annotations
> PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
> PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> internal compiler error: Segmentation fault
>  1733 | join();
This sounds like a compiler bug.  Can you try adding 
"%define _lto_cflags %{nil}"

To the .spec file and see if that gets you over the hump?  I've seen one failure
of this nature in my LTO testing and haven't gotten around to producing a
bugreport suitable for upstream (but the affected package has LTO disabled to
keep it from failing its builds).  My tester reports that it's never got a clean
control build of libreoffice, so I've never dug into it for any LTO specific
failures.



>   |  ^
> 
> Other errors look like this one from switchboard-plug-onlineaccounts:
> 
> src/libonline-accounts.so.p/Authentification/Server.c: In function
> ‘online_accounts_server_on_bus_acquired’:
> src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
> function ‘__errno_location’ is initialized like a variable
>   498 |  gint errno = 0;
>   |  ^~~~
> 
> Where errno is neither __errno_location, nor a function, but a gint??
This is more likely related to the glibc update.

> 
> Other failures I've seen end up with linker failures, line these, from
> postgresql:
> 
> ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'
This is a known interaction between stap/dtrace probes and LTO.  I've already
fixed postgresql to avoid LTO until we fix this issue on the GCC side.

jeff
> 
___
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: Modularity Improvements Objective

[Mat Booth]

On Fri, 24 Jul 2020 at 16:10, Mat Booth  wrote:
>
> On Fri, 24 Jul 2020 at 13:26, Petr Pisar  wrote:
> >
> > On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
> > > There's a Modularity Improvements Objective draft available[1].
> > >
> > > The Objective summarizes the work that is in progress already as well as
> > > highlights our plans for Fedora 34.
> > >
> > > We're planning to fix the current modularity in Fedora 33 and 34.
> > > We may look into alternatives or bigger design changes in Fedora 35 and
> > > later.
> > >
> > > You can find more details in the Objective document[1].
> > >
> > > - Daniel
> > >
> > > [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
> >
> > I hope that you find resources to properly maintain MBS. Currently (last two
> > weeks) it cannot build the modules
> > .
> >
> > -- Petr
>
> I opened this ticket more than two months ago. :-(
>

Err, more than one month ago sorry. Apologies if that mischaracterised
the situation.
___
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: Modularity Improvements Objective

[Neal Gompa]

On Fri, Jul 24, 2020 at 11:10 AM Mat Booth  wrote:
>
> On Fri, 24 Jul 2020 at 13:26, Petr Pisar  wrote:
> >
> > On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote:
> > > There's a Modularity Improvements Objective draft available[1].
> > >
> > > The Objective summarizes the work that is in progress already as well as
> > > highlights our plans for Fedora 34.
> > >
> > > We're planning to fix the current modularity in Fedora 33 and 34.
> > > We may look into alternatives or bigger design changes in Fedora 35 and
> > > later.
> > >
> > > You can find more details in the Objective document[1].
> > >
> > > - Daniel
> > >
> > > [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020
> >
> > I hope that you find resources to properly maintain MBS. Currently (last two
> > weeks) it cannot build the modules
> > .
> >
> > -- Petr
>
> I opened this ticket more than two months ago. :-(
>
> What's *worse* is that before I filed that infra ticket I filed this
> ticket [1] at the MBS upstream project and that got *absolutely* no
> response. Complete silence. In fact *no* ticket reported there haven't
> seen any activity in months. Not exactly confidence inspiring for the
> future of the project.
>
> [1] https://pagure.io/fm-orchestrator/issue/1640
>
> I've tried *so* hard to get on board with modularity but I think I'm
> done with modules now in Fedora.
>
> In the early days the people who maintained MBS were super helpful and
> worked hard to fix the bugs I found in it, but now it feels like those
> days are gone and still it's just hurdle after hurdle. All I want is
> an easy life, and I thought modules were that, but it's impossible to
> get anything done in a timely manner, builds have required so much
> babysitting, the MBS requiring (already scarce) releng resources to
> intervene periodically Honestly, it's been just exhausting and
> demoralising how many man-hours have gone to waste. So I've pulled all
> my packages back into mainline Fedora since that seems to be the path
> of least resistance even though I will once again have to maintain
> multiple branches of my whole stack of packages.
>
> Interesting experiment, maybe, but if there's going to be no
> commitment to pay the on-going cost of infra maintenance and fix the
> design-flaws or whatever serious problem is currently holding back
> MBS, then I have to end the experiment for my own sanity at least.
>

Unfortunately, MBS is maintained by a different team: the team that
maintains Koji. I am unsure about what they're planning to do, but I
hope they're going to do *something*.


-- 
真実はいつも一つ！/ 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://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: Modularity Improvements Objective

[Ben Cotton]

On Fri, Jul 24, 2020 at 11:17 AM Neal Gompa  wrote:
>
> Unfortunately, MBS is maintained by a different team: the team that
> maintains Koji. I am unsure about what they're planning to do, but I
> hope they're going to do *something*.
>
With my Council hat on, I'd like to see that team represented in the
Objective if their involvement is going to be critical to the success
of Modularity.



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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: Modularity Improvements Objective

[Kevin Fenzi]

On Fri, Jul 24, 2020 at 11:16:16AM -0400, Neal Gompa wrote:
> 
> Unfortunately, MBS is maintained by a different team: the team that
> maintains Koji. I am unsure about what they're planning to do, but I
> hope they're going to do *something*.

To add history here, MBS was written by and maintained by a different
team until early this year, when it was handed off to the koji team. 

Last I heard they were still trying to get up to speed on the codebase,
etc. It's not easy to take a codebase someone else has written and
maintained and take it over. ;( 

I'm of course not speaking for them, and hopefully they will chime in
here with more info...

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

Re: Very strange compiler/linker related build failures in rawhide

[Fabio Valentini]

On Fri, Jul 24, 2020 at 5:11 PM Jeff Law  wrote:
> > One error I've seen in libreoffice is a gcc / annobin segfault:
> >
> > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > *** WARNING *** there are active plugins, do not report this as a bug
> > unless you can reproduce it without enabling any plugins.
> > Event| Plugins
> > PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> > PLUGIN_START_UNIT| annobin: Generate global annotations
> > PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> > annotations
> > PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
> > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > internal compiler error: Segmentation fault
> >  1733 | join();
> This sounds like a compiler bug.  Can you try adding
> "%define _lto_cflags %{nil}"
>
> To the .spec file and see if that gets you over the hump?  I've seen one 
> failure
> of this nature in my LTO testing and haven't gotten around to producing a
> bugreport suitable for upstream (but the affected package has LTO disabled to
> keep it from failing its builds).  My tester reports that it's never got a 
> clean
> control build of libreoffice, so I've never dug into it for any LTO specific
> failures.

I added this %define _lto_cflags %{nil} to the top of the libreoffice
.spec file, and compiled it in mock locally.
And it spits out the same GCC crash error message without LTO.

Fabio
___
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: Very strange compiler/linker related build failures in rawhide

[Jeff Law]

On Fri, 2020-07-24 at 17:44 +0200, Fabio Valentini wrote:
> On Fri, Jul 24, 2020 at 5:11 PM Jeff Law  wrote:
> > > One error I've seen in libreoffice is a gcc / annobin segfault:
> > > 
> > > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > > *** WARNING *** there are active plugins, do not report this as a bug
> > > unless you can reproduce it without enabling any plugins.
> > > Event| Plugins
> > > PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> > > PLUGIN_START_UNIT| annobin: Generate global annotations
> > > PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> > > annotations
> > > PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
> > > symbol
> > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > > internal compiler error: Segmentation fault
> > >  1733 | join();
> > This sounds like a compiler bug.  Can you try adding
> > "%define _lto_cflags %{nil}"
> > 
> > To the .spec file and see if that gets you over the hump?  I've seen one 
> > failure
> > of this nature in my LTO testing and haven't gotten around to producing a
> > bugreport suitable for upstream (but the affected package has LTO disabled 
> > to
> > keep it from failing its builds).  My tester reports that it's never got a 
> > clean
> > control build of libreoffice, so I've never dug into it for any LTO specific
> > failures.
> 
> I added this %define _lto_cflags %{nil} to the top of the libreoffice
> .spec file, and compiled it in mock locally.
> And it spits out the same GCC crash error message without LTO.
THanks for checking.  That'll make things easier ;-)

Add -save-temps to the compile line and also build with V=1 so you can get the
full command line.  Pass along the .ii file and that full command line and I'll
take a peek at what's going on inside GCC.

jeff
___
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: Very strange compiler/linker related build failures in rawhide

[Fabio Valentini]

On Fri, Jul 24, 2020 at 5:48 PM Jeff Law  wrote:
>
> On Fri, 2020-07-24 at 17:44 +0200, Fabio Valentini wrote:
> > On Fri, Jul 24, 2020 at 5:11 PM Jeff Law  wrote:
> > > > One error I've seen in libreoffice is a gcc / annobin segfault:
> > > >
> > > > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > > > *** WARNING *** there are active plugins, do not report this as a bug
> > > > unless you can reproduce it without enabling any plugins.
> > > > Event| Plugins
> > > > PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> > > > PLUGIN_START_UNIT| annobin: Generate global annotations
> > > > PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> > > > annotations
> > > > PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
> > > > symbol
> > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > > > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > > > internal compiler error: Segmentation fault
> > > >  1733 | join();
> > > This sounds like a compiler bug.  Can you try adding
> > > "%define _lto_cflags %{nil}"
> > >
> > > To the .spec file and see if that gets you over the hump?  I've seen one 
> > > failure
> > > of this nature in my LTO testing and haven't gotten around to producing a
> > > bugreport suitable for upstream (but the affected package has LTO 
> > > disabled to
> > > keep it from failing its builds).  My tester reports that it's never got 
> > > a clean
> > > control build of libreoffice, so I've never dug into it for any LTO 
> > > specific
> > > failures.
> >
> > I added this %define _lto_cflags %{nil} to the top of the libreoffice
> > .spec file, and compiled it in mock locally.
> > And it spits out the same GCC crash error message without LTO.
> THanks for checking.  That'll make things easier ;-)
>
> Add -save-temps to the compile line and also build with V=1 so you can get the
> full command line.  Pass along the .ii file and that full command line and 
> I'll
> take a peek at what's going on inside GCC.
>
> jeff
>

Looks like somebody already did that and attached the .ii file to the RHBZ.
https://bugzilla.redhat.com/show_bug.cgi?id=1859588
___
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: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

[Miro Hrončok]

On 24. 07. 20 16:19, Vít Ondruch wrote:

In this context, I'd be more than happy if the documentation discouraged
use of the default streams. Something along these lines: "Modularity
have default stream feature, but use it with caution only if you know
what you do and what is the impact."


In any context, default modular streams are not allowed.

This Change proposal does not propose to change that and hence I still don't 
understand why the policy contains guidelines for default modular streams at all :/


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

[Neal Gompa]

On Fri, Jul 24, 2020 at 12:05 PM Miro Hrončok  wrote:
>
> On 24. 07. 20 16:19, Vít Ondruch wrote:
> > In this context, I'd be more than happy if the documentation discouraged
> > use of the default streams. Something along these lines: "Modularity
> > have default stream feature, but use it with caution only if you know
> > what you do and what is the impact."
>
> In any context, default modular streams are not allowed.
>
> This Change proposal does not propose to change that and hence I still don't
> understand why the policy contains guidelines for default modular streams at 
> all :/
>

You asked him to make a Change and build general guidelines for
modules and module defaults for Fedora that could be applied to ELN.
He did that. Thus, here we are.



-- 
真実はいつも一つ！/ 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://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: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

[Miro Hrončok]

On 24. 07. 20 18:06, Neal Gompa wrote:

On Fri, Jul 24, 2020 at 12:05 PM Miro Hrončok  wrote:


On 24. 07. 20 16:19, Vít Ondruch wrote:

In this context, I'd be more than happy if the documentation discouraged
use of the default streams. Something along these lines: "Modularity
have default stream feature, but use it with caution only if you know
what you do and what is the impact."


In any context, default modular streams are not allowed.

This Change proposal does not propose to change that and hence I still don't
understand why the policy contains guidelines for default modular streams at 
all :/



You asked him to make a Change and build general guidelines for
modules and module defaults for Fedora that could be applied to ELN.
He did that. Thus, here we are.


I've asked to discuss allowing default modular streams in ELN with wider 
community. Stephen offered to prepare a change proposal. The change proposal 
doesn't say anything about allowing default modular streams in ELN. Hence my 
confusion.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Very strange compiler/linker related build failures in rawhide

[Jeff Law]

On Fri, 2020-07-24 at 17:59 +0200, Fabio Valentini wrote:
> On Fri, Jul 24, 2020 at 5:48 PM Jeff Law  wrote:
> > On Fri, 2020-07-24 at 17:44 +0200, Fabio Valentini wrote:
> > > On Fri, Jul 24, 2020 at 5:11 PM Jeff Law  wrote:
> > > > > One error I've seen in libreoffice is a gcc / annobin segfault:
> > > > > 
> > > > > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > > > > *** WARNING *** there are active plugins, do not report this as a bug
> > > > > unless you can reproduce it without enabling any plugins.
> > > > > Event| Plugins
> > > > > PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> > > > > PLUGIN_START_UNIT| annobin: Generate global 
> > > > > annotations
> > > > > PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
> > > > > annotations
> > > > > PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
> > > > > symbol
> > > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> > > > > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > > > > internal compiler error: Segmentation fault
> > > > >  1733 | join();
> > > > This sounds like a compiler bug.  Can you try adding
> > > > "%define _lto_cflags %{nil}"
> > > > 
> > > > To the .spec file and see if that gets you over the hump?  I've seen 
> > > > one failure
> > > > of this nature in my LTO testing and haven't gotten around to producing 
> > > > a
> > > > bugreport suitable for upstream (but the affected package has LTO 
> > > > disabled to
> > > > keep it from failing its builds).  My tester reports that it's never 
> > > > got a clean
> > > > control build of libreoffice, so I've never dug into it for any LTO 
> > > > specific
> > > > failures.
> > > 
> > > I added this %define _lto_cflags %{nil} to the top of the libreoffice
> > > .spec file, and compiled it in mock locally.
> > > And it spits out the same GCC crash error message without LTO.
> > THanks for checking.  That'll make things easier ;-)
> > 
> > Add -save-temps to the compile line and also build with V=1 so you can get 
> > the
> > full command line.  Pass along the .ii file and that full command line and 
> > I'll
> > take a peek at what's going on inside GCC.
> > 
> > jeff
> > 
> 
> Looks like somebody already did that and attached the .ii file to the RHBZ.
> https://bugzilla.redhat.com/show_bug.cgi?id=1859588
Unfortunately neither Marek nor I can reproduce with the compilers we've tested.
 Is it possible the OOM killer is killing the process?  Is there anything in the
system logs that might be relevant?

Jeff
___
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: Very strange compiler/linker related build failures in rawhide

[Dominique Martinet]

Jeff Law wrote on Fri, Jul 24, 2020:
> > Looks like somebody already did that and attached the .ii file to the RHBZ.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1859588
>
> Unfortunately neither Marek nor I can reproduce with the compilers we've 
> tested.
>  Is it possible the OOM killer is killing the process?  Is there anything in 
> the
> system logs that might be relevant?

I was able to reproduce running a rawhide mock, it's definitely not
memory pressure.

It's a plain segfault in cc1plus - I'd give a backtrace but it looks
mangled up so I didn't take the time to install debuginfos

-- 
Dominique
___
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

rust-ipnetwork license change

[Dusty Mabe]

The license for rust-ipnetwork changed to "MIT or Apache-2.0" upstream [1].
This is reflected in the PR to distgit [2] to update to the latest version.

Dusty

[1] 
https://github.com/achanda/ipnetwork/commit/fa128680b51fbcf9c37db99f011c91204c4a3b0d
[2] https://src.fedoraproject.org/rpms/rust-ipnetwork/pull-request/1
___
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: Very strange compiler/linker related build failures in rawhide

[Vít Ondruch]

The LTO break Ruby on various platforms.


https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573

vs

https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733

(Note these are my experimental builds testing single test case).


The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
least behaving the same on all platforms :/


And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby

Looking at the full test suite, it seems it causes some troubles to
SIGSEV signal handler (Ruby spawns subprocess and kills it).


Vít



Dne 24. 07. 20 v 10:31 Fabio Valentini napsal(a):
> Hi all,
>
> I'm starting to see various very strange kinds of build failures in
> rawhide, that seem to have started with either of these updates (or a
> combination of them):
>
> - annobin 9.21-1.fc33 → 9.22-1.fc33
> - binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
> - elfutils 0.179-2.fc33 → 0.180-2.fc33
> - glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33
>
> These rawhide updates all happened at roughly the same time, so it's
> difficult to say which one of them is to blame (if any of them).
>
> One error I've seen in libreoffice is a gcc / annobin segfault:
>
> [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> *** WARNING *** there are active plugins, do not report this as a bug
> unless you can reproduce it without enabling any plugins.
> Event| Plugins
> PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
> PLUGIN_START_UNIT| annobin: Generate global annotations
> PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
> PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx: In
> destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> internal compiler error: Segmentation fault
>  1733 | join();
>   |  ^
>
> Other errors look like this one from switchboard-plug-onlineaccounts:
>
> src/libonline-accounts.so.p/Authentification/Server.c: In function
> ‘online_accounts_server_on_bus_acquired’:
> src/libonline-accounts.so.p/Authentification/Server.c:498:2: error:
> function ‘__errno_location’ is initialized like a variable
>   498 |  gint errno = 0;
>   |  ^~~~
>
> Where errno is neither __errno_location, nor a function, but a gint??
>
> Other failures I've seen end up with linker failures, line these, from
> postgresql:
>
> ld: undefined reference to `postgresql_subtrans__checkpoint__start_semaphore'
>
> Does somebody have a clue what's going on here? It's currently
> blocking rawhide composes because libreoffice fails to build /
> install.
>
> See also: https://pagure.io/releng/failed-composes/issue/1571
>
> Thanks,
> Fabio
> ___
> 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
___
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: Very strange compiler/linker related build failures in rawhide

[Jeff Law]

On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote:
> The LTO break Ruby on various platforms.
> 
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573
> 
> vs
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733
> 
> (Note these are my experimental builds testing single test case).
I haven't gotten a clean ruby build with or without LTO.  So I haven't
investigated Ruby for any LTO specific failures.

> 
> 
> The only difference is redhat-rpm-config 162-1.fc33 => 163-1.fc33.
> Adding `%define _lto_cflags %{nil}` helped to recover, but if it was at
> least behaving the same on all platforms :/
> 
> 
> And this is Koschei failure: https://koschei.fedoraproject.org/package/ruby
> 
> Looking at the full test suite, it seems it causes some troubles to
> SIGSEV signal handler (Ruby spawns subprocess and kills it).
Does the signal handler modify any global variables?  That's been a common 
source
of issues I've seen.

jeff
> 
___
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

The case of LTO when produced enlarged binaries

[Artem Tim]

Hi. In rare cases building packages with LTO producing binaries or libraries 
which have bigger size then if they have built without LTO. For example 'kitty' 
package:

* with LTO:
  - koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
1.79 MB glfw-wayland.so
1.99 MB glfw-x11.so
4.78 MB fast_data_types.so
8.56 MB total

* no LTO
  - koji https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
1.65 MB glfw-wayland.so
1.84 MB glfw-x11.so
4.51 MB fast_data_types.so
8.00 MB total

Difference is 7%. What we should do in such case? Should we disable LTO for 
such packages? Or there is still could be gains from faster code execution 
speed?
___
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

z3 soname bump

[Jerry James]

I will soon push a change to the z3 package, in Rawhide only, which
will result in an soname bump.  The actual contents of libz3 will not
change, however.  The only Fedora consumer outside of the z3 package
itself is cppcheck, which currently fails to build due to the recent
cmake change.  If the cppcheck maintainers want me to try to fix that,
I will do so; otherwise, I am happy to let them fix it themselves.

The gory details for those interested:

The z3 project has two build systems: an old one, based on generating
Makefiles with python scripts, and a new one based on cmake.  We have
been using the old one, because the cmake build system does not
support building z3's OCaml interface.  However, the old build system
has a number of ... features ... that we had to work around, leading
to a fair amount of uncleanness in the spec file.

I have decided to take the plunge and switch to using the cmake build
system, with manual steps afterward to build the OCaml interface.  The
old build system gave the z3 library an soname of "libz3.so", which
the spec file modified to be "libz3.so.0", with a versioned library
libz3.so.0.0.0.  The cmake build system gives the library an soname of
"libz3.so.4.8" (where 4 and 8 are the major and minor version numbers,
respectively), with a versioned library libz3.so.4.8.8.0.  This lets
me throw out a bunch of cruft, while introducing a much smaller amount
of cruft due to the OCaml interface.  I think it's a win.
-- 
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: pagure pull-request email workflow

[Richard W.M. Jones]

On Wed, Jul 22, 2020 at 02:19:59PM +0200, Mark Wielaard wrote:
> Hi Tom,
> 
> On Tue, 2020-07-21 at 13:53 +0100, Tom Hughes via devel wrote:
> > On 21/07/2020 13:12, Mark Wielaard wrote:
> > > > I normally just edit .git/config and add to the origin remote
> > > > an extra fetch:
> > > > 
> > > > fetch = +refs/pull/*/head:refs/remotes/origin/pull/*
> > > > 
> > > > then after fetching you can merge origin/pull/NNN.
> > > 
> > > But this is very helpful! Thanks.
> > > 
> > > So with that I can easily do checks, adjustments, create my own
> > > commits, do cherry-picks or merges, etc. But how does it interact with
> > > the website? How do I sent comments? I see it comes with a mini-CI koji
> > > run, does it add a tag to the commit as tested when it succeeds/fails?
> > > How do I indicate which changes I made/pushed or which changes I would
> > > like the submitter to make? How do I discard a pull if I determine it
> > > isn't useful? etc.
> > 
> > You use the web site as far as I know.
> > 
> > Unlike github it doesn't even notice when you push a merge so
> > you still have to close the PR on the web site as well.
> > 
> > > And if I wish to create a pagure pull request myself, do I simply push
> > > to pull/NNN? How do I determine which NNN to use?
> > 
> > Well you push to a branch on your fork but then you have to
> > use the web site to open the PR I think.
> > 
> > I mean there is a pagure API through which you can likely do
> > all these things but AFAIK there is no CLI interface for it so
> > you have to hit it with curl or something ;-)
> 
> I found libpagure, which makes it possible to write some command line
> tooling. The library is a little clunky imho, but that might be because
> my python is a little rusty. But I was able to comment on the pull
> request and actually merge it. Although I wish I hadn't because it
> doesn't do a rebase first. But combined with the .git/config trick to
> add:
> 
> fetch = +refs/pull/*/head:refs/remotes/origin/pull/*
> 
> libpagure has the potential to create a useful workflow. For others
> that want to try, you'll initialize through something like:
> 
> >>> from libpagure import Pagure
> >>> pg = Pagure(pagure_token="xxx",instance_url="
> https://src.fedoraproject.org/",pagure_repository="rpms/valgrind";)
> >>> pg.comment_request(1, "Trying out libpagure commenting. This
> request looks reasonable.")
> 
> As you say, the web api is even more resourceful and we can integrate
> some of those requests into the library: https://pagure.io/api/
> 
> The only thing that is not very nice are those pagure_tokens. I was
> hoping you could get a temporary one through simple fedora kerberos
> authentication. But the only way to create one seems to be through a
> webbrowser: https://src.fedoraproject.org/settings#nav-api-tab
> You can create one that is valid for 2 years, which is helpful, but
> doesn't feel very secure. How do people manage those tokens?
> 
> And I really would like to see a mail backend (maybe simply accepting
> gpg signed emails) so you don't have to be online just to deal with
> these kind of pull requests.

Dan Berrange is writing a thing called bichon.  It ony works with
gitlab at the moment, but AIUI he'll accept patches to support other
"*hubs".

https://gitlab.com/bichon-project/bichon

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: The case of LTO when produced enlarged binaries

[Jeff Law]

On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote:
> Hi. In rare cases building packages with LTO producing binaries or libraries 
> which have bigger size then if they have built without LTO. For example 
> 'kitty' package:
> 
> * with LTO:
>   - koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
> 1.79 MB glfw-wayland.so
> 1.99 MB glfw-x11.so
> 4.78 MB fast_data_types.so
> 8.56 MB total
> 
> * no LTO
>   - koji https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
> 1.65 MB glfw-wayland.so
> 1.84 MB glfw-x11.so
> 4.51 MB fast_data_types.so
> 8.00 MB total
> 
> Difference is 7%. What we should do in such case? Should we disable LTO for 
> such packages? Or there is still could be gains from faster code execution 
> speed?
I'd tend to leave LTO on, but it's totally your call.  Without looking at the
binaries, sources and compiler dumps I'd hazard a guess you're getting a lot of
cross module inlining, but very little identical code folding.  THe former tends
to make things bigger, but faster.  The latter tends to shrink code with little
impact on runtime performance.

Unfortunately comparing this stuff in an LTO world is much harder than in a non-
LTO world.  You can't just bisect it to a .o or function that's larger :(


jeff
> 
___
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: z3 soname bump

[Jeff Law]

On Fri, 2020-07-24 at 13:15 -0600, Jerry James wrote:
> I will soon push a change to the z3 package, in Rawhide only, which
> will result in an soname bump.  The actual contents of libz3 will not
> change, however.  The only Fedora consumer outside of the z3 package
> itself is cppcheck, which currently fails to build due to the recent
> cmake change.  If the cppcheck maintainers want me to try to fix that,
> I will do so; otherwise, I am happy to let them fix it themselves.
> 
> The gory details for those interested:
> 
> The z3 project has two build systems: an old one, based on generating
> Makefiles with python scripts, and a new one based on cmake.  We have
> been using the old one, because the cmake build system does not
> support building z3's OCaml interface.  However, the old build system
> has a number of ... features ... that we had to work around, leading
> to a fair amount of uncleanness in the spec file.
> 
> I have decided to take the plunge and switch to using the cmake build
> system, with manual steps afterward to build the OCaml interface.  The
> old build system gave the z3 library an soname of "libz3.so", which
> the spec file modified to be "libz3.so.0", with a versioned library
> libz3.so.0.0.0.  The cmake build system gives the library an soname of
> "libz3.so.4.8" (where 4 and 8 are the major and minor version numbers,
> respectively), with a versioned library libz3.so.4.8.8.0.  This lets
> me throw out a bunch of cruft, while introducing a much smaller amount
> of cruft due to the OCaml interface.  I think it's a win.
Just a note on z3.  

I've been trying to track down what I think is an uninstantiated template issue
that's exposed by LTO.  I've been chasing it on/off over the last day or two
without success.  So if you get a build failure that looks like this:

/usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x110): undefined 
reference to `lp::lp_solver::get_variable_name[abi:cxx11](unsigned int) const'
/usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x168): undefined 
reference to `lp::lp_solver::get_variable_name[abi:cxx11](unsigned int) const'
/usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x1b0): undefined 
reference to `lp::lp_solver::get_variable_name[abi:cxx11](unsigned int) const'
collect2: error: ld returned 1 exit status

Just disable LTO via the usual mechanism (%define _lto_cflags %{nil}).  We'll
revisit any opt-outs again between F33 and F34 and re-evaluate them.

Jeff
___
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: z3 soname bump

[Jerry James]

On Fri, Jul 24, 2020 at 1:35 PM Jeff Law  wrote:
> Just a note on z3.
>
> I've been trying to track down what I think is an uninstantiated template 
> issue
> that's exposed by LTO.  I've been chasing it on/off over the last day or two
> without success.  So if you get a build failure that looks like this:
>
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x110): undefined 
> reference to `lp::lp_solver double>::get_variable_name[abi:cxx11](unsigned int) const'
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x168): undefined 
> reference to `lp::lp_solver double>::get_variable_name[abi:cxx11](unsigned int) const'
> /usr/bin/ld: /tmp/z3.16EntH.ltrans1.ltrans.o:(.data.rel.ro+0x1b0): undefined 
> reference to `lp::lp_solver double>::get_variable_name[abi:cxx11](unsigned int) const'
> collect2: error: ld returned 1 exit status
>
> Just disable LTO via the usual mechanism (%define _lto_cflags %{nil}).  We'll
> revisit any opt-outs again between F33 and F34 and re-evaluate them.

Thanks for the heads-up, Jeff.  I have not seen that in a mock build,
but if there hasn't been a successful Rawhide compose since the LTO
bits landed, that is no surprise.  I have a vague memory of asking z3
upstream to add some explicit template instantiations around the time
gcc 10 landed in Rawhide, so there is precedent if we need to do so
again.

Regards,
-- 
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: [HEADS-UP] OpenJDK 11 is now the default Java in rawhide

[Deepak Bhole]

* Adam Williamson  [2020-07-24 00:52]:
> On July 23, 2020 6:17:04 p.m. PDT, Deepak Bhole  wrote:
> >* Adam Williamson  [2020-07-23 20:57]:
> >> On Tue, 2020-07-21 at 12:02 +0200, Fabio Valentini wrote:

[ ... ]

> >
> >I could of-course misunderstanding the issue but is there a reason that
> >you
> >believe this is JDK related?
> >
> >Deepak
> >
> >> Merging the side tag with FreeIPA known broken was arguable enough,
> >but
> >> merging it with a release-blocking package broken seems worse. Please
> >> try not to do this in future.

[ ... ]

> 
> The specific compile error isn't really relevant, the problem is that we need 
> a new LO because the deps of the existing build cannot be satisfied. However, 
> now I look closer, I think I was wrong to blame java for the deps changing, I 
> apologize for that - the timing lined up, and there was an LO build failure 
> in the java side tag like I mentioned, so I figured the new java was the 
> issue based on that, but it actually seems to be coincidental. It looks like 
> the dep that changed was actually poppler - a new build of poppler was done 
> two weeks ago but I guess was only tagged to f33 recently.

Ah okay, thanks for clarifying, I was unaware of the additional dep issue.

Deepak

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> 
___
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: The case of LTO when produced enlarged binaries

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote:
> On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote:
> > Hi. In rare cases building packages with LTO producing binaries or
> > libraries which have bigger size then if they have built without
> > LTO. For example 'kitty' package:
> > 
> > * with LTO:
> >   - koji task 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
> > 1.79 MB glfw-wayland.so
> > 1.99 MB glfw-x11.so
> > 4.78 MB fast_data_types.so
> > 8.56 MB total
> > 
> > * no LTO
> >   - koji 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
> > 1.65 MB glfw-wayland.so
> > 1.84 MB glfw-x11.so
> > 4.51 MB fast_data_types.so
> > 8.00 MB total
> > 
> > Difference is 7%. What we should do in such case? Should we disable
> > LTO for such packages? Or there is still could be gains from faster
> > code execution speed?
> I'd tend to leave LTO on, but it's totally your call.  Without
> looking at the
> binaries, sources and compiler dumps I'd hazard a guess you're
> getting a lot of
> cross module inlining, but very little identical code folding.  THe
> former tends
> to make things bigger, but faster.  The latter tends to shrink code
> with little
> impact on runtime performance.

- From what I see in this case, -ffat-lto-objects generates code that is
bigger than without -flto. -flto alone generates smaller code than
without -flto.

> Unfortunately comparing this stuff in an LTO world is much harder
> than in a non-
> LTO world.  You can't just bisect it to a .o or function that's
> larger :(
> 
> 
> jeff
> > 
> ___
> 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

- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bQ2cACgkQEV1auJxc
Hh4KkA/+LfGfZGjkZZcgJfgRYhVGdjpFpjdEjwTPQh/75IFnkd0q0BAJlHAxuvKA
HQ0z/EQH5dfXIXtKYzg8+t+EHYjABPio+BSllNtv8OOAFW55TsRgxHCq/vDDjugU
gM9urFXTvYnK8P52/EFMmZoIcg0PiLEMDArsoeUmHxzBDLSi4755HAsz/dz0VWxa
BpJWWavTDHSFgkjMbqsrU/E9n/N0WdRdhaG1vuYEc80OLuQxGA9wSyT8fCOauGGZ
6qg2l93gHmQQys/V1PDOup2Dpjgr/GFEN3H0Q55UhdszXhfYKmipA0gS+rX7evyH
jj9bYN+VMm8Qq9i7wmwPHsa88kYztozsx3vXYebpnuxgzG0uq1F+A2WoxkECtztc
n5Ug0wUbYZSEBbpzxt7Tr9zaYoJ+TzdT8Ce+doub+P2fmnGO3Rhz87V0MGyiYcSG
siBdnMBh26MwkQxRJkb5oR7WwCDmde2Rt7SmkVQuBI4sIUN418tif+bJUV+PMeMJ
Q2hvqZryKeMHqGx7QmoUqSr5dMcZaY4zvMVbWggn2+qphNyI7gdc+QZMmtJ+5xeG
ZpgKjMDofW8PWgD8Pn3ToeN/pyIzFFd17vvYY1sFD1ZpKE229T58eP6kWiMOnGyL
j2/BI5UGjH0s+bhiUDLvfyVregBJRSxTptP975HLjjiP4GWUYN0=
=taI4
-END 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

Re: The case of LTO when produced enlarged binaries

[Jeff Law]

On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote:
> On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote:
> > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote:
> > > Hi. In rare cases building packages with LTO producing binaries or
> > > libraries which have bigger size then if they have built without
> > > LTO. For example 'kitty' package:
> > > 
> > > * with LTO:
> > >   - koji task 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
> > > 1.79 MB glfw-wayland.so
> > > 1.99 MB glfw-x11.so
> > > 4.78 MB fast_data_types.so
> > > 8.56 MB total
> > > 
> > > * no LTO
> > >   - koji 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
> > > 1.65 MB glfw-wayland.so
> > > 1.84 MB glfw-x11.so
> > > 4.51 MB fast_data_types.so
> > > 8.00 MB total
> > > 
> > > Difference is 7%. What we should do in such case? Should we disable
> > > LTO for such packages? Or there is still could be gains from faster
> > > code execution speed?
> > I'd tend to leave LTO on, but it's totally your call.  Without
> > looking at the
> > binaries, sources and compiler dumps I'd hazard a guess you're
> > getting a lot of
> > cross module inlining, but very little identical code folding.  THe
> > former tends
> > to make things bigger, but faster.  The latter tends to shrink code
> > with little
> > impact on runtime performance.
> 
> From what I see in this case, -ffat-lto-objects generates code that is
> bigger than without -flto. -flto alone generates smaller code than
> without -flto.
The fat-lto-objects bits are not used during an LTO link.  They exist solely to
cover the case where there's a .o/.a that ends up installed.

jeff
> 
___
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: The case of LTO when produced enlarged binaries

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote:
> On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote:
> > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote:
> > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote:
> > > > Hi. In rare cases building packages with LTO producing binaries
> > > > or
> > > > libraries which have bigger size then if they have built
> > > > without
> > > > LTO. For example 'kitty' package:
> > > > 
> > > > * with LTO:
> > > >   - koji task 
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
> > > > 1.79 MB glfw-wayland.so
> > > > 1.99 MB glfw-x11.so
> > > > 4.78 MB fast_data_types.so
> > > > 8.56 MB total
> > > > 
> > > > * no LTO
> > > >   - koji 
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
> > > > 1.65 MB glfw-wayland.so
> > > > 1.84 MB glfw-x11.so
> > > > 4.51 MB fast_data_types.so
> > > > 8.00 MB total
> > > > 
> > > > Difference is 7%. What we should do in such case? Should we
> > > > disable
> > > > LTO for such packages? Or there is still could be gains from
> > > > faster
> > > > code execution speed?
> > > I'd tend to leave LTO on, but it's totally your call.  Without
> > > looking at the
> > > binaries, sources and compiler dumps I'd hazard a guess you're
> > > getting a lot of
> > > cross module inlining, but very little identical code folding. 
> > > THe
> > > former tends
> > > to make things bigger, but faster.  The latter tends to shrink
> > > code
> > > with little
> > > impact on runtime performance.
> > 
> > From what I see in this case, -ffat-lto-objects generates code that
> > is
> > bigger than without -flto. -flto alone generates smaller code than
> > without -flto.
> The fat-lto-objects bits are not used during an LTO link.  They exist
> solely to
> cover the case where there's a .o/.a that ends up installed.

Well, I tell what I see :)

Compiling kitty with settings below produces this big
/usr/lib64/kitty/kitty/fast_data_types.so:

* Without any LTO-related flags: 4.52 MB
* With -flto: 4.30 MB
* With -flto -ffat-lto-objects: 4.79 MB

Well, I did not run compilation multiple times but don't think it will
change much.

> jeff
> > 
> 

- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bROYACgkQEV1auJxc
Hh6dsBAApNegXihpiJ3SVr5IiD4pypEUDUNyBTY+Tp+HINNWdQHVivs2jYWwfVpU
rNokkpq6Crgj68wznNGnwq+/eSP7DQwP3rN0TsAsfVydO1w0xBkz3zC47Y/7NPRR
Ceeoalajz6/EqN89LDyYT/aQbfT4zbOV0ZTnUQrOe21URg2L1mUBSjeCoDortkC+
1um7lyexAFroXmU4fQSdUMNTLrSolfFJPlkqeaaiJorqMvzex08xrv1D3vRrIyBD
6Z0NdPjB1nMbIWdCwTATYkbARzBH/88AUE3RZbjvRakr1BTBmsye3XaFts3Gn4Q8
ykINe/ImL+sDxm+cxKEAzafnr2GZQPvxYbwPjF+CEwDsBhqn92goOewgrrxNh+sq
e9yf0vpJhmJBIq/hwPgvTihn9vB7oqxjT2/CFjIlNFCc5FyZfuSJPsyE/8EA4Vb6
9b8vj/q+gAlt9Ty/aJ+yhxQsO8zT0ZrVOi4L1/5RQna9HGca3YyKH4v9exHRMSpo
HtbacKKg+7zYvVif7go6ERGBM680Pi5t6ypaH2cWOg4lRX50BVNn5NDpvatnOD/L
VxJ1p+LmhRaoXT1Kzb4P5bNaSl+o7lPAjIjRk8osVll7m2jxFJxKfMLvnUBUaROj
5mVGA2JgdgGXKOdeFLHPsDmxs9B+EdR+PMzhMkcbww+MbhPXOiM=
=gRTO
-END 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

Re: The case of LTO when produced enlarged binaries

[Jeff Law]

On Fri, 2020-07-24 at 22:30 +0200, Igor Raits wrote:
> On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote:
> > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote:
> > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote:
> > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote:
> > > > > Hi. In rare cases building packages with LTO producing binaries
> > > > > or
> > > > > libraries which have bigger size then if they have built
> > > > > without
> > > > > LTO. For example 'kitty' package:
> > > > > 
> > > > > * with LTO:
> > > > >   - koji task 
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998
> > > > > 1.79 MB glfw-wayland.so
> > > > > 1.99 MB glfw-x11.so
> > > > > 4.78 MB fast_data_types.so
> > > > > 8.56 MB total
> > > > > 
> > > > > * no LTO
> > > > >   - koji 
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854
> > > > > 1.65 MB glfw-wayland.so
> > > > > 1.84 MB glfw-x11.so
> > > > > 4.51 MB fast_data_types.so
> > > > > 8.00 MB total
> > > > > 
> > > > > Difference is 7%. What we should do in such case? Should we
> > > > > disable
> > > > > LTO for such packages? Or there is still could be gains from
> > > > > faster
> > > > > code execution speed?
> > > > I'd tend to leave LTO on, but it's totally your call.  Without
> > > > looking at the
> > > > binaries, sources and compiler dumps I'd hazard a guess you're
> > > > getting a lot of
> > > > cross module inlining, but very little identical code folding. 
> > > > THe
> > > > former tends
> > > > to make things bigger, but faster.  The latter tends to shrink
> > > > code
> > > > with little
> > > > impact on runtime performance.
> > > 
> > > From what I see in this case, -ffat-lto-objects generates code that
> > > is
> > > bigger than without -flto. -flto alone generates smaller code than
> > > without -flto.
> > The fat-lto-objects bits are not used during an LTO link.  They exist
> > solely to
> > cover the case where there's a .o/.a that ends up installed.
> 
> Well, I tell what I see :)
> 
> Compiling kitty with settings below produces this big
> /usr/lib64/kitty/kitty/fast_data_types.so:
> 
> * Without any LTO-related flags: 4.52 MB
> * With -flto: 4.30 MB
> * With -flto -ffat-lto-objects: 4.79 MB
> 
> Well, I did not run compilation multiple times but don't think it will
> change much.
That's quite bizarre.  I'll put it on the list of things to investigate.

jeff
___
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: Very strange compiler/linker related build failures in rawhide

[Eric Sandeen]

On 7/24/20 1:31 AM, Fabio Valentini wrote:
> Hi all,
> 
> I'm starting to see various very strange kinds of build failures in
> rawhide, that seem to have started with either of these updates (or a
> combination of them):
> 
> - annobin 9.21-1.fc33 → 9.22-1.fc33
> - binutils 2.34.0-6.fc33 → 2.34.0-7.fc33
> - elfutils 0.179-2.fc33 → 0.180-2.fc33
> - glibc 2.31.9000-13.fc33 → 2.31.9000-14.fc33
> 
> These rawhide updates all happened at roughly the same time, so it's
> difficult to say which one of them is to blame (if any of them).

Hm, is this related?  (libtool segfault building xfsprogs)

https://kojipkgs.fedoraproject.org//work/tasks/9149/47779149/build.log

/bin/sh ../libtool --quiet --tag=CC --mode=link gcc -Wl,-z,relro 
-Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rpath /lib64 -version-info 0:0:0 
-static -o libfrog.la avl64.lo bitmap.lo bulkstat.lo convert.lo crc32.lo 
fsgeom.lo list_sort.lo linux.lo logging.lo paths.lo projects.lo ptvar.lo 
radix-tree.lo scrub.lo topology.lo util.lo workqueue.lo 
../libtool: line 1085: 137776 Segmentation fault  (core dumped) ar cru 
.libs/libfrog.a avl64.o bitmap.o bulkstat.o convert.o crc32.o fsgeom.o 
list_sort.o linux.o logging.o paths.o projects.o ptvar.o radix-tree.o scrub.o 
topology.o util.o workqueue.o
gmake[2]: *** [../include/buildrules:71: libfrog.la] Error 139
gmake[1]: *** [include/buildrules:36: libfrog] Error 2
make: *** [Makefile:92: default] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
Child return code was: 1
EXCEPTION: [Error()]
___
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: Very strange compiler/linker related build failures in rawhide

[Jerry James]

On Fri, Jul 24, 2020 at 2:49 PM Eric Sandeen  wrote:
> Hm, is this related?  (libtool segfault building xfsprogs)
>
> https://kojipkgs.fedoraproject.org//work/tasks/9149/47779149/build.log
>
> /bin/sh ../libtool --quiet --tag=CC --mode=link gcc -Wl,-z,relro 
> -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rpath /lib64 -version-info 
> 0:0:0 -static -o libfrog.la avl64.lo bitmap.lo bulkstat.lo convert.lo 
> crc32.lo fsgeom.lo list_sort.lo linux.lo logging.lo paths.lo projects.lo 
> ptvar.lo radix-tree.lo scrub.lo topology.lo util.lo workqueue.lo
> ../libtool: line 1085: 137776 Segmentation fault  (core dumped) ar cru 
> .libs/libfrog.a avl64.o bitmap.o bulkstat.o convert.o crc32.o fsgeom.o 
> list_sort.o linux.o logging.o paths.o projects.o ptvar.o radix-tree.o scrub.o 
> topology.o util.o workqueue.o
> gmake[2]: *** [../include/buildrules:71: libfrog.la] Error 139
> gmake[1]: *** [include/buildrules:36: libfrog] Error 2
> make: *** [Makefile:92: default] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
> Child return code was: 1
> EXCEPTION: [Error()]

Isn't that ar segfaulting?  I just saw the same thing (an ar segfault)
while trying to do a mock build of z3 with --enablerepo=local.
-- 
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: Very strange compiler/linker related build failures in rawhide

[Jeff Law]

On Fri, 2020-07-24 at 15:00 -0600, Jerry James wrote:
> On Fri, Jul 24, 2020 at 2:49 PM Eric Sandeen  wrote:
> > Hm, is this related?  (libtool segfault building xfsprogs)
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/9149/47779149/build.log
> > 
> > /bin/sh ../libtool --quiet --tag=CC --mode=link gcc -Wl,-z,relro 
> > -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> > -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rpath /lib64 -version-info 
> > 0:0:0 -static -o libfrog.la avl64.lo bitmap.lo bulkstat.lo convert.lo 
> > crc32.lo fsgeom.lo list_sort.lo linux.lo logging.lo paths.lo projects.lo 
> > ptvar.lo radix-tree.lo scrub.lo topology.lo util.lo workqueue.lo
> > ../libtool: line 1085: 137776 Segmentation fault  (core dumped) ar cru 
> > .libs/libfrog.a avl64.o bitmap.o bulkstat.o convert.o crc32.o fsgeom.o 
> > list_sort.o linux.o logging.o paths.o projects.o ptvar.o radix-tree.o 
> > scrub.o topology.o util.o workqueue.o
> > gmake[2]: *** [../include/buildrules:71: libfrog.la] Error 139
> > gmake[1]: *** [include/buildrules:36: libfrog] Error 2
> > make: *** [Makefile:92: default] Error 2
> > error: Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
> > RPM build errors:
> > Bad exit status from /var/tmp/rpm-tmp.fcTM51 (%build)
> > Child return code was: 1
> > EXCEPTION: [Error()]
> 
> Isn't that ar segfaulting?  I just saw the same thing (an ar segfault)
> while trying to do a mock build of z3 with --enablerepo=local.
More likely the binutils update if that's gone in.  Nick's probably already
wrapped for the day.

Jeff
> 
___
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

ar (binutils) segfaulting in Rawhide - known bug?

[Richard W.M. Jones]

Just upgraded a development machine to:

binutils-2.34.0-10.fc33.x86_64
gcc-10.1.1-2.fc33.x86_64
glibc-2.31.9000-21.fc33.x86_64

and a very simple C compile (non-LTO) is now segfaulting:

make[3]: Entering directory '/home/rjones/d/nbdkit/common/protocol'
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../..-Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE  -MT 
libprotocol_la-protostrings.lo -MD -MP -MF 
.deps/libprotocol_la-protostrings.Tpo -c -o libprotocol_la-protostrings.lo 
`test -f 'protostrings.c' || echo './'`protostrings.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla -Werror 
-O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD -MP -MF 
.deps/libprotocol_la-protostrings.Tpo -c protostrings.c  -fPIC -DPIC -o 
.libs/libprotocol_la-protostrings.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla -Werror 
-O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD -MP -MF 
.deps/libprotocol_la-protostrings.Tpo -c protostrings.c -o 
libprotocol_la-protostrings.o >/dev/null 2>&1
mv -f .deps/libprotocol_la-protostrings.Tpo 
.deps/libprotocol_la-protostrings.Plo
/bin/sh ../../libtool  --tag=CC   --mode=link gcc -Wall -Wshadow -Wvla -Werror 
-O0 -g -Wp,-U_FORTIFY_SOURCE   -O0 -g -Wp,-U_FORTIFY_SOURCE  -o libprotocol.la  
libprotocol_la-protostrings.lo   
libtool: link: ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o 
../../libtool: line 1734: 2572327 Segmentation fault  (core dumped) ar cru 
.libs/libprotocol.a .libs/libprotocol_la-protostrings.o

Core was generated by `ar cru .libs/libprotocol.a 
.libs/libprotocol_la-protostrings.o'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
 binutils-2.34.0-10.fc33.x86_64
(gdb) bt
Missing separate debuginfos, use: dnf debuginfo-install#0  0x 
in ?? ()
#1  0x7f15bd3e03d0 in make_relative_prefix_1.part ()
   from /lib64/libbfd-2.34.0.20200522.so
#2  0x7f15bd3d22db in bfd_plugin_object_p.lto_priv ()
   from /lib64/libbfd-2.34.0.20200522.so
#3  0x7f15bd3401ce in bfd_check_format_matches ()
   from /lib64/libbfd-2.34.0.20200522.so
#4  0x7f15bd340e7a in _bfd_write_archive_contents ()
   from /lib64/libbfd-2.34.0.20200522.so
#5  0x7f15bd348b2a in bfd_close () from /lib64/libbfd-2.34.0.20200522.so
#6  0x559ee83994b6 in write_archive ()
#7  0x559ee8396ac3 in main ()

I can't find any BZ for this.  Any ideas what it could be?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: ar (binutils) segfaulting in Rawhide - known bug?

[Jerry James]

On Fri, Jul 24, 2020 at 3:30 PM Richard W.M. Jones  wrote:
> Just upgraded a development machine to:
>
> binutils-2.34.0-10.fc33.x86_64
> gcc-10.1.1-2.fc33.x86_64
> glibc-2.31.9000-21.fc33.x86_64
>
> and a very simple C compile (non-LTO) is now segfaulting:

[snip]

> I can't find any BZ for this.  Any ideas what it could be?

See the last few messages in the "Very strange compiler/linker related
build failures in rawhide" thread.  It looks like something has gone
awry with the binutils update.  The problem is not limited to ar,
either.  This is from a mock build of the abc package:

extracting debug info from
/builddir/build/BUILDROOT/abc-1.01-27.git20200720.fc33.x86_64/usr/bin/abc
/usr/lib/rpm/find-debuginfo.sh: line 262:  6010 Segmentation fault
 (core dumped) nm -D "$binary" --format=posix --defined-only
  6011 Done| awk '{ print $1 }'
  6012 Done| sort > "$dynsyms"
/usr/lib/rpm/find-debuginfo.sh: line 262:  6013 Segmentation fault
 (core dumped) nm "$debuginfo" --format=sysv --defined-only
  6014 Done| awk -F \| '{ if ($4 ~ "FUNC") print $1 }'
  6015 Done| sort > "$funcsyms"
xz: /tmp/tmp.1oP6gAlDVB: No such file or directory
objcopy: cannot open: /tmp/tmp.1oP6gAlDVB.xz: No such file or directory
/usr/lib/rpm/find-debuginfo.sh: line 262:  6044 Segmentation fault
 (core dumped) nm -D "$binary" --format=posix --defined-only
  6045 Done| awk '{ print $1 }'
  6046 Done| sort > "$dynsyms"
/usr/lib/rpm/find-debuginfo.sh: line 262:  6047 Segmentation fault
 (core dumped) nm "$debuginfo" --format=sysv --defined-only
  6048 Done| awk -F \| '{ if ($4 ~ "FUNC") print $1 }'
  6049 Done| sort > "$funcsyms"
xz: /tmp/tmp.rddMhW6CLz: No such file or directory
objcopy: cannot open: /tmp/tmp.rddMhW6CLz.xz: No such file or directory

So ar and nm are affected, at least.
-- 
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: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Fri, 2020-07-24 at 22:29 +0100, Richard W.M. Jones wrote:
> Just upgraded a development machine to:
> 
> binutils-2.34.0-10.fc33.x86_64
> gcc-10.1.1-2.fc33.x86_64
> glibc-2.31.9000-21.fc33.x86_64
> 
> and a very simple C compile (non-LTO) is now segfaulting:
> 
> make[3]: Entering directory '/home/rjones/d/nbdkit/common/protocol'
> /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I../..-Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE  -MT 
> libprotocol_la-protostrings.lo -MD -MP -MF 
> .deps/libprotocol_la-protostrings.Tpo -c -o libprotocol_la-protostrings.lo 
> `test -f 'protostrings.c' || echo './'`protostrings.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla 
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD 
> -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c  -fPIC -DPIC 
> -o .libs/libprotocol_la-protostrings.o
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla 
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD 
> -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c -o 
> libprotocol_la-protostrings.o >/dev/null 2>&1
> mv -f .deps/libprotocol_la-protostrings.Tpo 
> .deps/libprotocol_la-protostrings.Plo
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc -Wall -Wshadow -Wvla 
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE   -O0 -g -Wp,-U_FORTIFY_SOURCE  -o 
> libprotocol.la  libprotocol_la-protostrings.lo   
> libtool: link: ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o 
> ../../libtool: line 1734: 2572327 Segmentation fault  (core dumped) ar 
> cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o
> 
> Core was generated by `ar cru .libs/libprotocol.a 
> .libs/libprotocol_la-protostrings.o'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x in ?? ()
>  binutils-2.34.0-10.fc33.x86_64
> (gdb) bt
> Missing separate debuginfos, use: dnf debuginfo-install#0  0x 
> in ?? ()
> #1  0x7f15bd3e03d0 in make_relative_prefix_1.part ()
>from /lib64/libbfd-2.34.0.20200522.so
> #2  0x7f15bd3d22db in bfd_plugin_object_p.lto_priv ()
>from /lib64/libbfd-2.34.0.20200522.so
> #3  0x7f15bd3401ce in bfd_check_format_matches ()
>from /lib64/libbfd-2.34.0.20200522.so
> #4  0x7f15bd340e7a in _bfd_write_archive_contents ()
>from /lib64/libbfd-2.34.0.20200522.so
> #5  0x7f15bd348b2a in bfd_close () from /lib64/libbfd-2.34.0.20200522.so
> #6  0x559ee83994b6 in write_archive ()
> #7  0x559ee8396ac3 in main ()
> 
> I can't find any BZ for this.  Any ideas what it could be?
Hmm, what's interesting here is that it's binutils-2.34, so it's not the update
that Nick was doing to do today.  I've seen a couple folks trip over this today
and just saw it in a couple of my builds.

I'll take a look.  I'm not much of a binutils hacker these days, but it's just
code.

jeff
> 
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Richard W.M. Jones]

On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> Hmm, what's interesting here is that it's binutils-2.34, so it's not
> the update that Nick was doing to do today.  I've seen a couple
> folks trip over this today and just saw it in a couple of my builds.

I believe it's the version that nickc just built in Rawhide this
afternoon.

> I'll take a look.  I'm not much of a binutils hacker these days, but
> it's just code.

Even simpler reproducer ...

$ ar cru test.a /dev/null
Segmentation fault (core dumped)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > the update that Nick was doing to do today.  I've seen a couple
> > folks trip over this today and just saw it in a couple of my builds.
> 
> I believe it's the version that nickc just built in Rawhide this
> afternoon.
Yea, but I'm probably to blame :-)


> 
> > I'll take a look.  I'm not much of a binutils hacker these days, but
> > it's just code.
> 
> Even simpler reproducer ...
> 
> $ ar cru test.a /dev/null
> Segmentation fault (core dumped)
Sweet.   I'm on it.

jeff
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > the update that Nick was doing to do today.  I've seen a couple
> > folks trip over this today and just saw it in a couple of my builds.
> 
> I believe it's the version that nickc just built in Rawhide this
> afternoon.
> 
> > I'll take a look.  I'm not much of a binutils hacker these days, but
> > it's just code.
> 
> Even simpler reproducer ...
> 
> $ ar cru test.a /dev/null
> Segmentation fault (core dumped)
But that's not triggering for me:(   Let me try with the nbdkit bits

jeff
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Stephen John Smoogen]

On Fri, 24 Jul 2020 at 17:51, Jeff Law  wrote:
>
> On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> > On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > > the update that Nick was doing to do today.  I've seen a couple
> > > folks trip over this today and just saw it in a couple of my builds.
> >
> > I believe it's the version that nickc just built in Rawhide this
> > afternoon.
> >
> > > I'll take a look.  I'm not much of a binutils hacker these days, but
> > > it's just code.
> >
> > Even simpler reproducer ...
> >
> > $ ar cru test.a /dev/null
> > Segmentation fault (core dumped)
> But that's not triggering for me:(   Let me try with the nbdkit bits
>

Would it help if the people having the problem gave a list of what
RPMs they have installed and what kernel they are running? That could
help cut down some of the guessing.

-- 
Stephen J Smoogen.
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Fri, 2020-07-24 at 17:55 -0400, Stephen John Smoogen wrote:
> On Fri, 24 Jul 2020 at 17:51, Jeff Law  wrote:
> > On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > > > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > > > the update that Nick was doing to do today.  I've seen a couple
> > > > folks trip over this today and just saw it in a couple of my builds.
> > > 
> > > I believe it's the version that nickc just built in Rawhide this
> > > afternoon.
> > > 
> > > > I'll take a look.  I'm not much of a binutils hacker these days, but
> > > > it's just code.
> > > 
> > > Even simpler reproducer ...
> > > 
> > > $ ar cru test.a /dev/null
> > > Segmentation fault (core dumped)
> > But that's not triggering for me:(   Let me try with the nbdkit bits
> > 
> 
> Would it help if the people having the problem gave a list of what
> RPMs they have installed and what kernel they are running? That could
> help cut down some of the guessing.
No need.  I've reproduced it with the nbdkit package.  Proceeding to debugging.

jeff
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Jeff Law]

On Fri, 2020-07-24 at 17:55 -0400, Stephen John Smoogen wrote:
> On Fri, 24 Jul 2020 at 17:51, Jeff Law  wrote:
> > On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > > > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > > > the update that Nick was doing to do today.  I've seen a couple
> > > > folks trip over this today and just saw it in a couple of my builds.
> > > 
> > > I believe it's the version that nickc just built in Rawhide this
> > > afternoon.
> > > 
> > > > I'll take a look.  I'm not much of a binutils hacker these days, but
> > > > it's just code.
> > > 
> > > Even simpler reproducer ...
> > > 
> > > $ ar cru test.a /dev/null
> > > Segmentation fault (core dumped)
> > But that's not triggering for me:(   Let me try with the nbdkit bits
> > 
> 
> Would it help if the people having the problem gave a list of what
> RPMs they have installed and what kernel they are running? That could
> help cut down some of the guessing.
What would help would be if someone could untag that version of binutils so that
it doesn't show up in the buildroots anymore.  It's clearly fubar'd.

What exceedingly weird is it looks like like we've got a call through the PLT to
a routine that should be defined, but the PLT entry is zero.  Naturally that
causes bad things to happen.

Jeff
___
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: ar (binutils) segfaulting in Rawhide - known bug?

[Kevin Fenzi]

On Fri, Jul 24, 2020 at 04:55:31PM -0600, Jeff Law wrote:
> On Fri, 2020-07-24 at 17:55 -0400, Stephen John Smoogen wrote:
> > On Fri, 24 Jul 2020 at 17:51, Jeff Law  wrote:
> > > On Fri, 2020-07-24 at 22:40 +0100, Richard W.M. Jones wrote:
> > > > On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote:
> > > > > Hmm, what's interesting here is that it's binutils-2.34, so it's not
> > > > > the update that Nick was doing to do today.  I've seen a couple
> > > > > folks trip over this today and just saw it in a couple of my builds.
> > > > 
> > > > I believe it's the version that nickc just built in Rawhide this
> > > > afternoon.
> > > > 
> > > > > I'll take a look.  I'm not much of a binutils hacker these days, but
> > > > > it's just code.
> > > > 
> > > > Even simpler reproducer ...
> > > > 
> > > > $ ar cru test.a /dev/null
> > > > Segmentation fault (core dumped)
> > > But that's not triggering for me:(   Let me try with the nbdkit bits
> > > 
> > 
> > Would it help if the people having the problem gave a list of what
> > RPMs they have installed and what kernel they are running? That could
> > help cut down some of the guessing.
> What would help would be if someone could untag that version of binutils so 
> that
> it doesn't show up in the buildroots anymore.  It's clearly fubar'd.

Done.

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

cmake has broken python

[Luya Tshimbalanga]

Bug report filed: https://bugzilla.redhat.com/show_bug.cgi?id=1860546

On 2020-07-23 11:02 p.m., Luya Tshimbalanga wrote:


Hello team,

It looks like something broke inside cmake when attempting to detect 
python:


CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 
(message):
   Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH
   PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)
Call Stack (most recent call first):
   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:445 
(_FPHSA_FAILURE_MESSAGE)
   build_files/cmake/Modules/FindPythonLibsUnix.cmake:180 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
   build_files/cmake/platform/platform_unix.cmake:99 (find_package)
   CMakeLists.txt:812 (include)
-- Configuring incomplete, errors occurred!
See also 
"/builddir/build/BUILD/blender-2.83.3/build/CMakeFiles/CMakeOutput.log".


Can someone investigate the issue?

Reference: https://koji.fedoraproject.org/koji/taskinfo?taskID=47730766

Thanks

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

___
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


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

___
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

[Test-Announce] Proposal to CANCEL: 2020-07-27 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
have anything urgent this week. Also I'm going to be on vacation.

If you're aware of anything important we have to discuss this week,
please do reply to this mail, but someone else will need to run the
meeting :)

Also not going to propose a blocker meeting this week, there is only
one proposed blocker currently.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.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