[04:55] <sontek> I'm trying to push a build to a PPA (first time) and I'm not seeing any builds happen when I go to the +builds URL
[04:56] <sontek> is there a place I can check the status of a build?
[04:58] <cjwatson> Which +builds URL are you talking about?
[04:59] <cjwatson> You'd normally check the status of builds in a PPA using <URL to PPA>/+packages
[05:02] <sontek> Yeah, I go to +packages and then click "view all builds"
[05:03] <sontek> and then switch to "all states" and I see nothing
[05:04] <sontek> It said "successfully uploaded packages"
[05:04] <cjwatson> That would imply the builds are done
[05:04] <cjwatson> What's the URL to this PPA?
[05:06] <sontek> https://launchpad.net/~surveymonkey/+archive/surveymonkey
[05:08] <cjwatson> OK, so all the builds are old, indeed
[05:09] <cjwatson> That then suggests your upload wasn't accepted
[05:09] <cjwatson> Two things: (1) check your mail for reject messages (2) make sure the upload was signed with a key registered in Launchpad, as if it wasn't you won't even get a reject message
[05:09] <cjwatson> (this is basically to avoid Launchpad being a spam vector)
[05:10] <sontek> ahh, I do see it got rejected
[05:10] <sontek> libmemcached_1.0.16-1ubuntu2.dsc: Version older than that in the archive. 1.0.16-1ubuntu2 <= 1.0.16-1+lucid1
[05:10] <sontek> it sees those old ones as newer
[05:10] <sontek> so I need to bump to .16-2
[05:11] <cjwatson> that seems too high
[05:11] <sontek> It bumped the back from -ubuntu2
[05:11] <sontek> but that didn't help
[05:11] <sontek> maybe because those packages are -lucid?
[05:11] <sontek> I thought the build server would do the different versions
[05:11] <cjwatson> 1.0.16-1ubuntu2+lucid1, I'd have thought
[05:11] <sontek> Do I have to build the package per version?
[05:11] <sontek> per release
[05:11] <cjwatson> The version is embedded in the source package, and Launchpad doesn't modify the source package
[05:12] <cjwatson> So yes you do
[05:12] <sontek> So it wont take the source package and build it on precise for me
[05:12] <cjwatson> Though if the builds are compatible (no ABI changes in dependent libraries or whatever) then you can build on the oldest series you care about and then copy-with-binaries to later series
[05:12] <sontek> oh, can I upload binaries instead of source packages?
[05:13] <cjwatson> No, but you can copy them around within Launchpad
[05:13] <sontek> So right now in my changelog it has libmemcached (1.0.16-1ubuntu2) lucid; urgency=low
[05:13] <sontek> I should change that to 1-ubuntu3-lucid?
[05:13] <cjwatson> No
[05:14] <cjwatson> 1.0.16-1ubuntu2+lucid1 (if you want it to be just greater than 1.0.16-1ubuntu2, e.g. if it has substantive changes) or 1.0.16-1ubuntu2~lucid1 (if you want it to be just less, e.g. if it's a straight backport)
[05:14] <cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning has specific advice on versioning
[05:14] <sontek> This is the same package thats already there, its just the one up there has a bug
[05:15] <sontek> so I need to get a new version up there without the bug
[05:15] <cjwatson> Oh.  Why wouldn't it just be 1.0.16-1+lucid2, then?
[05:15] <cjwatson> That would be the normal scheme given what's there now
[05:16] <cjwatson> And 1.0.16-1ubuntu2 doesn't exist in Ubuntu AFAICS, so it doesn't make sense to use versions that look like they're derivatives of an Ubuntu version
[05:17] <cjwatson> 1.0.16-1+lucid2 seems best
[05:19] <sontek> Nice, looks like thats working
[05:20] <sontek> doesn't look like it marked it as superseded though
[05:20] <cjwatson> It'll get round to that once the builds are done
[05:20] <cjwatson> You wouldn't want to supersede when the new version isn't there yet, normally
[05:21] <cjwatson> (including its binaries)
[05:22] <cjwatson> You might want to review https://launchpadlibrarian.net/161401455/libmemcached_1.0.16-1%2Blucid1_1.0.16-1%2Blucid2.diff.gz and see whether that's actually what you meant to change; it looks surprisingly ... like a total packaging rewrite, for a bug fix
[05:23] <cjwatson> Looks like a step backwards in a number of ways
[05:23] <cjwatson> Perhaps it was inadvertently derived from an entirely different source tree?
[05:25] <sontek> Yeah, I need to pull in all those changes as well. This was my first attempt at building a package, so I completely did it from scratch
[05:25] <sontek> so it doesn't have all the upstream debian stuff yet
[05:25] <cjwatson> That's generally a scary mistake
[05:26] <sontek> It wasn't a mistake, I wanted to learn
[05:26] <cjwatson> I would strongly advise starting out with the version you're trying to supersede, in nearly all circumstances
[05:26] <cjwatson> Uploading it over the top of the previous version is the mistake I'm referring to ...
[05:26] <cjwatson> Learning locally is fine, of course
[05:26] <sontek> oh, yeah thats true
[05:26] <sontek> can I remove packages after they've been uploaded?
[05:27] <cjwatson> Yes, though putting the old one back is a bit more effort (though possible)
[05:27] <cjwatson> I'd suggest waiting until the builds complete
[05:27] <cjwatson> (They'll probably fail - the build-depends look incomplete)
[05:28] <sontek> I ran the debuild and lintian stuff to test
[05:28] <sontek> maybe I ran the wrong commands
[05:28] <cjwatson> That's not enough if you weren't running in a clean environment
[05:28] <cjwatson> I recommend sbuild
[05:29] <sontek> is there a good document on doing all this?  I found lots of different sources and they all do it differently
[05:29] <cjwatson> Let me hurry those builds along a bit so you can see
[05:29] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild is pretty similar to the build setup I use
[05:30] <sontek> ok, those builds failed
[05:30] <cjwatson> They haven't failed yet
[05:30] <sontek> oh, maybe not, they are still going
[05:31] <sontek> So you think the best way is to download the tarball thats already there
[05:31] <cjwatson> The source package, yes
[05:31] <cjwatson> "dget https://launchpad.net/~surveymonkey/+archive/surveymonkey/+files/libmemcached_1.0.16-1%2Blucid1.dsc"
[05:32] <cjwatson> then fix up the file name with "mv libmemcached_1.0.16-1%2Blucid1.dsc libmemcached_1.0.16-1~lucid1.dsc"
[05:32] <cjwatson> (dget is in the devscripts package)
[05:33] <cjwatson> er that should be "mv libmemcached_1.0.16-1%2Blucid1.dsc libmemcached_1.0.16-1+lucid1.dsc" of course
[05:33] <cjwatson> ascii fail
[05:33] <cjwatson> you won't be able to reuse 1.0.16-1+lucid2 now, but you can bump to 1.0.16-1+lucid3
[05:34] <cjwatson> huh, those builds are getting further than I expected :)
[05:34] <sontek> https://launchpad.net/~surveymonkey/+archive/surveymonkey/+files/  gives 404, how were you able to get the filename?
[05:34] <sontek> I tested them locally, so I'd expect them to build all the way through
[05:35] <cjwatson> https://launchpad.net/~surveymonkey/+archive/surveymonkey/+packages?field.name_filter=&field.status_filter=&field.series_filter=lucid
[05:36] <sontek> That doesn't show the source file name
[05:37] <cjwatson> it does if you press the expander triangle
[05:37] <cjwatson> under "Package files"
[05:37] <sontek> ahh, I see it, so I just need the .dsc and that figures everything else out
[05:37] <cjwatson> dget will fetch the others
[05:38] <cjwatson> or you can download manually if you prefer - you need .dsc, .debian.tar.gz, .orig.tar.gz
[05:38] <cjwatson> anyhow, to answer your earlier question, you can either upload a version that's derived from the former one, or else there's a "Delete packages" link and then once it's processed the deletion you can use https://launchpad.net/~surveymonkey/+archive/surveymonkey/+copy-packages to copy an old version back in; switch "Published" to "Any status" and press Filter to find the old version, leave the destination PPA at "This PPA" and the ...
[05:38] <cjwatson> ... destination series at "The same series", and change "Copy options" to "Copy existing binaries"
[05:38] <cjwatson> ah, there we go, those builds failed indeed
[05:39] <sontek> gpg: Can't check signature: public key not found
[05:39] <sontek> Validation FAILED!!
[05:39] <sontek> when doing dget
[05:39] <cjwatson> either get the public key of the person who signed the previous upload, or check the contents in some other way
[05:40] <sontek> Wouldn't they have to put the key public for it to sign and upload?
[05:40] <cjwatson> -# upstream does not ship a stable make test, or one suitable for running in
[05:40] <cjwatson> -# a build farm, so we have to skip it. We aren't patching any of the code
[05:40] <sontek> I add to do send-keys
[05:40] <cjwatson> -# so any library failures are directly a result of upstream bugs
[05:40] <cjwatson> -override_dh_auto_test:
[05:40] <cjwatson> -	echo "skipping tests"
[05:40] <cjwatson> that part of the diff from the previous version to yours is no doubt responsible :)
[05:40] <cjwatson> they would have had to push their key to Launchpad in order to upload
[05:41] <cjwatson> So I would assume it's http://keyserver.ubuntu.com:11371/pks/lookup?search=0x8E9C15287F3F8CB2F64FBAE86452957424F90553&op=index
[05:41] <cjwatson> (from https://launchpad.net/~msabramo)
[05:41] <cjwatson> in which case you can grab it with "gpg --keyserver keyserver.ubuntu.com --recv-keys 8E9C15287F3F8CB2F64FBAE86452957424F90553"
[05:44] <sontek> dscverify: libmemcached_1.0.16-1%2Blucid1.dsc failed signature check:
[05:44] <sontek> gpg: Signature made Fri 08 Nov 2013 06:48:39 AM PST using RSA key ID 24F90553
[05:44] <sontek> gpg: Can't check signature: public key not found
[05:44] <sontek> gpg --list-keys |grep 24F90553
[05:44] <sontek> pub   2048R/24F90553 2013-11-06
[05:48] <cjwatson> oh, blah, dscverify is checking against a different keyring
[05:48] <cjwatson> "dscverify --no-default-keyrings libmemcached_1.0.16-1%2Blucid1.dsc" will verify it against your normal keyrings
[05:49] <cjwatson> then you can fix up the filename ("mv libmemcached_1.0.16-1%2Blucid1.dsc libmemcached_1.0.16-1+lucid1.dsc", as above) and unpack it with "dpkg-source -x libmemcached_1.0.16-1+lucid1.dsc"
[05:51] <sontek> http://paste2.org/YZLp1NwE
[05:51] <cjwatson> Did you delete those other files or something?
[05:51] <cjwatson> Just download them again
[05:52] <sontek> I didn't download any files other than .dsc
[05:52] <sontek> I'm trying to use dget to get all of them
[05:52] <cjwatson> I'm afraid I'm running out of steam, I need to go back to bed
[05:52] <cjwatson> You should have enough information to get the source package one way or another :)
[05:53] <sontek> No worries, you were very helpful, I'll do some searching to see what dget is trying to do with this verification
[05:53] <sontek> its definitely not using what gpg uses
[05:53] <cjwatson> It's now verified the signature properly, so you just need to grab the other files
[05:53] <cjwatson> Read the error closely - it's not anything to do with gpg at this point, it's that the mentioned files don't exist locally
[05:54] <cjwatson> So the simplest fix is just to grab them and re-run dscverify --no-default-keyrings
[05:59] <sontek> yeah, I was trying to use dget to get it all
[06:00] <sontek> I was able to tell it not to verify by doing ~/.devscripts DGET_VERIFY=no
[06:00] <sontek> but the files its trying to get 404
[06:00] <sontek> So I'm just going to do it manually :P
[21:10] <jtaylor> grr a bug in the upstream numpy tarball creation means I need to a MIR for python-numpydoc :/
[21:12] <Laney> you could generate your own orig
[21:14] <jtaylor> that or multiple tarball is probably a better way
[21:15] <jtaylor> hm own tarball means I need to mess with bzr again :(
[21:17] <jtaylor> oh well git snapshot is probably better than my stack of 9 patches I was planning to do :)
[21:25] <michagogo|cloud> What does MIR stand for again?
[21:25] <jtaylor> main inclusion request
[21:25] <jtaylor> not mir the display manager
[21:25] <jtaylor> or whatever it is
[21:28] <michagogo|cloud> Why does a bug in upstream tarballs mean that the package needs to be in main?
[21:28] <jtaylor> upstream forgot to add a submodule to the tarball (why won't git fix that ...)
[21:28] <jtaylor> the content of the submodule is also in python-numpydoc which is a separate source package
[21:29] <jtaylor> fine in debian, not in ubuntu as numpydoc is universe
[22:00] <foxx> hello motus. i have a question r.e. packaging/fakechroot, which has been bugging me for days. whenever i use "fakechroot fakeroot" with deboostrap, the second stage always seems to apply the wrong prefix to symlinks.. i.e.  ls -lah home/foxx/wtf/etc/nologin shows "wtf/etc/nologin -> /home/foxx/wtf/var/lib/initscripts/nologin", so its applying full absolute path to symlinks in second stage
[22:00] <foxx> rather than "/". this is breaking some of my packaging scripts which use fakechroot combined with debootstrap. can anyone think of any way to stop this sort of behavior from happening? any help would be much appreciated.