Le vendredi 03 juillet 2020 à 08:24 -0700, PGNet Dev a écrit :
>
>
> On 7/3/20 12:01 AM, Nicolas Mailhot wrote:
> > You added some processing that depends on the git command (that
> > forgemeta does not use) but forgot to BuildRequire the package
> > providing that command.
>
> It's _clearly_
On 7/3/20 2:07 PM, PGNet Dev wrote:
> from cmd line,
>
> copr-cli edit-chroot --packages git
>
> looks like it should work as well
and it does, nicely:
==> 14:26:43 Build 1517366: succeeded
___
devel mailing list --
On 7/3/20 8:24 AM, PGNet Dev wrote:
> git _was_ trivially added to the local mock chroot, for its use, with obvious
> success, in the local mock build of the spec.
>
> COPR uses mock.
>
> So far, I have not seen how that's to be similarly done for the COPR env.
>
> Is is possible to,
hi,
> ...
All the above^ is an interesting/informative read.
On 7/3/20 2:31 AM, Nicolas Mailhot via devel wrote:
> The requester is clearly attempting the second approach.
Well, not explicitly. I'm not requesting any _specific_ approach.
The goal is simply to 'build it here (locally, via
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit :
>
> I'd appreciate the link to spectool rewrite, though.
Here it is:
https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool
Regards,
--
Nicolas Mailhot
___
devel mailing list --
Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit :
> On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel
> wrote:
> > it will certainly be possible to compute a second level of sources
> > during the dynamic buildrequires first pass over prep, and the
> > change
> >
On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel wrote:
> it will certainly be possible to compute a second level of sources
> during the dynamic buildrequires first pass over prep, and the change
> makes the forge macro code modular enough the second level will be
>
On Friday, July 3, 2020 9:01:16 AM CEST Nicolas Mailhot wrote:
> Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit :
>
> Hi,
>
> As usual for those things the reason is dead stupid (so stupid the
> human brain refuses to see it)
>
> > submitting the _same_ spec to COPR for online build
Le jeudi 02 juillet 2020 à 18:00 -0700, PGNet Dev a écrit :
Hi,
As usual for those things the reason is dead stupid (so stupid the
human brain refuses to see it)
> submitting the _same_ spec to COPR for online build FAILS @,
> supposedly, similar Mock build
>
> Here's a diff
>
>
Le vendredi 03 juillet 2020 à 07:26 +0200, Pavel Raiskup a écrit :
Hi,
> I'm not familiar with the %forge* macros, but I don't think it is
> expected that you will add commands that need the Internet into the
> macro definition.
It’s neither expected nor unexpected. For a Fedora-oriented
On Friday, July 3, 2020 3:00:48 AM CEST PGNet Dev wrote:
> https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
There are things like:
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%define _ctag1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-02 at 18:00 -0700, PGNet Dev wrote:
> (i'd been discussing this issue with praiskup @ copr-devel/buildsys;
> he suggested that I bring it here ...)
>
> This spec
>
>
>
(i'd been discussing this issue with praiskup @ copr-devel/buildsys; he
suggested that I bring it here ...)
This spec
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
which uses forgemeta to pull multiple SCM sources,
13 matches
Mail list logo
