Re: modular repositories in mock configs: please don't

[Miroslav Suchý]

Dne 06. 03. 19 v 14:00 Mikolaj Izdebski napsal(a):
> - create a proper modulemd document
> - build some (zero or more) RPM packages using rpmbuild
> - create YUM repodata from built packages using createrepo_c
> - attach modulemd to repodata using modifyrepo_c

Yes. But the first and last steps needs to be automated. No ones wants to do 
that manually.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Stephen John Smoogen]

On Wed, 6 Mar 2019 at 07:53, Ken Dreyer  wrote:
>
>
>
> On Tue, Mar 5, 2019, 12:53 PM Miroslav Suchý  wrote:
>>
>> Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a):
>> >
>> > I'm there with you Richard. I don't really get how I can get started 
>> > building a module outside of the Fedora
>> > infrastructure's system (Koji or Copr).
>>
>> In fact, Copr support building modules for ages - even before the modularity 
>> has been finalized.
>>
>> You just create project in Copr, build regular packages there. Then you 
>> click on "Modules" tab, then "Create new
>> module", select which packages should be part of module and submit the form. 
>> Few seconds later your module should be ready.
>>
>> Copr does not support all features of modularity, because the format of 
>> modules changed every few week and it was hard
>> for us to keep pace. But you are simply build simple module in Copr.
>
>
> What I meant was that I don't know how to do this outside of Koji or Copr. My 
> use cases:
>
> * I want to experiment on my laptop,
> * I want to build modules I cannot distribute through Copr,
> * I have a large project with many changes every day, and if I sent all of 
> those into copr.fedoraproject.org via Jenkins, it could melt down
>
> With Fedora regular RPMs, fedpkg has "mockbuild" to do local builds. How can 
> I do something similar on my laptop for a module?
>

I think you are looking for the same thing a lot of people are
wanting: A detailed "How the henry do I do this locally without using
your buildsystem?" howto. Followed by "how to I use this for my own
build system." and then "How do I do integrate this with some other
system?" I am saying this because I see a lot of the frustration and
venting seems to be that this information isn't easily found if it
exists. I think that until such stuff is written, then we can get to
informed frustrations of 'why did you do it this way?'


>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Mikolaj Izdebski]

On Wed, Mar 6, 2019 at 1:54 PM Ken Dreyer  wrote:
> With Fedora regular RPMs, fedpkg has "mockbuild" to do local builds. How can 
> I do something similar on my laptop for a module?

Modules are just sets of RPMs with extra metadata. To build a module
it is enoug to:
- create a proper modulemd document
- build some (zero or more) RPM packages using rpmbuild
- create YUM repodata from built packages using createrepo_c
- attach modulemd to repodata using modifyrepo_c

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Ken Dreyer]

On Tue, Mar 5, 2019, 12:53 PM Miroslav Suchý  wrote:

> Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a):
> >
> > I'm there with you Richard. I don't really get how I can get started
> building a module outside of the Fedora
> > infrastructure's system (Koji or Copr).
>
> In fact, Copr support building modules for ages - even before the
> modularity has been finalized.
>
> You just create project in Copr, build regular packages there. Then you
> click on "Modules" tab, then "Create new
> module", select which packages should be part of module and submit the
> form. Few seconds later your module should be ready.
>
> Copr does not support all features of modularity, because the format of
> modules changed every few week and it was hard
> for us to keep pace. But you are simply build simple module in Copr.
>

What I meant was that I don't know how to do this outside of Koji or Copr.
My use cases:

* I want to experiment on my laptop,
* I want to build modules I cannot distribute through Copr,
* I have a large project with many changes every day, and if I sent all of
those into copr.fedoraproject.org via Jenkins, it could melt down

With Fedora regular RPMs, fedpkg has "mockbuild" to do local builds. How
can I do something similar on my laptop for a module?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Ralf Corsepius]

On 3/5/19 9:08 AM, Adam Samalik wrote:

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  wrote:


On 3/4/19 3:04 AM, Petr Šabata wrote:

You can view them as virtual repositories with dependencies.  I
think that might be the simplest way to put it.

You can try playing with fedmod to generate your modulemd file or
you can just write it from scratch; it's not all that complicated.


Why should I care? Please, win me over. (I'm being serious.)



I think you should care if:

a) You need to maintain multiple versions of the same app/runtime/set of
tools tools in Fedora (or an alternative to something that already exists),
or
b) You only want to maintain one source branch per package for all Fedora
releases, or
c) You could benefit from having a build recipe in case you maintain
app/runtime/set of tools tools represented by multiple packages that need
to be built in the right order

But if any of the above is something that you need/want to do, then
Modularity won't help you nor hurt you in any way.


All of what list above can be handled at the rpm-level by means of 
"proper" system integration.


That said, to me, modules are an approach to circumvent system integration.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[stan]

On Tue, 5 Mar 2019 11:18:04 -0500
Neal Gompa  wrote:

> No. It should be possible for modular content to become non-modular
> and vice versa.

Thanks for the response and the information.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miroslav Suchý]

Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a):
> 
> I'm there with you Richard. I don't really get how I can get started building 
> a module outside of the Fedora
> infrastructure's system (Koji or Copr).

In fact, Copr support building modules for ages - even before the modularity 
has been finalized.

You just create project in Copr, build regular packages there. Then you click 
on "Modules" tab, then "Create new
module", select which packages should be part of module and submit the form. 
Few seconds later your module should be ready.

Copr does not support all features of modularity, because the format of modules 
changed every few week and it was hard
for us to keep pace. But you are simply build simple module in Copr.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Neal Gompa]

On Tue, Mar 5, 2019 at 11:01 AM stan  wrote:
>
> On Tue, 5 Mar 2019 09:08:19 +0100
> Adam Samalik  wrote:
>
> > On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth 
> > wrote:
>
> > > Why should I care? Please, win me over. (I'm being serious.)
> > >
> >
> > I think you should care if:
> >
> > a) You need to maintain multiple versions of the same app/runtime/set
> > of tools tools in Fedora (or an alternative to something that already
> > exists), or
> > b) You only want to maintain one source branch per package for all
> > Fedora releases, or
> > c) You could benefit from having a build recipe in case you maintain
> > app/runtime/set of tools tools represented by multiple packages that
> > need to be built in the right order
> >
> > But if any of the above is something that you need/want to do, then
> > Modularity won't help you nor hurt you in any way.
> >
> >
> > > I view the current RPM system as reliable, standard, and
> > > well-documented. It's
> > > served me and the people I know that use it well for decades. I view
> > > Modularity as
> > > an answer to a question no one asked. It presents new problems that
> > > never existed
> > > and has been somewhat silently taking over RPM-land with very little
> > > community
> > > involvement.
>
> I'm not a packager, I only follow devel to see what is coming down
> the pipe as a user.  I'm concerned about modularity.  Like Michael, I
> find rpm works fine for my use case, an individual workstation.  I have
> a couple of comments, but since I am not the target of modularity, take
> them as curiosity.
>
> It seems that modularity will create one more layer of indirection, so
> security holes will be more prone to exist and be harder to find and
> fix for the user, particularly on mixed rpm / modularity systems.
>

Modules are merely collections of rpms built in a special way.
Sometimes that's with macro definitions to force overrides for
specific configurations, and sometimes that's with filtering packages,
or customizing build and runtime content.

> Modularity seems to be a workaround to avoid making the system fully
> multi version.  Admittedly, that is a lot of work, gcc has to be
> modified to create a dictionary of libraries and api calls needed in
> executables, libraries have to be modified to publish their api calls,
> the kernel has to sort through multiple versions of a binary checking
> priorities (somehow).  rpm has to be modified to allow multiple version
> installation, and to do library checking to be sure that an existing
> library will cover needed calls. There has to be garbage collection for
> libraries no longer needed by executables on the system.  etc.  The up
> side is there is no more shared library so numbers for libraries, so
> updates will *always* succeed, and the garbage collector will take
> care of no longer needed packages. Is the following a good summarization
> of the purpose of modularity? Modularity is a workaround using the
> pareto principle to get 80% of the benefits of multi version with only
> 20% of the work.
>

