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