* 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
> k
* 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
* 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]
>
* 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
* 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 in
* 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
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.f
* Stephen Gallagher:
> /dev/urandom is not cryptographically sound. From the manpage:
I think the key word in the manpage is "theoretical".
"openssl genrsa" and others use it for generating non-ephemeral keys.
It shares most of its code with /dev/random, so algorithmic breaches
will affect both.
