[EPEL-devel] Re: Incompatible upgrade for oniguruma in EPEL 7

[Jeff Sheltren]

On Fri, May 15, 2020 at 4:19 PM Kevin Fenzi  wrote:

> On Fri, May 15, 2020 at 03:59:57PM -0500, Carl George wrote:
>
> > Let me know your thoughts and concerns about moving forward with this.
>
> +1 here and thanks for making epel a safer place.
>
>
+1, thanks!

-Jeff
___
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: EPEL bugzilla / component listing limited

[Leon Fauster]

Am 15.05.20 um 22:04 schrieb Troy Dawson:

On Fri, May 15, 2020 at 12:39 PM Leon Fauster
 wrote:


I wanted to request a new EPEL package and noticed that it is not
possible to select the package name (fedora) in the component field
in the bug report form (Product: Fedora EPEL). Is this enforced or is
this a regression? I remember making such requests without problem.

The targeted package in request is: xdg-dbus-proxy

Any ideas?



If a package has never been in EPEL before, it isn't listed in
Product: Fedora EPEL.
I don't know if this is "enforced", it's just the way it is.
If a package was ever in EPEL, going back to EPEL5 or possibly 4, it's
listed.  But if it never has been (such as xdg-dbus-proxy) then it
isn't listed and you have to go through Fedora -> Fedora to request
it.


Okay, thanks to clarifying it. I will try that path ...

--
Leon





___
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] EPEL bugzilla / component listing limited

[Leon Fauster]

I wanted to request a new EPEL package and noticed that it is not
possible to select the package name (fedora) in the component field
in the bug report form (Product: Fedora EPEL). Is this enforced or is
this a regression? I remember making such requests without problem.

The targeted package in request is: xdg-dbus-proxy

Any ideas?

--
Thanks,
Leon
___
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: Incompatible upgrade for oniguruma in EPEL 7

[Kevin Fenzi]

On Fri, May 15, 2020 at 03:59:57PM -0500, Carl George wrote:
> The current version of oniguruma in EPEL 7 is affected by multiple CVEs.
> 
> * rhbz#1466750 - CVE-2017-9224 CVE-2017-9225 CVE-2017-9226
> CVE-2017-9227 CVE-2017-9228 CVE-2017-9229
> * rhbz#1728967 - CVE-2019-13225
> * rhbz#1728972 - CVE-2019-13224
> * rhbz#1768999 - CVE-2019-16163
> * rhbz#1770213 - CVE-2019-16161
> * rhbz#1777538 - CVE-2019-19246
> * rhbz#1802053 - CVE-2019-19012
> * rhbz#1802063 - CVE-2019-19203
> * rhbz#1802072 - CVE-2019-19204
> 
> I've discussed doing an incompatible upgrade of the package with the
> other maintainers (rhbz#1777660), and so far no one is opposed to it.
> As far as I can tell, the only package that would need to be rebuilt
> is jq.
> 
> ```
> [root@c7-container:~]# repoquery --provides oniguruma | grep '\.so'
> libonig.so.2()(64bit)
> [root@c7-container:~]# repoquery --whatrequires 'libonig.so.2()(64bit)'
> jq-0:1.6-1.el7.x86_64
> oniguruma-devel-0:5.9.5-3.el7.x86_64
> [root@c7-container:~]# repoquery --quiet --disablerepo \*
> --queryformat '%{name}' --archlist src --enablerepo
> epel-source,epel-testing-source --whatrequires oniguruma-devel
> jq
> ```
> 
> Let me know your thoughts and concerns about moving forward with this.

+1 here and thanks for making epel a safer place. 

kevin


signature.asc
Description: PGP signature
___
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] Incompatible upgrade for oniguruma in EPEL 7

[Carl George]

The current version of oniguruma in EPEL 7 is affected by multiple CVEs.

