[10:31] <dch> hey I’m trying for the first time to duplicate my ppa package to multiple releases, i.e. works on precise, want to generate for saucy & trusty
[10:32] <dch> dput works fine, but LP whines with File apache-couchdb_1.6.0-0ubuntu2.debian.tar.gz already exists in developer builds, but uploaded version has different contents.
[10:33] <dch> does this .debian.tar.gz need to remain between debuild/dput runs? I’d cleaned it out before.
[10:38] <dch> when I run debuild -S -sa the …debian.tar.gz gets rebuitl automatically, because the debian/changelog has 'apache-couchdb (1.6.0-0ubuntu2) precise; urgency=low’ and 'apache-couchdb (1.6.0-0ubuntu2) trusty; urgency=low’ in the newer one.
[10:56] <geser> dch: do you need a rebuild? if no then you can copy the source + binary packages through the LP web ui to a different release; if yes, then you need up upload with a different package revision
[11:53] <cjwatson> dch: What geser said.  To answer the rest of your question, .debian.tar.gz is part of your source package; you probably shouldn't "clean it out" because then you may forget that you've already uploaded that version.  Launchpad will not let you upload the same filename to any given archive multiple times with different contents.
[16:43] <Mez> trying to rebuild something - and it's going straight to "failed to build" with no build logs... any idea why this would happen?
[17:09] <cjwatson> Mez: Builder failure of some kind.  We'd need URLs to check
[17:09] <cjwatson> That would happen if you managed to kill the builder hard, though there may be other causes
[17:30] <dch> sorry netsplit there. geser, cjwatson  it should be rebuilt as the binary deps are different erlang versions. What is the best way to generate multiple releases where the source tar ball is the same (but binaries will be different due to dependency version changes) ?
[17:31] <dch> I’m pretty sure I am doing it wrong the way I tried, and it seems odd that I would need a different ppa for each release, surely?
[19:12] <ndec> hi. i am seeing an issue with one of our Linaro (ARM enabled) PPA. i am trying to build gst-plugin-base for armhf, and the build is stuck when running the tests. in the arcives the last built was done on v7 h/w, while this time it's using on chindi06 (amd64+qemu). not sure if this can be problem
[19:12] <ndec> my build is here: https://launchpad.net/~linaro-maintainers/+archive/ubuntu/qcom-overlay/+build/6191367
[19:12] <ndec> i tried twice, and it got stuck twice at the same place
[19:12] <cjwatson> I didn't think linaro-maintainers had ever been on real hardware.
[19:13] <ndec> yes, i think it was long time ago, maybe
[19:13] <cjwatson> There's no previous build of gst-plugin-base1.0 in that PPA.
[19:13] <ndec> not in this one, this one is quite new
[19:13] <cjwatson> And I'm afraid we don't offer non-qemu armhf builds outside of Canonical
[19:13] <cjwatson> (Or the Ubuntu archive proper)
[19:14] <cjwatson> Possibly unless there are some contractual arrangements, I wouldn't know about that
[19:14] <cjwatson> But out of my hands unfortunately
[19:15] <ndec> we used to build gst, see https://launchpad.net/~linaro-maintainers/+archive/ubuntu/staging-overlay/+build/3686950
[19:15] <ndec> fabo: ^^
[19:15] <ndec> so, i guess i should just disable the tests for now, right? i probably don't care about that anyways
[19:17] <cjwatson> diphda?  I wonder what that was ...
[19:17] <cjwatson> No longer racked
[19:18] <ndec> that's old. probably was a panda..
[19:18] <cjwatson> Oh, there was a brief period when there were some bits of ARM kit specifically for use by Linaro, I think
[19:18] <cjwatson> But none of that is physically in service any more
[19:18] <cjwatson> So yeah, I think your only choice is to disable tests; qemu and threading generally aren't friends and that's probably what's going on here
[19:19] <ndec> yup. will try that.
[21:34] <ndec> cjwatson: btw, disabling the tests/check fixed my problem.. i am fine. thanks for your quick answer.
[23:25] <cjwatson> ndec: good stuff