RPM already allows multiversion installation with the caveat that
there are no file collisions. The other aspects are things that can be
handled by DNF. Modules are only about some of those use cases. The
other major cases involve build-time customization and partitioning
built packages into supportable or non-supportable groups.

> Would it be practical to have a new hierarchy under /usr for
> modularity, say /usr/mod, or move the current /usr to /usr/rpm and
> let /usr be for modularity?  This would make it easier to specify which
> version of a binary to run, and which should be default in the path.
> So, if I install a module with old, possibly insecure components,
> because I need it for legacy purposes, I can specify it in a script, and
> let the newer version be the default for general use.

No. It should be possible for modular content to become non-modular
and vice versa.



-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[stan]

On Tue, 5 Mar 2019 09:08:19 +0100
Adam Samalik  wrote:

> On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth 
> wrote:

> > Why should I care? Please, win me over. (I'm being serious.)
> >  
> 
> I think you should care if:
> 
> a) You need to maintain multiple versions of the same app/runtime/set
> of tools tools in Fedora (or an alternative to something that already
> exists), or
> b) You only want to maintain one source branch per package for all
> Fedora releases, or
> c) You could benefit from having a build recipe in case you maintain
> app/runtime/set of tools tools represented by multiple packages that
> need to be built in the right order
> 
> But if any of the above is something that you need/want to do, then
> Modularity won't help you nor hurt you in any way.
> 
> 
> > I view the current RPM system as reliable, standard, and
> > well-documented. It's
> > served me and the people I know that use it well for decades. I view
> > Modularity as
> > an answer to a question no one asked. It presents new problems that
> > never existed
> > and has been somewhat silently taking over RPM-land with very little
> > community
> > involvement.

I'm not a packager, I only follow devel to see what is coming down
the pipe as a user.  I'm concerned about modularity.  Like Michael, I
find rpm works fine for my use case, an individual workstation.  I have
a couple of comments, but since I am not the target of modularity, take
them as curiosity.

It seems that modularity will create one more layer of indirection, so
security holes will be more prone to exist and be harder to find and
fix for the user, particularly on mixed rpm / modularity systems.

Modularity seems to be a workaround to avoid making the system fully
multi version.  Admittedly, that is a lot of work, gcc has to be
modified to create a dictionary of libraries and api calls needed in
executables, libraries have to be modified to publish their api calls,
the kernel has to sort through multiple versions of a binary checking
priorities (somehow).  rpm has to be modified to allow multiple version
installation, and to do library checking to be sure that an existing
library will cover needed calls. There has to be garbage collection for
libraries no longer needed by executables on the system.  etc.  The up
side is there is no more shared library so numbers for libraries, so
updates will *always* succeed, and the garbage collector will take
care of no longer needed packages. Is the following a good summarization
of the purpose of modularity? Modularity is a workaround using the
pareto principle to get 80% of the benefits of multi version with only
20% of the work.

Would it be practical to have a new hierarchy under /usr for
modularity, say /usr/mod, or move the current /usr to /usr/rpm and
let /usr be for modularity?  This would make it easier to specify which
version of a binary to run, and which should be default in the path.
So, if I install a module with old, possibly insecure components,
because I need it for legacy purposes, I can specify it in a script, and
let the newer version be the default for general use.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Vít Ondruch]

Dne 05. 03. 19 v 9:08 Adam Samalik napsal(a):
>
>
> On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  > wrote:
>
> On 3/4/19 3:04 AM, Petr Šabata wrote:
> > You can view them as virtual repositories with dependencies.  I
> > think that might be the simplest way to put it.
> >
> > You can try playing with fedmod to generate your modulemd file or
> > you can just write it from scratch; it's not all that complicated.
>
> Why should I care? Please, win me over. (I'm being serious.)
>
>
> I think you should care if:


I am afraid you are missing one point. You need to care if somebody else
believes the points you list below are relevant. This is the issue.


Vít



>
> a) You need to maintain multiple versions of the same app/runtime/set
> of tools tools in Fedora (or an alternative to something that already
> exists), or
> b) You only want to maintain one source branch per package for all
> Fedora releases, or
> c) You could benefit from having a build recipe in case you maintain
> app/runtime/set of tools tools represented by multiple packages that
> need to be built in the right order
>
> But if any of the above is something that you need/want to do, then
> Modularity won't help you nor hurt you in any way.
>
>
> I view the current RPM system as reliable, standard, and
> well-documented. It's
> served me and the people I know that use it well for decades. I
> view Modularity as
> an answer to a question no one asked. It presents new problems
> that never existed
> and has been somewhat silently taking over RPM-land with very
> little community
> involvement.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
>
> Adam Šamalík
> ---
> Software Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Adam Samalik]

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  wrote:

> On 3/4/19 3:04 AM, Petr Šabata wrote:
> > You can view them as virtual repositories with dependencies.  I
> > think that might be the simplest way to put it.
> >
> > You can try playing with fedmod to generate your modulemd file or
> > you can just write it from scratch; it's not all that complicated.
>
> Why should I care? Please, win me over. (I'm being serious.)
>

I think you should care if:

a) You need to maintain multiple versions of the same app/runtime/set of
tools tools in Fedora (or an alternative to something that already exists),
or
b) You only want to maintain one source branch per package for all Fedora
releases, or
c) You could benefit from having a build recipe in case you maintain
app/runtime/set of tools tools represented by multiple packages that need
to be built in the right order

But if any of the above is something that you need/want to do, then
Modularity won't help you nor hurt you in any way.


> I view the current RPM system as reliable, standard, and well-documented.
> It's
> served me and the people I know that use it well for decades. I view
> Modularity as
> an answer to a question no one asked. It presents new problems that never
> existed
> and has been somewhat silently taking over RPM-land with very little
> community
> involvement.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Michael Cronenworth]

On 3/4/19 3:04 AM, Petr Šabata wrote:

You can view them as virtual repositories with dependencies.  I
think that might be the simplest way to put it.

You can try playing with fedmod to generate your modulemd file or
you can just write it from scratch; it's not all that complicated.


Why should I care? Please, win me over. (I'm being serious.)

I view the current RPM system as reliable, standard, and well-documented. It's 
served me and the people I know that use it well for decades. I view Modularity as 
an answer to a question no one asked. It presents new problems that never existed 
and has been somewhat silently taking over RPM-land with very little community 
involvement.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Michael Cronenworth]

On 3/1/19 8:25 AM, Richard Shaw wrote:

Not replying to anyone in particular but just a nit for me...

I've been a Fedora packager for probably 10 years now (need to check!) but I 
*STILL* don't really understand modules other than at a high level (it lets you 
use dependencies that aren't available in the main repos). I've read through some 
of the documentation but it's still not clear. I know I would have to crate some 
kind of module file which I think tools could be developed to mostly automate 
(spec->module template converter?).


While modularity is more of a Fedora thing I think it's sad that for more standard 
tools I reference Arch documentation more often than Fedora documentation. Of 
course there's the, "I could help with that" part and I might, but frankly I can 
barely keep up with my packages between $DAYJOB, $FAMILY, Fedora, and RPM Fusion.


+1. I stumbled upon this email among the hundreds I get hourly. My sentiment mirrors 
yours bit for bit.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Stephen Gallagher]

