Bug 26392

Also, is it possible to add :

%goinstall

in the install section ?

Because, after installing it, I can not build golang-uber-tools, I meet that error :
> event_type_test.go:26:2: cannot find package "github.com/stretchr/testify/assert" in any of:
>         /usr/lib/golang/src/github.com/stretchr/testify/assert (from $GOROOT)
>         /home/jybz/rpmbuild/BUILD/tools-2cfd321de3ee5d5f8a5fda2521d1703478334d98/_build/src/github.com/stretchr/testify/assert (from $GOPATH)
> FAIL    go.uber.org/tools/lib/parallel [setup failed]

I just analyse the rpm, and finaly found it under /usr/lib64 and not /usr/lib, aside 2 others packages :
godbus dbus
gorilla mux

Analysing the packages...
> http://svnweb.mageia.org/packages/updates/7/golang-godbus/current/SPECS/golang-godbus.spec?view=markup
doesn't contains %goinstall
> http://svnweb.mageia.org/packages/updates/7/golang-gorilla-mux/current/SPECS/golang-gorilla-mux.spec?view=markup
Neither !

Does someone know how to add lib64 in the go src path if this packages does not shift it to lib ?

You ask for a lot of changes! The first one is certainly legitimate:
> Is it possible to update this package : golang-testify
> The package is 2014, version 0.0.0
> It is currently version 1.5.0
Can you please clarify comment 1, which looks a real bug. It is unclear exactly which package(s) wrongly cite(s) /usr/lib rather than /usr/lib64.
I found that it is 'golang-testify-devel' which actually provides the many
 /usr/lib64/golang/src/pkg/github.com/stretchr/testify/
components.

Unsure what you mean with respect to:
 godbus dbus
 gorilla mux
which are not package names. Please re-state this point.

CC: (none) => lewyssmith
Source RPM: (none) => golang-testify-0.git8ce79b9f0b77-4.mga7.src.rpm

Hello Lewis,

I didn't reply for a while, but I go further. I still have a lot to say.

About comment 1, when installed, I still can't use it, because an environment variable (where go sources are stored) is not set at the same path.
Worst, I didn't saw policies about. And as the result, I couldn't use golang-testify-devel in /usr/lib64, but, after a deeper research, I found another packet golang-github-stretchr-testify-devel, and understood how to set and use the env.var. so, here is a double package, but they are using different path to store the source code on mageia :

golang-github-stretchr-testify-devel:/usr/share/gocode/src/github.com/stretchr/testify/doc.go

golang-testify-devel:/usr/lib64/golang/src/pkg/github.com/stretchr/testify/doc.go

So, in fine, it isn't two different paths, but three :
> /usr/share/gocode/src
> /usr/lib/golang/src
> /usr/lib64/golang/src

-devel packages using /usr/lib/golang/src :
> [07:06:45 jibz@jabztop ~]$ urpmf /usr/lib/golang/src | cut -d ':' -f 1 | sort -u
> golang-blackfriday-devel
> golang-logrus-devel
> golang-net-devel
> golang-src
> golang-tests
> go-md2man-devel

-devel packages using /usr/lib64/golang/src
(is the -devel is missing ?)
> [07:07:16 jibz@jabztop ~]$ urpmf /usr/lib64/golang/src | cut -d ':' -f 1 | sort -u
> docker-devel
> golang-codegangsta-devel
> golang-godbus
> golang-gopatricia
> golang-gorilla-context
> golang-gorilla-mux
> golang-go-systemd
> golang-libcontainer-devel
> golang-libtrust
> golang-sqlite
> golang-syndtr-gocapability
> golang-testify-devel

