rawhide.
That's why they come with built-in error handling.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
rt was to define 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
ject archives, 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
It tends to hate the patches 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 adj
; ?
But, I'll bow to whatever FPC decides. *I* won'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 somewhe
"if archive == %{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
hat costs actual 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
_
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 g
patches that 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
-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
d
end
Don't tell me that's overly difficult 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 conden
, 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
eone 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 a
_files[@]}
/usr/lib/rpm/sepdebugcrcfix: 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.fedora
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,
--
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
y I 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 unsubscrib
>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
ly" 5 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
- Mail original -
De: "Jakub Cajka"
À: 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"
> De: "Jakub Cajka&q
t my Go toolchain makes creating 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
27;s what you want
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
s so they don't trigger autodeps, and tries very hard to
own all relevant directories.
For those reasons I don't propose to activate autodeps in old-style golang
packages. They need conversion (and review by a human to check no problem code
is deployed) first.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
s to go-srpm-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
global commit 9b4c5fa5b10a683339a270d664474b9f4aee62fc
%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 manipulat
d be 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?
ation#Packaging_examples
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
- 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 -- go
- Mail original -
De: "Jason L Tibbitts III"
>>>>> "nm" == nicolas mailhot writes:
>nm> And the forge macros are now available since
>nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream
>nm> renaming the file).
I wrote the forge part could be made available 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,
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
ng to read any documentation.
Regards,
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
lems that it would 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
each Go packager to do it himself with his own means. And that is
certainly not 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
g. A
lot of them are nice and responsible and just didn't see they had an 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. Wh
hrough the entire proposal, but it certainly
> looks 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
age ecosystems do not manage to
avoid them. You can strive to limit compat 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,
that prevents 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 a
Hi Robert André
That's an interesting request
I guess you can't figure if the example is for building binaries or Go libs,
because there is no hard frontier between both cases in the proposed guidelines
In Go, everything is effectively a code library that can be reused elsewhere.
So the approa
- 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
ally in some years permit building 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
er around to
> 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
re you stating it's a major use case, Fedora is not doing it today.
"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 exac
a Fedora-specific identifier namespace at the lib level would be a good idea.
Though, the few projects 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
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 sic
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
Le lundi 19 février 2018 à 16:50 +, Jiri Kucera a écrit :
> Thank You for Your note, I will take care about EPEL7 branches.
>
> Btw is anybody working on gin and gopacket (and the rest of the
> packages)? If not, I will take them.
FYI the spec dump we're working on, which is waiting for Jan t
github.com/prometheus/snmp_
exporter
rkt.spec github.com/rkt/rkt
runc.spec github.com/opencontainers/runc
swarmkit.spec github.com/docker/swarmkit
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fed
Hi Jason,
> > "nm" == nicolas mailhot wrote:
> Jason L Tibbitts wrote:
> > nm> And the forge macros are now available since
> > nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to
> > upstream
> > nm> renaming the file). Heartfelt t
leases of
other components, 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.f
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 you as
Le 2018-03-06 13:24, Nicolas Mailhot a écrit :
(really not happy right now about golist trying to parse, install and
test non production code such as examples, tesdata and _dirs by
default, all of those should be ignored, trying to parse and install
them breaks many of our packages, as most
ftware-management/rpm/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 f
Hi,
I'm obviously interested, even though I'm not available all year round
--
Nicolas Mailhot
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Cond
ackaging rules and tooling for two
separate 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://getfed
dos to jchaloup 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@lis
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 pro
tions, 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
Reg
ort Go but *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 -- go
will grow flags to select the archive to work on, when packaging several
of those).
I hope that from now on we can continue to evolve the macro
capabilities, to take into account changes in the Go language, while
keeping the way they are used in s
o-sig 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 go
send the result to FPC and the Fonts SIG to switch existing
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: http
r 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
Fedora Code
s it (so detached digital
signatures, not 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
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, suffe
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
> > li
ny more than you can push
code with missing function definitions 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 &quo
out own curated set 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@l
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
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 -- jus
exist upstream
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.ht
urse it will not 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 -- gola
n move forward in a team.
Best 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 Gui
oaltipaths produce compat packages, to make very clear 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
F
need 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)
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
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 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
Le 2019-03-27 10:44, 'Nicolas Mailhot' via golang-dev a écrit :
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
so 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
_
, it's
real blacklisting 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 Con
ng will enforce them 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
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
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 f
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
___
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 rep
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 wo
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 to
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 github.com/sirupsen/
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 golang-le...@l
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)
https://pagure.io/go-rpm-macros/blob/m
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 -- golang@lists.fedor
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
github.com/gofe
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 golang
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 deplo
Le lundi 19 février 2018 à 16:50 +, Jiri Kucera a écrit :
> Thank You for Your note, I will take care about EPEL7 branches.
>
> Btw is anybody working on gin and gopacket (and the rest of the
> packages)? If not, I will take them.
FYI the spec dump we're working on, which is waiting for Jan t
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 h
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
/builddir/build/BUILDROOT/golang-github
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
+ /usr/bin/chmod
1 - 100 of 213 matches
Mail list logo
