[golist] Issue #4: golist needs to be able to process multiple import path
in one pass
by Nicolas Mailhot
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 work reliably, you need to compute the codebase requirements in a single pass. Otherwise `golist` will forget to filter out imports of code, already available on-system under another import path. And that will break BuildRequires computation.
So we need something like
```sh
$ golist --imported --skip-self --with-tests --package-path %{goipath0} --package-path %{goipath1} --package-path %{goipath2}
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/4
4 years, 11 months
[golist] Issue #14: golist should handle naming assertions cleanly
by Nicolas Mailhot
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 scripts (for example, rpm dependency scripts) the panic messages are unhelpful, because the recipient of those messages has not called golist directly and does not know what exact golist call resulted in this panic.
golist should handle this case by default and:
1. output useful info to stderr, including what exactly it was doing at the panic time
2. abort with an error code
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/14
4 years, 11 months
Re: [golang-dev] Try our new module mirror!
by Jakub Cajka
----- Original Message -----
> From: "Katie Hockman" <katie(a)golang.org>
> To: golang-dev(a)googlegroups.com
> Sent: Monday, April 29, 2019 10:35:38 PM
> Subject: [golang-dev] Try our new module mirror!
>
> Hey Gophers!
>
> In the blog post Go Modules in 2019 <https://blog.golang.org/modules2019>,
> we announced our intent to provide a module mirror for accelerating Go
> module downloads, an index for discovering new modules, and a checksum
> database for authenticating module content.
>
> We are excited to share that we are ready for developers to start alpha
> testing our module mirror, index, and checksum database!
>
> Our privacy policy explains how we collect and use your information. The
> privacy policy for all of these services is proxy.golang.org/privacy.
Hello,
if I'm not mistaken the page that you are linking for privacy information of the proxy seems not related to it at all. It looks like some sort of generic terms that Google is using for all of its services. It is not describing what is collected and what for, how and where it is retained and stored, etc. in context of the proxy/this new google service.
Could you expand on these topics in actual go proxy context, please? What are you collecting/are you planning on collecting and what for?
>
> The module mirror at proxy.golang.org serves the go command’s proxy
> protocol. To make the go command use it (when in module mode), set GOPROXY=
> https://proxy.golang.org.
>
> The module index at index.golang.org serves a feed of module versions in
> the order they are discovered. For example, see
> https://index.golang.org/index?since=2019-03-04T18:00:15.161182-07:00
>
> The module checksum database at sum.golang.org serves the URLs described in
> the Secure the Public Go Module Ecosystem
> <https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md>
With brief look on the proposal, just from the technical perspective(kind of including modules too). Little has changed from my perspective since the initial proposal. I'm still worried that I will have to disabled/de-configured or at worst case scenario even patch it (out) to make our build system in Fedora work with Go sources that we are curating/shipping/using(i.e. occasional need to carry downstream/backport patches). Leaving out for now the privacy/MITM concerns which look nearly the same(i.e. IMHO not resolved) as previously.
> proposal. If you use the Go 1.13 development version of the go command,
> setting GOPROXY=https://proxy.golang.org will automatically use the
> checksum database as well. To use the checksum database to protect other
> code downloads, set GOSUMDB=sum.golang.org explicitly. See the development
> version go command docs
> <https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures> for
> details. If you are using Go 1.12 or earlier, you can manually check a
> go.sum file against the checksum database with gosumcheck
> <https://godoc.org/golang.org/x/exp/sumdb/gosumcheck>:
>
> go get golang.org/x/exp/sumdb/gosumcheck
>
> gosumcheck /path/to/go.sum
>
> We hope you’ll try out these new services! Note that these are in the early
> stages, so even though we don’t have any planned outages, you should
> recognize it is an alpha release and instability and bugs are expected.
> We’ll be actively working through these and improving our services, so
> please file issues <https://github.com/golang/go/issues/new> if you spot
> them, with the title prefix “proxy.golang.org:” (or index.golang.org, or
> sum.golang.org). We look forward to hearing about how it’s working for you!
>
> Cheers,
>
> Katie Hockman
Is there anywhere a place where I or anyone else could pull the sources and contribute to all of these new Go features/services that you are deploying/running, or so I/anyone could potentially even run my own instances of proxy.golang.org, sum.golang.org and index.golang.org and help with devel?
Thanks for any info. Sorry if I have missed some details.
JC
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
4 years, 12 months
[golist] Issue #12: golist should be buildroot prefix aware
by Nicolas Mailhot
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 actual requires and provides rpm will generate.
As a consequence of this rpm design we can not change:
* the files operated on are not in their final place but under a root prefix (`%{buildroot}/something` instead of `something`), and
* absolute symbolic links that point within the target deployment tree are left dangling (they point to `something`, when `/something` is still at `%{buildroot}/something`)
Since *golist* is used to compute provides and requires for Go sources, and those sources can include absolute symlinks, and will continue to prefer absolute symlinks over relative symlinks because relative symlinks are quite hard to get right, *golist* needs to learn to work in prefix mode, and learn to walk to `%{buildroot}/something` when encountering a `/something` symlink in the source tree.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/12
5 years
