The issue: `%goprep should apply patches automatically` of project:
`go-rpm-macros` has been assigned to `nim` by nim.
https://pagure.io/go-rpm-macros/issue/3
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim reported a new issue against the project: `golist` that you are following:
``
The last stage of rpm packaging is copying a clean final copy of all the files
that will be shipped in an arborescence under a `%{buildroot}` prefix.
That is the deployment tree that is operated on to compute the
nim added a new comment to an issue you are following:
``
And of course the nice thing of using documented rpm variables instead of
macro-specific switches, is that any other macro can read the same variables
and implement some other smarter form of processing, without requiring argument
nim reported a new issue against the project: `golist` that you are following:
``
golist fails to output project go files on github.com/rubiojr/go-vhd
```sh
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NZHyXq
+ umask 022
+ cd /builddir/build/BUILD
+ '['
nim reported a new issue against the project: `golist` that you are following:
``
This is a continuation and modernization of
https://github.com/gofed/go-macros/issues/35
When bootstrapping a set of Go projects, with circular dependencies, you need
to identify quickly the parts that
nim reported a new issue against the project: `golist` that you are following:
``
Migrated from https://github.com/gofed/symbols-extractor/issues/158
When I use golist in the project cloud.google.com/go, the commands
```sh
golist --imported --package-path cloud.google.com/go --skip-self
golist
nim added a new comment to an issue you are following:
``
Yes that's what this issue is about: fixing golist so we can kill the compat
package (or better not have to create it at all).
It is hidden in the golist binary we currently use because it vendors its deps
(among other bad bad things).
nim reported a new issue against the project: `golist` that you are following:
``
```sh
$ golist --imported --package-path github.com/sirupsen/logrus --skip-self
--tests
```
only outputs
```
github.com/stretchr/testify/assert
```
for sirupsen logrus, when the terminal_check_notappengine.go
nim reported a new issue against the project: `golist` that you are following:
``
Issue migrated from https://github.com/gofed/symbols-extractor/issues/157
This is from the mock build log:
```sh
+ go-rpm-integration check -i github.com/syncthing/notify -p
nim reported a new issue against the project: `golist` that you are following:
``
golist 9f4330a, built on x86_64 with
https://koji.fedoraproject.org/koji/buildinfo?buildID=1139757 crashes when
processing github.com/kr/pretty 0.1.0
It should not do that
```sh
+ cd pretty-0.1.0
+
nim reported a new issue against the project: `golist` that you are following:
``
It would be awfully nice if `golist` had a mode that outputed, for every path
that can be built as a binary:
* the buildable path
* a separator that can not occur in paths
* the expected command output name (via
The issue: `-devel subpackage is build tag specific` of project:
`go-rpm-macros` has been assigned to `nim` by nim.
https://pagure.io/go-rpm-macros/issue/1
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim reported a new issue against the project: `go-rpm-macros` that you are
following:
``
This is a clone of
https://github.com/gofed/go-macros/issues/56
The problem is actually in golist, not in the macros themselves. Sticking it in
the macro project for now as they need to be switched to
nim reported a new issue against the project: `golist` that you are following:
``
This is a similar issue to https://pagure.io/golist/issue/3 this time for
packagers that try to package several import paths in a single spec (I’m told
the practice is common RHEL-side).
For this use pattern to
nim added a new comment to an issue you are following:
``
Therefore, building golist as it is coded today requires the creation of a
compat package, for a gopkg.in/urfave/cli.v1 version released in 29 Aug 2016,
and not longer supported upstream
``
To reply, visit the link below or just reply
nim reported a new issue against the project: `golist` that you are following:
``
Right now `golist` does not permit querying the imports of a project and its
tests in a single pass. You can emulate most of it with two separate commands:
```sh
golist --imported --package-path
The issue: `golist processing is arch and tag-specific` of project: `golist`
has been assigned to `jcajka` by nim.
https://pagure.io/golist/issue/2
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
nim reported a new issue against the project: `golist` that you are following:
``
This is the root cause behind
https://pagure.io/go-rpm-macros/issue/1
When asked to list the files to deploy, golist only answers for the current
tags (arch and build options)
The issue: `golist relies on an obsolete release of gopkg.in/urfave/cli.v1
(1.18) and does not work with the current one (1.20)` of project: `golist` has
been reset by nim.
https://pagure.io/golist/issue/1
___
golang mailing list --
nim reported a new issue against the project: `golist` that you are following:
``
golist relies on an obsolete release of gopkg.in/urfave/cli.v1 (1.18) and does
not work with the current one (1.20)
+ go build -buildmode pie -compiler gc '-tags=rpm_crashtraceback ' -ldflags '
-X
nim reported a new issue against the project: `go-rpm-macros` that you are
following:
``
The macro code needs massaging to also work on EPEL.
Most of the work is spec side since some of the macros are going to collide
with the ones provided by previous iterations of Go macro packages
``
To
not propagate, they only apply in BuildRequires, not
Requires
(I'm curious how that will work out in practice, it feels too clever by
half, I don't see real-world devs understanding the implications, but
I’ll be happy to be proven wrong)
--
Nicolas Mailhot
_
Le 2019-04-02 15:11, Robert-André Mauchin a écrit :
On Tuesday, 2 April 2019 13:27:09 CEST Nicolas Mailhot wrote:
Le 2019-04-02 12:52, Jakub Cajka a écrit :
> I might have not been clear, sorry. My point is more that we don't
> need to recreate/capture the constrains in the spec fil
Le 2019-04-02 14:51, Jakub Cajka a écrit :
- Original Message -
From: "Nicolas Mailhot"
To: "Discussion of RPM packaging standards and practices for Fedora"
Cc: golang@lists.fedoraproject.org, "Jakub Cajka"
Sent: Tuesday, April 2, 2019 1:27:09 PM
Subj
anyway.
ie builds will fail because the build environment is not populated
correctly. It'd rather populate it automatically and correctly by
default than wait for builds to fail and then spend time on manual
workarounds because the tooling does not help me.
--
Nicolas Mailhot
not “I don't want to look at other versions” stuff
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code
oduces 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
___
gola
Le 2019-03-27 10:25, fge...@gmail.com a écrit :
On 3/27/19, 'Nicolas Mailhot' via golang-dev
wrote:
...
Anyway here is the code, not finished, not feature-complete, very
lightly tested, but already doing some useful things
https://pagure.io/modist/
...
And I should have added, the readme
Le 2019-03-26 20:42, Nicolas Mailhot a écrit :
Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
Le 2019-03-13 20:33, thepudds1...@gmail.com a écrit :
>
> However, even in advance of that, I have seen different people put
> together one-off shell scripts or similar that ar
Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit :
> Le 2019-03-13 20:33, thepudds1...@gmail.com a écrit :
> >
> > However, even in advance of that, I have seen different people put
> > together one-off shell scripts or similar that are capable of
> > pu
eed revisiting since in-place won't work with go
modules (will probably force every upstream to move their doc files to
the project root or in a specific documentation subdir, unless they
expect the readers to unzip the module files to access documentation)
Regards,
lear you should
try to avoid using them).
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-
t regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject
t fix the consequences of past errors, just
prevent new ones
² And, jchaloup had facilities others do not have (working @rh, trusted
by the Fedora golang maintainer, owning many key packages).
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fed
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guideli
Le 2019-03-13 03:24, Ian Denhardt a écrit :
Quoting Nicolas Mailhot (2019-03-12 04:22:45)
> In a parallel thread, a Nix developer was asking about basically the
> same use case, and was pointed at `go build -mod=vendor`. It seems like
> this does exactly what is wanted here --
Le 2019-03-11 19:18, Ian Denhardt a écrit :
Quoting Matthew Dempsky (2019-03-11 13:54:07)
On Mon, Mar 11, 2019 at 8:01 AM Nicolas Mailhot
<[1]nicolas.mail...@laposte.net> wrote:
And as I have explained in the detailed description Matthew
requested,
To be clear, I was
of modules, not the ones upstream found on
the Internet.
In fact, I'm pretty sure we will start each build by removing the
upstream go.sum file altogether.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
ns and expect it to build.
And as I have explained in the detailed description Matthew requested,
our construction of the CI/CD environment is incremental, so the
assumption in the go tool code that "everything is there and it it is
not it can be downloaded dire
Le vendredi 08 mars 2019 à 18:01 -0800, Matthew Dempsky a écrit :
> On Fri, Mar 8, 2019 at 4:52 PM 'Nicolas Mailhot' via golang-dev <
> golang-...@googlegroups.com> wrote:
> > It would be nice if it where true. Unfortunately even a simple
> > command
> > like tell me
Le vendredi 08 mars 2019 à 10:28 -0500, Russ Cox a écrit :
> On Fri, Mar 8, 2019 at 8:09 AM 'Nicolas Mailhot' via golang-dev <
> golang-...@googlegroups.com> wrote:
> > The notary part of Go modules, like the rest of the module
> > implementation, suffers from
t direct server hash lookups).
And I’ll stop here before I write things I will regret later.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fe
ore I write things I will regret later.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-
ting
packaging guidelines
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
group.
>
> Ed Marshall (logic) already joined us and have contributed his
> packages.
Thanks a lot, that's wonderful news!
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...
*shrug* at this point I don't care, feel free to
write something better if you want. The Go code is small and trivial.
Regards,
¹ https://github.com/rpm-software-management/mock/issues/160
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproje
, and they don't leave a transcript that can be used by
people who missed the meeting (or just to refresh one's memory after a
few months).
So my preference would be to any form of text-based system with archived
transcripts
Regards,
--
Nicolas Mailhot
Le 2018-08-28 13:27, Neal Gompa a écrit :
On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot
wrote:
However, my initial objectives were to produce clean prometheus and
grafana Fedora packages, I finished the Go part a few months ago, but
they both include a javascript layer, so I'll probably
who did a huge part of the
work).
But sure, I'll make a pass to check if it contains references to stuff
that turned out slightly differently than the initial plan
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
rate programming languages.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidel
m/issues/104 and
https://github.com/rpm-software-management/mock/issues/160
This is actually quite simple and fast as long as you do not hit API
breaks or projects with scores of tests to check (or broken tests:().
It was a lot more difficult and long before the macros were finalized.
Regards,
Le 2018-03-06 11:49, Jakub Cajka a écrit :
- Original Message -
From: "Nicolas Mailhot"
3. it is *way* simpler with dynamic linking where all the objects are
nicely separated, in different packages, with separate documentation,
and legal analysis can be made at the time yo
omponents, and if you do vendor don't include the vendored files
in you git repo, just the vendor config file.
But do ask spot or fedoral-legal when in doubt.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubsc
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). Heartfel
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
De: "Jan Chaloupka"
Hi Jan
Apologies for the delayed answer, I was beating the PR into shape to address
review comments.
> Let's keep moving forward,
> improving the infrastructure for other folks and pushing new ideas and
> improvements into practical solutions.
Let's move forward, I'm
that version their import paths, and make sure to only
extend their APIS within a major release, could be libified today
(theoretically, I've not checked how to do it). I'm not sure there are enough
of them to be worth multiple packaging style
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
By default, the standard golang compiler produces static libraries. There is
little value in shipping these prebuilt, especially since these libraries are
very specifically tied to the exact minor release of the golang compiler."
"Presently the shared object
t; do all the bidding.
Sure, the changes will only remove some barriers to new Go packagers, they
can't replace those packagers, or the people who take care of the baseline core.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedo
apps, but never
this year, because upstream state is not conflict and compat-free yet.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
- 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 respe
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
events them from
working as much a they'd like to on updating their packages. It's a death
spiral. It results in a massively obsolete Go package baselines, full of holes,
because all the energy is poured in making existing stuff work, at the expense
of onboarding new packages and packagers.
Rega
ompat packages to the minimum amount, and
the minimum period, but you can not fully avoid them, once an ecosystem has
grown enough it is too big to be perfectly coordinated all the time.
So making compat creation easy and fast, is required to manage a huge amount of
interdependent packages, whic
like a major step forward!
Please finish reading it and propose all the fixes and comments and
improvements you want! Your experience is appreciated.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
API break
to manage yet because their use of vendoring hid the problem.
Of course that supposes that creating a compat package does not add a
significant package-creation burden. Which I *did* try to avoid.
Organization-wise Go will still need a form of exempt
overkill, given how lax Go projects are about maintaining API
stability.
And then in case of breakage, revert or create a compat package. That's why
there is a long chapter dedicated to compat package creation in the proposed
guidelines.
Regards,
--
Nicolas Mailhot
___
uld take about as much work to solve by auditing the
vendored code manually.
Regards,
--
Nicolas mAilhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
any documentation.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
your_software_third-party-friendly
It can be moved later wherever you feel is more appropriate
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
ilable in EL6, it depends on
little except the lua built in rpm, and can be useful as-is, while the Go part
is something else entirely, as its utility is directly linked to the quantity
and freshness of Go software packages in the distro.
Regards,
--
Nicolas Mailhot
- Mail original -
De: "Jason L Tibbitts III"
>>>>> "nm" == nicolas mailhot <nicolas.mail...@laposte.net> writes:
>nm> And the forge macros are now available since
>nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstre
- 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
___
golang mailing list -- gola
ples
Ah, yes the examples snip the lines that do not need specific changes for
readability
Is the … not clear enough?
I fear that putting a full preamble would be even more confusing for some
readers. Though if people disagree, I'l try to find some time to add the
skipped lines back in
--
Nicola
hairy (deploying
without autodeps should be trivial however)
To be honest, given all the parts current packages fail to install, I'd expect
many of the current unit test packages to fail in mysterious ways, so I'm
curious: what use has been found for them?
Regards,
--
fc
%gometa
%global common_description %{expand:
Socket address convenience functions for Go. go-sockaddr is a convenience
library…}
Name:%{goname}
Version: 0
Release: 0.14%{?dist}
Summary: A Go convenience library to manipulate IP Addresses and UNIX sockets
License: MPLv2.0
URL: %{
pm-macros now so everyone can play
with them
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
n 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.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
ant
Not calling %gometa at all will kill stuff like goname which is kind of
mandatory for consistency.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
reating and updating Go
packages trivial. The time consuming phase is build log analysis (especially to
sort what unit tests are relevant and what unit tests can not work in a mock
env).
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@l
- Mail original -
De: "Jakub Cajka" <jca...@redhat.com>
À: golang@lists.fedoraproject.org
Envoyé: Mardi 16 Janvier 2018 10:16:19
Objet: Re: F28 System Wide Change: Golang 1.10a
>>> De: "Jakub Cajka"
>> From: "nicolas mailhot"
>
MiB compressed with xz -9). Did you not
receive them ?
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
>De: "Jakub Cajka"
>> From: "nicolas mailhot"
> I'm not generally blaming it on outdated packages(although there are some),
> I'm mostly blaming it > on code that is not following best coding
> practices(https://tip.golang.org/doc/go1.10#test)
suspect some of the packages that pass in your tests are
obsolete code with disabled unit tests so you're not seeing all the problems.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email
, they take around 100 MiB each uncompressed
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Hi Jakub
I'm not sure if the package exists in devel, of if we're unbundling it from
some other package, or if we're executing unit tests previously ignored
The core dump does not stop the package build
Will investigate some more…
Regards,
--
Nicolas Mailhot
fix: Updated 0 CRC32s, 1 CRC32s did match.
in golang-github-hashicorp-discover
Any idea if it's due to Go 1.10 or another fedora-devel change?
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an em
someone to fix the EL7 toolchain.
Anyway, with the latest changes, we don't hit the EL7 bug anymore so spectool
also works in EL7
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an ema
, and completely new packages.
I hope posting the second part of the automation will answer some questions
people had on the
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft
Regards,
--
Nicolas Mailhot
___
golang mailing
, and completely new packages.
I hope posting the second part of the automation will answer some questions
people had on the
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft
Regards,
--
Nicolas Mailhot
___
golang mailing
t to understand or adapt. I'm sure the
mediawiki markup dedicated to GitHub in our guidelines is actually longer
(plus, it does not work and it is not applied consistently)
It could be condensed by removing error handling, but what would be the point.
-hosted_projects_packaging_automation draft
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
hat apply at different levels, you can't use it,
> unless there's a trick I don't know about.
My patches are all -p1 as taught by ancient rpm lore, but sometimes I mix
patches from other origins and those can be anything.
Thanks for the tip, I will try to remem
Hi all,
Since most participants seems to be in favor of explicit %setup handling, I've
updated the wiki and the macro file
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang
money and potential contributors.
If there is now way to do it cleanly or safely in rpm, I'll de-optimize the
packager side. I don't want to cause problems to anyone. But that would be
pretty sad.
Regards,
--
Nicolas Mailhot
___
golang mailing list --
e == %{archivename}%{archiveext} change %setup to %setup
%{?setupargs}"
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
n't make the wrong macro call in
my specs :).
> and allows you to %autosetup underneath on versions where macro arguments are
> expanded (rpm >= 4.14)
Interesting, are the changes described somewhere? Not that I want to break
compat with el7 from the start
es I
produce.
OTOH it would be nice if the macro could adjust %setup to mean %setup -n
%{archivename} when necessary, but I couldn't figure how to do it cleanly.
> add a text like
> "See https://fedoraproject.org/wiki/Packaging:Versioning how to adjust
> Release tag for pre-/post-
es, so it can not be supported right now.
RFE: https://pagure.io/pagure/issue/2845
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
e a generic macro structure, with a packager-friendly
API, sane rpm variable names, reasonable rule ordering and error handling.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
101 - 200 of 201 matches
Mail list logo
