=== maclin1 is now known as maclin | ||
dobey | wgrant: if you're around, could you bump the quota to 4GB on https://launchpad.net/~dobey/+archive/ubuntu/audiotools please? | 03:17 |
---|---|---|
wgrant | dobey: Done. | 03:41 |
=== maclin1 is now known as maclin | ||
=== [HeOS] is now known as HeOS | ||
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:31 |
cjwatson | teward: URL to the build, please? | 19:32 |
teward | https://launchpad.net/~teward/+archive/ubuntu/nginx-devel-testing/+build/8773582 | 19:32 |
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 |
ubot5 | Launchpad bug 1529428 in Launchpad itself "Librarian sets aggressive cache headers on missing files" [Critical,In progress] | 19:33 |
cjwatson | teward: I've cleared this now and retried your build | 19:33 |
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:34 |
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:35 | |
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) | 19:49 |
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:00 |
cyball | I found only PKGBUILDDIR is there a PKGSRCDIR or something similar? | 20:01 |
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:22 |
cjwatson | cyball: ^- | 20:24 |
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:25 |
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:26 |
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:27 |
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:28 |
cyball | yes ... that's what I'm trying now | 20:29 |
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:39 |
teward | ^ that (I speak from experience!) | 20:40 |
teward | (helps a lot for me :P) | 20:40 |
cjwatson | cyball: http://paste.ubuntu.com/14292170/ <- directory tree after the failure | 20:41 |
cjwatson | so looks like that's where "go install" put things | 20:42 |
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:43 |
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:45 |
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:46 |
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:47 |
cyball | but I try to get it running now ... that is from my perspective the step before :) | 20:48 |
dobey | it seems the problem is taht your "source" package already contains the built code | 21:03 |
cyball | cjwatson: ok it seems to work now | 21:05 |
cjwatson | dobey: no, that's not the problem | 21:05 |
cjwatson | cyball: ok, good | 21:06 |
cyball | now i can take care about the different arch types :D | 21:06 |
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:07 |
dobey | ah, yeah, the rules file is going about it all wrong | 21:08 |
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:10 |
cjwatson | looks like that could be improved further with dh-exec, too :) | 21:11 |
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:12 |
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:13 |
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:31 |
dobey | https://github.com/kardianos/govendor | 21:33 |
cyball | dobey: thx | 21:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!