[00:05] <kuldeep> i earlier looked at http://packaging.ubuntu.com/html/packaging-new-software.html and it help.
[00:07] <nacc> yeah, although i'd ignore the bzr bits :)
[00:07] <kuldeep> Im looking at https://anonscm.debian.org/cgit/users/cjwatson/libpipeline.git/tree/debian/control  and could not undertand "Package: libpipeline1" , why is it required?  i have two things, "libbox0-dev" to install headers, "libbox0" to install header, why the third one/
[00:07] <nacc> kuldeep: one is a source package name (this source package)
[00:07] <nacc> that's Source: ....
[00:07] <kuldeep> in my case, that would become "libbox01" isnt it.
[00:07] <nacc> the other two are binary packages
[00:08] <nacc> which are Package: ...
[00:08] <nacc> kuldeep: so you probably need at least one more binary package in your control file for the library itself
[00:08] <nacc> kuldeep: probably called libbox0
[00:09] <nacc> kuldeep: well, i woudl say, if i had to geuss, your source package is actually 'libbox' not 'libbox0' as it is now
[00:09] <kuldeep> instead of "Package: libpipeline1"   can i just keep "Package: libpipeline"
[00:09] <nacc> iiuc, that indicates so versioning
[00:09] <kuldeep> nacc, "box0" the name, brand whatever you can think of it
[00:10] <kuldeep> and libbox0 is now at v0.3.0
[00:10] <nacc> kuldeep: ok, you can name it however you want, and source package names can be the same as binary package names
[00:10] <nacc> kuldeep: *so* versioning
[00:10] <nacc> shared object
[00:10] <nacc> https://autotools.io/libtool/version.html may help
[00:11] <kuldeep> nacc, yes, the shared library follow the INTERFACE standard. (version age like stuff)
[00:16] <kuldeep> update the paste: https://gist.github.com/kuldeepdhaka/79f3b0b59e3d504abe73000909b958a4
[00:17] <kuldeep> nacc, cjwatson    (heavily borrowed from cjwatson libpipeline)
[00:18] <kuldeep> also, directly used libpipeline1.install and libpipeline-dev.install
[00:20] <kuldeep> update: Added all file i have
[00:24] <kuldeep> possibly just need to figure out what need to be in "rules" file
[00:24] <kuldeep> :)
[00:27] <nacc> kuldeep: do you currently use a Makefile in your upstream?
[00:27] <cjwatson> What is the SONAME of your library?
[00:28] <cjwatson> The runtime library package should probably in fact be libbox0-1 or something like that, reflecting the SONAME.
[00:28] <nacc> cjwatson: good point, i didn't realize earlier that 'box0' was part of the product name
[00:28] <cjwatson> And you should have a symbols file declaring its exported interfaces.
[00:29] <kuldeep> libbox0.so.2.0.0  <--- master code, latest
[00:29] <cjwatson> Then libbox0-2
[00:31] <cjwatson> The symbols is mildly tedious to craft the first time, but if your rules file has an override_dh_makeshlibs target something like libpipeline's (with -c2 or higher, preferably -c4) then the first build should fail with output that gives you a rough idea of the initial contents.  In future the symbols file makes it much easier for the system to automatically generate appropriate library ...
[00:31] <cjwatson> ... dependencies, and warn you when you've broken ABI without realising it.
[00:31] <cjwatson> The symbols -> The symbols file
[00:44] <kuldeep> nacc, uses CMake which generate the Makefile.
[00:44] <kuldeep> will resume work on waking up.
[00:45] <kuldeep> thank you, GN.
=== chihchun_afk is now known as chihchun
=== JanC_ is now known as JanC
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== pleia2_ is now known as pleia2
[14:55] <kuldeep> im using "deb-version {debupstream:master}+{revno:master}" for recipe.  and my changelog contain "libbox0 (0.3.0-1) unstable; urgency=medium". so i guess this will generate: 0.3+4264 any input on any problem with it?
[14:55] <kuldeep> s/0.3+4264/0.3.0+4264/
[14:58] <kuldeep> is my usage of debupstream:master and revno:master correct?  (use the master branch to get these variables)?
=== chihchun is now known as chihchun_afk
[15:45] <kuldeep> Im unable to git push to my repo https://paste.debian.net/hidden/91ec39e1/     https://code.launchpad.net/libbox0 [project] and https://launchpad.net/~kuldeepdhaka [account]
[15:46] <kuldeep> do i need to do something special to push a new branch? (my first interaction with git server)
[15:48] <kuldeep> i cloned, made a new branch, commit the changes and now while push the branch it having problem.  i used `git clone git://git.launchpad.net/libbox0`
[16:08] <kuldeep> is it due to because i have imported the git code from somewhere else,i cannot push any changes to it?
[16:49] <sigmavirus> kuldeep: if I look at https://code.launchpad.net/libbox0 I see a recently updated debian branch
[16:50] <sigmavirus> oh kuldeep I think I see the problem
[16:50] <sigmavirus> You cloned using git:// which is a read-only URI
[16:50] <jpd> I am trying to establish a session from a build server to launchpad upload a release and I am in a text browser
[16:50] <sigmavirus> I think you might need to use git+ssh://git.launchpad.net/libbox0
[16:50] <kuldeep> sigmavirus, i uploaded to the gitlab repo, then i told lp to pull the changes.
[16:51] <jpd>  I can't complete the login sequence because of this error : Launchpad requires a REFERER header to perform this action.
[16:51] <jpd> the browser is lynx
[16:52] <kuldeep> sigmavirus, i tried but it had problem. minor change: i had to use  "git+ssh://kuldeepdhaka@git.launchpad.net/libbox0" (to pull) and then for push same problem.
[16:53] <sigmavirus> kuldeep: odd. I don't use launchpad as a git repository, so I'm not sure why you're running into your particular issue
[17:05] <cjwatson> kuldeep: you can't push to repositories that are imported from somewhere else
[17:06] <cjwatson> kuldeep: either push to a different repository in the same project on Launchpad, or (simpler if you can) just push the branch to gitlab
[17:06] <cjwatson> kuldeep: though sigmavirus is also correct that you can't push over git://
[17:08] <cjwatson> kuldeep: if you've pushed to gitlab already, then you don't need to tell LP to pull the changes, it'll do so automatically.  If you're impatient you can go to https://code.launchpad.net/~kuldeepdhaka/libbox0/+git/libbox0 and press "Import Now"
[17:41] <kuldeep> cjwatson, that what i did.
[17:42] <nacc> kuldeep: afaict, the idea behind the git-to-git imports is that you only push to gitlab, launchpad will notice and since you have a recipe, will build (presuming you've marked it as automatic)
[17:44] <cjwatson> that's right.  we don't let you push to imported repositories because how would we resolve the case of changes on both sides?
[17:44] <kuldeep> pretty reasonable behaviour, i also concluded that.
[17:45] <nacc> cjwatson: makes total sense to me :)
[17:45] <kuldeep> cjwatson, hum
[17:46] <kuldeep> though this import behaviour could have been per branch, but more work and very specific usecase.
[17:47] <kuldeep> readonly clone could have been a good description. something like that tell people what will happen if the code is "imported".
[17:48] <cjwatson> feel free to file a bug
[17:48] <cjwatson> I'm very unlikely to remember an IRC conversation from now until after the new year :)
[17:48] <sigmavirus> heh
[17:49] <nacc> kuldeep: it is documented at: https://help.launchpad.net/Code/Git
[17:49] <nacc> "You won't be able to push directly to the imported repository"
[17:50] <cjwatson> yeah, but it's reasonable to suggest that it should be more self-documenting
[17:50] <nacc> never hurts :)
[17:51] <nacc> cjwatson: based upon context, i assume i should defer bringing up how we want (if we do) to tie the importer repositories to launchpad -- specifically for questions like: 1) where should uploaders be able to upload to (we want to keep the importer trees read-only so that they only reflect the publishing history, but they can add an 'upload' parent which is indicative of what the uploader says they pushed)
[17:51] <nacc> that is, defer to the new year :)
[17:53] <cjwatson> I'm not sure I agree with that decision, but I also don't want to get into it now :)
[17:55] <nacc> cjwatson: fair enough :)
[17:55] <nacc> cjwatson: but i generally want to have a launchpad discussion on it, so we can figure all that out
[18:02] <kuldeep> https://bugs.launchpad.net/launchpad/+bug/1651826
[18:02] <ubot5`> Ubuntu bug 1651826 in Launchpad itself "Mention on the git code import page that "You won't be able to push directly to the imported repository"" [Undecided,New]
[18:03] <kuldeep> nacc, :)
[18:04] <nacc> kuldeep: sorry, did you mean: https://help.launchpad.net/Code/Git ?
[18:04] <nacc> kuldeep: because it is there already
[18:05] <kuldeep> nacc, its on doc page i know. but such a important peice of information should probably be on the ui directly. (imo)
[18:06] <nacc> kuldeep: oh ok, i'd clarify in the bug where you mean then
[18:06] <nacc> kuldeep: as i don't know what by reading it :)
[18:07] <cjwatson> it's always fine to give an example URL
[18:07] <cjwatson> so please do that
[18:07] <kuldeep> (or if descriptive error can be printed when someone try to push some code to server on imported repo - it would be better. because "permission denied" was very vauge for me)
[18:08] <nacc> i assume the error was a generic git protocol return code (and permission denied was presumably accurate)
[18:08] <kuldeep> it could have been because im trying to push to some one else repo.
[18:08] <cjwatson> that should be a separate bug
[18:08] <cjwatson> again, with specifics
[18:10] <kuldeep> in my working-dir/   libbox0_0.3.0+62+62.tar.xz has been generated "by deb-version {debupstream}+{revno}"  where my changelog has "libbox0 (0.3.0-1) unstable; urgency=medium"
[18:12] <kuldeep> (build locally by `git-build-recipe --allow-fallback-to-native libbox0.recipe working-dir`)
[18:12] <kuldeep> could not understand "62+62". shouldnt that have been "62" only?
[18:15] <kuldeep> libbox0.recipe:   "# git-build-recipe format 0.4 deb-version {debupstream}+{revno}    \n      lp:libbox0 debian"
[18:18] <nacc> it seems like it should have been 0.3.0-62 (depending on the revision number being 62)
[18:19] <nacc> kuldeep: "For recipe versions 0.4 and newer, you must specify the name of the branch (e.g. {debupstream-base:packaging})."
[18:19] <kuldeep> `git rev-list --count HEAD` return 62  (master)
[18:20] <nacc> kuldeep: so i think you want {debupstream:<branch name>}
[18:21] <kuldeep> gitbuildrecipe.deb_version.NotFullyExpanded: deb-version not fully expanded: {debupstream:master}+62.  Valid substitutions in recipe format 0.4 are: ['{time}', '{date}', '{git-commit}', '{latest-tag}', '{revdate}', '{revtime}', '{debversion}', '{debupstream-base}', '{debupstream}']
[18:22] <kuldeep> ^^ deb-version {debupstream:master}+{revno}
[18:22] <kuldeep> gitbuildrecipe.deb_version.NotFullyExpanded: deb-version not fully expanded: {debupstream:master}+{revno:master}.  Valid substitutions in recipe format 0.4 are: ..... <snip>
[18:22] <kuldeep> ^^ deb-version {debupstream:master}+{revno:master}
[18:22] <nacc> interesting, maybe it only applies to bzr?
[18:23] <nacc> hrm, do you have a master branch? it seems liek the : syntax should work regardless?
[18:23] <kuldeep> nacc, i have two branch: master, debian.   i uploaded debian some time back.
[18:24] <nacc> kuldeep: which one has the debian/changelog in it?
[18:24] <kuldeep> nacc, debian
[18:24] <nacc> kuldeep: then that's the branch you should refer to
[18:24] <nacc> "debversion, debupstream and debupstream-base require debian/changelog to exist in the given branch. "
[18:25] <nacc> not sure why it put 62 in, could be a bug, but it seems like you need to be very specific with the branches you use in your recipe
[18:25] <kuldeep> nacc, then which branch code will be compiled? debian or master?
[18:26] <kuldeep> currently BRANCH(debian) = BRANCH(master) + COMMIT(containing-debian-dir)
[18:26] <nacc> kuldeep: i think the code to compile depends entirely on your recipe
[18:27] <kuldeep> i think,i can solve the problem by making the COMMIT(containing-debian-dir) in master later on.
[18:27] <nacc> kuldeep: i htink you're looking for the nest-part or merge bits of the recipes
[18:27] <kuldeep> gitbuildrecipe.deb_version.NotFullyExpanded: deb-version not fully expanded: {debupstream:debian}+{revno:debian}.  Valid substitutions in recipe format 0.4 are: ['{time} ......
[18:28] <mquigley> I'm having trouble logging into launchpad with a new account. Is this the place to ask for help, or is there a better location elsewhere? Thanks!
[18:29] <kuldeep> mquigley, please go on.
[18:29] <kuldeep> nacc, you can try my recipe:   "# git-build-recipe format 0.4 deb-version {debupstream}+{revno}   \n   lp:libbox0 debian" if you like
[18:30] <nacc> kuldeep: i'm out of my depth now, maybe cjwatson or another LP admin has insight
[18:30] <kuldeep> oops "# git-build-recipe format 0.4 deb-version {debupstream:debian}+{revno:debian}   \n   lp:libbox0 debian"
[18:30] <nacc> kuldeep: will try locally
[18:30] <mquigley> Thank you. I created a new account with Ubuntu One, but when I try to sign into launchpad.net it returns "Oops! Sorry, something just went wrong with Launchpad...(Error ID: OOPS-59334964f22deff950a2d2632cabf9fb)". It's quite possible I'm doing something wrong, but I've tried in a few browsers and a few different machines yesterday and today trying to eliminate causes on my end.
[18:30] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-59334964f22deff950a2d2632cabf9fb
[18:31] <dobey> kuldeep: you probably don't just want to build from the debian branch. you want to pull the master branch and then merge the debian branch
[18:31] <kuldeep> dobey, BRANCH(debian) = BRANCH(master) + COMMIT(containing-debian-dir)
[18:31] <dobey> kuldeep: until you push new stuff onto master, yes
[18:32] <kuldeep> dobey, "until you push new stuff onto master, yes" what do you mean by that?
[18:32] <kuldeep> please elaborate.
[18:32] <nacc> kuldeep: hrm, i get a different error from `git-build-recipe` -- says it can't find an upstream tag
[18:33] <dobey> kuldeep: i mean, when you push changes to master, the debian branch doesn't automatically get them
[18:33] <nacc> kuldeep: http://paste.ubuntu.com/23665127/
[18:34] <kuldeep> dobey, the debian branch is on launchpad, i press'd "Import Now" to force import.
[18:34] <nacc> kuldeep: what dobey is referring to is a general structure of your repository
[18:34] <nacc> kuldeep: as you push commits to master, your debian branch will be 'behind' master
[18:34] <nacc> kuldeep: so you are forcing yourself to rebase and push debian (forcibly as it won't be a fast-forward) each time
[18:35] <nacc> kuldeep: you can see the merge examples in the recipes documentation: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[18:36] <dobey> hmm, is there any documentation on git recipes?
[18:36] <nacc> dobey: it's in there too, afaict
[18:36] <nacc> although it's not 100% clear if everything about bzr recipes applies to git recipes :)
[18:36] <kuldeep> look like, while i check'd out the lp master branch, lp didnt fetch the latest master from gitlab, so in between there is a commit missing in debian branch.
[18:36] <kuldeep> lemme fix that first
[18:37] <dobey> nacc: yeah i see some "if you use git, do y"
[18:37] <nacc> dobey: yep
[18:39] <dobey> hmm, launchpad says "no recipes using this repository"
[18:40] <dobey> anyway
[18:40] <dobey> i think http://pastebin.ubuntu.com/23665168/ is actually what you want
[18:45] <kuldeep> ok, i pushed debian branch after rebasing against master.(the missing commit is now there) force pushed to gitlab server and imported the code to lp libbox0 page.
[18:47] <kuldeep> dobey, im using your recipe and got "Exception: Invalid deb-version: {debupstream:debian}+63: Invalid version string '{debupstream:debian}+63'" executed `git-build-recipe libbox0.recipe working-dir`
[18:48] <dobey> kuldeep: remove the :debian then (i didn't modify that from yours)
[18:49] <kuldeep> dobey, after removing the :debian,  i got "git-build-recipe: error: Unable to find the upstream source.  Import it as tag upstream/0.3.0+62 or build with --allow-fallback-to-native."
[18:50] <dobey> kuldeep: yeah, your version string is native, so build with --allow-fallback-to-native
[18:50] <dobey> (lp does build recipes with that option)
[18:50] <kuldeep> now it got "libbox0_0.3.0+62.tar.xz"  when i passed --allow-fallback-to-native
[18:50] <kuldeep> *now i got
[18:51]  * kuldeep wonder the use of --allow-fallback-to-native
[18:54] <kuldeep> now "# git-build-recipe format 0.4 deb-version {debupstream}+{revno}   \n   lp:libbox0 debian" works.   so i guess the problem was due to the missing commit that was left out due to sync between server and my failure to notice it.
[18:58] <dobey> that was undoubtedly not the problem
[18:58] <kuldeep> i have the package. libbox0_0.3.0+62.tar.xz :)  [containing the source]
[18:59] <kuldeep> getting pbuilder :D
[19:02] <kuldeep> dobey, "that was undoubtedly not the problem" then? what was the problem?
[19:03] <kuldeep> dobey, <dobey> nacc: yeah i see some "if you use git, do y"    i wont mind understanding the joke. (if it is) :D
[19:03] <dobey> there is no joke
[19:04] <dobey> i don't know what the problem was exactly. probably the fact that you created a tarball from the recipe i gave you resulted in a success when you tried to then run your recipe, as now there was an "upstream source"
[19:05] <kuldeep> oh ok. atleast its gone now.
[19:08] <dobey> but the recipe i pastebinned is the one you want
[19:08] <dobey> at least, if you want launchpad to automatically build packages from your master branch
[19:10] <kuldeep> dobey, probably later, i will move the debian/ files to master branch.
[19:12] <dobey> not a requirement
[19:12] <dobey> but do whatever you want i guess
[19:15] <kuldeep> dobey, my reason of moving is: because i can easily forget to make changes to the changelog. also, until someone take the packaging work from me, i have to do the work.  but i do see that number of dir are growing in my source root.
[19:16] <kuldeep> if its at one place, there is a heigher chance of remembering.
[19:16] <kuldeep> dobey, if you were me, will you have kept that file?
[19:16]  * kuldeep `pbuiler create` finished
[19:17] <dobey> you only really need to update debian/changelog for recipes if you want to bump the main upstream version
[19:17] <dobey> but sure
[19:30] <kuldeep> my library uses cmake for build. https://git.launchpad.net/libbox0/tree/debian/rules?h=debian    problem is idk how to write a rule file that build code that uses cmake
[19:31] <kuldeep> i see https://anonscm.debian.org/cgit/users/rfrancoise/libpcap.git/tree (uses cmake) but could not understand how to reuse the rule file.
[19:33] <kuldeep> i just copied "dh_auto_configure -Skde -- -DBUILD_DEMO=OFF" assuming it may work for me.  (removed the -Dvariable and placed mine)  from here https://anonscm.debian.org/cgit/users/modax/amarok.git/tree/debian/rules
[19:44] <dobey> unless you need to pass specific options to cmake or something, the simplest rules file with just %: rule that runs "dh $@" will "just work"
[19:45] <dobey> i doubt you need the -Skde
[19:47] <kuldeep> hum, in think too.
[19:47] <kuldeep> https://anonscm.debian.org/cgit/users/rfrancoise/libpcap.git/tree/debian/rules#n26   im going to add this target too. lets see what will happen. probably related to symbol file as earlier mentioned.
[19:48] <nacc> kuldeep: again you don't *need* to override any targets unless you know you need to
[19:49] <kuldeep> i think, my code is a library, and `dh_makeshlibs -- -c4` is require for library. symbol checking/generation.... something like that
[19:49] <kuldeep> *my reason, my code
[19:49] <kuldeep> nacc, isnt it?
[19:51] <nacc> again, they are choosing to override the -c value (default is 1)
[19:52] <dobey> you don't need to override anything by default
[19:52] <nacc> right
[19:52] <kuldeep> <cjwatson> The symbols is mildly tedious to craft the first time, but if your rules file has an override_dh_makeshlibs target something like libpipeline's (with -c2 or higher, preferably -c4) then the first build should fail with output that gives you a rough idea of the initial contents.  In future the symbols file makes it much easier for the system to automatically generate appropriate library ...
[19:53] <dobey> i would just leave the symbols file out of your package for now
[19:54] <kuldeep> dobey, for simplicity (mine) or my package is 0.x (which are considered in very heavy development) or something else?
[19:54] <dobey> i doubt you're making any guarantee of abi stability yet, and you are packaging in a PPA, not trying to get it into the debian or ubuntu archives yet
[19:55] <kuldeep> just PPA atm.  (i wont mind it get into debian or ubuntu :)
[19:56] <kuldeep> you are right, i cannot garantee abi atm. (fyi, i just broke abi compatibility with prev release :)
[19:56] <kuldeep> so, as dobey recommend - no symbol file for now.
[19:57] <dobey> and you're probably not bumping the soname whenever you break abi either
[19:57] <dobey> so yeah, simplest to just avoid the symbols file for now
[19:58] <kuldeep> im bumping current=2, age=0, revision=0     last afair was current=1 and age=0, revision=0
[19:59] <kuldeep> dobey, https://git.launchpad.net/libbox0/tree/libbox0/CMakeLists.txt#n53
[20:01] <dobey> ok
[20:01] <kuldeep> i added 1 to CURRENT.     (though i keep forgetting that what is the format of current,age,revision - everytime i have to lookup on internet)
[20:03] <kuldeep> the library is in heavy development, so i would avoid any abi promises now. will just ignore symbol files for simplicity and till it dont make into actual debian or ubuntu.
[20:04] <kuldeep> dobey, make sense?
[20:10] <dobey> ok
[20:24] <kuldeep> i just got an idea, why not just provide just {rev}+{git-commit}   i dont have to maintain anything at all. and these files can be external to the master.
[20:24] <kuldeep> (no symbol file will not be provided)
[20:26] <kuldeep> im adding "{rev}+" to tell package manager that the next package is newer than the last rev.  (since {rev} is incremented as commit are added). or is it unnecessary?
[20:27] <dobey> you still have to maintain something
[20:28] <kuldeep> dobey, but not in every release.
[20:28] <dobey> and yes, you can append the git-commit or the revno launchpad assigns to the commit if you want
[20:28] <dobey> kuldeep: well, if you bump the SONAME in every release, yes, you have to rename the .install file and update the control file
=== elijah_ is now known as elijah
[20:29] <dobey> speak of which, you should probably have the install file to use libbox0*.so.2* instead of just *.so.*
[20:29] <kuldeep> dobey, it contain "usr/lib/*/libbox0*.so.*"   so, it does the work automatically?
[20:29] <dobey> so it will fail to build if you bump the soname
[20:29] <dobey> kuldeep: right, but then the package name doesn't match the soname
[20:29] <dobey> which is wrong
[20:31] <kuldeep> i changed the package name  "libbox0-2" to "libbox0".  in future, when we get a proper maintainer - they can do the whole thing. (i still dont know alot of the debian standards)
[20:31] <kuldeep> dobey, "which is wrong" wrong in the sense that for future release it could cause problem?
[20:32] <kuldeep> please share your experience, i dont know anything about debian packaging.
[20:32] <dobey> yes, and that it doesn't comply with debian packaging standards
[20:34] <cjwatson> The reason for this is that it causes unnecessary upgrade problems.
[20:34] <kuldeep> dobey, i was un-aware of that. https://anonscm.debian.org/cgit/users/cjwatson/libpipeline.git/tree/debian/libpipeline1.install  it contain "usr/lib/*/libpipeline*.so.*"
[20:35] <cjwatson> But I disagree with dobey regarding what the install file should say; I don't think that's a necessary change.
[20:35] <cjwatson> (When I say "it causes unnecessary upgrade problems", I'm referring to the binary package name.  It should change any time the SONAME changes.)
[20:35] <dobey> yeah, i didn't say that the contents are wrong. i was just suggesting that having the soname inside the install file as well, makes it easier to know when you end up with a problem
[20:35] <cjwatson> I think that's busywork :)
[20:36] <dobey> because then if you change the library soname, and then forget to change the install file and package name, it will fail to build and tell you why
[20:36] <dobey> versus building anyway and giving you a broken upgrade :)
[20:36] <cjwatson> I prefer using a symbols file to tell me that.
[20:36] <cjwatson> That's what dh_makeshlibs -- -c4 does
[20:37]  * kuldeep is having hard time following cjwatson and dobey cross-communication. :)
[20:37] <cjwatson> But I agree that if you aren't bothering with a symbols file then maybe you need some other kind of guard
[20:39] <kuldeep> if i today keep "libbox0" as the binary package name and later get a full fledge maintainer, she/he can start rolling "libbox0-X" (where X is extracted from interface,age,rev). will user have problem upgrading from "libbox0" to "libbox0-X"?
[20:39] <cjwatson> Possibly, depending on how competent they are.
[20:40] <cjwatson> It's probably unavoidable for there to be some kind of upgrade problem there, unless it happens to coincide with a SONAME change.
[20:40] <cjwatson> So you really are storing up trouble for yourself.
[20:41] <cjwatson> (And it should not be extracted from interface,age,rev directly, but rather from the SONAME.  Forget about the libtool stuff for this purpose, although it doesn't hurt to use it internally.)
[20:42] <kuldeep> cjwatson, "It's probably unavoidable for there to be some kind of upgrade problem there, unless it happens to coincide with a SONAME change." this sentence is still undigestable for me. can you make it a bit easier to digest? :)
[20:43] <cjwatson> Yes, the user may well have a problem upgrading from libbox0 to libbox0-X.  Which is why it's a mistake for you to rename to libbox0.
[20:44] <cjwatson> If done carefully, it's possible, but it will involve temporarily deconfiguring any installed packages that depend on libbox0*, and it's easy to get wrong.
[20:45] <kuldeep> thats a good insight of the working.
[20:47] <kuldeep> cjwatson, i think i got your thoughts.   libbox0 and libbox0-X will be installed for sometime in the transition. (or else, package manager will throw error that another package file is being overwritten) right?
[20:48] <kuldeep> if they have same SO version.  if concidently, libbox0-X got a different SO version, then things will go fine smoothly. right?
[20:49] <cjwatson> If they ship overlapping files (as they will, if they have the same SONAME), then it is not possible to install them at the same time; there'll have to be a Conflicts, which makes it much more work for apt to resolve the upgrade.
[20:49] <cjwatson> I don't understand why you're trying so very hard to ignore the best-practice advice we've given you.
[20:51] <kuldeep> cjwatson, im trying to feed my curiosity/understanding of what would happen/process.
[20:51] <cjwatson> A very large fraction of the packaging guidelines is there because things go wrong if you do something else; it's basically an encoded version of "here's how not to repeat the mistakes of the past".
[20:52] <cjwatson> So it's best to follow them pretty carefully until you understand things well enough to vary from them.
[20:52] <kuldeep> hahahhaha nicely said. yes.
[20:52] <OverCoder> Hello
[20:52] <OverCoder> I have been biulding a package for an open-source project for quite a while
[20:53] <OverCoder> The problem is that I built my package and uploaded it with the wrong upstream tarball, and obviously build failed at Launchpad's servers
[20:53] <OverCoder> now I built with the correct upstream tarball but launchpad is refusing the new tarball, because it has different contents under the same name
[20:53] <OverCoder> what do I do?
[20:53] <cjwatson> You'll have to upload the correct tarball under a slightly different name.  It's conventional to append e.g. +ds in this kind of case.
[20:54] <OverCoder> well, debuild fails if I rename the upstream tarball
[20:54] <cjwatson> So foo_1.0.0.orig.tar.xz -> foo_1.0.0+ds1.orig.tar.xz (and bump your changelog version from 1.0.0-1 to 1.0.0+ds1-1, etc.)
[20:54] <cjwatson> it will only fail if you haven't changed other things to suit
[20:54] <OverCoder> o
[20:54] <OverCoder> let me try
[20:55] <cjwatson> if you do it with the above scheme then you should be able to drop the +ds suffix at the next upstream release.
[20:56] <OverCoder> great.
[20:57] <OverCoder> I think this is gonna work, uploading
[21:00] <OverCoder> that worked D:
[21:00] <OverCoder> cjwatson: http://askubuntu.com/questions/862778/how-to-overwrite-a-previously-uploaded-malformed-upstream-tarball-in-launchpads You answer it or I do?
[21:00] <OverCoder> (It's my question)
[21:01] <cjwatson> I might as well.
[21:01] <OverCoder> okay :P
[21:02] <cjwatson> done
[21:09] <kuldeep> cjwatson, ok, im going to do libbox0-2. and i have to maintain proper versions.
[21:10] <kuldeep> then its just a matter of preference to provide a symbol file or not, will decide on it later.
[21:11] <cjwatson> Right, while a symbols file is best practice it's not necessary for correctness.
[21:13] <kyrofa> I'm getting timeouts whenever I try to change bug statuses
[21:13] <kyrofa> I can browse everything fine, though
[21:13] <cjwatson> kyrofa: Almost certainly the usual everything-stops-for-ten-minutes-while-PostgreSQL-changes-its-underwear thing.
[21:13] <kyrofa> Hahaha
[21:14] <kyrofa> cjwatson, alright, thanks for the heads up, I'll give it a breather
[21:14] <cjwatson> We're hoping that an upgrade in the new year will sort it out or at least give us something more to go on.
[21:14] <cjwatson> (It's some kind of maintenance that makes a trigger unable to create temporary tables)
[21:20] <kuldeep> cjwatson, just to confirm: in you package, libpipeline1.symbols "pipecmd_fchdir@Base 1.4.0"   1.4.0 is the package release version.  ie that symbol was first introduced in libpipeline1_1.4.0####.deb right?
[21:21] <kuldeep> (making sure that i dont mix up SO version and semiver)
[21:23] <kuldeep> looking at changelog, it always has "upstream release" that at version.
[21:23] <dobey> yes, the version after each symbol is the package version it was introduced in
[21:34] <kuldeep> (building source using pbuilder) atleast compiled code.
[21:35] <cjwatson> Right, it turns into a >= dependency.
[21:35] <cjwatson> And in libpipeline I've never introduced symbols in anything other than a new upstream release.
[21:35] <kuldeep> https://paste.debian.net/903807/   build shared library and reached till make install. but then failed. idk why
[21:36] <kuldeep> (idk why it is installing at wrong path)
[21:36] <kuldeep> here is the my debian/  https://git.launchpad.net/libbox0/commit/?h=debian
[21:36] <cjwatson> That looks like you're missing .install files, or maybe missing some entries in them.
[21:36] <cjwatson> Doesn't look like it's installing to the wrong path.
[21:37] <kuldeep> i have libbox0-2.install and libbox0-dev.install
[21:38] <cjwatson> Oh, no, I see, missing multiarch directory.  One moment.
[21:40] <cjwatson> I think you're probably hardcoding too many directories in your libbox0/CMakeLists.txt.  I don't speak cmake very well.
[21:41] <cjwatson> But you're hardcoding the library destination to "lib" and the pkg-config destination to "lib/pkgconfig", which aren't correct for modern Debian/Ubuntu library packages - they're supposed to install to the multiarch library path, e.g. /usr/lib/x86_64-linux-gnu.  That's passed in by the package build machinery and it usually works automatically if it's not overridden by the upstream build ...
[21:41] <cjwatson> ... system, which I think it must be here.
[21:42] <cjwatson> Also you need to remove usr/share/man/man3 from debian/libbox0-dev.install.
[21:42] <kuldeep> ok
[21:42] <dobey> need to -DCMAKE_INSTALL_LIBDIR="lib/${DEB_GNU_ARCH_TRIPLET}" or whatever the variable is
[21:43] <cjwatson> Not that one.  But isn't some equivalent of that done automatically?
[21:43] <cjwatson> https://wiki.debian.org/Multiarch/Implementation#CMake
[21:43] <dobey> oh, well the CMakeLists.txt is broken further down too
[21:43] <cjwatson> Ah, right, only very modern debhelper.
[21:44] <cjwatson> Anyway that says that upstreams should use GNUInstallDirs.
[21:44] <dobey> also that too
[21:44] <dobey> https://git.launchpad.net/libbox0/tree/libbox0/CMakeLists.txt?h=debian#n135
[21:44] <dobey> vs
[21:44] <dobey> https://git.launchpad.net/libbox0/tree/libbox0/CMakeLists.txt?h=debian#n176
[21:44] <dobey> though
[21:45] <cjwatson> And then you probably do indeed need to pass -DCMAKE_INSTALL_LIBDIR="lib/$(DEB_HOST_MULTIARCH)" in a dh_auto_configure override
[21:46] <dobey> but nice that newer debhelper does it
[21:47]  * dobey wonders what probability of it being SRU to xenial is
[21:47] <cjwatson> about nil
[21:47] <cjwatson> I suspect
[21:47] <cjwatson> Anyway if you don't want to deal with this right now you could disable multiarch: drop the */ segments from the usr/lib/whatever lines in .install, and remove both occurrences of Multi-Arch: same from debian/control
[21:48] <cjwatson> Your users won't be able to do fancy things like coinstallation of the same library for different architectures, it may get in the way of cross-building etc., but you also may not care right now.
[21:50] <kuldeep> if both of you can tell me in a simpler language that i need to do in the CMake files and in debian/, i will be happy to fix anything that is less than recommended-level.
[21:50] <cjwatson> disable multiarch: drop the */ segments from the usr/lib/whatever lines in .install, and remove both occurrences of Multi-Arch: same from debian/control
[21:50] <cjwatson> that's as simple as I can make it
[21:50] <kuldeep> i do understand a bit that multi arch installation would be problem because of hard coding in cmake fikle
[21:51] <cjwatson> I can't give you simple language for what needs to be fixed in your cmake config to do the job properly
[21:51] <cjwatson> but you can do the job improperly here by disabling multiarch and it won't be terrible
[21:51] <dobey> use GNUInstallDirs and don't use hard-coded path names like "lib" and "bin", basically
[21:52] <dobey> to make multi-arch workable; otherwise just drop the multi-arch support as cjwatson said
[21:54] <kuldeep> ok, in my cmake code, i add "include(GNUInstallDirs)" and use the exported variable by the module instead of hardcoded strings. right?
[21:55] <kuldeep> looking at the provided examples
[21:56] <kuldeep> that seem simple.
[22:11] <kuldeep> question: https://anonscm.debian.org/cgit/debian-med/libdivsufsort.git/tree/debian/patches/0001-Fix-upstream-cmake-files-to-support-multi-arch.patch?id=78397139d346fb15d035f63f6a0ad8f239675afa     has "set(CMAKE_INSTALL_INCLUDEDIR "include/${CMAKE_LIBRARY_ARCHITECTURE}")"  but https://anonscm.debian.org/cgit/collab-maint/libsdsl.git/tree/debian/patches/0001-Patch-cmake-files.patch?id=8f0e9ba2bee3b1b5f3e90d7b0fd4325f5ccf44bf dont
[22:13] <kuldeep> https://cmake.org/cmake/help/v3.3/module/GNUInstallDirs.html  seems like CMAKE_INSTALL_INCLUDEDIR is set by the package.
[22:49] <kuldeep> ---
[22:50] <kuldeep> im switching to  "git-build-recipe format 0.4 deb-version {debupstream}" because the build result in "+ b0_aout_bitsize_speed_get@Base 0.3.0+65" not "- b0_aout_bitsize_speed_get@Base 0.3.0" (current symbols)
[22:51] <kuldeep> its adding "+65" at the end of line in symbol.
[22:51] <kuldeep> dobey, cjwatson ok?
[22:52] <kuldeep> (im revoing "+{revno}" because of which "+65" is being generated)
[22:52] <kuldeep> *removing
[23:18] <kuldeep> https://anonscm.debian.org/cgit/users/cjwatson/libpipeline.git/tree/debian/source/format uses "3.0 (quilt)" so i used that too, but pbuilder or git-recipe-build  change that to "3.0 (native)" for me.
[23:18] <kuldeep> why?
[23:18] <kuldeep> cjwatson, any tip ^^ ?
[23:22] <kuldeep> dobey  ^^^ :)
[23:23] <nacc> kuldeep: do you understand the difference between the two?
[23:24] <nacc> kuldeep: https://wiki.debian.org/Projects/DebSrc3.0 and `man dpkg-source` may help
[23:24] <kuldeep> nacc, idk the difference.
[23:24] <kuldeep> i shamelessly copied the file :)
[23:26] <kuldeep> nacc, i can choose any. any significat difference?
[23:27] <nacc> kuldeep: https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
[23:27] <nacc> *if* your build is turning it into native, it's probably a mistake int he naming or versioning -- given that your package is not a debian-specific library (afaict)
[23:29] <kuldeep> nacc, git-recipe-build generated libbox0_0.3.0.tar.xz
[23:29] <wgrant> Not quite.
[23:29] <wgrant> bzr-builder and git-build-recipe are designed for daily builds, so they will convert a package from 3.0 (quilt) to 3.0 (native) if they can't find an orig tarball to use.
[23:29] <nacc> oh!
[23:30] <wgrant> They attempt to obtain the orig tarball using pristine-tar on the git or bzr repository used in the build. If that fails, they'll transform it to native so the build can succeed.
[23:31] <kuldeep> relate to "--allow-fallback-to-native" argument?
[23:32] <wgrant> Yes.
[23:33] <wgrant> So it's harmless, but you might want to add pristine-tar metadata to the repository so you get a proper non-native build.
[23:33] <kuldeep> where did pbuilder put my resultant .deb file?
[23:34] <kuldeep> wgrant, ok, will look into it later. thanks for the input.
[23:37] <kuldeep> got it! /var/cache/pbuilder/result/
[23:56] <kuldeep> my build is having a little failure.   https://paste.debian.net/hidden/ed108325/
[23:57] <kuldeep> i kept like https://anonscm.debian.org/cgit/users/cjwatson/libpipeline.git/tree/debian/libpipeline1.symbols#n1   "libpipeline.so.1 libpipeline1 #MINVER#"
[23:57] <kuldeep> but pbuilder is raising error and saying `libbox0.so.2.0.0 libbox0-2 #MINVER#`   (see the paste for diff)
[23:58] <kuldeep> (im almost there :)