=== jalcine is now known as Jacky [06:52] good morning [07:04] good morning dholbach [07:04] hey geser === fabo_ is now known as fabo [07:54] Morning. === almaisan-away is now known as al-maisan [12:37] http://developer.ubuntu.com/packaging/html/libraries.html#an-example lists the name of file as "debian/libnova-0.12-2.install" ... Do we need version numbers in *.install filenames? [12:37] Could not we simply use libnova.install instead? [12:38] you do not need numbers in install files [12:38] but you need the soname of the library in the binary package name of the library [12:38] and then you get the soname into the install file too :) [12:40] But when I do 'apt-cache search lib', most lib* packages don't have soname/version in their name (?) [12:43] actually "libnova-0.12-2" is the package name here [12:44] yes, I get that.... but why don't most lib* packages in ubuntu don't have soname/version for e.g. http://pastebin.com/ANLjqDfD [12:49] AmberJ_: Perl libraries are not ELF libraries, so they don't have a soname [12:50] Most "regular" libraries should have a soname in the package name [12:51] Right, I get it now. [12:51] I need to read more about libraries... === al-maisan is now known as almaisan-away [16:31] vibhav: re your zerofree merge: during a merge the new Debian entries are kept as is and not "merged" into the merge change log entry (you add a new changelog entry) [16:31] usually the output of MoM is a good starting point for a merge === JainAmber is now known as AmberJ_ [17:48] Why do both code blocks in http://i.imgur.com/2VqL1.png have different format? [17:48] Source of above linked image: http://developer.ubuntu.com/packaging/html/debian-dir-overview.html#additional-files [17:49] you mean leading / vs no leading /? [17:49] yes [17:50] who knows, but feel free to propose a merge tidying it up [17:50] the leading / makes no practical difference [17:51] The path is considered relative to debian/tmp/ ? [17:52] see dh_install's manpage [17:52] relative to debian/tmp or relative to . if it wasn't found there [17:54] right. Thanks! [17:55] It's the other way.... If not found in current dir, it fallbacks to debian/tmp .. [17:56] :) [17:56] Anyways, upstream's Makefile installs it in debian/tmp...So, I don't have much to worry about atm ;) === yofel_ is now known as yofel [19:39] What are *.substvars files created in debian/ ? [19:40] Temporary files used by debuild etc.? [19:40] I guess a packager is not expected to fiddle with them (it seems so having looked at their contents) [19:45] the substvars files contain variables which are substituted into control [19:45] like shlib:Depends [19:45] yes, I see that from it's contents [19:45] AmberJ_: Yeah, it's an auto-generated file. [19:45] ok (I won't mess up with it then). Thanks! [19:45] you can mess with them, but the need for that is rare (and should more likely be done over dpkg-gencontrol === cyphermox_ is now known as cyphermox [20:17] With over ~100 warnings, I have other stuff to take care of than mess with *.substvars files ;-) [20:18] Fixing 100 warnings are sufficient to keep me busy for quite some time :D [20:33] wow, test-building on amd64 didn't help much here: https://launchpad.net/ubuntu/+source/google-glog/0.3.2-1 [20:34] oh my [20:38] jbicha: bit of a problem there :) [20:44] the changelog: "Fix FTBFS on several architectures", I think we need a few more architectures :) [21:46] i386 is clearly not the dominant architecture any more [21:54] Suppose I have multi-binary config... Let's say foo.install and foo-doc.install. Can we use 'install' file as well (alongwith foo.install and foo-doc.install)? [22:00] AmberJ_: install will apply to the first binary package [22:01] so when you have more than one it's best to just name the package in each config file [22:01] * Laney was just pointed to an amusing ajmitch work item [22:01] https://blueprints.launchpad.net/ubuntu/+spec/other-q-backports-bof [22:02] * Laney giggles [22:02] Laney: yessir? [22:02] yup, he volunteered, out of nowhere [22:02] I remember now [22:02] s/nowhere/a creeping madness/ [22:02] the heady excitement of a UDS session leads one to make rash promises :P [22:03] I'll have to try & get that landed well before feature freeze then [22:03] the change itself is pretty trivial [22:03] there's still other structures that need to be in place though really [22:04] list them all somewhere please [22:04] * Laney wonders why Launchpad times out so much more recently [22:04] did a timeout change? [22:04] yes [22:04] the other stuff should be on that BP [22:04] bots and such [22:05] default timeout changed ~a week ago [22:05] sounds about right [22:06] https://lists.launchpad.net/launchpad-dev/msg09410.html [22:07] Laney: so how's that bot going? [22:07] i branched the code. [22:07] woohoo! [22:07] that's progress :) [22:08] i added some logging to the code!!!!! [22:08] more progress than I've had on the rcbugs rewrite with udd :) [22:08] i'll get debfx through NM then look at it some more :P [22:08] * Laney gets on that now [22:08] Laney: good luck with the core-dev application btw. I'm still hanging back waiting for more endorsers [22:09] tumbleweed: you need endorsers? [22:09] ajmitch: yeah, https://wiki.ubuntu.com/StefanoRivera/CoreDevApplication [22:09] i have to upload to main more now, which rapidly becomes irritating [22:09] indeed [22:09] when sponsoring is rewuired [22:09] q [22:09] ajmitch: Laney does too [22:09] but Laney has lots of photos to show how technical he is [22:10] heh [22:10] technical in all the right ways [22:10] he knows that pretty pictures are far more convinsing to the DMB than endorsements [22:10] convincing even [22:10] of course [22:10] distract them with kittens or something [22:11] * ajmitch probably needs to sponsor stuff to write anything nice that counts [22:12] * Laney will hassle you from now until July 2nd [22:12] yeah I haven't had many sponsors for main-stuff, which doesn't help so much [22:13] "so, why are mono and ghc both knackered on arm?" [22:13] /part [22:14] pretend you are a community member who doesn't have access to porterboxes [22:14] so will you approve each other's core dev membership, or recuse yourself both times? :) [22:14] actually, the arm one is down :P [22:14] certainly can't endorse each-other [22:18] ok thanks tumbleweed! [22:18] tumbleweed: how long are you in uk for? [22:23] Laney: til friday. I should have been proactive about getting out of town, but the weekends have all been pretty busy [22:24] ah, bad luck [22:25] guess seeing the queen was more exciting :P [22:25] pish [22:25] * tumbleweed had better rain at home [22:26] Suppose I have two packages: foo and bar. If a file in foo depends on another in bar, I'll need to add "Depends: bar" in foo.install [22:27] I guess the answer is yes, but I still thought of asking (just to be sure) [22:27] foo.install instructs dh_install. It has nothing to do with dependencies [22:29] oops, I meant: "If a file in foo depends on another in bar, I'll need to add "Depends: bar" in debian/control " ? [22:30] + for entry corresponding to foo package in debian/control [22:30] if you /need/ the bar available when foo is run, then yes Depends is what you want [22:31] yes that's what I meant to ask.. [22:31] I'll add appropriate Depends then.. [22:33] or Recommends if it'd fail gracefully without it and not everyone would need it [22:36] I already divided upstream into 14 packages (there might be a few more) so that independent components go into separate packages :D [22:37] I'll need to confirm with upstream devs to find which packages go into Recommends and which in Depends. [22:38] there's also Suggests :) [22:38] and Enhances! [22:42] And, the most important one: Pre-Depends :D [22:42] important since docs say "Use it very sparingly" ;) [22:42] err, you should try and avoid that one [22:43] has anyone written anything that uses Enhances, yet? [22:43] yes, I was j/k [22:47] Umm.. Suppose foo.deb has 2 binary executables: foo1 and foo2. [22:48] bar.deb has 1 .so library [22:48] If foo1 depends on bar.so ... but foo2 does NOT depends on bar.so, [22:49] Will we add a Depends:bar to foo package [22:49] ? [22:51] yes [22:51] unless it wolud print a helpful error when running foo2 and many people would never use foo2 [22:51] btw, these questions are far easier with real examples [22:53] I do have a real case in front of me. And, from what I have seen it won't print a helpful error message. So, I'll add Depends: line ... [22:53] Thanks! [22:53] dh_shlibdeps knows about shared libraries [22:54] if foo2 is dynamically linked to libbar, it'll add the dependency fo ryou [22:57] ok [22:58] also, if you are packaging shared libraries, beware, they're non-trivial (and there's a decent fairly old howto out there somewhere) [23:00] yes, http://developer.ubuntu.com/packaging/html/libraries.html (fotunately, it's linked from new UDD packaging page) :) [23:00] I meant http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [23:01] yes, this one is linked from the bottom of wiki page (but I was too lazy to read it). [23:01] but yes, looks like the packaging guide has a nice overview [23:01] Now that you mention it, I'll read the other tutorial as well. [23:07] "In the lib* package, only the runtime library, and the files necessary to use the runtime library should be included..." ... I guess this means that lin lib* packages, at the minimal we'll need to put library (*.so) and header files? [23:08] header files go in -dev [23:09] Err, that means MOAR packages! [23:09] yes [23:09] Ah, that was mentioned in the next paragraph :( [23:09] thanks to multi-arch, library packages tend to just contain .so.X.Y.Z shared libraries and .so.X symlinks [23:09] I should read the complete guide first. Thanks! [23:10] be aware that it's fairly old. It predates deb-symbols and multi-arch [23:17] "thanks to multiarch"? multiarch by and large hasn't changed anything in package contents [23:17] keeping separate -dev packages has been policy forever :) [23:21] it did force a few extra things to move out, but fair enough :)