Usefulness of `copr mock-config <PROJECT> <CHROOT>` feature?

[Pavel Raiskup]

Because we are unable to find a consensus on implementation details, it's
likely we'll drop this feature from copr API and it will be probably a bit
more complicated to setup mock chroot for local tests in future (you'll
need to have builder machine with copr-rpmbuild installed, which brings a
lot more runtime dependencies at least).

From user perspective, do you mind if we dropped `copr mock-config` command?

Pavel

[Pavel Raiskup]

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>  Because we are unable to find a consensus on implementation details,
> it's
>  likely we'll drop this feature from copr API and it will be probably a bit
>  more complicated to setup mock chroot for local tests in future (you'll
>  need to have builder machine with copr-rpmbuild installed, which brings a
>  lot more runtime dependencies at least).
>  
>  From user perspective, do you mind if we dropped `copr mock-config` command?
>  
>  Pavel

[Michael Šimáček]

On 2018-02-13 11:47, Pavel Raiskup wrote:
>  Sorry, I wanted to CC fedora devel before, forwarding.
>  
>  Pavel
>  
>  On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> > Because we are unable to find a consensus on implementation details, it's
> > likely we'll drop this feature from copr API and it will be probably a bit
> > more complicated to setup mock chroot for local tests in future (you'll
> > need to have builder machine with copr-rpmbuild installed, which brings a
> > lot more runtime dependencies at least).
> >
> >  From user perspective, do you mind if we dropped `copr mock-config` command?
> > 
I didn't know this command existed, but there were multiple times in the 
past where I wished something like this had been available (It didn't 
exist back then). It was usually situation like this: "Hi, I'm trying to 
build $package in $copr and it fails because of $build_tool that you 
maintain, can you help me?". And since I had no idea how his copr was 
set up, it took me a lot of time before I was able to reproduce the 
problem. So, I would find the feature useful, especially in instances 
outside Fedora, which usually have more complex configurations.
If it had to be dropped, I'd appreciate if copr could display the 
configuration of given project for non-owners. That way it would be 
easier to construct my own config, without trying to guess stuff based 
on the logs.

Michael

[Michal Novotny]

Hello,

On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com&gt;
wrote:

>  On 2018-02-13 11:47, Pavel Raiskup wrote:
>
> > Sorry, I wanted to CC fedora devel before, forwarding.
> >
> > Pavel
> >
> > On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> >
> >> Because we are unable to find a consensus on implementation details, it's
> >> likely we'll drop this feature from copr API and it will be probably a
> >> bit
> >> more complicated to setup mock chroot for local tests in future (you'll
> >> need to have builder machine with copr-rpmbuild installed, which brings a
> >> lot more runtime dependencies at least).
> >>
> >>  From user perspective, do you mind if we dropped `copr mock-config`
> >> command?
> >>
> >>
>  I didn't know this command existed, but there were multiple times in the
>  past where I wished something like this had been available (It didn't exist
>  back then). It was usually situation like this: "Hi, I'm trying to build
>  $package in $copr and it fails because of $build_tool that you maintain,
>  can you help me?". And since I had no idea how his copr was set up, it took
>  me a lot of time before I was able to reproduce the problem. So, I would
>  find the feature useful, especially in instances outside Fedora, which
>  usually have more complex configurations.
>  If it had to be dropped, I'd appreciate if copr could display the
>  configuration of given project for non-owners. That way it would be easier
>  to construct my own config, without trying to guess stuff based on the logs.
>  
First, thanks for your input. This is very useful information for us. Next,
I would like to ask if it was ok to put all the functionality about
build-testing and building itself into just a single package:
copr-rpmbuild. I think having things on just one place can help us focus on
doing them really well and as the copr-rpmbuild tool is already responsible
for building, I think it would be a perfect place to add additional
build-debugging functionality like printing-out/dumping mock configs,
enablement to run just a part of the build process, possibility to enter
the build environment interactively etc. Would this be alright?

Thank you again for your feedback
Michal


