[00:00] dobey, yeah, notice that too..... thanks and good bye [04:00] :( wgrant im having a hard time getting my head around this [04:01] my library depends on libssl and libxml2 and it seems like it shoud be compiled against the distribution its being put on [04:01] but i dont get really how this is supposed to work with changelog [04:02] 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] but nothing changes in changelog except the version and distribution [04:04] im kind of curious why launchpad deleted the previous package maybe cause it failed to build? [04:04] or is always only going to keep the last version if the version changes? [04:14] http://askubuntu.com/questions/20835/how-do-i-copy-packages-within-a-ppa-from-one-release-to-another-nonsensical-s [04:14] this seems to reflect that, all you can do i just change the version [04:15] in changelog [04:15] 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] karstensrage: You need to upload a different source package for each set of binaries that you want to be built. [04:52] Launchpad only keeps the most recent version of each package in each series. [04:59] wgrant, but nothing is changing for (what's 11.10), 12,04, 13.10, 14,04, etc [05:00] the docs said something like 1.0-1ubuntu~trusty1 [05:00] so *ALL* that changes is that damn string in changelog [05:00] karstensrage: That's the only change in the source, yes. [05:01] But different series will build different binaries, and different binaries must have different versions. [05:01] 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] does 12.04 (precise) work for 13.10 ? [05:02] Ubuntu 13.10 has been unsupported for nearly two years. [05:03] The only supported series today are 12.04, 14.04, 15.04, 15.10 [05:03] people still have them [05:03] Their machines are probably part of a botnet by now :) [05:03] Launchpad does not build for EOL Ubuntu series. [05:03] what im asking is not that [05:04] do you have to have specific version for everything ubuntu puts out? [05:04] It depends on your package's dependencies. [05:04] heres the way i think about it [05:04] 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] i put up the source, its the source [05:05] build it for whatever machine asks for it [05:06] is there someone thats whole life is just chasing ubuntu versions and resubmitting tomcat for every single version? [05:06] or any package really? [05:06] There is one Ubuntu release every six months; it is not particularly onerous. [05:07] and what about older versions? [05:07] What do you mean/ [05:07] 11.10, 12.04, 13.10 [05:07] 10.04 [05:07] 12.04 is still supported, the others are not. [05:08] they are still out there [05:08] Anybody running them is reckless, as they have numerous unpatched security vulnerabilities. [05:08] We cannot support them. [05:09] i want them to be able to install my stuff regardless of what they have [05:10] just like back then i could install apt-get install tomcat6 [05:10] today i just apt-get install tomcat7 [05:10] and later apt-get install tomcat8 [05:10] for me its all three apt-get install mylib [05:10] Launchpad does not build for obsolete Ubuntu series. [05:11] If you want to support people with vulnerable machines, you'll need to distribute the packages from somewhere else. [05:11] where does 15.10 get its stuff? [05:11] from 14.04 packages? [05:11] Which stuff? [05:11] its tomcat8 [05:11] Some binary packages are copied, others are rebuilt. [05:12] https://launchpad.net/ubuntu/+source/tomcat8 shows the version in each supported series. [05:12] quick question.. i am logged in however the 'report a bug' link takes me to a wiki.. [05:12] 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] karstensrage: 14.04 doesn't have tomcat8, and 15.04, 15.10 and xenial all have different versions. [05:13] wgrant; thanks [05:13] wgrant; i thought i was nuts. [05:17] xenial is 16.04? [05:17] xenial will be 16.04, yes. [05:18] ok hmm [05:18] maybe i should move all this to 14.04 and just resubmit every 6 months like you said? [05:18] Move all which? [05:18] all my work so far as been on a 12.04 vm that i use for a lot of development work [05:19] so everything is built and tested on 12.04 [05:19] 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] 14.04 is the current LTS release, and 16.04 will be the next. [05:19] i think you underestimate how many old systems are out there [05:19] Oh, I'm well aware, and running 12.04 today is fine. [05:20] 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] 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] i thought botnets were all windows machines [05:21] Nope [05:21] Regrettably not, though there are an awful lot of those. [05:21] I guess you know you've really made it as an OS when there are botnets of your machines! === rbasak_ is now known as rbasak [09:22] good morning (CET) [09:22] I am unable to log into wiki.ubuntu.com using my Ubuntu ONE account. === axino` is now known as axino [10:30] sunweaver: We can't help you here; we maintain neither of those systems. Try #canonical-sysadmin [10:39] cjwatson: thanks. === FourDollars_ is now known as FourDollars === rvba` is now known as rvba === kickinz1|afk is now known as kickinz1 [12:21] the target must be the path within the targer repository [12:21] -> shouldn't that be like preset to :master ? and/or whatever development focus (aka remote HEAD) are? [12:22] we need a better picker for that in general [12:22] definitely a known problem [12:22] 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] *commit [12:23] tsimonq2: Just add further commits on top of your branch with your fixes. [12:23] cjwatson: ahh okay thanks :) [15:58] 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] kamal: select all the packages, copy existing binaries to the same PPA [15:59] wait an eon [15:59] though, if you're sending 200 builds to the builders, I think the LP admins will be annoyed [15:59] s/will be/may be/ [15:59] teward, I tried exactly that, but LP doesn't buy it ... [15:59] "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] kamal: FWIW vivid went EOL [16:00] 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] teward, i.e. same result for supported releases as well [16:02] i can't replicate, but I also can't see what you're selecting [16:02] My GUESS is you have "Rebuild" ticked... [16:02] not "copy existing binaries", but don't quote me on that [16:03] 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] teward, yes I did tick "Rebuild" (since I wanted it to build something)... "Copy existing binaries" makes no sense here, I think. [16:04] kamal: actually, 'copy existing binaries' makes more sense [16:04] it'll sense armhf is misisng, and build [16:04] it's how i kicked the ZNC and NGINX PPAs I run into rebuilding for missing releases [16:04] and how i'm getting ppc64el building right now for my nginx ppas :P [16:04] kamal: missing binaries then get built, I believe [16:05] sounds counter intuitive, but it apparently works [16:05] 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] 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] (just saying) [16:05] teward, they know where to find me ;-) === cjwatson_ is now known as cjwatson [16:25] kamal: Copy the packages in question over the top of themselves, including binaries [16:26] kamal: i.e. "Copy packages" in the PPA in question, select the relevant packages, "This PPA", "The same series", "Copy existing binaries" [16:26] cjwatson, teward sorted me out ... the magic solution was that I needed to select "Copy existing binaries". [16:26] cjwatson: wouldn't 200 packages going for armhf builds take up a majority of the builders though? [16:26] cjwatson, yup :-) [16:26] and clog the queue? [16:26] teward: *shrug* [16:26] teward: will clear quick enough [16:27] teward: no different than 200 different people requesting builds at the same time, of the same priority. [16:27] teward: (also may not be quite that many sources) [16:28] teward: anyway, we can deal with abuse if it happens, but the build farm is there to be used [16:28] indeed [16:28] * teward just sent all his nginx packages through the ppc64el builds :P [16:30] wgrant, ! [16:33] huh [16:35] 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] i was just wanting to adopt the way wireshark included the packaging info for debian in their source tree, [16:36] to e20... but may not be a good choice [16:37] furthermore, packaging info can only support **most likely** the latest flavors .... it wont be able to support old flavors like precise etc.... [16:38] that's just too much combination, and overhead for the developer to maintain [16:38] packaging can support multiple series easily enough [16:38] the main problem is that binaries built on different series, are different, and so should have different versions [16:39] this will especially be a problem with the enlightenment stack, because there are many libraries and such [16:39] 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] json is available on precise [16:42] i think it was lib json,, here: https://code.launchpad.net/~tpham3783/+recipe/edkit-daily [16:42] libjson-c-dev [16:47] dobey, is the file at debian/.install neccessary? what if I do not have it? is it like an install mask? === chrisccoulson_ is now known as chrisccoulson [16:50] 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] debian/*.install is described in "man dh_install" [16:52] in general the various debhelper manual pages are excellent and you should consult them [16:53] 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] Recipes don't yet support builds of private code. [16:53] (It's hopefully coming in the next few months, although probably only for git) === marcoceppi_ is now known as marcoceppi === kiko` is now known as kiko === caraka_ is now known as caraka [19:29] 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] 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] debuild/dpkg-buildpackage is "the correct way" to build a debian package [19:33] 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] 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] 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] 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] dobey, that makes sense, thanks..... [19:45] 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] i use recipes all the time [19:48] 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] "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] 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] 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] You can always use chroots if you're building on some other distribution. [19:53] cjwatson, thanks, i was just wanting to know of other ways... [19:54] 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] 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] 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] 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] Thanks guys, I will use dpkg-buildpackage from now on.... [20:42] 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] 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] i tested my ppa and it seems to have worked [21:54] how big generally are chroots [21:54] varies release to release [21:54] * teward pulls his sbuild schroots sizes [21:55] im going to test in natty and saucy but i cant put those on launchpad right? [21:56] I'm going to pretend I didn't hear that. [21:57] lol [22:05] these are the filesizes for my chroots... though, I also have Debian chroots 'cause I use them... [22:05] http://paste.ubuntu.com/14897387/ [22:07] and yes I have a Vivid chroot there - it's just not been deleted yet :) [22:08] but it's so new [22:08] okay, that made me chuckle [22:08] heh [22:08] dobey: thanks for making my day a little better xD