11:27 a.m.
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
12:08 p.m.
On Tue, 22 Jun 2021 at 12:30, Jiri Vanek <jvanek(a)redhat.com> 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.
12:22 p.m.
On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Tue, 22 Jun 2021 at 12:30, Jiri Vanek <jvanek(a)redhat.com>
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!
12:42 p.m.
On Tue, 22 Jun 2021 at 13:22, Jiri Vanek <jvanek(a)redhat.com> wrote:
On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
> On Tue, 22 Jun 2021 at 12:30, Jiri Vanek <jvanek(a)redhat.com> 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 <blah>
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.
11:57 a.m.
On 6/22/21 7:42 PM, Stephen John Smoogen wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Tue, 22 Jun 2021 at 13:22, Jiri Vanek <jvanek(a)redhat.com>
wrote:
>
>
>
> On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
>> On Tue, 22 Jun 2021 at 12:30, Jiri Vanek <jvanek(a)redhat.com> 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 <blah>
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!
3:57 a.m.
On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> 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.
8:08 a.m.
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...)
8:16 a.m.
On Thu, Jun 24, 2021 at 9:09 AM Remi Collet <Fedora(a)famillecollet.com> 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!
8:33 a.m.
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:02 a.m.
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
9:44 a.m.
On Thu, 24 Jun 2021 at 10:03, Remi Collet <Fedora(a)famillecollet.com> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
11:04 a.m.
...
>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
8:19 p.m.
On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com>
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
10:24 p.m.
On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>
> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> 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.
10:25 p.m.
On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
>
>
> On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>>
>> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> 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".
4:52 a.m.
Dne 02. 07. 21 v 5:25 Nico Kadel-Garcia napsal(a):
On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia
<nkadel(a)gmail.com> wrote:
> On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>>
>>
>> On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>>> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com> 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
12:09 p.m.
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 <nkadel(a)gmail.com> wrote:
>> On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
>>>
>>>
>>> On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
>>>> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek <jvanek(a)redhat.com>
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
12:09 p.m.
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
1008
days inactive
1032
days old
18 comments
9 participants
participants (9)
-
Gary Buhrmaster -
Jiri Vanek -
Josh Boyer -
Matthew Miller -
Neal Gompa -
Nico Kadel-Garcia -
Remi Collet -
Stephen John Smoogen -
Vít Ondruch