On Mon, Mar 4, 2019 at 11:36 AM Ken Dreyer  wrote:
>
>
>
> On Fri, Mar 1, 2019, 8:26 AM Richard Shaw  wrote:
>>
>> Not replying to anyone in particular but just a nit for me...
>>
>> I've been a Fedora packager for probably 10 years now (need to check!) but I 
>> *STILL* don't really understand modules other than at a high level (it lets 
>> you use dependencies that aren't available in the main repos). I've read 
>> through some of the documentation but it's still not clear. I know I would 
>> have to crate some kind of module file which I think tools could be 
>> developed to mostly automate (spec->module template converter?).
>>
>> While modularity is more of a Fedora thing I think it's sad that for more 
>> standard tools I reference Arch documentation more often than Fedora 
>> documentation. Of course there's the, "I could help with that" part and I 
>> might, but frankly I can barely keep up with my packages between $DAYJOB, 
>> $FAMILY, Fedora, and RPM Fusion.
>
>
> I'm there with you Richard. I don't really get how I can get started building 
> a module outside of the Fedora infrastructure's system (Koji or Copr).
>
> I'm hoping this gets a lot clearer after modules come in RHEL 8 and we get 
> concrete examples.
>


This is a known gap. We're having a Modularity hackfest in Boston
right now and looking into how we're going to make this simpler and
easier.  Stay tuned.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Ken Dreyer]

On Fri, Mar 1, 2019, 8:26 AM Richard Shaw  wrote:

> Not replying to anyone in particular but just a nit for me...
>
> I've been a Fedora packager for probably 10 years now (need to check!) but
> I *STILL* don't really understand modules other than at a high level (it
> lets you use dependencies that aren't available in the main repos). I've
> read through some of the documentation but it's still not clear. I know I
> would have to crate some kind of module file which I think tools could be
> developed to mostly automate (spec->module template converter?).
>
> While modularity is more of a Fedora thing I think it's sad that for more
> standard tools I reference Arch documentation more often than Fedora
> documentation. Of course there's the, "I could help with that" part and I
> might, but frankly I can barely keep up with my packages between $DAYJOB,
> $FAMILY, Fedora, and RPM Fusion.
>

I'm there with you Richard. I don't really get how I can get started
building a module outside of the Fedora infrastructure's system (Koji or
Copr).

I'm hoping this gets a lot clearer after modules come in RHEL 8 and we get
concrete examples.

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Fabio Valentini]

On Mon, Mar 4, 2019, 11:41 Pavel Raiskup  wrote:

> On Monday, March 4, 2019 11:21:05 AM CET Petr Šabata wrote:
> > I suggested to drop the modular repo from the mock config to get
> > an environment similar to what we have in koji.
>
> It is disabled here anyways:
> https://github.com/rpm-software-management/mock/commit/
> 65d87447c44e0a4ae628306b701b9d805fed0b24
>

Yes. It was disabled because of this thread ...


> .. but I doubt it is needed;  can anyone explain how we can afford to have
> those modules enabled by default in fedora-repos.rpm (fedora users) but we
> can not in mock?
>
> > The koji change might take a while, and, as noted, the module set
> > available in koji might ultimately differ from the one in distribution
> > repos.
>
> I'd warn against such differences.  Wouldn't it make the understanding of
> the whole Fedora build system even worse, and doesn't it lead to
> ultimately broken design of _pre-compiled_ distro?
>
> Pavel
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Pavel Raiskup]

On Monday, March 4, 2019 11:21:05 AM CET Petr Šabata wrote:
> I suggested to drop the modular repo from the mock config to get
> an environment similar to what we have in koji.

It is disabled here anyways:
https://github.com/rpm-software-management/mock/commit/
65d87447c44e0a4ae628306b701b9d805fed0b24

.. but I doubt it is needed;  can anyone explain how we can afford to have
those modules enabled by default in fedora-repos.rpm (fedora users) but we
can not in mock?

> The koji change might take a while, and, as noted, the module set
> available in koji might ultimately differ from the one in distribution
> repos.

I'd warn against such differences.  Wouldn't it make the understanding of
the whole Fedora build system even worse, and doesn't it lead to
ultimately broken design of _pre-compiled_ distro?

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Stephen John Smoogen]

