Re: New Go Packaging Guidelines landed in rawhide (koji) today
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, July 6, 2019 8:39:12 AM Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today 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 > releases? It could be done for previous releases, if someone was motivated enough. The macro code itself works, with trivial adjustments, on ancient releases like EL7. But, it depends on things in redhat-rpm- config, so backporting would demand to convince redhat-rpm-config maintainers to backport too. Anyway this is pretty academic right now, I doubt anyone would accept a backport without synchronized backport of the whole Go packageset, and that can not happen before eclipso finishes to update the stack in devel. You have omitted that the new macros stack is not fully backwards compatible, so it would require more work on fixing the packages that are affected by the breakage(AFAIK a bit under ~100). IMHO it is not a good idea to back-port this to any stable Fedora release. That’s why I wrote that a macro backport, without the mass spec cleanup & fixing eclipseo is doing in devel right now, would not be a good idea. (fixing a clean spec to use the new macro stack takes a couple of minutes; fixing the warts that accumulated in Fedora for years because the tooling was not there is something else entirely) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
- 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 8:39:12 AM > Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today > > 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 > > releases? > > It could be done for previous releases, if someone was motivated > enough. The macro code itself works, with trivial adjustments, on > ancient releases like EL7. But, it depends on things in redhat-rpm- > config, so backporting would demand to convince redhat-rpm-config > maintainers to backport too. > > Anyway this is pretty academic right now, I doubt anyone would accept a > backport without synchronized backport of the whole Go packageset, and > that can not happen before eclipso finishes to update the stack in > devel. > > Regards, > > -- > Nicolas Mailhot You have omitted that the new macros stack is not fully backwards compatible, so it would require more work on fixing the packages that are affected by the breakage(AFAIK a bit under ~100). IMHO it is not a good idea to back-port this to any stable Fedora release. JC > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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 > releases? It could be done for previous releases, if someone was motivated enough. The macro code itself works, with trivial adjustments, on ancient releases like EL7. But, it depends on things in redhat-rpm- config, so backporting would demand to convince redhat-rpm-config maintainers to backport too. Anyway this is pretty academic right now, I doubt anyone would accept a backport without synchronized backport of the whole Go packageset, and that can not happen before eclipso finishes to update the stack in devel. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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 vast majority of > packages is easy to clean up (just adapt the templates in go-rpm- > templates or use go2rpm), it's just there is an awful lot of them, so > Robert-André Mauchin (eclipseo) can not do all of them in a single > pass. > DO NOT TOUCH ANY PACKAGES BEFORE I FINISH WITH F31-GO. Otherwise I'll need to rebase my git and it will be a PITA. All packages are being updated anyway. As for your Deepin packages, Robin, I have updated according to your work on COPR. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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 of > packages is easy to clean up (just adapt the templates in go-rpm- > templates or use go2rpm), it's just there is an awful lot of them, so > Robert-André Mauchin (eclipseo) can not do all of them in a single > pass. It's great to see that all this stuff is finally coming together. I've tried to fix some of my broken packages locally, but I had trouble getting go2rpm to run from the sources - because AFAICT, go2rpm isn't packaged for fedora yet. Is there anything blocking a package or has just nobody worked on it yet? Fabio > If you hit one of the cases where a project needs weird stuff, or if > you do not understand something, there is help available here and in > the #fedora-golang channel. > > Please just state here (or tell eclispeo directly) what you will > convert, so you do not end up doing the same work in parallel. > > Quite often, eclipseo will have prepared things in his copr, just not > built them in koji yet. > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/ > > So taking up from where he prepared, and checking the result builds in > koji and works for you, will accelerate things. > > @eclipseo: please correct if I wrote something that does not make > things easier your side > > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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 or use go2rpm), it's just there is an awful lot of them, so Robert-André Mauchin (eclipseo) can not do all of them in a single pass. If you hit one of the cases where a project needs weird stuff, or if you do not understand something, there is help available here and in the #fedora-golang channel. Please just state here (or tell eclispeo directly) what you will convert, so you do not end up doing the same work in parallel. Quite often, eclipseo will have prepared things in his copr, just not built them in koji yet. https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/ So taking up from where he prepared, and checking the result builds in koji and works for you, will accelerate things. @eclipseo: please correct if I wrote something that does not make things easier your side Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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’s > history, we will be able to perform Go package builds conforming to an > approved Fedora Packaging Guideline. > > Packaging documentation: > https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ > and approval: https://pagure.io/packaging-committee/issue/382 > The go-rpm-templates package provides more complete info. > > F31 change page: > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > and approval: https://pagure.io/fesco/issue/2120 > > While the guidelines will feel familiar to anyone who created a Fedora > Go packages in the last two years, they DO include a backwards- > incompatible change. Making GOPATH manipulation robust required moving > the corresponding logic to %prep with a new %goprep macro. > > Therefore, existing specs are expected to fail without the addition of > the %goprep call. > > This is of course not the end of the road, just a key step. > > It opens the way to a mass cleanup and refresh of the Fedora Go stack. > https://pagure.io/packaging-committee/issue/901 > > A preview of this refresh is available here: > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ > > Enormous thanks to > – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing > updating and cleaning-up all those packages, and to > – Elliott Sales de Andrade (Qulogic), that picked up maintenance of > golist and fixed many of its long-standing bugs and limitations. > > Many thanks to the mock, rpm and redhat-rpm-config maintainers, > that integrated the changes, we built upon (Igor Gnatenko, Florian > Festi, Miroslav Suchý, Panu Matilainen) > > The macro set supports Go DynamicBuildRequires > https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > They will be usable in mock as soon as rpm 4.15 lands > https://fedoraproject.org/wiki/Changes/RPM-4.15 > > Use in koji or copr will have to wait for the corresponding refresh > buldsystem-side. So this part of the change is a technology preview for > now. > > Best regards, > > -- > Nicolas Mailhot 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? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
- 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 rawhide (koji) today > > 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 is System Wide Change as it seems to affect (nearly) all > > Go based packages in distribution(and will require work/attention of > > people that are not change owners, actually not accounted for in > > change proposal). For past several releases I have been doing rebase > > of Go compiler change(yet to be filed for F31) that is IMHO > > comparable(maybe a bit smaller) in scope and they were always deemed > > by FESCO as System Wide Changes. This really leaves me > > confused. Could someone from FESCO clarify? > > https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says > > Examples include [...] a coordinated effort within a SIG with > > limited impact outside the SIG's functional area > > So in this case, even though the change affects so many packages, it > falls into the "self contained change" category. > > That said, the difference between "system-wide" and "self-contained" > boils down to two things: some additional data required in the change > page, and filing the change a bit earlier. In this case the additional > data is mostly there in the change page, and the change was filed early, > so even if we were to change the Change to "system-wide", the effect > would be cosmetic. > > Zbyszek Thank you for clarification :). IMO it would be great if that has been recorded in https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes, this approach can't be really inferred from it(at least I don't see it there). With that popped on my mind that may be calling it "early/late window change" would fit better along with recording the complexity of the change, rather then system wide, contained change. But this is really just my brain storm. Unfortunately no early changes for me as Golang release are aligned late in to the Fedora devel cycle. JC > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
- 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 Guidelines landed in rawhide (koji) today > > 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/Adopt_new_Go_Packaging_Guidelines#Summary > > “ This proposal consists of: > Packaging the new Go macros: go-rpm-macros > Getting the Guidelines approved by the FPC > Updating all Go libraries with the new macros > Mass-rebuilding all the Go package in a side tag ” > > You complain that step 3 and 4 are separate, but that’s how it was > planed from the start up and approved in the change page. > > You're conflating merging two mass Go package rebuilds (one for the new > Go compiler, and another for the new, and first, Go packaging > guidelines) with merging step 3 and 4 (which would have had other > drawbacks, that were never discussed, because that's not how we planed > things). > > And BTW it was already so in > https://pagure.io/GoSIG/go-sig/issue/20 6 months ago (though this page > is obsolete, you made us rewrite the plan in so many formats over time > I've lost track or what is up to date or not. The change page is up to > date, it’s the most recent rewrite) I guess that we have not agreed on the SIG meeting then. I don't complain and this is not in any ways personal, keep it on mind please. The change proposal predates that SIG discussion as other bit predates the change proposal. I'm pointing out that we could have avoided any breakage if we did few thing slightly differently. Currently by your actions there are several FTBFS packages, it is not really a serious issues(as I'm sure that eclipso will fix up all the packages that need it in time for Fedora 31, kudos for committing for that work :)) but it is unnecessary and avoidable inconvenience that I(and I guess others too) will have to account for(spend some time on). In my case preparing for Go rebase(I do scratch rebuilds). One of the points been also possibility to fit in the Go rebase in to that side tag, but after further discussion with eclipseo on Wednesday it will make more sense to use regular mass-rebuild for that(as I usually do) assuming that the side tag rebuild will conclude 1-2w prior to it(so I will be able to observe dist git in coherent shape). JC > > Sincerely, > > -- > Nicolas Mailhot > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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 is System Wide Change as it seems to affect (nearly) all > Go based packages in distribution(and will require work/attention of > people that are not change owners, actually not accounted for in > change proposal). For past several releases I have been doing rebase > of Go compiler change(yet to be filed for F31) that is IMHO > comparable(maybe a bit smaller) in scope and they were always deemed > by FESCO as System Wide Changes. This really leaves me > confused. Could someone from FESCO clarify? https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says > Examples include [...] a coordinated effort within a SIG with > limited impact outside the SIG's functional area So in this case, even though the change affects so many packages, it falls into the "self contained change" category. That said, the difference between "system-wide" and "self-contained" boils down to two things: some additional data required in the change page, and filing the change a bit earlier. In this case the additional data is mostly there in the change page, and the change was filed early, so even if we were to change the Change to "system-wide", the effect would be cosmetic. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
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/Adopt_new_Go_Packaging_Guidelines#Summary “ This proposal consists of: Packaging the new Go macros: go-rpm-macros Getting the Guidelines approved by the FPC Updating all Go libraries with the new macros Mass-rebuilding all the Go package in a side tag ” You complain that step 3 and 4 are separate, but that’s how it was planed from the start up and approved in the change page. You're conflating merging two mass Go package rebuilds (one for the new Go compiler, and another for the new, and first, Go packaging guidelines) with merging step 3 and 4 (which would have had other drawbacks, that were never discussed, because that's not how we planed things). And BTW it was already so in https://pagure.io/GoSIG/go-sig/issue/20 6 months ago (though this page is obsolete, you made us rewrite the plan in so many formats over time I've lost track or what is up to date or not. The change page is up to date, it’s the most recent rewrite) Sincerely, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New Go Packaging Guidelines landed in rawhide (koji) today
- 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 Packaging Guidelines landed in rawhide (koji) today > > Hi, > > 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), so there is no observable breakage(if any would occur) for package builds and all packages "just" pop in using new macros and following new guidelines. Currently following packages are FTBFS due to this change https://apps.fedoraproject.org/koschei/affected-by/go-srpm-macros?epoch1=0=2=19.fc30=0=3.0.8=3.fc31=f31 (thanks to qulogic for this query). And still we will have to do the side tag rebuild(for this change). We could have done that in one pass without causing any observable breakage for anyone. > 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 Guideline. > > Packaging documentation: > https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ > and approval: https://pagure.io/packaging-committee/issue/382 > The go-rpm-templates package provides more complete info. > > 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 is System Wide Change as it seems to affect (nearly) all Go based packages in distribution(and will require work/attention of people that are not change owners, actually not accounted for in change proposal). For past several releases I have been doing rebase of Go compiler change(yet to be filed for F31) that is IMHO comparable(maybe a bit smaller) in scope and they were always deemed by FESCO as System Wide Changes. This really leaves me confused. Could someone from FESCO clarify? > > While the guidelines will feel familiar to anyone who created a Fedora > Go packages in the last two years, they DO include a backwards- > incompatible change. Making GOPATH manipulation robust required moving > the corresponding logic to %prep with a new %goprep macro. > > Therefore, existing specs are expected to fail without the addition of > the %goprep call. When this has been discussed, new macros have been presented to me as backwards compatible(i.e. current packages will work and build as is, although requiring refresh to adopt new features), so it has not been concern for me. Other issue that I have is that you have not communicated this change(landing the new macro package) prior it happening here or elsewhere. I'm a Go SIG member(and maintainer of the previous macros packages, which by the way are still out there) and I have not been aware of this pending change landing now. > > This is of course not the end of the road, just a key step. I would much appreciate if you would communicate a bit more before landing such a big changes(go-rpm-package) in future, it would made possible to avoid some breakages, collect feedback and improve overall packagers experience. I think that communication is not easy, at least not for me, and I don't think that it is my strong skill, but we shouldn't resign on it as it is IMO crucial part of the Fedora community. Is there something that can I do to improve the information flow from my side? JC > > It opens the way to a mass cleanup and refresh of the Fedora Go stack. > https://pagure.io/packaging-committee/issue/901 > > A preview of this refresh is available here: > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ > > Enormous thanks to > – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing > updating and cleaning-up all those packages, and to > – Elliott Sales de Andrade (Qulogic), that picked up maintenance of > golist and fixed many of its long-standing bugs and limitations. > > Many thanks to the mock, rpm and redhat-rpm-config maintainers, > that integrated the changes, we built upon (Igor Gnatenko, Florian > Festi, Miroslav Suchý, Panu Matilainen) > > The macro set supports Go DynamicBuildRequires > https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > They will be usable in mock as soon as rpm 4.15 lands > https://fedoraproject.org/wiki/Changes/RPM-4.15 > > Use in koji or copr will have to wait for the corresponding refresh > buldsystem-side. So this part of the change is a te
New Go Packaging Guidelines landed in rawhide (koji) today
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 Guideline. Packaging documentation: https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ and approval: https://pagure.io/packaging-committee/issue/382 The go-rpm-templates package provides more complete info. F31 change page: https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines and approval: https://pagure.io/fesco/issue/2120 While the guidelines will feel familiar to anyone who created a Fedora Go packages in the last two years, they DO include a backwards- incompatible change. Making GOPATH manipulation robust required moving the corresponding logic to %prep with a new %goprep macro. Therefore, existing specs are expected to fail without the addition of the %goprep call. This is of course not the end of the road, just a key step. It opens the way to a mass cleanup and refresh of the Fedora Go stack. https://pagure.io/packaging-committee/issue/901 A preview of this refresh is available here: https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ Enormous thanks to – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing updating and cleaning-up all those packages, and to – Elliott Sales de Andrade (Qulogic), that picked up maintenance of golist and fixed many of its long-standing bugs and limitations. Many thanks to the mock, rpm and redhat-rpm-config maintainers, that integrated the changes, we built upon (Igor Gnatenko, Florian Festi, Miroslav Suchý, Panu Matilainen) The macro set supports Go DynamicBuildRequires https://fedoraproject.org/wiki/Changes/DynamicBuildRequires They will be usable in mock as soon as rpm 4.15 lands https://fedoraproject.org/wiki/Changes/RPM-4.15 Use in koji or copr will have to wait for the corresponding refresh buldsystem-side. So this part of the change is a technology preview for now. Best regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines
- 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 Go Packaging > Guidelines > > 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 of new > RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to > formally adopt new Go Packaging Guidelines, which aim at automation, > reliability > and simplicity. > > == Owner == > * Name: [[User:eclipseo| Robert-André Mauchin]] > * Name: [[User:jcajka| Jakub Cajka]] Hello, as much as this change proposal excites me and I'm looking forward to it. I'm unfortunately currently not able to own this change, regardless as much I would really like to. I would also like to note that I have been added as owner arbitrarily, without notice and without my consent and therefore I would like to be removed from the owner list. Thanks. > * Name: [[User:nim| Nicolas Mailhot]] > * Name: [[User:qulogic| Elliott Sales de Andrade]] > > * Email: > > > == Detailed Description == > > Over 775 Go packages are currently residing in Fedora's repositories, yet no > formal guidelines have ever been approved. As a result, the various Go SPECs > are > inconsistent and most often outdated. Moreover, the next version of Go, 1.13, > will introduce the concept of modules by default, which will completely > change > how Go libraries are distributed. With the current state of our tooling, the > Go > SIG is not prepared to face such a drastic change. > > [[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which > will allow us to disconnect the upstream Go tooling from the downstream > integration inside RPM. This will allow us to adapt easily to future upstream > changes without the need to rewrite our SPEC catalogue. > > == Benefit to Fedora == > > * Simplicity: SPEC files are simpler, less error-prone > * Automation: the new macros computes packages definition, Requires, > Provides and has provision for the new automated BuildRequires > * Standardization of SPEC files across the Go library > * Drastic reduction of boilerplate and SPEC size > * Automatic removal of vendored code > * Ease of testing: all units tests are detected and run > * Ease of upkeep > * Ease of adaptation to upstream changes > > == Scope == > > * Proposal owners: > ** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51 > Get the last macros approved in ''redhat-rpm-config''] > ** Get ''[https://pagure.io/golist golist]'', the tool detecting > dependencies, updated and split from the > ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' > package > ** Release ''GOPATH'' directory ownership from the > ''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it > can be managed by the ''[https://pagure.io/go-rpm-macros > go-rpm-macros]'' package > ** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and > reviewed > ** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros > go-srpm-macros]'' and > ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' > ** Port existing Go packages to the new macros (it probably won't be > finished by [[Releases/31 | Fedora 31]]) > > * Other developers: N/A (not a System Wide Change) > I believe this affects all packagers maintaining Go based packages as they should update their packages up to the new standard, so we don't fragment the package base. So IMO this should be system wide change. JC > > * Policies and guidelines: > [https://pagure.io/packaging-committee/pull-request/883 Get the Go > packaging guidelines approved by the Packaging Committee] > > == Upgrade/compatibility impact == > > No compatibility impact is expected. All the new macros are backward > compatible > with the old ones. > > == How To Test == > > The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/ > nim/macros-ng] > can be used to test the new macros on Rawhide. Sample SPEC files are > available > in the FPC Guidelines proposal. > > == User Experience == > > The user impact is minimal or nil. As a result of the simplification of SPEC > files, we may ship updated libraries more quickly, and it may be easier for > new > contributors to package Go applications. > > == Depen
Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines
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 of new RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to formally adopt new Go Packaging Guidelines, which aim at automation, reliability and simplicity. == Owner == * Name: [[User:eclipseo| Robert-André Mauchin]] * Name: [[User:jcajka| Jakub Cajka]] * Name: [[User:nim| Nicolas Mailhot]] * Name: [[User:qulogic| Elliott Sales de Andrade]] * Email: == Detailed Description == Over 775 Go packages are currently residing in Fedora's repositories, yet no formal guidelines have ever been approved. As a result, the various Go SPECs are inconsistent and most often outdated. Moreover, the next version of Go, 1.13, will introduce the concept of modules by default, which will completely change how Go libraries are distributed. With the current state of our tooling, the Go SIG is not prepared to face such a drastic change. [[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which will allow us to disconnect the upstream Go tooling from the downstream integration inside RPM. This will allow us to adapt easily to future upstream changes without the need to rewrite our SPEC catalogue. == Benefit to Fedora == * Simplicity: SPEC files are simpler, less error-prone * Automation: the new macros computes packages definition, Requires, Provides and has provision for the new automated BuildRequires * Standardization of SPEC files across the Go library * Drastic reduction of boilerplate and SPEC size * Automatic removal of vendored code * Ease of testing: all units tests are detected and run * Ease of upkeep * Ease of adaptation to upstream changes == Scope == * Proposal owners: ** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51 Get the last macros approved in ''redhat-rpm-config''] ** Get ''[https://pagure.io/golist golist]'', the tool detecting dependencies, updated and split from the ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' package ** Release ''GOPATH'' directory ownership from the ''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it can be managed by the ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' package ** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and reviewed ** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros go-srpm-macros]'' and ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' ** Port existing Go packages to the new macros (it probably won't be finished by [[Releases/31 | Fedora 31]]) * Other developers: N/A (not a System Wide Change) * Policies and guidelines: [https://pagure.io/packaging-committee/pull-request/883 Get the Go packaging guidelines approved by the Packaging Committee] == Upgrade/compatibility impact == No compatibility impact is expected. All the new macros are backward compatible with the old ones. == How To Test == The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/ nim/macros-ng] can be used to test the new macros on Rawhide. Sample SPEC files are available in the FPC Guidelines proposal. == User Experience == The user impact is minimal or nil. As a result of the simplification of SPEC files, we may ship updated libraries more quickly, and it may be easier for new contributors to package Go applications. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: If the required packages are not merged by the deadline target, or if the Guidelines are not approved, we may continue with our current set of non-approved practices. No other impact is expected. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No * Blocks product? No == Documentation == The FPC Guidelines proposal is available on [https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ eclipseo personal space]. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines
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 of new RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to formally adopt new Go Packaging Guidelines, which aim at automation, reliability and simplicity. == Owner == * Name: [[User:eclipseo| Robert-André Mauchin]] * Name: [[User:jcajka| Jakub Cajka]] * Name: [[User:nim| Nicolas Mailhot]] * Name: [[User:qulogic| Elliott Sales de Andrade]] * Email: == Detailed Description == Over 775 Go packages are currently residing in Fedora's repositories, yet no formal guidelines have ever been approved. As a result, the various Go SPECs are inconsistent and most often outdated. Moreover, the next version of Go, 1.13, will introduce the concept of modules by default, which will completely change how Go libraries are distributed. With the current state of our tooling, the Go SIG is not prepared to face such a drastic change. [[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which will allow us to disconnect the upstream Go tooling from the downstream integration inside RPM. This will allow us to adapt easily to future upstream changes without the need to rewrite our SPEC catalogue. == Benefit to Fedora == * Simplicity: SPEC files are simpler, less error-prone * Automation: the new macros computes packages definition, Requires, Provides and has provision for the new automated BuildRequires * Standardization of SPEC files across the Go library * Drastic reduction of boilerplate and SPEC size * Automatic removal of vendored code * Ease of testing: all units tests are detected and run * Ease of upkeep * Ease of adaptation to upstream changes == Scope == * Proposal owners: ** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51 Get the last macros approved in ''redhat-rpm-config''] ** Get ''[https://pagure.io/golist golist]'', the tool detecting dependencies, updated and split from the ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' package ** Release ''GOPATH'' directory ownership from the ''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it can be managed by the ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' package ** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and reviewed ** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros go-srpm-macros]'' and ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]'' ** Port existing Go packages to the new macros (it probably won't be finished by [[Releases/31 | Fedora 31]]) * Other developers: N/A (not a System Wide Change) * Policies and guidelines: [https://pagure.io/packaging-committee/pull-request/883 Get the Go packaging guidelines approved by the Packaging Committee] == Upgrade/compatibility impact == No compatibility impact is expected. All the new macros are backward compatible with the old ones. == How To Test == The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/ nim/macros-ng] can be used to test the new macros on Rawhide. Sample SPEC files are available in the FPC Guidelines proposal. == User Experience == The user impact is minimal or nil. As a result of the simplification of SPEC files, we may ship updated libraries more quickly, and it may be easier for new contributors to package Go applications. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: If the required packages are not merged by the deadline target, or if the Guidelines are not approved, we may continue with our current set of non-approved practices. No other impact is expected. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No * Blocks product? No == Documentation == The FPC Guidelines proposal is available on [https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ eclipseo personal space]. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Go packaging guidelines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/14/2014 02:18 PM, Matthew Miller wrote: On Tue, Jan 14, 2014 at 12:06:09PM +0100, Florian Weimer wrote: A couple of questions and comments. I think overall, the approach works. # Packaging Libraries This does not mention libraries which use cgo. Should they be handled the same way? What about additional C wrappers? I think for now, yes. Unless you have a better suggestion. # Security in Go Language Packages The repoquery invocations for checking for affected programs are incorrect because the archive may have evolved from the time the binary Go program has been built and no longer reflect those dependencies. The non-stripped nature of binaries should make it possible to see, based on the binaries alone, which libraries were used to compile it. Hmmm, okay. Would it be useful to have a script that generates a list automatically? On the other hand, I wonder if we should rebuild all dependent binary Go programs each time any of the libraries used to build it change. This ensure that we ship matching source code for the compiled binary, and it causes any breakage sooner. I'm worried that that would cause a lot of needless churn. But maybe it's for the best. I have added some go bindings for libselinux, which are used in the docker port. Currently I am shipping these in libselinux-devel. # rpm -q libselinux-devel libselinux-devel-2.2.2-2.fc21.x86_64 # rpm -ql libselinux-devel | grep go /usr/share/gocode/src/selinux /usr/share/gocode/src/selinux/selinux.go Is the correct way for C libraries that we ship to provide go bindings? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLegL0ACgkQrlYvE4MpobMumgCffnGnOxQr05KJ434TVzdG3XjH WW0Anj/bV06DBh6T/ZK+83q5PsAlsdJN =sqgm -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On Tue, Jan 21, 2014 at 09:14:21AM -0500, Daniel J Walsh wrote: # rpm -ql libselinux-devel | grep go /usr/share/gocode/src/selinux /usr/share/gocode/src/selinux/selinux.go Is the correct way for C libraries that we ship to provide go bindings? libguestfs has shipped go bindings in Fedora for 7 months. We do it in a separate package which looks like this: $ repoquery -ql golang-guestfs /usr/lib64/golang/pkg/linux_amd64/libguestfs.org /usr/lib64/golang/pkg/linux_amd64/libguestfs.org/guestfs /usr/lib64/golang/src/pkg/libguestfs.org /usr/lib64/golang/src/pkg/libguestfs.org/guestfs /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_010_load_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_020_create_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_030_create_flags_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_040_create_multiple_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_050_handle_properties_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_060_explicit_close_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_070_optargs_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_100_launch_test.go /usr/lib64/golang/src/pkg/libguestfs.org/guestfs/guestfs_900_rstringlist_test.go /usr/share/doc/golang-guestfs /usr/share/doc/golang-guestfs/LICENSE /usr/share/doc/golang-guestfs/create-disk.go /usr/share/doc/golang-guestfs/inspect-vm.go /usr/share/man/man3/guestfs-golang.3.gz It's on my to-do list to take a look at the updated packaging draft to see how close we are to it. We matched the old packaging draft correctly at the time that I added the bindings. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On 01/13/2014 04:11 PM, H. Guémar wrote: there's a draft, i suggest that you start checking it. http://fedoraproject.org/wiki/PackagingDrafts/Go A couple of questions and comments. I think overall, the approach works. # Packaging Libraries This does not mention libraries which use cgo. Should they be handled the same way? What about additional C wrappers? # Libraries and Arch Is it really a good idea to hard-code the list of supported architectures in spec files? Is there a way to avoid this? # Security in Go Language Packages The repoquery invocations for checking for affected programs are incorrect because the archive may have evolved from the time the binary Go program has been built and no longer reflect those dependencies. The non-stripped nature of binaries should make it possible to see, based on the binaries alone, which libraries were used to compile it. On the other hand, I wonder if we should rebuild all dependent binary Go programs each time any of the libraries used to build it change. This ensure that we ship matching source code for the compiled binary, and it causes any breakage sooner. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On 01/14/2014 01:06 PM, Florian Weimer wrote:
On 01/13/2014 04:11 PM, H. Guémar wrote:
there's a draft, i suggest that you start checking it.
http://fedoraproject.org/wiki/PackagingDrafts/Go
A couple of questions and comments. I think overall, the approach works.
# Packaging Libraries
This does not mention libraries which use cgo. Should they be handled
the same way? What about additional C wrappers?
# Libraries and Arch
Is it really a good idea to hard-code the list of supported
architectures in spec files? Is there a way to avoid this?
The de facto standard way is adding a lang-arch macro to
redhat-rpm-config, for example:
[pmatilai@mursu ~]$ cat /etc/rpm/macros.ocaml-srpm
# arches that ocaml runs on
%ocaml_arches alpha %{arm} %{ix86} ia64 x86_64 ppc sparc sparcv9 ppc64
[pmatilai@mursu ~]$ cat /etc/rpm/macros.ghc-srpm
# macro defining the archs that ghc runs on in fedora
%ghc_arches %{ix86} x86_64 ppc ppc64 alpha sparcv9 armv7hl armv5tel s390
s390x
%ghc_arches_with_ghci %{ix86} x86_64 ppc sparcv9 armv7hl armv5tel
[pmatilai@mursu ~]$ cat /etc/rpm/macros.mono-srpm
# arches that mono builds on
%mono_arches %{ix86} x86_64 sparc sparcv9 ia64 %{arm} alpha s390x ppc ppc64
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On Tue, Jan 14, 2014 at 12:06:09PM +0100, Florian Weimer wrote: A couple of questions and comments. I think overall, the approach works. # Packaging Libraries This does not mention libraries which use cgo. Should they be handled the same way? What about additional C wrappers? I think for now, yes. Unless you have a better suggestion. # Security in Go Language Packages The repoquery invocations for checking for affected programs are incorrect because the archive may have evolved from the time the binary Go program has been built and no longer reflect those dependencies. The non-stripped nature of binaries should make it possible to see, based on the binaries alone, which libraries were used to compile it. Hmmm, okay. Would it be useful to have a script that generates a list automatically? On the other hand, I wonder if we should rebuild all dependent binary Go programs each time any of the libraries used to build it change. This ensure that we ship matching source code for the compiled binary, and it causes any breakage sooner. I'm worried that that would cause a lot of needless churn. But maybe it's for the best. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Go packaging guidelines?
Hi all, Long time ago I submitted a package written in go, then we found that no guidelines at that moment, it's hard to review it properly. Now since docker and many golang tools are accepted in Fedora, can someone prepare a guideline for Go? I got some ideas from SUSE's, but not sure if it's accurate for Fedora. Thanks. -- Yours sincerely, Christopher Meng Noob here. http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
Hi, there's a draft, i suggest that you start checking it. http://fedoraproject.org/wiki/PackagingDrafts/Go Taking a peek at Debian and OpenSuSE Go guidelines might be worthy: http://pkg-go.alioth.debian.org/packaging.html http://en.opensuse.org/openSUSE:Packaging_Go Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
My apologies for linking opensuse guidelines, i missed that point in your mail. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On Mon, Jan 13, 2014 at 04:11:23PM +0100, H. Guémar wrote: there's a draft, i suggest that you start checking it. http://fedoraproject.org/wiki/PackagingDrafts/Go Taking a peek at Debian and OpenSuSE Go guidelines might be worthy: http://pkg-go.alioth.debian.org/packaging.html http://en.opensuse.org/openSUSE:Packaging_Go We tried to match the Debian practices in drafting our Go guidelines. SUSE uses macros heavily, so without detangling that I'm not actually sure exactly what they're doing. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
On Mon, Jan 13, 2014 at 04:39:10PM +0100, H. Guémar wrote: As far as i'm concerned, the draft is good enough to be submitted to the FPC. Still, i'm not confident enough in my go skills to suggest it :) Me either, but I won't let that stop me. https://fedorahosted.org/fpc/ticket/382 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
