Le 2019-07-08 09:06, Jakub Cajka a écrit :
- Original Message -
From: "Nicolas Mailhot via devel"
To: "Christophe de Dinechin" , "Development
discussions related to Fedora"
Cc: "Robin Lee" , "nicolas mailhot"
Sent: Saturday, Jul
- Original Message -
> From: "Nicolas Mailhot via devel"
> To: "Christophe de Dinechin" , "Development discussions
> related to Fedora"
>
> Cc: "Robin Lee" , "nicolas mailhot"
>
> Sent: Saturday, July 6, 2019
Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
écrit :
>
> Also, would anybody mind if I add a note on the guideline page
> stating
> that this is from F31 on, since the go-rpm-macros package does not
> exist before. Unless there is a plan to create branches for earlier
> rele
On Saturday, 29 June 2019 09:26:20 CEST Nicolas Mailhot via devel wrote:
> Hi,
>
>
> > What should I do at this moment as a packager that maintaining some
> > Go packages?
> > Should I fix my packages and build against f31-go in Koji?
>
>
> Yes, sure, if you can that would be appreciated. The v
On Sat, Jun 29, 2019 at 10:15 AM Nicolas Mailhot via devel
wrote:
>
> Hi,
>
> > What should I do at this moment as a packager that maintaining some
> > Go packages?
> > Should I fix my packages and build against f31-go in Koji?
>
> Yes, sure, if you can that would be appreciated. The vast majority
Hi,
> What should I do at this moment as a packager that maintaining some
> Go packages?
> Should I fix my packages and build against f31-go in Koji?
Yes, sure, if you can that would be appreciated. The vast majority of
packages is easy to clean up (just adapt the templates in go-rpm-
templates o
On Sat, Jun 8, 2019 at 10:35 PM Nicolas Mailhot via devel
wrote:
>
> Hi,
>
> Fedora’s new Go packaging macros landed in rawhide (koji) today.
>
> The corresponding Fedora Go packaging conventions are therefore
> EFFECTIVE for new rawhide builds. For the first time in Fedora
- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek"
> To: "Development discussions related to Fedora"
>
> Cc: gol...@lists.fedoraproject.org
> Sent: Wednesday, June 12, 2019 4:20:40 PM
> Subject: Re: New Go Packaging Guidelines landed in
- Original Message -
> From: "Nicolas Mailhot"
> To: "Jakub Cajka"
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to
> Fedora"
> Sent: Wednesday, June 12, 2019 11:23:34 AM
> Subject: Re: New Go Packaging Guidel
On Wed, Jun 12, 2019 at 04:39:07AM -0400, Jakub Cajka wrote:
> > F31 change page:
> > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
> > and approval: https://pagure.io/fesco/issue/2120
>
> It seems that this change has been accepted as Self Contained Change
> but IMHO it
Le 2019-06-12 10:39, Jakub Cajka a écrit :
Fedora’s new Go packaging macros landed in rawhide (koji) today.
I thought that we have agreed on Go SIG meeting with eclipseo to do
this in side tag along with golang rebase(to avoid 2 rebuilds),
https://fedoraproject.org/wiki/Changes
- Original Message -
> From: "Nicolas Mailhot via devel"
> To: gol...@lists.fedoraproject.org
> Cc: devel@lists.fedoraproject.org, annou...@lists.fedoraproject.org, "Nicolas
> Mailhot"
> Sent: Saturday, June 8, 2019 3:45:20 PM
> Subject: New Go
Hi,
Fedora’s new Go packaging macros landed in rawhide (koji) today.
The corresponding Fedora Go packaging conventions are therefore
EFFECTIVE for new rawhide builds. For the first time in Fedora’s
history, we will be able to perform Go package builds conforming to an
approved Fedora Packaging
- Original Message -
> From: "Ben Cotton"
> To: devel-annou...@lists.fedoraproject.org, "Development discussions related
> to Fedora"
>
> Sent: Friday, April 12, 2019 10:11:51 PM
> Subject: Fedora 31 Self-Contained Change proposal: Adopt new
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
== Summary ==
The [[PackagingDrafts/Go| current Go packaging guidelines]] have been in a draft
state for several years now, and they do not reflect the
[[ More_Go_packaging|current practices ]] from the Go SIG. As a result
On jeudi 8 mars 2018 16:37:57 CET Jan Chaloupka wrote:
> On 03/07/2018 04:07 PM, Jan Chaloupka wrote:
> >
> > Saying that, I will prepare new builds of gofed so the new spec files
> > are generated with the new macros.
>
>
> F27 gofed build:
> https://bodhi.fedoraproject.org/updates/FEDORA-2018
On 03/07/2018 04:07 PM, Jan Chaloupka wrote:
On 03/07/2018 04:02 PM, Jan Chaloupka wrote:
On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:
On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are
Le mercredi 07 mars 2018 à 16:35 +0100, Nicolas Mailhot a écrit :
> Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit :
>
> Hi,
>
> > Nicolas, can you more elaborate on that? I don't see any more reason
> > why we should block folks from relying on the new macros.
>
> IMHO they're so
Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit :
Hi,
> Nicolas, can you more elaborate on that? I don't see any more reason
> why we should block folks from relying on the new macros.
IMHO they're solid enough to be used in production both for binary
packages and -devel packages (
On 03/07/2018 04:02 PM, Jan Chaloupka wrote:
On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:
On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new ma
On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:
On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:
> Hi Robert-André,
>
> thank you for your patience and all comments pointing out pieces that
> are not working as expected.
> Introduction of new macros is a time-consuming process and it requires
> resilience so we keep up till the state
>
e is only
one source of truth about the Go packaging.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
[2] https://fedoraproject.org/wiki/More_Go_packaging
Major changes, by memory:
1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix
2. %g
On 02/27/2018 07:22 PM, Nicolas Mailhot wrote:
Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit :
How do we test this? I installedtho go-srpm-macros from Rawhide but it
doesn't seem to have the required macros?
Yes in rawhide go-compilers and go-srpm-macros are in an inte
Hi Fabio,
thank you for staying with us in the Go packaging world and for sharing
any difficulty or problem you encounter with.
I created github repository [1] where you can report all issues wrt.
macros used in Go packaging.
We are currently in a process of iterating over all the macros
. Making
the packaging experience as easy as possible at the same time.
On 02/27/2018 07:39 PM, Robert-André Mauchin wrote:
On mardi 27 février 2018 15:49:44 CET Fabio Valentini wrote:
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and si
Le samedi 03 mars 2018 à 11:47 -0300, Athos Ribeiro a écrit :
>
> Are there any intentions to push the macros into f28? I really liked
> the
> improvements in the spec file sizes, but porting too many packages now
> and keep them updated in both f28 and rawhide (making the branches
> completely di
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
On Tue, Feb 27, 2018 at 07:22:42PM +0100, Nicolas Mailhot wrote:
> Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit :
> >
> >
> > How do we test this? I installedtho go-srpm-macros from Rawhide but it
> > doesn't seem to have the required macros?
>
> Yes in rawhide go-compile
On mardi 27 février 2018 19:39:47 CET you wrote:
> > 6) When I finally got the macros right enough for %prep, %build, and
> > %install to proceed, the build failed due to missing debuginfo files (and
> > warnings about duplicate files) - well, it's a source-only library
> > package,
> > how do I sp
On mardi 27 février 2018 15:49:44 CET Fabio Valentini wrote:
> Hi everybody,
>
> I've been following the (long overdue) improvements concerning go packaging
> in fedora, and since I saw that packages are starting to make use of the
> new mechanisms, I wanted to finally chec
Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit :
>
>
> How do we test this? I installedtho go-srpm-macros from Rawhide but it
> doesn't seem to have the required macros?
Yes in rawhide go-compilers and go-srpm-macros are in an intermediary
not fully tested/integrated state.
On mardi 27 février 2018 16:03:36 CET Nicolas Mailhot wrote:
> Le 2018-02-27 15:49, Fabio Valentini a écrit :
>
> Hi Fabio,
>
> Thanks a lot for testing, we need more input to produce great Go
> packaging tooling.
>
>
> > I've been following the (long
ade I don't understand either. It's looks
like an attempt to reintroduce old Go packaging conventions, but as they
overlap with the new ones (but are not sufficient to replace them), no
good can come out of it.
3) The %gosource macro doesn't work correctly (at least for github
sourc
Le 2018-02-27 15:49, Fabio Valentini a écrit :
Hi Fabio,
Thanks a lot for testing, we need more input to produce great Go
packaging tooling.
I've been following the (long overdue) improvements concerning go
packaging in fedora, and since I saw that packages are starting to
make use o
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
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
ful, but I *have* seen quite a few
Fedora packages that were declaring garbage deps, because the external tool was
run on another code state and the requirements were never corrected.
> I am surprised you are able to do that without any API issues. Have you
> tried to de-bundle an
ns
Totally agree with the release discipline in many Go projects.
gives up on many conventions of current Fedora Go packaging, as they
were an obstacle to the target packaging efficiency.
(Still part of the Limitations): Can you make a list of conventions you
consider as obstacles? I wo
, 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
aging drafts.
> I believe that technically exhausting document is needed as Go packaging is
> far from trivial. Sure it would be great to have
> (trivial) quick start guide. I think that your proposal fits that bill more
> than full documentation.
IMHO that's exactly what FPC expe
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
g to avoid working within
rpm via godep, refusing to include different states of the same Go code in the
distro when major Go apps *disagree* on the correct state to include) that
didn't work out in practice, with the hindsight of several years of Fedora Go
packaging and the Go package
t; Subject: Re: Proposed Fedora packaging guideline: More Go packaging
>
> 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
>
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
red digging through specs and mailing lists to find
> resolution examples before. The basic Go packaging skeleton will be
> sufficient is most cases without requiring to read any documentation.
> Regards,
>
> --
> Nicolas Mailhot
> ___
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
't think Fedora can afford to pass on Go and still stay relevant
server-side. That's even more true for Fedora downstreams and Fedora's main
sponsor.
So I guess it all boils down to strategic choices for Fedora and Red Hat:
invest in Go packaging, even if it *is* painful, or pass
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
e *are* lots of people that would like to do Go packaging. Many Go software
projects currently make headlines. That there are so few Go packagers in
Fedora, at the time Go is in the limelight, is a pretty good indicator we are
making it too hard.
> I don't see way how it makes it less pa
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 a
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
o stream of Fedora-originated
fixes, no Fedora pressure to stabilize parts when upstream is lost in tunnel
effect mode and does not realize that it is wasting everyone's time starting
with its own).
Therefore, trying to get all this it a better state, requires the following
steps IMHO:
1. comple
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
ections to
> propose, and so on.
>
> Then I will push it FPC side again.
>
> Actual practice should be fairly simple and self-explanatory, the proposal
> length can be scary but that's because it documents all kinds of corner cases
> that required digging through specs
imple and self-explanatory, the proposal
length can be scary but that's because it documents all kinds of corner cases
that required digging through specs and mailing lists to find resolution
examples before. The basic Go packaging skeleton will be sufficient is most
cases without requiri
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-
me is right (but do not
>> block on me!)
> If we are talking about EPEL6 stack, it is fairly fresh(1.9.2) and stable(it
> will be on 1.9 for whole of its
> upstream support), although Go packaging macros are missing.
Yes the core golang package is there but first the other Go mac
- 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 converte
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
irs so they don't trigger autodeps, and tries very
hard to own all relevant directories.
For those reasons I don't propose to activate autodeps in old-style golang
packages. They need conversion (and review by a human to check no problem
code is deployed) first.
So, if I understand correctly
- 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
>
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
- go-srpm-macros RFE with the technical files:
https://
On 10/02/2014 09:02 AM, Vincent Batts wrote:
> On 30/09/14 08:46 +0100, Richard W.M. Jones wrote:
>> How does gccgo affect the packaging of libraries?
>
> The libraries may have support for one or more versions of the go API,
> or exclusively one version. Since the gccgo support is usually an API
1 - 100 of 132 matches
Mail list logo
