Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-18 Thread nicolas . mailhot 
Hi,

> 4. There is a bug in EL7 that causes spectool not to process the resulting 
> files. rpmbuild and mock work fine though. I
> added a -i switch to the macro that prints the resolved source url, you can 
> then dump it in curl, wget or whatever in EL7.
> Alternatively, get someone to fix the EL7 toolchain.

Anyway, with the latest changes, we don't hit the EL7 bug anymore so spectool 
also works in EL7

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-16 Thread nicolas . mailhot 
Hi

Anyway, to answer some of the questions posted during review and in:

https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-13/fpc.2017-12-13-18.00.log.html

1. I just posted the second part of the proposal (the Go-specific bits). Read 
it there https://fedoraproject.org/wiki/More_Go_packaging to understand some of 
the choices of this draft.

2. I added a %forgeautosetup helper for %autosetup users (though I don't use it 
myself, some testing would be appreciated)

3. I added some optional parameters for parameter lovers. Though the macro 
processes many rpm variables, and sets many others, which are used in other 
parts of the spec including in the proposed Go autoprovides, so full 
parametrization is neither suitable nor technically possible.

This is not a single-purpose macro that influences a single part of the spec. 
Forge and SCM data has effects on all parts of the spec, like %{name} or 
%{version}. A %{commit} or %{tag} is just a form of %{version} anyway.

People will have to set the variables to specific names anyway for the rest of 
the automation to work, our guidelines already mandate lots of variables to 
handle forge hosting, this proposal actually shrinks the number of variables 
needed to handle this kind of project (and don't make me start on the way 
different parts of our guidelines name the same variable in slightly different 
ways, causing a mess when you try to put everything together).

4. There is a bug in EL7 that causes spectool not to process the resulting 
files. rpmbuild and mock work fine though. I added a -i switch to the macro 
that prints the resolved source url, you can then dump it in curl, wget or 
whatever in EL7. Alternatively, get someone to fix the EL7 toolchain.

5. The macro does not handle nor intends to handle multiple downloaded 
tarballs. This is quite a rare case and it becomes infinitesimal when you add 
modern scm-based software publishing services to the mix. Plus, the Go 
automation is centered on a single root import path.

6. Most specs lag the current GitHub guidelines, the current GitHub guidelines 
are broken as written (because GiHub changed), and I'm pretty sure the 
resulting packages would fail a source download test (either because the url no 
longer exists or because it names the downloaded file some other way). That 
pretty conclusively shows the current way of handling such services does not 
work. If you want more proof, go look at some Go spec files that rely on GitHub 
(for example golang-googlecode-google-api-client). I haven't tested the other 
services our guidelines cover, they are probably also broken in some way.

7. the way of handling corner cases is already documented in the proposal 
(that's why it's so long, it treats all cases). If you have some other corner 
case in mind, please post it.

