kuldeepi earlier looked at http://packaging.ubuntu.com/html/packaging-new-software.html and it help.00:05
naccyeah, although i'd ignore the bzr bits :)00:07
kuldeepIm 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
nacckuldeep: one is a source package name (this source package)00:07
naccthat's Source: ....00:07
kuldeepin my case, that would become "libbox01" isnt it.00:07
naccthe other two are binary packages00:07
naccwhich are Package: ...00:08
nacckuldeep: so you probably need at least one more binary package in your control file for the library itself00:08
nacckuldeep: probably called libbox000:08
nacckuldeep: well, i woudl say, if i had to geuss, your source package is actually 'libbox' not 'libbox0' as it is now00:09
kuldeepinstead of "Package: libpipeline1"   can i just keep "Package: libpipeline"00:09
nacciiuc, that indicates so versioning00:09
kuldeepnacc, "box0" the name, brand whatever you can think of it00:09
kuldeepand libbox0 is now at v0.3.000:10
nacckuldeep: ok, you can name it however you want, and source package names can be the same as binary package names00:10
nacckuldeep: *so* versioning00:10
naccshared object00:10
nacchttps://autotools.io/libtool/version.html may help00:10
kuldeepnacc, yes, the shared library follow the INTERFACE standard. (version age like stuff)00:11
kuldeepupdate the paste: https://gist.github.com/kuldeepdhaka/79f3b0b59e3d504abe73000909b958a400:16
kuldeepnacc, cjwatson    (heavily borrowed from cjwatson libpipeline)00:17
kuldeepalso, directly used libpipeline1.install and libpipeline-dev.install00:18
kuldeepupdate: Added all file i have00:20
kuldeeppossibly just need to figure out what need to be in "rules" file00:24
nacckuldeep: do you currently use a Makefile in your upstream?00:27
cjwatsonWhat is the SONAME of your library?00:27
cjwatsonThe runtime library package should probably in fact be libbox0-1 or something like that, reflecting the SONAME.00:28
nacccjwatson: good point, i didn't realize earlier that 'box0' was part of the product name00:28
cjwatsonAnd you should have a symbols file declaring its exported interfaces.00:28
kuldeeplibbox0.so.2.0.0  <--- master code, latest00:29
cjwatsonThen libbox0-200:29
cjwatsonThe 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
cjwatsonThe symbols -> The symbols file00:31
kuldeepnacc, uses CMake which generate the Makefile.00:44
kuldeepwill resume work on waking up.00:44
kuldeepthank you, GN.00:45
=== 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
kuldeepim 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
kuldeepis my usage of debupstream:master and revno:master correct?  (use the master branch to get these variables)?14:58
=== chihchun is now known as chihchun_afk
kuldeepIm 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:45
kuldeepdo i need to do something special to push a new branch? (my first interaction with git server)15:46
kuldeepi 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`15:48
kuldeepis it due to because i have imported the git code from somewhere else,i cannot push any changes to it?16:08
sigmaviruskuldeep: if I look at https://code.launchpad.net/libbox0 I see a recently updated debian branch16:49
sigmavirusoh kuldeep I think I see the problem16:50
sigmavirusYou cloned using git:// which is a read-only URI16:50
jpdI am trying to establish a session from a build server to launchpad upload a release and I am in a text browser16:50
sigmavirusI think you might need to use git+ssh://git.launchpad.net/libbox016:50
kuldeepsigmavirus, i uploaded to the gitlab repo, then i told lp to pull the changes.16:50
jpd I can't complete the login sequence because of this error : Launchpad requires a REFERER header to perform this action.16:51
jpdthe browser is lynx16:51
kuldeepsigmavirus, 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:52
sigmaviruskuldeep: odd. I don't use launchpad as a git repository, so I'm not sure why you're running into your particular issue16:53
cjwatsonkuldeep: you can't push to repositories that are imported from somewhere else17:05
cjwatsonkuldeep: either push to a different repository in the same project on Launchpad, or (simpler if you can) just push the branch to gitlab17:06
cjwatsonkuldeep: though sigmavirus is also correct that you can't push over git://17:06
cjwatsonkuldeep: 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:08
kuldeepcjwatson, that what i did.17:41
nacckuldeep: 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:42
cjwatsonthat'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
kuldeeppretty reasonable behaviour, i also concluded that.17:44
nacccjwatson: makes total sense to me :)17:45
kuldeepcjwatson, hum17:45
kuldeepthough this import behaviour could have been per branch, but more work and very specific usecase.17:46
kuldeepreadonly clone could have been a good description. something like that tell people what will happen if the code is "imported".17:47
cjwatsonfeel free to file a bug17:48
cjwatsonI'm very unlikely to remember an IRC conversation from now until after the new year :)17:48
nacckuldeep: it is documented at: https://help.launchpad.net/Code/Git17:49
nacc"You won't be able to push directly to the imported repository"17:49
cjwatsonyeah, but it's reasonable to suggest that it should be more self-documenting17:50
naccnever hurts :)17:50
nacccjwatson: 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
naccthat is, defer to the new year :)17:51
cjwatsonI'm not sure I agree with that decision, but I also don't want to get into it now :)17:53
nacccjwatson: fair enough :)17:55
nacccjwatson: but i generally want to have a launchpad discussion on it, so we can figure all that out17:55
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:02
kuldeepnacc, :)18:03
nacckuldeep: sorry, did you mean: https://help.launchpad.net/Code/Git ?18:04
nacckuldeep: because it is there already18:04
kuldeepnacc, its on doc page i know. but such a important peice of information should probably be on the ui directly. (imo)18:05
nacckuldeep: oh ok, i'd clarify in the bug where you mean then18:06
nacckuldeep: as i don't know what by reading it :)18:06
cjwatsonit's always fine to give an example URL18:07
cjwatsonso please do that18: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:07
nacci assume the error was a generic git protocol return code (and permission denied was presumably accurate)18:08
kuldeepit could have been because im trying to push to some one else repo.18:08
cjwatsonthat should be a separate bug18:08
cjwatsonagain, with specifics18:08
kuldeepin 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:10
kuldeep(build locally by `git-build-recipe --allow-fallback-to-native libbox0.recipe working-dir`)18:12
kuldeepcould not understand "62+62". shouldnt that have been "62" only?18:12
kuldeeplibbox0.recipe:   "# git-build-recipe format 0.4 deb-version {debupstream}+{revno}    \n      lp:libbox0 debian"18:15
naccit seems like it should have been 0.3.0-62 (depending on the revision number being 62)18:18
nacckuldeep: "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:19
nacckuldeep: so i think you want {debupstream:<branch name>}18:20
kuldeepgitbuildrecipe.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:21
kuldeep^^ deb-version {debupstream:master}+{revno}18:22
kuldeepgitbuildrecipe.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
naccinteresting, maybe it only applies to bzr?18:22
nacchrm, do you have a master branch? it seems liek the : syntax should work regardless?18:23
kuldeepnacc, i have two branch: master, debian.   i uploaded debian some time back.18:23
nacckuldeep: which one has the debian/changelog in it?18:24
kuldeepnacc, debian18:24
nacckuldeep: then that's the branch you should refer to18:24
nacc"debversion, debupstream and debupstream-base require debian/changelog to exist in the given branch. "18:24
naccnot 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 recipe18:25
kuldeepnacc, then which branch code will be compiled? debian or master?18:25
kuldeepcurrently BRANCH(debian) = BRANCH(master) + COMMIT(containing-debian-dir)18:26
nacckuldeep: i think the code to compile depends entirely on your recipe18:26
kuldeepi think,i can solve the problem by making the COMMIT(containing-debian-dir) in master later on.18:27
nacckuldeep: i htink you're looking for the nest-part or merge bits of the recipes18:27
kuldeepgitbuildrecipe.deb_version.NotFullyExpanded: deb-version not fully expanded: {debupstream:debian}+{revno:debian}.  Valid substitutions in recipe format 0.4 are: ['{time} ......18:27
mquigleyI'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:28
kuldeepmquigley, please go on.18:29
kuldeepnacc, you can try my recipe:   "# git-build-recipe format 0.4 deb-version {debupstream}+{revno}   \n   lp:libbox0 debian" if you like18:29
nacckuldeep: i'm out of my depth now, maybe cjwatson or another LP admin has insight18:30
kuldeepoops "# git-build-recipe format 0.4 deb-version {debupstream:debian}+{revno:debian}   \n   lp:libbox0 debian"18:30
nacckuldeep: will try locally18:30
mquigleyThank 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
dobeykuldeep: you probably don't just want to build from the debian branch. you want to pull the master branch and then merge the debian branch18:31
kuldeepdobey, BRANCH(debian) = BRANCH(master) + COMMIT(containing-debian-dir)18:31
dobeykuldeep: until you push new stuff onto master, yes18:31
kuldeepdobey, "until you push new stuff onto master, yes" what do you mean by that?18:32
kuldeepplease elaborate.18:32
nacckuldeep: hrm, i get a different error from `git-build-recipe` -- says it can't find an upstream tag18:32
dobeykuldeep: i mean, when you push changes to master, the debian branch doesn't automatically get them18:33
nacckuldeep: http://paste.ubuntu.com/23665127/18:33
kuldeepdobey, the debian branch is on launchpad, i press'd "Import Now" to force import.18:34
nacckuldeep: what dobey is referring to is a general structure of your repository18:34
nacckuldeep: as you push commits to master, your debian branch will be 'behind' master18:34
nacckuldeep: so you are forcing yourself to rebase and push debian (forcibly as it won't be a fast-forward) each time18:34
nacckuldeep: you can see the merge examples in the recipes documentation: https://help.launchpad.net/Packaging/SourceBuilds/Recipes18:35
dobeyhmm, is there any documentation on git recipes?18:36
naccdobey: it's in there too, afaict18:36
naccalthough it's not 100% clear if everything about bzr recipes applies to git recipes :)18:36
kuldeeplook 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
kuldeeplemme fix that first18:36
dobeynacc: yeah i see some "if you use git, do y"18:37
naccdobey: yep18:37
dobeyhmm, launchpad says "no recipes using this repository"18:39
dobeyi think http://pastebin.ubuntu.com/23665168/ is actually what you want18:40
kuldeepok, 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:45
kuldeepdobey, 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:47
dobeykuldeep: remove the :debian then (i didn't modify that from yours)18:48
kuldeepdobey, 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:49
dobeykuldeep: yeah, your version string is native, so build with --allow-fallback-to-native18:50
dobey(lp does build recipes with that option)18:50
kuldeepnow it got "libbox0_0.3.0+62.tar.xz"  when i passed --allow-fallback-to-native18:50
kuldeep*now i got18:50
* kuldeep wonder the use of --allow-fallback-to-native18:51
kuldeepnow "# 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:54
dobeythat was undoubtedly not the problem18:58
kuldeepi have the package. libbox0_0.3.0+62.tar.xz :)  [containing the source]18:58
kuldeepgetting pbuilder :D18:59
kuldeepdobey, "that was undoubtedly not the problem" then? what was the problem?19:02
kuldeepdobey, <dobey> nacc: yeah i see some "if you use git, do y"    i wont mind understanding the joke. (if it is) :D19:03
dobeythere is no joke19:03
dobeyi 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:04
kuldeepoh ok. atleast its gone now.19:05
dobeybut the recipe i pastebinned is the one you want19:08
dobeyat least, if you want launchpad to automatically build packages from your master branch19:08
kuldeepdobey, probably later, i will move the debian/ files to master branch.19:10
dobeynot a requirement19:12
dobeybut do whatever you want i guess19:12
kuldeepdobey, 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:15
kuldeepif its at one place, there is a heigher chance of remembering.19:16
kuldeepdobey, if you were me, will you have kept that file?19:16
* kuldeep `pbuiler create` finished19:16
dobeyyou only really need to update debian/changelog for recipes if you want to bump the main upstream version19:17
dobeybut sure19:17
kuldeepmy 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 cmake19:30
kuldeepi see https://anonscm.debian.org/cgit/users/rfrancoise/libpcap.git/tree (uses cmake) but could not understand how to reuse the rule file.19:31
kuldeepi 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/rules19:33
dobeyunless you need to pass specific options to cmake or something, the simplest rules file with just %: rule that runs "dh $@" will "just work"19:44
dobeyi doubt you need the -Skde19:45
kuldeephum, in think too.19:47
kuldeephttps://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:47
nacckuldeep: again you don't *need* to override any targets unless you know you need to19:48
kuldeepi think, my code is a library, and `dh_makeshlibs -- -c4` is require for library. symbol checking/generation.... something like that19:49
kuldeep*my reason, my code19:49
kuldeepnacc, isnt it?19:49
naccagain, they are choosing to override the -c value (default is 1)19:51
dobeyyou don't need to override anything by default19: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:52
dobeyi would just leave the symbols file out of your package for now19:53
kuldeepdobey, for simplicity (mine) or my package is 0.x (which are considered in very heavy development) or something else?19:54
dobeyi 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 yet19:54
kuldeepjust PPA atm.  (i wont mind it get into debian or ubuntu :)19:55
kuldeepyou are right, i cannot garantee abi atm. (fyi, i just broke abi compatibility with prev release :)19:56
kuldeepso, as dobey recommend - no symbol file for now.19:56
dobeyand you're probably not bumping the soname whenever you break abi either19:57
dobeyso yeah, simplest to just avoid the symbols file for now19:57
kuldeepim bumping current=2, age=0, revision=0     last afair was current=1 and age=0, revision=019:58
kuldeepdobey, https://git.launchpad.net/libbox0/tree/libbox0/CMakeLists.txt#n5319:59
kuldeepi 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:01
kuldeepthe 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:03
kuldeepdobey, make sense?20:04
kuldeepi 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:24
kuldeepim 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:26
dobeyyou still have to maintain something20:27
kuldeepdobey, but not in every release.20:28
dobeyand yes, you can append the git-commit or the revno launchpad assigns to the commit if you want20:28
dobeykuldeep: well, if you bump the SONAME in every release, yes, you have to rename the .install file and update the control file20:28
=== elijah_ is now known as elijah
dobeyspeak of which, you should probably have the install file to use libbox0*.so.2* instead of just *.so.*20:29
kuldeepdobey, it contain "usr/lib/*/libbox0*.so.*"   so, it does the work automatically?20:29
dobeyso it will fail to build if you bump the soname20:29
dobeykuldeep: right, but then the package name doesn't match the soname20:29
dobeywhich is wrong20:29
kuldeepi 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
kuldeepdobey, "which is wrong" wrong in the sense that for future release it could cause problem?20:31
kuldeepplease share your experience, i dont know anything about debian packaging.20:32
dobeyyes, and that it doesn't comply with debian packaging standards20:32
cjwatsonThe reason for this is that it causes unnecessary upgrade problems.20:34
kuldeepdobey, 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:34
cjwatsonBut 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
dobeyyeah, 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 problem20:35
cjwatsonI think that's busywork :)20:35
dobeybecause 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 why20:36
dobeyversus building anyway and giving you a broken upgrade :)20:36
cjwatsonI prefer using a symbols file to tell me that.20:36
cjwatsonThat's what dh_makeshlibs -- -c4 does20:36
* kuldeep is having hard time following cjwatson and dobey cross-communication. :)20:37
cjwatsonBut I agree that if you aren't bothering with a symbols file then maybe you need some other kind of guard20:37
kuldeepif 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
cjwatsonPossibly, depending on how competent they are.20:39
cjwatsonIt's probably unavoidable for there to be some kind of upgrade problem there, unless it happens to coincide with a SONAME change.20:40
cjwatsonSo you really are storing up trouble for yourself.20:40
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:41
kuldeepcjwatson, "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:42
cjwatsonYes, 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:43
cjwatsonIf 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:44
kuldeepthats a good insight of the working.20:45
kuldeepcjwatson, 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:47
kuldeepif they have same SO version.  if concidently, libbox0-X got a different SO version, then things will go fine smoothly. right?20:48
cjwatsonIf 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
cjwatsonI don't understand why you're trying so very hard to ignore the best-practice advice we've given you.20:49
kuldeepcjwatson, im trying to feed my curiosity/understanding of what would happen/process.20:51
cjwatsonA 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:51
cjwatsonSo it's best to follow them pretty carefully until you understand things well enough to vary from them.20:52
kuldeephahahhaha nicely said. yes.20:52
OverCoderI have been biulding a package for an open-source project for quite a while20:52
OverCoderThe problem is that I built my package and uploaded it with the wrong upstream tarball, and obviously build failed at Launchpad's servers20:53
OverCodernow I built with the correct upstream tarball but launchpad is refusing the new tarball, because it has different contents under the same name20:53
OverCoderwhat do I do?20:53
cjwatsonYou'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:53
OverCoderwell, debuild fails if I rename the upstream tarball20:54
cjwatsonSo 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
cjwatsonit will only fail if you haven't changed other things to suit20:54
OverCoderlet me try20:54
cjwatsonif you do it with the above scheme then you should be able to drop the +ds suffix at the next upstream release.20:55
OverCoderI think this is gonna work, uploading20:57
OverCoderthat worked D:21:00
OverCodercjwatson: 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:00
cjwatsonI might as well.21:01
OverCoderokay :P21:01
kuldeepcjwatson, ok, im going to do libbox0-2. and i have to maintain proper versions.21:09
kuldeepthen its just a matter of preference to provide a symbol file or not, will decide on it later.21:10
cjwatsonRight, while a symbols file is best practice it's not necessary for correctness.21:11
kyrofaI'm getting timeouts whenever I try to change bug statuses21:13
kyrofaI can browse everything fine, though21:13
cjwatsonkyrofa: Almost certainly the usual everything-stops-for-ten-minutes-while-PostgreSQL-changes-its-underwear thing.21:13
kyrofacjwatson, alright, thanks for the heads up, I'll give it a breather21:14
cjwatsonWe'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:14
kuldeepcjwatson, 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:20
kuldeep(making sure that i dont mix up SO version and semiver)21:21
kuldeeplooking at changelog, it always has "upstream release" that at version.21:23
dobeyyes, the version after each symbol is the package version it was introduced in21:23
kuldeep(building source using pbuilder) atleast compiled code.21:34
cjwatsonRight, it turns into a >= dependency.21:35
cjwatsonAnd in libpipeline I've never introduced symbols in anything other than a new upstream release.21:35
kuldeephttps://paste.debian.net/903807/   build shared library and reached till make install. but then failed. idk why21:35
kuldeep(idk why it is installing at wrong path)21:36
kuldeephere is the my debian/  https://git.launchpad.net/libbox0/commit/?h=debian21:36
cjwatsonThat looks like you're missing .install files, or maybe missing some entries in them.21:36
cjwatsonDoesn't look like it's installing to the wrong path.21:36
kuldeepi have libbox0-2.install and libbox0-dev.install21:37
cjwatsonOh, no, I see, missing multiarch directory.  One moment.21:38
cjwatsonI think you're probably hardcoding too many directories in your libbox0/CMakeLists.txt.  I don't speak cmake very well.21:40
cjwatsonBut 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:41
cjwatsonAlso you need to remove usr/share/man/man3 from debian/libbox0-dev.install.21:42
dobeyneed to -DCMAKE_INSTALL_LIBDIR="lib/${DEB_GNU_ARCH_TRIPLET}" or whatever the variable is21:42
cjwatsonNot that one.  But isn't some equivalent of that done automatically?21:43
dobeyoh, well the CMakeLists.txt is broken further down too21:43
cjwatsonAh, right, only very modern debhelper.21:43
cjwatsonAnyway that says that upstreams should use GNUInstallDirs.21:44
dobeyalso that too21:44
cjwatsonAnd then you probably do indeed need to pass -DCMAKE_INSTALL_LIBDIR="lib/$(DEB_HOST_MULTIARCH)" in a dh_auto_configure override21:45
dobeybut nice that newer debhelper does it21:46
* dobey wonders what probability of it being SRU to xenial is21:47
cjwatsonabout nil21:47
cjwatsonI suspect21:47
cjwatsonAnyway 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/control21:47
cjwatsonYour 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:48
kuldeepif 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
cjwatsondisable multiarch: drop the */ segments from the usr/lib/whatever lines in .install, and remove both occurrences of Multi-Arch: same from debian/control21:50
cjwatsonthat's as simple as I can make it21:50
kuldeepi do understand a bit that multi arch installation would be problem because of hard coding in cmake fikle21:50
cjwatsonI can't give you simple language for what needs to be fixed in your cmake config to do the job properly21:51
cjwatsonbut you can do the job improperly here by disabling multiarch and it won't be terrible21:51
dobeyuse GNUInstallDirs and don't use hard-coded path names like "lib" and "bin", basically21:51
dobeyto make multi-arch workable; otherwise just drop the multi-arch support as cjwatson said21:52
kuldeepok, in my cmake code, i add "include(GNUInstallDirs)" and use the exported variable by the module instead of hardcoded strings. right?21:54
kuldeeplooking at the provided examples21:55
kuldeepthat seem simple.21:56
kuldeepquestion: 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 dont22:11
kuldeephttps://cmake.org/cmake/help/v3.3/module/GNUInstallDirs.html  seems like CMAKE_INSTALL_INCLUDEDIR is set by the package.22:13
kuldeepim 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:50
kuldeepits adding "+65" at the end of line in symbol.22:51
kuldeepdobey, cjwatson ok?22:51
kuldeep(im revoing "+{revno}" because of which "+65" is being generated)22:52
kuldeephttps://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
kuldeepcjwatson, any tip ^^ ?23:18
kuldeepdobey  ^^^ :)23:22
nacckuldeep: do you understand the difference between the two?23:23
nacckuldeep: https://wiki.debian.org/Projects/DebSrc3.0 and `man dpkg-source` may help23:24
kuldeepnacc, idk the difference.23:24
kuldeepi shamelessly copied the file :)23:24
kuldeepnacc, i can choose any. any significat difference?23:26
nacckuldeep: https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F23: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:27
kuldeepnacc, git-recipe-build generated libbox0_0.3.0.tar.xz23:29
wgrantNot quite.23:29
wgrantbzr-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
wgrantThey 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:30
kuldeeprelate to "--allow-fallback-to-native" argument?23:31
wgrantSo 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
kuldeepwhere did pbuilder put my resultant .deb file?23:33
kuldeepwgrant, ok, will look into it later. thanks for the input.23:34
kuldeepgot it! /var/cache/pbuilder/result/23:37
kuldeepmy build is having a little failure.   https://paste.debian.net/hidden/ed108325/23:56
kuldeepi kept like https://anonscm.debian.org/cgit/users/cjwatson/libpipeline.git/tree/debian/libpipeline1.symbols#n1   "libpipeline.so.1 libpipeline1 #MINVER#"23:57
kuldeepbut pbuilder is raising error and saying `libbox0.so.2.0.0 libbox0-2 #MINVER#`   (see the paste for diff)23:57
kuldeep(im almost there :)23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!