[05:12] <sergio-br2> hello
[05:12] <sergio-br2> anyone?
[05:21] <wgrant_> sergio-br2: Hi.
[05:21] <sergio-br2> hi
[05:21] <sergio-br2> hey, I sent a package with dput to my ppa, but it seems it went to space or something like that
[05:22] <sergio-br2> in terminal it seems it worked: "Successfully uploaded packages."
[05:22] <sergio-br2> but i'm waiting for 4 hours
[05:25] <sergio-br2> is it normal wgrant_ ?
[05:29] <wgrant> sergio-br2: You received a rejection email three hours ago:
[05:29] <wgrant> 2014-07-18 02:29:51 DEBUG   Rejected:
[05:29] <wgrant> 2014-07-18 02:29:51 DEBUG   Source/binary (i.e. mixed) uploads are not allowed.
[05:29] <wgrant> 2014-07-18 02:29:51 DEBUG   ppsspp_0.9.8.git.20140717-0ubuntu4.dsc: Version older than that in the archive. 0.9.8.git.20140717-0ubuntu4 <= 0.9.8.git.20140717.2~ubuntu14.04.1
[05:30] <sergio-br2> naaaahhh
[05:30] <sergio-br2> :(
[05:30] <sergio-br2> ok
[05:31] <sergio-br2> (and i didn't receive email here in thunderbird... funny)
[05:32] <wgrant> Launchpad certainly sent it to a yahoo.com.br address.
[05:32] <sergio-br2> nothing here...
[05:32] <wgrant> 2014-07-18 02:29:51 DEBUG   Sent a mail:
[05:32] <wgrant> 2014-07-18 02:29:51 DEBUG     Subject: [~sergio-br2/ubuntu/ppsspp] ppsspp_0.9.8.git.20140717-0ubuntu4_amd64.changes rejected
[05:33] <wgrant> 2014-07-18 02:29:51 DEBUG     Sender: Launchpad PPA <no_reply@launchpad.net>
[05:33] <sergio-br2> where did you find that info? Is it public?
[05:33] <wgrant> It's from our internal logs.
[05:33] <sergio-br2> ah
[05:33] <sergio-br2> thank you
[05:34] <sergio-br2> there is no quote anymore for me, today, to build recipes
[05:34] <sergio-br2> my last hope was using dput.. dammit
[05:34] <wgrant> You can use dput, you just need to fix the errors that caused the rejection.
[05:34] <sergio-br2> yeah, the version
[05:35] <sergio-br2> but the code... it's 400 MB
[05:35] <wgrant> Specifically, you tried to upload binaries (you need to give -S to dpkg-buildpackage or debuild to ask for a source-only upload), and your version was bad.
[05:36] <sergio-br2> Can I upload only binary?
[05:36] <sergio-br2> the code is so big
[05:36] <wgrant> No. Launchpad only accepts source uploads. All binaries exposed by Launchpad are built by Launchpad.
[05:36] <sergio-br2> hum
[05:37] <sergio-br2> so, if I use dput, after it will publish amd64 and x86 versions?
[05:37] <wgrant> You upload a source package, and Launchpad will use that to build i386 and amd64 binaries.
[05:37] <sergio-br2> ah
[05:38] <sergio-br2> well, i already have the code in launchpad, but my build request by recipes finished for today
[05:40] <sergio-br2> for example, the last build request for trusty was 12 hours ago, so i have to wait more 12 to try to request again other build?
[05:40] <wgrant> You can only build a recipe for a particular series five times in a 24 hour window.
[05:40] <sergio-br2> (and I want to know how to cancel a build request)
[05:41] <wgrant> Why do you need to cancel one?
[05:41] <sergio-br2> sometimes I messed up with version, in the recipe content
[05:41] <wgrant> It's very rare that you would need more than five a day, or to cancel one. You should always be test building locally first, so the Launchpad builds should work first time.
[05:41] <sergio-br2> yeah, i tested here, and it compile was successful
[05:43] <sergio-br2> hey wgrant, do you know how can I force debuild (in the server) to use quilt instead native? Do I have to change something in rules?
[05:44] <sergio-br2> i have some quilt patches in other program, and debian package is in upstream now. So I need to run the quilt patches, even if package is native
[05:44] <wgrant> sergio-br2: It will use 3.0 (quilt) if your package specifies 3.0 (quilt) in debian/source/format and your branch has pristine-tar metadata to construct an orig tarball.
[05:44] <wgrant> It's not possible to use 3.0 (quilt) without an orig tarball.
[05:45] <sergio-br2>  pristine-tar metadata?
[05:45] <wgrant> But are you sure the patches aren't being applied anyway?
[05:45] <sergio-br2> but the tarball isn't the code i host in launchpad?
[05:45] <wgrant> IIRC when bzr-builder forces a package to 3.0 (native), it applies any quilt patches first.
[05:47] <sergio-br2> for example, this: http://ppa.launchpad.net/sergio-br2/cabrio/ubuntu/dists/trusty/main/source/Sources
[05:47] <sergio-br2> it has no quilt patches, but in the future maybe. And I see Format: 3.0 (native)
[05:47] <wgrant> That's a 3.0 (native) package. A 3.0 (quilt) package has a .dsc, a .debian.tar.gz, and a .orig.tar.gz.
[05:48] <sergio-br2> but the code is in launchpad, and debian folder is inside
[05:48] <wgrant> If bzr-builder sees a 3.0 (quilt) package but you haven't given it the pristine-tar metadata it needs to generate the orig.tar.gz (eg. using 'bzr import-upstream'), it will apply the quilt patches and force it to 3.0 (native).
[05:48] <wgrant> Sure, Launchpad has the code.
[05:48] <sergio-br2> I have no idea how to use a recipe without debian folder inside the code
[05:49] <wgrant> But an orig.tar.gz is usually bit-identical to the upstream tarball, so it can't reasonably be generated manually without the pristine-tar data.
[05:49] <wgrant> 3.0 (native) is usually the right choice for daily builds, as there isn't a corresponding upstream release tarball.
[05:49] <wgrant> Are you sure it's not applying patches today, even though it's being forced to 3.0 (native)?
[05:49] <sergio-br2> i don't know, i have to test it
[05:50] <sergio-br2> wait, i'm processing the information
[05:52] <sergio-br2> so, i don't need to import all code of upstream to launchpad? I can maintain a debian folder in the launchpad bzr, and it can download a tarball from git or sourceforge, with this pristine-tar metadata?
[05:53] <wgrant> Recipes always build from a Bazaar branch. They cannot use a tarball directly.
[05:54] <wgrant> Manual uploads using dput can use an upstream tarball, but Launchpad won't grab an external tarball automatically: you need to upload it the first time you use it.
[05:55] <sergio-br2> hum, but with dput it's not possible to automate build for 3 version of ubuntu for example
[05:55] <sergio-br2> only for trusty, or for utopic...
[05:55] <wgrant> You need to upload each source package, yes.
[05:56] <sergio-br2> and lost some time...
[05:56] <wgrant> The orig.tar.gz can be shared between them.
[05:56] <sergio-br2> yeah
[05:56] <wgrant> It need only be uploaded in the first upload.
[05:57] <sergio-br2> so i do dput ppa:sergio-br2/ppsspp ../ppsspp_0.9.8.git.20140717-0ubuntu4_amd64.changes
[05:57] <sergio-br2> in the first time?
[05:58] <sergio-br2> dput ppa:sergio-br2/myPPA package_amd64.changes, or
[05:58] <sergio-br2> dput ppa:sergio-br2/myPPA package_amd64.source or like that?
[06:18] <wgrant> sergio-br2: It must always be a _source.changes.
[06:18] <wgrant> Binary uploads are not accepted.
[06:19] <sergio-br2> ok
[06:19] <sergio-br2> more one question: Can i use -j4 in make command, in the rules?
[06:20] <sergio-br2> my package will build faster?
[06:23] <wgrant> sergio-br2: You wouldn't do that directly. Packages should examine the "DEB_BUILD_OPTIONS" environment variable's "parallel" key, which specifies the number of concurrent jobs to run. That way the builder can tell the build how many cores to use.
[06:23] <wgrant> If you're using a modern debian/rules that uses dh's automatic targets, you can just give dh the --parallel option. But if you're directly invoking make yourself, you'll need to construct a -j option manually.
[06:24] <sergio-br2> it's like it:
[06:24] <sergio-br2> build-stamp: configure-stamp
[06:24] <sergio-br2> 	dh_testdir
[06:24] <sergio-br2> 	# Add here commands to compile the package.
[06:24] <sergio-br2> 	$(MAKE) -C build-qt/
[06:25] <geser> dch: no, not different ppas but different versions: e.g. 1.0-0ubuntu1precise1 for the precise upload, 1.0-0ubuntu1trusty1 for the trusty upload, etc. (all can go into the same ppa)
[06:51] <sergio-br2> hey wgrant, thanks :)
[06:51] <sergio-br2> bye!
[09:51] <Mez> cjwatson: it was saucy end of life coming into effect
[10:00] <cjwatson> ah, ok
[10:06] <dch> geser: hey, thanks. I am looking at this now. I understand how to resubmit each package now (use debuild -S, then dput ..).
[10:06] <dch> the older debia/changelog entry is 'apache-couchdb (1.6.0-0ubuntu2) precise; urgency=low'
[10:07] <dch> for trusty, (and other builds) should I have 'apache-couchdb (1.6.0-0ubuntu3) trusty; urgency=low’ ?
[10:07] <dch> i.e. increment the ubuntuX suffix and change the package name? Or do I need a different name?
[10:08] <dch> it’s not clear how the changelog entry maps to the debuild output
[10:10] <geser> dch: just increment the version. 1.6.0-0ubuntu3 would work for trusty
[10:11] <cjwatson> there's advice on versioning linked from the PPA section of help.launchpad.net somewhere
[10:14] <dch> OK it seems the “best” way to do this is simply ` dch -D trusty —increment`
[10:14] <dch> which DTRT
[10:22] <dch> ok, submitted that but I get a warning about multiple upload of the orig.tar.gz, is there a way to suppress dput trying to upload the .orig.tar.gz again?
[10:22] <dch> and thanks for your help, I think it’s almost done :-)
[10:25] <cjwatson> Don't pass -sa to debuild
[10:26] <cjwatson> Or pass -sd to force the orig to be excluded from the .changes, although that's hardly ever necessary ...
[10:27] <dch> cjwatson: thanks!
[10:35] <dch> ok beautiful, working perfectly
[11:45] <trash> how long does it usually take for a ppa to appear on launchpad? I success fully uploaded a *changes file via dput and it did not appear
[11:45] <trash> (it's my first one at all)
[11:51] <geser> trash: did you got an email?
[11:51] <trash> no
[11:51] <geser> check if the key you used to sign the upload it registered with your LP account
[11:52] <trash> I did not do that at least yet, that could be a problem :)
[11:52] <geser> (this is a common error if you don't get an email about an upload)
[11:54] <trash> where can I upload/link my gpg key in my launchpad profile?
[11:54] <trash> I do not seem to find the proper place
[11:54] <trash> ah found it
[11:55] <trash> thanks :)
[12:01] <trash> now came some useful email, thanks again.
[14:35] <akuznetsova> Hi there)
[14:36] <akuznetsova> Can somebody help ? I need to get a milestone id using launchpadlib. Is it possible ?
[14:42] <cjwatson> akuznetsova: What sort of ID do you mean?
[14:42] <akuznetsova> Id from url : &field.milestone%3Alist=63962
[14:44] <akuznetsova> I want to dynamically generate a link, I know how to get all needed parameters except milestone id
[14:46] <akuznetsova> if I use lp.get_project("test").active_milestones I get list of milestone's names
[14:47] <cjwatson> Hmm
[14:49] <cjwatson> What a maze; there's really no reason you shouldn't just be able to pass a name
[14:52] <cjwatson> You could screen-scrape it out of the ?advanced=1 bug search form, but good grief that's awful
[14:53] <akuznetsova> It isn't work in my case: I need to get list of bugs for a specific milestone of the project
[14:54] <cjwatson> Right, but the advanced bug search form has the list of milestones with their object IDs in the "value" attribute.  It's awful though.
[14:54] <cjwatson> I guess this is basically https://bugs.launchpad.net/launchpad/+bug/436706
[14:55] <cjwatson> And indeed bug 1241875
[14:55] <akuznetsova> yes, i saw it, it is very old bug)
[14:56] <cjwatson> I would love to have a better answer but I don't; making field.milestone accept the milestone name as an alternative would probably not be too difficult, as a first step
[14:56] <cjwatson> Though I'm a bit too busy today to attack it
[14:57] <cjwatson> (This is not to say no answer exists; not an expert in the bugs code)
[14:57] <cjwatson> I do think the right answer is not to have to do this at all though
[15:00] <akuznetsova> ok, thanks, try to solve my problem in a different way
[19:20] <sergio-br2> hey hello
[19:21] <sergio-br2> i'm trying to make a package with recipe, but it seems it complains about missing dependence. But I'm using embedded libraries here, ffmpeg and glew
[19:21] <sergio-br2> take a look: http://pastebin.com/jzBtezjt
[22:04] <cjwatson> sergio-br2: your package clearly isn't using the embedded versions
[22:04] <cjwatson> sergio-br2: not a Launchpad problem :)
[22:05] <sergio-br2> hey
[22:05] <sergio-br2> yeah
[22:05] <sergio-br2> i think the problem is in headers
 instead ""