8. the macro could certainly grow as more software hosting services are added. 
That's not a problem because the complexity is not in the handling of a 
specific service, it's in the other common parts. Adding a service it mostly 
writing the Lua patterns (~regexes) to extract the needed parts from the 
project url, and then combining them the same way our guidelines currently do. 
The difference is that individual packagers do not need to read or apply those 
guidelines, the result is made available to the whole distro as soon as the 
macro package is updated. So the process complexity actually shrinks. Here is 
the full length of the GitHub-specific block for example

  if (string.match(forge, "^github[%.-]") or string.match(forge, 
"[%.-]github[%.]")) then
forgeurl = string.match(forgeurl, "https://[^/]+/[^/]+/[^/#?]+;)
if (forgeurl == "") then
  if not silent then
rpm.expand("%{error:GitHub URLs must match 
https://(…[-.])github[-.]…/owner/repo !\\n}")
  end
else
  explicitset("forgeurl",   forgeurl)
  safeset("archiveext", "tar.gz")
  safeset("forgesetupargs", "-n %{archivename}")
  if (commit ~= "") or (tag ~= "") then
safeset("scm", "git")
  end
  local owner = string.match(forgeurl, "^[^:]+://[^/]+/([^/]+)")
  local repo  = string.match(forgeurl, "^[^:]+://[^/]+/[^/]+/([^/]+)")
  if (tag ~= "") then
safeset("archivename",   repo .. "-%{tag}")
safeset("archiveurl","%{forgeurl}/archive/%{tag}.%{archiveext}")
  else
if (commit ~= "") then
  safeset("archivename", repo .. "-%{commit}")
  safeset("archiveurl",  "%{forgeurl}/archive/%{commit}/" .. repo .. 
"-%{commit}.%{archiveext}")
else
  safeset("archivename", repo .. "-%{version}")
  safeset("archiveurl",   
"%{forgeurl}/archive/v%{version}.%{archiveext}")
end
  end
end
  end

Don't tell me that's overly difficult to understand or adapt. I'm sure the 
mediawiki markup dedicated to GitHub in our guidelines is actually longer 
(plus, it does not work and it is not applied consistently)

It could be condensed by removing

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-14 Thread Ken Dreyer 
On Tue, Dec 12, 2017 at 1:16 PM, Adam Williamson
 wrote:
> On Tue, 2017-12-12 at 21:11 +0100, nicolas.mail...@laposte.net wrote:
>>
>> > If you have patches that apply at different levels, you can't use
>> > it,
>> > unless there's a trick I don't know about.
>>
>> My patches are all -p1 as taught by ancient rpm lore, but sometimes I
>> mix patches from other origins and those can be anything.
>>
>>
>> Thanks for the tip, I will try to remember it
>
> No problem. I find %autosetup so handy that usually if I need to use a
> patch from somewhere else that's at a different prefix level, I just
> hand-edit that patch to be at level 1 so I can keep using it...

Definitely agree with rewriting the patch to fit %autosetup. It also
reminds me to resubmit the patch upstream whenever I find patches that
old :)

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-12 Thread Adam Williamson 
On Tue, 2017-12-12 at 21:11 +0100, nicolas.mail...@laposte.net wrote:
> 
> > If you have patches that apply at different levels, you can't use
> > it,
> > unless there's a trick I don't know about.
> 
> My patches are all -p1 as taught by ancient rpm lore, but sometimes I
> mix patches from other origins and those can be anything.
> 
> 
> Thanks for the tip, I will try to remember it

No problem. I find %autosetup so handy that usually if I need to use a
patch from somewhere else that's at a different prefix level, I just
hand-edit that patch to be at level 1 so I can keep using it...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-12 Thread nicolas . mailhot 
De: "Adam Williamson" 

On Sat, 2017-12-09 at 13:34 +0100, nicolas.mail...@laposte.net wrote:
>> I don't have a good history with %autosetup :) It tends to hate the patches 
>> I produce.

> Did you know you still can/have to pass it a prefix level? That tripped
> me up for a while. For most cases, you want:

> %autosetup -p1

That's probably what I needed last time, but it was faster to add a %patch line 
than to investigate :). I find out nowadays there are lots of things I could do 
better if only I had the time to look them up.

> If you have patches that apply at different levels, you can't use it,
> unless there's a trick I don't know about.

My patches are all -p1 as taught by ancient rpm lore, but sometimes I mix 
patches from other origins and those can be anything.


Thanks for the tip, I will try to remember it

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-12 Thread Adam Williamson 
On Sat, 2017-12-09 at 13:34 +0100, nicolas.mail...@laposte.net wrote:
> I don't have a good history with %autosetup :) It tends to hate the patches I 
> produce.

Did you know you still can/have to pass it a prefix level? That tripped
me up for a while. For most cases, you want:

%autosetup -p1

If you have patches that apply at different levels, you can't use it,
unless there's a trick I don't know about.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Panu Matilainen 

On 12/11/2017 06:07 PM, nicolas.mail...@laposte.net wrote:

Hi all,

Since most participants seems to be in favor of explicit %setup handling, I've 
updated the wiki and the macro file


Thank you.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread nicolas . mailhot 
Hi all,

Since most participants seems to be in favor of explicit %setup handling, I've 
updated the wiki and the macro file

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread nicolas . mailhot 
De: "Panu Matilainen"

> On a more constructive note, I'd think conceptually this might better 
> fit into %autosetup territory. Have you looked at extending that, rather 
> than overriding/building something separate?

I've looked at it a bit, but apart the fact autosetup is an actual macro, 
unlike setup, it does not seem a lot better than %setup for my purposes.

To extend it safely and transparently I would still need to test that the 
processed archive matches the archive that needs special handling, and I don't 
know how to access the expanded archive name from within autosetup.

Otherwise that would just be "if processed_archive == 
%{archivename}%{archiveext} use setupargs else do the usual processing"

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, Dec 11, 2017 at 01:23:19PM +0100, nicolas.mail...@laposte.net wrote:
> Hi Neal,
> 
> > And the issue you're having that requires %setupargs is not a problem
> > in RPM 4.14
> 
> I don't have an issue with  %setupargs, I have an issue with requiring 
> packagers to change stuff in the spec header *and*
> at %prep level, which is not in the same place of the spec. That is something 
> which has wasted huge quantities of man-hours in the past, even for 
> experienced packagers.
> 
> The automation knows how the downloaded source archive will be named, what is 
> the structure of the source archive (the arguments that need passing to 
> %setup for this archive). The question is just how to pass that knowledge 
> from the automation macro call to %setup or %autosetup.
> 
> Overriding %setup makes this work transparently with little risk.
> If there is a strong opposition to that what is the best way to achieve the 
> same result?
> 
> Using a specific setup-ish macro name like suggested by Panu is trivial 
> technically but has the huge drawback that it requires a specific call by the 
> packager (and many will forget it, at least as first). So it de-optimizes the 
> packager workflow. I'd frankly prefer to optimize the packager workflow over 
> helping tooling – that's what costs actual money and potential contributors.

I think it's OK. After all you already require a specific '%setup -n '
invocation ( in this case is different then the github default), and
setting a few different fields in a specific order. So in practice people
are going to go by the template provided in the docs, and whether it's
%setup -n something or %forgesetup doesn't make much difference.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Panu Matilainen 

On 12/11/2017 02:23 PM, nicolas.mail...@laposte.net wrote:

Hi Neal,


And the issue you're having that requires %setupargs is not a problem
in RPM 4.14


I don't have an issue with  %setupargs, I have an issue with requiring 
packagers to change stuff in the spec header *and*
at %prep level, which is not in the same place of the spec. That is something 
which has wasted huge quantities of man-hours in the past, even for experienced 
packagers.


They only need to change %prep once. Which they do at the time they 
learn how to use these new macros anyway.




The automation knows how the downloaded source archive will be named, what is 
the structure of the source archive (the arguments that need passing to %setup 
for this archive). The question is just how to pass that knowledge from the 
automation macro call to %setup or %autosetup.

Overriding %setup makes this work transparently with little risk.
If there is a strong opposition to that what is the best way to achieve the 
same result?

Using a specific setup-ish macro name like suggested by Panu is trivial 
technically but has the huge drawback that it requires a specific call by the 
packager (and many will forget it, at least as first). So it de-optimizes the 
packager workflow. I'd frankly prefer to optimize the packager workflow over 
helping tooling – that's what costs actual money and potential contributors.

If there is now way to do it cleanly or safely in rpm, I'll de-optimize the 
packager side. I don't want to cause problems to anyone. But that would be 
pretty sad.


Specific functionality requiring explicit invocation is better than 
feeble magic built on loopholes (that will eventually be closed anyway)


On a more constructive note, I'd think conceptually this might better 
fit into %autosetup territory. Have you looked at extending that, rather 
than overriding/building something separate?


- Panu -


Regards,


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread nicolas . mailhot 
Hi Neal,

> And the issue you're having that requires %setupargs is not a problem
> in RPM 4.14

I don't have an issue with  %setupargs, I have an issue with requiring 
packagers to change stuff in the spec header *and*
at %prep level, which is not in the same place of the spec. That is something 
which has wasted huge quantities of man-hours in the past, even for experienced 
packagers.

The automation knows how the downloaded source archive will be named, what is 
the structure of the source archive (the arguments that need passing to %setup 
for this archive). The question is just how to pass that knowledge from the 
automation macro call to %setup or %autosetup.

Overriding %setup makes this work transparently with little risk.
If there is a strong opposition to that what is the best way to achieve the 
same result?

Using a specific setup-ish macro name like suggested by Panu is trivial 
technically but has the huge drawback that it requires a specific call by the 
packager (and many will forget it, at least as first). So it de-optimizes the 
packager workflow. I'd frankly prefer to optimize the packager workflow over 
helping tooling – that's what costs actual money and potential contributors.

If there is now way to do it cleanly or safely in rpm, I'll de-optimize the 
packager side. I don't want to cause problems to anyone. But that would be 
pretty sad.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Neal Gompa 
On Mon, Dec 11, 2017 at 5:57 AM,   wrote:
>>De: "Panu Matilainen"
>
> Hi Panu,
>
>>> But don't override %setup. There's no need for such abuse
>
>> It is really pretty safe, the macro controls the downloaded file, the file 
>> structure is known, the only time it won't "just
>> work" is when a spec needs to call %setup several times (in that case the 
>> arguments will be wrong for the second call).
>
> BTW the macro know even more than that, it knows the archive filename for 
> which setup needs specific arguments so it could be made 100% transparent and 
> safe if it was possible to specify
>
> "if archive == %{archivename}%{archiveext} change %setup to %setup 
> %{?setupargs}"
>

%setup is a very special macro. It's not actually written in macro
language, (and neither is %patch, for that matter). It's really not a
good idea to override it, especially if people need to do multi-source
things.

And the issue you're having that requires %setupargs is not a problem
in RPM 4.14, which ships in Fedora 27 and newer, and will be part of
RHEL 8.

If you'd like this to be fixed in EL7 or something, then file a bug
report against RHEL 7 and see if anything can be done about it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Panu Matilainen 

On 12/11/2017 12:51 PM, nicolas.mail...@laposte.net wrote:


De: "Panu Matilainen"

Hi Panu,


Kudos for work on reducing repetitive complex error prone cruft in specs!


Thanks!


But don't override %setup. There's no need for such abuse


It is really pretty safe, the macro controls the downloaded file, the file structure is 
known, the only time it won't "just work" is when a spec needs to call %setup 
several times (in that case the arguments will be wrong for the second call).
No. It's not about whether it's "pretty safe" or not, it's an rpm 
built-in and it's simply not yours to override (and what about the next 
guy who wants to override it for their own purposes, say, go-specific 
thing?). The fact that you can do so is basically a loophole in rpm that 
just hasn't gotten closed, yet. Don't bet the future on loopholes.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Panu Matilainen 

On 12/11/2017 12:51 PM, nicolas.mail...@laposte.net wrote:


De: "Panu Matilainen"


and allows you to %autosetup underneath on versions where macro arguments are 
expanded (rpm >= 4.14)


Interesting, are the changes described somewhere? Not that I want to break 
compat with el7 from the startup if I can avoid it


Sorry, forgot to reply to this part.

http://rpm.org/wiki/Releases/4.14.0#Macros has the bullet points, other 
than that it's pretty scarce.


https://bugzilla.redhat.com/show_bug.cgi?id=1397209 is the original case 
with pointers to upstream commit etc.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread nicolas . mailhot 
>De: "Panu Matilainen"

Hi Panu,

>> But don't override %setup. There's no need for such abuse

> It is really pretty safe, the macro controls the downloaded file, the file 
> structure is known, the only time it won't "just
> work" is when a spec needs to call %setup several times (in that case the 
> arguments will be wrong for the second call).

BTW the macro know even more than that, it knows the archive filename for which 
setup needs specific arguments so it could be made 100% transparent and safe if 
it was possible to specify

"if archive == %{archivename}%{archiveext} change %setup to %setup 
%{?setupargs}"

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread nicolas . mailhot 

De: "Panu Matilainen"

Hi Panu,

> Kudos for work on reducing repetitive complex error prone cruft in specs!

Thanks!

> But don't override %setup. There's no need for such abuse

It is really pretty safe, the macro controls the downloaded file, the file 
structure is known, the only time it won't "just work" is when a spec needs to 
call %setup several times (in that case the arguments will be wrong for the 
second call).

And, how many specs need to do that? Especially when the target project uses 
modern forge hosting? That's already deep rpm black magic land for most 
packagers.

I can add a guard so the override is only set when %{setupargs} is non empty if 
you want.

> Use something like %forgesetup instead which signifies it's something a 
> bit special

I don't want to signify it's a bit special, that's one more step the packager 
can do wrong, I'd rather have the common case easy and the complex cases 
possible.

Granted, the macro makes the complex cases a tad more complex, but if you're 
already in multiple-setup-call hell, how difficult is it to set %{setupargs} to 
"" ?

But, I'll bow to whatever FPC decides. *I* won't make the wrong macro call in 
my specs :).

> and allows you to %autosetup underneath on versions where macro arguments are 
> expanded (rpm >= 4.14)

Interesting, are the changes described somewhere? Not that I want to break 
compat with el7 from the startup if I can avoid it

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-11 Thread Panu Matilainen 

On 12/08/2017 08:03 PM, nicolas.mail...@laposte.net wrote:

Hi,

I am proposing for inclusion a macro set aimed at automating the packaging of 
forge-hosted projects.

— Packaging draft: 
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
— FPC ticket: https://pagure.io/packaging-committee/issue/719 (without the 
“hasdraft” tag because I don't know how to add it in pagure)
— fedora-rpm-macros RFE with the macro file: 
https://bugzilla.redhat.com/show_bug.cgi?id=1523779

What it does: conversion of a forge url, version, tag, commit set to the values 
expected in rpm specfiles, in optional rpm variables. Computation of the 
corresponding %{dist}.

Objective: centralize forge structure know-how in a single technical place, 
deprecate all the complex manual forge URL handling spread over many Fedora 
spec files, simplify packaging and spend time on more interesting stuff.


Kudos for work on reducing repetitive complex error prone cruft in specs!

But don't override %setup. There's no need for such abuse (yes 
overriding rpm build-ins is abuse even if it still doesn't prevent it) 
and no good will come out of it.


Use something like %forgesetup instead which signifies it's something a 
bit special, and allows you to %autosetup underneath on versions where 
macro arguments are expanded (rpm >= 4.14)


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-09 Thread nicolas . mailhot 
De: "Zbigniew Jędrzejewski-Szmek" 

> Impressive! I just tested this on some random package using github and
> everything works great.

Thanks for the nice feedback

> Would it be possible to drop the requirement to have "/" at the end
> of a github URL? I think it's natural to paste the URL without the
> trailing slash...

Not having to handle special cases was easier for me, but ok done, the macro is 
now less pedantic.

> Your instructions say "just copy the file into /usr/lib/rpm/macros.d",
> suggesting that the name can by anything, but I think it has to start
> with "macros.".

You're right, it's documented now.

> Wouldn't it be better to recommend %autosetup instead of %setup?
> It's one less thing to change if patches are added.

I don't have a good history with %autosetup :) It tends to hate the patches I 
produce.

OTOH it would be nice if the macro could adjust %setup to mean %setup -n 
%{archivename} when necessary, but I couldn't figure how to do it cleanly.

> add a text like
> "See https://fedoraproject.org/wiki/Packaging:Versioning how to adjust
> Release tag for pre-/post- release commits.". 

Done, thank you for the review.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-09 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Dec 08, 2017 at 07:03:48PM +0100, nicolas.mail...@laposte.net wrote:
> Hi,
> 
> I am proposing for inclusion a macro set aimed at automating the packaging of 
> forge-hosted projects.
> 
> — Packaging draft: 
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
> — FPC ticket: https://pagure.io/packaging-committee/issue/719 (without the 
> “hasdraft” tag because I don't know how to add it in pagure)
> — fedora-rpm-macros RFE with the macro file: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1523779
> 
> What it does: conversion of a forge url, version, tag, commit set to the 
> values expected in rpm specfiles, in optional rpm variables. Computation of 
> the corresponding %{dist}.

Impressive! I just tested this on some random package using github and
everything works great.

Would it be possible to drop the requirement to have "/" at the end
of a github URL? I think it's natural to paste the URL without the
trailing slash...

Your instructions say "just copy the file into /usr/lib/rpm/macros.d",
suggesting that the name can by anything, but I think it has to start
with "macros.". At least "forgeforge.macros" did not work here.

Wouldn't it be better to recommend %autosetup instead of %setup?
It's one less thing to change if patches are added.

In the docs, the instructions under "Packaging a pre-release commit" 
actually apply to post-release commits. Maybe change the title
to "Packaging a pre-release/post-release commit" and add a text like
"See https://fedoraproject.org/wiki/Packaging:Versioning how to adjust
Release tag for pre-/post- release commits.". 

Zbyszek


> 
> Objective: centralize forge structure know-how in a single technical place, 
> deprecate all the complex manual forge URL handling spread over many Fedora 
> spec files, simplify packaging and spend time on more interesting stuff.
> 
> What's currently implemented: definitions for github.com and 
> code.googlesource.com
> (I didn't want to propose stuff I didn't use myself. Adding more definitions 
> is trivial. The macros are in Lua which is change-friendly, no arcane rpm 
> syntax knowledge is needed).
> 
> Please consult packaging draft for full information.
> 
> This is a spin-off of the work I'm currently doing on Go packaging, as Go is 
> heavily forge-oriented. I took the time to extract the generic 
> non-Go-specific forge knowledge in a separate macro file. The macros have 
> been heavily tested on real-life Go projects with quite a lot of variance, on 
> EL7 and rawhide. That's why they come with built-in error handling.
> 
> Regards,
> 
> -- 
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

2017-12-09 Thread Neal Gompa 
On Sat, Dec 9, 2017 at 3:33 AM,   wrote:
>
> Since I'm a nice person I added GitLab support this morning (both gitlab.com 
> and hosted gitlab). Releases are clearly an afterthought in GitLab, they 
> depend on free-form tags and can't be used in rpm without knowing the 
> corresponding hash (so worst-case, packaging a GitLab release requires 
> declaration of version + tag + commit and not just version as on other 
> forges).
>

I made an RFE for this a while back, people can thumbs it up so that
it gets more priority:
https://gitlab.com/gitlab-org/gitlab-ce/issues/38830


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org