<div dir="ltr"><p dir="ltr">It's even easier than that. After doing go get and godeps -u, do a godeps -t and ensure the output matches dependencies.tsv.</p>
<p>that will ensure that the actual dependencies that exist are the same as the ones we expect to exist. If they're different, something's wrong.</p><p>This will require that godeps -t returns the right stuff, which right now it won't because of windows npipe stuff... which I can fix by making npipe importable from linux (even though it'll be featureless).</p>

<div class="gmail_quote">On Aug 1, 2014 2:51 AM, "roger peppe" <<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 1 August 2014 00:43, Menno Smits <<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>> wrote:<br>
> Trunk is currently broken if building using a clean GOPATH because revision<br>
> 03e56dcd was recently merged which imports mgo from <a href="http://labix.org" target="_blank">labix.org</a> instead of<br>
> <a href="http://gopkg.in" target="_blank">gopkg.in</a>. We no longer use mgo from <a href="http://labix.org" target="_blank">labix.org</a> and godeps no longer installs<br>
> it from that location.<br>
><br>
> The following import paths should be used instead:<br>
><br>
> <a href="http://gopkg.in/mgo.v2" target="_blank">gopkg.in/mgo.v2</a><br>
> <a href="http://gopkg.in/mgo.v2/bson" target="_blank">gopkg.in/mgo.v2/bson</a><br>
> <a href="http://gopkg.in/mgo.v2/txn" target="_blank">gopkg.in/mgo.v2/txn</a><br>
><br>
> This was perhaps not publicised well enough but the switch was made a couple<br>
> of weeks ago.<br>
><br>
> Right now juju will only build on machines that incidentally have a<br>
> <a href="http://labix.org" target="_blank">labix.org</a> mgo install. If the machine doesn't already have it, godeps won't<br>
> install it and builds fail.<br>
><br>
> I imagine the problem revision got past the landing bot because our test<br>
> hosts still have the <a href="http://labix.org" target="_blank">labix.org</a> mgo installed. If so, this should be cleaned<br>
> up.<br>
><br>
> I will fix the problem imports in the upgrades package now.<br>
<br>
I suggest that it might be a good thing to have a landing check<br>
that checks for unwanted import duplication.<br>
<br>
Something like:<br>
<br>
    if godeps -t ./... | sed -r -e "s:\t.*::" \<br>
       -e "s:labix\.org/v./mgo:<a href="http://gopkg.in/mgo.v0" target="_blank">gopkg.in/mgo.v0</a>:" \<br>
       -e "s:github\.com/juju/charm:<a href="http://gopkg.in/charm.v0" target="_blank">gopkg.in/charm.v0</a>:" \<br>
       -e "s:(gopkg\.in/[^/]+)\.v[0-9]+:\1.vX:" | sort | uniq -d | grep '^'<br>
    then<br>
        echo imports with different versions found<br>
        exit 1<br>
    fi<br>
<br>
might do the trick.<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div>
</div>