The remaining packages are: golang-github-jacobsa-bazilfuse (currently in NEW) golang-github-jacobsa-fuse golang-github-jacobsa-gcloud gcsfuse
Where each one depends on the one before being accepted into Debian. The packaging itself is done, it’s now just a matter of waiting for ftpmaster to accept them one by one. On Mon, Jun 22, 2015 at 10:00 AM, Michael Stapelberg <[email protected]> wrote: > I’m a bit pressed on time, so short reply: See > https://qa.debian.org/developer.php?login=stapelberg%40debian.org for > which packages are in Debian and which ones are in NEW. > > Currently, all further packages are blocked on golang-golang-x-sys getting > accepted. > > paultag, can you help with that? :) > > On Mon, Jun 22, 2015 at 3:34 AM, Aaron Jacobs <[email protected]> wrote: > >> Hi Michael, >> >> Any progress with the remaining packages? Feel free to ignore my >> philosophical >> questions/suggestions if they're not relevant or helpful. >> >> Aaron >> >> On Mon, Jun 15, 2015 at 8:32 AM, Aaron Jacobs <[email protected]> wrote: >> > On Fri, Jun 12, 2015 at 5:02 PM, Michael Stapelberg >> > <[email protected]> wrote: >> >> The Debian policy is to not ship copies of libraries in packages. For >> C, >> >> that works quite well, since library authors are generally aware of >> SONAMEs >> >> and when they need to bump them. For Go, package paths are supposed to >> never >> >> break backwards compatibility, and it seems like most of the community >> >> agrees. We haven’t had a single case of backwards compatibility >> breakage yet >> >> (that I know of). >> > >> > I agree it's the convention to never break backwards compatibility, but >> it does >> > happen from time to time. I will sheepishly raise my hand and say that >> I've >> > done it, and will probably do it again, for code that I own where other >> code I >> > own is the primary or sole user. >> > >> > In such a case, would bumping a major semantic version number (in the >> form of a >> > git tag) help you? I guess this would be the analog of C library >> versions, but >> > I don't actually know how Debian deals with the problem of dependent A >> needing >> > version 1 and dependent B needing version 2, even for C libraries. >> > >> > >> > On Mon, Jun 15, 2015 at 7:13 AM, Michael Stapelberg >> > <[email protected]> > golang-github-jacobsa-oglematchers is in >> > Debian >> >> golang-github-jacobsa-reqtrace is in Debian >> >> golang-goprotobuf was updated in Debian >> >> >> >> golang-github-jacobsa-oglemock is in the NEW queue >> >> golang-github-jacobsa-ogletest is in the NEW queue >> >> golang-google-appengine is in the NEW queue >> >> golang-golang-x-oauth2 is in the NEW queue >> > >> > Great! Thank you. :-) >> > >> > >> >> Looking at remaining dependencies, you could save me a lot of >> headaches if >> >> you could split out github.com/googlecloudplatform/gcsfuse/timeutil >> into a >> >> separate repository. Otherwise, we have circular dependencies >> >> (github.com/googlecloudplatform/gcsfuse depends on >> github.com/jacobsa/fuse, >> >> which depends on github.com/googlecloudplatform/gcsfuse/timeutil). >> >> >> >> Also, either doing the same with github.com/jacobsa/gcloud/syncutil or >> >> inlining the (github.com/jacobsa/fuse/fsutil).AnonymousFile call in >> >> github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go >> would >> >> help as well. >> > >> > I had been feeling guilty I hadn't done this anyway; thanks for the >> push. Done: >> > >> > https://github.com/jacobsa/timeutil >> > https://github.com/jacobsa/syncutil >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
