I agree with Zbyzsek on this.
What about to carry a tiny down-stream patch until this issue is fixed:
https://github.com/golang/go/issues/18304
(https://github.com/golang/go/issues/18304)
Jakub
-- Původní zpráva --
Od: Zbigniew Jędrzejewski-Szmek
Komu: Development d
On Tue, Dec 13, 2016 at 01:06:29PM -0500, Jakub Cajka wrote:
> > can we enable coredumping for Go programs by default - i.e. set GOTRACEBACK=
> > crash?
> >
> > Currently, Go terminate a process that panic and prints out an error
> > message on stderr.
> >
> > This approach does not provide much
On Sat, Dec 9, 2017 at 3:33 AM, wrote:
>
> Since I'm a nice person I added GitLab support this morning (both gitlab.com
> and hosted gitlab). Releases are clearly an afterthought in GitLab, they
> depend on free-form tags and can't be used in rpm without knowing the
> corresponding hash (so wo
On Fri, Dec 08, 2017 at 07:03:48PM +0100, nicolas.mail...@laposte.net wrote:
> Hi,
>
> I am proposing for inclusion a macro set aimed at automating the packaging of
> forge-hosted projects.
>
> — Packaging draft:
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
> — FP
> I really do like this. There are only two issues I have with it:
>
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
>
> 2. Mandating a forge is going to be tricky for self-hosted s
On Tue, Dec 12, 2017 at 1:16 PM, Adam Williamson
wrote:
> On Tue, 2017-12-12 at 21:11 +0100, nicolas.mail...@laposte.net wrote:
>>
>> > If you have 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
On Sun, Dec 17, 2017 at 2:11 AM, wrote:
> Hi,
>
> I am proposing for inclusion a set of rpm technical files aimed at automating
> the packaging of forge-hosted projects.
>
> - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging
> - https://pagure.io/packaging-committee/issue/734
>
On Mon, Dec 11, 2017 at 01:23:19PM +0100, nicolas.mail...@laposte.net wrote:
> Hi Neal,
>
> > And the issue you're having that requires %setupargs is not a problem
> > in RPM 4.14
>
> I don't have an issue with %setupargs, I have an issue with requiring
> packagers to change stuff in the spec h
On Mon, Dec 11, 2017 at 5:57 AM, wrote:
>>De: "Panu Matilainen"
>
> Hi Panu,
>
>>> But don't override %setup. There's no need for such abuse
>
>> It is really pretty safe, the macro controls the downloaded file, the file
>> structure is known, the only time it won't "just
>> work" is when a spec
On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa wrote:
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> wrote:
> >> I really do like this. There are only two issues I have with it:
> >>
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (
On Tue, Jan 23, 2018 at 5:45 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>>
I really do like this. There are only two issues I have with it:
1. This seems to mandate that all packages must be named by their
>>
On mardi 30 janvier 2018 16:11:49 CET nicolas.mail...@laposte.net wrote:
> Hi,
>
> Now the technical PR is submitted
> https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
>
> and waiting for action from the go-srpm-macros maintainers, I took (quite a
> long) time to refresh and flesh
On Tue, Jan 23, 2018 at 9:40 AM, wrote:
>
>> - Mail original -
>> De: "Neal Gompa"
>
>>> I'm curious, what are you missing in the preamble ? As far as I can see
>>> it's all there (even though some values
>>> set to variables %gometa precomputes). I had it's right autogenerated some
>>>
On Tue, Jan 23, 2018 at 8:54 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>> 2. if your concern is that the *forge* macros are defective somewhere I'd
>>> be curious where as you'd be the
>>> first to report an actual technical problem. I've used them intensively in
>>> raw
On Tue, Jan 23, 2018 at 9:00 AM, wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>> As long as I can do Obsoletes/Provides for the old name for the devel,
>> unit-test,
>
> BTW is anyone using the unit-test packages? Right now I do not generate them,
> I don't need them, and making t
On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
wrote:
>> I really do like this. There are only two issues I have with it:
>>
>> 1. This seems to mandate that all packages must be named by their
>> import path. My golang package (snapd) is not, intentionally so. I
>> don't want to change this.
+1, I started looking on packaging Go libraries and looking for
recommendations. I saw [1] but as this seems more a draft (so a WIP
document) it would be good if we have specific group to discuss best
practices, package reviews, etc.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
On Fri,
CCing Jeff :)
On 09/18/2018 02:45 PM, Jakub Cajka wrote:
- Original Message -
From: "Neal Gompa"
To: golang@lists.fedoraproject.org, opensuse...@opensuse.org
Cc: "Aleksa Sarai" , "Richard Brown" ,
vrothb...@suse.com, jca...@redhat.com
Sent: Tuesday, September 18, 2018 1:35:36 PM
S
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
I wish this message wasn't crossposted everywhere, but I don't want to
lose any discussion by trimming the CC list. Sorry if replies generate
bounces for some.
> "nm" == nicolas mailhot writes:
nm> And the forge macros are now available since
nm> redhat-rpm-config-73-1.fc28 (I had missed th
On Tue, Jan 30, 2018 at 10:11 AM, wrote:
> Hi,
>
> Now the technical PR is submitted
> https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
>
> and waiting for action from the go-srpm-macros maintainers, I took (quite a
> long) time to refresh and flesh out the corresponding packagin
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
On Mon, Sep 3, 2018 at 1:49 PM Nicolas Mailhot
wrote:
>
> Le 2018-09-03 11:04, Jakub Cajka a écrit :
>
> Hi,
>
> > Please let me know if this date doesn't fit you or you would prefer
> > IRC meeting.
>
> Not fond of audio/video systems, they're unfriendly to non native
> English speakers, they'r
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
The issue: `golist processing is arch and tag-specific` of project: `golist`
has been reset by jcajka.
https://pagure.io/golist/issue/2
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedorap
The issue: `golist processing is arch and tag-specific` of project: `golist`
has been reset by jcajka.
https://pagure.io/golist/issue/2
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedorap
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
> "nm" == nicolas mailhot writes:
nm> I don't know about EPEL6, but we use it as-is in EL7 and it works
nm> just as well (except maybe for the %autosetup bits but IIRC that's
nm> autosetup which is broken in EL7).
I had ported autosetup to EPEL6 and then at the next release the macros
showed
Adding Jeff, too
On 09/18/2018 01:35 PM, Neal Gompa wrote:
Hello all,
For the Fedorans among you (and Richard), you may be aware that a
number of us met at Flock[0] and decided we wanted to do something
about the poor state of affairs on supporting Go in Linux
distributions. After the success
jcajka added a new comment to an issue you are following:
``
@nim This is a blocker, devel packages needs to be noarch, i.e. representing
the upstream source with possible Fedora patches applied. No file filtering
based on arch tag combination.
``
To reply, visit the link below or just reply to
On Fri, Aug 3, 2018 at 7:51 AM Jakub Cajka wrote:
>
> Thank you very much for your interest.
>
> I will now create SIG wiki page(and let you know to add yourself there),
> IRC channel(#fedora-golang, making it official). I believe we can use
> golang@lists.fedoraproject.org as the mailing li
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
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 -
eclipseo added a new comment to an issue you are following:
``
Should we fix golist instead of requiring a compat package?
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/1
___
golang mailing list -- golang@l
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 test
nim reported a new issue against the project: `go-rpm-macros` that you are
following:
``
`%goprep` should apply patches automatically, so there is no convenience gap
with `%autosetup`.
This is generic work that should be done *redhat-rpm-config* side in forge
macros and then reused in`%goprep`
ngompa added a new comment to an issue you are following:
``
How do we handle the case of when patches should be applied
manually/conditionally?
Is it demonstratively worse to have either
```
%gosetup
%goautopatch
%goprep
```
or
```
%goautosetup
%goprep
```
instead?
``
To reply, visit the
mooz reported a new issue against the project: `go-rpm-macros` that you are
following:
``
I'm trying to build a golang package for EL7 but I'm unable to create a SRPM
from a spec file after installing the go RPM macros. I'm receiving the below
error:
```
rpmbuild -bs golang-github-jedisct1-clo
nim reported a new issue against the project: `golist` that you are following:
``
`golist` only implements a single output format, which means this output needs
to be reprocessed in shell before being fed to other software, like rpm¹.
This shell reprocessing is brittle and adds noise to Go packa
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 gol
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 a
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
surger
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
+ '['
/builddir/build/BUILDROOT/golang-githu
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 participate
nim added a new comment to an issue you are following:
``
It's kind of hard to diagnose without the spec file and build logs, but
basically there have been a lot of fixing and rewriting in the months since the
wiki page was written. Macro usage is still the same but the code itself has
changed
nim added a new comment to an issue you are following:
``
> How do we handle the case of when patches should be applied
> manually/conditionally?
That would actually be trivial to handle cleanly
```specfile
%if
%global source_patches3 6 87 456 # apply patches 6 87 456 after unpacking
source 3
qulogic added a new comment to an issue you are following:
``
Never mind, I found the information about symlinking in the README.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/15
___
golang mailing list --
qulogic added a new comment to an issue you are following:
``
From a bit of testing in mock, the problem seems to be about running in the
source directory. If I'm in the source directory, then run (simplified from
`go-rpm-integration`):
`GOPATH="/builddir/build/BUILD/viper-1.3.1/_build${GOPATH+:
nim added a new comment to an issue you are following:
``
The original reporter may not see the question since this is a migrated issue.
But even if tests were still being run (not sure about this), a panic is pretty
bad behavior: packagers are supposed to care about how builds proceed, we don't
carlwgeorge opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Update bootstrapping link
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/5
___
golang mail
qulogic added a new comment to an issue you are following:
``
So is this or is this not a problem? Are tests actually being run or are they
being ignored just like this panic?
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/7
_
The status of the issue: `Missing pkg/util/internal directory` of project:
`golist` has been updated to: Closed by qulogic.
https://pagure.io/golist/issue/15
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to gola
qulogic reported a new issue against the project: `golist` that you are
following:
``
```
$ go get pagure.io/golist/...
package pagure.io/golist/pkg/util/internal/load: unrecognized import path
"pagure.io/golist/pkg/util/internal/load" (parse
https://pagure.io/golist/pkg/util/internal/load?go-g
nim reported a new issue against the project: `golist` that you are following:
``
Because the naming of Go projects is a mess many of them (including core Google
modules) have started asserting how they should be named.
This results in golist panics.
Because golist is often called by other scri
nim added a new comment to an issue you are following:
``
Yes that's what I meant by a little tricky. The changes are not big or scary
but they are spread over several packages that call one another, it's easier to
publish a copr with all the small changes than try to walk you through it
manua
mooz added a new comment to an issue you are following:
``
rpmbuild doesn't appear to want to give me any verbosity, I ran it with the
--showrc flag and it looks to be stopping at the forgesource if statement below:
```
-- All the Go packaging automation relies on goipath being set
local goipath
jcajka added a new comment to an issue you are following:
``
@nim I would much appreciate if you woudn't put words in to my mouth, thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/7
___
golang mailing l
nim added a new comment to an issue you are following:
``
For readers that don't understand the latest exchange, the participants wrote
their piece here https://pagure.io/GoSIG/go-sig/issue/3
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/7
_
qulogic added a new comment to an issue you are following:
``
A workaround I've found that appears to work is:
```rpm
%check
builddir="$PWD/_build"
cd ..
%gochecks -b "$builddir"
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/7
___
nim added a new comment to an issue you are following:
``
@jcajka: how do you expect anyone to understand your position? Months over
months of not accepting macro fixes, months over months of finding new reasons
not to look at them, refusal to discuss it in SIG meetings, no activity in the
pagu
nim added a new comment to an issue you are following:
``
That sucks since other projects *expect* to be in the source dir when run. So
I guess the shell wrapper will need to be changed to run golist outside this
dir and switch to it afterwards: (
I've filled it as https://pagure.io/go-rpm-ma
qulogic added a new comment to an issue you are following:
``
Should I push a fix directly (I think I can at least) or open a PR?
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/1
___
golang mailing list -- g
The issue: `golist needs to be run outside the source tree to avoid panics` of
project: `go-rpm-macros` has been assigned to `nim` by nim.
https://pagure.io/go-rpm-macros/issue/6
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe
nim added a new comment to an issue you are following:
``
@qulogic this is all originally @jchaloup 's code. He asked to split it in a
separate repository, but I don't know what's the level of involvement he wants
(and can) provide here. Ask him politely how he wants to do things (of course
if
qulogic opened a new pull-request against the project: `golist` that you are
following:
``
Fix compile against latest urfave/cli.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/16
___
golang mailing
nim reported a new issue against the project: `go-rpm-macros` that you are
following:
``
To workaround https://pagure.io/golist/issue/7, the shell wrapper should switch
to another directory (for example /usr/bin) before running `golist`, and switch
back to the correct dir afterwards (so add str
The issue: `golist should be ported to a current release of
gopkg.in/urfave/cli.v1` of project: `golist` has been assigned to `qulogic` by
qulogic.
https://pagure.io/golist/issue/1
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscri
qulogic added a new comment to an issue you are following:
``
Based on [further debugging](https://pagure.io/golist/issue/7#comment-551104),
this appears related to Go modules. As such, an alternate workaround is to set
`GO111MODULES=off` before calling `golist`. Of course, you need to be sure y
jcajka merged a pull-request against the project: `go-rpm-macros` that you are
following.
Merged pull-request:
``
Update bootstrapping link
``
https://pagure.io/go-rpm-macros/pull-request/5
___
golang mailing list -- golang@lists.fedoraproject.org
To
nim added a new comment to an issue you are following:
``
Sure it does, however till someone analyses both issues and concludes they are
the same, it's dangerous to track only one of them.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/8
qulogic added a new comment to an issue you are following:
``
Well, the null pointer is here:
```
/builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/internal/load/pkg.go:1888
+0x5f fp=0xc000123038 sp=0xc0001
qulogic added a new comment to an issue you are following:
``
Is this still a problem?
```
$ golist --imported --package-path cloud.google.com/go --skip-self | rg go-cmp
github.com/google/go-cmp/cmp
$ golist --imported --package-path cloud.google.com/go --skip-self --tests | rg
go-cmp
github.com
qulogic added a new comment to an issue you are following:
``
The backtraces point to line 1888 here:
```go
1886 func ImportPaths(args []string) []*search.Match {
1887 if ModInit(); cfg.ModulesEnabled {
1888>return ModImportPaths(args)
1889 }
1890 return sea
nim added a new comment to an issue you are following:
``
BTW:
* thanks an *awful* lot for looking at golist code maintenance
* if you can figure how to make golist process module info, and spit out the
version constrains that only exists in those modules, that would be much nicer
than inhibiti
The issue: `runtime panic, nil dereference when running %gochecks` of project:
`golist` has been assigned to `qulogic` by qulogic.
https://pagure.io/golist/issue/7
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email t
nim added a new comment to an issue you are following:
``
Yes, I suppose an alternative would be to track the things that depends on this
bit of code and ask them to drop it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/10
_
qulogic added a new comment to an issue you are following:
``
This looks the same as #7, no?
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/8
___
golang mailing list -- golang@lists.fedoraproject.org
To unsu
qulogic opened a new pull-request against the project: `golist` that you are
following:
``
Replace Go internals with go/build
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/17
___
golang mailing list
qulogic added a new comment to an issue you are following:
``
What I'm saying is that golist does _not_ think it's a test file, and I'm
confused why you think it should be.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/9
nim added a new comment to an issue you are following:
``
Ah ok. I think that's because we only hit it when executing tests. Will look at
it once more, maybe the logrus code was refactored since this was filed
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist
qulogic added a new comment to an issue you are following:
``
This package also fails `go build` with the same message, so I'm not sure we
can really blame `golist`. It seems to be an outdated and broken-on-latest-Go
package.
``
To reply, visit the link below or just reply to this email
https:/
qulogic commented on the pull-request: `Replace Go internals with go/build`
that you are following:
``
So for tests, I searched the specs for all that define`goipath` and cloned all
of them (note this is _not_ all Go packages.) Then ran `golist` as packaged and
`golist` from this PR and compare
nim added a new comment to an issue you are following:
``
golist does not uses this kind or regexes it plugs directly in the Go compiler
inner code to match the Go compiler view of what's in a project. This was a
deliberate choice by Fedora Go maintainers last year, my initial macro
implementat
The issue: `golist needs to be able to process multiple import paths in one
pass` of project: `golist` has been assigned to `qulogic` by qulogic.
https://pagure.io/golist/issue/4
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe
The issue: `didn't find "github.com/google/go-cmp/cmp"` of project: `golist`
has been assigned to `nim` by nim.
https://pagure.io/golist/issue/6
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@list
qulogic added a new comment to an issue you are following:
``
I think most of the code is already written to handle this; it just needs to
fix the CLI flags to work correctly.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/4
_
nim added a new comment to an issue you are following:
``
I will recheck. cloud.google.com/go is a full bag of nastiness, that even other
Google projects have problems with (most of them still import it under a legacy
name, which means they are afraid of using the latest code. The current
cloud
The issue: `incomplete import detection for tests ` of project: `golist` has
been assigned to `nim` by nim.
https://pagure.io/golist/issue/9
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fe
qulogic commented on the pull-request: `Replace Go internals with go/build`
that you are following:
``
As a note, the original code ran a resolve on the test imports, but not the
regular imports. I tried adding a resolve on the regular imports as well, but
it doesn't help. I also tried setting
qulogic added a new comment to an issue you are following:
``
Aren't Go tests in files that end with `_test.go`? Since
`terminal_check_notappengine.go` is not one of those, it shouldn't be output
with `--tests`. It _is_ output in the normal (no `--tests`) results.
``
To reply, visit the link be
1 - 100 of 164 matches
Mail list logo
