=== maclin1 is now known as maclin [03:17] wgrant: if you're around, could you bump the quota to 4GB on https://launchpad.net/~dobey/+archive/ubuntu/audiotools please? [03:41] dobey: Done. === maclin1 is now known as maclin === [HeOS] is now known as HeOS [19:31] um... is it typical for a build to fail on a PPA and *not* have a buildlog? [19:31] cjwatson: ^ any thoughts/ideas? [19:32] teward: URL to the build, please? [19:32] https://launchpad.net/~teward/+archive/ubuntu/nginx-devel-testing/+build/8773582 [19:33] one minute run means it was probably something big or substantial, but no build log makes me think the env just died [19:33] teward: https://bugs.launchpad.net/launchpad/+bug/1529428 [19:33] Launchpad bug 1529428 in Launchpad itself "Librarian sets aggressive cache headers on missing files" [Critical,In progress] [19:33] teward: I've cleared this now and retried your build [19:34] thanks [19:34] er, let me try that again, maybe I didn't give it long enough [19:34] i'm running in a local sbuild just to rule out the PPA system being at fault [19:34] though all the other builds succeeded [19:34] it'll be chroot-specific [19:34] ok [19:34] i.e. just xenial i386 in this instance [19:35] failed again [19:35] yes I know [19:35] and I said that [19:35] 19:34 er, let me try that again, maybe I didn't give it long enough [19:35] ah ok [19:35] sorry, running faster than i am reading :) [19:35] hm, still getting 404 from squid [19:35] * teward goes to find some tea to calm his overclocked brain :P [19:49] teward: properly cleared now, retried again. I'll just go and look for other casualties [19:49] cjwatson: thank you, i'll let you know if anything remains dead (it does succeed building, though :P) [20:00] 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] I found only PKGBUILDDIR is there a PKGSRCDIR or something similar? [20:22] 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] for example a link to the failing build [20:24] cyball: ^- [20:25] 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] cjwatson: confirmed, that nginx build cleared and worked, thanks! [20:26] cjwatson: https://launchpadlibrarian.net/232329954/buildlog_ubuntu-trusty-amd64.eve_0.1-1_BUILDING.txt.gz [20:26] 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] cyball: given it's go, note that LP builds are not allowed to fetch stuff from the internet [20:27] yes i know ... that's why i have the problems .. so i have to provide all golang libs into the sources [20:28] but it is some kind of sad that there is no PKGSRCDIR env var [20:28] uh, hardly [20:28] it would be meaningless [20:28] your package's source is in your current directory, you don't need another environment variable for that [20:29] yes ... that's what I'm trying now [20:39] cyball: your source package fails identically in a local sbuild instance [20:39] cyball: I recommend setting up https://wiki.ubuntu.com/SimpleSbuild and testing your source package in that before uploading it [20:40] ^ that (I speak from experience!) [20:40] (helps a lot for me :P) [20:41] cyball: http://paste.ubuntu.com/14292170/ <- directory tree after the failure [20:42] so looks like that's where "go install" put things [20:43] cjwatson: thx for the tree :) [20:43] 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] even if that doesn't happen to matter yet [20:45] 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] yes this is the directory created by the dh_golang stuff [20:46] 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] which suggests to me that there is a template somewhere for this kind of thing that might work better [20:47] might be .. I didn't find it yet [20:48] but I try to get it running now ... that is from my perspective the step before :) [21:03] it seems the problem is taht your "source" package already contains the built code [21:05] cjwatson: ok it seems to work now [21:05] dobey: no, that's not the problem [21:06] cyball: ok, good [21:06] now i can take care about the different arch types :D [21:07] 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] probably needs some clean rule tidyup, but anyway [21:08] ah, yeah, the rules file is going about it all wrong [21:10] 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] 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] something akin to https://bazaar.launchpad.net/~unity-api-team/unity-scope-snappy/trunk/view/head:/debian/rules [21:11] looks like that could be improved further with dh-exec, too :) [21:12] fwiw, including the .git directory in all the dependency trees in your source is also not nice [21:12] ah, maybe not, the .in file in question isn't a debhelper file [21:12] yes ... the git stuff will also be removed ... :-) [21:13] 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] dobey: do you know how to vendor the sources in the pkg tree? [21:31] dobey: is there a specific directory i have to put it into? [21:31] cyball: see the "vendor" tool [21:33] https://github.com/kardianos/govendor [21:33] dobey: thx