| kuldeep | i want to keep `libbox0.so.2 libbox0-2 #MINVER#` like libpipeline1. | 00:00 |
|---|---|---|
| kuldeep | do i have to keep like `libbox0.so.2.0.0 libbox0-2 #MINVER#` and update everytime the SO VERSION? | 00:01 |
| nacc | kuldeep: does your binary package create a libbox0.so.2? | 00:03 |
| nacc | kuldeep: becuase libpipeline1 contains both: | 00:04 |
| nacc | /usr/lib/x86_64-linux-gnu/libpipeline.so.1 | 00:04 |
| nacc | /usr/lib/x86_64-linux-gnu/libpipeline.so.1.4.1 | 00:04 |
| nacc | which one a symlink to the other | 00:04 |
| kuldeep | afaik: file libbox0.so.2.0.0 and symbolic link libbox0.so -> libbox0.so.2.0.0 | 00:05 |
| nacc | libbox0.so is wrong, isn't it? | 00:05 |
| nacc | an unversioned lib? | 00:05 |
| kuldeep | nacc, https://paste.debian.net/903842/ | 00:06 |
| kuldeep | libbox0.so is a symbolic link to libbox0.so.2.0.0. is that a problem? | 00:06 |
| nacc | kuldeep: right so your symbols file and the contents of the package disagree | 00:06 |
| nacc | kuldeep: you told the symbols file to look at a library called libbox0.so.2 | 00:06 |
| nacc | but you don't ship any such library | 00:06 |
| nacc | so the build system recognizes that and switches to the library it did find | 00:07 |
| nacc | afaict that's what the log you got is saying | 00:07 |
| kuldeep | nacc, will it be happy (with the symbolic link?) "`libbox0.so libbox0-2 #MINVER#`" ? | 00:07 |
| kuldeep | [checking my trick] | 00:08 |
| cjwatson | libbox0.so belongs exclusively in libbox0-dev | 00:08 |
| cjwatson | libbox0-2 should ship libbox0.so.2 as a symlink to libbox0.so.2.0.0 | 00:09 |
| nacc | kuldeep: I don't know, maybe? but you have to refer to an actually shipped library either way; that seems like it should work, but it seems odd that you're not shipping libbox0.so.2 | 00:09 |
| cjwatson | you must ship the thing that's named in your SONAME or stuff won't work | 00:09 |
| nacc | kuldeep: so then, no, you should't do your trick, as it's not in the same package | 00:09 |
| kuldeep | ok | 00:09 |
| cjwatson | it is not correct to use libbox0.so in .symbols - that field is supposed to be the SONAME | 00:10 |
| kuldeep | cmake isnt generating the libbox0.so.2 and libbox0.2.0 have to look into that. | 00:10 |
| cjwatson | right, fix that. | 00:10 |
| nacc | cjwatson: right, duh, thanks for clearing that up :) | 00:11 |
| cjwatson | and re symbols containing 0.3.0+65, you're meant to edit that. | 00:11 |
| cjwatson | it'll only automatically fill in the minimum version if the symbols file didn't already have a version for that symbol. | 00:12 |
| nacc | kuldeep: right i think cjwatson's advice earlier was to use makeshlibs to give you a base symbols file that you then make correct in practice | 00:12 |
| cjwatson | it just uses the current version because that's the conservative choice and it can't know any better. | 00:12 |
| nacc | i think dh_makeshlibs even mentions that :) | 00:13 |
| tsimonq2 | So do Bad Things happen when I accidentally close a terminal when it's dputting to a PPA and it's on the source tarball? | 00:22 |
| kuldeep | cmake only allow me to set "SET_TARGET_PROPERTIES(box0 PROPERTIES SOVERSION <so-value-here>") but it only allow one value. | 00:23 |
| kuldeep | multiple call to SET_TARGET_PROPERTIES result in final only being generated. | 00:23 |
| kuldeep | so, either i can generated libbox0.so.2 or libbox0.so.2.0 or libbox0.2.0.0 + a symbolic link libbox0.so to the actual shared library | 00:24 |
| kuldeep | /usr/lib64/libpipeline.so -> libpipeline.so.1.4.1 | /usr/lib64/libpipeline.so.1 -> libpipeline.so.1.4.1 | /usr/lib64/libpipeline.so.1.4.1 | 00:28 |
| nacc | kuldeep: keep in mind that libpipeline.so lives ina different binary pacakge | 00:32 |
| kuldeep | nacc, it is mandatory to provide /usr/lib64/libpipeline.so -> libpipeline.so.1.4.1 ? | 00:41 |
| === tsimonq2alt is now known as tsimonq2 | ||
| nacc | kuldeep: well, in the -dev package, probably? otherwise how would you compile against it? | 00:49 |
| nacc | *link* against it, rather | 00:49 |
| cjwatson | tsimonq2: no; either it finished anyway or the whole thing is discarded | 01:05 |
| cjwatson | kuldeep: /usr/lib64/ isn't a thing in Ubuntu | 01:05 |
| tsimonq2 | cjwatson: Thanks. | 01:05 |
| cjwatson | kuldeep: but yes, a libfoo.so symlink is required in the -dev package as nacc says, since that's what ld looks for | 01:05 |
| kuldeep | cjwatson, ok | 01:06 |
| cjwatson | I can't believe that cmake is actually as useless as you're suggesting though; I'd suggest you find a competent existing library package that's built using cmake | 01:06 |
| kuldeep | cjwatson, atleast it isnt doing the that by default. | 01:07 |
| kuldeep | finding libraries that uses cmake is hard. trying ... | 01:08 |
| kuldeep | im doing on https://anonscm.debian.org/cgit/users/ | 01:08 |
| cjwatson | grep-dctrl -FBuild-Depends,Build-Depends-Indep cmake -a -Pr ^lib -nsPackage /var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_*_Sources | sort -u | 01:10 |
| cjwatson | (well, maybe not gb.archive in your case) | 01:10 |
| cjwatson | should find you a decent list to poke at | 01:10 |
| tsimonq2 | cjwatson: Speaking of that, is there a technical reason why we don't have an httpredir.debian.org for Ubuntu? | 01:11 |
| cjwatson | not afaik | 01:12 |
| tsimonq2 | Then who do I talk to about asking that Canonical set one up? :) | 01:13 |
| cjwatson | RT, I'd presume ... | 01:15 |
| tsimonq2 | cjwatson: Oh, so do you think it would be worth bringing up for discussion or should I Just File The Goshdarn RT? :) | 01:16 |
| cjwatson | I have absolutely no idea | 01:16 |
| tsimonq2 | Ok, fair enough \o/ | 01:16 |
| cjwatson | it's nearly end of year and I'm just trying to finish off my project so I can stop :P | 01:16 |
| tsimonq2 | cjwatson: Fair enough, cheers, good luck, happy holidays. :) | 01:17 |
| * tsimonq2 takes note to not poke Colin until January so he can finish his project | 01:17 | |
| kuldeep | https://anonscm.debian.org/cgit/users/abe/nmu/plplot.git/tree/debian PLplot dont have any symbol file. (uses cmake) | 01:24 |
| kuldeep | cjwatson, https://cmake.org/cmake/help/v3.0/command/install.html it says "lib<name>.so -> lib<name>.so.1" documented as im seeing | 01:38 |
| cjwatson | I think you'd be best off not addressing me about cmake issues | 01:38 |
| cjwatson | I don't personally like it and don't use it, so can't help you further there | 01:38 |
| kuldeep | cjwatson, i pinged you because of "I can't believe that cmake is actually as useless as you're suggesting though; I'd suggest you find a competent existing library package that's built using cmake" | 01:39 |
| kuldeep | so, atleast i found in the documentation :) | 01:39 |
| cjwatson | but if you mean what the symlink target should be, then it doesn't matter whether it's to lib<name>.so.1 or to lib<name>.so.1.X.Y | 01:39 |
| cjwatson | it just has to exist at all | 01:39 |
| cjwatson | anyway, please stop pinging me about cmake-related things, thanks :) | 01:40 |
| * tsimonq2 coughs at #debian-mentors on OFTC and #ubuntu-motu on freenode as well... | 01:40 | |
| cjwatson | yep, much better venues for all this | 01:40 |
| cjwatson | basically none of this is specific to launchpad.net at this point | 01:40 |
| kuldeep | cjwatson, ok. (maybe i should stop giving you reason to curse cmake :p ) | 01:40 |
| tsimonq2 | Oh jeez, looks like someone's doing a mass rebuild... :P | 01:42 |
| kuldeep | cjwatson, nacc and dobey for helping me out throughout the way of learning, building my first debian package. i have been a constant source of ping's for you :D | 01:42 |
| kuldeep | cjwatson, nacc and dobey THANK YOU for helping me out | 01:44 |
| tsimonq2 | kuldeep: Although I haven't helped much, don't give up here! Go get help in those channels I listed. I'm not an expert but you just have to keep at it and you'll become good. ;) | 01:44 |
| tsimonq2 | (I'm not good but I'm better than I was 3 months ago...) | 01:45 |
| kuldeep | :) | 01:45 |
| kuldeep | for the past two days, i have been slicing cjwatson libpipeline package and result in a ping when share any link. im have saturated cjwatson. sorry :) | 01:47 |
| kuldeep | thanks you to tsimonq2 and wgrant (and anyone i missed) too. | 01:49 |
| nacc | kuldeep: np, gl! | 01:51 |
| kuldeep | :) | 02:03 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| kuldeep | Finally, i got my deb file without error. :D | 10:57 |
| kuldeep | (my fault not cmake because i didnt set the SOVERSION and VERSION properties correctly) | 10:57 |
| kuldeep | so, finally i got the libbox0_0.3.0.tar.xz libbox0-2_0.3.0_amd64.deb libbox0-dev_0.3.0_amd64.deb /var/cache/pbuilder/build/ | 10:57 |
| jabowery | In July a maxima package bug was fixed that still hasn't shown up in the xenial updates. No one is assigned. What is a reasonable course of action? | 15:35 |
| dobey | #ubuntu-devel is where you want to ask about ubuntu development | 15:36 |
| jabowery | The reason I asked here is this response to the launchpad bug tracking: "A thing the maintainer perhaps could do would be to create a launchpad mirror of the sourceforge repo maxima's code is kept in - and then to initiate a nightly build ppa for maxima." https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941/comments/8 | 15:38 |
| ubot5` | Ubuntu bug 1602941 in maxima (Ubuntu Xenial) "Draw cannot be loaded in 16.04 (Repackage needed since gcl has changed?)" [Undecided,Confirmed] | 15:38 |
| dobey | yes, but that doesn't get it into xenial updates | 15:47 |
| dobey | if someone wants to create a daily build PPA, they can. but it doesn't have anything to do with fixing bugs in ubuntu itself | 15:47 |
| cjwatson | yeah, that comment is from somebody uninformed but trying to be helpful, rather than somebody who knows about how stable updates happen | 15:51 |
| === maclin1 is now known as maclin | ||
| === JanC_ is now known as Guest35600 | ||
| === JanC__ is now known as JanC | ||
| === pbek_ is now known as pbek | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!