Re: building against epel8 modules
Btw, not sure who did what, but thanx a lot. Without any touches, the epel8 package now builds fine. So thank ou fedora relengs! J. On 6/22/21 6:27 PM, Jiri Vanek wrote: Hello! I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8: Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8: CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 Error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering web search is failing me. Is there some magical spec switch which is enbaling... modules? or something? Thanx! j. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Yup. That sounds like a plan. On 7/2/21 11:52 AM, Vít Ondruch wrote: Dne 02. 07. 21 v 5:25 Nico Kadel-Garcia napsal(a): On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia wrote: On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: On 6/22/21 7:08 PM, Stephen John Smoogen wrote: Welcome to RHEL-8 modularity and the joy it brings anyone trying to port software to 8. The problem is not with EPEL but with the way hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in twilight :-) I can't find *anyone* who likes modularity. I'm devoutly hoping that it is discarded for RHEL 9. For the record, it is not being discarded in RHEL 9. josh Any chance of ignoring it almost entirely, or only using it for modular packages? It caused real dependency for some perl modules, and even the name is confusing when we start talking about perl and python modules. Sorry, I meant "only use it for entirely optional, non-build-related software". The initial versions of SW will be (mostly) non-modular, additional versions will be (mostly) modular. Vít ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Dne 02. 07. 21 v 5:25 Nico Kadel-Garcia napsal(a): On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia wrote: On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: On 6/22/21 7:08 PM, Stephen John Smoogen wrote: Welcome to RHEL-8 modularity and the joy it brings anyone trying to port software to 8. The problem is not with EPEL but with the way hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in twilight :-) I can't find *anyone* who likes modularity. I'm devoutly hoping that it is discarded for RHEL 9. For the record, it is not being discarded in RHEL 9. josh Any chance of ignoring it almost entirely, or only using it for modular packages? It caused real dependency for some perl modules, and even the name is confusing when we start talking about perl and python modules. Sorry, I meant "only use it for entirely optional, non-build-related software". The initial versions of SW will be (mostly) non-modular, additional versions will be (mostly) modular. Vít ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Wed, Jun 23, 2021 at 8:58 AM Nico Kadel-Garcia wrote: > I can't find *anyone* who likes modularity. I like the concept of modules. But primarily only if someone else is doing the actual hard work that ends up being necessary to build them. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia wrote: > > On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: > > > > > > > > On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: > >> > >> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: > >> > > >> > > >> > > >> > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: > >> > >> > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to > >> > > port software to 8. The problem is not with EPEL but with the way > >> > > >> > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore > >> > darkness in twilight :-) > >> > >> I can't find *anyone* who likes modularity. I'm devoutly hoping that > >> it is discarded for RHEL 9. > > > > > > For the record, it is not being discarded in RHEL 9. > > > > josh > > Any chance of ignoring it almost entirely, or only using it for > modular packages? It caused real dependency for some perl modules, and > even the name is confusing when we start talking about perl and python > modules. Sorry, I meant "only use it for entirely optional, non-build-related software". ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: > > > > On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: >> >> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: >> > >> > >> > >> > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: >> >> > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to >> > > port software to 8. The problem is not with EPEL but with the way >> > >> > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness >> > in twilight :-) >> >> I can't find *anyone* who likes modularity. I'm devoutly hoping that >> it is discarded for RHEL 9. > > > For the record, it is not being discarded in RHEL 9. > > josh Any chance of ignoring it almost entirely, or only using it for modular packages? It caused real dependency for some perl modules, and even the name is confusing when we start talking about perl and python modules. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: > On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: > > > > > > > > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: > > > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to > > > port software to 8. The problem is not with EPEL but with the way > > > > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore > darkness in twilight :-) > > I can't find *anyone* who likes modularity. I'm devoutly hoping that > it is discarded for RHEL 9. > For the record, it is not being discarded in RHEL 9. josh ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
... I still don't understand what Frankenstein buildroot we are using. 2 lines in a mock file allow to be aware of modules... modules=1 ... config_opts['module_enable'] = ['php:7.4', ... 2h of work to find the proper configuration and I was able to build such packages since the day RHEL-8-Beta was made publicly available, in May 2018... 3 years ago and still waiting for something to happen in EPEL Maybe allow some spec switch to do that? But it is noobs suggestion based on not-knwoing. It is easy to do this in a mock. It isn't easy to do this in koji and or mbs because they assume they 'built' everything they are going to use to build other things. This means we either have to build all of RHEL with the Fedora koji/mbs packages so they 'understand' what is there.. or you have to come up with some sort of hack which does something like this: 1. koji/mbs create the mock.cfg file and start setting up a buildroot on a builder. 2. your script rewrites the mock.cfg with the config items and fake koji/mbs into everything is ok. 3. koji/mbs continues the build The problems with this method are the following: 1. You have to hand edit the script to know what modules are being used and for when. 2. You have to hope that 2 doesn't get abused in multiple ways 3. It is kludgy and breaks a lot so you end up doing a 'repeat build until either fail_counter=X || build_complete' 4. You end up needing to do this separately from the regular Fedora koji/mbs because if you can do this in one build root, you can do it in all.. The way EPEL is set up is a third way which is a 'best of worst worlds' method: 1. You download RHEL packages into a repository 2. You run a demodularizer which breaks apart the modules into a one tree. You have to be careful because some modules conflict so you only do the ones which are 'Default' or in CodeReady If I take look to my error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Then from thsi demodualrize-explaining sentence I would guess, that I'm useing jsut wrong versions . I already tried to play with various BuildRequires xyz > or < a.b but mostly did it just worse. In addition, I had failed to search koji/centos builder for this dependence checks and was moreover blindly shooting. thoughts? Thanx a lot for all the inputs! 3. You rebuild this into a single repository 4. koji looks at this as an external repository like it has done from EPEL-5 days. This uses a method which was meant for just kickstarting a build tree by having an external tree to point to but works for RHEL. Koji tries to deal with this but it causes issues 5. mbs still only knows how to use modules it built itself.. This means that the external modules in RHEL are invisible to it. This is what breaks it from being able to build PHP modules. In the end, the core problem is that we are (ab)using the koji/mbs build structure to do things it was never intended to do. It has been made to do it, but deep down it is like making pizza on a shovel at a blacksmith.. you can do it but neither the forge or the shovel were meant for this and you end up constantly trying to figure out how to remove coal tar from the food. Ex: https://rpms.remirepo.net/temp/epel-temp.repo And mock configuration https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg Remi ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, 24 Jun 2021 at 10:03, Remi Collet wrote: > > Le 24/06/2021 à 15:33, Matthew Miller a écrit : > > On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: > >> P.S. yes, I'm really disappointed by how Fedora evolves, > >> not being able to use a proper build system (modules aware) > > > > If you could wave a magic wand here, what would a proper build system look > > like? > > I'm fine with current tooling (Koji) > > I only like to be able to build additional packages for existing modules > (e.g. php extensions in EPEL for php streams in RHEL) so > in some new module (php-extras) or better in the same one (php) > > In short being able to run "fedpkg module build" from > https://src.fedoraproject.org/modules/php-extras/tree/7.3 > (work is ready for months) > > I still don't understand what Frankenstein buildroot we are using. > > 2 lines in a mock file allow to be aware of modules... > > modules=1 > ... > config_opts['module_enable'] = ['php:7.4', ... > > 2h of work to find the proper configuration and > I was able to build such packages since the day RHEL-8-Beta > was made publicly available, in May 2018... 3 years ago > and still waiting for something to happen in EPEL > It is easy to do this in a mock. It isn't easy to do this in koji and or mbs because they assume they 'built' everything they are going to use to build other things. This means we either have to build all of RHEL with the Fedora koji/mbs packages so they 'understand' what is there.. or you have to come up with some sort of hack which does something like this: 1. koji/mbs create the mock.cfg file and start setting up a buildroot on a builder. 2. your script rewrites the mock.cfg with the config items and fake koji/mbs into everything is ok. 3. koji/mbs continues the build The problems with this method are the following: 1. You have to hand edit the script to know what modules are being used and for when. 2. You have to hope that 2 doesn't get abused in multiple ways 3. It is kludgy and breaks a lot so you end up doing a 'repeat build until either fail_counter=X || build_complete' 4. You end up needing to do this separately from the regular Fedora koji/mbs because if you can do this in one build root, you can do it in all.. The way EPEL is set up is a third way which is a 'best of worst worlds' method: 1. You download RHEL packages into a repository 2. You run a demodularizer which breaks apart the modules into a one tree. You have to be careful because some modules conflict so you only do the ones which are 'Default' or in CodeReady 3. You rebuild this into a single repository 4. koji looks at this as an external repository like it has done from EPEL-5 days. This uses a method which was meant for just kickstarting a build tree by having an external tree to point to but works for RHEL. Koji tries to deal with this but it causes issues 5. mbs still only knows how to use modules it built itself.. This means that the external modules in RHEL are invisible to it. This is what breaks it from being able to build PHP modules. In the end, the core problem is that we are (ab)using the koji/mbs build structure to do things it was never intended to do. It has been made to do it, but deep down it is like making pizza on a shovel at a blacksmith.. you can do it but neither the forge or the shovel were meant for this and you end up constantly trying to figure out how to remove coal tar from the food. > Ex: > https://rpms.remirepo.net/temp/epel-temp.repo > And mock configuration > https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg > > > > Remi > ___ > devel mailing list -- devel@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Le 24/06/2021 à 15:33, Matthew Miller a écrit : On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: P.S. yes, I'm really disappointed by how Fedora evolves, not being able to use a proper build system (modules aware) If you could wave a magic wand here, what would a proper build system look like? I'm fine with current tooling (Koji) I only like to be able to build additional packages for existing modules (e.g. php extensions in EPEL for php streams in RHEL) so in some new module (php-extras) or better in the same one (php) In short being able to run "fedpkg module build" from https://src.fedoraproject.org/modules/php-extras/tree/7.3 (work is ready for months) I still don't understand what Frankenstein buildroot we are using. 2 lines in a mock file allow to be aware of modules... modules=1 ... config_opts['module_enable'] = ['php:7.4', ... 2h of work to find the proper configuration and I was able to build such packages since the day RHEL-8-Beta was made publicly available, in May 2018... 3 years ago and still waiting for something to happen in EPEL Ex: https://rpms.remirepo.net/temp/epel-temp.repo And mock configuration https://git.remirepo.net/cgit/tools/mock.git/tree/epel874.cfg Remi ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jun 24, 2021 at 03:08:42PM +0200, Remi Collet wrote: > P.S. yes, I'm really disappointed by how Fedora evolves, > not being able to use a proper build system (modules aware) If you could wave a magic wand here, what would a proper build system look like? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Thu, Jun 24, 2021 at 9:09 AM Remi Collet wrote: > > Le 23/06/2021 à 10:57, Nico Kadel-Garcia a écrit : > > > I can't find *anyone* who likes modularity. > > I like modules ! > > BTW > > Community have killed SCL > Community is killing modules > Software Collections made the assumption that packager ergonomics did not matter. That is obviously patently false. Today, I could probably come up with an implementation of SCLs that is more packager-friendly by leveraging the existing abstractions in RPM and macros. We actually do this for Flatpak builds, so it's not a foreign concept. Conceptually, I like modules. However, after doing work to implement modularity in a build system, I want a better version of it. I'm not sure that will happen anytime soon, though. > EPEL-8 is IMHO partially broken, > and perhaps should be consider as dead. > > > > I'm devoutly hoping that it is discarded for RHEL 9. > > I rather hope than EPEL-9 will be better > and available for "Beta" time. > > > Remi > > > P.S. yes, I'm really disappointed by how Fedora evolves, > not being able to use a proper build system (modules aware) > in 2 years, while everyone else seems to be able to > do it quite shortly (CentOS, Alma, Rocky, Oracle...) The amount of cursing I've heard from the developers of all of those distributions over the modularity implementation should not be ignored. Every one of those did it because Red Hat did it, and I've advised a fair number of them on how to do it. At least one of them considered deviating from RHEL to get rid of it because the implementation is terrible. Among distribution tooling developers, the current modularity implementation is nearly universally hated. It makes assumptions about what kind of access the build system has, is deeply tied into Koji+MBS, has poor local build support, and the modulemd formats weren't designed for outside use in mind (assumptions around dist-git, commitish, direct access to cherry-pick from Koji, etc.). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
Le 23/06/2021 à 10:57, Nico Kadel-Garcia a écrit : I can't find *anyone* who likes modularity. I like modules ! BTW Community have killed SCL Community is killing modules EPEL-8 is IMHO partially broken, and perhaps should be consider as dead. > I'm devoutly hoping that it is discarded for RHEL 9. I rather hope than EPEL-9 will be better and available for "Beta" time. Remi P.S. yes, I'm really disappointed by how Fedora evolves, not being able to use a proper build system (modules aware) in 2 years, while everyone else seems to be able to do it quite shortly (CentOS, Alma, Rocky, Oracle...) ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On 6/22/21 7:42 PM, Stephen John Smoogen wrote: On Tue, 22 Jun 2021 at 13:22, Jiri Vanek wrote: On 6/22/21 7:08 PM, Stephen John Smoogen wrote: On Tue, 22 Jun 2021 at 12:30, Jiri Vanek wrote: Hello! I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8: Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8: CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 Error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering web search is failing me. Is there some magical spec switch which is enbaling... modules? or something? Welcome to RHEL-8 modularity and the joy it brings anyone trying to port software to 8. The problem is not with EPEL but with the way hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in twilight :-) various modules in 8 interact. I that the issue is that one of the 'java' modules conflicts with the maven and won't allow it to be installed when it is. In order to deal with this you have to edit a /etc/mock for your software with config_opts['module_enable'] = ['maven'] config_opts['module_install'] = ['maven'] in the appropriate place and it will build locally. Or you can try to do a scratch build in koji to see if the de-modularization script allows it. I can easily do this localy, but for fedpkg build? it seems that there si some corner of koji I was not aware till now! So the original email doesn't say how you got this error. Was it from a Sorry for it. mock -r It happens in local mock too, but I can workaround it here (moreover as you wrote up) fedpkg local fedpkg build or koji right, fedpkg build is my main trouble. The error you listed should not happen with builds in koji. We use a hack to demodularize RHEL8 so that things 'work'.. however it is a Interesting! I actually thought it is vice versa - that all modules are disabled for non modular builds. Id the default streems are now enabled, then I'm not sure how that issue could happen. hack on top of a kludge so not all cases may work. [If you got this via a `fedpkg build` then this may just be impossible to build without it being a module.] oh gosh:( not that:( > I can't find *anyone* who likes modularity. I'm devoutly hoping that it is discarded for RHEL 9. Right. The idea was excellent but the implementation was really completely barked out:( Thanx a lot for help! -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: > > > > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to > > port software to 8. The problem is not with EPEL but with the way > > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in > twilight :-) I can't find *anyone* who likes modularity. I'm devoutly hoping that it is discarded for RHEL 9. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Tue, 22 Jun 2021 at 13:22, Jiri Vanek wrote: > > > > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: > > On Tue, 22 Jun 2021 at 12:30, Jiri Vanek wrote: > >> > >> Hello! > >> > >> I have an ordinery package, which builds as is for epel7,and all fedoras, > >> but not for epel8: > >> > >> Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not > >> in epel8: > >> CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 > >> Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 > >> Error: > >>Problem 1: conflicting requests > >> - package > >> maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is > >> filtered out by modular filtering > >>Problem 2: conflicting requests > >> - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch > >> is filtered out by modular filtering > >>Problem 3: conflicting requests > >> - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is > >> filtered out by modular filtering > >> > >> > >> > >> web search is failing me. Is there some magical spec switch which is > >> enbaling... modules? or something? > >> > > > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to > > port software to 8. The problem is not with EPEL but with the way > > hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in > twilight :-) > > various modules in 8 interact. I that the issue is that one of the > > 'java' modules conflicts with the maven and won't allow it to be > > installed when it is. In order to deal with this you have to edit a > > /etc/mock for your software with > > > > config_opts['module_enable'] = ['maven'] > > config_opts['module_install'] = ['maven'] > > > > in the appropriate place and it will build locally. Or you can try to > > do a scratch build in koji to see if the de-modularization script > > allows it. > > I can easily do this localy, but for fedpkg build? it seems that there si > some corner of koji I was not aware till now! So the original email doesn't say how you got this error. Was it from a mock -r fedpkg local fedpkg build or koji The error you listed should not happen with builds in koji. We use a hack to demodularize RHEL8 so that things 'work'.. however it is a hack on top of a kludge so not all cases may work. [If you got this via a `fedpkg build` then this may just be impossible to build without it being a module.] -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On 6/22/21 7:08 PM, Stephen John Smoogen wrote: On Tue, 22 Jun 2021 at 12:30, Jiri Vanek wrote: Hello! I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8: Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8: CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 Error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering web search is failing me. Is there some magical spec switch which is enbaling... modules? or something? Welcome to RHEL-8 modularity and the joy it brings anyone trying to port software to 8. The problem is not with EPEL but with the way hmm. Thanx a lot of for a bt of light in darknes.. or mayb emore darkness in twilight :-) various modules in 8 interact. I that the issue is that one of the 'java' modules conflicts with the maven and won't allow it to be installed when it is. In order to deal with this you have to edit a /etc/mock for your software with config_opts['module_enable'] = ['maven'] config_opts['module_install'] = ['maven'] in the appropriate place and it will build locally. Or you can try to do a scratch build in koji to see if the de-modularization script allows it. I can easily do this localy, but for fedpkg build? it seems that there si some corner of koji I was not aware till now! -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: building against epel8 modules
On Tue, 22 Jun 2021 at 12:30, Jiri Vanek wrote: > > Hello! > > I have an ordinery package, which builds as is for epel7,and all fedoras, but > not for epel8: > > Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in > epel8: > CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 > Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 > Error: > Problem 1: conflicting requests >- package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch > is filtered out by modular filtering > Problem 2: conflicting requests >- package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is > filtered out by modular filtering > Problem 3: conflicting requests >- package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is > filtered out by modular filtering > > > > web search is failing me. Is there some magical spec switch which is > enbaling... modules? or something? > Welcome to RHEL-8 modularity and the joy it brings anyone trying to port software to 8. The problem is not with EPEL but with the way various modules in 8 interact. I that the issue is that one of the 'java' modules conflicts with the maven and won't allow it to be installed when it is. In order to deal with this you have to edit a /etc/mock for your software with config_opts['module_enable'] = ['maven'] config_opts['module_install'] = ['maven'] in the appropriate place and it will build locally. Or you can try to do a scratch build in koji to see if the de-modularization script allows it. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
building against epel8 modules
Hello! I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8: Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8: CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 Error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering web search is failing me. Is there some magical spec switch which is enbaling... modules? or something? Thanx! j. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
