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,
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?
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-03-28 16:00 UTC in #fedora-meeting-1 on irc.freenode.net.
Local time information (via. uitime):
================= Day: Thursday ==================
2019-03-28 09:00 PDT US/Pacific
2019-03-28 12:00 EDT --> US/Eastern <--
2019-03-28 16:00 GMT Europe/London
2019-03-28 16:00 UTC UTC
2019-03-28 17:00 CET Europe/Berlin
2019-03-28 17:00 CET Europe/Paris
2019-03-28 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2019-03-29 00:00 HKT Asia/Hong_Kong
2019-03-29 00:00 +08 Asia/Singapore
2019-03-29 01:00 JST Asia/Tokyo
2019-03-29 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
= Followups =
#topic #845 Wiki deprecation status
#topic #859 Scriptlet to replace a directory: try delete first?
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
Le mercredi 27 mars 2019 à 19:13 +0000, David Dykstra a écrit :
> 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
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
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
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:
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:
Hi, I've just realized that %dist is defined to:
That effectively means that using %bcond_without bootstrap, the dist is changed
Is this something that we actually want? E.g. I was quite surprised by the behavior.
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
Also, how do I opt-out from this behavior (other than renaming my conditional)?
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
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.
Christophe de Dinechin <dinechin(a)redhat.com> writes:
> 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?
> 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://email@example.com
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
Instructions are at https://pagure.io/FedoraReview/pull-request/312 -> the first
comment of my Pull Request is updated with up to date instructions.