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
On Mon, Nov 8, 2021 at 8:07 AM Florian Weimer fweimer@redhat.com 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).
* 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
On Mon, Nov 8, 2021 at 8:27 AM Florian Weimer fweimer@redhat.com 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.
* 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
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
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@lists.fedoraproject.org To unsubscribe send an email todevel-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
* 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
* 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
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
* 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
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
On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi kevin@scrye.com 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
On 16. 11. 21 21:23, Fabio Valentini wrote:
On Fri, Nov 12, 2021 at 10:06 PM Kevin Fenzi kevin@scrye.com 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).