[11:38] I'm getting a really big error message when I try and mark bug 1382517 as a dupe of 1382133 [11:38] bug 1382133 in evolution-data-server (Ubuntu Trusty) "duplicate for #1382517 Issue with servers with SSLv3 disabled due to Poodle " [Undecided,In progress] https://launchpad.net/bugs/1382133 [11:43] oh, probably because someone else did it seconds before I did, never mind === karni is now known as karni-lunch === karni-lunch is now known as karni [15:04] Is it normal after using dput successfully for nothing to show up in your PPA even after 20 minutes or so? [15:04] PPA still says nothing uploaded/empty [15:05] Did you check your mails? [15:06] if you didn't get a mail, most likely cause is you signed the source with the wrong key (or it was unsigned) [15:06] pkern: oh, no, figured if dput said successful it was successful [15:08] jefferai: dput only knows about the upload of files to the ftp; it has no idea what launchpad does with the files after that [15:17] pkern: dobey Thanks, managed to figure out the issue from the rejection email [15:39] OK, one more question. The help guide says that each package you push up is built on 386 and amd64. But mine was only built on 386. I don't see anywhere in the control files a specification that it should be 386 only [15:39] Any idea what I'm doing wrong? [15:47] jefferai: Is it arch:all? [15:47] If so, it's only built on i386. [15:48] pkern: there's no arch line specified, so maybe that's the issue [15:49] pkern: my .dsc has Architecture: all [15:49] so does debian/control [15:49] Yeah, then that's correct. [15:49] (so does my source.changes file, FWIW) [15:51] pkern: should it be "Architecture: any"? [15:51] http://packaging.ubuntu.com/html/debian-dir-overview.html#the-changelog has an example showing that [15:52] although the text shows "all" [15:53] pkern: oh, oh [15:53] ok, it build it as an all arch package, which makes sense [15:53] but in launchpad it's marked as an "i386" build [15:53] the deb shows all though [15:53] so it's just a display thing === karni is now known as karni-eod [16:19] jefferai: it's just that arch:all packages are built on the i386 builders [16:19] there is no "all" builder [16:19] dobey: Ah [16:48] Hi there, when I want to build an architecture-dependent package on Launchpad, does the source package have to include the "sources" for all architectures? In my case the "sources" are Java/SWT JAR files containing native i386 and amd64 libraries. [16:48] If so, how can I control the build process so that the i386 JAR is included in the i386 build and the amd64 JAR in the am64 build? [16:49] Here's an example source package (here: only for amd64): https://launchpad.net/~syncany/+archive/ubuntu/snapshot/+files/syncany-plugin-gui_0.1.12.alpha%2BSNAPSHOT.1410171552.git782ac5b%7Etrustyppa1.tar.gz [16:52] and here is how it was built: https://travis-ci.org/syncany/syncany-plugin-gui/builds/38274292#L1229 [16:53] is this not the right place to ask? [16:54] binwiederhier: the source package should include the upstream source with build system info and all, and debian/rules would specify how to create the binaries and install them to the system [16:55] ie, should have the .java files which get compiled into .jars [16:57] i realize that, but since the PPA is just one of the output formats i'm building, i'd rather let Travis build the JARs and do the packaging on Launchpad -- or I could move all the other output types to launchpad, but I don't think that's a good idea... [16:58] i figured that the debian/rules file has something to do with that. do you have any examples on how to do "if(amd64) then copy this file"? [16:58] eh? a PPA isn't an "output format" [16:58] binary .debs are [16:59] a PPA is one way to distribute your software. [16:59] a windows exe file is another. [16:59] a PPA is a tool to build your source into binary debs as a means to distribute your software [16:59] the end product isn't a PPA, it's binary debs [17:00] okay, true. but ... [17:00] launchpad forces me to do "source packages" when i really want to build the package myself and upload it. [17:01] then you don't want a PPA. you want an archive that you host [17:01] hm. [17:02] with that archive, does the whole apt-get magic also work? is it complicated? *googling* [17:03] yes [17:03] it is more complicated [17:03] and you have to host it somewhere [17:04] ... [17:04] hm... [17:04] but it doesn't automatically rebuild for different versions of ubuntu, against different versions of the dependencies [17:04] which is the whole point of building from source in PPAs [17:04] i realize that now. [17:05] but for me and my project, it's just a way to distribute the software -- which is probably a terrible belittling of the PPA concept ... [17:06] any hints on the debian/rules stuff? i think i'm going to stick with that for now ... [17:09] fix your travis build to create proper source package with the actual source for uploading to the PPA [17:10] dobey: what difference does it make? i would have to include the dependent JARs in the source package anyway. [17:10] or i'd have to run the whole gradle on travis _and_ launchpad [17:11] and? [17:11] and that's difficult. [17:11] how so? [17:13] well, 1. i have no idea how the PPA stuff works (granted, my problem; and fixable) [17:13] 2. the travis build is not really easy: https://travis-ci.org/syncany/syncany [17:14] (https://github.com/syncany/syncany/blob/develop/.travis.yml) [17:14] well, downloading pre-built .jar files from a plaintext http source isn't a particularly good plan anyway [17:15] plaintext http? [17:15] where? [17:16] that's what gradle is doing, in the travis build log [17:16] a whole messload of pom and jar files [17:16] from the maven repo, yes... [17:17] but that's nothing that we can fix here and now. [17:17] gradle/maven does that. [17:17] well i could run this on the PPA: https://travis-ci.org/syncany/syncany#L3685 [17:18] or something like that ... [17:19] it just seems like a lot of work "just" to distribute a couple of deb files. [17:33] dobey: this doesn't look so complicated: https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro [17:33] it's waayyyy less complicated than the whole PPA process. [17:35] you're making the PPA process waayyyy more complicated than it needs to be [17:36] gradle/maven certainly don't seem to be helping with that either though [17:36] :D === RedDwarf is now known as Zackio [22:07] dobey: Thanks again for the tip with the archive. That was indeed a lot easier. :D I seemed to have misunderstood PPAs entirely -- and that after 6 years of using Ubuntu... At least now I get it. [22:09] binwiederhier: well, experience using ubuntu != experience building packages for ubuntu. if you aren't mirroring code to launchpad, or more of an ubuntu developer (one who builds a lot of packages), PPAs can be a bit confusing [22:10] i kinda thought PPA = archive; turns out that is definitely not the case. [22:11] but yet, confusing is the least of it. PPAs are hard :D [22:12] well a PPA is an archive, but it's integrated into launchpad and there are some polices about what one can host in it. it's not simply a blind archive :) [22:13] in my case, blind is good. all the hard work is done by travis. [22:13] and since i have a server anyway, there is no issue here.