-devel packages using /usr/share/gocode/src
(14 don't ends with "-devel" even if it is pure source code used to compile other software)
> [07:07:27 jibz@jabztop ~]$ urpmf /usr/share/gocode/src | cut -d ':' -f 1 | sort -u         
> compat-golang-github-chzyer-readline-devel
> compat-golang-github-shurcool-githubql-devel
> compat-golang-github-shurcool-octiconssvg-devel
> compat-golang-gopkg-bradfitz-gomemcache-1-devel
> golang
> golang-ActiveState-tail
> golang-bazil-fuse-devel
> golang-bitbucket-ww-goautoneg-devel
> golang-dmitri-shuralyov-html-belt-devel
> golang-dmitri-shuralyov-route-github-devel
> golang-dmitri-shuralyov-state-devel
> golang-github-10gen-openssl-devel
> golang-github-aclements-gg-devel
> golang-github-aclements-moremath-devel
> golang-github-ajstarks-svgo-devel
> golang-github-alecthomas-kingpin-devel
> golang-github-alecthomas-template-devel
> golang-github-alecthomas-units-devel
> golang-github-anmitsu-shlex-devel
> golang-github-beorn7-perks-devel
> golang-github-bradfitz-gomemcache-devel
> golang-github-bradfitz-smtpd-devel
> golang-github-BurntSushi-toml-devel
> golang-github-chzyer-logex-devel
> golang-github-chzyer-test-devel
> golang-github-coreos-go-systemd-devel
> golang-github-coreos-pkg-devel
> golang-github-cpuguy83-go-md2man-devel
> golang-github-davecgh-go-spew-devel
> golang-github-dustin-go-humanize-devel
> golang-github-eapache-go-resiliency-devel
> golang-github-eapache-queue-devel
> golang-github-fsnotify-fsnotify-devel
> golang-github-fsnotify-fsnotify-unit-test-devel
> golang-github-garyburd-redigo-devel
> golang-github-gliderlabs-ssh-devel
> golang-github-godbus-dbus-devel
> golang-github-golang-appengine-devel
> golang-github-golang-glog-devel
> golang-github-golang-snappy-devel
> golang-github-golang-snappy-unit-test
> golang-github-golang-sys-devel
> golang-github-golang-time-devel
> golang-github-go-mgo-mgo-devel
> golang-github-gonum-blas-devel
> golang-github-gonum-floats-devel
> golang-github-gonum-internal-devel
> golang-github-gonum-lapack-devel
> golang-github-gonum-matrix-devel
> golang-github-googleapis-gax-devel
> golang-github-google-btree-devel
> golang-github-google-go-cmp-devel
> golang-github-google-go-genproto-devel
> golang-github-google-go-github-devel
> golang-github-google-go-querystring-devel
> golang-github-google-martian-devel
> golang-github-google-pprof-devel
> golang-github-gopherjs-devel
> golang-github-gorilla-context-devel
> golang-github-gorilla-mux-devel
> golang-github-go-sql-driver-mysql-devel
> golang-github-go-tomb-tomb-devel
> golang-github-go-tomb-tomb-devel-v2
> golang-github-gregjones-httpcache-devel
> golang-github-grpc-grpc-go-devel
> golang-github-hashicorp-hcl-devel
> golang-github-howeyc-gopass-devel
> golang-github-ianlancetaylor-demangle-devel
> golang-github-inconshreveable-mousetrap-devel
> golang-github-jellevandenhooff-dkim-devel
> golang-github-jessevdk-go-flags-devel
> golang-github-jtolds-gls-devel
> golang-github-julienschmidt-httprouter-devel
> golang-github-kisielk-gotool-devel
> golang-github-klauspost-crc32-devel
> golang-github-kr-fs-devel
> golang-github-kr-pretty-devel
> golang-github-kr-text-devel
> golang-github-lib-pq-devel
> golang-github-magiconair-properties-devel
> golang-github-mattn-go-runewidth-devel
> golang-github-mattn-go-sqlite3-devel
> golang-github-matttproud-golang_protobuf_extensions-devel
> golang-github-microcosm-cc-bluemonday-devel
> golang-github-mitchellh-go-homedir-devel
> golang-github-mock-devel
> golang-github-neelance-astrewrite-devel
> golang-github-neelance-sourcemap-devel
> golang-github-onsi-ginkgo-devel
> golang-github-onsi-gomega-devel
> golang-github-openzipkin-zipkin-devel
> golang-github-pelletier-go-toml-devel
> golang-github-peterbourgon-diskv-devel
> golang-github-pkg-errors-devel
> golang-github-pkg-sftp-devel
> golang-github-pmezard-go-difflib-devel
> golang-github-prometheus-client_golang-devel
> golang-github-prometheus-client_model-devel
> golang-github-prometheus-common-devel
> golang-github-prometheus-procfs-devel
> golang-github-russross-blackfriday-devel
> golang-github-russross-blackfriday-v2-devel
> golang-github-sergi-go-diff-devel
> golang-github-Shopify-sarama-devel
> golang-github-Shopify-sarama-unit-test-devel
> golang-github-Shopify-toxiproxy-devel
> golang-github-shurcool-component-devel
> golang-github-shurcool-devel
> golang-github-shurcool-events-devel
> golang-github-shurcool-flavored-markdown-devel
> golang-github-shurcool-frontend-devel
> golang-github-shurcool-githubql-devel
> golang-github-shurcool-gofontwoff-devel
> golang-github-shurcool-goon-devel
> golang-github-shurcool-graphql-devel
> golang-github-shurcool-highlight-devel
> golang-github-shurcool-highlight-diff-devel
> golang-github-shurcool-home-devel
> golang-github-shurcool-htmlg-devel
> golang-github-shurcool-httperror-devel
> golang-github-shurcool-httpfs-devel
> golang-github-shurcool-httpgzip-devel
> golang-github-shurcool-issuesapp-devel
> golang-github-shurcool-issues-devel
> golang-github-shurcool-markdownfmt-devel
> golang-github-shurcool-notificationsapp-devel
> golang-github-shurcool-notifications-devel
> golang-github-shurcool-octiconssvg-devel
> golang-github-shurcool-reactions-devel
> golang-github-shurcooL-sanitized_anchor_name-devel
> golang-github-shurcooL-sanitized_anchor_name-unit-test
> golang-github-shurcool-users-devel
> golang-github-shurcool-webdavfs-devel
> golang-github-Sirupsen-logrus-devel
> golang-github-smartystreets-assertions-devel
> golang-github-smartystreets-goconvey-devel
> golang-github-sourcegraph-annotate-devel
> golang-github-sourcegraph-syntaxhighlight-devel
> golang-github-spacemonkeygo-flagfile-devel
> golang-github-spacemonkeygo-spacelog-devel
> golang-github-spf13-afero-devel
> golang-github-spf13-afero-unit-test-devel
> golang-github-spf13-cast-devel
> golang-github-spf13-cobra-devel
> golang-github-spf13-jWalterWeatherman-devel
> golang-github-spf13-jWalterWeatherman-unit-test
> golang-github-spf13-pflag-devel
> golang-github-spf13-viper-devel
> golang-github-stretchr-objx-devel
> golang-github-stretchr-objx-unit-test
> golang-github-stretchr-testify-devel
> golang-github-syndtr-goleveldb-devel
> golang-github-syndtr-goleveldb-unit-test
> golang-github-syndtr-gosnappy-devel
> golang-github-tambet-asana-devel
> golang-github-tarm-serial-devel
> golang-github-urfave-cli-devel
> golang-go4-devel
> golang-golangorg-crypto-devel
> golang-golang-org-net-devel
> golang-golangorg-text-devel
> golang-golangorg-tools-devel
> golang-googlecode-goauth2-devel
> golang-googlecode-go-decimal-inf-devel
> golang-googlecode-go-decimal-inf-unit-test
> golang-googlecode-gogoprotobuf-devel
> golang-googlecode-goprotobuf-devel
> golang-google-golang-org-api-devel
> golang-google-golangorg-cloud-devel
> golang-gopkg-check-devel
> golang-gopkg-go-check-check-devel
> golang-gopkg-pipe-2-devel
> golang-gopkg-readline-1-devel
> golang-gopkg-urfave-cli-1-devel
> golang-gopkg-yaml-devel
> golang-gopkg-yaml-devel-v2
> golang-grpc-go4-devel
> golang-honnef-js-dom-devel
> golang-honnef-tools-devel
> golang-howeyc-fsnotify
> golang-kr-pty
> golang-launchpad-tomb
> golang-libcrypto
> golang-mitchellh-goamz
> golang-mitchellh-go-fs
> golang-mitchellh-go-vnc
> golang-mitchellh-iochan
> golang-mitchellh-mapstructure
> golang-mitchellh-multistep
> golang-mitchellh-osext
> golang-mitchellh-panicwrap
> golang-opencensus-devel
> golang-racker-perigee
> golang-rackspace-gophercloud
> golang-x-build-devel
> golang-x-perf-devel
> golang-x-sync-devel
> gox-devel
> mongo-tools-devel

On the list, we can see some doubles:

> golang-blackfriday-devel
> golang-github-russross-blackfriday-devel
> golang-github-russross-blackfriday-v2-devel

> golang-logrus-devel
> golang-github-Sirupsen-logrus-devel

> golang-net-devel
> golang-golang-org-net-devel

> go-md2man-devel
> golang-github-cpuguy83-go-md2man-devel

> golang-godbus
> golang-github-godbus-dbus-devel

> golang-gorilla-context
> golang-github-gorilla-context-devel

> golang-gorilla-mux
> golang-github-gorilla-mux-devel

> golang-go-systemd
> golang-github-coreos-go-systemd-devel

> golang-github-stretchr-testify-devel
> golang-testify-devel

They are using different paths.

About the naming of the packages.
most of them are using such pattern :
golang-(ipath without TLD and with dash remplacing dots and slashes)
> github.com/Sirupsen/logrus
> golang-github-Sirupsen-logrus
or, when grom golang.org itseft:
(ipath without TLD and with dash remplacing dots and slashes)
> golang.org/x/sync
> golang-x-sync
but, few of them are using other naming policies.
For example:
> golang.org/x/crypto
> golang-golangorg-crypto-devel

> golang.org/x/net
> golang-golang-org-net-devel

> golang.org/x/time
> golang-github-golang-time-devel

> github.com/mitchellh/mapstructure
> golang-mitchellh-mapstructure

> github.com/golang/protobuf
> golang-googlecode-goprotobuf-devel

> google.golang.org/genproto
> golang-github-google-go-genproto-devel


I wrote to the two main maintainers of go packages, but still waiting for replies.

Thanks for all your research. This has rather re-defined the bug; can you please raise a new bug (as this was originally) just for the issue in Comment 0: update 
golang-testify. Just copy the first two comments from here to the new bug.

> I wrote to the two main maintainers of go packages
You should not have done that. This bug is for that.

You cannot be the only person using Golang, so the picture should not be as black as you paint it. I cannot judge.

Given the huge number of SRPMs involved, I can do no more than assign this globally, CC'ing the main packagers listed as maintainers of these things. If any of you want to un-CC yourself, please do.
I am leaving myself CC'd to see what the reaction is.

Summary: Update golang-testify => Inconsistent source paths in different Golang components;
CC: (none) => bruno, guillomovitch, pterjan
Assignee: bugsquad => pkg-bugs

I think most of those inconsistencies are due to history as paths and macros have evolved over time but not all packages were updated (Some packages were imported before any of those macros existed).

Cleaning things up is always welcome, duplicates being the easiest ones to fix.

I can do it. I start the apprenticeship, but I'm still initiate, so I'm not granted, and I want to be supervised (iif I do it).

Fixing duplicates is not so easy, as they might be used for other packages using also an alternative path.

As the most used source path is 
/usr/share/gocode/src
I believe the fastest way is to process the packages of the two other paths.

With : $( mgarepo maintdb get ${PACKAGE_NAME} ) I output the following :

For /usr/lib/golang/src
bcornec :
> golang-blackfriday      (covered by golang-github-russross-blackfriday-devel )
> golang-logrus           (covered by golang-github-Sirupsen-logrus-devel )
> golang-net              (covered by golang-golang-org-net-devel )
> go-md2man               (covered by golang-github-cpuguy83-go-md2man-devel )

And for golang-src and golang-tests, the package itself is golang, maintainer joequant but bcornec for Mga7 release.

For /usr/lib64/golang/src
bcornec :
> docker
> golang-codegangsta
> golang-godbus           (covered by golang-github-godbus-dbus-devel )
> golang-gopatricia
> golang-go-systemd       (covered by golang-github-coreos-go-systemd-devel )
> golang-libcontainer
> golang-libtrust
> golang-testify          (covered by golang-github-stretchr-testify-devel )
nobody :
> golang-gorilla-context  (covered by golang-github-gorilla-context-devel )
> golang-gorilla-mux      (covered by golang-github-gorilla-mux-devel )
> golang-sqlite
> golang-syndtr-gocapability


The template I use :
https://termbin.com/cc6s

I will write specs for thus which are unique :
> golang-codegangsta
> golang-gopatricia
> golang-libcontainer
> golang-libtrust
> golang-sqlite
> golang-syndtr-gocapability
As soon as it is written, I will submit here the specs.
The naming convention I use is :
golang-%{import path from the golang import perspective, excluding tld, and except from golang.org itself}
For examples :
golang-github-owner-repo for github.com/owner/repo
golang-x-project for golang.org/x/project
golang-google-golang-project for google.golang.org/project (I already note a difference between google.golang.org and golang.org...)


I please bcornec to check if the following packages are required (BuildRequires/Requires) for other packages. (I believe there is no dependencies to these packages, but I dont know how to ensure.)
> golang-blackfriday     
> golang-logrus          
> golang-net             
> go-md2man              
> golang-godbus          
> golang-go-systemd      
> golang-testify         
I wish you can also check :
> golang-gorilla-context
> golang-gorilla-mux    
as there is no maintainers.

I will look closer the specs of docker, and see if this only two lines do the job (jump from /usr/lib(64)/golang to /usr/share/gocode:
%global goroot  %{_datadir}/gocode
%global gopath  %{goroot}

For the package golang itself, I'm much more scary...


Other suggestions ? Objections ?

From github.com/codegangsta/cli we are redirected to github.com/urfave/cli
What to do ?
-we obsolete it ?
-we patch packages which need it in ordre to use urfave ?
-we generate a symlink /usr/share/gocode/src/github.com/codegangsta/cli → ../../urfave/cli ? (in this way, all packages which needs codegangsta will use urfave code ?)

Created attachment 11595 [details]
suggestion golang-gopatricia replacement

For Mageia7, works.
For cauldron, replace %gosetup by %goprep , %gochecks by %gocheck, and works.

First yes, /usr/share/gocode/src is the correct one (But it should be done using %{gopath}/src/ and %{gopath} is rightly /usr/share/gocode/).

In general, using current macros should fix most packages

(In reply to Jybz from comment #7)
> From github.com/codegangsta/cli we are redirected to github.com/urfave/cli
> What to do ?
> -we obsolete it ?
> -we patch packages which need it in ordre to use urfave ?
> -we generate a symlink /usr/share/gocode/src/github.com/codegangsta/cli →
> ../../urfave/cli ? (in this way, all packages which needs codegangsta will
> use urfave code ?)

I would first check if anything uses it, and if so yes a symlink seems like a good idea

(In reply to Jybz from comment #8)
> Created attachment 11595 [details]
> suggestion golang-gopatricia replacement
> 
> For Mageia7, works.
> For cauldron, replace %gosetup by %goprep , %gochecks by %gocheck, and works.

The first things I noticed:

It should be enough to have:
%global goipath         github.com/tchap/go-patricia

As the rest will by default be extracted from it, and only needs to be defined if they did something strange.

Also:

%global goroot  %{_datadir}/gocode
%global gopath  %{goroot}

gopath is already defined to the same value in go-srpm-macros, and goroot is not used anywhere else so both can be removed.

I think it could be as simple as this:

%global goipath         github.com/tchap/go-patricia
Version:                2.3.0

%global common_description %{expand:
A generic patricia trie (also called radix tree) implemented in Go (Golang).

The patricia trie as implemented in this library enables fast visiting of items
in some particular ways:

    visit all items saved in the tree,
    visit all items matching particular prefix (visit subtree), or
    given a string, visit all items matching some prefix of that string.

[]byte type is used for keys, interface{} for values.

Trie is not thread safe. Synchronize the access yourself.}

%gometa

%global golicenses    LICENSE

Name:       %{goname}
Release:    %mkrel 1
Summary:    A generic patricia trie (also called radix tree) implemented in Go (Golang)
License:    MIT
Group:      Development/Other
URL:        %{gourl}
Source0:    %{gosource}

%description
%{common_description}

%gopkg

%prep
%goprep

%install
%gopkginstall

%check
%gochecks

%gopkgfiles

Created attachment 11597 [details]
golang-github-opencontainers-runc.spec

> gopath is already defined to the same value in go-srpm-macros, and goroot is not used anywhere else so both can be removed.
I disagree on the fact that goroot is not used. For example, the (next) package golang-libcontainer have a vendor folder, if I remove it, it will try to find the needed source code from several directories :
> libcontainer/container_linux.go:33:2: cannot find package "github.com/vishvananda/netlink/nl" in any of:
>         /usr/lib/golang/src/github.com/vishvananda/netlink/nl (from $GOROOT)
>         /home/jybz/rpmbuild/BUILD/runc-1.0.0-rc10/_build/src/github.com/vishvananda/netlink/nl (from $GOPATH)
>         /usr/share/gocode/src/github.com/vishvananda/netlink/nl
So when it is looking for a library, it first look into the %{goroot} directory defined as "/usr/lib/golang/src/"
Of course, I agree that is it useless to define it as it will never find source code here and will find it inside %{gopath} ( /usr/share/gocode ), but %{goroot} is used.

For the Macros :
%gopkg
%gopkginstall
%gopkgfiles
When I started (on mga7) to package, I can't used it, I always had something like "/var/tmp/rpm-tmp.1LdXMr: line 90: fg: no job control", I conclude (too quickly) that this macros are only for RedHat/Fedora. Now I know, it is new features. How to manage Mga7 and Cauldron ? Should we write two different specs ? (There is still no planned date for Mga8, so I have to package for Mga7 to continue the build of the tools I want to use.)


Oh ! I just found it !
No need to do a Symlink !
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_handling_package_renames
%global goaltipaths     github.com/Sirupsen/logrus
This variable works with the macro %gopkgfiles.
It generates a specific package named compat-%{goname} (related to the alternative path) which contains only one file, a symlink to the real source from the primary package containing the source code.
But for Mga7, we need such symlink.


In attachment, a spec suggestion for golang-libcontainer
So, it should be good for the package golang-github-urfave-cli (pterjan, you are the maintainer) to set 
> %global goaltipaths     github.com/codegangsta/cli


> I think it could be as simple as this:
> 
> %global goipath         github.com/tchap/go-patricia
> Version:                2.3.0

I know that my multiples lines
> %global goipath         github.com/tchap/go-patricia
> %global provider        github.com
> %global project         tchap
> %global repo            go-patricia
> # https://github.com/tchap/go-patricia
> %global forgeurl        https://%{provider}/%{project}/%{repo}
> Version:                2.3.0
are repetitive, but it isn't a lot of extra work. But there are few project using another forgeurl than goipath, it helps me. Is it a bad practice ?


In attachment, a spec for golang-libcontainers for mga7 and prepared for cauldron (in comments).

I updated my template : https://termbin.com/t74uh
I still have to make BuildRequires for the check section in a conditional %if section. It will be done soon. Any feedback on the template is welcome.

Created attachment 11598 [details]
golang-libtrust replacement golang-github-docker-libtrust.spec

Suggestion for golang-libtrust

(In reply to Jybz from comment #10)
> For the Macros :
> %gopkg
> %gopkginstall
> %gopkgfiles
> When I started (on mga7) to package, I can't used it, I always had something
> like "/var/tmp/rpm-tmp.1LdXMr: line 90: fg: no job control", I conclude (too
> quickly) that this macros are only for RedHat/Fedora. Now I know, it is new
> features. How to manage Mga7 and Cauldron ? Should we write two different
> specs ? (There is still no planned date for Mga8, so I have to package for
> Mga7 to continue the build of the tools I want to use.)

Yes that's a problem every time we have incompatible changes :(

I guess the new macro packages could go to 7 backports media to allow backporting go packages...
 
> Oh ! I just found it !
> No need to do a Symlink !
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
> #_handling_package_renames
> %global goaltipaths     github.com/Sirupsen/logrus
> This variable works with the macro %gopkgfiles.
> It generates a specific package named compat-%{goname} (related to the
> alternative path) which contains only one file, a symlink to the real source
> from the primary package containing the source code.
> But for Mga7, we need such symlink.


Nice

> In attachment, a spec suggestion for golang-libcontainer
> So, it should be good for the package golang-github-urfave-cli (pterjan, you
> are the maintainer) to set 
> > %global goaltipaths     github.com/codegangsta/cli
> 
> 
> > I think it could be as simple as this:
> > 
> > %global goipath         github.com/tchap/go-patricia
> > Version:                2.3.0
> 
> I know that my multiples lines
> > %global goipath         github.com/tchap/go-patricia
> > %global provider        github.com
> > %global project         tchap
> > %global repo            go-patricia
> > # https://github.com/tchap/go-patricia
> > %global forgeurl        https://%{provider}/%{project}/%{repo}
> > Version:                2.3.0
> are repetitive, but it isn't a lot of extra work. But there are few project
> using another forgeurl than goipath, it helps me. Is it a bad practice ?

It is usually bad to put more than needed as it is more to update when something changes (including if macros change again) so we normally only define the minimal needed.
In a template I would comment it out and say to use it only when it is different.

For golang-sqlite, the source code webpage (from google) is deleted. No trace of the source code since 2013, latest trace, the docker repo on github tried alternatives in 2014.

I believe, this package was originally made for Docker (how can I check it ?), and is not used anymore.

Created attachment 11600 [details]
golang-github-syndtr-gocapability replacement for golang-syndtr-gocapability

(In reply to Pascal Terjan from comment #5)
> I think most of those inconsistencies are due to history as paths and macros
> have evolved over time but not all packages were updated (Some packages were
> imported before any of those macros existed).
> 
> Cleaning things up is always welcome, duplicates being the easiest ones to
> fix.

When I started to package docker for Mageia, I had no clue how to make go packages, so IIRC I looked at Fedora, and the upstream receipt to build docker, and as Pascal said it's historical if I messed up stuff at that time, sorry for that :-(

Sorry for the late reply:

(In reply to Jybz from comment #6)
> I please bcornec to check if the following packages are required
> (BuildRequires/Requires) for other packages. (I believe there is no
> dependencies to these packages, but I dont know how to ensure.)
> > golang-blackfriday     
> > golang-logrus          
> > golang-net             
> > go-md2man              
> > golang-godbus          
> > golang-go-systemd      
> > golang-testify

IIRC (back in 2014), I created (some of) these packages just to be able to build docker. Now docker comes with everything embedded, so IMHO they could go, if no other one uses it (and that I don't know, as I'm not at all a Go expert, and my only goal was to have docker that I use extensively nearly everyday).

> I wish you can also check :
> > golang-gorilla-context
> > golang-gorilla-mux    
> as there is no maintainers.

Humm sorry, no can't tell for these.

> 
> I will look closer the specs of docker, and see if this only two lines do
> the job (jump from /usr/lib(64)/golang to /usr/share/gocode:
> %global goroot  %{_datadir}/gocode
> %global gopath  %{goroot}

For docker, as long as it still works after your modifications, I'm fine with the improvements you're working on ;-)

Just a note docker uses the opencontainers-runc package (which may also conflict with golang-github-opencontainers-runc.

Again, I have nothing for or against using one or the other, as long as you use 1.0.0-rc10

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED