Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
thanks
-- Lee
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
thanks
-- Lee _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, 9 Jul 2019 at 07:56, Stephen John Smoogen smooge@gmail.com wrote:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
And this is where I see I hit control+enter and not enter.. sending an email which is not complete.
1. Thank you for bringing up an EPEL list here. I don't normally cross post to this list because I am not sure how much is germane to this list. 2. Thank you for your interest in EPEL. It is helpful to have people wanting to inform others of where we are. 3. We are having problems with a new release. We have had different problems with RHEL-6 and RHEL-7 as each time our build system and rules have changed greatly since the last time we added an EPEL branch. The problems are not insurmountable and we are progressing towards having packages built. It just isn't instant.
thanks
-- Lee _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
Thanks for the explanation, Stephen. Looking forward to what you all come up with. Will there be any documentation leading those of use using koji internally on what changes need to be made to our build systems to support el8? Thanks!
On Tue, Jul 9, 2019 at 9:58 AM Stephen John Smoogen smooge@gmail.com wrote:
On Tue, 9 Jul 2019 at 07:56, Stephen John Smoogen smooge@gmail.com wrote:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
And this is where I see I hit control+enter and not enter.. sending an email which is not complete.
- Thank you for bringing up an EPEL list here. I don't normally cross post to this list because I am not sure how much is germane to this list.
- Thank you for your interest in EPEL. It is helpful to have people wanting to inform others of where we are.
- We are having problems with a new release. We have had different problems with RHEL-6 and RHEL-7 as each time our build system and rules have changed greatly since the last time we added an EPEL branch. The problems are not insurmountable and we are progressing towards having packages built. It just isn't instant.
thanks
-- Lee _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, 9 Jul 2019 at 14:34, BC centoslistmail@gmail.com wrote:
Thanks for the explanation, Stephen. Looking forward to what you all come up with. Will there be any documentation leading those of use using koji internally on what changes need to be made to our build systems to support el8? Thanks!
There have been a couple of documents as we try to figure this out. They will also be a work in progress as changes are made to koji (we have had to patch several things to make it work with even the latest version).
On Tue, Jul 9, 2019 at 9:58 AM Stephen John Smoogen smooge@gmail.com wrote:
On Tue, 9 Jul 2019 at 07:56, Stephen John Smoogen smooge@gmail.com
wrote:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com
wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules"
architecture.
You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will
solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
And this is where I see I hit control+enter and not enter.. sending an
email which is not complete.
- Thank you for bringing up an EPEL list here. I don't normally cross
post to this list because I am not sure how much is germane to this list.
- Thank you for your interest in EPEL. It is helpful to have people
wanting to inform others of where we are.
- We are having problems with a new release. We have had different
problems with RHEL-6 and RHEL-7 as each time our build system and rules have changed greatly since the last time we added an EPEL branch. The problems are not insurmountable and we are progressing towards having packages built. It just isn't instant.
thanks
-- Lee _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Am 09.07.2019 um 13:56 schrieb Stephen John Smoogen smooge@gmail.com:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
It seems that the CodeReady repository has some missing devel packages. This will make the build process harder ...
-- LF
On Wed, 10 Jul 2019 at 17:56, Leon Fauster via CentOS-devel < centos-devel@centos.org> wrote:
Am 09.07.2019 um 13:56 schrieb Stephen John Smoogen smooge@gmail.com:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com
wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules"
architecture.
You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will
solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
It seems that the CodeReady repository has some missing devel packages. This will make the build process harder ...
So we haven't gotten that far yet in this. The proof of concept we worked on before the release did find that what is shipped or not shipped in RHEL makes it harder.
Even so. EPEL is a place where Fedora package maintainers put packages they would like to be usable in EL environments. That means not every Fedora package appears in EPEL and it also means that we do not have 1:1 package between EPEL-6 and EPEL-7 and won't with EPEL-8 as various maintainers may not wish to have a package there. So when EPEL-8 is 'open for business' not a lot of packages will be there. Hopefully it will grow over time.. or it might not. I can make no promises.
-- LF
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jul 10, 2019 at 6:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 10 Jul 2019 at 17:56, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Am 09.07.2019 um 13:56 schrieb Stephen John Smoogen smooge@gmail.com:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
It seems that the CodeReady repository has some missing devel packages. This will make the build process harder ...
So we haven't gotten that far yet in this. The proof of concept we worked on before the release did find that what is shipped or not shipped in RHEL makes it harder.
Even so. EPEL is a place where Fedora package maintainers put packages they would like to be usable in EL environments. That means not every Fedora package appears in EPEL and it also means that we do not have 1:1 package between EPEL-6 and EPEL-7 and won't with EPEL-8 as various maintainers may not wish to have a package there. So when EPEL-8 is 'open for business' not a lot of packages will be there. Hopefully it will grow over time.. or it might not. I can make no promises.
Mock, and awsclii, are the ones I wanted most. I've published two tools I use for RHEL 8 mock building. One is the "reposync-rhel-8.sh" script in my repository at https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.s.... I use that on a RHEL 8 box to create an internal RHEL 8 yum mirror on my licensed RHEL 8 host.
On top of that, I build a local copy of mock, using my tools at https://github.com/nkadel/nkadel-rhel-8-mockrepo . EPEL 8 is welcome to my tools to build mock from that repo.. Building RHEL 8 or EPEL 8 packages requires setting up the relevant "epel-8-x86_64.cfg" to use the "best=0" setting, to avoid confusion about the "module" RPMs.
Am 12.07.2019 um 02:54 schrieb Nico Kadel-Garcia nkadel@gmail.com:
On Wed, Jul 10, 2019 at 6:17 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 10 Jul 2019 at 17:56, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Am 09.07.2019 um 13:56 schrieb Stephen John Smoogen smooge@gmail.com:
On Tue, 9 Jul 2019 at 02:23, Thomas Stephen Lee lee.iitb@gmail.com wrote:
Hi,
It looks like Fedora EPEL people are having issues with the "modules" architecture. You all are probably busy with CentOS 8. If anyone has spare time, take a look.
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
I would expect we are having problems with a lot of things, but we will solve them one by one. We solved our problems with RHEL-7 and RHEL-6.
It seems that the CodeReady repository has some missing devel packages. This will make the build process harder ...
So we haven't gotten that far yet in this. The proof of concept we worked on before the release did find that what is shipped or not shipped in RHEL makes it harder.
Even so. EPEL is a place where Fedora package maintainers put packages they would like to be usable in EL environments. That means not every Fedora package appears in EPEL and it also means that we do not have 1:1 package between EPEL-6 and EPEL-7 and won't with EPEL-8 as various maintainers may not wish to have a package there. So when EPEL-8 is 'open for business' not a lot of packages will be there. Hopefully it will grow over time.. or it might not. I can make no promises.
Mock, and awsclii, are the ones I wanted most. I've published two tools I use for RHEL 8 mock building. One is the "reposync-rhel-8.sh" script in my repository at https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-8.s.... I use that on a RHEL 8 box to create an internal RHEL 8 yum mirror on my licensed RHEL 8 host.
On top of that, I build a local copy of mock, using my tools at https://github.com/nkadel/nkadel-rhel-8-mockrepo . EPEL 8 is welcome to my tools to build mock from that repo.. Building RHEL 8 or EPEL 8 packages requires setting up the relevant "epel-8-x86_64.cfg" to use the "best=0" setting, to avoid confusion about the "module" RPMs.
Reading this, I wonder if its possible to build the meta information for module packages out of a rpm list (without additional knowledge)? Similar to createrepo that works just pointing to a directory. Scenario: pinning a version or incorporating upstream packages in a local repository. Just curious because that module thing completely passed me by since I don't use fedora. So, EL8 put the wall in front of me :-)
-- LF
On Fri, 12 Jul 2019 at 08:05, Leon Fauster via CentOS-devel < centos-devel@centos.org> wrote:
Am 12.07.2019 um 02:54 schrieb Nico Kadel-Garcia nkadel@gmail.com:
On top of that, I build a local copy of mock, using my tools at https://github.com/nkadel/nkadel-rhel-8-mockrepo . EPEL 8 is welcome to my tools to build mock from that repo.. Building RHEL 8 or EPEL 8 packages requires setting up the relevant "epel-8-x86_64.cfg" to use the "best=0" setting, to avoid confusion about the "module" RPMs.
Reading this, I wonder if its possible to build the meta information for module packages out of a rpm list (without additional knowledge)? Similar to createrepo that works just pointing to a directory. Scenario: pinning a version or incorporating upstream packages in a local repository. Just curious because that module thing completely passed me by since I don't use fedora. So, EL8 put the wall in front of me :-)
There are multiple definitions, filters, controls and other data which are in the modular data file which an rpm list does not have.. much of that data is used in some form. Here is the section for squid from today's in modules.yaml.gz file
--- document: modulemd version: 2 data: name: squid stream: 4 version: 820181213143653 context: 9edba152 arch: x86_64 summary: Squid - Optimising Web Delivery description: >- an initial version of the squid caching proxy module license: module: - MIT content: - BSD - GPLv2+ and (LGPLv2+ and MIT and BSD and Public Domain) xmd: mbs: mse: TRUE scmurl: git:// pkgs.devel.redhat.com/modules/squid?#21e20d36bd79e5a938598ac24dfb9f74b56028ad commit: 21e20d36bd79e5a938598ac24dfb9f74b56028ad buildrequires: platform: stream_collision_modules: stream: el8 ref: virtual filtered_rpms: [] ursine_rpms: koji_tag: module-rhel-8.0.0-build version: 2 context: 00000000 rpms: squid: ref: c8510e2ed3af9860df1a961795e47e6070621a18 libecap: ref: 1d5fed47e0ff19fa962034645d42bf2e5a2564dc dependencies: - buildrequires: platform: [el8] requires: platform: [el8] references: documentation: http://www.squid-cache.org/Doc/ tracker: https://bugs.squid-cache.org/index.cgi profiles: common: rpms: - squid api: rpms: - squid components: rpms: libecap: rationale: library needed by Squid repository: git://pkgs.devel.redhat.com/rpms/libecap cache: http://pkgs.devel.redhat.com/repo/pkgs/libecap ref: stream-1.0 buildorder: 1 arches: [aarch64, i686, ppc64le, s390x, x86_64] squid: rationale: squid caching proxy repository: git://pkgs.devel.redhat.com/rpms/squid cache: http://pkgs.devel.redhat.com/repo/pkgs/squid ref: stream-4 buildorder: 2 arches: [aarch64, i686, ppc64le, s390x, x86_64] artifacts: rpms: - libecap-0:1.0.1-1.module+el8+2479+dae5d0d3.x86_64 - libecap-devel-0:1.0.1-1.module+el8+2479+dae5d0d3.x86_64 - squid-7:4.4-4.module+el8+2479+dae5d0d3.x86_64 ... --- document: modulemd-defaults version: 1 data: module: squid stream: 4 profiles: 4: [common] ...
There may be some other data spread through the file which would be needed for it to use this. This is one of the least complicated ones as it does not have anything which is supposed to tell pungi to filter out packages in the final compose or dependency chains in what it conflicts or requires. Those are very long in text.. so I didn't want to spam email more than I am already with the above.
-- LF
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
BC -
Leon Fauster -
Nico Kadel-Garcia -
Stephen John Smoogen -
Thomas Stephen Lee