Translating Go modules buildrequires in rpm syntax
by Nicolas Mailhot
Hi,
For Go modules, that will become the default upstream in August, Google
invented holed BuildRequires version ranges:
– anything starting with version
– except a list of specific version exclusions (not exclusion ranges,
specific versions)
Basically upstreams are allowed to declare incompatible versions, but
Google would really like them to keep ascendent API compatibility
(and Google requires module renaming on major version changes, so there
is no upper limit to the API compatibility)
Is the correct way to represent those in rpm:
BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0) and ((golang-module(github.com/stretchr/testify) < 1.3.2~0.20180906233101.161cd47e91fd) or (golang-module(github.com/stretchr/testify) > 1.3.2~0.20180906233101.161cd47e91fd)) and ((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1) or (golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and ((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1.0.20180628173108.788fd7840127) or (golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1.0.20180628173108.788fd7840127)))
or am I missing something obvious?
Best regards,
--
Nicolas Mailhot
5 years
Re: New Golang Packaging Guidelines: Feedback needed and appreciated
by Nicolas Mailhot
Le mercredi 27 mars 2019 à 19:13 +0000, David Dykstra a écrit :
Hi David,
>
> I'd like to see clarity on the guidelines for golang applications as
> opposed to golang libraries. It seems to assume from the start that
> it's talking about libraries, based on the package naming
> requirement.
From a technical POW and given how the Go world is structured a Golang
application is just another bundle of Go source code, that happens to
produce binaries.
So all the Go source code packaging guidelines apply as-is, except for
the srpm naming, and the fact that %build also produces binaries that
need to be deployed somewhere on the filesystem (but once compiled,
there is no specific difference between a Go or a C binary from a
packaging POW, so you won't find long Go-binary specific explanations
here).
--
Nicolas Mailhot
5 years, 1 month
New Golang Packaging Guidelines: Feedback needed and appreciated
by Robert-André Mauchin
Hello Fedora people,
As you may or may not know, currently applied Golang packaging guidelines
have always been simply a « draft ». Part of the new Go SIG mission is to
update ours best practices and tooling. As such, Nicolas Mailhot designed a
new set of macros based on lua script to improve our current situation. As a
result, we needed to draft new guidelines to reflect the future implementation
of these macros.
I have written these new guidelines and I'd like to ask for your help in
order to review them: both from current Go SIG packagers point of view and
from novices in the matter, in order to make sure they are clear and
understandable enough for everyone.
I have uploaded a mirror of the Guidelines on my FedoraPeople space:
https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
Please, if you have 10 mn to spare, read them and send me feedback. If you
wish you can also directly send me a Merge Request on Pagure:
https://pagure.io/fork/eclipseo/packaging-committee/ (branch
implement_golang_guidelines).
Best regards,
Robert-André
5 years, 1 month
.fc31~bootstrap - is this a feature or a bug?
by Miro Hrončok
Hi, I've just realized that %dist is defined to:
%{?distprefix}.fc30%{?with_bootstrap:~bootstrap}
That effectively means that using %bcond_without bootstrap, the dist is changed
to .fc31~bootstrap.
Is this something that we actually want? E.g. I was quite surprised by the behavior.
Reading https://pagure.io/packaging-committee/issue/818
gives me an impression that the packaging committee didn't really approve nor
forbid this, so I'm looking for recommendation.
When I bootstrap, should I manually bump the release number or let this magic
happen?
Also, how do I opt-out from this behavior (other than renaming my conditional)?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 1 month
Re: Packaging .c files in a non-devel package
by Dan Čermák
Hi Christophe,
since the .c files appear to be fundamental for the functionality of
make-it-quick, I'd rather silence this one specific check via an
rpmlintrc file instead of renaming them or converting this into a -devel
package.
Renaming them is probably a lot more work and calling it -devel will
confuse end users. Both are imho not worth it just for the sake of
silencing a single rpmlint warning.
Cheers,
Dan
Christophe de Dinechin <dinechin(a)redhat.com> writes:
> Hello,
>
>
> I’m currently working on a Fedora package for make-it-quick (https://github.com/c3d/make-it-quick), a make-only build system with basic auto-configuration.
>
> rpmlint complains about shipping .c files in a non -devel package. The package does contains several small .c files that are used for autoconfiguration.
>
> One option would be to rename the package as “make-it-quick-devel”, but that seems a bit redundant given that the whole point of the package is to be a development tool.
>
> Another option would be to rename the files to use some custom extension for configuration sources. But that seems more like obfuscation, and I don’t like doing that just to silence rpmlint.
>
> Can you suggest a good approach?
>
>
> Thanks
> Christophe de Dinechin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
5 years, 1 month
Help us test FedoraReview on Python 3
by Miro Hrončok
There is a FedoraReview port to Python 3 that needs real word testing by packagers.
When you use FedoraReview, please use the Python 3 port instead to help us find
bugs.
Instructions are at https://pagure.io/FedoraReview/pull-request/312 -> the first
comment of my Pull Request is updated with up to date instructions.
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 1 month
Summary/Minutes from today's FPC Meeting (2019-03-07 17:00 - 17:45 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 17:00:15 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-07/fpc.2019-03...
.
Meeting summary
---------------
* Roll Call (geppetto, 17:00:15)
* Schedule (geppetto, 17:05:18)
* LINK:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
(geppetto, 17:05:22)
* Open Floor (geppetto, 17:06:21)
* ACTION: Add pbokoc as committer to our repository for typos and
small tweaks (+1:5, 0:0, -1:0) (geppetto, 17:19:08)
* LINK:
https://docs.fedoraproject.org/en-US/modularity/making-modules/packaging-...
(ignatenkobrain, 17:19:37)
Meeting ended at 17:44:05 UTC.
Action Items
------------
* Add pbokoc as committer to our repository for typos and small tweaks
(+1:5, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Add pbokoc as committer to our repository for typos and small tweaks
(+1:5, 0:0, -1:0)
People Present (lines said)
---------------------------
* geppetto (35)
* tibbs (29)
* ignatenkobrain (27)
* zodbot (14)
* redi (10)
* mhroncok (7)
* decathorpe (6)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
5 years, 1 month
