Long-running side tag for porting Fedora to C99 (no implicit decls)

[Florian Weimer]

I would like to create a long-running rawhide side tag for preparing
Fedora for the removal of implicit function declarations from the GCC
defaults.  This is a change that happened in the C99 version of the
language, but GCC could not adopt at the time because too much software
was broken by it.  Even today, there are build failures, and, arguably
worse, successful builds with different feature sets.

The goal is to disable implicit function declarations in GCC 13, to be
released in spring 2023 (not next year's GCC 12 version).  This plan was
presented at this year's Cauldron, and was met with approval:

  Eliminating implicit function declarations
  <https://linuxplumbersconf.org/event/11/contributions/1014/>

I have some space to work on this during the coming months, for
implementing the buildroot changes (in gcc and presumably
redhat-rpm-config, built off branches in dist-git), for creating some
HTML reports, and even for creating the package changes themselves.
Changes will be submitted to upstream projects initially.  Eventually,
we'll have to fix the Fedora packages if there's no upstream release
with the fixes.  We'll need some way to coordinate the fixes between
multiple developers, a way to find unapplied upstream fixes once we are
heading towards Fedora 38, and ideally some way to share patches across
distributions if the upstream project no longer exists/accepts patches.

If Fedora wants to support this, I'd need a long-running side tag in
Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
can do the test builds as scratch builds, to conserve storage space and
not to pollute Koji with uninteresting NVRs.

Thoughts?

Thanks,
Florian

[Neal Gompa]

On Mon, Nov 8, 2021 at 8:07 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  I would like to create a long-running rawhide side tag for preparing
>  Fedora for the removal of implicit function declarations from the GCC
>  defaults.  This is a change that happened in the C99 version of the
>  language, but GCC could not adopt at the time because too much software
>  was broken by it.  Even today, there are build failures, and, arguably
>  worse, successful builds with different feature sets.
>
>  The goal is to disable implicit function declarations in GCC 13, to be
>  released in spring 2023 (not next year's GCC 12 version).  This plan was
>  presented at this year's Cauldron, and was met with approval:
>
>    Eliminating implicit function declarations
>    <https://linuxplumbersconf.org/event/11/contributions/1014/>
>
>  I have some space to work on this during the coming months, for
>  implementing the buildroot changes (in gcc and presumably
>  redhat-rpm-config, built off branches in dist-git), for creating some
>  HTML reports, and even for creating the package changes themselves.
>  Changes will be submitted to upstream projects initially.  Eventually,
>  we'll have to fix the Fedora packages if there's no upstream release
>  with the fixes.  We'll need some way to coordinate the fixes between
>  multiple developers, a way to find unapplied upstream fixes once we are
>  heading towards Fedora 38, and ideally some way to share patches across
>  distributions if the upstream project no longer exists/accepts patches.
>
>  If Fedora wants to support this, I'd need a long-running side tag in
>  Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
>  can do the test builds as scratch builds, to conserve storage space and
>  not to pollute Koji with uninteresting NVRs.
>
>  Thoughts?
>  
Seems like a worthy effort to me. Though instead of having branches
for redhat-rpm-config, you could add macros to flag it on and off by
default, and have releng configure a side-tag for you that turns it on
for package builds (we can have macros set for build tags).



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Florian Weimer]

* Neal Gompa:

>  Seems like a worthy effort to me. Though instead of having branches
>  for redhat-rpm-config, you could add macros to flag it on and off by
>  default, and have releng configure a side-tag for you that turns it on
>  for package builds (we can have macros set for build tags). 
Is it possible to set a dist tag suffix for the branch, then?  In
combination with the flag approach, that would actually be more
convenient (assuming the gcc folks are okay with a conditionally applied
patch for that branch).

Thanks,
Florian

[Neal Gompa]

On Mon, Nov 8, 2021 at 8:27 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Neal Gompa:
>
>  > Seems like a worthy effort to me. Though instead of having branches
>  > for redhat-rpm-config, you could add macros to flag it on and off by
>  > default, and have releng configure a side-tag for you that turns it on
>  > for package builds (we can have macros set for build tags).
>
>  Is it possible to set a dist tag suffix for the branch, then?  In
>  combination with the flag approach, that would actually be more
>  convenient (assuming the gcc folks are okay with a conditionally applied
>  patch for that branch).
>  
You can set the dist tag suffix in the build tag too. That's what we
do for ELN, for example.

You can set any number of macros this way and use them as flags to
trigger behavioral differences in packages submitted to build. The way
*I* suggest doing it (you may choose another way, of course) would be
to set the flags up in the build tag and build from the rawhide
branch. Fixes for C99 should be integrated straight into the mainline
rawhide branch anyway.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Florian Weimer wrote:
>  Eventually, we'll have to fix the Fedora packages if there's
> no upstream
>  release with the fixes. 
We just have to add -Wno-error=implicit-function-declaration to the build 
flags of the offending packages (same as for format-security).

        Kevin Kofler

[Florian Weimer]

* Kevin Kofler via devel:

>  Florian Weimer wrote:
> > Eventually, we'll have to fix the Fedora packages if there's no upstream
> > release with the fixes.
>
>  We just have to add -Wno-error=implicit-function-declaration to the build 
>  flags of the offending packages (same as for format-security). 
For some packages, that is unfortunately more difficult than fixing the
actual source of the incompatibility.

Thanks,
Florian

[Kevin Fenzi]

On Mon, Nov 08, 2021 at 02:06:43PM +0100, Florian Weimer wrote:
>  I would like to create a long-running rawhide side tag for preparing
>  Fedora for the removal of implicit function declarations from the GCC
>  defaults.  This is a change that happened in the C99 version of the
>  language, but GCC could not adopt at the time because too much software
>  was broken by it.  Even today, there are build failures, and, arguably
>  worse, successful builds with different feature sets.
>  
>  The goal is to disable implicit function declarations in GCC 13, to be
>  released in spring 2023 (not next year's GCC 12 version).  This plan was
>  presented at this year's Cauldron, and was met with approval:
>  
>    Eliminating implicit function declarations
>    <https://linuxplumbersconf.org/event/11/contributions/1014/>
>  
>  I have some space to work on this during the coming months, for
>  implementing the buildroot changes (in gcc and presumably
>  redhat-rpm-config, built off branches in dist-git), for creating some
>  HTML reports, and even for creating the package changes themselves.
>  Changes will be submitted to upstream projects initially.  Eventually,
>  we'll have to fix the Fedora packages if there's no upstream release
>  with the fixes.  We'll need some way to coordinate the fixes between
>  multiple developers, a way to find unapplied upstream fixes once we are
>  heading towards Fedora 38, and ideally some way to share patches across
>  distributions if the upstream project no longer exists/accepts patches.
>  
>  If Fedora wants to support this, I'd need a long-running side tag in
>  Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
>  can do the test builds as scratch builds, to conserve storage space and
>  not to pollute Koji with uninteresting NVRs.
>  
>  Thoughts? 
Isn't this an ideal use case for copr? 
Or is the lack of s390x (and non emulated armv7) there too much of a hurdle?

kevin

[Vít Ondruch]

Dne 08. 11. 21 v 21:39 Kevin Fenzi napsal(a):
>  On Mon, Nov 08, 2021 at 02:06:43PM +0100, Florian Weimer wrote:
> > I would like to create a long-running rawhide side tag for preparing
> > Fedora for the removal of implicit function declarations from the GCC
> > defaults.  This is a change that happened in the C99 version of the
> > language, but GCC could not adopt at the time because too much software
> > was broken by it.  Even today, there are build failures, and, arguably
> > worse, successful builds with different feature sets.
> >
> > The goal is to disable implicit function declarations in GCC 13, to be
> > released in spring 2023 (not next year's GCC 12 version).  This plan was
> > presented at this year's Cauldron, and was met with approval:
> >
> >    Eliminating implicit function declarations
> >    <https://linuxplumbersconf.org/event/11/contributions/1014/>
> >
> > I have some space to work on this during the coming months, for
> > implementing the buildroot changes (in gcc and presumably
> > redhat-rpm-config, built off branches in dist-git), for creating some
> > HTML reports, and even for creating the package changes themselves.
> > Changes will be submitted to upstream projects initially.  Eventually,
> > we'll have to fix the Fedora packages if there's no upstream release
> > with the fixes.  We'll need some way to coordinate the fixes between
> > multiple developers, a way to find unapplied upstream fixes once we are
> > heading towards Fedora 38, and ideally some way to share patches across
> > distributions if the upstream project no longer exists/accepts patches.
> >
> > If Fedora wants to support this, I'd need a long-running side tag in
> > Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
> > can do the test builds as scratch builds, to conserve storage space and
> > not to pollute Koji with uninteresting NVRs.
> >
> > Thoughts?
>  Isn't this an ideal use case for copr?
>  

+1

Or maybe I just don't understand how the side-tag is going to be used. 
Will there be some modifications necessary for some packages (except 
those already listed)? Will these changes be compatible with rawhide? 
Will the side-tag ever be merged back into Rawhide?


Vít


>  Or is the lack of s390x (and non emulated armv7) there too much of a
> hurdle?
>
>  kevin
>
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
>

[Florian Weimer]

* Vít Ondruch:

>  Or maybe I just don't understand how the side-tag is going to be
>  used. Will there be some modifications necessary for some packages
>  (except those already listed)? 
The modifications can go directly into rawhide because they are
compatible with older compilers.  But at least in the beginning, I plan
to submit them just to upstream, hoping that the Fedora package gets
rebase to an upstream release with the fix before the switch to GCC 13.

>  Will these changes be compatible with rawhide? Will the side-tag
> ever
>  be merged back into Rawhide? 
The side tag will not be merged back.

Thanks,
Florian

[Florian Weimer]

* Kevin Fenzi:

>  Isn't this an ideal use case for copr? 
I don't know.  I could piece together the Koji API fairly easily, and
had hoped to reuse some of the script logic.

Or does COPR have direct support this?  Can I tell it directly to report
rawhide in a special buildroot?  Is there a programmatic way to access
the resulting log files?

(I won't need the built RPMs, which is why I would use scratch builds in
Koji.)

>  Or is the lack of s390x (and non emulated armv7) there too much of a
> hurdle? 
I would prefer to test on the real thing, true.

Thanks,
Florian

[Kevin Fenzi]

On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
>  * Kevin Fenzi:
>  
>  > Isn't this an ideal use case for copr?
>  
>  I don't know.  I could piece together the Koji API fairly easily, and
>  had hoped to reuse some of the script logic.
>  
>  Or does COPR have direct support this?  Can I tell it directly to report
>  rawhide in a special buildroot?  Is there a programmatic way to access
>  the resulting log files?
>  
>  (I won't need the built RPMs, which is why I would use scratch builds in
>  Koji.) 
Yes, copr has a api also. 
https://python-copr.readthedocs.io/en/latest/ClientV3.html

>  > Or is the lack of s390x (and non emulated armv7) there too much
> of a hurdle?
>  
>  I would prefer to test on the real thing, true. 
Yeah, thats the one reason I was wondering about suggesting copr, but
other than the arch issues I think it may be a better fit for this. 

kevin

[Florian Weimer]

* Kevin Fenzi:

>  On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
> > * Kevin Fenzi:
> > 
> > > Isn't this an ideal use case for copr?
> > 
> > I don't know.  I could piece together the Koji API fairly easily, and
> > had hoped to reuse some of the script logic.
> > 
> > Or does COPR have direct support this?  Can I tell it directly to report
> > rawhide in a special buildroot?  Is there a programmatic way to access
> > the resulting log files?
> > 
> > (I won't need the built RPMs, which is why I would use scratch builds in
> > Koji.)
>
>  Yes, copr has a api also. 
>  https://python-copr.readthedocs.io/en/latest/ClientV3.html 
Is there an overview similar to <https://koji.fedoraproject.org/koji/api>?
It's hard to tell what the capbilities are.

Thanks,
Florian

[Kevin Fenzi]

On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:
>  * Kevin Fenzi:
>  
>  > On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
>  >> * Kevin Fenzi:
>  >> 
>  >> > Isn't this an ideal use case for copr?
>  >> 
>  >> I don't know.  I could piece together the Koji API fairly easily, and
>  >> had hoped to reuse some of the script logic.
>  >> 
>  >> Or does COPR have direct support this?  Can I tell it directly to report
>  >> rawhide in a special buildroot?  Is there a programmatic way to access
>  >> the resulting log files?
>  >> 
>  >> (I won't need the built RPMs, which is why I would use scratch builds in
>  >> Koji.)
>  >
>  > Yes, copr has a api also. 
>  > https://python-copr.readthedocs.io/en/latest/ClientV3.html
>  
>  Is there an overview similar to <https://koji.fedoraproject.org/koji/api>?
>  It's hard to tell what the capbilities are. 
I'm not sure and I was hoping one of the copr folks would chime in. ;) 

CCing praiskup

kevin

[Fabio Valentini]

On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:
>  > * Kevin Fenzi:
>  >
>  > > On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
>  > >> * Kevin Fenzi:
>  > >>
>  > >> > Isn't this an ideal use case for copr?
>  > >>
>  > >> I don't know.  I could piece together the Koji API fairly easily, and
>  > >> had hoped to reuse some of the script logic.
>  > >>
>  > >> Or does COPR have direct support this?  Can I tell it directly to report
>  > >> rawhide in a special buildroot?  Is there a programmatic way to access
>  > >> the resulting log files?
>  > >>
>  > >> (I won't need the built RPMs, which is why I would use scratch builds
> in
>  > >> Koji.)
>  > >
>  > > Yes, copr has a api also.
>  > > https://python-copr.readthedocs.io/en/latest/ClientV3.html
>  >
>  > Is there an overview similar to <https://koji.fedoraproject.org/koji/api>?
>  > It's hard to tell what the capbilities are.
>
>  I'm not sure and I was hoping one of the copr folks would chime in. ;)
>
>  CCing praiskup 
I'm pretty sure the Python team is doing something very similar for
their Python, Sphinx, etc. rebase test build COPRs, like this one for
Python 3.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/

They're set up so that any dist-git commits (and PRs) are
automatically rebuilt in that COPR.
The COPR command-line tool (copr-cli) provides all commands that are
needed to set that up, as far as I know - so the copr python module
should do that, too.

Fabio

[Miro Hrončok]

On 16. 11. 21 21:23, Fabio Valentini wrote:
>  On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
> >
> > On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:
> >> * Kevin Fenzi:
> >>
> >>> On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
> >>>> * Kevin Fenzi:
> >>>>
> >>>>> Isn't this an ideal use case for copr?
> >>>>
> >>>> I don't know.  I could piece together the Koji API fairly easily,
> and
> >>>> had hoped to reuse some of the script logic.
> >>>>
> >>>> Or does COPR have direct support this?  Can I tell it directly to report
> >>>> rawhide in a special buildroot?  Is there a programmatic way to access
> >>>> the resulting log files?
> >>>>
> >>>> (I won't need the built RPMs, which is why I would use scratch builds
> in
> >>>> Koji.)
> >>>
> >>> Yes, copr has a api also.
> >>> https://python-copr.readthedocs.io/en/latest/ClientV3.html
> >>
> >> Is there an overview similar to <https://koji.fedoraproject.org/koji/api>?
> >> It's hard to tell what the capbilities are.
> >
> > I'm not sure and I was hoping one of the copr folks would chime in. ;)
> >
> > CCing praiskup
>  
>  I'm pretty sure the Python team is doing something very similar for
>  their Python, Sphinx, etc. rebase test build COPRs, like this one for
>  Python 3.10:
>  https://copr.fedorainfracloud.org/coprs/g/python/python3.10/
>  
>  They're set up so that any dist-git commits (and PRs) are
>  automatically rebuilt in that COPR.
>  The COPR command-line tool (copr-cli) provides all commands that are
>  needed to set that up, as far as I know - so the copr python module
>  should do that, too. 
The one for Python 3.10 has the automation already disabled, but there's one 
for Python 3.11 now:

https://copr.fedorainfracloud.org/coprs/g/python/python3.11/

One advantage of this automation is that any Pull Request to rawhide branch of 
tracked packages appears as a result in that Copr as well (the build is 
isolated from the others, similarly to Koji scratch-builds).

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok