Hi Jason,
> > "nm" == nicolas mailhot wrote:
> Jason L Tibbitts wrote:
> > nm> And the forge macros are now available since
> > nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to
> > upstream
> > nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> > Please don't forget to let
De: "nicolas mailhot"
À: "Jan Chaloupka"
>> I mentioned a list of things that you did not answer fully. Most important
>> to me:
>> - your macros do not generate build-time dependencies, which I see as
>> one of the drawbacks.
> Generating BuildRequires dynamically needs changes in rpm toolin
De: "Jan Chaloupka"
Hi Jan
Apologies for the delayed answer, I was beating the PR into shape to address
review comments.
> Let's keep moving forward,
> improving the infrastructure for other folks and pushing new ideas and
> improvements into practical solutions.
Let's move forward, I'm sic
Hi Nicolas,
before I start arguing, I appreciate all your hard work on improving the
Go guidelines, spending so much time explaining reasoning behind your
decision. Also appreciating the effort on making the life easier for
packagers, not just in the Go land, but throughout the distribution as
, 2018 7:34:03 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Jakub Cajka"
>
> Hi Jakub,
>
> >> And I'm sure any
> >> attempt to strip the WIP bits from my side will be m
- Mail original -
De: "Jakub Cajka"
Hi Jakub,
>> And I'm sure any
>> attempt to strip the WIP bits from my side will be met with energetic
>> protests.
> Have you tried that? What make you assume that? I'm sure that if you do it in
> constructive way, they will be accepted.
My exper
February 5, 2018 3:27:01 PM
> Subject: Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Jakub Cajka"
>
> > Our as Fedora or yours company/org? I believe that your contribution of
&g
, 2018 4:48:31 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Jakub Cajka"
>
> Hi Jakub
>
> > I think that it would be best if Nicolas could fold his proposal in to the
> > original
- Mail original -
De: "Jakub Cajka"
Hi Jakub
> I think that it would be best if Nicolas could fold his proposal in to the
> original draft as
> optional part for simple library/binary packages.
Frankly, that's a lot of work and churn, I don't want the new parts to be
refused because
- Mail original -
De: "Jakub Cajka"
> Our as Fedora or yours company/org? I believe that your contribution of those
> in to Fedora will be much
> appreciated.
Our was meaning the set of specs we are preparing for inclusion. Can't really
share them before the macros they depend on are
018 12:16:14 PM
> Subject: [Fedora-packaging] Re: Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Jakub Cajka"
>
> > I think one of the main responsibilities of Fedora packager is to work with
- Mail original -
De: "Jakub Cajka"
> I think one of the main responsibilities of Fedora packager is to work with
> upstreams, help them
> mature and generally improve their projects.
Sure but expecting everything to be perfect and consistent before shipping
anything just DOES NOT WO
- Original Message -
> From: "Robert-André Mauchin"
> To: devel@lists.fedoraproject.org
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards
> and practices for Fedora"
>
> Sent: Friday, February 2, 2018 4:54:10 PM
&g
ruary 3, 2018 4:27:36 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> Hi Jakub
>
> > I'm strongly against general unrestricted practice of compat packages as
> > proposed.
- Mail original -
De: "Nicolas Mailhot"
> It's a bit of a Lego guideline, you assemble the spec blocs you need, and
> ignore those you don't need. The
> example was chosen to include as many blocks as possible, with the
> walkthrough explaining their respective
> functions. All the blo
Hi Robert André
That's an interesting request
I guess you can't figure if the example is for building binaries or Go libs,
because there is no hard frontier between both cases in the proposed guidelines
In Go, everything is effectively a code library that can be reused elsewhere.
So the approa
De: "Jakub Cajka"
Hi Jakub
> I'm strongly against general unrestricted practice of compat packages as
> proposed. If you need compat package you
> need to work with usptreams on stabilizing the API/project, fork it, or just
> use COPR as your projects(or its
> dependencies) are not yet mature
On mardi 30 janvier 2018 16:11:49 CET nicolas.mail...@laposte.net wrote:
> Hi,
>
> Now the technical PR is submitted
> https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
>
> and waiting for action from the go-srpm-macros maintainers, I took (quite a
> long) time to refresh and flesh
ruary 1, 2018 4:24:52 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> >> Filling upstream holes is pretty much the definition of an
> >> integrator/distributor role. In G
De: "Colin Walters"
> I appreciate the work you're doing here,
Thank you
> but I think the right path for golang (indeed for most other language
> ecosystems) is to autogenerate
> specs.
You're, of course, are entitled to your opinion, but I do not share it :) I
think rpm has been an incred
On Thu, Feb 1, 2018, at 10:24 AM, nicolas.mail...@laposte.net wrote:
>
> Not directly. It does provide the means to easily rev a spec to a new
> code state (version tag or commit), and it makes deps systematic (so
> Fedora tooling can accurately detect what is likely to be impacted by a
> cha
On 02/01/2018 05:49 AM, Jakub Cajka wrote:
On contrary Fedora is trying to fill the hole that upstream Go projects dug them selves in to.
IMNHO Go have traded any subjectively perceived "RPM/deb hell" for even deeper levels of
"Go (vendor) hell".
This unfortunately became a trend: "the old pa
De: "Jakub Cajka"
>> Filling upstream holes is pretty much the definition of an
>> integrator/distributor role. In Go they are particularly numerous and deep,
>> but Fedora users do want their docker and kubernetes (and Kubernetes, BTW,
>> is astonishingly free of the problems that plague many Go
De: "Owen Taylor"
> I'm embarrassed to admit that before I sent my mail I carefully read over
> ... the old PackageDrafts/Go :-( My only excuse is that it was in my
> browser history.
NP, that gave you some context on where Fedora is today.
> Having actually read the relevant parts of "More Go P
ruary 1, 2018 2:51:13 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> Hi Jakub,
>
> > It depends (as everything) on available manpower, if you are willing to own
> > your depende
De: "Jakub Cajka"
Hi Jakub,
> It depends (as everything) on available manpower, if you are willing to own
> your dependencies
> you can package anything and everything debundled.
Sure, but available manpower depends on how high the bar you put for people
wanting to join, and right now this b
Hi Nicolas,
I'm embarrassed to admit that before I sent my mail I carefully read over
... the old PackageDrafts/Go :-( My only excuse is that it was in my
browser history.
Having actually read the relevant parts of "More Go Packaging", the
explanation of compat packages and notification procedure
uary 1, 2018 11:21:59 AM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Owen Taylor"
>
> Hi Owen,
>
> > Is there a guide for Fedora packagers about how to handle unbu
- Mail original -
De: "Owen Taylor"
Hi Owen,
> Is there a guide for Fedora packagers about how to handle unbundling for
> golang packages? The draft guidelines don't seem to go into any details.
I don't think there is, nor that it is necessarily needed. The posted
guidelines should be
January 31, 2018 6:50:21 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
> Hi Nicolas,
>
> Is there a guide for Fedora packagers about how to handle unbundling for
> golang packages? The draft guidelines don't seem to go into
Hi Nicolas,
Is there a guide for Fedora packagers about how to handle unbundling for
golang packages? The draft guidelines don't seem to go into any details.
I've looked at packaging a few golang packages unbundled, and have
immediately run into:
A) lots of unpackaged dependencies
B) dependenci
>De: "Neal Gompa"
> The only thing I see that might be missing is autogenerating
> bundled(golang()) Provides when a vendor tree exists (with the
> appropriate automatic filters on Requires).
I had though a little about doing it but first, as many Go elements, vendoring
relies on conventions no
On Tue, Jan 30, 2018 at 10:11 AM, wrote:
> Hi,
>
> Now the technical PR is submitted
> https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
>
> and waiting for action from the go-srpm-macros maintainers, I took (quite a
> long) time to refresh and flesh out the corresponding packagin
Hi,
Now the technical PR is submitted
https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
and waiting for action from the go-srpm-macros maintainers, I took (quite a
long) time to refresh and flesh out the corresponding packaging guidelines
proposal. It should be fairly complete no
De: "Jakub Cajka"
> Very nice list, it would be nice to have it as sub-wiki page of guidelines. I
> have took liberty to add
> few points.
Ok, I put it here so people have a place to work on it
https://fedoraproject.org/wiki/More_Go_packaging#Go_developer_guidance:_making_your_software_third-
- Mail original -
De: "Jakub Cajka"
Hi Jakub,
>> For my part I doubt I'll ever use it in EL6 since I did it
>> for Go and the EL6 Go stack is really too old for a merge to be interesting.
>> Anyway I'll certainly let you know when I feel the time is right (but do not
>> block on me!)
>
- Original Message -
> From: "nicolas mailhot"
> To: "Development discussions related to Fedora"
>
> Sent: Tuesday, January 23, 2018 7:45:06 PM
> Subject: Re: Re: Proposed Fedora packaging guideline: More Go packaging
>
>
>
>
"
>
> Sent: Tuesday, January 23, 2018 6:00:24 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
>
> I wish this message wasn't crossposted everywhere, but I don't want to
> lose any discussion by trimming the CC list. Sorry if replies genera
"
>
> Sent: Tuesday, January 23, 2018 9:28:15 PM
> Subject: Re: Proposed Fedora packaging guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Jason L Tibbitts III"
>
> >>>>> "nm" == nicolas mailhot writes:
> "nm" == nicolas mailhot writes:
nm> I don't know about EPEL6, but we use it as-is in EL7 and it works
nm> just as well (except maybe for the %autosetup bits but IIRC that's
nm> autosetup which is broken in EL7).
I had ported autosetup to EPEL6 and then at the next release the macros
showed
- Mail original -
De: "Jason L Tibbitts III"
> "nm" == nicolas mailhot writes:
>nm> And the forge macros are now available since
>nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
>nm> renaming the file). Heartfelt thanks to Jason Tibbitts !
> Please don't fo
- Mail original -
De: "Mátyás Selmeci"
Hi,
> This looks pretty cool!
Thanks for the feedback!
> One thing I notice in the limitations section of
> your draft is a lot of "we can't do XXX due to lack of release
> discipline..."
> Do you have any recommendations for Go programmers o
- Mail original -
De: "nicolas mailhot"
> Now that the non-Go part in redhat-rpm-macros is merged in devel I'll try to
> do a clean PR on go-srpm-macros.
> Then once Jan or Jakub accepts it it will be possible to play with the
> automation in devel and I'll be able to share my specs s
- Mail original -
De: "Neal Gompa"
> For snipping, use "[...]" notation to indicate skipped stuff. It's
> hard to tell otherwise.
Ok, that was easy to fix :)
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsu
I wish this message wasn't crossposted everywhere, but I don't want to
lose any discussion by trimming the CC list. Sorry if replies generate
bounces for some.
> "nm" == nicolas mailhot writes:
nm> And the forge macros are now available since
nm> redhat-rpm-config-73-1.fc28 (I had missed th
On 12/17/2017 01:11 AM, nicolas.mail...@laposte.net wrote:
Hi,
I am proposing for inclusion a set of rpm technical files aimed at automating
the packaging of forge-hosted projects.
- Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
- https://pagure.io/packaging-committee/issue
On Tue, Jan 23, 2018 at 9:40 AM, wrote:
>
>> - Mail original -
>> De: "Neal Gompa"
>
>>> I'm curious, what are you missing in the preamble ? As far as I can see
>>> it's all there (even though some values
>>> set to variables %gometa precomputes). I had it's right autogenerated some
>>>
> - Mail original -
> De: "Neal Gompa"
>> I'm curious, what are you missing in the preamble ? As far as I can see it's
>> all there (even though some values
>> set to variables %gometa precomputes). I had it's right autogenerated some
>> parts of it in the past but it's all
>> converted
- Mail original -
De: "Fabio Valentini"
> So, if I understand correctly, both the forge stuff and the new macros for
> go packaging are completely opt-in?
> If that's correct, this looks like the best solution to me - as old
> packages can then be converted one at a time (which I am loo
On Tue, Jan 23, 2018 at 9:00 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>> As long as I can do Obsoletes/Provides for the old name for the devel,
>> unit-test,
>
> BTW is anyone using the unit-test packages? Right now I do not generate them,
> I don't need them, and making t
- Mail original -
De: "Neal Gompa"
> As long as I can do Obsoletes/Provides for the old name for the devel,
> unit-test,
BTW is anyone using the unit-test packages? Right now I do not generate them, I
don't need them, and making them work with autodeps would be hairy (deploying
with
On Tue, Jan 23, 2018 at 8:54 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>> 2. if your concern is that the *forge* macros are defective somewhere I'd
>>> be curious where as you'd be the
>>> first to report an actual technical problem. I've used them intensively in
>>> raw
- Mail original -
De: "Neal Gompa"
>> 2. if your concern is that the *forge* macros are defective somewhere I'd
>> be curious where as you'd be the
>> first to report an actual technical problem. I've used them intensively in
>> rawhide and el7 with many different
>>rpm tools and the
On Tue, Jan 23, 2018 at 5:45 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>>
I really do like this. There are only two issues I have with it:
1. This seems to mandate that all packages must be named by their
>>
De: "Neal Gompa"
>> The issue is that the new Go macros are tightly wound into the forge
>> macros. I just want to be sure that we can leverage things like the
>> dependency generators without all the other stuff.
Hi Neal,
>I should probably not let this pass without clarifying:
> 3. if your
On Jan 23, 2018 12:41, wrote:
- Mail original -
De: "Neal Gompa"
>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>
>>> I really do like this. There are only two issues I have with it:
>>>
>>> 1. This seems to mandate that all packages must be named by their
>>> import path. My gola
- Mail original -
De: "Neal Gompa"
>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>
>>> I really do like this. There are only two issues I have with it:
>>>
>>> 1. This seems to mandate that all packages must be named by their
>>> import path. My golang package (snapd) is not, inten
- Mail original -
De: "Neal Gompa"
Hi,
Thanks for the review !
> I really do like this. There are only two issues I have with it:
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to c
4:04:19 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More
> Go packaging
>
>
>
> On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa < ngomp...@gmail.com > wrote:
>
>
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> < dridi
On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa wrote:
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> wrote:
> >> I really do like this. There are only two issues I have with it:
> >>
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (
On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
wrote:
>> I really do like this. There are only two issues I have with it:
>>
>> 1. This seems to mandate that all packages must be named by their
>> import path. My golang package (snapd) is not, intentionally so. I
>> don't want to change this.
> I really do like this. There are only two issues I have with it:
>
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
>
> 2. Mandating a forge is going to be tricky for self-hosted s
On Sun, Dec 17, 2017 at 2:11 AM, wrote:
> Hi,
>
> I am proposing for inclusion a set of rpm technical files aimed at automating
> the packaging of forge-hosted projects.
>
> - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
> - https://pagure.io/packaging-committee/issue/734
>
63 matches
Mail list logo
