c99-port branches in dist-git

[Florian Weimer]

I'm going to push a branch to dist-git for very few packages (so far gcc
and redhat-rpm-config) which will be used by COPR builds to port Fedora
to C99 and later language standards.

GCC 14 is expected to reject certain constructs that were removed from C
in C99:

  * implicit function declarations
  * implicit ints
  * implicit conversion between pointers and int
    (that may not have been in C89 even; details still pending)

It's possible to build with -std=gnu89 or -std=c89 to re-enable these
constructs, or fix the sources not to use them.  Implicit function
declarations in particular have wasted countless programmer hours due to
difficult-to-track-down ABI mismatches, so it's definitely desirable to
cause them to fail the build.

We have tooling that identifies these constructs if GCC is used, even if
they are used in configure check.  Unexpected failures in configure
checks can be tricky because if the package is well-written, the end
result is still a consistent build with some expected failures missing,
corresponding testsuite bits disabled etc.

We will contribute fixes upstream and to rawhide, either by fixing the
sources or switch to C89 mode where it is unlikely source changes will
be acceptable to upstream.  The c99-port dist-git branch will only be
used for our support tooling that should not be used by production
builds in the rawhide buildroot.  As this is necessarily a
cross-distribution effort, there will be some tracking mechanism to
record and share patches for which no active upstream exists anymore.

C++ packages are only affected in so far as they use the C compiler in
configure checks: these constructs haven't been part of C++ for a long,
long time and may not have been implemented in G++, ever.

I hope to submit a formal Fedora 40 change proposal after some initial
experiments.

Thanks,
Florian

[Fabio Valentini]

On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  I'm going to push a branch to dist-git for very few packages (so far gcc
>  and redhat-rpm-config) which will be used by COPR builds to port Fedora
>  to C99 and later language standards. 
So you only plan to trigger COPR builds from these branches, but not
any koji builds? If that is the case, you might want to create and
push these branches only in forks, not in the "official" dist-git
repos (COPR can build from both). Otherwise the branches might need to
stick around "forever".

Fabio

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 19, 2022 at 01:49:33PM +0200, Fabio Valentini wrote:
>  On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer
> <fweimer(a)redhat.com&gt; wrote:
>  >
>  > I'm going to push a branch to dist-git for very few packages (so far gcc
>  > and redhat-rpm-config) which will be used by COPR builds to port Fedora
>  > to C99 and later language standards.
>  
>  So you only plan to trigger COPR builds from these branches, but not
>  any koji builds? If that is the case, you might want to create and
>  push these branches only in forks, not in the "official" dist-git
>  repos (COPR can build from both). Otherwise the branches might need to
>  stick around "forever". 
I think we changed the policy to allow removal of branches which don't have
any commits not reachable from other branches from which no koji builds have
been made (https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py).

Zbyszek

[Miro Hrončok]

On 19. 10. 22 17:24, Zbigniew Jędrzejewski-Szmek wrote:
>  On Wed, Oct 19, 2022 at 01:49:33PM +0200, Fabio Valentini wrote:
> > On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> >>
> >> I'm going to push a branch to dist-git for very few packages (so far gcc
> >> and redhat-rpm-config) which will be used by COPR builds to port Fedora
> >> to C99 and later language standards.
> >
> > So you only plan to trigger COPR builds from these branches, but not
> > any koji builds? If that is the case, you might want to create and
> > push these branches only in forks, not in the "official" dist-git
> > repos (COPR can build from both). Otherwise the branches might need to
> > stick around "forever".
>  
>  I think we changed the policy to allow removal of branches which don't have
>  any commits not reachable from other branches from which no koji builds have
>  been made (https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py).
The policy was created to allow undoing accidental pushes, not to encourage 
branching like this.

I'm with Fabio. If it's for Copr only, please use a fork.

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

[Florian Weimer]

* Miro Hrončok:

>  On 19. 10. 22 17:24, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Oct 19, 2022 at 01:49:33PM +0200, Fabio Valentini wrote:
> >> On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer <fweimer(a)redhat.com&gt;
> wrote:
> >>>
> >>> I'm going to push a branch to dist-git for very few packages (so far gcc
> >>> and redhat-rpm-config) which will be used by COPR builds to port Fedora
> >>> to C99 and later language standards.
> >>
> >> So you only plan to trigger COPR builds from these branches, but not
> >> any koji builds? If that is the case, you might want to create and
> >> push these branches only in forks, not in the "official" dist-git
> >> repos (COPR can build from both). Otherwise the branches might need to
> >> stick around "forever".
> > I think we changed the policy to allow removal of branches which
> > don't have
> > any commits not reachable from other branches from which no koji builds have
> > been made (https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py).
>
>  The policy was created to allow undoing accidental pushes, not to
>  encourage branching like this.
>
>  I'm with Fabio. If it's for Copr only, please use a fork. 
It wasn't intended to use COPR originally, it's just that Fedora releng
ignored my request for close to a year.

I filed <https://pagure.io/releng/issue/11102> for the branch removals.

I must say this is quite confusing.  Why offer self-service branch
creation at all if we aren't supposed to use it in general?

What's the recommended way to collaborate with packages/provenpackagers?
Someone's personal fork on src.fedoraproject.org with a branch with a
wide-open ACL?

Thanks,
Florian

[Richard W.M. Jones]

On Wed, Oct 19, 2022 at 11:30:59AM +0200, Florian Weimer wrote:
>  I'm going to push a branch to dist-git for very few packages (so
> far gcc
>  and redhat-rpm-config) which will be used by COPR builds to port Fedora
>  to C99 and later language standards.
>  
>  GCC 14 is expected to reject certain constructs that were removed from C
>  in C99: 
If we're changing defaults, could we make -fPIC the default and have
-fno-pic be an explicit choice?

Finding every place in the OCaml toolchain that passes flags to the
compiler is very tedious, I had another bug filed about it only a few
days ago.  This would all go away if -fPIC was simply the default.
AIUI on x86-64 because of rip-relative addressing there's no serious
penalty.

Rich.

>    * implicit function declarations
>    * implicit ints
>    * implicit conversion between pointers and int
>      (that may not have been in C89 even; details still pending)
>  
>  It's possible to build with -std=gnu89 or -std=c89 to re-enable these
>  constructs, or fix the sources not to use them.  Implicit function
>  declarations in particular have wasted countless programmer hours due to
>  difficult-to-track-down ABI mismatches, so it's definitely desirable to
>  cause them to fail the build.
>  
>  We have tooling that identifies these constructs if GCC is used, even if
>  they are used in configure check.  Unexpected failures in configure
>  checks can be tricky because if the package is well-written, the end
>  result is still a consistent build with some expected failures missing,
>  corresponding testsuite bits disabled etc.
>  
>  We will contribute fixes upstream and to rawhide, either by fixing the
>  sources or switch to C89 mode where it is unlikely source changes will
>  be acceptable to upstream.  The c99-port dist-git branch will only be
>  used for our support tooling that should not be used by production
>  builds in the rawhide buildroot.  As this is necessarily a
>  cross-distribution effort, there will be some tracking mechanism to
>  record and share patches for which no active upstream exists anymore.
>  
>  C++ packages are only affected in so far as they use the C compiler in
>  configure checks: these constructs haven't been part of C++ for a long,
>  long time and may not have been implemented in G++, ever.
>  
>  I hope to submit a formal Fedora 40 change proposal after some initial
>  experiments.
>  
>  Thanks,
>  Florian
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-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, report it: https://pagure.io/fedora-infrastructure/new_issue
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Florian Weimer]

* Richard W. M. Jones:

