Re: gcc 10: Default to -fno-common, multiple definitions of ...
by Jeff Law
>
>
>
> Date: Tue, 21 Jan 2020 11:05:37 -0500
> From: Steve Grubb <sgrubb(a)redhat.com>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> ...
> To: devel(a)lists.fedoraproject.org
> Cc: Jakub Jelinek <jakub(a)redhat.com>
> Message-ID: <4127758.jL2Gs7s9Fr@x2>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote:
> > This is a known thing in gcc 10:
> >
> > https://gcc.gnu.org/gcc-10/porting_to.html#common
> >
> > "Default to -fno-common
> >
> > A common mistake in C is omitting extern when declaring a global variable
> > in a header file. If the header is included by several files it results in
> > multiple definitions of the same variable. In previous GCC versions this
> > error is ignored. GCC 10 defaults to -fno-common, which means a linker
> > error will now be reported. To fix this, use extern in header files when
> > declaring global variables, and ensure each global is defined in exactly
> > one C file. As a workaround, legacy C code can be compiled with -fcommon.
> >
> >
> > int x; // tentative definition - avoid in header files
> >
> > extern int y; // correct declaration in a header file"
>
> So, for those of us using F31 as the development / test environment, is there
> a macro that we can add -fno-common to in ~/.rpmmacros without placing it in
> the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ?
>
> Looking for an easy way to reproduce this without modifying root owned files.
>
> -Steve
>
>
> ------------------------------
>
> Date: Tue, 21 Jan 2020 17:27:20 +0100
> From: Miro Hrončok <mhroncok(a)redhat.com>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> ...
> To: Steve Grubb <sgrubb(a)redhat.com>, devel(a)lists.fedoraproject.org
> Message-ID: <0f655139-44f5-a0c5-b600-66614c8bd6d6(a)redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 21. 01. 20 17:05, Steve Grubb wrote:
> > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote:
> > > This is a known thing in gcc 10:
> > >
> > > https://gcc.gnu.org/gcc-10/porting_to.html#common
> > >
> > > "Default to -fno-common
> > >
> > > A common mistake in C is omitting extern when declaring a global variable
> > > in a header file. If the header is included by several files it results in
> > > multiple definitions of the same variable. In previous GCC versions this
> > > error is ignored. GCC 10 defaults to -fno-common, which means a linker
> > > error will now be reported. To fix this, use extern in header files when
> > > declaring global variables, and ensure each global is defined in exactly
> > > one C file. As a workaround, legacy C code can be compiled with -fcommon.
> > >
> > >
> > > int x; // tentative definition - avoid in header files
> > >
> > > extern int y; // correct declaration in a header file"
> >
> > So, for those of us using F31 as the development / test environment, is there
> > a macro that we can add -fno-common to in ~/.rpmmacros without placing it in
> > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ?
> >
> > Looking for an easy way to reproduce this without modifying root owned files.
>
> You should be able to redefine %__global_compiler_flags in ~/.rpmmacros.
> It still means you need to copy paste the current flags, but you won't need to
> touch root owned files.
I proposed a change to redhat-rpm-config to handle this case by
allowing package to add a single line to their .spec file to turn off
the new common symbol handling. Igor rejected that change arguing that
the packages themselves should be fixed.
Jeff
4 years, 2 months
Fedora 32 Self-Contained Change proposal: PostgreSQL 12
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PostgreSQL_12
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from 11 to 12 version in the non-modular (main) builds.
== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panovotn(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from 11 to 12 version in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Benefit to Fedora ==
Latest stable software is used by Fedora users.
Version v12 of PostgreSQL introduces several enahncements and
performance improvementes:
https://www.postgresql.org/about/news/1976/
== Scope ==
* Proposal owners:
**Prepare PostgreSQL 12 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 11 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 12 to Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 11 and PostgreSQL 12
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible, so
there shouldn't be any issues, but rebuild of the depended components
is better to be sure.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 12.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade`.
If users want to stick with PostgreSQL 11 for a little longer, there
should be PostgreSQL 11 module.
If users want to test it before it reaches Fedora 32, there is
PostgreSQL 12 module already.
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.
== Contingency Plan ==
Modules will provide the functional version of PostgreSQL 11,
available to all users.
* Contingency mechanism: Fedora Modules available
* Contingency deadline: beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
Upgrade startegy: https://www.postgresql.org/docs/12/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 12 release:
https://www.postgresql.org/docs/12/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/about/news/1976/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 2 months
[modularity] Meeting Minutes - Jan 14, 2020
by Langdon White
Minutes:
https://meetbot.fedoraproject.org/teams/modularity/modularity.2020-01-14-...
Minutes (text):
https://meetbot-raw.fedoraproject.org/teams/modularity/modularity.2020-01...
Log:
https://meetbot.fedoraproject.org/teams/modularity/modularity.2020-01-14-...
==========================================
#fedora-meeting-3: Modularity Team Meeting
==========================================
Meeting started by langdon at 15:00:37 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-3/2020-01-14/modularit...
.
Meeting summary
---------------
* Roll Call (langdon, 15:00:55)
* agenda (langdon, 15:03:04)
* reviewing issues tagged with "meeting" (langdon, 15:04:45)
* CI test to enforce no-replace-base-packages policy for default streams
(170) (langdon, 15:06:08)
* LINK: https://pagure.io/modularity/issue/170 (langdon, 15:06:16)
* ACTION: contyk will get in touch with the CI team to see who could
own and implement such checks, as well as provide test definitions
later. (contyk, 15:31:30)
* Issue #169: Security vulnerabilities (CVEs) are not properly tracked
in modular packages - modularity - Pagure.io -
https://pagure.io/modularity/issue/169 (langdon, 15:32:10)
* #169 blocked by #166 and #163, when resolved, we will follow up with
the security team (langdon, 15:58:37)
* Issue #168: some thoughts on modularity docs - modularity - Pagure.io
- https://pagure.io/modularity/issue/168 (langdon, 15:58:56)
* contyk and langdon to review #168 and associated docs next week (jan
20, 2020) (langdon, 16:09:08)
Meeting ended at 16:10:13 UTC.
Action Items
------------
* contyk will get in touch with the CI team to see who could own and
implement such checks, as well as provide test definitions later.
Action Items, by person
-----------------------
* contyk
* contyk will get in touch with the CI team to see who could own and
implement such checks, as well as provide test definitions later.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* langdon (97)
* contyk (75)
* mhroncok (38)
* asamalik (34)
* zbyszek (20)
* zodbot (17)
* sct (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 2 months
Thank you for a way to requesting/merging side tags on demand.
by Vít Ondruch
Hi everybody,
I just like to thank everybody, who helped to have the possibility to
ask for side tag from fedpkg and allowed merging of the side tag via
Bodhi. This will make Rawhide much better place.
I encourage everybody, who is going to build more then just a few
packages to use this feature.
Vít
4 years, 2 months