[00:00] <tpham3783> dobey, yeah, notice that too..... thanks and good bye
[04:00] <karstensrage> :( wgrant im having a hard time getting my head around this
[04:01] <karstensrage> my library depends on libssl and libxml2 and it seems like it shoud be compiled against the distribution its being put on
[04:01] <karstensrage> but i dont get really how this is supposed to work with changelog
[04:02] <karstensrage> it seems like changelog should be templated... so that you just build multiple .changes and .dsc that have the exact same stuff but different versions
[04:02] <karstensrage> but nothing changes in changelog except the version and distribution
[04:04] <karstensrage> im kind of curious why launchpad deleted the previous package maybe cause it failed to build?
[04:04] <karstensrage> or is always only going to keep the last version if the version changes?
[04:14] <karstensrage> http://askubuntu.com/questions/20835/how-do-i-copy-packages-within-a-ppa-from-one-release-to-another-nonsensical-s
[04:14] <karstensrage> this seems to reflect that, all you can do i just change the version
[04:15] <karstensrage> in changelog
[04:15] <karstensrage> has anyone thought of the idea of jinja2 templating changelog and have the build process take a distribution and the ppa/ubuntu thing?
[04:52] <wgrant> karstensrage: You need to upload a different source package for each set of binaries that you want to be built.
[04:52] <wgrant> Launchpad only keeps the most recent version of each package in each series.
[04:59] <karstensrage> wgrant, but nothing is changing for (what's 11.10), 12,04, 13.10, 14,04, etc
[05:00] <karstensrage> the docs said something like 1.0-1ubuntu~trusty1
[05:00] <karstensrage> so *ALL* that changes is that damn string in changelog
[05:00] <wgrant> karstensrage: That's the only change in the source, yes.
[05:01] <wgrant> But different series will build different binaries, and different binaries must have different versions.
[05:01] <karstensrage> so if i write some script that templates changelog, debbuild -S and get 7 .changes and 7 .dsc's just upload all of those?
[05:02] <karstensrage> does 12.04 (precise) work for 13.10 ?
[05:02] <wgrant> Ubuntu 13.10 has been unsupported for nearly two years.
[05:03] <wgrant> The only supported series today are 12.04, 14.04, 15.04, 15.10
[05:03] <karstensrage> people still have them
[05:03] <wgrant> Their machines are probably part of a botnet by now :)
[05:03] <wgrant> Launchpad does not build for EOL Ubuntu series.
[05:03] <karstensrage> what im asking is not that
[05:04] <karstensrage> do you have to have specific version for everything ubuntu puts out?
[05:04] <wgrant> It depends on your package's dependencies.
[05:04] <karstensrage> heres the way i think about it
[05:04] <wgrant> If, for example, a library that you depend on changes its ABI, you'll have to build a separate version for each ABI.
[05:05] <karstensrage> i put up the source, its the source
[05:05] <karstensrage> build it for whatever machine asks for it
[05:06] <karstensrage> is there someone thats whole life is just chasing ubuntu versions and resubmitting tomcat for every single version?
[05:06] <karstensrage> or any package really?
[05:06] <wgrant> There is one Ubuntu release every six months; it is not particularly onerous.
[05:07] <karstensrage> and what about older versions?
[05:07] <wgrant> What do you mean/
[05:07] <karstensrage> 11.10, 12.04, 13.10
[05:07] <karstensrage> 10.04
[05:07] <wgrant> 12.04 is still supported, the others are not.
[05:08] <karstensrage> they are still out there
[05:08] <wgrant> Anybody running them is reckless, as they have numerous unpatched security vulnerabilities.
[05:08] <wgrant> We cannot support them.
[05:09] <karstensrage> i want them to be able to install my stuff regardless of what they have
[05:10] <karstensrage> just like back then i could install apt-get install tomcat6
[05:10] <karstensrage> today i just apt-get install tomcat7
[05:10] <karstensrage> and later apt-get install tomcat8
[05:10] <karstensrage> for me its all three apt-get install mylib
[05:10] <wgrant> Launchpad does not build for obsolete Ubuntu series.
[05:11] <wgrant> If you want to support people with vulnerable machines, you'll need to distribute the packages from somewhere else.
[05:11] <karstensrage> where does 15.10 get its stuff?
[05:11] <karstensrage> from 14.04 packages?
[05:11] <wgrant> Which stuff?
[05:11] <karstensrage> its tomcat8
[05:11] <wgrant> Some binary packages are copied, others are rebuilt.
[05:12] <wgrant> https://launchpad.net/ubuntu/+source/tomcat8 shows the version in each supported series.
[05:12] <oranged> quick question.. i am logged in however the 'report a bug' link takes me to a wiki..
[05:12] <wgrant> oranged: Ubuntu overrides their Launchpad bug filing link to point to that page. The wiki explains the various avenues for filing an Ubuntu bug.
[05:13] <wgrant> karstensrage: 14.04 doesn't have tomcat8, and 15.04, 15.10 and xenial all have different versions.
[05:13] <oranged> wgrant; thanks
[05:13] <oranged> wgrant; i thought i was nuts.
[05:17] <karstensrage> xenial is 16.04?
[05:17] <wgrant> xenial will be 16.04, yes.
[05:18] <karstensrage> ok hmm
[05:18] <karstensrage> maybe i should move all this to 14.04 and just resubmit every 6 months like you said?
[05:18] <wgrant> Move all which?
[05:18] <karstensrage> all my work so far as been on a 12.04 vm that i use for a lot of development work
[05:19] <karstensrage> so everything is built and tested on 12.04
[05:19] <wgrant> 12.04 is only supported for another 14 or so months. It would be unwise to deploy anything new on it at this point.
[05:19] <wgrant> 14.04 is the current LTS release, and 16.04 will be the next.
[05:19] <karstensrage> i think you underestimate how many old systems are out there
[05:19] <wgrant> Oh, I'm well aware, and running 12.04 today is fine.
[05:20] <wgrant> But if you are making any significant changes to deployment, it's probably wise to upgrade to something that will last more than a year.
[05:20] <wgrant> And if you're running an EOL Ubuntu release, tell me your address so I can come and unplug that machine from the Internet :)
[05:21] <karstensrage> i thought botnets were all windows machines
[05:21] <StevenK> Nope
[05:21] <wgrant> Regrettably not, though there are an awful lot of those.
[05:21] <wgrant> I guess you know you've really made it as an OS when there are botnets of your machines!
[09:22] <sunweaver> good morning (CET)
[09:22] <sunweaver> I am unable to log into wiki.ubuntu.com using my Ubuntu ONE account.
[10:30] <cjwatson> sunweaver: We can't help you here; we maintain neither of those systems.  Try #canonical-sysadmin
[10:39] <sunweaver> cjwatson: thanks.
[12:21] <xnox> the target must be the path within the targer repository
[12:21] <xnox> -> shouldn't that be like preset to :master ? and/or whatever development focus (aka remote HEAD) are?
[12:22] <cjwatson> we need a better picker for that in general
[12:22] <cjwatson> definitely a known problem
[12:22] <tsimonq2> just curious, If I make a merge proposal and it needs fixing, how do I get that fix to the reviewer? Do I jommit to the branch? what?
[12:22] <tsimonq2> *commit
[12:23] <cjwatson> tsimonq2: Just add further commits on top of your branch with your fixes.
[12:23] <tsimonq2> cjwatson: ahh okay thanks :)
[15:58] <kamal> I've just gotten ARM builds enabled for a PPA which supplies > 200 packages.  How can I make LP rebuild all the existing packages in that PPA for the ARM arches?  (And bumping the version numbers and re-uploading all those packages is not a palatable solution!)
[15:59] <teward> kamal: select all the packages, copy existing binaries to the same PPA
[15:59] <teward> wait an eon
[15:59] <teward> though, if you're sending 200 builds to the builders, I think the LP admins will be annoyed
[15:59] <teward> s/will be/may be/
[15:59] <kamal> teward, I tried exactly that, but LP doesn't buy it ...
[15:59] <kamal> "Launchpad encountered an error during the following operation: copying a package.  trustedqsl 2.2-2~kamal~vivid in vivid (same version already has published binaries in the destination archive)"
[16:00] <teward> kamal: FWIW vivid went EOL
[16:00] <kamal> teward, :-)    Launchpad encountered an error during the following operation: copying a package.  trustedqsl 2.2-2~kamal~xenial in xenial (same version already has published binaries in the destination archive)
[16:00] <kamal> teward, i.e. same result for supported releases as well
[16:02] <teward> i can't replicate, but I also can't see what you're selecting
[16:02] <teward> My GUESS is you have "Rebuild" ticked...
[16:02] <teward> not "copy existing binaries", but don't quote me on that
[16:03] <teward> the people who can help are the LP admins; however, again, without knowing the build system fluently, you may want to consider NOT throwing 200 armhf builds into the queues
[16:03] <kamal> teward, yes I did tick "Rebuild" (since I wanted it to build something)...  "Copy existing binaries" makes no sense here, I think.
[16:04] <teward> kamal: actually, 'copy existing binaries' makes more sense
[16:04] <teward> it'll sense armhf is misisng, and build
[16:04] <teward> it's how i kicked the ZNC and NGINX PPAs I run into rebuilding for missing releases
[16:04] <teward> and how i'm getting ppc64el building right now for my nginx ppas :P
[16:04] <teward> kamal: missing binaries then get built, I believe
[16:05] <teward> sounds counter intuitive, but it apparently works
[16:05] <kamal> teward, wow!  "Copy existing binaries" does indeed work!   ok, I still don't get the logic of that verbiage at all, but . . .  THANKS!
[16:05] <teward> kamal: note though that if your armhf builds take up all the builders, I think myself, many others, and the LP admins might squish you :P
[16:05] <teward> (just saying)
[16:05] <kamal> teward, they know where to find me  ;-)
[16:25] <cjwatson> kamal: Copy the packages in question over the top of themselves, including binaries
[16:26] <cjwatson> kamal: i.e. "Copy packages" in the PPA in question, select the relevant packages, "This PPA", "The same series", "Copy existing binaries"
[16:26] <kamal> cjwatson, teward sorted me out ... the magic solution was that I needed to select "Copy existing binaries".
[16:26] <teward> cjwatson: wouldn't 200 packages going for armhf builds take up a majority of the builders though?
[16:26] <kamal> cjwatson, yup :-)
[16:26] <teward> and clog the queue?
[16:26] <cjwatson> teward: *shrug*
[16:26] <cjwatson> teward: will clear quick enough
[16:27] <dobey> teward: no different than 200 different people requesting builds at the same time, of the same priority.
[16:27] <cjwatson> teward: (also may not be quite that many sources)
[16:28] <cjwatson> teward: anyway, we can deal with abuse if it happens, but the build farm is there to be used
[16:28] <teward> indeed
[16:28]  * teward just sent all his nginx packages through the ppc64el builds :P
[16:30] <tpham3783> wgrant, !
[16:33] <dobey> huh
[16:35] <tpham3783> hi dobey, i think i understand why you said packaging information shouldn't be included in the source package... b/c thats just to much to info to maintain as a developer..
[16:36] <tpham3783> i was just wanting to adopt the way wireshark included the packaging info for debian in their source tree,
[16:36] <tpham3783> to e20... but may not be a good choice
[16:37] <tpham3783> furthermore, packaging info can only support **most likely** the latest flavors .... it wont be able to support old flavors like precise etc....
[16:38] <tpham3783> that's just too much combination, and overhead for the developer to maintain
[16:38] <dobey> packaging can support multiple series easily enough
[16:38] <dobey> the main problem is that binaries built on different series, are different, and so should have different versions
[16:39] <dobey> this will especially be a problem with the enlightenment stack, because there are many libraries and such
[16:39] <tpham3783> dobey, i ran info this problem the other day, i had a build dependency libjson, and its not available on precise... so pretty much, i would need to write another recipe for precise, particularly
[16:39] <dobey> json is available on precise
[16:42] <tpham3783> i think it was lib json,, here: https://code.launchpad.net/~tpham3783/+recipe/edkit-daily
[16:42] <tpham3783> libjson-c-dev
[16:47] <tpham3783> dobey, is the file at debian/<pkg>.install neccessary?  what if I do not have it?  is it like an install mask?
[16:50] <dobey> for packages that build a single binary is't not necessary; if you build multiple binaries, you must have .install files because they list the files that go in that package
[16:52] <cjwatson> debian/*.install is described in "man dh_install"
[16:52] <cjwatson> in general the various debhelper manual pages are excellent and you should consult them
[16:53] <tpham3783> dobey, i have a closed source project but I want to leverage LP to build for all flavors of U., is it possible to write a recipe but yet somehow keep the source closed?
[16:53] <cjwatson> Recipes don't yet support builds of private code.
[16:53] <cjwatson> (It's hopefully coming in the next few months, although probably only for git)
[19:29] <tpham3783> cjwatson, as a developer and a packager of a private software app, what's the best way to create deb installation packages?  At one point, i added a debian folder to the root source tree of my project, then install (using DESTDIR) to the debian folder; then used dpkg-deb to create a .deb installable package from it... I am sure its not the right way?  can you recommend a correct way please?
[19:30] <tpham3783>  cjwatson, i've been researching, i some recommended that I create another branch, say debian-package, and then merge with the master branch if i want to create a deb package.. not sure what is the ideal best solution w/o reverting to LP
[19:31] <dobey> debuild/dpkg-buildpackage is "the correct way" to build a debian package
[19:33] <tpham3783> dobey, thanks, i want to know the correct work flow from other people too, also, I would like not to depend on debuild/dpkg-buildpackage if possible
[19:36] <dobey> well, if you want to build debian packages, the correct way is to use the supported proper tools for building those packages. trying to do things manually with dpkg-deb will eventually result in problems
[19:39] <tpham3783> dobey, where would you store your packaging info (debian folder), in a upstream git/svn branch, then merge in with the master branch?  just want to know common practices?  thanks
[19:41] <dobey> tpham3783: well, i've set up daily builds of several things, and i typically stick the packaging in a separate bzr branch which i nest into the upstream code as debian/. for git, that could be a separate branch on the upstream repository, or it could be a separate repository or something.
[19:42] <tpham3783> dobey, that makes sense, thanks.....
[19:45] <tpham3783> dobey, do you always rely on LP to make builds for different flavors of U?  or u use some kind of jailroot on ur dev machine to build them manually?
[19:47] <dobey> i use recipes all the time
[19:48] <dobey> i only build things on my machine while developing and to test things out, and pretty much never install directly to / from source
[19:49] <tpham3783> "never install to /", how would you test though? b/c i test E20, and i had to install it to /, bc it would be complicated if not set to /, say /usr/local/e20_install; had to change all kind of env paths just to test E
[19:51] <dobey> depends on what i'm working on. i probably wouldn't test the entire enlightenment stack as if it were a single thing, because it's not. and anything i need to install to test, i'd build packages of first
[19:53] <cjwatson> tpham3783: I agree with dobey that the correct approach is to use dpkg-buildpackage.  I'm sorry but I'm not willing to help you work around that.
[19:53] <cjwatson> You can always use chroots if you're building on some other distribution.
[19:53] <tpham3783> cjwatson, thanks, i was just wanting to know of other ways...
[19:54] <cjwatson> Obviously it's *possible* to do it by hand (after all dpkg-buildpackage is just a script wrapping debian/rules etc.) but it's not something I'm prepared to help with.
[19:55] <cjwatson> Because IME advising people on that just results in them coming back to me with problems they wouldn't have had if they'd used a more standard route. :-)
[19:56] <dobey> it's completely open source and an open format, so it's totally possible to manually construct a .deb; it's just not worth the trouble to do it
[19:56] <cjwatson> Assuming that the app in question has its own existence independent of packaging, then it likely does make sense for the packaging to be in a separate branch of some kind, not embedded in the upstream tree.
[20:02] <tpham3783> Thanks guys, I will use dpkg-buildpackage from now on....
[20:42] <tpham3783> for a brand new project, how do i tell dpkg-buildpackage to auto install all dependencies listed in the control file, prior to building?
[21:05] <cjwatson> tpham3783: not dpkg-buildpackage's job - that's generally up to higher-level tools, IMO the best of which is sbuild (https://wiki.ubuntu.com/SimpleSbuild)
[21:54] <karstensrage> i tested my ppa and it seems to have worked
[21:54] <karstensrage> how big generally are chroots
[21:54] <teward> varies release to release
[21:54]  * teward pulls his sbuild schroots sizes
[21:55] <karstensrage> im going to test in natty and saucy but i cant put those on launchpad right?
[21:56] <wgrant> I'm going to pretend I didn't hear that.
[21:57] <teward> lol
[22:05] <teward> these are the filesizes for my chroots... though, I also have Debian chroots 'cause I use them...
[22:05] <teward> http://paste.ubuntu.com/14897387/
[22:07] <teward> and yes I have a Vivid chroot there - it's just not been deleted yet :)
[22:08] <dobey> but it's so new
[22:08] <teward> okay, that made me chuckle
[22:08] <teward> heh
[22:08] <teward> dobey: thanks for making my day a little better xD