On Mon, 4 Mar 2019 at 05:22, Adam Samalik  wrote:
>
>
>
> On Mon, Mar 4, 2019 at 11:13 AM Pavel Raiskup  wrote:
>>
>> On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
>> > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
>> > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
>> > > > Replying in general.
>> > > >
>> > > > While it's never been entirely the same, I'd also like our mock configs
>> > > > to be as close to koji environment as possible.  In the current
>> > > > situation that would mean no modules being available.
>> > >
>> > > I don't understand your point of view.  If it is safe to enable modular
>> > > repositories on user boxes by default (that's what we have now), why we
>> > > can not enable them in koji and why we can not enable them in mock?
>> >
>> > We're currently discussing how to enable them in koji.  It's just not
>> > the case at the moment.  Also the module set available and enabled in
>> > koji might differ from the repo we ship.
>>
>> So the thing is to fix koji, not to fix mock - but you suggested to remove
>> modular repos from mock config, iirc so why?  So if there's actually a
>> reason to do so, shouldn't we removed it from
>> /etc/yum.repos.d/fedora-modular.repo as well?
>
>
> That's exactly right, we need to "fix" this situation in Koji. And while 
> we're doing that, we want to maintain consistency between Koji and Mock.
>

I think part of the confusion is that a lot of people just assume koji
mock pulls in packages just like local mock with it pulling data from
/pub/fedora/linux/{releases,updates} versus the generated buildroot
from tagged packages that koji uses. So a lot of the 'oh its so easy,
you can just do this...' doesn't seem to work because what koji mock
repos get is something completely different. [I actually don't know
enough myself to better explain it than .. the koji people said they
were different and it doesn't work the way you think.] Getting a
better diagram of why it doesn't work might help explain to people why
it is taking so long and why various 'oh that would be simple' have
turned into 'ohh that wont work here'.


> The goal is to support standalone packages to depend (both runtime and build 
> time) on default modules — so maintainers can choose wether they can have 
> their packages in a module or not without influencing the rest. However, that 
> work is in progress. We already support the runtime dep part (that's the 
> reason of having /etc/yum.repos.d/fedora-modular.repo on the system) but not 
> the build part because the infra is not ready (that's why we don't have that 
> in mock at the moment).
>
>>
>> > > > Once/if we proceed with one of the modules-in-the-non-modular-buildroot
>> > > > proposals, I would like them to include the same module set that is
>> > > > available in the non-modular buildroot in koji.
>> > >
>> > > Can you elaborate?  How the 'non-modular buildroot in koji' differs from
>> > > modules-in-the-non-modular-buildroot?
>> >
>> > https://pagure.io/fesco/issue/2003
>> >
>> > The standard buildroot doesn't currently include any modular
>> > content.  There are ways to put it in but we haven't decided how
>> > to do it yet.
>> >
>> > Non-modular buildroot is the base buildroot that non-modular
>> > packages use to build.  It may or may not include modules.  It
>> > currently doesn't but we would like to change that.
>> >
>> > Once it does, I would like the mock config to include modules that
>> > the koji buildroot includes.  Currently it doesn't include any so
>> > I'd rather not include any.
>>
>> Ah, so we consider "modular" content to be a standard, and non-modular to
>> be non-standard.  I understood it vice versa before TBH.
>>
>>
>> > > > If you're building content that depends on modular packages at this
>> > > > point, you should be building a module anyway.
>> > >
>> > > Please elaborate on "why" on this, too.
>> >
>> > Since the buildroot normally doesn't include modules (see above)
>> > and there might be multiple incompatible streams anyway, you
>> > should build your content as a module and define proper
>> > module-level dependencies on the content you need -- either to
>> > build, to run, or both.
>>
>> You should be able to pick what you build/run/both against, and there
>> should be some default (== no stream enabled by default seems to be the
>> sanest default to me).
>>
>> > I don't think this is all that different from normal package
>> > builds where you simply declare your RPM-level deps rather than
>> > hope that something is magically pulled into the buildroot or
>> > already installed on the system.
>>
>> Well, this comes from my misunderstanding how the modularity is used
>> probably...  E.g. there are attempts to move e.g. java stack to modular
>> content - only because the MBS allows building against all fedora release
>> by one command (== to avoid fedora branching "burden").  Even though this
>> use-case is probably a misuse - to explain why I'm 

Re: modular repositories in mock configs: please don't

[Adam Samalik]

On Mon, Mar 4, 2019 at 11:13 AM Pavel Raiskup  wrote:

> On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
> > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > > > Replying in general.
> > > >
> > > > While it's never been entirely the same, I'd also like our mock
> configs
> > > > to be as close to koji environment as possible.  In the current
> > > > situation that would mean no modules being available.
> > >
> > > I don't understand your point of view.  If it is safe to enable modular
> > > repositories on user boxes by default (that's what we have now), why we
> > > can not enable them in koji and why we can not enable them in mock?
> >
> > We're currently discussing how to enable them in koji.  It's just not
> > the case at the moment.  Also the module set available and enabled in
> > koji might differ from the repo we ship.
>
> So the thing is to fix koji, not to fix mock - but you suggested to remove
> modular repos from mock config, iirc so why?  So if there's actually a
> reason to do so, shouldn't we removed it from
> /etc/yum.repos.d/fedora-modular.repo as well?
>

That's exactly right, we need to "fix" this situation in Koji. And while
we're doing that, we want to maintain consistency between Koji and Mock.

The goal is to support standalone packages to depend (both runtime and
build time) on default modules — so maintainers can choose wether they can
have their packages in a module or not without influencing the rest.
However, that work is in progress. We already support the runtime dep part
(that's the reason of having /etc/yum.repos.d/fedora-modular.repo on the
system) but not the build part because the infra is not ready (that's why
we don't have that in mock at the moment).


> > > > Once/if we proceed with one of the
> modules-in-the-non-modular-buildroot
> > > > proposals, I would like them to include the same module set that is
> > > > available in the non-modular buildroot in koji.
> > >
> > > Can you elaborate?  How the 'non-modular buildroot in koji' differs
> from
> > > modules-in-the-non-modular-buildroot?
> >
> > https://pagure.io/fesco/issue/2003
> >
> > The standard buildroot doesn't currently include any modular
> > content.  There are ways to put it in but we haven't decided how
> > to do it yet.
> >
> > Non-modular buildroot is the base buildroot that non-modular
> > packages use to build.  It may or may not include modules.  It
> > currently doesn't but we would like to change that.
> >
> > Once it does, I would like the mock config to include modules that
> > the koji buildroot includes.  Currently it doesn't include any so
> > I'd rather not include any.
>
> Ah, so we consider "modular" content to be a standard, and non-modular to
> be non-standard.  I understood it vice versa before TBH.


> > > > If you're building content that depends on modular packages at this
> > > > point, you should be building a module anyway.
> > >
> > > Please elaborate on "why" on this, too.
> >
> > Since the buildroot normally doesn't include modules (see above)
> > and there might be multiple incompatible streams anyway, you
> > should build your content as a module and define proper
> > module-level dependencies on the content you need -- either to
> > build, to run, or both.
>
> You should be able to pick what you build/run/both against, and there
> should be some default (== no stream enabled by default seems to be the
> sanest default to me).
>
> > I don't think this is all that different from normal package
> > builds where you simply declare your RPM-level deps rather than
> > hope that something is magically pulled into the buildroot or
> > already installed on the system.
>
> Well, this comes from my misunderstanding how the modularity is used
> probably...  E.g. there are attempts to move e.g. java stack to modular
> content - only because the MBS allows building against all fedora release
> by one command (== to avoid fedora branching "burden").  Even though this
> use-case is probably a misuse - to explain why I'm asking - I'd still
> expect that the java modular content is somehow available in buildroots
> by default configured in mock.
>

That's the point, exactly. But, as I stated above, the work is in progress
and we need to maintain consistency. The Java situation is somehow
happening earlier than it should.


>
> Pavel
>
> > > > In that case your local MBS manages the build and pulls the relevant
> > > > packages for you.
> > >
> > > Ok, but consider that
> > >
> > >   $ mock -r fedora-rawhide-x86_64 \
> > >
> > > --config-opts module_enable=postgresql:10
> > > --rebuild my.srpm
> > >
> > > is much more convenient and economical than approaching the whole MBS
> > > "thingy".
> >
> > This is actually pretty cool.
> >
> > P
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Re: modular repositories in mock configs: please don't

[Petr Šabata]

On Mon, Mar 04, 2019 at 11:11:48AM +0100, Pavel Raiskup wrote:
> On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
> > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > > > Replying in general.
> > > > 
> > > > While it's never been entirely the same, I'd also like our mock configs
> > > > to be as close to koji environment as possible.  In the current
> > > > situation that would mean no modules being available.
> > > 
> > > I don't understand your point of view.  If it is safe to enable modular
> > > repositories on user boxes by default (that's what we have now), why we
> > > can not enable them in koji and why we can not enable them in mock?
> > 
> > We're currently discussing how to enable them in koji.  It's just not
> > the case at the moment.  Also the module set available and enabled in
> > koji might differ from the repo we ship.
> 
> So the thing is to fix koji, not to fix mock - but you suggested to remove
> modular repos from mock config, iirc so why?  So if there's actually a
> reason to do so, shouldn't we removed it from
> /etc/yum.repos.d/fedora-modular.repo as well?

I suggested to drop the modular repo from the mock config to get
an environment similar to what we have in koji.  The koji change
might take a while, and, as noted, the module set available in
koji might ultimately differ from the one in distribution repos.

> > > > Once/if we proceed with one of the modules-in-the-non-modular-buildroot
> > > > proposals, I would like them to include the same module set that is
> > > > available in the non-modular buildroot in koji.
> > > 
> > > Can you elaborate?  How the 'non-modular buildroot in koji' differs from
> > > modules-in-the-non-modular-buildroot?
> > 
> > https://pagure.io/fesco/issue/2003
> > 
> > The standard buildroot doesn't currently include any modular
> > content.  There are ways to put it in but we haven't decided how
> > to do it yet.
> > 
> > Non-modular buildroot is the base buildroot that non-modular
> > packages use to build.  It may or may not include modules.  It
> > currently doesn't but we would like to change that.
> > 
> > Once it does, I would like the mock config to include modules that
> > the koji buildroot includes.  Currently it doesn't include any so
> > I'd rather not include any.
> 
> Ah, so we consider "modular" content to be a standard, and non-modular to
> be non-standard.  I understood it vice versa before TBH.

No.  Where am I saying that?

> > > > If you're building content that depends on modular packages at this
> > > > point, you should be building a module anyway.
> > > 
> > > Please elaborate on "why" on this, too.
> > 
> > Since the buildroot normally doesn't include modules (see above)
> > and there might be multiple incompatible streams anyway, you
> > should build your content as a module and define proper
> > module-level dependencies on the content you need -- either to
> > build, to run, or both.
> 
> You should be able to pick what you build/run/both against, and there
> should be some default (== no stream enabled by default seems to be the
> sanest default to me).

And you do that by wrapping your content in a module and declaring
your deps.

We still want to enable streams by default as we believe it
contributes to better user experience -- users don't have to look
for packages in modules and enable them manually.  Still, if you
depend on modular content, you should say so.  They only have to
care if they want to consume alternative content.

> > I don't think this is all that different from normal package
> > builds where you simply declare your RPM-level deps rather than
> > hope that something is magically pulled into the buildroot or
> > already installed on the system.
> 
> Well, this comes from my misunderstanding how the modularity is used
> probably...  E.g. there are attempts to move e.g. java stack to modular
> content - only because the MBS allows building against all fedora release
> by one command (== to avoid fedora branching "burden").  Even though this
> use-case is probably a misuse - to explain why I'm asking - I'd still
> expect that the java modular content is somehow available in buildroots
> by default configured in mock.

We would like that to be the case but for that we need to resolve
the FESCo ticket I linked earlier.  If Java goes module-only right
now, it will not be available to non-modular packages.  Hence why
some people are taking over the non-modular variants of those
packages for the time being.

P

> 
> Pavel
> 
> > > > In that case your local MBS manages the build and pulls the relevant
> > > > packages for you.
> > > 
> > > Ok, but consider that
> > > 
> > >   $ mock -r fedora-rawhide-x86_64 \
> > >   
> > > --config-opts module_enable=postgresql:10
> > > --rebuild my.srpm
> > > 
> > > is much more convenient and economical than approaching the whole MBS
> > > "thingy".
> > 
> > This is 

Re: modular repositories in mock configs: please don't

[Fabio Valentini]

On Mon, Mar 4, 2019, 11:12 Pavel Raiskup  wrote:

> On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
> > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > > > Replying in general.
> > > >
> > > > While it's never been entirely the same, I'd also like our mock
> configs
> > > > to be as close to koji environment as possible.  In the current
> > > > situation that would mean no modules being available.
> > >
> > > I don't understand your point of view.  If it is safe to enable modular
> > > repositories on user boxes by default (that's what we have now), why we
> > > can not enable them in koji and why we can not enable them in mock?
> >
> > We're currently discussing how to enable them in koji.  It's just not
> > the case at the moment.  Also the module set available and enabled in
> > koji might differ from the repo we ship.
>
> So the thing is to fix koji, not to fix mock - but you suggested to remove
> modular repos from mock config, iirc so why?  So if there's actually a
> reason to do so, shouldn't we removed it from
> /etc/yum.repos.d/fedora-modular.repo as well?
>

I asked for the modular repos to be disabled for mock because they were
causing new build failures - due to failed dependency resolution in modules.

Looking at the other thread (the "please test the 29 -> 30 upgrade with
modules), I'd say that the issue is also present there, and modular repos
shouldn't have been enabled by default for fedora 29 users, either.

Fabio


> > > > Once/if we proceed with one of the
> modules-in-the-non-modular-buildroot
> > > > proposals, I would like them to include the same module set that is
> > > > available in the non-modular buildroot in koji.
> > >
> > > Can you elaborate?  How the 'non-modular buildroot in koji' differs
> from
> > > modules-in-the-non-modular-buildroot?
> >
> > https://pagure.io/fesco/issue/2003
> >
> > The standard buildroot doesn't currently include any modular
> > content.  There are ways to put it in but we haven't decided how
> > to do it yet.
> >
> > Non-modular buildroot is the base buildroot that non-modular
> > packages use to build.  It may or may not include modules.  It
> > currently doesn't but we would like to change that.
> >
> > Once it does, I would like the mock config to include modules that
> > the koji buildroot includes.  Currently it doesn't include any so
> > I'd rather not include any.
>
> Ah, so we consider "modular" content to be a standard, and non-modular to
> be non-standard.  I understood it vice versa before TBH.
>
> > > > If you're building content that depends on modular packages at this
> > > > point, you should be building a module anyway.
> > >
> > > Please elaborate on "why" on this, too.
> >
> > Since the buildroot normally doesn't include modules (see above)
> > and there might be multiple incompatible streams anyway, you
> > should build your content as a module and define proper
> > module-level dependencies on the content you need -- either to
> > build, to run, or both.
>
> You should be able to pick what you build/run/both against, and there
> should be some default (== no stream enabled by default seems to be the
> sanest default to me).
>
> > I don't think this is all that different from normal package
> > builds where you simply declare your RPM-level deps rather than
> > hope that something is magically pulled into the buildroot or
> > already installed on the system.
>
> Well, this comes from my misunderstanding how the modularity is used
> probably...  E.g. there are attempts to move e.g. java stack to modular
> content - only because the MBS allows building against all fedora release
> by one command (== to avoid fedora branching "burden").  Even though this
> use-case is probably a misuse - to explain why I'm asking - I'd still
> expect that the java modular content is somehow available in buildroots
> by default configured in mock.
>
> Pavel
>
> > > > In that case your local MBS manages the build and pulls the relevant
> > > > packages for you.
> > >
> > > Ok, but consider that
> > >
> > >   $ mock -r fedora-rawhide-x86_64 \
> > >
> > > --config-opts module_enable=postgresql:10
> > > --rebuild my.srpm
> > >
> > > is much more convenient and economical than approaching the whole MBS
> > > "thingy".
> >
> > This is actually pretty cool.
> >
> > P
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 

Re: modular repositories in mock configs: please don't

[Pavel Raiskup]

On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote:
> On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > > Replying in general.
> > > 
> > > While it's never been entirely the same, I'd also like our mock configs
> > > to be as close to koji environment as possible.  In the current
> > > situation that would mean no modules being available.
> > 
> > I don't understand your point of view.  If it is safe to enable modular
> > repositories on user boxes by default (that's what we have now), why we
> > can not enable them in koji and why we can not enable them in mock?
> 
> We're currently discussing how to enable them in koji.  It's just not
> the case at the moment.  Also the module set available and enabled in
> koji might differ from the repo we ship.

So the thing is to fix koji, not to fix mock - but you suggested to remove
modular repos from mock config, iirc so why?  So if there's actually a
reason to do so, shouldn't we removed it from
/etc/yum.repos.d/fedora-modular.repo as well?

> > > Once/if we proceed with one of the modules-in-the-non-modular-buildroot
> > > proposals, I would like them to include the same module set that is
> > > available in the non-modular buildroot in koji.
> > 
> > Can you elaborate?  How the 'non-modular buildroot in koji' differs from
> > modules-in-the-non-modular-buildroot?
> 
> https://pagure.io/fesco/issue/2003
> 
> The standard buildroot doesn't currently include any modular
> content.  There are ways to put it in but we haven't decided how
> to do it yet.
> 
> Non-modular buildroot is the base buildroot that non-modular
> packages use to build.  It may or may not include modules.  It
> currently doesn't but we would like to change that.
> 
> Once it does, I would like the mock config to include modules that
> the koji buildroot includes.  Currently it doesn't include any so
> I'd rather not include any.

Ah, so we consider "modular" content to be a standard, and non-modular to
be non-standard.  I understood it vice versa before TBH.

> > > If you're building content that depends on modular packages at this
> > > point, you should be building a module anyway.
> > 
> > Please elaborate on "why" on this, too.
> 
> Since the buildroot normally doesn't include modules (see above)
> and there might be multiple incompatible streams anyway, you
> should build your content as a module and define proper
> module-level dependencies on the content you need -- either to
> build, to run, or both.

You should be able to pick what you build/run/both against, and there
should be some default (== no stream enabled by default seems to be the
sanest default to me).

> I don't think this is all that different from normal package
> builds where you simply declare your RPM-level deps rather than
> hope that something is magically pulled into the buildroot or
> already installed on the system.

Well, this comes from my misunderstanding how the modularity is used
probably...  E.g. there are attempts to move e.g. java stack to modular
content - only because the MBS allows building against all fedora release
by one command (== to avoid fedora branching "burden").  Even though this
use-case is probably a misuse - to explain why I'm asking - I'd still
expect that the java modular content is somehow available in buildroots
by default configured in mock.

Pavel

> > > In that case your local MBS manages the build and pulls the relevant
> > > packages for you.
> > 
> > Ok, but consider that
> > 
> >   $ mock -r fedora-rawhide-x86_64 \
> >   
> > --config-opts module_enable=postgresql:10
> > --rebuild my.srpm
> > 
> > is much more convenient and economical than approaching the whole MBS
> > "thingy".
> 
> This is actually pretty cool.
> 
> P



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Petr Šabata]

On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote:
> On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> > Replying in general.
> > 
> > While it's never been entirely the same, I'd also like our mock configs
> > to be as close to koji environment as possible.  In the current
> > situation that would mean no modules being available.
> 
> I don't understand your point of view.  If it is safe to enable modular
> repositories on user boxes by default (that's what we have now), why we
> can not enable them in koji and why we can not enable them in mock?

We're currently discussing how to enable them in koji.  It's just
not the case at the moment.  Also the module set available and
enabled in koji might differ from the repo we ship.

When I build in mock, I typically do it to test my changes before
sending a build to koji; I would therefore like the environment to
be nearly identical.  But I'd like to learn about other use cases,
too.

> > Once/if we proceed with one of the modules-in-the-non-modular-buildroot
> > proposals, I would like them to include the same module set that is
> > available in the non-modular buildroot in koji.
> 
> Can you elaborate?  How the 'non-modular buildroot in koji' differs from
> modules-in-the-non-modular-buildroot?

https://pagure.io/fesco/issue/2003

The standard buildroot doesn't currently include any modular
content.  There are ways to put it in but we haven't decided how
to do it yet.

Non-modular buildroot is the base buildroot that non-modular
packages use to build.  It may or may not include modules.  It
currently doesn't but we would like to change that.

Once it does, I would like the mock config to include modules that
the koji buildroot includes.  Currently it doesn't include any so
I'd rather not include any.

> > If you're building content that depends on modular packages at this
> > point, you should be building a module anyway.
> 
> Please elaborate on "why" on this, too.

Since the buildroot normally doesn't include modules (see above)
and there might be multiple incompatible streams anyway, you
should build your content as a module and define proper
module-level dependencies on the content you need -- either to
build, to run, or both.

I don't think this is all that different from normal package
builds where you simply declare your RPM-level deps rather than
hope that something is magically pulled into the buildroot or
already installed on the system.

> > In that case your local MBS manages the build and pulls the relevant
> > packages for you.
> 
> Ok, but consider that
> 
>   $ mock -r fedora-rawhide-x86_64 \
> --config-opts module_enable=postgresql:10
> --rebuild my.srpm
> 
> is much more convenient and economical than approaching the whole MBS
> "thingy".

This is actually pretty cool.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Pavel Raiskup]

On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote:
> Replying in general.
> 
> While it's never been entirely the same, I'd also like our mock configs
> to be as close to koji environment as possible.  In the current
> situation that would mean no modules being available.

I don't understand your point of view.  If it is safe to enable modular
repositories on user boxes by default (that's what we have now), why we
can not enable them in koji and why we can not enable them in mock?

> Once/if we proceed with one of the modules-in-the-non-modular-buildroot
> proposals, I would like them to include the same module set that is
> available in the non-modular buildroot in koji.

Can you elaborate?  How the 'non-modular buildroot in koji' differs from
modules-in-the-non-modular-buildroot?

> If you're building content that depends on modular packages at this
> point, you should be building a module anyway.

Please elaborate on "why" on this, too.

> In that case your local MBS manages the build and pulls the relevant
> packages for you.

Ok, but consider that

  $ mock -r fedora-rawhide-x86_64 \
--config-opts module_enable=postgresql:10
--rebuild my.srpm

is much more convenient and economical than approaching the whole MBS
"thingy".

Pavel

> But I also kinda like the idea of having two configs -- one that
> aims to somewhat replicate the koji experience and one that's
> close to installations.  Not sure if there's really any value in
> it, though.
> 
> P


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Petr Šabata]

On Fri, Mar 01, 2019 at 08:25:32AM -0600, Richard Shaw wrote:
> Not replying to anyone in particular but just a nit for me...
> 
> I've been a Fedora packager for probably 10 years now (need to check!) but
> I *STILL* don't really understand modules other than at a high level (it
> lets you use dependencies that aren't available in the main repos). I've
> read through some of the documentation but it's still not clear. I know I
> would have to crate some kind of module file which I think tools could be
> developed to mostly automate (spec->module template converter?).

You can view them as virtual repositories with dependencies.  I
think that might be the simplest way to put it.

You can try playing with fedmod to generate your modulemd file or
you can just write it from scratch; it's not all that complicated.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Petr Šabata]

Replying in general.

While it's never been entirely the same, I'd also like our mock
configs to be as close to koji environment as possible.  In the
current situation that would mean no modules being available.

Once/if we proceed with one of the
modules-in-the-non-modular-buildroot proposals, I would like them
to include the same module set that is available in the
non-modular buildroot in koji.

If you're building content that depends on modular packages at
this point, you should be building a module anyway.  In that case
your local MBS manages the build and pulls the relevant packages
for you.

But I also kinda like the idea of having two configs -- one that
aims to somewhat replicate the koji experience and one that's
close to installations.  Not sure if there's really any value in
it, though.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Richard Shaw]

Not replying to anyone in particular but just a nit for me...

I've been a Fedora packager for probably 10 years now (need to check!) but
I *STILL* don't really understand modules other than at a high level (it
lets you use dependencies that aren't available in the main repos). I've
read through some of the documentation but it's still not clear. I know I
would have to crate some kind of module file which I think tools could be
developed to mostly automate (spec->module template converter?).

While modularity is more of a Fedora thing I think it's sad that for more
standard tools I reference Arch documentation more often than Fedora
documentation. Of course there's the, "I could help with that" part and I
might, but frankly I can barely keep up with my packages between $DAYJOB,
$FAMILY, Fedora, and RPM Fusion.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Pavel Raiskup]

On Friday, March 1, 2019 9:56:48 AM CET Mikolaj Izdebski wrote:
> Koji doesn't use upstream mock configs. For each task it generates a
> new config dynamically. These generated configs don't include any
> modular repos.

Looks like a serious bug in Koji -> if modular repos are enabled by
default in Fedora, Koji, Copr (and mock) should it do as well, no?

Or the other way around - if enabling modules causes _any_ problems
anywhere, it should be disabled by default (and let people opt-in, in
mock, copr, koji, and plain fedora).

The status quo - inconsistency - is really bad for Fedora.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Fabio Valentini]

On Fri, Mar 1, 2019 at 11:39 AM Miroslav Suchý  wrote:
>
> Dne 01. 03. 19 v 10:28 Fabio Valentini napsal(a):
> > Either way, I'm just strongly opposed to enable modular repos in mock
> > by default (yet).
>
> *nod*
> With the all issues it brought, it is pragmatic move to remove the modular 
> repo. In fact, I will just set enabled=0.
>
> Done:
> https://github.com/rpm-software-management/mock/commit/65d87447c44e0a4ae628306b701b9d805fed0b24
> Expect Bodhi update in a few hours.

Thank you, Miroslav! I think this is a good solution for now.
With these changes, people who *explicitly want* modular repos enabled
can then just invoke mock with "--enablerepo=fedora-modular" as
needed, right?

Fabio

> However, everyone should be aware that Mock can deliver different results 
> than pure `rpmbuild` on the same platform.
>
> And I strongly encourage the Modularity team to resolve this ASAP.
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Mikolaj Izdebski]

On Fri, Mar 1, 2019 at 11:31 AM Fabio Valentini  wrote:
>
> On Fri, Mar 1, 2019 at 11:28 AM Mikolaj Izdebski  wrote:
> >
> > On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini  
> > wrote:
> > > I agree, this change to mock-core-configs seems to have been rushed
> > > and uncoordinated, since it's not possible to use modules in koji at
> > > all.
> >
> > It is possible to use modules in Koji. But Fedora Koji is not
> > configured to use modules.
>
> Thanks, that's what I meant to say. Of course koji can produce modules.
> It's just that "normal" builds can't consume modules (yet?).
> Guess I pressed "Send" too quickly.

"Normal" builds in Koji *can* already depend on modules. Modules can
be enabled in Koji buildroots using "module_enable" mock config
option. But Fedora Koji is not configured that way.

"Normal" builds in Koji can also depend on modular packages from
non-modular repositories. This can be configured by adding YUM
repositories without modlar metadata to Koji tags. Ursa-Major uses
this approach, but it can be configured without Ursa-Major too.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miroslav Suchý]

Dne 01. 03. 19 v 10:28 Fabio Valentini napsal(a):
> Either way, I'm just strongly opposed to enable modular repos in mock
> by default (yet).

*nod*
With the all issues it brought, it is pragmatic move to remove the modular 
repo. In fact, I will just set enabled=0.

Done:
https://github.com/rpm-software-management/mock/commit/65d87447c44e0a4ae628306b701b9d805fed0b24
Expect Bodhi update in a few hours.


However, everyone should be aware that Mock can deliver different results than 
pure `rpmbuild` on the same platform.

And I strongly encourage the Modularity team to resolve this ASAP.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Fabio Valentini]

