/srv/irclogs.ubuntu.com/2015/12/30/#launchpad.txt

=== maclin1 is now known as maclin
dobeywgrant: if you're around, could you bump the quota to 4GB on https://launchpad.net/~dobey/+archive/ubuntu/audiotools please?03:17
wgrantdobey: Done.03:41
=== maclin1 is now known as maclin
=== [HeOS] is now known as HeOS
tewardum... is it typical for a build to fail on a PPA and *not* have a buildlog?19:31
tewardcjwatson: ^ any thoughts/ideas?19:31
cjwatsonteward: URL to the build, please?19:32
tewardhttps://launchpad.net/~teward/+archive/ubuntu/nginx-devel-testing/+build/877358219:32
tewardone minute run means it was probably something big or substantial, but no build log makes me think the env just died19:33
cjwatsonteward: https://bugs.launchpad.net/launchpad/+bug/152942819:33
ubot5Launchpad bug 1529428 in Launchpad itself "Librarian sets aggressive cache headers on missing files" [Critical,In progress]19:33
cjwatsonteward: I've cleared this now and retried your build19:33
tewardthanks19:34
cjwatsoner, let me try that again, maybe I didn't give it long enough19:34
tewardi'm running in a local sbuild just to rule out the PPA system being at fault19:34
tewardthough all the other builds succeeded19:34
cjwatsonit'll be chroot-specific19:34
tewardok19:34
cjwatsoni.e. just xenial i386 in this instance19:34
tewardfailed again19:35
cjwatsonyes I know19:35
cjwatsonand I said that19:35
cjwatson19:34 <cjwatson> er, let me try that again, maybe I didn't give it long enough19:35
tewardah ok19:35
tewardsorry, running faster than i am reading :)19:35
cjwatsonhm, still getting 404 from squid19:35
* teward goes to find some tea to calm his overclocked brain :P19:35
cjwatsonteward: properly cleared now, retried again.  I'll just go and look for other casualties19:49
tewardcjwatson: thank you, i'll let you know if anything remains dead (it does succeed building, though :P)19:49
cyballhi ... 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 sources20:00
cyballI found only PKGBUILDDIR is there a PKGSRCDIR or something similar?20:01
cjwatsonthe source files are available from the archive on Launchpad - I might be able to give a more helpful answer given more specifics20:22
cjwatsonfor example a link to the failing build20:22
cjwatsoncyball: ^-20:24
cjwatsonPKGBUILDDIR 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 easily20:25
tewardcjwatson: confirmed, that nginx build cleared and worked, thanks!20:25
cyballcjwatson: https://launchpadlibrarian.net/232329954/buildlog_ubuntu-trusty-amd64.eve_0.1-1_BUILDING.txt.gz20:26
cyballcjwatson: i 've tried now to put everything in the pkg folder it seems to work but i have now an path conflict20:26
cjwatsoncyball: given it's go, note that LP builds are not allowed to fetch stuff from the internet20:27
cyballyes i know ... that's why i have the problems .. so i have to provide all golang libs into the sources20:27
cyballbut it is some kind of sad that there is no PKGSRCDIR env var20:28
cjwatsonuh, hardly20:28
cjwatsonit would be meaningless20:28
cjwatsonyour package's source is in your current directory, you don't need another environment variable for that20:28
cyballyes ... that's what I'm trying now20:29
cjwatsoncyball: your source package fails identically in a local sbuild instance20:39
cjwatsoncyball: I recommend setting up https://wiki.ubuntu.com/SimpleSbuild and testing your source package in that before uploading it20:39
teward^ that (I speak from experience!)20:40
teward(helps a lot for me :P)20:40
cjwatsoncyball: http://paste.ubuntu.com/14292170/ <- directory tree after the failure20:41
cjwatsonso looks like that's where "go install" put things20:42
cyballcjwatson: thx for the tree :)20:43
cjwatsonalso 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
cjwatsoneven if that doesn't happen to matter yet20:43
cjwatsonit might not matter right now, but since the problem is around this obj-x86_64-linux-gnu directory, it seems a good place to start20:45
cyballyes this is the directory created by the dh_golang stuff20:46
cjwatsonyeah, 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 architectures20:46
cjwatsonwhich suggests to me that there is a template somewhere for this kind of thing that might work better20:47
cyballmight be .. I didn't find it yet20:47
cyballbut I try to get it running now ... that is from my perspective the step before :)20:48
dobeyit seems the problem is taht your "source" package already contains the built code21:03
cyballcjwatson: ok it seems to work now21:05
cjwatsondobey: no, that's not the problem21:05
cjwatsoncyball: ok, good21:06
cyballnow i can take care about the different arch types :D21:06
cjwatsondobey: (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
cjwatsonprobably needs some clean rule tidyup, but anyway21:07
dobeyah, yeah, the rules file is going about it all wrong21:08
dobeyassuming 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 rule21:10
cyballyes ... 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 them21:10
dobeysomething akin to https://bazaar.launchpad.net/~unity-api-team/unity-scope-snappy/trunk/view/head:/debian/rules21:10
cjwatsonlooks like that could be improved further with dh-exec, too :)21:11
dobeyfwiw, including the .git directory in all the dependency trees in your source is also not nice21:12
cjwatsonah, maybe not, the .in file in question isn't a debhelper file21:12
cyballyes ... the git stuff will also be removed ... :-)21:12
dobeycjwatson: 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:13
cyballdobey: do you know how to vendor the sources in the pkg tree?21:31
cyballdobey: is there a specific directory i have to put it into?21:31
dobeycyball: see the "vendor" tool21:31
dobeyhttps://github.com/kardianos/govendor21:33
cyballdobey: thx21:33

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!