>  Michael
>  _______________________________________________
>  copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org
>

[Michal Novotny]

On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <clime(a)redhat.com&gt; wrote:

>  Hello,
>
>  On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com&gt;
>  wrote:
>
> > On 2018-02-13 11:47, Pavel Raiskup wrote:
> >
> >> Sorry, I wanted to CC fedora devel before, forwarding.
> >>
> >> Pavel
> >>
> >> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> >>
> >>> Because we are unable to find a consensus on implementation details,
> >>> it's
> >>> likely we'll drop this feature from copr API and it will be probably a
> >>> bit
> >>> more complicated to setup mock chroot for local tests in future (you'll
> >>> need to have builder machine with copr-rpmbuild installed, which brings
> >>> a
> >>> lot more runtime dependencies at least).
> >>>
> >>>  From user perspective, do you mind if we dropped `copr mock-config`
> >>> command?
> >>>
> >>>
> > I didn't know this command existed, but there were multiple times in the
> > past where I wished something like this had been available (It didn't exist
> > back then). It was usually situation like this: "Hi, I'm trying to build
> > $package in $copr and it fails because of $build_tool that you maintain,
> > can you help me?". And since I had no idea how his copr was set up, it took
> > me a lot of time before I was able to reproduce the problem. So, I would
> > find the feature useful, especially in instances outside Fedora, which
> > usually have more complex configurations.
> > If it had to be dropped, I'd appreciate if copr could display the
> > configuration of given project for non-owners. That way it would be easier
> > to construct my own config, without trying to guess stuff based on the logs.
> >
>
>  First, thanks for your input. This is very useful information for us.
>  Next, I would like to ask if it was ok to put all the functionality about
>  build-testing and building itself into just a single package:
>  copr-rpmbuild. I think having things on just one place can help us focus on
>  doing them really well and as the copr-rpmbuild tool is already responsible
>  for building, I think it would be a perfect place to add additional
>  build-debugging functionality like printing-out/dumping mock configs,
>  enablement to run just a part of the build process, possibility to enter
>  the build environment interactively etc. Would this be alright?
>  
I need to add that with this tool you really need to know _what_ you are
building to be on the safe side. It is similar to running rpmbuild locally
(unless you are really just dumping mock configs).


>  Thank you again for your feedback
>  Michal
>
>
> >
> > Michael
> > _______________________________________________
> > copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
> > To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org
> >
>
>

Hi,

BTW, in my own very basic use of copr, I'm mostly annoyed with:
1. copr failing builds because of problems syncing repodata → not my problem as packager,
retry till you manage to sync repositories and package groups
2. copr sometimes starting the next build, before finishing syncing the results of the
previous one on all builders → again not my problem as packager, I want to see problems in
*my* packaging only

That basically means a mass rebuild can not fire and forget srpms to copr once they build
in local mock successfully, it needs to wait for each copr build to succeed and kick it
again and again every time copr fails for non-packaging-related reasons.

With some builds taking an hour or more that means adding days of waiting to a complete
coprified mass rebuild.

Regards,

-- 
Nicolas Mailhot

[Pavel Raiskup]

On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
>  On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny
> <clime(a)redhat.com&gt; wrote:
>  
>  > Hello,
>  >
>  > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com&gt;
>  > wrote:
>  >
>  >> On 2018-02-13 11:47, Pavel Raiskup wrote:
>  >>
>  >>> Sorry, I wanted to CC fedora devel before, forwarding.
>  >>>
>  >>> Pavel
>  >>>
>  >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>  >>>
>  >>>> Because we are unable to find a consensus on implementation details,
>  >>>> it's
>  >>>> likely we'll drop this feature from copr API and it will be probably
> a
>  >>>> bit
>  >>>> more complicated to setup mock chroot for local tests in future
> (you'll
>  >>>> need to have builder machine with copr-rpmbuild installed, which brings
>  >>>> a
>  >>>> lot more runtime dependencies at least).
>  >>>>
>  >>>>  From user perspective, do you mind if we dropped `copr mock-config`
>  >>>> command?
>  >>>>
>  >>>>
>  >> I didn't know this command existed, but there were multiple times in the
>  >> past where I wished something like this had been available (It didn't exist
>  >> back then). It was usually situation like this: "Hi, I'm trying to
> build
>  >> $package in $copr and it fails because of $build_tool that you maintain,
>  >> can you help me?". And since I had no idea how his copr was set up, it
> took
>  >> me a lot of time before I was able to reproduce the problem. So, I would
>  >> find the feature useful, especially in instances outside Fedora, which
>  >> usually have more complex configurations.
>  >> If it had to be dropped, I'd appreciate if copr could display the
>  >> configuration of given project for non-owners. That way it would be easier
>  >> to construct my own config, without trying to guess stuff based on the logs.
>  >>
>  >
>  > First, thanks for your input. This is very useful information for us.
>  > Next, I would like to ask if it was ok to put all the functionality about
>  > build-testing and building itself into just a single package:
>  > copr-rpmbuild. I think having things on just one place can help us focus on
>  > doing them really well and as the copr-rpmbuild tool is already responsible
>  > for building, I think it would be a perfect place to add additional
>  > build-debugging functionality like printing-out/dumping mock configs,
>  > enablement to run just a part of the build process, possibility to enter
>  > the build environment interactively etc. Would this be alright?
>  >
>  
>  I need to add that with this tool you really need to know _what_ you are
>  building to be on the safe side. It is similar to running rpmbuild locally
>  (unless you are really just dumping mock configs). 
I use 'copr mock-config' for working with buildroot, even if I don't want
to build anything (mock --shell).  So except from mock, any other deps
installed by copr-rpmbuild are useless and I don't want them on my box
basically.

Pavel

>  > Thank you again for your feedback
>  > Michal
>  >
>  >
>  >>
>  >> Michael
>  >> _______________________________________________
>  >> copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
>  >> To unsubscribe send an email to copr-devel-leave(a)lists.fedorahosted.org
>  >>
>  >
>  >

Hey Nicolas,

thank you for your notes, could you post it into a separate thread? I would like to react
to it there.

Thank you!
clime

[Michal Novotny]

Hello Pavel,

On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; wrote:

>  On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
>  > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <clime(a)redhat.com&gt;
>  wrote:
>  >
>  > > Hello,
>  > >
>  > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com
>  >
>  > > wrote:
>  > >
>  > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
>  > >>
>  > >>> Sorry, I wanted to CC fedora devel before, forwarding.
>  > >>>
>  > >>> Pavel
>  > >>>
>  > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>  > >>>
>  > >>>> Because we are unable to find a consensus on implementation
> details,
>  > >>>> it's
>  > >>>> likely we'll drop this feature from copr API and it will be
>  probably a
>  > >>>> bit
>  > >>>> more complicated to setup mock chroot for local tests in future
>  (you'll
>  > >>>> need to have builder machine with copr-rpmbuild installed, which
>  brings
>  > >>>> a
>  > >>>> lot more runtime dependencies at least).
>  > >>>>
>  > >>>>  From user perspective, do you mind if we dropped `copr
> mock-config`
>  > >>>> command?
>  > >>>>
>  > >>>>
>  > >> I didn't know this command existed, but there were multiple times in
>  the
>  > >> past where I wished something like this had been available (It didn't
>  exist
>  > >> back then). It was usually situation like this: "Hi, I'm trying
> to
>  build
>  > >> $package in $copr and it fails because of $build_tool that you
>  maintain,
>  > >> can you help me?". And since I had no idea how his copr was set up,
>  it took
>  > >> me a lot of time before I was able to reproduce the problem. So, I
>  would
>  > >> find the feature useful, especially in instances outside Fedora, which
>  > >> usually have more complex configurations.
>  > >> If it had to be dropped, I'd appreciate if copr could display the
>  > >> configuration of given project for non-owners. That way it would be
>  easier
>  > >> to construct my own config, without trying to guess stuff based on
>  the logs.
>  > >>
>  > >
>  > > First, thanks for your input. This is very useful information for us.
>  > > Next, I would like to ask if it was ok to put all the functionality
>  about
>  > > build-testing and building itself into just a single package:
>  > > copr-rpmbuild. I think having things on just one place can help us
>  focus on
>  > > doing them really well and as the copr-rpmbuild tool is already
>  responsible
>  > > for building, I think it would be a perfect place to add additional
>  > > build-debugging functionality like printing-out/dumping mock configs,
>  > > enablement to run just a part of the build process, possibility to
>  enter
>  > > the build environment interactively etc. Would this be alright?
>  > >
>  >
>  > I need to add that with this tool you really need to know _what_ you are
>  > building to be on the safe side. It is similar to running rpmbuild
>  locally
>  > (unless you are really just dumping mock configs).
>
>  I use 'copr mock-config' for working with buildroot, even if I don't want
>  to build anything (mock --shell).  So except from mock, any other deps
>  installed by copr-rpmbuild are useless and I don't want them on my box
>  basically.
>  
Alright, we can set some most prominent deps of copr-rpmbuild as weak deps.