On Fri, Mar 1, 2019 at 11:28 AM Mikolaj Izdebski  wrote:
>
> On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini  wrote:
> > I agree, this change to mock-core-configs seems to have been rushed
> > and uncoordinated, since it's not possible to use modules in koji at
> > all.
>
> It is possible to use modules in Koji. But Fedora Koji is not
> configured to use modules.

Thanks, that's what I meant to say. Of course koji can produce modules.
It's just that "normal" builds can't consume modules (yet?).
Guess I pressed "Send" too quickly.

Fabio

> --
> Mikolaj Izdebski
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Mikolaj Izdebski]

On Fri, Mar 1, 2019 at 10:29 AM Fabio Valentini  wrote:
> I agree, this change to mock-core-configs seems to have been rushed
> and uncoordinated, since it's not possible to use modules in koji at
> all.

It is possible to use modules in Koji. But Fedora Koji is not
configured to use modules.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Fabio Valentini]

On Fri, Mar 1, 2019 at 9:58 AM Adam Samalik  wrote:
>
> I'm glad Modularity is getting popular, however, we should coordinate such 
> big changes so we keep consistency among various build environments.

I'd call it "notorious" or "infamous" instead of "popular", but that's
just a difference perspective ;)

> The ability to enable modules in a Koji buildroot is being discussed in a 
> FESCo ticket [1] — although that discussion is a bit longer than initially 
> anticipated. But when that's done, we'll be finally able to move content from 
> traditional packages to default modules when desired. And that'll be the best 
> time to enable the modular repo in Mock so it behaves consistently with Koji.