* rhbz#1466750 - CVE-2017-9224 CVE-2017-9225 CVE-2017-9226
CVE-2017-9227 CVE-2017-9228 CVE-2017-9229
* rhbz#1728967 - CVE-2019-13225
* rhbz#1728972 - CVE-2019-13224
* rhbz#1768999 - CVE-2019-16163
* rhbz#1770213 - CVE-2019-16161
* rhbz#1777538 - CVE-2019-19246
* rhbz#1802053 - CVE-2019-19012
* rhbz#1802063 - CVE-2019-19203
* rhbz#1802072 - CVE-2019-19204

I've discussed doing an incompatible upgrade of the package with the
other maintainers (rhbz#1777660), and so far no one is opposed to it.
As far as I can tell, the only package that would need to be rebuilt
is jq.

```
[root@c7-container:~]# repoquery --provides oniguruma | grep '\.so'
libonig.so.2()(64bit)
[root@c7-container:~]# repoquery --whatrequires 'libonig.so.2()(64bit)'
jq-0:1.6-1.el7.x86_64
oniguruma-devel-0:5.9.5-3.el7.x86_64
[root@c7-container:~]# repoquery --quiet --disablerepo \*
--queryformat '%{name}' --archlist src --enablerepo
epel-source,epel-testing-source --whatrequires oniguruma-devel
jq
```

Let me know your thoughts and concerns about moving forward with this.

-- 
Carl George
___
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: EPEL bugzilla / component listing limited

[Troy Dawson]

On Fri, May 15, 2020 at 12:39 PM Leon Fauster
 wrote:
>
> I wanted to request a new EPEL package and noticed that it is not
> possible to select the package name (fedora) in the component field
> in the bug report form (Product: Fedora EPEL). Is this enforced or is
> this a regression? I remember making such requests without problem.
>
> The targeted package in request is: xdg-dbus-proxy
>
> Any ideas?
>

If a package has never been in EPEL before, it isn't listed in
Product: Fedora EPEL.
I don't know if this is "enforced", it's just the way it is.
If a package was ever in EPEL, going back to EPEL5 or possibly 4, it's
listed.  But if it never has been (such as xdg-dbus-proxy) then it
isn't listed and you have to go through Fedora -> Fedora to request
it.

Troy
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Troy Dawson]

On Fri, May 15, 2020 at 10:37 AM Michel Alexandre Salim
 wrote:
> Or have a "purgatory" repo where packages retired in EL 8.2 get to live
> until, say, a month after CentOS 8.2 is GA? Again, seems like too much work.
>

Or, perhaps we could archive things before a release.
I guess my reply got trimmed off and/or ignored.

There is the EPEL archives.

This is fairly recent, but we did a snapshot of 8.1 a bit before 8.2 came out.
We plan on doing this for each minor release (7 and 8).
Fedora Archives are not on all the mirrors, so it might be a little
slower, depending on where you get it from, but at least it's there.

https://archives.fedoraproject.org/pub/archive/epel/8.1/

Troy
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Michel Alexandre Salim]

On 5/14/20 4:59 PM, Nico Kadel-Garcia wrote:


It's an ongoing problem. EPEL's decision to show only the most recent
versions of RPMs, and to trim old RPMs out, is a destabilizing problem
and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
internal access to old packages.


So that's a problem we have with Fedora (e.g. hardware regressions 
preventing some hardware from being in the latest kernel, *but* if they 
were not updating often enough, the last known-good version might not be 
available anymore unless you pull from Koji).


But it does not really apply to the EPEL retirement. If a decision is 
made to retire packages for a given branch, it does not matter how many 
versions you keep, they will all be retired, right?


Perhaps having additional metadata in dist-git (e.g. "retire from EL 8.2 
onwards") would allow maintainers to keep building as normal, we can 
publish epel/8-all, epel/8.1, epel/8.2 etc. repos where the first repo 
has all packages, and the others have symlinks to 8-all but filtering 
out the retired packages?


But that won't work if there are ABI incompatibilities... so yeah, 
overall I think the best solution is to just try and get CentOS releases 
out of the door sooner rather than later.


Or have a "purgatory" repo where packages retired in EL 8.2 get to live 
until, say, a month after CentOS 8.2 is GA? Again, seems like too much work.


In our case, hopefully this is a one-off (it's because we deploy 
RPM-with-zstd internally).


--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Updating CMake in EPEL-8: How to create a module?

[Neal Gompa]

On Fri, May 15, 2020 at 10:37 AM Orion Poplawski  wrote:
>
> On 5/15/20 8:32 AM, Alexander Korsunsky wrote:
> >> Has anyone asked if CMake could be updated in RHEL yet?
> >
> > This would be the absolute best option here, but it depends on the 
> > benevolence of Red Hat.
> >
> > I don't have a subscription and I don't know how to ask them for a rebase 
> > without one. Maybe there's some kind of process for getting stuff into 
> > CentOS Stream? So far the interaction with upstream seems to be limited to 
> > "create an issue on Bugzilla".
>
> That would be my suggestion:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=cmake

Wrong place. This is the correct one:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&component=cmake


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Updating CMake in EPEL-8: How to create a module?

[Orion Poplawski]

On 5/15/20 8:32 AM, Alexander Korsunsky wrote:

Has anyone asked if CMake could be updated in RHEL yet?


This would be the absolute best option here, but it depends on the benevolence 
of Red Hat.

I don't have a subscription and I don't know how to ask them for a rebase without one. 
Maybe there's some kind of process for getting stuff into CentOS Stream? So far the 
interaction with upstream seems to be limited to "create an issue on Bugzilla".


That would be my suggestion:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=cmake

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Updating CMake in EPEL-8: How to create a module?

[Alexander Korsunsky]

> Has anyone asked if CMake could be updated in RHEL yet?

This would be the absolute best option here, but it depends on the benevolence 
of Red Hat.

I don't have a subscription and I don't know how to ask them for a rebase 
without one. Maybe there's some kind of process for getting stuff into CentOS 
Stream? So far the interaction with upstream seems to be limited to "create an 
issue on Bugzilla".
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Fri, 15 May 2020 at 09:06, Nico Kadel-Garcia  wrote:

> On Fri, May 15, 2020 at 8:02 AM Stephen John Smoogen 
> wrote:
> >
> >
> >
> > On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia 
> wrote:
> >>
> >> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > We're working on validating CentOS 8 for some desktop use cases at
> work,
> >> > and noticed that after working fine on a machine that's installed
> >> > several months ago, it's now failing on a freshly-installed machine.
> >>
> >> Do not get me *started* on the ansible version fun and games, or the
> >> confusing state of the python3 for various EPEL, RHEL and CentOS
> >> migrations. The situation is exacerbated when RHEL elects to use a
> >> kind-of-sort-of distinct naming scheme for software previously
> >> published via EPEL.
> >>
> >> It's an ongoing problem. EPEL's decision to show only the most recent
> >> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> >> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> >> internal access to old packages.
> >
> >
> > To be clear here.. the 'decision' is that EPEL is built using the same
> build system that Fedora uses. The Fedora build system does not keep older
> versions of packages in its composes for a space and so EPEL can not keep
> older versions of packages either. We tried several 'hacks' to do this and
> they broke the Fedora side or didn't do what we wanted on the EPEL side
> either.
>
> That is not clear at all. Build systems normally build new versions of
> software and deploy them to some target space. The decision to delete
> older packages is a very distinct one. Review of that workspace and
> expiration of old packages pretty much *must* be a distinct one.
> Deletion of obsolete packages in anticipation of their activation in
> an entirely distinct repository  is a very distinct decision.
>
>
I believe Dennis Gilmore and others have tried to explain this multiple
times in the past, but it seems that it just doesn't get through. Here is
my take on it.. which is not as nice as theirs and probably flawed because
I am tired.

The Fedora build system means everything from pkgs, pdc, bodhi, koji,
pungi, and several other tools. The way that this system is built is to
build a complete operating system with the 'compose' being just like what
is in rawhide or a release. Everything is tagged to be in the compose, a
fresh tree is generated, createrepo and other items are built on that tree,
and that tree then replaces the old one on the download servers. Just like
F32 directories and rawhide do not have older copies of packages.. neither
does EPEL.  So to the system there are no old rpms to keep around.. [and
trying to keep them seems to end up with a good many mirrors carrying new
packages but old repodata (or vice versa.. new repodata but no new rpms) so
can't be used by yum/dnf]

Of course there could be other solutions that would fix this problem.. but
each one takes time and energy that no one seems to have the time to
volunteer to get done. If you have the time to do so, I am sure people will
welcome it.



-- 
Stephen J Smoogen.
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia  wrote:

> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
>  wrote:
> >
> > Hi,
> >
> > We're working on validating CentOS 8 for some desktop use cases at work,
> > and noticed that after working fine on a machine that's installed
> > several months ago, it's now failing on a freshly-installed machine.
>
> Do not get me *started* on the ansible version fun and games, or the
> confusing state of the python3 for various EPEL, RHEL and CentOS
> migrations. The situation is exacerbated when RHEL elects to use a
> kind-of-sort-of distinct naming scheme for software previously
> published via EPEL.
>
> It's an ongoing problem. EPEL's decision to show only the most recent
> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> internal access to old packages.
>

To be clear here.. the 'decision' is that EPEL is built using the same
build system that Fedora uses. The Fedora build system does not keep older
versions of packages in its composes for a space and so EPEL can not keep
older versions of packages either. We tried several 'hacks' to do this and
they broke the Fedora side or didn't do what we wanted on the EPEL side
either.

At this point it is either someone finding the time to deep dive into pungi
and other tools to make it work for this 2 different case mode or moving
EPEL to a different build system. Both are giant projects which no one has
had the time to do.


-- 
Stephen J Smoogen.
___
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: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


signature.asc
Description: PGP signature
___
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: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


signature.asc
Description: PGP signature
___
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: Updating CMake in EPEL-8: How to create a module?

[Neal Gompa]

On Fri, May 15, 2020 at 4:58 AM Alexander Korsunsky
 wrote:
>
> Hi there,
>
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11, 
> which is becoming more and more outdated. Me (and a few other people, judging 
> by bug report participation) would quite like to have a newer version of 
> CMake on their systems.
>

Has anyone asked if CMake could be updated in RHEL yet? Unlike in the
CMake 2.x days, CMake 3.x tends to maintain behavioral compatibility
extraordinarily well...




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Documentation for EPEL modules?

[Antonio Trande]

Shortly (Martin is in Cc to confirm):

1) Make a module:

$ fedpkg clone cmake3
$ fedpkg request-repo --namespace modules --exception cmake3-latest
$ fedpkg request-branch --namespace modules --repo cmake3-latest epel8

2) Writing a `modulemd` file based on this example [1]:

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/

3) Build the module:

$ fedpkg module-build


On 14/05/20 17:51, Petr Pisar wrote:
> On Thu, May 14, 2020 at 06:46:29AM -0500, Richard Shaw wrote:
>> So this happened:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ad02b27ee3
>> https://bugzilla.redhat.com/show_bug.cgi?id=1830748
>>
>> TLDR; So we need an updated version of CMake in EPEL 8 but RHEL/CentOS
>> already provide a "3" version. Worse both the Fedora and EL versions
>> provide "cmake3" packages and binaries so it's not possible to install the
>> cmake3 package in EL 8.
>>
>> So here's a great use case for modularity but I have no idea how it works
>> and there doesn't seem to be any EPEL specific documentation even though
>> it's obviously getting used:
>>
>> https://bodhi.fedoraproject.org/releases/EPEL-8M
>>
>> Do we need a epel8 branch? Or is the EL module created from master?
>>
> I believe modules in EPEL are similar to modules in Fedora. I'm not aware
> about a documentation for modules in EPEL. There were some attempts to draft
> the guide lines like forbiding default streams and mandating stream prefixes,
> but I do not remember any output.
> 
> Let's look at real examples.
>  lists 
> avocado-latest-820200512173744.9edba152 module. That's this
>  module build
> in Koji. The Source field reads 
> .
> 
> Theat means "fedpkg clone modules/avocado" and there these branches:
> 
> * latest
>   remotes/origin/52lts
>   remotes/origin/69lts
>   remotes/origin/HEAD -> origin/latest
>   remotes/origin/f29
>   remotes/origin/latest
>   remotes/origin/master
>   remotes/origin/stable
> 
> The module stream is called "latest", let us check "latest" branch:
> 
> commit 12e2140e759fdb0a4477ab2432c411a4452d8efc (HEAD -> latest, 
> origin/latest, origin/HEAD)
> Author: Merlin Mathesius 
> Date:   Tue May 12 12:37:44 2020 -0500
> 
> Rebuild with avocado 79.0.
> 
> Signed-off-by: Merlin Mathesius 
> 
> So you can see the module is built from a non-epel8 branch. An avocado.yaml
> file lists these dependencies:
> 
>   dependencies:
>   - buildrequires:
>   platform: []
> requires:
>   platform: []
> 
> So "platform" is left empty to expand it by MBS on all available platforms. If
> you look at koji listing
> , there are
> five modules avocado-latest-*20200512173744 builds of from the same sources.
> That probably means that Koji attempts to build the module for all Fedoras and
> EPEL 8. Technically, it's possible to override the platform with "fedpkg
> module-build" command, but I cannot see any trace of it in the logs.
> 
> That buld was performed by "merlinm" users. You can ask him for more details.
> 
> -- Petr
> 
> 
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
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: Updating CMake in EPEL-8: How to create a module?

[Petr Pisar]

On Fri, May 15, 2020 at 08:58:21AM -, Alexander Korsunsky wrote:
> Hi there,
> 
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11,
> which is becoming more and more outdated. Me (and a few other people,
> judging by bug report participation) would quite like to have a newer
> version of CMake on their systems.
> 
> Now, if I understand correctly, according to the EPEL policies,
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is
> prohibited to replace packages from the base distribution. It is, however,
> allowed to replace these packages in modules that are not enabled by
> default.
> 
> Unfortunately, nobody really seems to know how to build modules for EPEL.
> There is documentation for Fedora:
> https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However,
> being not very familiar with modularity, I have no clue which parts of the
> documentation apply to EPEL, and I could not find EPEL-specific
> documentations and recommendations. I have seen some threads on this list
> *discussing* these, but it's hard for me to discern the consensus and best
> practices from mailing list threads.
> 
> Would the Modularity magicians be so kind as to reply with some pointers on
> how to create modules for EPEL? If that already exists, my apologies, I hope
> you can direct me to that resource.
> 
I replied to the same question yesterday on Fedora devel list
.
 

-- Petr


signature.asc
Description: PGP signature
___
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] Updating CMake in EPEL-8: How to create a module?

[Alexander Korsunsky]

Hi there,

the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11, 
which is becoming more and more outdated. Me (and a few other people, judging 
by bug report participation) would quite like to have a newer version of CMake 
on their systems.

Now, if I understand correctly, according to the EPEL policies, 
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is 
prohibited to replace packages from the base distribution. It is, however, 
allowed to replace these packages in modules that are not enabled by default.

Unfortunately, nobody really seems to know how to build modules for EPEL. There 
is documentation for Fedora: 
https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However, 
being not very familiar with modularity, I have no clue which parts of the 
documentation apply to EPEL, and I could not find EPEL-specific documentations 
and recommendations. I have seen some threads on this list *discussing* these, 
but it's hard for me to discern the consensus and best practices from mailing 
list threads.

Would the Modularity magicians be so kind as to reply with some pointers on how 
to create modules for EPEL? If that already exists, my apologies, I hope you 
can direct me to that resource.

Kind Regards,
Alexander
___
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