[03:17] <dobey> wgrant: if you're around, could you bump the quota to 4GB on https://launchpad.net/~dobey/+archive/ubuntu/audiotools please?
[03:41] <wgrant> dobey: Done.
[19:31] <teward> um... is it typical for a build to fail on a PPA and *not* have a buildlog?
[19:31] <teward> cjwatson: ^ any thoughts/ideas?
[19:32] <cjwatson> teward: URL to the build, please?
[19:32] <teward> https://launchpad.net/~teward/+archive/ubuntu/nginx-devel-testing/+build/8773582
[19:33] <teward> one minute run means it was probably something big or substantial, but no build log makes me think the env just died
[19:33] <cjwatson> teward: https://bugs.launchpad.net/launchpad/+bug/1529428
[19:33] <cjwatson> teward: I've cleared this now and retried your build
[19:34] <teward> thanks
[19:34] <cjwatson> er, let me try that again, maybe I didn't give it long enough
[19:34] <teward> i'm running in a local sbuild just to rule out the PPA system being at fault
[19:34] <teward> though all the other builds succeeded
[19:34] <cjwatson> it'll be chroot-specific
[19:34] <teward> ok
[19:34] <cjwatson> i.e. just xenial i386 in this instance
[19:35] <teward> failed again
[19:35] <cjwatson> yes I know
[19:35] <cjwatson> and I said that
[19:35] <cjwatson> 19:34 <cjwatson> er, let me try that again, maybe I didn't give it long enough
[19:35] <teward> ah ok
[19:35] <teward> sorry, running faster than i am reading :)
[19:35] <cjwatson> hm, still getting 404 from squid
[19:35]  * teward goes to find some tea to calm his overclocked brain :P
[19:49] <cjwatson> teward: properly cleared now, retried again.  I'll just go and look for other casualties
[19:49] <teward> cjwatson: thank you, i'll let you know if anything remains dead (it does succeed building, though :P)
[20:00] <cyball> hi ... is there some documentation about where launchpad is storing the orig sources from a pkg? if i build my deb locally it just works on the launchpad server it seems not to find the sources
[20:01] <cyball> I found only PKGBUILDDIR is there a PKGSRCDIR or something similar?
[20:22] <cjwatson> the source files are available from the archive on Launchpad - I might be able to give a more helpful answer given more specifics
[20:22] <cjwatson> for example a link to the failing build
[20:24] <cjwatson> cyball: ^-
[20:25] <cjwatson> PKGBUILDDIR is not very relevant, that's just a substitution sbuild applies in place of the real build directory in the build log so that logs from different versions can be compared more easily
[20:25] <teward> cjwatson: confirmed, that nginx build cleared and worked, thanks!
[20:26] <cyball> cjwatson: https://launchpadlibrarian.net/232329954/buildlog_ubuntu-trusty-amd64.eve_0.1-1_BUILDING.txt.gz
[20:26] <cyball> cjwatson: i 've tried now to put everything in the pkg folder it seems to work but i have now an path conflict
[20:27] <cjwatson> cyball: given it's go, note that LP builds are not allowed to fetch stuff from the internet
[20:27] <cyball> yes i know ... that's why i have the problems .. so i have to provide all golang libs into the sources
[20:28] <cyball> but it is some kind of sad that there is no PKGSRCDIR env var
[20:28] <cjwatson> uh, hardly
[20:28] <cjwatson> it would be meaningless
[20:28] <cjwatson> your package's source is in your current directory, you don't need another environment variable for that
[20:29] <cyball> yes ... that's what I'm trying now
[20:39] <cjwatson> cyball: your source package fails identically in a local sbuild instance
[20:39] <cjwatson> cyball: I recommend setting up https://wiki.ubuntu.com/SimpleSbuild and testing your source package in that before uploading it
[20:40] <teward> ^ that (I speak from experience!)
[20:40] <teward> (helps a lot for me :P)
[20:41] <cjwatson> cyball: http://paste.ubuntu.com/14292170/ <- directory tree after the failure
[20:42] <cjwatson> so looks like that's where "go install" put things
[20:43] <cyball> cjwatson: thx for the tree :)
[20:43] <cjwatson> also hardcoding x86-64 is weird - aren't there conventions for how go packages' debian/rules are laid out that are a bit more portable?
[20:43] <cjwatson> even if that doesn't happen to matter yet
[20:45] <cjwatson> it might not matter right now, but since the problem is around this obj-x86_64-linux-gnu directory, it seems a good place to start
[20:46] <cyball> yes this is the directory created by the dh_golang stuff
[20:46] <cjwatson> yeah, but it's an architecture-specific one; I find it hard to believe that most go packages hardcode it, since most of them manage to build on other architectures
[20:47] <cjwatson> which suggests to me that there is a template somewhere for this kind of thing that might work better
[20:47] <cyball> might be .. I didn't find it yet
[20:48] <cyball> but I try to get it running now ... that is from my perspective the step before :)
[21:03] <dobey> it seems the problem is taht your "source" package already contains the built code
[21:05] <cyball> cjwatson: ok it seems to work now
[21:05] <cjwatson> dobey: no, that's not the problem
[21:06] <cjwatson> cyball: ok, good
[21:06] <cyball> now i can take care about the different arch types :D
[21:07] <cjwatson> dobey: (the fix was https://launchpadlibrarian.net/232331708/eve_0.1-1_0.2-1.diff.gz, which should hopefully give you an idea)
[21:07] <cjwatson> probably needs some clean rule tidyup, but anyway
[21:08] <dobey> ah, yeah, the rules file is going about it all wrong
[21:10] <dobey> assuming the dependencies are vendored in the source tree, or have their source packaged and are enumerated as build-depends, then you should only need the standard %: dh $@ --buildsystem=golang --with=golang rule
[21:10] <cyball> yes ... the cleanup will follow now ... :) ... it took me the whole day all that stuff ... i've first started building only binary pkgs until the point i realized that PPA does not support them
[21:10] <dobey> something akin to https://bazaar.launchpad.net/~unity-api-team/unity-scope-snappy/trunk/view/head:/debian/rules
[21:11] <cjwatson> looks like that could be improved further with dh-exec, too :)
[21:12] <dobey> fwiw, including the .git directory in all the dependency trees in your source is also not nice
[21:12] <cjwatson> ah, maybe not, the .in file in question isn't a debhelper file
[21:12] <cyball> yes ... the git stuff will also be removed ... :-)
[21:13] <dobey> cjwatson: yeah, there's some extra nasty stuff in there because go's build system itself doesn't have any way to manage generated data files :-/
[21:31] <cyball> dobey: do you know how to vendor the sources in the pkg tree?
[21:31] <cyball> dobey: is there a specific directory i have to put it into?
[21:31] <dobey> cyball: see the "vendor" tool
[21:33] <dobey> https://github.com/kardianos/govendor
[21:33] <cyball> dobey: thx