I agree, this change to mock-core-configs seems to have been rushed
and uncoordinated, since it's not possible to use modules in koji at
all.

Can we find some middle ground here? Maybe two different configs (e.g.
fedora-29-x86_64 and fedora-29-modular-x86_64), where the first one
preserves the expected behaviour, and the new one enables modular
repositories for the people who want to test this out?

Either way, I'm just strongly opposed to enable modular repos in mock
by default (yet).
(Maybe I should have added a (yet) to the subject to this e-mail, as well.)

Fabio

> [1] https://pagure.io/fesco/issue/2003
>
> On Fri, Mar 1, 2019 at 9:49 AM Dan Horák  wrote:
>>
>> On Fri, 1 Mar 2019 08:59:35 +0100
>> Miroslav Suchý  wrote:
>>
>> > Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
>> > > On 01. 03. 19 0:05, Fabio Valentini wrote:
>> > >> I don't want or need modules installed for this package to build.
>> >
>> > It may be true if your specific case. But generally this is not true.
>> > AFAIK Some packages are not available in normal repo any more and are
>> > available only in modules. E.g., stratis* packages. The general
>> > expectaion is that more and more packages will move to modules.
>> >
>> > >> Any insights why this was done?
>> >
>> > Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of
>> > Fedora/CentOS. So running
>> >
>> >   mock -r fedora-29-x86_64 foo.src
>> >
>> > should give you the same results as running `rpmbuild --rebuild
>> > foo.src` on normal installation of fedora-29 with only minimal
>> > installation. And /etc/yum.repos.d/fedora-modular.repo *is* part of
>> > Fedora 29+. Therefore it is in mock configs. If you do not need it
>> > appeal either:
>> >  * maintainer of fedora-repos package
>> >  * modularity team
>> >  * FESCO representatives
>> >
>> > > Mock should IMHO bring the exact same (or at least the most
>> > > similar) results as building in koji. I don't want to get different
>> > > packages in mock and Koji just because the configurations are
>> > > different.
>> > >
>> > > Let's make the defaults the sme as Koji (currently, that means no
>> > > modular repos).
>> >
>> > Nope, it is the other way round. Koji use Mock and therefore Koji
>> > builds should be the same as your local builds with local mock.
>> > Only Koji admins do not jump on every released version and should
>> > (and I hope they do) test every new released version if it does not
>> > break Koji builds.
>>
>> koji provides own mock configs for the builds pointing to the internal
>> repos, it doesn't use the configs distributed with mock at all
>>
>>
>> Dan
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
>
> Adam Šamalík
> ---
> Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miro Hrončok]

