Merge lp:~sergiusens/nuntium/packaging_fixes into lp:nuntium
Status: | Merged |
---|---|
Merged at revision: | 32 |
Proposed branch: | lp:~sergiusens/nuntium/packaging_fixes |
Merge into: | lp:nuntium |
Diff against target: |
107 lines (+24/-20) 7 files modified
debian/changelog (+1/-2) debian/control (+8/-1) debian/nuntium-decode-cli.lintian-overrides (+0/-3) debian/nuntium.conf (+1/-5) debian/nuntium.lintian-overrides (+0/-3) debian/rules (+13/-5) storage/storage.go (+1/-1) |
To merge this branch: | bzr merge lp:~sergiusens/nuntium/packaging_fixes |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Matthias Klose | Approve | ||
Ubuntu Phablet Team | Pending | ||
Review via email: mp+218693@code.launchpad.net |
Commit message
Packaging fixes:
- using gccgo
- removed lintian overrides
- fixed upstart script
- updating the package dependencies to reflect the latest trunk (golang-go-xdg-dev & golang-gocheck-dev)
Description of the change
Please note that I would of used dh-golang completely but the build part uses go install and that doesn't play nice with the -compiler gccgo switch
Also to take into account (I plan to test in detail later today):
go test -compiler gccgo
OK: 3 passed
PASS
ok _/home/
sergiusens@
OK: 3 passed
PASS
ok _/home/
I do get smaller binaries though :-)
I plan to work on dh-golang to figure out a way to use gccgo transparently as well
[...] dh_auto_ build: /mms/decode- cli;
+Build-Depends:
+ debhelper (>= 9),
+ dh-golang,
+ gccgo,
+ gccgo-go,
[...]
+override_
+ cd $(BUILDDIR); \
+ export GOPATH=$(BUILDDIR); \
+ go build -compiler=gccgo -v $(DH_GOPKG); \
+ go build -compiler=gccgo -v $(DH_GOPKG)
+
The intention here appears to be to make sure we're using the gccgo implementation of the 'go' tool. In that case, it should be invoked explicitly as 'gccgo-go' rather than as 'go', to ensure that this is the implementation being used. If it doesn't actually matter which implementation we use, then the build-dep should be on 'gccgo-go | golang-go'.
The extensive override of dh_auto_build is interesting, I think this points to toolchain deficiencies in dh_golang that this can't be done more directly. FWIW, the dh_golang implementation of the go target does:
$this- >doit_in_ builddir( "go", "install", "-v", @_, "$ENV{DH_ GOPKG}/ ...");
so this isn't even calling the same subcommand (build vs. install). You might want to at least call 'install' for consistency, if possible, even though that seems a strange thing to do in the 'build' target.
[...]
+ golang-go-xdg-dev,
[...]
Strange that changing the compiler resulted in a new build-dependency?