On 2/22/22 1:56 PM, Jason L Tibbitts III wrote:
Brandon Nielsen writes:
I would like to see the forge macros removed from the guidelines if
development truly has ceased.
I would like to get into them and at least see what needs to change
but... the internal implementation is somewhat baroqu
On 2/24/22 10:12 AM, Fabio Valentini wrote:
On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote:
especially since they don't really provide value for
standard GitHub tarball downloads etc. compared to the "old" SourceURL
some of us strongly disagree. admittedly, with no weight ...
Admittedly
I have stopped using the “forge” macros in most cases where I am packaging a
release/tag, since the URLs are simple enough without them, usually something
like
URL: https://github.com/foo/bar
Source0: %{url}/archive/v%{version}/bar-%{version}.tar.gz
However, when I need to package an untagged c
On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote:
>
> > especially since they don't really provide value for
> > standard GitHub tarball downloads etc. compared to the "old" SourceURL
>
> some of us strongly disagree. admittedly, with no weight ...
Admittedly, packages like the .spec for nginx yo
especially since they don't really provide value for
standard GitHub tarball downloads etc. compared to the "old" SourceURL
some of us strongly disagree. admittedly, with no weight ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubsc
On Tue, Feb 22, 2022 at 8:57 PM Jason L Tibbitts III wrote:
>
> > Brandon Nielsen writes:
>
> > I would like to see the forge macros removed from the guidelines if
> > development truly has ceased.
>
> I would like to get into them and at least see what needs to change
> but... the internal i
Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:
not all are concerned with building according to Fedora Packaging standards,
for proposal in inclusion
some of us use forgemeta because it provides capability that al
Once upon a time, Ian Pilcher said:
> Can anyone suggest a good (simple) example SPEC file that I can
> reference as an example of how to use the forgemeta macro?
Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:
https
> Brandon Nielsen writes:
> I would like to see the forge macros removed from the guidelines if
> development truly has ceased.
I would like to get into them and at least see what needs to change
but... the internal implementation is somewhat baroque and my time is
severely limited. I think
On 2/22/22 1:19 AM, Mattia Verga via devel wrote:
Il 21/02/22 22:09, Fabio Valentini ha scritto:
Hi!
I would recommend that you use the standard source handling as
documented on the SourceURL page.
The forge macros are no longer actively maintained or developed, the
last fix / update they receiv
Il 21/02/22 22:09, Fabio Valentini ha scritto:
> Hi!
> I would recommend that you use the standard source handling as
> documented on the SourceURL page.
> The forge macros are no longer actively maintained or developed, the
> last fix / update they received was almost two years ago.
> The original
On 2/21/22 15:09, Fabio Valentini wrote:
So, if you plan to package releases / tags from your GitHub project,
just use what's documented here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git_tags
Glad I asked. Thanks!
--
==
On Mon, Feb 21, 2022 at 9:55 PM Ian Pilcher wrote:
>
> Can anyone suggest a good (simple) example SPEC file that I can
> reference as an example of how to use the forgemeta macro?
>
> I'm trying to build SPEC files for a couple of personal GitHub-hosted
> projects, and I'd like to make them as rob
Can anyone suggest a good (simple) example SPEC file that I can
reference as an example of how to use the forgemeta macro?
I'm trying to build SPEC files for a couple of personal GitHub-hosted
projects, and I'd like to make them as robust as possible. Even though
I have no current plans to try t
14 matches
Mail list logo