On 01. 03. 19 9:58, Adam Samalik wrote:
I'm glad Modularity is getting popular, however, we should coordinate such big 
changes so we keep consistency among various build environments.


Agreed.

The ability to enable modules in a Koji buildroot is being discussed in a FESCo 
ticket [1] — although that discussion is a bit longer than initially 
anticipated. But when that's done, we'll be finally able to move content from 
traditional packages to default modules when desired. And that'll be the best 
time to enable the modular repo in Mock so it behaves consistently with Koji.


I'm quite concerned with this approach. It feels like modularity is breaking 
stuff and asking for solutions once they are broken. Why don't we do it the 
other way around?



[1] https://pagure.io/fesco/issue/2003



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miro Hrončok]

On 01. 03. 19 8:59, Miroslav Suchý wrote:

Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of 
Fedora/CentOS. So running

   mock -r fedora-29-x86_64 foo.src

should give you the same results as running `rpmbuild --rebuild foo.src` on 
normal installation of fedora-29 with only
minimal installation.
And /etc/yum.repos.d/fedora-modular.repo *is* part of Fedora 29+. Therefore it 
is in mock configs. If you do not need it
appeal either:
  * maintainer of fedora-repos package
  * modularity team
  * FESCO representatives


Done https://pagure.io/fesco/issue/2003#comment-557358


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Adam Samalik]

I'm glad Modularity is getting popular, however, we should coordinate such
big changes so we keep consistency among various build environments.

The ability to enable modules in a Koji buildroot is being discussed in a
FESCo ticket [1] — although that discussion is a bit longer than initially
anticipated. But when that's done, we'll be finally able to move content
from traditional packages to default modules when desired. And that'll be
the best time to enable the modular repo in Mock so it behaves consistently
with Koji.

[1] https://pagure.io/fesco/issue/2003

On Fri, Mar 1, 2019 at 9:49 AM Dan Horák  wrote:

> On Fri, 1 Mar 2019 08:59:35 +0100
> Miroslav Suchý  wrote:
>
> > Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> > > On 01. 03. 19 0:05, Fabio Valentini wrote:
> > >> I don't want or need modules installed for this package to build.
> >
> > It may be true if your specific case. But generally this is not true.
> > AFAIK Some packages are not available in normal repo any more and are
> > available only in modules. E.g., stratis* packages. The general
> > expectaion is that more and more packages will move to modules.
> >
> > >> Any insights why this was done?
> >
> > Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of
> > Fedora/CentOS. So running
> >
> >   mock -r fedora-29-x86_64 foo.src
> >
> > should give you the same results as running `rpmbuild --rebuild
> > foo.src` on normal installation of fedora-29 with only minimal
> > installation. And /etc/yum.repos.d/fedora-modular.repo *is* part of
> > Fedora 29+. Therefore it is in mock configs. If you do not need it
> > appeal either:
> >  * maintainer of fedora-repos package
> >  * modularity team
> >  * FESCO representatives
> >
> > > Mock should IMHO bring the exact same (or at least the most
> > > similar) results as building in koji. I don't want to get different
> > > packages in mock and Koji just because the configurations are
> > > different.
> > >
> > > Let's make the defaults the sme as Koji (currently, that means no
> > > modular repos).
> >
> > Nope, it is the other way round. Koji use Mock and therefore Koji
> > builds should be the same as your local builds with local mock.
> > Only Koji admins do not jump on every released version and should
> > (and I hope they do) test every new released version if it does not
> > break Koji builds.
>
> koji provides own mock configs for the builds pointing to the internal
> repos, it doesn't use the configs distributed with mock at all
>
>
> Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Mikolaj Izdebski]

On Fri, Mar 1, 2019 at 9:00 AM Miroslav Suchý  wrote:
>
> Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> > On 01. 03. 19 0:05, Fabio Valentini wrote:
> > Mock should IMHO bring the exact same (or at least the most similar) 
> > results as building in koji. I don't want to get
> > different packages in mock and Koji just because the configurations are 
> > different.
> >
> > Let's make the defaults the sme as Koji (currently, that means no modular 
> > repos).
>
> Nope, it is the other way round. Koji use Mock and therefore Koji builds 
> should be the same as your local builds with
> local mock.
> Only Koji admins do not jump on every released version and should (and I hope 
> they do) test every new released version
> if it does not break Koji builds.

Koji doesn't use upstream mock configs. For each task it generates a
new config dynamically. These generated configs don't include any
modular repos.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Dan Horák]

On Fri, 1 Mar 2019 08:59:35 +0100
Miroslav Suchý  wrote:

> Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> > On 01. 03. 19 0:05, Fabio Valentini wrote:
> >> I don't want or need modules installed for this package to build.
> 
> It may be true if your specific case. But generally this is not true.
> AFAIK Some packages are not available in normal repo any more and are
> available only in modules. E.g., stratis* packages. The general
> expectaion is that more and more packages will move to modules.
> 
> >> Any insights why this was done?
> 
> Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of
> Fedora/CentOS. So running
> 
>   mock -r fedora-29-x86_64 foo.src
> 
> should give you the same results as running `rpmbuild --rebuild
> foo.src` on normal installation of fedora-29 with only minimal
> installation. And /etc/yum.repos.d/fedora-modular.repo *is* part of
> Fedora 29+. Therefore it is in mock configs. If you do not need it
> appeal either:
>  * maintainer of fedora-repos package
>  * modularity team
>  * FESCO representatives
> 
> > Mock should IMHO bring the exact same (or at least the most
> > similar) results as building in koji. I don't want to get different
> > packages in mock and Koji just because the configurations are
> > different.
> > 
> > Let's make the defaults the sme as Koji (currently, that means no
> > modular repos).
> 
> Nope, it is the other way round. Koji use Mock and therefore Koji
> builds should be the same as your local builds with local mock.
> Only Koji admins do not jump on every released version and should
> (and I hope they do) test every new released version if it does not
> break Koji builds.

koji provides own mock configs for the builds pointing to the internal
repos, it doesn't use the configs distributed with mock at all


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miroslav Suchý]

Dne 01. 03. 19 v 0:22 Miro Hrončok napsal(a):
> On 01. 03. 19 0:05, Fabio Valentini wrote:
>> I don't want or need modules installed for this package to build.

It may be true if your specific case. But generally this is not true. AFAIK 
Some packages are not available in normal
repo any more and are available only in modules. E.g., stratis* packages.
The general expectaion is that more and more packages will move to modules.

>> Any insights why this was done?

Mock is in fact just easy tool to run 'rpmbuild' in minimal chroot of 
Fedora/CentOS. So running

  mock -r fedora-29-x86_64 foo.src

should give you the same results as running `rpmbuild --rebuild foo.src` on 
normal installation of fedora-29 with only
minimal installation.
And /etc/yum.repos.d/fedora-modular.repo *is* part of Fedora 29+. Therefore it 
is in mock configs. If you do not need it
appeal either:
 * maintainer of fedora-repos package
 * modularity team
 * FESCO representatives

> Mock should IMHO bring the exact same (or at least the most similar) results 
> as building in koji. I don't want to get
> different packages in mock and Koji just because the configurations are 
> different.
> 
> Let's make the defaults the sme as Koji (currently, that means no modular 
> repos).

Nope, it is the other way round. Koji use Mock and therefore Koji builds should 
be the same as your local builds with
local mock.
Only Koji admins do not jump on every released version and should (and I hope 
they do) test every new released version
if it does not break Koji builds.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[YOUNG, MICHAEL A.]

On Thu, 28 Feb 2019, Miro Hrončok wrote:

> On 01. 03. 19 0:05, Fabio Valentini wrote:
>>  Hi everybody,
>>
>>  Recently, modular repositories were enabled in the mock configs for fedora
>>  29+.
>>
>>  Now, I can't build at least one of my packages (elementary-music) in
>>  fedora 29 chroots, due to dependency issues within modules. dnf just
>>  gives up with this rather unhelpful message:
>>
>>Problem: cannot install the best candidate for the job
>> - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is
>> excluded
>>
>>  I don't want or need modules installed for this package to build.
>>
>>  See:
>>  
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-901551
>>
>>  IMO it was a mistake to enable modular repositories in mock configs by
>>  default. Now dnf only downloads even more metadata for no benefit (or,
>>  it even breaks dependency resolution, as in this case).
>>
>>  Do I really have to manually edit mock's config files to disable
>>  modular repos, to get builds equivalent to koji (where modules aren't
>>  available / usable either)? I want to test builds locally, before I
>>  push them to koji builders ...
>>
>>  Any insights why this was done?
>>
>>  Can it be fixed please?
>>
>>  Or am I the only one having problems?
>
> No you are not. Rawhide mock is broken for the very same reason.

As is RHEL8 public beta 1. I think this is actually the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1673851
with 2 related rhel8 bugs
https://bugzilla.redhat.com/show_bug.cgi?id=1677583
https://bugzilla.redhat.com/show_bug.cgi?id=1678911

in which case you can probably work around it by setting best=0 in the 
relevant file in /etc/mock (or you could take a copy of the file and 
edit that, then select the edited copy with the -r option of mock).

Michael Young
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Miro Hrončok]

On 01. 03. 19 0:05, Fabio Valentini wrote:

Hi everybody,

Recently, modular repositories were enabled in the mock configs for fedora 29+.

Now, I can't build at least one of my packages (elementary-music) in
fedora 29 chroots, due to dependency issues within modules. dnf just
gives up with this rather unhelpful message:

  Problem: cannot install the best candidate for the job
   - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded

I don't want or need modules installed for this package to build.

See: 
https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-901551

IMO it was a mistake to enable modular repositories in mock configs by
default. Now dnf only downloads even more metadata for no benefit (or,
it even breaks dependency resolution, as in this case).

Do I really have to manually edit mock's config files to disable
modular repos, to get builds equivalent to koji (where modules aren't
available / usable either)? I want to test builds locally, before I
push them to koji builders ...

Any insights why this was done?

Can it be fixed please?

Or am I the only one having problems?


No you are not. Rawhide mock is broken for the very same reason.

Mock should IMHO bring the exact same (or at least the most similar) results as 
building in koji. I don't want to get different packages in mock and Koji just 
because the configurations are different.


Let's make the defaults the sme as Koji (currently, that means no modular 
repos).

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org