It will be then possible to install the minimal package setup e.g. with:

# dnf -y install copr-rpmbuild --setopt=install_weak_deps=False

I opened https://pagure.io/copr/copr/issue/222.

Thanks!


>  Pavel
>
>  > > Thank you again for your feedback
>  > > Michal
>  > >
>  > >
>  > >>
>  > >> Michael
>  > >> _______________________________________________
>  > >> copr-devel mailing list -- copr-devel(a)lists.fedorahosted.org
>  > >> To unsubscribe send an email to copr-devel-leave@lists.
>  fedorahosted.org
>  > >>
>  > >
>  > >
>
>
>
>
>

[Pavel Raiskup]

On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny wrote:
>  Hello Pavel,
>  
>  On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; wrote:
>  
>  > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
>  > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <clime(a)redhat.com&gt;
>  > wrote:
>  > >
>  > > > Hello,
>  > > >
>  > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com
>  > >
>  > > > wrote:
>  > > >
>  > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
>  > > >>
>  > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
>  > > >>>
>  > > >>> Pavel
>  > > >>>
>  > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup
> wrote:
>  > > >>>
>  > > >>>> Because we are unable to find a consensus on implementation
> details,
>  > > >>>> it's
>  > > >>>> likely we'll drop this feature from copr API and it will
> be
>  > probably a
>  > > >>>> bit
>  > > >>>> more complicated to setup mock chroot for local tests in
> future
>  > (you'll
>  > > >>>> need to have builder machine with copr-rpmbuild installed,
> which
>  > brings
>  > > >>>> a
>  > > >>>> lot more runtime dependencies at least).
>  > > >>>>
>  > > >>>>  From user perspective, do you mind if we dropped `copr
> mock-config`
>  > > >>>> command?
>  > > >>>>
>  > > >>>>
>  > > >> I didn't know this command existed, but there were multiple times
> in
>  > the
>  > > >> past where I wished something like this had been available (It
> didn't
>  > exist
>  > > >> back then). It was usually situation like this: "Hi, I'm
> trying to
>  > build
>  > > >> $package in $copr and it fails because of $build_tool that you
>  > maintain,
>  > > >> can you help me?". And since I had no idea how his copr was set
> up,
>  > it took
>  > > >> me a lot of time before I was able to reproduce the problem. So, I
>  > would
>  > > >> find the feature useful, especially in instances outside Fedora,
> which
>  > > >> usually have more complex configurations.
>  > > >> If it had to be dropped, I'd appreciate if copr could display the
>  > > >> configuration of given project for non-owners. That way it would be
>  > easier
>  > > >> to construct my own config, without trying to guess stuff based on
>  > the logs.
>  > > >>
>  > > >
>  > > > First, thanks for your input. This is very useful information for us.
>  > > > Next, I would like to ask if it was ok to put all the functionality
>  > about
>  > > > build-testing and building itself into just a single package:
>  > > > copr-rpmbuild. I think having things on just one place can help us
>  > focus on
>  > > > doing them really well and as the copr-rpmbuild tool is already
>  > responsible
>  > > > for building, I think it would be a perfect place to add additional
>  > > > build-debugging functionality like printing-out/dumping mock configs,
>  > > > enablement to run just a part of the build process, possibility to
>  > enter
>  > > > the build environment interactively etc. Would this be alright?
>  > > >
>  > >
>  > > I need to add that with this tool you really need to know _what_ you are
>  > > building to be on the safe side. It is similar to running rpmbuild
>  > locally
>  > > (unless you are really just dumping mock configs).
>  >
>  > I use 'copr mock-config' for working with buildroot, even if I don't
> want
>  > to build anything (mock --shell).  So except from mock, any other deps
>  > installed by copr-rpmbuild are useless and I don't want them on my box
>  > basically.
>  >
>  
>  Alright, we can set some most prominent deps of copr-rpmbuild as weak deps.
>  
>  It will be then possible to install the minimal package setup e.g. with:
>  
>  # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
>  
>  I opened https://pagure.io/copr/copr/issue/222.
>  
>  Thanks! 
I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still can
install mock/copr-cli and I can experiment with copr bulidroot through `copr
mock-config` feature.  IOW, enforcing user to install another client tool
for generating mock config doesn't make sense.

