[00:00] <kuldeep> i want to keep `libbox0.so.2 libbox0-2 #MINVER#` like libpipeline1.
[00:01] <kuldeep> do i have to keep like `libbox0.so.2.0.0 libbox0-2 #MINVER#` and update everytime the SO VERSION?
[00:03] <nacc> kuldeep: does your binary package create a libbox0.so.2?
[00:04] <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:05] <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:06] <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:07] <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:08] <kuldeep> [checking my trick]
[00:08] <cjwatson> libbox0.so belongs exclusively in libbox0-dev
[00:09] <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:10] <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:11] <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:12] <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:13] <nacc> i think dh_makeshlibs even mentions that :)
[00:22] <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:23] <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:24] <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:28] <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:32] <nacc> kuldeep: keep in mind that libpipeline.so  lives ina  different binary pacakge
[00:41] <kuldeep> nacc, it is mandatory to provide /usr/lib64/libpipeline.so -> libpipeline.so.1.4.1 ?
=== tsimonq2alt is now known as tsimonq2
[00:49] <nacc> kuldeep: well, in the -dev package, probably? otherwise how would you compile against it?
[00:49] <nacc> *link* against it, rather
[01:05] <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:06] <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:07] <kuldeep> cjwatson, atleast it isnt doing the that by default.
[01:08] <kuldeep> finding libraries that uses cmake is hard. trying ...
[01:08] <kuldeep> im doing on https://anonscm.debian.org/cgit/users/
[01:10] <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:11] <tsimonq2> cjwatson: Speaking of that, is there a technical reason why we don't have an httpredir.debian.org for Ubuntu?
[01:12] <cjwatson> not afaik
[01:13] <tsimonq2> Then who do I talk to about asking that Canonical set one up? :)
[01:15] <cjwatson> RT, I'd presume ...
[01:16] <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:17] <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:24] <kuldeep> https://anonscm.debian.org/cgit/users/abe/nmu/plplot.git/tree/debian  PLplot dont have any symbol file.  (uses cmake)
[01:38] <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:39] <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:40] <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:42] <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:44] <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:45] <tsimonq2> (I'm not good but I'm better than I was 3 months ago...)
[01:45] <kuldeep> :)
[01:47] <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:49] <kuldeep> thanks you to tsimonq2 and wgrant (and anyone i missed) too.
[01:51] <nacc> kuldeep: np, gl!
[02:03] <kuldeep> :)
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[10:57] <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/
[15:35] <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:36] <dobey> #ubuntu-devel is where you want to ask about ubuntu development
[15:38] <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:47] <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:51] <cjwatson> yeah, that comment is from somebody uninformed but trying to be helpful, rather than somebody who knows about how stable updates happen
=== maclin1 is now known as maclin
=== JanC_ is now known as Guest35600
=== JanC__ is now known as JanC
=== pbek_ is now known as pbek