Giter VIP home page Giter VIP logo

go-macros's Introduction

About

Gofed is a tool set aimed at automation of packaging of golang projects and analysis of Go ecosystem.

Per project support:

  • Spec file generator for the github.com, code.google.com, and bitbucket.org repositories
  • Fedora's Review Request generator for new golang packages
  • Comparison of APIs (exported symbols) of two golang projects
  • Go source code analysis: dependency discovery (imported projects), tests and main package detection
  • Dependency approximation: approximate Godeps.json for your project

Per distribution support:

  • Multicommands: run scratch-builds, builds, updates, etc. on multiple branches with one command
  • Update your package with one command using a wizard
  • Project snapshot checker: check current state of all dependencies of your project (up2date, outdated, missing)
  • Spec file bumper: update you spec file just be specifying commit
  • Create trackers for your Go projects in distribution
  • Lint your spec file: detection of missing Provides, [Build]Requires

Per ecosystem support:

  • Distribution analysis: dependency graph builders, new go project discovery

Quick start

  1. Clone the repository
  2. Install python modules
  3. Install packages
  4. Set up gofed
  5. Alias ./hack/gofed.sh
  6. Run gofed
$ git clone https://github.com/gofed/gofed; cd gofed
$ sudo dnf install python-pip python-devel redhat-rpm-config
$ pip install --user -r requirements.txt
$ sudo dnf install -y graphviz koji rpm-build rpmdevtools go-compilers-golang-compiler
$ ./hack/prep.sh
$ alias gofed=$(realpath ./hack/gofed.sh)
$ gofed

Note: gofed currently requires python2, so pip2 should be used to install the required packages.

Or if you prefer a containerized solution, you can run:

$ sudo docker pull gofed/gofed:v1.0.1
$ sudo docker run -it gofed/gofed:v1.0.1 /bin/bash

Experimental: run gofed command as a container

Currently supported commands:

  • gofed repo2spec (and its equivalents)
  • gofed inspect

Example:

./hack/gofed-docker.sh repo2spec --detect github.com/kr/text -f [--force]

In order to run gofed command as a container, one needs to add itself to the docker group:

$ sudo groupadd docker
$ sudo useradd -G docker USERNAME
$ newgrp docker

Resource management

Some gofed commands require working with resources. To provide a transparent interface, commands accept resource declarations only. Processed resources (source code tarball, rpms, etc.) may be stored under local directories dependening on the gofed system configuration. Check out infra.conf under the third_party/gofed_infra/system/config directory. By default, directories under /var/lib/gofed are expected. When running ./hack/prep.sh all resource working directories are set to point to their equivalents under the working_directory directory.

Resources that have been processed are not cleaned automatically. There are two ways to provide a cleaning mechanism:

  • cleaning daemons
  • one time command

Cleaning daemons

Check out gofed-resources-client.service and gofed-resources-provider.service under the third_party/gofed_infra/system/daemons directory. The services are meant to be run as user services as systemctl --user start gofed-resources-[client|provider].service. Before running the services make sure both are installed under the /usr/lib/systemd/user directory.

Required service are generated by hack/prep.sh.

Services cannot be run within containerized gofed.

One time command

Optionally, the daemons can be replaced with the gofed clean-resources command. The command cleans all resources retrived by gofed. On the other hand, the command has to be run manually every time.

Gofed land tour

Simple intro to the tools

Spec file generator

One of the common use cases is to generate a spec file. The fastest way to generate one for a Go project (e.g. https://github.com/cpuguy83/go-md2man) is to run:

$ gofed repo2spec --detect https://github.com/cpuguy83/go-md2man --commit 2724a9c9051aa62e9cca11304e7dd518e9e41599 -f --with-build

The project is already packaged in Fedora. Thus, use the --force option too.

Output:

Repo URL: github.com/cpuguy83/go-md2man
Commit: 2724a9c9051aa62e9cca11304e7dd518e9e41599
Name: golang-github-cpuguy83-go-md2man

(1/4) Checking if the package already exists in PkgDB
(2/4) Collecting data
(3/4) Generating spec file
(4/4) Discovering golang dependencies
Discovering package dependencies
	Class: github.com/russross/blackfriday (golang-github-russross-blackfriday) PkgDB=True

Spec file golang-github-cpuguy83-go-md2man.spec at /tmp/test/golang-github-cpuguy83-go-md2man/fedora/golang-github-cpuguy83-go-md2man

At the beginning, golang checks the Fedora repository to see if the package already exists. If not, it creates a spec file (needs to have missing data filled in), retrieves tarball with source code, and checks the current state of all dependencies (classes of imports decomposed by a repository - common import path prefix).

The gofed repo2spec command generates the spec file only. To download project's tarball, change your working directory to /tmp/test/golang-github-cpuguy83-go-md2man/fedora/golang-github-cpuguy83-go-md2man and run gofed fetch --spec:

$ gofed fetch --spec
Detecting spec file in the current directory...
'golang-github-cpuguy83-go-md2man.spec' detected
Parsing spec file
ipprefix: github.com/cpuguy83/go-md2man
commit: 2724a9c9051aa62e9cca11304e7dd518e9e41599
Fetching https://github.com/cpuguy83/go-md2man/archive/2724a9c9051aa62e9cca11304e7dd518e9e41599/go-md2man-2724a9c.tar.gz ...

The spec file and tarball are ready for analysis.

Dependency discovery

To discover imports and dependencies of the previous project, run the following command inside of the repository's tarball:

$ tar -xf go-md2man-2724a9c.tar.gz
$ cd go-md2man-2724a9c9051aa62e9cca11304e7dd518e9e41599
$ gofed ggi -c -s -d -v

Output:

Class: github.com/russross/blackfriday (golang-github-russross-blackfriday) PkgDB=True

When running with the -d option, gofed checks if the dependency is already packaged in the PkgDB database. To show only dependencies that are not packaged in PkgDB, run the command without the -v option.

When running gofed ggi without any options, list of all dependencies of devel part as shown:

$ gofed ggi
	github.com/russross/blackfriday

To show all dependencies, run the command with the --all-occurrences option:

$ gofed ggi --all-occurrences
	github.com/cpuguy83/go-md2man/md2man
	github.com/russross/blackfriday

Check project dependencies in Fedora

To check if all dependencies of a package are up-to-date in Fedora (for example etcd), run the following command on the package's Godeps.json file:

$ gofed check-deps --godeps Godeps.json

Output:

github.com/spf13/cobra is newer in distribution
github.com/kballard/go-shellquote is up-to-date
github.com/matttproud/golang_protobuf_extensions is newer in distribution
golang.org/x/crypto is newer in distribution
golang.org/x/net is up-to-date
github.com/codegangsta/cli is newer in distribution
github.com/beorn7/perks is up-to-date
github.com/russross/blackfriday is up-to-date
github.com/coreos/go-systemd is newer in distribution
bitbucket.org/ww/goautoneg is up-to-date
github.com/shurcooL/sanitized_anchor_name is up-to-date
github.com/olekukonko/tablewriter is up-to-date
github.com/olekukonko/ts is up-to-date
github.com/google/btree is up-to-date
github.com/gogo/protobuf is up-to-date
...

By default, the rawhide distribution is checked.

To speed up the check, it is recommended to scan the distribution first (see below).

Distribution analysis

Scan distribution for available projects

To scan the distribution for available Go projects, run the following command:

$ gofed scan-distro -v

The command checks the distribution (Fedora rawhide by default) for all Go projects packaged in the distribution with the generic name prefixed with golang-*. To provide a list of additional packages, use the --custom-packages option. Then, the list of the latest builds for packages is retrieved. Data from the builds are extracted and ready for analysis.

Data retrieved by gofed scan-distro is usually prerequisite for other scans such as:

  • gofed scan-packages
  • gofed scan-deps

or checks:

  • gofed check-deps

IMPORTANT: in order to run the command, all rpms must be scanned succesfully. If it does not hold, gofed scan-distro does not generate the distribution snapshot which is needed by the commands listed above. Thus, run the command with --skip-failed option to make sure the snapshot is generated.

Golang dependency graph

To display a dependency graph for a package, for example docker-io, run:

$ gofed scan-deps -v -g -o docker.png docker

This command generates a PNG picture, in this case named docker.png, with the dependency graph.

docker-io dependencies

IMPORTANT: before displaying the generated picture, checkout its size. Huge images tend to freeze your computer.

Golang project decomposition

To display a decomposition of a project into a dependency graph, for example prometheus, run the following command in project's directory:

$ gofed scan-deps -v -d github.com/prometheus/prometheus --from-dir . -g -o prometheus.png

This command generates a PNG picture, in this case named prometheus.png, with the dependency graph.

prometheus decomposition

API check

To see differences in exported symbols between two releases, commits, or versions of the same project, use the "gofed apidiff" command in the following format:

$ gofed apidiff --reference="upstream:project[:commit]" --compare-with="upstream:project[:commit]"

For example, to check API of etcd between etcd-2.3.3 and etcd-2.2.4, run:

$ gofed apidiff --reference="upstream:github.com/coreos/etcd:c41345d393002e87ae9e7023234b1c1e04ba9626" --compare-with="upstream:github.com/coreos/etcd:bdee27b19e8601ffd7bd4f0481abe9bbae04bd09"

Commit c41345d393002e87ae9e7023234b1c1e04ba9626 correponds to etcd-v2.3.3, commit bdee27b19e8601ffd7bd4f0481abe9bbae04bd09 to etcd-v2.2.4.

Output

-etcdctlv3/command: function removed: NewDeleteRangeCommand
-etcdctlv3/command: function removed: NewRangeCommand
-etcdserver/api/v3rpc: function removed: New
-etcdserver/api/v3rpc: function removed: handler.Compact
-etcdserver/api/v3rpc: function removed: handler.DeleteRange
-etcdserver/api/v3rpc: function removed: handler.Put
-etcdserver/api/v3rpc: function removed: handler.Range
-etcdserver/api/v3rpc: function removed: handler.Txn
...

To get new symbols and other information, use the -a option:

...
+etcdctlv3/command: new function: NewGetCommand
+etcdctlv3/command: new function: simplePrinter.Get
+etcdctlv3/command: new function: NewCompactionCommand
+etcdctlv3/command: new function: simplePrinter.Watch
~etcdctlv3/command: function updated: -type differs: selector != pointer
~etcdctlv3/command: function updated: -type differs: selector != pointer
-etcdctlv3/command: function removed: NewDeleteRangeCommand
-etcdctlv3/command: function removed: NewRangeCommand
+etcdctlv3/command: new variable: ExitIO
+etcdctlv3/command: new variable: ExitInvalidInput
+etcdctlv3/command: new variable: ExitBadArgs
+etcdctlv3/command: new variable: ExitError
+etcdctlv3/command: new variable: ExitBadConnection
...

Lines starting with the minus symbol ("-") break backward compatibility. Lines starting with the plus symbol ("+") are new. Lines starting with the tilde symbol ("~") are updated.

go-macros's People

Contributors

ingvagabund avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

go-macros's Issues

find: warning: you have specified the -maxdepth option after a non-option argument -iname

$ find . -iname '*.md' -type f -maxdepth 1
find: warning: you have specified the -maxdepth option after a non-option argument -iname, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.

Moving the -maxdepth before -iname silences the warning:

$ find . -maxdepth 1 -type f -iname '*.md'

Warning coming from here: https://github.com/gofed/go-macros/blob/master/bin/go-rpm-integration#L178

Error while running %gometa with the -i option

-i seems to cause issues when building the SRPM:

$ fedpkg --release f29 srpm                                                                                                                                        
sources file doesn't exist. Source files download skipped.
Failed to get module name from Git url or pushurl
Could not execute srpm: Could not get n-v-r-e from '\n\nForge-specific packaging variables\n\n  forgeurl:        https://github.com/bazil/fuse\n\n  forgesource:     https://github.com/bazil/fuse/archive/371fbbdaa8987b715bdd21d6adc4c9b20155f748/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748.tar.gz\n\n  forgesetupargs:  -n fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748\n\nGeneric variables\n\n  archivename:     fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748\n\n  archiveext:      tar.gz\n\n  archiveurl:      https://github.com/bazil/fuse/archive/371fbbdaa8987b715bdd21d6adc4c9b20155f748/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748.tar.gz\n\n  scm:             git\n\n  tag:             \n\n  commit:          371fbbdaa8987b715bdd21d6adc4c9b20155f748\n\n  dist:            .20180308git371fbbd.fc29 (snapshot date is computed once %{_sourcedir}/%{archivename}.%{archiveext} is available)\n\nGo-specific packaging variables\n  goipath:         bazil.org/fuse\n  goname:          golang-bazil-fuse\n  gourl:           https://github.com/bazil/fuse\n  gosource:        https://github.com/bazil/fuse/archive/371fbbdaa8987b715bdd21d6adc4c9b20155f748/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748.tar.gz\ngolang-bazil-fuse (none) 0 0.3.20180308git371fbbd.fc29'

EPEL availability

I've got asked to package a Golang app for EPEL, what are the plan for making the macros available in EPEL?

[RFE] Store commit and ipprefix in the .goipath

To make every devel rpm contain all information needed for automatic analysis. Currently, the commit/hexsha and the ipprefix are parsed from corresponding srpm, which introduces unintended complexity. No analysis solution should need more than is provided by the rpm.

For that, I suggest to put yaml/json structures into the .goipath. E.g.

meta:
- hexsha: 645ef00459ed84a119197bfb8d8205042c6df63d
- ipprefix: github.com/pkg/errors
- additional_options:
  ...

and have the content automatically generated by the macros.

Add a flag to exclude Go packages that import a specific import path

For bootstrapping it is usually necessary to disable everything that relies on other import paths, that are not available yet (but need the built package for their own build)

Likewise part of a Go project may use an import path, we don't want to exist in the distribution

Therefore, I'd like golist to support an -x --exclude-import-path that removes from its output any element that imports the excluded import path.

At least for checks and maybe for install and requires

Repeatable flag like the others

Use GO_BUILD_PATH in install

right now goinstall.sh goes out of its way to create a $PWD/_build directory and golist uses it as GOPATH

However:

  1. that's not the same GOPATH as in other golist invocations, so it is inconsistent
  2. $PWD/_build is already created by %gobuildroot rpm macros, and exported as GO_BUILD_PATH

→ golist should use GO_BUILD_PATH as source of installation files in --to-install mode, to be consistent with the rest and avoid duplicated code

Update all Go packages in Fedora to use the new macros [Rawhide]

  • rpms/golang-bitbucket-kardianos-osext
  • rpms/golang-bitbucket-ww-goautoneg
  • rpms/golang-github-10gen-openssl
  • rpms/golang-github-3rf-mongo-lint
  • rpms/golang-github-abbot-go-http-auth
  • rpms/golang-github-AdRoll-goamz
  • rpms/golang-github-agl-ed25519
  • rpms/golang-github-akrennmair-gopcap
  • rpms/golang-github-appc-spec
  • rpms/golang-github-armon-circbuf
  • rpms/golang-github-armon-gomdb
  • rpms/golang-github-armon-go-metrics
  • rpms/golang-github-armon-go-radix
  • rpms/golang-github-asaskevich-govalidator
  • rpms/golang-github-AudriusButkevicius-cli
  • rpms/golang-github-AudriusButkevicius-go-nat-pmp
  • rpms/golang-github-AudriusButkevicius-pfilter
  • rpms/golang-github-auth0-go-jwt-middleware
  • rpms/golang-github-aws-aws-sdk-go
  • rpms/golang-github-Azure-azure-sdk-for-go
  • rpms/golang-github-beorn7-perks
  • rpms/golang-github-bep-gitmap
  • rpms/golang-github-bep-inflect
  • rpms/golang-github-bgentry-speakeasy
  • rpms/golang-github-bkaradzic-go-lz4
  • rpms/golang-github-blang-semver
  • rpms/golang-github-bmizerany-assert
  • rpms/golang-github-bmizerany-pat
  • rpms/golang-github-bmizerany-perks
  • rpms/golang-github-boltdb-bolt
  • rpms/golang-github-bradfitz-gomemcache
  • rpms/golang-github-bradfitz-http2
  • rpms/golang-github-bugsnag-bugsnag-go
  • rpms/golang-github-bugsnag-panicwrap
  • rpms/golang-github-BurntSushi-toml
  • rpms/golang-github-BurntSushi-toml-test
  • rpms/golang-github-calmh-du
  • rpms/golang-github-calmh-luhn
  • rpms/golang-github-calmh-xdr
  • rpms/golang-github-ccding-go-stun
  • rpms/golang-github-cenkalti-backoff
  • rpms/golang-github-chaseadamsio-goorgeous
  • rpms/golang-github-cheggaaa-pb
  • rpms/golang-github-chmduquesne-rollinghash
  • rpms/golang-github-circonus-labs-circonus-gometrics
  • rpms/golang-github-circonus-labs-circonusllhist
  • rpms/golang-github-cloudfoundry-incubator-candiedyaml
  • rpms/golang-github-cockroachdb-cmux
  • rpms/golang-github-codegangsta-cli
  • rpms/golang-github-codegangsta-negroni
  • rpms/golang-github-collectd-go-collectd
  • rpms/golang-github-coreos-gexpect
  • rpms/golang-github-coreos-go-etcd
  • rpms/golang-github-coreos-go-iptables
  • rpms/golang-github-coreos-go-log
  • rpms/golang-github-coreos-go-oidc
  • rpms/golang-github-coreos-go-semver
  • rpms/golang-github-coreos-go-systemd
  • rpms/golang-github-coreos-pkg
  • rpms/golang-github-cpuguy83-go-md2man
  • rpms/golang-github-cznic-b
  • rpms/golang-github-cznic-fileutil
  • rpms/golang-github-cznic-golex
  • rpms/golang-github-cznic-internal
  • rpms/golang-github-cznic-lex
  • rpms/golang-github-cznic-lexer
  • rpms/golang-github-cznic-lldb
  • rpms/golang-github-cznic-mathutil
  • rpms/golang-github-cznic-ql
  • rpms/golang-github-cznic-sortutil
  • rpms/golang-github-cznic-strutil
  • rpms/golang-github-cznic-zappy
  • rpms/golang-github-d2g-dhcp4
  • rpms/golang-github-d2g-dhcp4client
  • rpms/golang-github-d4l3k-messagediff
  • rpms/golang-github-DataDog-datadog-go
  • rpms/golang-github-DATA-DOG-go-sqlmock
  • rpms/golang-github-davecgh-go-spew
  • rpms/golang-github-daviddengcn-go-colortext
  • rpms/golang-github-dchest-cssmin
  • rpms/golang-github-denverdino-aliyungo
  • rpms/golang-github-dgnorton-goback
  • rpms/golang-github-dgrijalva-jwt-go
  • rpms/golang-github-digitalocean-godo
  • rpms/golang-github-docker-go
  • rpms/golang-github-docker-go-connections
  • rpms/golang-github-docker-go-units
  • rpms/golang-github-docker-libcontainer
  • rpms/golang-github-docker-libkv
  • rpms/golang-github-docker-libtrust
  • rpms/golang-github-docker-spdystream
  • rpms/golang-github-docopt-docopt-go
  • rpms/golang-github-dustin-go-humanize
  • rpms/golang-github-dvsekhvalnov-jose2go
  • rpms/golang-github-eapache-go-resiliency
  • rpms/golang-github-eapache-queue
  • rpms/golang-github-edsrzf-mmap-go
  • rpms/golang-github-eknkc-amber
  • rpms/golang-github-elazarl-go-bindata-assetfs
  • rpms/golang-github-emicklei-go-restful
  • rpms/golang-github-endophage-gotuf
  • rpms/golang-github-evanphx-json-patch
  • rpms/golang-github-fatih-pool
  • rpms/golang-github-fortytw2-leaktest
  • rpms/golang-github-fsnotify-fsnotify
  • rpms/golang-github-fsouza-go-dockerclient
  • rpms/golang-github-garyburd-redigo
  • rpms/golang-github-gengo-grpc-gateway
  • rpms/golang-github-getsentry-raven-go
  • rpms/golang-github-ghodss-yaml
  • rpms/golang-github-glacjay-goini
  • rpms/golang-github-go-asn1-ber-asn1-ber
  • rpms/golang-github-gobwas-glob
  • rpms/golang-github-godbus-dbus
  • rpms/golang-github-go-errors-errors
  • rpms/golang-github-go-fsnotify-fsnotify
  • rpms/golang-github-go-ini-ini
  • rpms/golang-github-golang-appengine
  • rpms/golang-github-golang-glog
  • rpms/golang-github-golang-groupcache
  • rpms/golang-github-golang-sys
  • rpms/golang-github-golang-time
  • rpms/golang-github-go-ldap-ldap
  • rpms/golang-github-go-macaron-inject
  • rpms/golang-github-go-mgo-mgo
  • rpms/golang-github-gonum-blas
  • rpms/golang-github-gonum-floats
  • rpms/golang-github-gonum-graph
  • rpms/golang-github-gonum-internal
  • rpms/golang-github-gonum-lapack
  • rpms/golang-github-gonum-matrix
  • rpms/golang-github-google-btree
  • rpms/golang-github-google-gofuzz
  • rpms/golang-github-google-go-genproto
  • rpms/golang-github-google-go-github
  • rpms/golang-github-google-go-querystring
  • rpms/golang-github-goraft-raft
  • rpms/golang-github-gorilla-context
  • rpms/golang-github-gorilla-handlers
  • rpms/golang-github-gorilla-mux
  • rpms/golang-github-gorilla-securecookie
  • rpms/golang-github-gorilla-sessions
  • rpms/golang-github-gorilla-websocket
  • rpms/golang-github-gosexy-gettext
  • rpms/golang-github-go-sql-driver-mysql
  • rpms/golang-github-go-stack-stack
  • rpms/golang-github-go-tomb-tomb
  • rpms/golang-github-grpc-ecosystem-go-grpc-prometheus
  • rpms/golang-github-grpc-ecosystem-grpc-gateway
  • rpms/golang-github-grpc-grpc-go
  • rpms/golang-github-guelfey-godbus
  • rpms/golang-github-hashicorp-consul-migrate
  • rpms/golang-github-hashicorp-errwrap
  • rpms/golang-github-hashicorp-go-checkpoint
  • rpms/golang-github-hashicorp-go-cleanhttp
  • rpms/golang-github-hashicorp-go-immutable-radix
  • rpms/golang-github-hashicorp-golang-lru
  • rpms/golang-github-hashicorp-go-memdb
  • rpms/golang-github-hashicorp-go-msgpack
  • rpms/golang-github-hashicorp-go-multierror
  • rpms/golang-github-hashicorp-go-retryablehttp
  • rpms/golang-github-hashicorp-go-sockaddr
  • rpms/golang-github-hashicorp-go-syslog
  • rpms/golang-github-hashicorp-go-uuid
  • rpms/golang-github-hashicorp-go-version
  • rpms/golang-github-hashicorp-hcl
  • rpms/golang-github-hashicorp-hil
  • rpms/golang-github-hashicorp-logutils
  • rpms/golang-github-hashicorp-mdns
  • rpms/golang-github-hashicorp-memberlist
  • rpms/golang-github-hashicorp-net-rpc-msgpackrpc
  • rpms/golang-github-hashicorp-raft
  • rpms/golang-github-hashicorp-raft-boltdb
  • rpms/golang-github-hashicorp-raft-mdb
  • rpms/golang-github-hashicorp-scada-client
  • rpms/golang-github-hashicorp-serf
  • rpms/golang-github-hashicorp-yamux
  • rpms/golang-github-hawkular-hawkular-client-go
  • rpms/golang-github-howeyc-gopass
  • rpms/golang-github-imdario-mergo
  • rpms/golang-github-inconshreveable-mousetrap
  • rpms/golang-github-inconshreveable-muxado
  • rpms/golang-github-influxdb-go-cache
  • rpms/golang-github-influxdb-gomdb
  • rpms/golang-github-influxdb-hyperleveldb-go
  • rpms/golang-github-influxdb-influxdb
  • rpms/golang-github-influxdb-rocksdb
  • rpms/golang-github-jackpal-gateway
  • rpms/golang-github-jacobsa-oglematchers
  • rpms/golang-github-jessevdk-go-flags
  • rpms/golang-github-jfrazelle-go
  • rpms/golang-github-jinzhu-gorm
  • rpms/golang-github-jmespath-go-jmespath
  • rpms/golang-github-jmhodges-levigo
  • rpms/golang-github-jonboulle-clockwork
  • rpms/golang-github-jtolds-gls
  • rpms/golang-github-juju-ratelimit
  • rpms/golang-github-julienschmidt-httprouter
  • rpms/golang-github-karlseguin-ccache
  • rpms/golang-github-karlseguin-expect
  • rpms/golang-github-kballard-go-shellquote
  • rpms/golang-github-kdar-factorlog
  • rpms/golang-github-kimor79-gollectd
  • rpms/golang-github-klauspost-cpuid
  • rpms/golang-github-klauspost-crc32
  • rpms/golang-github-klauspost-reedsolomon
  • rpms/golang-github-knieriem-markdown
  • rpms/golang-github-kraman-libcontainer
  • rpms/golang-github-kr-fs
  • rpms/golang-github-kr-pretty
  • rpms/golang-github-kr-pty
  • rpms/golang-github-kr-text
  • rpms/golang-github-kubernetes-heapster
  • rpms/golang-github-kyokomi-emoji
  • rpms/golang-github-lib-pq
  • rpms/golang-github-lpabon-godbc
  • rpms/golang-github-lsegal-gucumber
  • rpms/golang-github-magiconair-properties
  • rpms/golang-github-MakeNowJust-heredoc
  • rpms/golang-github-Masterminds-semver
  • rpms/golang-github-Masterminds-vcs
  • rpms/golang-github-mattn-go-isatty
  • rpms/golang-github-mattn-go-runewidth
  • rpms/golang-github-mattn-go-sqlite3
  • rpms/golang-github-matttproud-golang_protobuf_extensions
  • rpms/golang-github-mesos-mesos-go
  • rpms/golang-github-miekg-dns
  • rpms/golang-github-miekg-mmark
  • rpms/golang-github-miekg-pkcs11
  • rpms/golang-github-milochristiansen-axis2
  • rpms/golang-github-milochristiansen-lua
  • rpms/golang-github-minio-sha256-simd
  • rpms/golang-github-mistifyio-go-zfs
  • rpms/golang-github-mitchellh-cli
  • rpms/golang-github-mitchellh-copystructure
  • rpms/golang-github-mitchellh-goamz
  • rpms/golang-github-mitchellh-go-homedir
  • rpms/golang-github-mitchellh-go-wordwrap
  • rpms/golang-github-mitchellh-mapstructure
  • rpms/golang-github-mitchellh-reflectwalk
  • rpms/golang-github-mreiferson-go-httpclient
  • rpms/golang-github-mtrmac-gpgme
  • rpms/golang-github-mvo5-goconfigparser
  • rpms/golang-github-mvo5-uboot-go
  • rpms/golang-github-mxk-go-flowrate
  • rpms/golang-github-ncw-swift
  • rpms/golang-github-noahdesu-go-ceph
  • rpms/golang-github-ojii-gettext.go
  • rpms/golang-github-olekukonko-tablewriter
  • rpms/golang-github-olekukonko-ts
  • rpms/golang-github-olivere-elastic
  • rpms/golang-github-onsi-ginkgo
  • rpms/golang-github-onsi-gomega
  • rpms/golang-github-opencontainers-runtime-spec
  • rpms/golang-github-opencontainers-specs
  • rpms/golang-github-openshift-go-json-rest
  • rpms/golang-github-openshift-go-systemd
  • rpms/golang-github-openshift-openshift-sdn
  • rpms/golang-github-oschwald-geoip2-golang
  • rpms/golang-github-oschwald-maxminddb-golang
  • rpms/golang-github-pelletier-go-buffruneio
  • rpms/golang-github-pelletier-go-toml
  • rpms/golang-github-petar-GoLLRB
  • rpms/golang-github-peterh-liner
  • rpms/golang-github-petermattis-goid
  • rpms/golang-github-pkg-errors
  • rpms/golang-github-pkg-profile
  • rpms/golang-github-pkg-sftp
  • rpms/golang-github-pmezard-go-difflib
  • rpms/golang-github-prometheus-client_golang
  • rpms/golang-github-prometheus-client_model
  • rpms/golang-github-prometheus-common
  • rpms/golang-github-prometheus-procfs
  • rpms/golang-github-prometheus-prometheus
  • rpms/golang-github-PuerkitoBio-purell
  • rpms/golang-github-PuerkitoBio-urlesc
  • rpms/golang-github-racker-perigee
  • rpms/golang-github-rackspace-gophercloud
  • rpms/golang-github-rakyll-globalconf
  • rpms/golang-github-rakyll-pb
  • rpms/golang-github-rakyll-statik
  • rpms/golang-github-RangelReale-osin
  • rpms/golang-github-RangelReale-osincli
  • rpms/golang-github-rcrowley-go-metrics
  • rpms/golang-github-remyoudompheng-bigfft
  • rpms/golang-github-rubyist-tracerx
  • rpms/golang-github-russross-blackfriday
  • rpms/golang-github-ryanuber-columnize
  • rpms/golang-github-samalba-dockerclient
  • rpms/golang-github-samuel-go-zookeeper
  • rpms/golang-github-sasha-s-go-deadlock
  • rpms/golang-github-SeanDolphin-bqschema
  • rpms/golang-github-seccomp-libseccomp-golang
  • rpms/golang-github-shiena-ansicolor
  • rpms/golang-github-Shopify-sarama
  • rpms/golang-github-Shopify-toxiproxy
  • rpms/golang-github-shurcooL-sanitized_anchor_name
  • rpms/golang-github-Sirupsen-logrus
  • rpms/golang-github-skarademir-naturalsort
  • rpms/golang-github-skratchdot-open-golang
  • rpms/golang-github-skynetservices-skydns
  • rpms/golang-github-smarterclayton-go-systemd
  • rpms/golang-github-smartystreets-assertions
  • rpms/golang-github-smartystreets-go-aws-auth
  • rpms/golang-github-smartystreets-goconvey
  • rpms/golang-github-spacejam-loghisto
  • rpms/golang-github-spacemonkeygo-flagfile
  • rpms/golang-github-spacemonkeygo-spacelog
  • rpms/golang-github-spf13-afero
  • rpms/golang-github-spf13-cast
  • rpms/golang-github-spf13-cobra
  • rpms/golang-github-spf13-fsync
  • rpms/golang-github-spf13-jWalterWeatherman (BuildError: package golang-github-spf13-jwalterweatherman not in list for tag f29-pending)
  • rpms/golang-github-spf13-nitro
  • rpms/golang-github-spf13-pflag
  • rpms/golang-github-spf13-viper
  • rpms/golang-github-stathat-go
  • rpms/golang-github-stevvooe-resumable
  • rpms/golang-github-stretchr-objx
  • rpms/golang-github-stretchr-testify
  • rpms/golang-github-syndtr-gocapability
  • rpms/golang-github-syndtr-goleveldb
  • rpms/golang-github-syndtr-gosnappy
  • rpms/golang-github-tchap-go-patricia
  • rpms/golang-github-tent-http-link-go
  • rpms/golang-github-thejerf-suture
  • rpms/golang-github-tonnerre-golang-pretty
  • rpms/golang-github-ugorji-go
  • rpms/golang-github-Unknwon-com
  • rpms/golang-github-urfave-cli
  • rpms/golang-github-vaughan0-go-ini
  • rpms/golang-github-vbatts-tar-split
  • rpms/golang-github-vishvananda-netlink
  • rpms/golang-github-vishvananda-netns
  • rpms/golang-github-vitrun-qart
  • rpms/golang-github-vjeantet-asn1-ber
  • rpms/golang-github-vjeantet-ldapserver
  • rpms/golang-github-vmware-govcloudair
  • rpms/golang-github-wsxiaoys-terminal
  • rpms/golang-github-xeipuuv-gojsonpointer
  • rpms/golang-github-xeipuuv-gojsonreference
  • rpms/golang-github-xeipuuv-gojsonschema
  • rpms/golang-github-xiang90-probing
  • rpms/golang-github-xtaci-kcp-go
  • rpms/golang-github-xtaci-smux
  • rpms/golang-github-yosssi-ace
  • rpms/golang-github-yosssi-gohtml
  • rpms/golang-github-yvasiyarov-go-metrics
  • rpms/golang-github-yvasiyarov-gorelic
  • rpms/golang-github-yvasiyarov-newrelic_platform_go
  • rpms/golang-github-zillode-notify
  • rpms/golang-googlecode-gcfg
  • rpms/golang-googlecode-goauth2
  • rpms/golang-googlecode-go-crypto
  • rpms/golang-googlecode-go-decimal-inf
  • rpms/golang-googlecode-go-exp
  • rpms/golang-googlecode-gogoprotobuf
  • rpms/golang-googlecode-gomock
  • rpms/golang-googlecode-google-api-client
  • rpms/golang-googlecode-goprotobuf
  • rpms/golang-googlecode-log4go
  • rpms/golang-googlecode-net
  • rpms/golang-googlecode-sqlite
  • rpms/golang-googlecode-text
  • rpms/golang-googlecode-tools
  • rpms/golang-googlecode-uuid
  • rpms/golang-google-golangorg-cloud
  • rpms/golang-gopkg-check
  • rpms/golang-gopkg-go-check-check
  • rpms/golang-gopkg-go-macaroon-macaroon
  • rpms/golang-gopkg-retry-v1
  • rpms/golang-gopkg-yaml
  • rpms/golang-launchpad-gocheck
  • rpms/golang-launchpad-go-xdg-v0

Computed snapshot date is wrong

Automatically computed date in dist is always today's date instead of the snapshot date.

For ex:

Forge-specific packaging variables

  forgeurl:        https://github.com/zyedidia/tcell

  forgesource:     https://github.com/zyedidia/tcell/archive/208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01/tcell-208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01.tar.gz

  forgesetupargs:  -n tcell-208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01

Generic variables

  archivename:     tcell-208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01

  archiveext:      tar.gz

  archiveurl:      https://github.com/zyedidia/tcell/archive/208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01/tcell-208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01.tar.gz

  scm:             git

  tag:             

  commit:          208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01

  dist:            .20180310git208b6e8.fc29 (snapshot date is computed once %{_sourcedir}/%{archivename}.%{archiveext} is available)

Snapshot date for 208b6e8f2f8d763a4accac33f3bdbd7dc9c71c01 should be 20180124, not the current day.

Do not special case supplementary import pathes

Let's just make the macros accept an unlimited number of
-i flags

instead of trying to pack them in a single flag, which is less flexible and requires complex unpacking in the shell code

Finer-grained test filtering

Right now the macros use golist to detect the packages that contain tests

Testing a package is an all or nothing thing

However golist already knows how to exclude specific files via its regexp switches

It would be nicer if it was possible to blacklist a single test file and execute all the other tests in the same subdirectory

golist --to-install should list glide.*, Godeps.json and other snapshot files

Currently, there is only a limited number of projects that provide a snapshot with all their dependencies (and commits). We should enforce in the guidelines that each devel subpackage must ship either available snapshot file or generate one if not provided by upstream (and ship it).

I have an experimental implementation of gofed approx-deps that approximate glide.lock file for a specific project and its commit. It generates the snapshot of all dependencies one would get if he/she run go get at the date corresponding to the commit. So far I was able to build archives from all defined packages based on the generated glide.lock and glide.yaml files.

It's essential to provide such a file since if the tooling can assume the snapshot file is available and corresponding project can be built from the enumerated dependencies, the tooling can run various advanced analysis such as API backward incompatibility detection.

This will require collaboration with all packagers (and maybe upstream) and testing. The expected benefit is automatical detection of incompatible API changes before a Go package is even updated and/or pushed into stable.

The Go utilities used by the macros should accept arbitrary numbers of flags

Real life is messy and excluding just the right bits of a Go project to make it work can take quite a lot of exclusion directives. Their number should not be limited

Also, since rpm does not like long flag names in macros, and to simplify the correspondance between the spec code and the Go code, single-letter flag names should be accepted

For example:
-d exclude/ignore the content of a whole directory (not recursive, subdirectories are not ignored)
-t exclude/ignore the content of a whole directory tree (recursive, subdirectories are ignored too
-r exclude/ignore whatever marches the Go regexp
-f exclude/ignore a specific file (though that is quite rare and can be done via regexes in the short term)

allow supplying additional -tags arguments to %gobuild

At the moment, the -tags argument in the %gobuild macro is hard-coded to -tags=rpm_crashtraceback.

It would be nice to be able to supply additional tags, for example syncthing expects to be compiled with a noupgrade tag when built for distro packages.

Solving this with an additional GOTAGS environment variable (similarly to how LDFLAGS are read from the environment, too, if the variable is defined) would be easiest, I think.

golist should treat all filles under all variations of testdata as data

testdata in all its forms is the accepted Go way to ship data, not code. When there is something like code in it it is usually very broken code to test breakage detection

So, golist should never attempt to parse or execute this what looks like go code under testdata, it will only result in panics and broken dependencies

goname removes -go from my package name

The following piece of code:

tokens["go"] = true
tokens["git"] = true
for token in string.gmatch(goname, "[^%-]+") do
if not tokens[token] then
result = result .. "-" .. token
tokens[token] = true
end
end

causes issue with my package golang-github-bitly-go-simplejson. It removes the "go" from the package name when building it, thus I can't import it in Koji.

date included in computed %{?dist} when packaging a stable version

I want to update a package to the latest stable release, and to use the new macros. However, when I do this:

# https://github.com/cznic/ql
%global goipath github.com/cznic/ql
%global tag     v1.2.0

%gometa -i

Name:           %{goname}
Version:        1.2.0
Release:        1%{?dist}

I get a NEVR of golang-github-cznic-ql-1.2.0-1.20180813gitv1.2.0.fc29, when I would expect golang-github-cznic-ql-1.2.0-1.fc29 for a stable release like this.

Am I missing something, or is this a bug? I expect the value of %{?dist} to be 1.fcXX when packaging a normal tagged release and not a snapshot.

[RFE] Have each devel rpm provide its own glide.lock file

Every devel rpm should provide a dependency snapshot file (e.g. glide.lock) so a tooling performing analysis know which dependencies of which commits were used to compile the source code.

E.g. put the glide.lock into the same directory where the .goipath file is.

Why remove -git- from %{goname}?

I'm packaging go-netrc from git-lfs here and the new macros export %{goname} as golang-github-lfs-netrc. I understand that -go- is removed because it's all over the place in Go package names.

I don't understand why -git- is removed from %{goname} though. Looking at #3, none of them have a -git- in the name. Looking at the full list of Go packages (about double what's in #3), there are only 3 with -git- in the name. So it doesn't look like using -git- in the name is some big problem with Go packages that it needs to be stripped out.

-devel subpackage builds differently on different arches

I'm getting the following error for koji scratch builds:

29084644 build (rawhide, golang-github-cznic-ql-1.2.0-1.fc30.src.rpm): open (buildvm-armv7-07.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: golang-github-cznic-ql-devel-1.2.0-1.fc30.noarch.rpm
rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
removed     /usr/share/gocode/src/github.com/cznic/ql/vendored/github.com/camlistore/go4/lock/lock_linux_amd64.go
  0 free  0 open  6 done  1 failed

[RFE] Optionally provide a snapshot of dependencies

Each project SHOULD provide a list of all dependencies with their corresponding commits/revisions.
So:

  • it is known exactly which dependencies were used to build/implement a library/binary
  • automatic analysers checking backward compatibility can run over all Go packages to detect API violetions
  • it is known which commit/revision of each dependency are at least expected to be packaged in a distribution

Q: What to do if the snapshot is not upstream provided?
A: Generated your own snapshot from which a Go project can be built (ability to build a project is more than nothing)

Q: What happens if the snapshot is not provided?
A: A snapshot gets constructed based on the commit date of a Go project (looking for the commits of dependencies that are at most up to the date)

[RFE] Hide complexity of Go spec file into auto generated fragments

TODO:

  • - autogenerate provided packages
  • - autogenerate imported packages
  • - complain if there are any arch specific files ignored (so the rpm can fail if the devel subpackage is noarch)
  • - list resource to-be-installed in rpm(s) that the Project needs to be compiled and run (Godeps.json, glide.lock and other will get listed separately)

Justifications

  • unit tests shipped in the devel subpackages:
    All files of rpm subpackages are located under the same buildroot so it is impossible to determine which file (resp. directory tree) belongs to which subpackage. At the same time the __NAME_requires macro is stateless and invoked for each file/directory (without subdirectories) separately. Thus, all _test.go (and their testing resources) will be provided by the devel subpackages. At the same time, all packages imported by the tests will be ignored and left to a packager to provide/install them in case the unit tests get run outside of the rpm building process.

Do not install non production code by default

I see that the new code that relies on golist to list elements to install now installs test code and examples by default. And, to workaround their usual breakage, do not generate the corresponding requires

This is wrong and a bad idea on several plans:

  • non production code should not be installed by default
  • if it is installed, it should work (ie declare the needed deps)

I know a few projects import examples of other projects in their tests but this is really a marginal case and should not direct the general installation policy. And, I could workaround it via the exclusion flags, but sorting those common cases really belongs in the heart of the code analysis engine.

However, the good news is that now we started using lockfiles, it is possible to distinguish between "this package ships this go directory for tests" and "this package ships this go directory for production code" in autodeps

Therefore, I propose the following changes in golist:

  • golist lists neither example file nor test files by default
  • when passed the -s flag (for system unit test install, like we already use for checks, maybe rename it to -u), it lists only unit tests and testdata
  • when passed the -x flag it lists only example file

And then change the shell installation logic to:

  • install only production code by default
  • install only unit tests with -s, and create a .goipath-tests lockfile
  • install only example files with -x, and create a .goipath-examples lockfile

With the following autodeps logic:

  • in presence of a .goipath-tests call golist with -s, generate requires for tests, do not generate provides (unless you have a use for golang-test(foo) provides)
  • in presence of a .goipath-examples lockfile call golist with -x, generate requires for example code, generate provides for example code (for the projects that import example code)

That would allow splitting cleanly unit tests and examples in their own separate subpackages and have clean production-only -devel subpackages

Permit relative ignore rules

Prepending each ignore rule with the import path quickly gets tedious, compexifies the specification of general cross-project rules, and not needed except by the few packages that try to ship multiple different projevts in a single package (which breaks a lot of rpm asumptions BTW)

Please keep the generic ignore flags relative to the project root, and add separate prefixed ignore flags for the few packages that need then

-d, -t, -r → ignore without import path prefix
-D, -T, -R → ignore with explicit import path prefix

compat Go subpackages

List of packages with compate subpackages:

  • golang-github-bradfitz-gomemcache
  • TBD

This kinda complicates automatic analysis cause the compat rpm does not contain any source code, just a symlink to a newly named package. We should not create a compat subpackage just because a devel subpackage got renamed. My original impression was a compat package ships source code from a different tarball which is fixed in a commit and no longer updated (up to security fixes and/or on have-to-have patches bases).

We need to revisit application of the compat subpackages. In general, avoid usage of it.

go-macros produces different noarch packages on different arches

See scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=25619962 :

BuildError: The following noarch package built differently on different architectures: golang-bazil-fuse-devel-0-0.3.20180310git371fbbd.fc29.noarch.rpm
rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
removed     /usr/share/gocode/src/bazil.org/fuse/syscallx/msync_amd64.go

The file syscallx/msync_amd64.go is only included on x86_64 resulting indifferent noarch packages. All the files should be the same for all noarch packages, whatever the arch it is build from. No files should be removed from the source, even the not useful ones for that arch.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.