| kuldeep | i earlier looked at http://packaging.ubuntu.com/html/packaging-new-software.html and it help. | 00:05 |
|---|---|---|
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| kuldeep | nacc, yes, the shared library follow the INTERFACE standard. (version age like stuff) | 00:11 |
| kuldeep | update the paste: https://gist.github.com/kuldeepdhaka/79f3b0b59e3d504abe73000909b958a4 | 00:16 |
| kuldeep | nacc, cjwatson (heavily borrowed from cjwatson libpipeline) | 00:17 |
| kuldeep | also, directly used libpipeline1.install and libpipeline-dev.install | 00:18 |
| kuldeep | update: Added all file i have | 00:20 |
| kuldeep | possibly just need to figure out what need to be in "rules" file | 00:24 |
| kuldeep | :) | 00:24 |
| nacc | kuldeep: do you currently use a Makefile in your upstream? | 00:27 |
| cjwatson | What is the SONAME of your library? | 00:27 |
| 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:28 |
| kuldeep | libbox0.so.2.0.0 <--- master code, latest | 00:29 |
| cjwatson | Then libbox0-2 | 00:29 |
| 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:31 |
| kuldeep | nacc, uses CMake which generate the Makefile. | 00:44 |
| kuldeep | will resume work on waking up. | 00:44 |
| kuldeep | thank 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 | ||
| 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:55 |
| kuldeep | is 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 | ||
| 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:45 |
| kuldeep | do i need to do something special to push a new branch? (my first interaction with git server) | 15:46 |
| 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` | 15:48 |
| kuldeep | is it due to because i have imported the git code from somewhere else,i cannot push any changes to it? | 16:08 |
| sigmavirus | kuldeep: if I look at https://code.launchpad.net/libbox0 I see a recently updated debian branch | 16:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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 | 16:53 |
| cjwatson | kuldeep: you can't push to repositories that are imported from somewhere else | 17:05 |
| 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:06 |
| 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:08 |
| kuldeep | cjwatson, that what i did. | 17:41 |
| 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:42 |
| 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:44 |
| nacc | cjwatson: makes total sense to me :) | 17:45 |
| kuldeep | cjwatson, hum | 17:45 |
| kuldeep | though this import behaviour could have been per branch, but more work and very specific usecase. | 17:46 |
| kuldeep | readonly clone could have been a good description. something like that tell people what will happen if the code is "imported". | 17:47 |
| 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:48 |
| 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:49 |
| cjwatson | yeah, but it's reasonable to suggest that it should be more self-documenting | 17:50 |
| nacc | never hurts :) | 17:50 |
| 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:51 |
| cjwatson | I'm not sure I agree with that decision, but I also don't want to get into it now :) | 17:53 |
| 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 | 17:55 |
| 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:02 |
| kuldeep | nacc, :) | 18:03 |
| nacc | kuldeep: sorry, did you mean: https://help.launchpad.net/Code/Git ? | 18:04 |
| nacc | kuldeep: because it is there already | 18:04 |
| kuldeep | nacc, its on doc page i know. but such a important peice of information should probably be on the ui directly. (imo) | 18:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:12 |
| kuldeep | libbox0.recipe: "# git-build-recipe format 0.4 deb-version {debupstream}+{revno} \n lp:libbox0 debian" | 18:15 |
| nacc | it seems like it should have been 0.3.0-62 (depending on the revision number being 62) | 18:18 |
| 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:19 |
| nacc | kuldeep: so i think you want {debupstream:<branch name>} | 18:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| nacc | kuldeep: you can see the merge examples in the recipes documentation: https://help.launchpad.net/Packaging/SourceBuilds/Recipes | 18:35 |
| 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:36 |
| dobey | nacc: yeah i see some "if you use git, do y" | 18:37 |
| nacc | dobey: yep | 18:37 |
| dobey | hmm, launchpad says "no recipes using this repository" | 18:39 |
| dobey | anyway | 18:40 |
| dobey | i think http://pastebin.ubuntu.com/23665168/ is actually what you want | 18:40 |
| 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:45 |
| 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:47 |
| dobey | kuldeep: remove the :debian then (i didn't modify that from yours) | 18:48 |
| 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:49 |
| 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:50 |
| * kuldeep wonder the use of --allow-fallback-to-native | 18:51 | |
| 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:54 |
| 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:58 |
| kuldeep | getting pbuilder :D | 18:59 |
| kuldeep | dobey, "that was undoubtedly not the problem" then? what was the problem? | 19:02 |
| 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:03 |
| 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:04 |
| kuldeep | oh ok. atleast its gone now. | 19:05 |
| 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:08 |
| kuldeep | dobey, probably later, i will move the debian/ files to master branch. | 19:10 |
| dobey | not a requirement | 19:12 |
| dobey | but do whatever you want i guess | 19:12 |
| 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:15 |
| 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:16 | |
| 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:17 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:44 |
| dobey | i doubt you need the -Skde | 19:45 |
| 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:47 |
| nacc | kuldeep: again you don't *need* to override any targets unless you know you need to | 19:48 |
| 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:49 |
| nacc | again, they are choosing to override the -c value (default is 1) | 19:51 |
| 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:52 |
| dobey | i would just leave the symbols file out of your package for now | 19:53 |
| 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:54 |
| kuldeep | just PPA atm. (i wont mind it get into debian or ubuntu :) | 19:55 |
| 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:56 |
| 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:57 |
| kuldeep | im bumping current=2, age=0, revision=0 last afair was current=1 and age=0, revision=0 | 19:58 |
| kuldeep | dobey, https://git.launchpad.net/libbox0/tree/libbox0/CMakeLists.txt#n53 | 19:59 |
| 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:01 |
| 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:03 |
| kuldeep | dobey, make sense? | 20:04 |
| dobey | ok | 20:10 |
| 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:24 |
| 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:26 |
| dobey | you still have to maintain something | 20:27 |
| 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 | 20:28 |
| === elijah_ is now known as elijah | ||
| 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:29 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| * 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:37 |
| 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:39 |
| 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: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 |
| 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:42 |
| 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:43 |
| 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:44 |
| kuldeep | thats a good insight of the working. | 20:45 |
| 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:47 |
| kuldeep | if they have same SO version. if concidently, libbox0-X got a different SO version, then things will go fine smoothly. right? | 20:48 |
| 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:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| OverCoder | great. | 20:56 |
| OverCoder | I think this is gonna work, uploading | 20:57 |
| 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:00 |
| cjwatson | I might as well. | 21:01 |
| OverCoder | okay :P | 21:01 |
| cjwatson | done | 21:02 |
| kuldeep | cjwatson, ok, im going to do libbox0-2. and i have to maintain proper versions. | 21:09 |
| kuldeep | then its just a matter of preference to provide a symbol file or not, will decide on it later. | 21:10 |
| cjwatson | Right, while a symbols file is best practice it's not necessary for correctness. | 21:11 |
| 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:13 |
| 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:14 |
| 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:20 |
| kuldeep | (making sure that i dont mix up SO version and semiver) | 21:21 |
| 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:23 |
| kuldeep | (building source using pbuilder) atleast compiled code. | 21:34 |
| 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:35 |
| 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:36 |
| kuldeep | i have libbox0-2.install and libbox0-dev.install | 21:37 |
| cjwatson | Oh, no, I see, missing multiarch directory. One moment. | 21:38 |
| cjwatson | I think you're probably hardcoding too many directories in your libbox0/CMakeLists.txt. I don't speak cmake very well. | 21:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| cjwatson | And then you probably do indeed need to pass -DCMAKE_INSTALL_LIBDIR="lib/$(DEB_HOST_MULTIARCH)" in a dh_auto_configure override | 21:45 |
| dobey | but nice that newer debhelper does it | 21:46 |
| * 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:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| dobey | to make multi-arch workable; otherwise just drop the multi-arch support as cjwatson said | 21:52 |
| kuldeep | ok, in my cmake code, i add "include(GNUInstallDirs)" and use the exported variable by the module instead of hardcoded strings. right? | 21:54 |
| kuldeep | looking at the provided examples | 21:55 |
| kuldeep | that seem simple. | 21:56 |
| 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:11 |
| kuldeep | https://cmake.org/cmake/help/v3.3/module/GNUInstallDirs.html seems like CMAKE_INSTALL_INCLUDEDIR is set by the package. | 22:13 |
| kuldeep | --- | 22:49 |
| 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:50 |
| kuldeep | its adding "+65" at the end of line in symbol. | 22:51 |
| kuldeep | dobey, cjwatson ok? | 22:51 |
| kuldeep | (im revoing "+{revno}" because of which "+65" is being generated) | 22:52 |
| kuldeep | *removing | 22:52 |
| 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:18 |
| kuldeep | dobey ^^^ :) | 23:22 |
| nacc | kuldeep: do you understand the difference between the two? | 23:23 |
| 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:24 |
| kuldeep | nacc, i can choose any. any significat difference? | 23:26 |
| 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:27 |
| 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:29 |
| 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:30 |
| kuldeep | relate to "--allow-fallback-to-native" argument? | 23:31 |
| wgrant | Yes. | 23:32 |
| 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:33 |
| kuldeep | wgrant, ok, will look into it later. thanks for the input. | 23:34 |
| kuldeep | got it! /var/cache/pbuilder/result/ | 23:37 |
| kuldeep | my build is having a little failure. https://paste.debian.net/hidden/ed108325/ | 23:56 |
| 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:57 |
| kuldeep | (im almost there :) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!