Pavel

[Michal Novotny]

On Wed, Feb 14, 2018 at 11:16 AM, Pavel Raiskup <praiskup(a)redhat.com&gt; wrote:

>  On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny
> wrote:
>  > Hello Pavel,
>  >
>  > On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <praiskup(a)redhat.com&gt;
>  wrote:
>  >
>  > > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
>  > > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <clime(a)redhat.com&gt;
>  > > wrote:
>  > > >
>  > > > > Hello,
>  > > > >
>  > > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <
>  msimacek(a)redhat.com
>  > > >
>  > > > > wrote:
>  > > > >
>  > > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
>  > > > >>
>  > > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
>  > > > >>>
>  > > > >>> Pavel
>  > > > >>>
>  > > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup
>  wrote:
>  > > > >>>
>  > > > >>>> Because we are unable to find a consensus on
> implementation
>  details,
>  > > > >>>> it's
>  > > > >>>> likely we'll drop this feature from copr API and it
> will be
>  > > probably a
>  > > > >>>> bit
>  > > > >>>> more complicated to setup mock chroot for local tests in
> future
>  > > (you'll
>  > > > >>>> need to have builder machine with copr-rpmbuild
> installed, which
>  > > brings
>  > > > >>>> a
>  > > > >>>> lot more runtime dependencies at least).
>  > > > >>>>
>  > > > >>>>  From user perspective, do you mind if we dropped `copr
>  mock-config`
>  > > > >>>> command?
>  > > > >>>>
>  > > > >>>>
>  > > > >> I didn't know this command existed, but there were multiple
> times
>  in
>  > > the
>  > > > >> past where I wished something like this had been available (It
>  didn't
>  > > exist
>  > > > >> back then). It was usually situation like this: "Hi, I'm
> trying to
>  > > build
>  > > > >> $package in $copr and it fails because of $build_tool that you
>  > > maintain,
>  > > > >> can you help me?". And since I had no idea how his copr was
> set
>  up,
>  > > it took
>  > > > >> me a lot of time before I was able to reproduce the problem. So,
> I
>  > > would
>  > > > >> find the feature useful, especially in instances outside Fedora,
>  which
>  > > > >> usually have more complex configurations.
>  > > > >> If it had to be dropped, I'd appreciate if copr could display
> the
>  > > > >> configuration of given project for non-owners. That way it would
>  be
>  > > easier
>  > > > >> to construct my own config, without trying to guess stuff based
> on
>  > > the logs.
>  > > > >>
>  > > > >
>  > > > > First, thanks for your input. This is very useful information for
>  us.
>  > > > > Next, I would like to ask if it was ok to put all the functionality
>  > > about
>  > > > > build-testing and building itself into just a single package:
>  > > > > copr-rpmbuild. I think having things on just one place can help us
>  > > focus on
>  > > > > doing them really well and as the copr-rpmbuild tool is already
>  > > responsible
>  > > > > for building, I think it would be a perfect place to add additional
>  > > > > build-debugging functionality like printing-out/dumping mock
>  configs,
>  > > > > enablement to run just a part of the build process, possibility to
>  > > enter
>  > > > > the build environment interactively etc. Would this be alright?
>  > > > >
>  > > >
>  > > > I need to add that with this tool you really need to know _what_ you
>  are
>  > > > building to be on the safe side. It is similar to running rpmbuild
>  > > locally
>  > > > (unless you are really just dumping mock configs).
>  > >
>  > > I use 'copr mock-config' for working with buildroot, even if I
> don't
>  want
>  > > to build anything (mock --shell).  So except from mock, any other deps
>  > > installed by copr-rpmbuild are useless and I don't want them on my box
>  > > basically.
>  > >
>  >
>  > Alright, we can set some most prominent deps of copr-rpmbuild as weak
>  deps.
>  >
>  > It will be then possible to install the minimal package setup e.g. with:
>  >
>  > # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
>  >
>  > I opened https://pagure.io/copr/copr/issue/222.
>  >
>  > Thanks!
>
>  I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still
>  can
>  install mock/copr-cli and I can experiment with copr bulidroot through
>  `copr
>  mock-config` feature.  IOW, enforcing user to install another client tool
>  for generating mock config doesn't make sense.
>  
Actually, I would like to make some deps as very weak deps ('Suggests' tag),
so that they are not installed by default.

I am not sure what's the status of yum in EPEL7 but I think it would be very
nice if this functionality was backported there. If not, I will need to add
separate
Require tags for rhel. But thanks for that note!


>  Pavel
>
>
>
>

[Michael Šimáček]

On 2018-02-13 21:51, Michal Novotny wrote:
>  Hello,
>  
>  On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On 2018-02-13 11:47, Pavel Raiskup wrote:
>  
>          Sorry, I wanted to CC fedora devel before, forwarding.
>  
>          Pavel
>  
>          On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>  
>              Because we are unable to find a consensus on implementation
>              details, it's
>              likely we'll drop this feature from copr API and it will be
>              probably a bit
>              more complicated to setup mock chroot for local tests in
>              future (you'll
>              need to have builder machine with copr-rpmbuild installed,
>              which brings a
>              lot more runtime dependencies at least).
>  
>                From user perspective, do you mind if we dropped `copr
>              mock-config` command?
>  
>  
>      I didn't know this command existed, but there were multiple times in
>      the past where I wished something like this had been available (It
>      didn't exist back then). It was usually situation like this: "Hi,
>      I'm trying to build $package in $copr and it fails because of
>      $build_tool that you maintain, can you help me?". And since I had no
>      idea how his copr was set up, it took me a lot of time before I was
>      able to reproduce the problem. So, I would find the feature useful,
>      especially in instances outside Fedora, which usually have more
>      complex configurations.
>      If it had to be dropped, I'd appreciate if copr could display the
>      configuration of given project for non-owners. That way it would be
>      easier to construct my own config, without trying to guess stuff
>      based on the logs.
>  
>  
>  First, thanks for your input. This is very useful information for us. 
>  Next, I would like to ask if it was ok to put all the functionality 
>  about build-testing and building itself into just a single package: 
>  copr-rpmbuild. I think having things on just one place can help us focus 
>  on doing them really well and as the copr-rpmbuild tool is already 
>  responsible for building, I think it would be a perfect place to add 
>  additional build-debugging functionality like printing-out/dumping mock 
>  configs, enablement to run just a part of the build process, possibility 
>  to enter the build environment interactively etc. Would this be alright?
>   
Yes, that would work for me. I don't mind additional deps.

Thank you,
Michael