>  On Wed, Oct 19, 2022 at 11:30:59AM +0200, Florian Weimer wrote:
> > I'm going to push a branch to dist-git for very few packages (so far gcc
> > and redhat-rpm-config) which will be used by COPR builds to port Fedora
> > to C99 and later language standards.
> > 
> > GCC 14 is expected to reject certain constructs that were removed from C
> > in C99:
>
>  If we're changing defaults, could we make -fPIC the default and have
>  -fno-pic be an explicit choice? 
There's no consensus for within Red Hat Platform Tools to build GCC with
--enable-default-pie (which is the closest that exists upstream today),
so no.

Thanks,
Florian

[Fabio Valentini]

On Thu, Oct 20, 2022 at 12:12 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Miro Hrončok:
>
>  > On 19. 10. 22 17:24, Zbigniew Jędrzejewski-Szmek wrote:
>  >> On Wed, Oct 19, 2022 at 01:49:33PM +0200, Fabio Valentini wrote:
>  >>> On Wed, Oct 19, 2022 at 11:31 AM Florian Weimer <fweimer(a)redhat.com&gt;
> wrote:
>  >>>>
>  >>>> I'm going to push a branch to dist-git for very few packages (so far
> gcc
>  >>>> and redhat-rpm-config) which will be used by COPR builds to port Fedora
>  >>>> to C99 and later language standards.
>  >>>
>  >>> So you only plan to trigger COPR builds from these branches, but not
>  >>> any koji builds? If that is the case, you might want to create and
>  >>> push these branches only in forks, not in the "official" dist-git
>  >>> repos (COPR can build from both). Otherwise the branches might need to
>  >>> stick around "forever".
>  >> I think we changed the policy to allow removal of branches which
>  >> don't have
>  >> any commits not reachable from other branches from which no koji builds have
>  >> been made
> (https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py).
>  >
>  > The policy was created to allow undoing accidental pushes, not to
>  > encourage branching like this.
>  >
>  > I'm with Fabio. If it's for Copr only, please use a fork.
>
>  It wasn't intended to use COPR originally, it's just that Fedora releng
>  ignored my request for close to a year.
>
>  I filed <https://pagure.io/releng/issue/11102> for the branch removals.
>
>  I must say this is quite confusing.  Why offer self-service branch
>  creation at all if we aren't supposed to use it in general?
>
>  What's the recommended way to collaborate with packages/provenpackagers?
>  Someone's personal fork on src.fedoraproject.org with a branch with a
>  wide-open ACL? 
Either that (provenpackagers can already push to forks on src.fp.o),
or just push fixes to the rawhide branch directly?

Also, the benefit of using COPR would be that you can set up
continuous integration, as COPR will automatically launch builds for
new commits in dist-git, and for any PRs that are filed. You might
want to ask the Python maintainers how they handle this for Python
rebases - as far as I know, they have scripts that automate large
parts of this process, which you could benefit from for this change,
as well (they build rawhide against newer Python, you're going to
build rawhide against different GCC, so the use case is pretty
similar). I think the only difference might be that you'll want to
enable more architectures than just x86_64?

Fabio

[Florian Weimer]

* Fabio Valentini:

> > It wasn't intended to use COPR originally, it's just that
> Fedora releng
> > ignored my request for close to a year.
> >
> > I filed <https://pagure.io/releng/issue/11102> for the branch removals.
> >
> > I must say this is quite confusing.  Why offer self-service branch
> > creation at all if we aren't supposed to use it in general?
> >
> > What's the recommended way to collaborate with packages/provenpackagers?
> > Someone's personal fork on src.fedoraproject.org with a branch with a
> > wide-open ACL?
>
>  Either that (provenpackagers can already push to forks on src.fp.o),
>  or just push fixes to the rawhide branch directly? 
This was for the infrastructure support, i.e. given maintainers a
compiler & buildroot with which they can validate their fixes.  These
changes cannot be pushed to rawhide because we do not want to change the
compiler defaults there.

The individual package fixes can go into rawhide for sure.

Thanks,
Florian