Spec URL: https://labs.linuxnetz.de/bugzilla/gcc-epel.spec SRPM URL: https://labs.linuxnetz.de/bugzilla/gcc-epel-8.4.1-1.src.rpm Description: The gcc package contains the GNU Compiler Collection version 8. You'll need this package in order to compile C code. Fedora Account System Username: robert This package is intended only for EPEL 8 to provide the missing parts of the GNU Compiler Collection that Red Hat decided to remove for RHEL 8 (and it won't even change partially as stated e.g. in bug #1826731). So this is gcc-8.4.1-1.el8 from RHEL 8 modified to be installable along with the regular package and providing the missing parts. The package itself was as less modified as possible to make the differences hopefully easily reviewable. As building Ada/GNAT requires an already working Ada/GNAT compiler, there will be a bootstrap situation (which is part of the package) based on old Fedora packages.
Created attachment 1802916 [details] Diff between current GCC from RHEL 8 and this package
Is the plan to rebase this package on future RHEL packages as they are released, or is this package a fork that will have its own development line from this point? What do you plan to do with the bootstrapping bits after the package has been built in EPEL? Could you comment on _hardened_build? Did you undefine it just because Fedora does, or is there a better reason for that difference from the RHEL package? I think there should be comments explaining the changes to the dependencies. Someone who installs all of gcc-gnat, gcc-objc and gcc-objc++ will get three copies of the same file. I suggest to install the compiler driver once, as /usr/bin/gcc-complete or /usr/bin/gcc-epel, make all the other names links to that file, and include that file in the subpackages gcc-gnat and gcc-objc. Packages can share ownership of a file when the file is identical in the different packages. gcc-objc++ doesn't need to contain the compiler driver because it pulls in gcc-objc.
(In reply to Björn Persson from comment #2) > Is the plan to rebase this package on future RHEL packages as they are > released, or is this package a fork that will have its own development line > from this point? When looking to the RHEL 8 lifecycle, the upcoming rebase with RHEL 8.5 will be likely the last one for RHEL 8. However, the plan is to perform in general always the same rebases like RHEL (otherwise re-using the original complicated spec file doesn't make much sense). > What do you plan to do with the bootstrapping bits after the package has > been built in EPEL? They will be kept, because a) it is unclear whether a future rebase might force another bootstrap situation (and be it just due to RPM package build-time dependency issues) and b) there might be downstreams with other architectures not covered by EPEL (armv7hl, i686), who might see themself in the need of bootstrapping, too. > Could you comment on _hardened_build? Did you undefine it just because > Fedora does, or is there a better reason for that difference from the RHEL > package? As long as _hardened_build is defined, any simple package rebuild doesn't succeed for me. Not sure which tricks Red Hat used internally in their private build system (maybe they built the package using another gcc version). I however got this idea purely from the Fedora package (but the real intentions at Fedora for their change are unclear to me). > I think there should be comments explaining the changes to the dependencies. Which changes are you referring to exactly? The 'gcc(major)' one? It relaxes the strict dependency from same NEVRA to same N-major to avoid immediate RPM package dependency conflicts in case of minor release bumps due to rebuilds in RHEL and/or EPEL (it's quite unlikely that RHEL and EPEL will always be on exactly the same NEVRA). > Someone who installs all of gcc-gnat, gcc-objc and gcc-objc++ will get three > copies of the same file. I suggest to install the compiler driver once, as > /usr/bin/gcc-complete or /usr/bin/gcc-epel, make all the other names links > to that file, and include that file in the subpackages gcc-gnat and > gcc-objc. Packages can share ownership of a file when the file is identical > in the different packages. gcc-objc++ doesn't need to contain the compiler > driver because it pulls in gcc-objc. Do you really think that these three copies cause harm? Build environments never come in small, additionally I think it's a non-common case to really have all three subpackages installed at the same time.
(In reply to Robert Scheck from comment #3) > When looking to the RHEL 8 lifecycle, the upcoming rebase with RHEL 8.5 will > be likely the last one for RHEL 8. However, the plan is to perform in > general always the same rebases like RHEL (otherwise re-using the original > complicated spec file doesn't make much sense). If I understand you correctly, this means that any changes made to the RHEL package will make their way into the gcc-epel package, unless they break the Ada, Go or Objective C parts. Is that right? That makes this review much easier, because then I can pass over many things that, if they are considered problematic, should be fixed upstream rather than in this package. > They will be kept, because a) it is unclear whether a future rebase might > force another bootstrap situation (and be it just due to RPM package > build-time dependency issues) and b) there might be downstreams with other > architectures not covered by EPEL (armv7hl, i686), who might see themself in > the need of bootstrapping, too. This is reasonable, but I wonder about the "%if !0%{?epel_bootstrap}" conditions around the additions to the package descriptions. The instruction to use the other commands instead of "gcc" applies equally to bootstrapping packages and normal packages. Why did you conditionalize those paragraphs? > As long as _hardened_build is defined, any simple package rebuild doesn't > succeed for me. Not sure which tricks Red Hat used internally in their > private build system (maybe they built the package using another gcc > version). Then I think you should replace the comment "Hardening slows the compiler way too much." with one that mentions the build failure you saw. If you were adapting a spec file from Fedora, then I would say you should leave this part unchanged, but since you're introducing a change from the RHEL spec file, the associated comment should explain your actual reason for the change. (If it fails while building the GNAT tools, then it may be the same problem that we have with Ada packages in Fedora. The hardening tends to break linking of Ada programs.) > Which changes are you referring to exactly? The 'gcc(major)' one? Yes. > It relaxes > the strict dependency from same NEVRA to same N-major to avoid immediate RPM > package dependency conflicts in case of minor release bumps due to rebuilds > in RHEL and/or EPEL (it's quite unlikely that RHEL and EPEL will always be > on exactly the same NEVRA). That makes sense. Please write that in the spec. > Do you really think that these three copies cause harm? Build environments > never come in small, additionally I think it's a non-common case to really > have all three subpackages installed at the same time. Anyone who installs gcc-objc++ will have gcc-objc installed at the same time. /usr/bin/gobjc++ is a waste of bandwidth, repository storage space and developers' storage space. The harm is small but unnecessary. The file can be replaced with a link to gobjc at no cost. Merging gobjc with gnatgcc matters less. This would only save space on developers' workstations, and only if they install both gcc-gnat and gcc-objc, which may indeed be uncommon.
(In reply to Björn Persson from comment #4) > If I understand you correctly, this means that any changes made to the RHEL > package will make their way into the gcc-epel package, unless they break the > Ada, Go or Objective C parts. Is that right? Yes, your understanding is correct. > This is reasonable, but I wonder about the "%if !0%{?epel_bootstrap}" > conditions around the additions to the package descriptions. The instruction > to use the other commands instead of "gcc" applies equally to bootstrapping > packages and normal packages. Why did you conditionalize those paragraphs? Hm...good question. I guess it was too late at night, when I thought it would be clever. Thus I'll remove that. > Then I think you should replace the comment "Hardening slows the compiler > way too much." with one that mentions the build failure you saw. If you were > adapting a spec file from Fedora, then I would say you should leave this > part unchanged, but since you're introducing a change from the RHEL spec > file, the associated comment should explain your actual reason for the > change. > > (If it fails while building the GNAT tools, then it may be the same problem > that we have with Ada packages in Fedora. The hardening tends to break > linking of Ada programs.) Good point, I'll update that accordingly. > > It relaxes > > the strict dependency from same NEVRA to same N-major to avoid immediate RPM > > package dependency conflicts in case of minor release bumps due to rebuilds > > in RHEL and/or EPEL (it's quite unlikely that RHEL and EPEL will always be > > on exactly the same NEVRA). > That makes sense. Please write that in the spec. I thought that would be obvious, but I can indeed do so. > Anyone who installs gcc-objc++ will have gcc-objc installed at the same > time. /usr/bin/gobjc++ is a waste of bandwidth, repository storage space and > developers' storage space. The harm is small but unnecessary. The file can > be replaced with a link to gobjc at no cost. > > Merging gobjc with gnatgcc matters less. This would only save space on > developers' workstations, and only if they install both gcc-gnat and > gcc-objc, which may indeed be uncommon. Do I understand you correctly that you would be okay with this? gcc-gnat: /usr/bin/gnatgcc (binary) gcc-objc: /usr/bin/gobjc (binary) gcc-objc++: /usr/bin/gobjc++ -> gcc-gobjc (symlink) Because as per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_duplicate_files the other approach doesn't seem to be allowed anymore but I would like to avoid a separate gcc-epel binary package increasing the complexity while only saving ~ 1.5 MB more in the end in a less common usecase. Is there currently something else to correct or discuss before I update the (large) SRPM?
Yes I'm working on it.
(In reply to Robert Scheck from comment #5) > Do I understand you correctly that you would be okay with this? > > gcc-gnat: /usr/bin/gnatgcc (binary) > gcc-objc: /usr/bin/gobjc (binary) > gcc-objc++: /usr/bin/gobjc++ -> gcc-gobjc (symlink) You don't have a file named gcc-gobjc. I assume that you meant gobjc. Yes, I think that's acceptable. > Because as per > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_duplicate_files > the other approach doesn't seem to be allowed anymore That seems to contradict the first few paragraphs of the same section, where subpackages are explicitly allowed to contain identical files: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership I don't know how the FPC interprets those rules together, but let's go with gnatgcc and gobjc as separate files then. > Is there currently something else to correct or discuss before I update the > (large) SRPM? I found a few more things: · libgo-static and libgccjit still require the exact NEVR of gcc. Should those requirements also be relaxed? · There is a grammar error: "rather" should be "rather than" in three places. · RPMlint reports: gcc-gnat.x86_64: W: no-manual-page-for-binary gcc-gnat gcc-gnat.x86_64: W: no-manual-page-for-binary gnatgcc gcc-objc.x86_64: W: no-manual-page-for-binary gcc-objc gcc-objc.x86_64: W: no-manual-page-for-binary gobjc gcc-objc++.x86_64: W: no-documentation gcc-objc++.x86_64: W: no-manual-page-for-binary gcc-objc++ gcc-objc++.x86_64: W: no-manual-page-for-binary gobjc++ I don't think that's a big problem, but since it's easy to do, why not make some links to the gcc manpage? Like this: ln -s gcc.1 %{buildroot}%{_mandir}/man1/gnatgcc.1 ln -s gcc.1 %{buildroot}%{_mandir}/man1/gcc-gnat.1 ln -s gcc.1 %{buildroot}%{_mandir}/man1/gobjc.1 ln -s gcc.1 %{buildroot}%{_mandir}/man1/gcc-objc.1 ln -s gcc.1 %{buildroot}%{_mandir}/man1/gobjc++.1 ln -s gcc.1 %{buildroot}%{_mandir}/man1/gcc-objc++.1 %files -n gcc-objc %{_mandir}/man1/gobjc.* %{_mandir}/man1/gcc-objc.* %files -n gcc-objc++ %{_mandir}/man1/gobjc++.* %{_mandir}/man1/gcc-objc++.* %files -n gcc-gnat %{_mandir}/man1/gcc-gnat.* %{_mandir}/man1/gnatgcc.* Fedora-review lists these issues, all of which are inherited from the Fedora and RHEL packages: - If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. Note: License file LICENSE.libgo is not marked as %license See: https://docs.fedoraproject.org/en-US/packaging- guidelines/LicensingGuidelines/#_license_text → That should probably be fixed, but in the Fedora package, not here. - ldconfig not called in %post and %postun for Fedora 28 and later. Note: /sbin/ldconfig called in libobjc, libgccjit, libgo See: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets → The ldconfig scriptlets have already been fixed in Fedora. - Header files in -devel subpackage, if present. Note: gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/NXConstStr.h gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/Object.h gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/Protocol.h gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/message.h gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/objc-decls.h gcc-objc : /usr/lib/gcc/x86_64-redhat- linux/8/include/objc/objc-exception.h gcc-objc : /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc-sync.h gcc-objc : /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc.h gcc-objc : /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/runtime.h gcc-objc : /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/thr.h See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_devel_packages - Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files directly in %_libdir. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_devel_packages - Package uses either %{buildroot} or $RPM_BUILD_ROOT Note: Using both %{buildroot} and $RPM_BUILD_ROOT See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_macros - Static libraries in -static or -devel subpackage, providing -devel if present. Note: Package has .a files: gcc-objc, libgnat-devel, libgnat-static, libgo-devel, libgo-static. Illegal package name: gcc-objc. Does not provide -static: gcc-objc, libgnat-devel, libgo-devel. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#packaging-static-libraries - Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 4014080 bytes in 142 files. See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_documentation → All of that is either correct, or should be addressed in the Fedora or RHEL package. Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated, [U] = Upstream matter; if there is a problem, then the place to fix it is in Fedora or RHEL. ===== MUST items ===== C/C++: [U]: Provides: bundled(gnulib) in place as required. Note: Sources not installed [x]: Package does not contain kernel modules. [U]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [U]: License field in the package spec file matches the actual license. [U]: License file installed when any subpackage combination is installed. [U]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [U]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/lib/gcc(gcc-gfortran, libasan-static, libstdc++-devel, gcc-objc, gcc-gdb-plugin, libgfortran-static, libatomic-static, gcc-c++, libgo-devel, liblsan- static, gcc, libgphobos-static, libubsan-static, libstdc++-static, libtsan-static, avr-gcc, libitm-devel, libgnat-static, arm-none-eabi- gcc-cs, gcc-go, libitm-static, gcc-plugin-devel, gcc-gnat, libgo- static, ghdl-grt, libquadmath-static, libquadmath-devel, gcc-offload- nvptx, libgnat-devel, gcc-gdc), /usr/lib/gcc/x86_64-redhat-linux(gcc- gfortran, libasan-static, libstdc++-devel, gcc-objc, gcc-gdb-plugin, libgfortran-static, libatomic-static, gcc-c++, libgo-devel, liblsan- static, gcc, libgphobos-static, libubsan-static, libstdc++-static, libtsan-static, libitm-devel, libgnat-static, gcc-go, libitm-static, gcc-plugin-devel, gcc-gnat, libgo-static, libquadmath-static, libquadmath-devel, gcc-offload-nvptx, libgnat-devel, gcc-gdc), /usr/libexec/gcc(gcc-c++, gcc-gfortran, gcc-objc++, gcc-offload-nvptx, arm-none-eabi-gcc-cs, gcc, gcc-go, ghdl, gcc-objc, gcc-gnat, gcc- plugin-devel, avr-gcc, cpp, gcc-gdc), /usr/libexec/gcc/x86_64-redhat- linux(gcc-c++, gcc-gfortran, gcc-objc++, gcc-offload-nvptx, gcc, gcc- go, gcc-objc, gcc-gnat, gcc-plugin-devel, cpp, gcc-gdc) [U]: %build honors applicable compiler flags or justifies otherwise. [U]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [U]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf %{buildroot} present but not required [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [U]: Development files must be in a -devel package [U]: Package uses nothing in %doc for runtime. [U]: Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in libgccjit-devel, gcc-gnat [U]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [U]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [!]: Requires correct, justified where necessary. → See above. [!]: Spec file is legible and written in American English. → one grammar error as noted above [-]: Package contains systemd file(s) if in need. [U]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [U]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [U]: Uses parallel make %{?_smp_mflags} macro. [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in gcc-objc , gcc-objc++ , libobjc , libgccjit , libgccjit-devel , gcc-gnat , libgnat , libgnat-devel , libgnat-static , gcc-go , libgo , libgo- devel , libgo-static [?]: Package functions as described. → I can't verify because CentOS 8 isn't self-hosting. [U]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [U]: Patches link to upstream bugs/comments/lists or are otherwise justified. [U]: Scriptlets must be sane, if used. [U]: SourceX tarball generation or download is documented. Note: Package contains tarball without URL, check comments [U]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [U]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [?]: Package should compile and build into binary rpms on all supported architectures. → I can't verify because CentOS 8 isn't self-hosting. [?]: %check is present and all tests pass. → I can't verify because CentOS 8 isn't self-hosting. [U]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [U]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 4730880 bytes in /usr/share [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. The following complaints from RPMlint do not need to be addressed in this package: gcc-objc++.x86_64: W: spelling-error %description -l en_US objc -> obj, obj c → not an error gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/NXConstStr.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/Object.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/Protocol.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/message.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc-decls.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc-exception.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc-sync.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/objc.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/runtime.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/include/objc/thr.h gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/libobjc.a gcc-objc.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc/x86_64-redhat-linux/8/libobjc.so libobjc.x86_64: W: no-documentation libgccjit.x86_64: W: shared-lib-calls-exit /usr/lib64/libgccjit.so.0.0.1 exit.5 libgccjit.x86_64: W: shared-lib-calls-exit /usr/lib64/libgccjit.so.0.0.1 _exit.5 libgccjit-devel.x86_64: W: hidden-file-or-dir /usr/share/doc/libgccjit-devel/html/.buildinfo gcc-gnat.x86_64: E: devel-dependency libgnat-devel gcc-gnat.x86_64: W: no-manual-page-for-binary gnat gcc-gnat.x86_64: W: no-manual-page-for-binary gnatbind gcc-gnat.x86_64: W: no-manual-page-for-binary gnatchop gcc-gnat.x86_64: W: no-manual-page-for-binary gnatclean gcc-gnat.x86_64: W: no-manual-page-for-binary gnatfind gcc-gnat.x86_64: W: no-manual-page-for-binary gnatkr gcc-gnat.x86_64: W: no-manual-page-for-binary gnatlink gcc-gnat.x86_64: W: no-manual-page-for-binary gnatls gcc-gnat.x86_64: W: no-manual-page-for-binary gnatmake gcc-gnat.x86_64: W: no-manual-page-for-binary gnatname gcc-gnat.x86_64: W: no-manual-page-for-binary gnatprep gcc-gnat.x86_64: W: no-manual-page-for-binary gnatxref libgnat.x86_64: W: no-documentation libgnat-devel.x86_64: W: no-dependency-on libgnat/libgnat-libs/liblibgnat libgnat-devel.x86_64: W: no-documentation libgnat-static.x86_64: W: no-documentation gcc-go.x86_64: E: devel-dependency libgo-devel gcc-go.x86_64: W: unstripped-binary-or-object /usr/bin/go.gcc gcc-go.x86_64: W: unstripped-binary-or-object /usr/bin/gofmt.gcc gcc-go.x86_64: W: unstripped-binary-or-object /usr/libexec/gcc/x86_64-redhat-linux/8/buildid gcc-go.x86_64: W: unstripped-binary-or-object /usr/libexec/gcc/x86_64-redhat-linux/8/cgo gcc-go.x86_64: W: unstripped-binary-or-object /usr/libexec/gcc/x86_64-redhat-linux/8/test2json gcc-go.x86_64: W: unstripped-binary-or-object /usr/libexec/gcc/x86_64-redhat-linux/8/vet gcc-go.x86_64: W: dangling-symlink /usr/bin/go /etc/alternatives/go gcc-go.x86_64: W: dangling-symlink /usr/bin/gofmt /etc/alternatives/gofmt gcc-go.x86_64: W: no-manual-page-for-binary go.gcc gcc-go.x86_64: W: no-manual-page-for-binary gofmt.gcc libgo.x86_64: W: unstripped-binary-or-object /usr/lib64/libgo.so.13.0.0 libgo.x86_64: W: shared-lib-calls-exit /usr/lib64/libgo.so.13.0.0 exit.5 libgo.x86_64: W: shared-lib-calls-exit /usr/lib64/libgo.so.13.0.0 _exit.5 libgo.x86_64: E: missing-call-to-chdir-with-chroot /usr/lib64/libgo.so.13.0.0 libgo-devel.x86_64: W: no-documentation libgo-static.x86_64: W: no-documentation gcc-epel.src:301: W: unversioned-explicit-obsoletes libcilkrts gcc-epel.src:302: W: unversioned-explicit-obsoletes libcilkrts-static gcc-epel.src:307: W: unversioned-explicit-provides bundled(libiberty) gcc-epel.src:387: W: unversioned-explicit-obsoletes libmudflap gcc-epel.src:388: W: unversioned-explicit-obsoletes libmudflap-devel gcc-epel.src:389: W: unversioned-explicit-obsoletes libmudflap-static gcc-epel.src:1052: W: configure-without-libdir-spec gcc-epel.src:1066: W: configure-without-libdir-spec gcc-epel.src:1222: W: configure-without-libdir-spec gcc-epel.src:1246: W: configure-without-libdir-spec gcc-epel.src:2580: W: macro-in-comment %{_prefix} gcc-epel.src:2580: W: macro-in-comment %{gcc_target_platform} gcc-epel.src:2580: W: macro-in-comment %{gcc_major} gcc-epel.src:2584: W: macro-in-comment %{_prefix} gcc-epel.src:2584: W: macro-in-comment %{gcc_target_platform} gcc-epel.src:2584: W: macro-in-comment %{gcc_major} gcc-epel.src:2592: W: macro-in-comment %{_prefix} gcc-epel.src:2592: W: macro-in-comment %{gcc_target_platform} gcc-epel.src:2592: W: macro-in-comment %{gcc_major} gcc-epel.src:2597: W: macro-in-comment %{_prefix} gcc-epel.src:2597: W: macro-in-comment %{gcc_target_platform} gcc-epel.src:2597: W: macro-in-comment %{gcc_major} gcc-epel.src:2857: W: macro-in-comment %{_prefix} gcc-epel.src:2857: W: macro-in-comment %{gcc_target_platform} gcc-epel.src:2857: W: macro-in-comment %{gcc_major} gcc-epel.src: E: specfile-error warning: line 301: It's not recommended to have unversioned Obsoletes: Obsoletes: libcilkrts gcc-epel.src: E: specfile-error warning: line 302: It's not recommended to have unversioned Obsoletes: Obsoletes: libcilkrts-static gcc-epel.src: E: specfile-error warning: line 387: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap gcc-epel.src: E: specfile-error warning: line 388: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap-devel gcc-epel.src: E: specfile-error warning: line 389: It's not recommended to have unversioned Obsoletes: Obsoletes: libmudflap-static → All of that is either correct, or should be addressed in the Fedora or RHEL package.
(In reply to Björn Persson from comment #7) > You don't have a file named gcc-gobjc. I assume that you meant gobjc. Yes, I > think that's acceptable. Yes, sorry, I meant "gobjc (symlink)". > I don't know how the FPC interprets those rules together, but let's go with > gnatgcc and gobjc as separate files then. Good catch, I've opened https://pagure.io/packaging-committee/issue/1099 to get this clarified in general. > · libgo-static and libgccjit still require the exact NEVR of gcc. Should > those requirements also be relaxed? Oh, yes...changed. > · There is a grammar error: "rather" should be "rather than" in three places. Corrected. > I don't think that's a big problem, but since it's easy to do, why not make > some links to the gcc manpage? Like this: Good idea, done. > - If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) > for the package is included in %license. > Note: License file LICENSE.libgo is not marked as %license > See: https://docs.fedoraproject.org/en-US/packaging- > guidelines/LicensingGuidelines/#_license_text > > → That should probably be fixed, but in the Fedora package, not here. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2005161 for that. Spec URL: https://labs.linuxnetz.de/bugzilla/gcc-epel.spec SRPM URL: https://labs.linuxnetz.de/bugzilla/gcc-epel-8.4.1-2.src.rpm
Created attachment 1823710 [details] Diff between current GCC from RHEL 8 and this package
(In reply to Robert Scheck from comment #8) > (In reply to Björn Persson from comment #7) > > · There is a grammar error: "rather" should be "rather than" in three places. > > Corrected. You got two out of three right, but one says "than rather" now. Once you fix that, this package is good to go.
(In reply to Björn Persson from comment #10) > You got two out of three right, but one says "than rather" now. Oh no...sorry! I'll fix that during the import into Git. And: Thank you very much for the review! Hope this helps for your Ada packages :)
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/gcc-epel
FEDORA-EPEL-2021-5848dcbea8 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5848dcbea8
FEDORA-EPEL-2021-5848dcbea8 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5848dcbea8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-5848dcbea8 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.