[11:38] <mdeslaur> I'm getting a really big error message when I try and mark bug 1382517 as a dupe of 1382133
[11:43] <mdeslaur> oh, probably because someone else did it seconds before I did, never mind
[15:04] <jefferai> Is it normal after using dput successfully for nothing to show up in your PPA even after 20 minutes or so?
[15:04] <jefferai> PPA still says nothing uploaded/empty
[15:05] <pkern> Did you check your mails?
[15:06] <dobey> 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] <jefferai> pkern: oh, no, figured if dput said successful it was successful
[15:08] <dobey> 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] <jefferai> pkern: dobey Thanks, managed to figure out the issue from the rejection email
[15:39] <jefferai> 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] <jefferai> Any idea what I'm doing wrong?
[15:47] <pkern> jefferai: Is it arch:all?
[15:47] <pkern> If so, it's only built on i386.
[15:48] <jefferai> pkern: there's no arch line specified, so maybe that's the issue
[15:49] <jefferai> pkern: my .dsc has Architecture: all
[15:49] <jefferai> so does debian/control
[15:49] <pkern> Yeah, then that's correct.
[15:49] <jefferai> (so does my source.changes file, FWIW)
[15:51] <jefferai> pkern: should it be "Architecture: any"?
[15:51] <jefferai> http://packaging.ubuntu.com/html/debian-dir-overview.html#the-changelog has an example showing that
[15:52] <jefferai> although the text shows "all"
[15:53] <jefferai> pkern: oh, oh
[15:53] <jefferai> ok, it build it as an all arch package, which makes sense
[15:53] <jefferai> but in launchpad it's marked as an "i386" build
[15:53] <jefferai> the deb shows all though
[15:53] <jefferai> so it's just a display thing
[16:19] <dobey> jefferai: it's just that arch:all packages are built on the i386 builders
[16:19] <dobey> there is no "all" builder
[16:19] <jefferai> dobey: Ah
[16:48] <binwiederhier> 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] <binwiederhier> 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] <binwiederhier> 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] <binwiederhier> and here is how it was built: https://travis-ci.org/syncany/syncany-plugin-gui/builds/38274292#L1229
[16:53] <binwiederhier> is this not the right place to ask?
[16:54] <dobey> 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] <dobey> ie, should have the .java files which get compiled into .jars
[16:57] <binwiederhier> 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] <binwiederhier> 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] <dobey> eh? a PPA isn't an "output format"
[16:58] <dobey> binary .debs are
[16:59] <binwiederhier> a PPA is one way to distribute your software.
[16:59] <binwiederhier> a windows exe file is another.
[16:59] <dobey> a PPA is a tool to build your source into binary debs as a means to distribute your software
[16:59] <dobey> the end product isn't a PPA, it's binary debs
[17:00] <binwiederhier> okay, true. but ...
[17:00] <binwiederhier> launchpad forces me to do "source packages" when i really want to build the package myself and upload it.
[17:01] <dobey> then you don't want a PPA. you want an archive that you host
[17:01] <binwiederhier> hm.
[17:02] <binwiederhier> with that archive, does the whole apt-get magic also work? is it complicated? *googling*
[17:03] <dobey> yes
[17:03] <dobey> it is more complicated
[17:03] <dobey> and you have to host it somewhere
[17:04] <binwiederhier> ...
[17:04] <binwiederhier> hm...
[17:04] <dobey> but it doesn't automatically rebuild for different versions of ubuntu, against different versions of the dependencies
[17:04] <dobey> which is the whole point of building from source in PPAs
[17:04] <binwiederhier> i realize that now.
[17:05] <binwiederhier> 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] <binwiederhier> any hints on the debian/rules stuff? i think i'm going to stick with that for now ...
[17:09] <dobey> fix your travis build to create proper source package with the actual source for uploading to the PPA
[17:10] <binwiederhier> dobey: what difference does it make? i would have to include the dependent JARs in the source package anyway.
[17:10] <binwiederhier> or i'd have to run the whole gradle on travis _and_ launchpad
[17:11] <dobey> and?
[17:11] <binwiederhier> and that's difficult.
[17:11] <dobey> how so?
[17:13] <binwiederhier> well, 1. i have no idea how the PPA stuff works (granted, my problem; and fixable)
[17:13] <binwiederhier> 2. the travis build is not really easy: https://travis-ci.org/syncany/syncany
[17:14] <binwiederhier> (https://github.com/syncany/syncany/blob/develop/.travis.yml)
[17:14] <dobey> well, downloading pre-built .jar files from a plaintext http source isn't a particularly good plan anyway
[17:15] <binwiederhier> plaintext http?
[17:15] <binwiederhier> where?
[17:16] <dobey> that's what gradle is doing, in the travis build log
[17:16] <dobey> a whole messload of pom and jar files
[17:16] <binwiederhier> from the maven repo, yes...
[17:17] <binwiederhier> but that's nothing that we can fix here and now.
[17:17] <binwiederhier> gradle/maven does that.
[17:17] <binwiederhier> well i could run this on the PPA: https://travis-ci.org/syncany/syncany#L3685
[17:18] <binwiederhier> or something like that ...
[17:19] <binwiederhier> it just seems like a lot of work "just" to distribute a couple of deb files.
[17:33] <binwiederhier> dobey: this doesn't look so complicated: https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro
[17:33] <binwiederhier> it's waayyyy less complicated than the whole PPA process.
[17:35] <dobey> you're making the PPA process waayyyy more complicated than it needs to be
[17:36] <dobey> gradle/maven certainly don't seem to be helping with that either though
[17:36] <binwiederhier> :D
[22:07] <binwiederhier> 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] <dobey> 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] <binwiederhier> i kinda thought PPA = archive; turns out that is definitely not the case.
[22:11] <binwiederhier> but yet, confusing is the least of it. PPAs are hard :D
[22:12] <dobey> 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] <binwiederhier> in my case, blind is good. all the hard work is done by travis.
[22:13] <binwiederhier> and since i have a server anyway, there is no issue here.