=== jalcine is now known as Jacky | ||
dholbach | good morning | 06:52 |
---|---|---|
geser | good morning dholbach | 07:04 |
dholbach | hey geser | 07:04 |
=== fabo_ is now known as fabo | ||
iulian | Morning. | 07:54 |
=== almaisan-away is now known as al-maisan | ||
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:37 |
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:38 |
AmberJ_ | But when I do 'apt-cache search lib', most lib* packages don't have soname/version in their name (?) | 12:40 |
mitya57 | actually "libnova-0.12-2" is the package name here | 12:43 |
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:44 |
mitya57 | AmberJ_: Perl libraries are not ELF libraries, so they don't have a soname | 12:49 |
mitya57 | Most "regular" libraries should have a soname in the package name | 12:50 |
AmberJ_ | Right, I get it now. | 12:51 |
AmberJ_ | I need to read more about libraries... | 12:51 |
=== al-maisan is now known as almaisan-away | ||
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 | 16:31 |
=== JainAmber is now known as AmberJ_ | ||
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:48 |
tumbleweed | you mean leading / vs no leading /? | 17:49 |
AmberJ_ | yes | 17:49 |
tumbleweed | who knows, but feel free to propose a merge tidying it up | 17:50 |
tumbleweed | the leading / makes no practical difference | 17:50 |
AmberJ_ | The path is considered relative to debian/tmp/ ? | 17:51 |
tumbleweed | see dh_install's manpage | 17:52 |
tumbleweed | relative to debian/tmp or relative to . if it wasn't found there | 17:52 |
AmberJ_ | right. Thanks! | 17:54 |
AmberJ_ | It's the other way.... If not found in current dir, it fallbacks to debian/tmp .. | 17:55 |
tumbleweed | :) | 17:56 |
AmberJ_ | Anyways, upstream's Makefile installs it in debian/tmp...So, I don't have much to worry about atm ;) | 17:56 |
=== yofel_ is now known as yofel | ||
AmberJ_ | What are *.substvars files created in debian/ ? | 19:39 |
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:40 |
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 | 19:45 |
=== cyphermox_ is now known as cyphermox | ||
AmberJ_ | With over ~100 warnings, I have other stuff to take care of than mess with *.substvars files ;-) | 20:17 |
AmberJ_ | Fixing 100 warnings are sufficient to keep me busy for quite some time :D | 20:18 |
jbicha | wow, test-building on amd64 didn't help much here: https://launchpad.net/ubuntu/+source/google-glog/0.3.2-1 | 20:33 |
Laney | oh my | 20:34 |
ajmitch | jbicha: bit of a problem there :) | 20:38 |
jbicha | the changelog: "Fix FTBFS on several architectures", I think we need a few more architectures :) | 20:44 |
tumbleweed | i386 is clearly not the dominant architecture any more | 21:46 |
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)? | 21:54 |
tumbleweed | AmberJ_: install will apply to the first binary package | 22:00 |
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:01 |
* 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:02 |
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:03 |
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:04 |
ajmitch | default timeout changed ~a week ago | 22:05 |
Laney | sounds about right | 22:05 |
ajmitch | https://lists.launchpad.net/launchpad-dev/msg09410.html | 22:06 |
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:07 |
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:08 |
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:09 |
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:10 |
* ajmitch probably needs to sponsor stuff to write anything nice that counts | 22:11 | |
* 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:12 |
Laney | "so, why are mono and ghc both knackered on arm?" | 22:13 |
Laney | /part | 22:13 |
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:14 |
AmberJ_ | ok thanks tumbleweed! | 22:18 |
Laney | tumbleweed: how long are you in uk for? | 22:18 |
tumbleweed | Laney: til friday. I should have been proactive about getting out of town, but the weekends have all been pretty busy | 22:23 |
Laney | ah, bad luck | 22:24 |
Laney | guess seeing the queen was more exciting :P | 22:25 |
tumbleweed | pish | 22:25 |
* tumbleweed had better rain at home | 22:25 | |
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:26 |
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:27 |
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:29 |
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:30 |
AmberJ_ | yes that's what I meant to ask.. | 22:31 |
AmberJ_ | I'll add appropriate Depends then.. | 22:31 |
tumbleweed | or Recommends if it'd fail gracefully without it and not everyone would need it | 22:33 |
AmberJ_ | I already divided upstream into 14 packages (there might be a few more) so that independent components go into separate packages :D | 22:36 |
AmberJ_ | I'll need to confirm with upstream devs to find which packages go into Recommends and which in Depends. | 22:37 |
tumbleweed | there's also Suggests :) | 22:38 |
Laney | and Enhances! | 22:38 |
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:42 |
tumbleweed | has anyone written anything that uses Enhances, yet? | 22:43 |
AmberJ_ | yes, I was j/k | 22:43 |
AmberJ_ | Umm.. Suppose foo.deb has 2 binary executables: foo1 and foo2. | 22:47 |
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:48 |
AmberJ_ | Will we add a Depends:bar to foo package | 22:49 |
AmberJ_ | ? | 22:49 |
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:51 |
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:53 |
tumbleweed | if foo2 is dynamically linked to libbar, it'll add the dependency fo ryou | 22:54 |
AmberJ_ | ok | 22:57 |
tumbleweed | also, if you are packaging shared libraries, beware, they're non-trivial (and there's a decent fairly old howto out there somewhere) | 22:58 |
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:00 |
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:01 |
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:07 |
tumbleweed | header files go in -dev | 23:08 |
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:09 |
tumbleweed | be aware that it's fairly old. It predates deb-symbols and multi-arch | 23:10 |
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:17 |
tumbleweed | it did force a few extra things to move out, but fair enough :) | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!