=== thomi_ is now known as thomi === Ursinha-afk is now known as Ursinha === mfisch` is now known as mfisch === mfisch is now known as Guest32427 [05:12] hello [05:12] anyone? [05:21] sergio-br2: Hi. === wgrant_ is now known as wgrant [05:21] hi [05:21] hey, I sent a package with dput to my ppa, but it seems it went to space or something like that [05:22] in terminal it seems it worked: "Successfully uploaded packages." [05:22] but i'm waiting for 4 hours [05:25] is it normal wgrant_ ? [05:29] sergio-br2: You received a rejection email three hours ago: [05:29] 2014-07-18 02:29:51 DEBUG Rejected: [05:29] 2014-07-18 02:29:51 DEBUG Source/binary (i.e. mixed) uploads are not allowed. [05:29] 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] naaaahhh [05:30] :( [05:30] ok [05:31] (and i didn't receive email here in thunderbird... funny) [05:32] Launchpad certainly sent it to a yahoo.com.br address. [05:32] nothing here... [05:32] 2014-07-18 02:29:51 DEBUG Sent a mail: [05:32] 2014-07-18 02:29:51 DEBUG Subject: [~sergio-br2/ubuntu/ppsspp] ppsspp_0.9.8.git.20140717-0ubuntu4_amd64.changes rejected [05:33] 2014-07-18 02:29:51 DEBUG Sender: Launchpad PPA [05:33] where did you find that info? Is it public? [05:33] It's from our internal logs. [05:33] ah [05:33] thank you [05:34] there is no quote anymore for me, today, to build recipes [05:34] my last hope was using dput.. dammit [05:34] You can use dput, you just need to fix the errors that caused the rejection. [05:34] yeah, the version [05:35] but the code... it's 400 MB [05:35] 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] Can I upload only binary? [05:36] the code is so big [05:36] No. Launchpad only accepts source uploads. All binaries exposed by Launchpad are built by Launchpad. [05:36] hum [05:37] so, if I use dput, after it will publish amd64 and x86 versions? [05:37] You upload a source package, and Launchpad will use that to build i386 and amd64 binaries. [05:37] ah [05:38] well, i already have the code in launchpad, but my build request by recipes finished for today [05:40] 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] You can only build a recipe for a particular series five times in a 24 hour window. [05:40] (and I want to know how to cancel a build request) [05:41] Why do you need to cancel one? [05:41] sometimes I messed up with version, in the recipe content [05:41] 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] yeah, i tested here, and it compile was successful [05:43] 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] 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] 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] It's not possible to use 3.0 (quilt) without an orig tarball. [05:45] pristine-tar metadata? [05:45] But are you sure the patches aren't being applied anyway? [05:45] but the tarball isn't the code i host in launchpad? [05:45] IIRC when bzr-builder forces a package to 3.0 (native), it applies any quilt patches first. [05:47] for example, this: http://ppa.launchpad.net/sergio-br2/cabrio/ubuntu/dists/trusty/main/source/Sources [05:47] it has no quilt patches, but in the future maybe. And I see Format: 3.0 (native) [05:47] 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] but the code is in launchpad, and debian folder is inside [05:48] 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] Sure, Launchpad has the code. [05:48] I have no idea how to use a recipe without debian folder inside the code [05:49] 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] 3.0 (native) is usually the right choice for daily builds, as there isn't a corresponding upstream release tarball. [05:49] Are you sure it's not applying patches today, even though it's being forced to 3.0 (native)? [05:49] i don't know, i have to test it [05:50] wait, i'm processing the information [05:52] 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] Recipes always build from a Bazaar branch. They cannot use a tarball directly. [05:54] 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] hum, but with dput it's not possible to automate build for 3 version of ubuntu for example [05:55] only for trusty, or for utopic... [05:55] You need to upload each source package, yes. [05:56] and lost some time... [05:56] The orig.tar.gz can be shared between them. [05:56] yeah [05:56] It need only be uploaded in the first upload. [05:57] so i do dput ppa:sergio-br2/ppsspp ../ppsspp_0.9.8.git.20140717-0ubuntu4_amd64.changes [05:57] in the first time? [05:58] dput ppa:sergio-br2/myPPA package_amd64.changes, or [05:58] dput ppa:sergio-br2/myPPA package_amd64.source or like that? === verterok` is now known as verterok [06:18] sergio-br2: It must always be a _source.changes. [06:18] Binary uploads are not accepted. [06:19] ok [06:19] more one question: Can i use -j4 in make command, in the rules? [06:20] my package will build faster? [06:23] 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] 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] it's like it: [06:24] build-stamp: configure-stamp [06:24] dh_testdir [06:24] # Add here commands to compile the package. [06:24] $(MAKE) -C build-qt/ [06:25] 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] hey wgrant, thanks :) [06:51] bye! === wallyworld__ is now known as wallyworld === wallyworld__ is now known as wallyworld [09:51] cjwatson: it was saucy end of life coming into effect [10:00] ah, ok [10:06] geser: hey, thanks. I am looking at this now. I understand how to resubmit each package now (use debuild -S, then dput ..). [10:06] the older debia/changelog entry is 'apache-couchdb (1.6.0-0ubuntu2) precise; urgency=low' [10:07] for trusty, (and other builds) should I have 'apache-couchdb (1.6.0-0ubuntu3) trusty; urgency=low’ ? [10:07] i.e. increment the ubuntuX suffix and change the package name? Or do I need a different name? [10:08] it’s not clear how the changelog entry maps to the debuild output [10:10] dch: just increment the version. 1.6.0-0ubuntu3 would work for trusty [10:11] there's advice on versioning linked from the PPA section of help.launchpad.net somewhere [10:14] OK it seems the “best” way to do this is simply ` dch -D trusty —increment` [10:14] which DTRT [10:22] 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] and thanks for your help, I think it’s almost done :-) [10:25] Don't pass -sa to debuild [10:26] Or pass -sd to force the orig to be excluded from the .changes, although that's hardly ever necessary ... [10:27] cjwatson: thanks! [10:35] ok beautiful, working perfectly [11:45] 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] (it's my first one at all) [11:51] trash: did you got an email? [11:51] no [11:51] check if the key you used to sign the upload it registered with your LP account [11:52] I did not do that at least yet, that could be a problem :) [11:52] (this is a common error if you don't get an email about an upload) [11:54] where can I upload/link my gpg key in my launchpad profile? [11:54] I do not seem to find the proper place [11:54] ah found it [11:55] thanks :) [12:01] now came some useful email, thanks again. === jibel_ is now known as jibel [14:35] Hi there) [14:36] Can somebody help ? I need to get a milestone id using launchpadlib. Is it possible ? [14:42] akuznetsova: What sort of ID do you mean? [14:42] Id from url : &field.milestone%3Alist=63962 [14:44] I want to dynamically generate a link, I know how to get all needed parameters except milestone id [14:46] if I use lp.get_project("test").active_milestones I get list of milestone's names [14:47] Hmm [14:49] What a maze; there's really no reason you shouldn't just be able to pass a name [14:52] You could screen-scrape it out of the ?advanced=1 bug search form, but good grief that's awful [14:53] It isn't work in my case: I need to get list of bugs for a specific milestone of the project [14:54] 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] I guess this is basically https://bugs.launchpad.net/launchpad/+bug/436706 [14:54] Ubuntu bug 436706 in Launchpad itself "Milestone vocabulary leaks object id" [Low,Triaged] [14:55] And indeed bug 1241875 [14:55] bug 1241875 in Launchpad itself "Bug search does not accept milestone or series names and requires integer id" [Undecided,New] https://launchpad.net/bugs/1241875 [14:55] yes, i saw it, it is very old bug) [14:56] 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] Though I'm a bit too busy today to attack it [14:57] (This is not to say no answer exists; not an expert in the bugs code) [14:57] I do think the right answer is not to have to do this at all though [15:00] ok, thanks, try to solve my problem in a different way === JanC_ is now known as JanC === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Barnabas_ is now known as BarnabasDK [19:20] hey hello [19:21] 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] take a look: http://pastebin.com/jzBtezjt === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [22:04] sergio-br2: your package clearly isn't using the embedded versions [22:04] sergio-br2: not a Launchpad problem :) [22:05] hey [22:05] yeah [22:05] i think the problem is in headers [22:05] <> instead "" [22:05] Well, the error is from the linker [22:05] If it's a header problem, then that's quite far removed from the error [22:06] 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] Anyway, you should try it in sbuild locally, at which point you will be able to investigate directly [22:09] i tried to use pbuilder-dist [22:09] pbuilder-dist trusty build ppsspp_0.9.8.git.20140717-0ubuntu4.dsc [22:10] W: /home/sergio/.pbuilderrc does not exist [22:10] E: File /home/sergio/pbuilder/trusty-base.tgz does not exist [22:11] cjwatson, to use sbuild, just do sbuild in the directory? like debuild? [22:13] you have to create the chroot to build in, before pbuilder/sbuild will work [22:14] sudo pbuilder create ? [22:14] sergio-br2: https://wiki.ubuntu.com/SimpleSbuild [22:14] pbuilder-dist trusty create probably [22:14] or follow that link [22:14] ok [22:14] If you already have pbuilder set up, fine, but I would not start there in 2014 [22:15] sbuid better than pbuilder? [22:15] I think so [22:16] And sbuild is what Launchpad uses, albeit an ancient version [22:16] it's closer to what luanchpad uses [22:16] well, launchpad also has some configuration at least, that is different from local sbuild [22:17] hum [22:17] Yeah, but not huge amounts and not normally relevant [22:17] how can I purge what i did with pbuilder? [22:17] 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] well, behavior of $HOME and inability to hit network would be nice to have replicated locally [22:18] Pretty sure Stéphane has something for that [22:18] Or was working on it ... he was doing stuff with sbuild-launchpad-chroot [22:18] cool [22:18] (The network restrictions are technically external to Launchpad, though I realise that's immaterial to most users) [22:20] 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] I gather it's pretty easy to do with lxc [22:20] Just don't have the runes to hand [22:20] i.e. lxc-unshare rather than actually a full container [22:22] 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] 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] so let's not confuse [22:22] yeah [22:22] or he could just not try to build an internal copy of ffmpeg, and use the system libs instead [22:23] (unprivileged containers!) [22:23] 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] is upstream ffmpeg fully redistributable even? [22:24] so I can understand somebody not wanting to do it for something in a PPA [22:24] you can do something like "lxc-unshare -s "USER|NETWORK" -- /sbin/ifconfig -a" as a user on current Ubuntu [22:24] sure [22:24] 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] which is kinda sad but [22:25] yeah, ffmpeg is a mess :-/ [22:25] and that's being kind [23:07] ok, let me see if work