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
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
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
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček msimacek@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?
Thank you again for your feedback Michal
Michael _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny clime@redhat.com wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček msimacek@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).
Thank you again for your feedback Michal
Michael _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@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,
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
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@redhat.com wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček msimacek@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.
Pavel
Thank you again for your feedback Michal
Michael _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
Hello Pavel,
On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup praiskup@redhat.com 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@redhat.com
wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek@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@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.
fedorahosted.org
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@redhat.com 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@redhat.com
wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek@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
On Wed, Feb 14, 2018 at 11:16 AM, Pavel Raiskup praiskup@redhat.com 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@redhat.com
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@redhat.com
wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <
msimacek@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
On 2018-02-13 21:51, Michal Novotny wrote:
Hello,
On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msimacek@redhat.com mailto:msimacek@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?
Yes, that would work for me. I don't mind additional deps.
Thank you, Michael
copr-devel@lists.fedorahosted.org
-
clime＠redhat.com -
Michael Šimáček -
Michal Novotny
-
nicolas.mailhot＠laposte.net -
Pavel Raiskup