[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Florian Weimer]

* Josh Boyer:

> As part of our continued 3 year major Red Hat Enterprise Linux release
> cadence, RHEL 9 development is starting to wrap up with the spring
> 2022 release coming soon.  That means planning for the next release
> will start in earnest in the very near future.  As some of you may
> know, Red Hat has been using both Bugzilla and Jira via
> issues.redhat.com for RHEL development for several years.  Our
> intention is to move to using issues.redhat.com only for the major
> RHEL releases after RHEL 9.

Thanks for posting this publicly.

> - Fedora Linux and EPEL have their own Bugzilla product families and
> are not directly impacted in their own workflows by the choice to use
> only issues.redhat.com for RHEL.
> - There will be impacts on existing documentation that provide
> guidance on requesting things from RHEL in various places like EPEL.
> We will be happy to help adjust these.

There is already an “FC” project on issues.redhat.com, into which Fedora
bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
mirror+ Bugzilla flag publicly, and make the FC project public, so that
people can experiment with that?

> If there are other impacts that you can think of, please raise them on
> this thread.  We’d like to ensure we’re covering as much as possible
> as this rolls out.

What is going to happen to the CentOS Mantis instance
?  From the looks of it, it probably should
just be switched off?

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Getting %ldconfig_scriptlets in CentOS 7

[Florian Weimer]

* Mikhail Ramendik:

> So how can he get his aarch64 CentOS 7 to support this macro, to
> enable rebuilds without modifying the .spec file?

Does the package actually require running ldconfig?

If not, building with "-D ldconfig_scriptlets %{nil}" should work, I
think.

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Request for daemonize package

[Florian Weimer]

* Gerard Braad:

>
> I am using CentOS8 and am using various packages in the EPEL
> repository. I am interested in seeing 'daemonize' [0] added to EPEL.
>
> Would it be possible for you to maintain the package in EPEL? If not
> do you know of a maintainer who could help you with it? While EPEL[1]
> is more conservative in package maintenance, it does allow for updates
> to later versions when needed.

You should use systemd for that.  Setting the umask to 0, like daemonize
does, introduces security vulnerabilities.

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: %{python3} no defined in epel-7-aarch64?

[Florian Weimer]

* Miro Hrončok:

> Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:
>
> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/
>
> No easy way to solve this except to stop building for aarch64 on EPEL
> 7. You could use the %__python3 macro instead to workaround this
> particular problem, but you will most likely hit another one later.

aarch64 is completely EOL on 7, so you should just stop building it.
There is no Extended Update Support and no Extended life cycle support
for it.



Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: gcc-gnat

[Florian Weimer]

* Björn Persson:

> In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage
> of gcc. Adding it to EPEL would make it a separate package. I'm not
> sure what complications might arise from that.

The main problem is that /usr/bin/gcc does not have Ada support.  It
will not try to invoke gnat1 (the actual Ada compiler) even if it is
installed at the correct path.  I'm trying to figure out if anything can
be done about this.  This change would have to happen in the gcc
package.

If this change does not happen, you will have to ship /usr/bin/gnatgcc
instead, with some patching of the GNAT tools to use that.  Ada packages
that assume a single compiler driver for Ada/C/C++ will need fixing,
too.

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: What version of gcc is available in EPEL-7?

[Florian Weimer]

* José Abílio Matos:

>   what versions, other than 4.8.5, of gcc are avaialble for EPEL-7?
>
> My question is due to LyX that is starting the release procedure for 2.4 and 
> there is a consideration for the minimum supported gcc supported.
>
> The interest in gcc (actually g++) is due to the fact that the regex library 
> in 4.8 has problems.

There are publicly available builds of GCC 8 for CentOS:

  

It still uses the old C++ ABI.   and many other things will work,
though.

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Koji garbage collection for EPEL repositories

[Florian Weimer]

Is Koji garbage collection enabled?  Or can users get access to all 
previously released package versions, assuming their builds are still 
tagged (and we don't untag them automatically)?


Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org