[07:03] good morning [07:16] good morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [10:44] these OpenERP-prerequisite backports are impressive === al-maisan is now known as almaisan-away === yofel_ is now known as yofel === almaisan-away is now known as al-maisan [11:45] Hi. I'm interested in getting the Ninja build system (https://github.com/martine/ninja) packaged. There's a request for it (bug #988478) and I have it packaged in my PPA (pending build): https://launchpad.net/~jpakkane/+archive/ppa [11:45] Launchpad bug 988478 in Ubuntu "[needs-packaging] ninja (small build system)" [Wishlist,Confirmed] https://launchpad.net/bugs/988478 [12:47] Satoris, why don't you submit an ITP to Debian and get it in to Debian instead? [12:51] because there are already two packages with ninja* names in debian [12:51] Because I am not a Debian developer (I have not used it in years even) and because the package is special in certain ways. I'm not sure it even builds on anything other than x86/AMD64 and possibly ARM. [12:51] why, oh why, do people chose such names [12:51] its like call all your kernels kernel [12:52] Also, they don't do releases. The recommended way to go is to just grab trunk. [12:53] I called all my sons "Sam," what's the problem there? (when I call, they all come running) [12:54] It would be inconvenient if "aptitude install package" installed every package in the repos. [12:54] Though it would make dependency management easier. [12:55] I guess dak would not be able to handle this, multiple sources with the same name [12:55] (does ubuntu use dak at all?) [12:55] no [12:55] only the first few ubuntu release used dak [12:59] Zhenech: as Ubuntu syncs from Debian, we have those ninja* packages too [12:59] geser, ehm right, ofc, but makes my argument nil :) [13:39] The project I'm packaging is distributed under AGPL license. Do I need to write whole license (~700 lines) in debian/copyright file? [13:41] Or, will a small AGPL notice (similar to http://pastebin.com/efD3zerf) will suffice? [13:51] Plus, do we need to explicitly state a (maintainer) clause for debian/copyright for "File: debian/*" ? [13:52] dont need, can [13:53] Right...so, copyright for debian/* is optional (If not specified, copyright for upstream applies). [13:54] you should add yourself as a copyright holder though probably [13:54] and for the first question, if it's in /usr/share/common-licenses/ then you don't need to replicate it [13:54] otherwise you do [13:54] got it. Thanks :) [14:14] Laney, Are files in /usr/share/common-licenses/ installed with system? [14:14] Or, can I add a line in debian/install to put a copy of my license in /usr/share/common-licenses/ ? [14:15] they come from base-files and you can't add your license in there, no [14:15] ok === Quintasan_ is now known as Quintasan === al-maisan is now known as almaisan-away [15:44] http://developer.ubuntu.com/packaging/html/debian-dir-overview.html#the-control-file says an entry: "Bzr-Vcs" ... But when I try to debuild, I get "dpkg-source: warning: unknown information field 'Bzr-Vcs' in input data in general section of control info file" [15:45] I guess the wiki page needs to be fixed [15:45] Or, is it supposed to be "Vcs-Bzr" (like "Vcs-Git") ? === Adri2000 is now known as Guest67276 === Adri2000_ is now known as Guest43626 === Guest43626 is now known as Adri2000 [17:00] it should be Vcs-Bzr [17:02] who can edit that site? [17:03] ok its bzr managed [17:04] Thanks, I'll make it Vcs-Bzr then... [17:05] And, Vcs-Web is supposed to be a link to web interface to the repo...right? [17:05] yes [17:05] *Vcs-Browser [18:06] Upstream code has a cmake target called "tests". The default debian/rules (generated by bzr dh-make) has "%" target which means "all targets" in upstream make config. [18:06] Is there a way to exclude just one target (in upstream's cmake)? [18:09] A link to appropriate documentation will suffice (since I'm starting with reading debian/rules documentation)... [18:10] override_dh_auto_test: [18:10] \t#noop [18:11] ok, an empty target [18:12] yeah [18:12] Does this works for any CUSTOM_TARGET defined? like... [18:12] override_dh_auto_CUSTOM-TARGET: [18:12] whatever custom target is [18:13] (where CUSTOM-TARGET is any target defined in Makefile) [18:13] ok [18:13] it works with every dh_* command [18:13] ah right.. [18:13] (see man dh) [18:13] Thanks :) [18:13] and thats what you should care about [18:13] as not every target is called in upstreams makefile [18:13] but only the "needed" in terms of dh thinks (make, make install, make tests usually) [18:14] yes [18:15] If I change debian/* , I can use 'debuild -nc' so that build resumes from where it stop due to error...right? [18:15] *shrug* no idea :) [18:15] but most probably yes, if -nc means no clean [18:16] I read it somewhere on Ubuntu/Debian docs....don't remember the exact option (-nc i.e.) [18:18] yes, -nc means no clean (http://developer.ubuntu.com/packaging/html/packaging-new-software.html#next-steps) [18:18] Thanks :) [19:47] What is the difference between a "Transitional" and a "Meta" package? [19:47] transitional is temporary to get users from a to b [19:48] Does "temporary" means that a "Transitional" package will be removed from future version? [19:48] meta is either to get user to install a-best-implemenation or a set of packages that are commonly known as a [19:48] may/should yes [19:48] ok thanks :) [19:56] hi, are there any plans for updating clutter in precise/Q [19:56] ? [19:56] there is annoying segfault, which was fixed in recent point release [19:59] Suppose I do creating multi-binary/deb... Do I need to explicitly specify files for "ALL" packages in "EACH" $package.install ? [20:01] I did a install with 2 binaries/debs in debian/control (pretty much default config setup by dh-make i.e. 2 packages: xyx and xyz-doc ). Without any contents in xyz.install and xyz-doc.install, it created almost empty packages [20:02] yes all [20:02] but you can use wildcards [20:02] like usr/bin/* in foo.install [20:02] In fact, iirc, dh-make didn't made any xyz.install ... It only created xyz-doc.install [20:02] and usr/share/* in foo-common.install [20:02] (not sure if usr/share is a good example) [20:02] yes, wild cards... [20:06] I asked because dh-make didn't created foo.install (it only created foo-doc.install). So, I thought maybe it was like: put files specified in foo-doc.install in foo-doc.deb .... and put everything else in foo.deb [20:07] nope [20:09] Ok, I was wrong! Thanks (again) :) === ripps_ is now known as ripps [22:40] <\sh> moins [22:47] hi \sh [22:47] <\sh> hey micahg [22:48] <\sh> micahg: hows life? [22:48] \sh: good [22:48] \sh: and you? [22:49] <\sh> micahg: right now? very good...just thousands of miles away from home in sunny california [22:56] hi \sh [22:56] <\sh> hey ajmitch [23:17] hello there I am making a package and for some reason I am getting error on dh_usrlocal sayong that there is a imagaes in my images folder so it can not rm that ? [23:17] what up with that ? [23:19] ERROR : http://paste.ubuntu.com/1025921/ [23:20] why can I not package in /usr/local ? [23:20] because that's for sysadmins [23:20] lol l [23:20] packaged stuff belongs in /usr/share [23:21] tumbleweed, work around is to make rules file into script ? [23:21] so change the upstream then ? [23:21] bobweaver: the way to fix it is to make the build system respect PREFIX [23:22] nad how to so that ? [23:22] do * not so [23:22] for next time now I am hacking upstream to be in usr/share [23:23] depends on the package [23:25] thanks tumbleweed [23:25] package is a perl package [23:26] here is upstream http://blog.bodhizazen.net/linux/zen-koans/ [23:26] I am going to hack at it and make it save all stuff to usr/share/* [23:27] what does your debian/rules look like? [23:28] cause I don't see any build system [23:29] just a simple rules [23:30] that is just upstream [23:30] I have not pushed to bzr yet [23:30] will do now [23:34] p:~josephjamesmills/+junk/zen-koans