Dmitry, note that the pkg-go team policy states that packages must be buildable using git-buildpackage: https://pkg-go.alioth.debian.org/packaging.html
So, even if you prefer not to use git-buildpackage, please at least verify before pushing your repository that it can successfully be built using git-buildpackage (without having to specify any options). Thanks. On Mon, Oct 19, 2015 at 6:11 AM, Dmitry Smirnov <only...@debian.org> wrote: > On Sunday 18 October 2015 23:39:35 Matthew Dawson wrote: > > > Why? Etcd is as a statically linked binary so you do not need to > re-build > > > it for Jessie. Just use the package from "testing" as is. You can use > > > Apt- Pinning technique to allow list of certain packages to be > installed > > > from "testing". > > > > I generally avoid this method only because eventually I find packages > that > > start requiring newer versions of core packages that I don't want to pull > > and keep up to date constantly. In the past I usually got away with what > > was available in Wheezy, but this time I have a huge dependency list. > > > > If etcd (and Kubernetes in the future) can keep its runtime dependencies > > Jessie friendly, I wouldn't have an issue doing as you suggest. > > So you are building your own private backports... :) > > I'm not sure which core packages you are concerned about but in general > since > both Etcd and Kubernetes are still fairly young they are adding new > dependencies all the time. Docker does the same... > > > > If not, you could consider this a start on a backports effort :) > > Maybe if this effort would be sponsored financially... > > I agree that backports could be useful even for statically linked Golang > software as protection from sudden changes in "testing". > > > > I'm happy to help in any way I can. I haven't dug into Debian packaging > > before, so I figured I'd start on etcd and move on to Kubernetes after. > Is > > there any specific method you'd want me to follow to work on those > > packages? > > I'd use dh-make-golang (-type="library") with passing -git_revision > whenever > upstream do formal releases. Also I add "debian/watch" file even if > upstream > do not tag yet -- it helped me more than twice already when tags > appeared... > > > > I was going to start with one of the other Go packages as a > > template, so if you can point me at a good example I can try starting > from > > there. I do want to finish dealing with etcd first, so that I can start > > Kubernetes once its ready. > > Although Kubernetes packaging is not published yet it is not too bad and > will > probably need only little work. But packaging all dependencies is a pain... > > > > > I tried adding that, but it didn't seem to help. It seems gbp doesn't > like > > this repository format by default, as it assume the upstream files are > > available. Making it use git-pbuilder does fix it, as it builds > > everything from the tar archive. Google doesn't seem to talk much about > > this. > > > > I'll keep poking at this, but any other suggestions would be appreciated. > > Sorry, then I think it must be the following: > > ~~~~ > [DEFAULT] > builder = pdebuild --debbuildopts "-i\.git -I.git $*" > ~~~~ > > > > Ok, for reference what do you run to build from the git repository? That > > might help me get this going. > > I just extract tarball obtained with `uscan` or `origtargz`, add "debian" > directory and invoke `pbuilder` (or `debuild). IMHO this procedure is > simple > enough and avoids GBP which I see as unnecessary complex and demanding... > > -- > All the best, > Dmitry Smirnov. > > _______________________________________________ > Pkg-go-maintainers mailing list > Pkg-go-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers