[pkg-go] RFS: fleet -- Distributed init system using systemd and etcd

[Michael Stapelberg]

On Tue, Jun 30, 2015 at 7:41 AM, Potter, Tim (Cloud Services) <
timothy.potter at hp.com> wrote:

> On 30 Jun 2015, at 6:06 am, Michael Stapelberg <stapelberg at debian.org>
> wrote:
> > On Sat, Jun 27, 2015 at 1:09 AM, Potter, Tim (Cloud Services) <
> timothy.potter at hp.com> wrote:
> > On 23 Jun 2015, at 5:34 pm, Michael Stapelberg <stapelberg at debian.org>
> wrote:
> > >
> > > Sorry for the late reply. In the meantime, we’ve changed the library
> naming conventions in http://pkg-go.alioth.debian.org/packaging.html, so
> could you please adjust the package names?
> > >
> > > Let me know when you want me to take another look.
> >
> > OK I’m all done with renaming for packages that have not been uploaded
> yet.  Could you take a look?  I’ve found some non-determinism in one of the
> tests for goini so that and it’s antecedent globalconf can’t be uploaded
> yet.
> >
> > golang-goini -> golang-github-glacjay-goini
> >
> > Uploaded.
>
> Thanks!
>
> > golang-globalconf -> golang-github-rakyll-globalconf
> >
> > Depends on goini, so I can’t upload it yet.
>
> Still working on a fix for this.  I think there is an upstream bug that
> needs resolving first.
>
> > golang-go-uuid -> golang-github-pborman-uuid
> >
> > This one still has export DH_GOPKG := code.google.com/p/go-uuid/uuid in
> its debian/rules. Is that an oversight? In debian/{control,copyright}, you
> use https://github.com/pborman/uuid
>
> I’m not sure.  Fleet refers to it using the code.google.com namespace so
> it’s consistent in that respect, but not with the repository location.  The
> tests refer to the package as just “uuid”.  Not sure what the right answer
> here is.
>

I think we should be using the github package name (other packages use
canonical import paths to enforce this, so it’s a normal situation to be
in) and change upstream to refer to the package that way. If upstream
doesn’t do the change quickly enough, ship a patch in debian/patches.


>
> > Should I rename golang-go-semver and golang-clockwork?  They’re in
> testing but aren’t dependencies of any other packages yet so now would be a
> good time to re-upload them with new names I think.
> >
> > I’ll deal with them later, ideally in an automated fashion. Currently,
> the first renamed package is still in NEW, but once it’s through and hence
> has validated our strategy, we can come up with a concrete plan.
>
> I wasn’t expecting this answer and yesterday I performed and pushed a
> rename of these two packages.  I can revert if that messes up your plans
> otherwise they can be re-pushed in the interests of consistency.
>

No, that’s fine.


>
> > Are there any other not-yet-uploaded Go packages you want me to take a
> look at?
>
> No, I think that’s it for the moment.
>
>
> Thanks!
>
> Tim.
>
> >
> > --
> > Best regards,
> > Michael
>
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150630/b1035682/attachment-0001.html>