[22:05] <cjwatson> Well, the error is from the linker
[22:05] <cjwatson> If it's a header problem, then that's quite far removed from the error
[22:06] <cjwatson> You might find the library in question isn't actually being built or something; some build systems aren't good at stopping at the first error
[22:06] <cjwatson> Anyway, you should try it in sbuild locally, at which point you will be able to investigate directly
[22:09] <sergio-br2> i tried to use pbuilder-dist
[22:09] <sergio-br2> pbuilder-dist trusty build ppsspp_0.9.8.git.20140717-0ubuntu4.dsc
[22:10] <sergio-br2> W: /home/sergio/.pbuilderrc does not exist
[22:10] <sergio-br2> E: File /home/sergio/pbuilder/trusty-base.tgz does not exist
[22:11] <sergio-br2> cjwatson, to use sbuild, just do sbuild in the directory? like debuild?
[22:13] <dobey> you have to create the chroot to build in, before pbuilder/sbuild will work
[22:14] <sergio-br2> sudo pbuilder create ?
[22:14] <cjwatson> sergio-br2: https://wiki.ubuntu.com/SimpleSbuild
[22:14] <dobey> pbuilder-dist trusty create probably
[22:14] <dobey> or follow that link
[22:14] <sergio-br2> ok
[22:14] <cjwatson> If you already have pbuilder set up, fine, but I would not start there in 2014
[22:15] <sergio-br2> sbuid better than pbuilder?
[22:15] <cjwatson> I think so
[22:16] <cjwatson> And sbuild is what Launchpad uses, albeit an ancient version
[22:16] <dobey> it's closer to what luanchpad uses
[22:16] <dobey> well, launchpad also has some configuration at least, that is different from local sbuild
[22:17] <sergio-br2> hum
[22:17] <cjwatson> Yeah, but not huge amounts and not normally relevant
[22:17] <sergio-br2> how can I purge what i did with pbuilder?
[22:17] <cjwatson> Also pbuilder *still* has no way to keep the base directory in anything other than a tarball, which is dreadfully slow unless your disks are really fast.  cowbuilder takes a somewhat more sensible approach, but sbuild has that built in
[22:17] <dobey> well, behavior of $HOME and inability to hit network would be nice to have replicated locally
[22:18] <cjwatson> Pretty sure Stéphane has something for that
[22:18] <cjwatson> Or was working on it ... he was doing stuff with sbuild-launchpad-chroot
[22:18] <dobey> cool
[22:18] <cjwatson> (The network restrictions are technically external to Launchpad, though I realise that's immaterial to most users)
[22:20] <dobey> yeah, i'd like to have a way to enforce that when i do "make check" in my local development tree, and not have to rely on errors popping up when stuff hits launchpad
[22:20] <cjwatson> I gather it's pretty easy to do with lxc
[22:20] <cjwatson> Just don't have the runes to hand
[22:20] <cjwatson> i.e. lxc-unshare rather than actually a full container
[22:22] <dobey> sure. but i'd prefer something i can easily integrate into a project's build system and doesn't require running anything as root or such
[22:22] <cjwatson> sergio-br2's case isn't going to need this though - all it needs is a build in a clean chroot with just the declared build-dependencies installed on top
[22:22] <cjwatson> so let's not confuse
[22:22] <dobey> yeah
[22:22] <dobey> or he could just not try to build an internal copy of ffmpeg, and use the system libs instead
[22:23] <cjwatson> (unprivileged containers!)
[22:23] <cjwatson> well, I would certainly recommend that for anything in Ubuntu proper, but from experience I can say that that's often a lot of work, unfortunately
[22:24] <dobey> is upstream ffmpeg fully redistributable even?
[22:24] <cjwatson> so I can understand somebody not wanting to do it for something in a PPA
[22:24] <stgraber> you can do something like "lxc-unshare -s "USER|NETWORK" -- /sbin/ifconfig -a" as a user on current Ubuntu
[22:24] <dobey> sure
[22:24] <cjwatson> we've had a number of cases even where we thought we had a full port to current libav and then it turned out to have runtime bugs that didn't appear with ffmpeg - often needs an expert
[22:25] <cjwatson> which is kinda sad but
[22:25] <dobey> yeah, ffmpeg is a mess :-/
[22:25] <dobey> and that's being kind
[23:07] <sergio-br2> ok, let me see if work