| drstikko | StevenK: yes this all succeeded and packages are build, but no binaries. Where does the build system gets his info from for placing the binaries? From the install step in the Makefile? | 00:01 |
|---|---|---|
| StevenK | drstikko: Can you link me to the recipe page, and I'll have a look? | 00:02 |
| drstikko | yes of course | 00:03 |
| drstikko | StevenK: https://code.launchpad.net/~d-r-stikkolorum/+recipe/dporg-daily | 00:04 |
| JonnyJD_ | drstikko: yes, a build on launchpad does both. You might be missing stuff in your debian/control file (so no binaries get built) | 00:11 |
| drstikko | JonnyJD_: I think they even get build, but not added to the deb. I think the builder gets info from the Makefile | 00:15 |
| drstikko | .... for placing the binairies e.g. in /usr/bin | 00:15 |
| JonnyJD_ | drstikko: the builder does not "get info from makefile" | 00:16 |
| JonnyJD_ | drstikko: the builder uses the makefile | 00:16 |
| JonnyJD_ | possibly the makefile is not prepared to do standard things like DESTDIR (not autotools build?) | 00:16 |
| drstikko | JonnyJD: I understand, | 00:16 |
| JonnyJD_ | check your debian/rules, or link them here, somebody might find the problem | 00:17 |
| drstikko | JonnyJD, wel I discovered there was no make install step in the Makefile | 00:17 |
| drstikko | .... so I added that | 00:17 |
| drstikko | .... but I have no quota anymore for today ;) | 00:18 |
| JonnyJD_ | how does your debian/rules work? using debhelper? | 00:18 |
| drstikko | JonnyJD: I used debhelper | 00:19 |
| drstikko | ... did not changed the rule file | 00:19 |
| drstikko | and use a Makefile | 00:19 |
| maxb | No 'make install' implementation would certainly account for not getting anything installed :-) | 00:19 |
| maxb | It's generally wrong for a package to be installing into /usr/local/ though | 00:20 |
| JonnyJD_ | hm, then fixing the install target in the makefile to use the DESTDIR and/or PREFIX environment variables might help (don't know which exactly, but DESTDIR would be my first) | 00:20 |
| drstikko | maxb: yes, ;) I also thought that, but could not try it, too many builds today | 00:20 |
| JonnyJD_ | drstikko: you can also build locally first | 00:21 |
| maxb | LP isn't really meant as a service for practising building things, you should just do that on your local computer | 00:21 |
| drstikko | JonnyJD_ : added it to the Makefile, can try it tomorrow | 00:21 |
| JonnyJD_ | drstikko: try bzr builddeb and "pbuilder" for local builds | 00:22 |
| drstikko | max: yes you are probably right | 00:22 |
| drstikko | ... but local was not working | 00:22 |
| drstikko | ok JonnyJD, thnx | 00:22 |
| JonnyJD_ | drstikko: I do "bzr builddeb -S" to create the dsc and "cd ../build-area && pbuilder build <dsc file>" | 00:23 |
| JonnyJD_ | but explaining how that works exactly is a bit much for now on IRC (you'll find something on google) | 00:23 |
| maxb | pbuilder is a helpful tool for replicating builds in a clean environment, but there's no need to go to that extent just to develop things like Makefiles | 00:24 |
| maxb | It should be perfectly fine to just run 'dpkg-buildpackage -b' in a local bzr tree | 00:25 |
| drstikko | ok I'll give it a try locally | 00:26 |
| JonnyJD_ | maxb, drstikko: well, yes. If you have a nice debian environment for building you can also go without. I use pbuilder to make sure I have a clean build environment/system | 00:27 |
| maxb | A clean-chroot approach is a valuable tool, but can make development more cumbersome when you're rapidly changing things and rebuilding | 00:29 |
| drstikko | wel dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/dporg_0.3-15-1.diff.qKJfrd | 00:30 |
| drstikko | ... is what I get from bzr builddeb -S | 00:30 |
| drstikko | and dpkg-buildpackage -b calls the wrong qmake | 00:31 |
| maxb | I don't know much (anything) about qmake, but perhaps your package should be specifying the correct one somehow | 00:33 |
| maxb | As for the other - it means you have changes in your bzr tree that don't match the upstream tarball, and aren't properly represented as patches | 00:34 |
| maxb | You have a very strange version string too - it's generally considered unusual to have more than one hyphen | 00:35 |
| drstikko | maxb: ok I will give it a look tomorrow | 00:35 |
| drstikko | heading for bed now, all new to me this environment | 00:36 |
| drstikko | thn guys | 00:36 |
| maxb | The hyphen serves as the separator between the upstream version and the packaging version - whilst there's a systematic definition of how to interpret versions with multiple hyphens, it's generally considered too confusing to be wise to rely on | 00:36 |
| === tasdomas` is now known as tasdomas | ||
| drstikko | Anyone can help me out with dpkg-buildpackage to force to qmake-qt4 in stead of qmake | 08:43 |
| AndChat|358400 | Can anyone help me out with forcing dpkg-buildpackage use qmake-qt4 in stead of qmake ? | 08:52 |
| Pomyk_ | hello, I have a problem with a branch, it's stuck in "updating branch...": https://code.launchpad.net/~pomyks/maria/10.0-per-query-variables | 10:08 |
| drstikko | who knows how to force dpkg-buildpackage to use qmake-qt4 | 10:26 |
| drstikko | ? | 10:26 |
| wgrant | drstikko: Have you tried the --buildsystem=qmake_qt4 option to dh? | 10:30 |
| drstikko | wgrant not yet :) going to try | 10:33 |
| wgrant | Pomyk_: I've fixed that branch up. | 10:40 |
| drstikko | wgrant how to add that? just in the rules file? (I see I cannot add it to the dpkg-buildpackage command)) | 10:41 |
| wgrant | drstikko: That would go as an argument to the dh invocation in your debian/rules file. | 10:41 |
| drstikko | I tried but does not accept it | 10:41 |
| Pomyk_ | wgrant: thanks! | 10:42 |
| wgrant | drstikko: What do you mean? | 10:43 |
| drstikko | wgrant rules file is very empty: %: dh $@ , the rest is in the Makefile | 10:43 |
| wgrant | drstikko: dh --buildsystem=qmake_qt4 $@ | 10:43 |
| drstikko | yes I tried that | 10:43 |
| wgrant | What didn't work? | 10:43 |
| drstikko | wgrant dh: Unknown sequence --buildsystem=qmake_qt4 (options should not come before the sequence) | 10:44 |
| wgrant | Ah, other way around, then | 10:44 |
| drstikko | wgrant like this : --buildsystem=qmake_qt4 dh $@ ? | 10:47 |
| wgrant | dh $@ --buildsystem=qmake_qt4 | 10:47 |
| drstikko | wgrant: that worked better!! only error at the end: dh_usrlocal: debian/dporg/usr/local/bin/dporg is not a directory | 10:49 |
| drstikko | rmdir: failed to remove `debian/dporg/usr/local/bin': Directory not empty | 10:49 |
| drstikko | dh_usrlocal: rmdir debian/dporg/usr/local/bin returned exit code 1 | 10:49 |
| drstikko | dporg is my executable | 10:49 |
| wgrant | Your Makefile shouldn't be installing things into /usr/local. | 10:50 |
| wgrant | Packages aren't to contain anything in that subtree. | 10:50 |
| drstikko | wgrant: ok what location then? | 10:50 |
| wgrant | One would usually use /usr/bin etc. rather than /usr/local/bin. /usr/local is for non-packaged files. | 10:51 |
| drstikko | wgrant, that worked, I had to use sudo also I noticed. | 10:56 |
| cjwatson | You should never need to use sudo in packaging. | 10:57 |
| wgrant | drstikko: You must not use sudo in debian/rules | 10:57 |
| cjwatson | Sounds like you were trying to install into /usr/bin rather than debian/dporg/usr/bin ... | 10:57 |
| drstikko | wgrant, cjwatson, but dpkg-buildpackage -b gave me: rm: cannot remove `debian/dporg/DEBIAN/md5sums': Permission denied | 10:59 |
| drstikko | and I whole bunch of those | 10:59 |
| wgrant | drstikko: That's what will happen if you run bits of it with sudo. | 11:02 |
| wgrant | Because root will have created things. | 11:02 |
| wgrant | Perhaps 'sudo debian/rules clean' once to get rid of the root-owned files. | 11:02 |
| drstikko | wgrant, clwatson ;) yes noticed that!! Fixed now, thanks works great! | 11:03 |
| cjwatson | In future use fakeroot rather than sudo. | 11:07 |
| === bencer is now known as jsalamero | ||
| === Ursinha_ is now known as Ursinha | ||
| === jsalamero is now known as bencer | ||
| sreedevi | Hello, I am trying to fix one minor bug in launchpad. I pushed my committed branch, Could you please verify my fix, This is my first bug, Please help me | 14:01 |
| sreedevi | My bug link is:https://bugs.launchpad.net/ubuntu/+source/secure-delete/+bug/1245415 | 14:01 |
| ubot5 | Ubuntu bug 1245415 in secure-delete (Ubuntu) "Spelling mistake in smem's page" [Undecided,In progress] | 14:01 |
| czajkowski | sreedevi: the folks on LP are in AU timezones | 14:01 |
| czajkowski | you may not get a reply here | 14:01 |
| czajkowski | have you thought of posting it to the mailing list for feedback/.review? | 14:02 |
| cjwatson | That isn't a fix in Launchpad - you should look in Ubuntu channels for review, not here | 14:02 |
| sreedevi | czajkowski: Whom should I subscribe in launchpad to get my fix verified, Can you please help me with this | 14:03 |
| czajkowski | cjwatson: morning | 14:03 |
| cjwatson | You'd only look for reviewers here (or indeed #launchpad-dev) if it were a fix to Launchpad itself, rather than to a project hosted on Launchapd | 14:03 |
| cjwatson | sreedevi: https://wiki.ubuntu.com/SponsorshipProcess | 14:03 |
| czajkowski | ah I didnt check to see if it wasn't lp realted given the user was posting in here | 14:03 |
| cjwatson | czajkowski: morning, or something | 14:04 |
| czajkowski | cjwatson: so messed up on times :/ going to be a long week | 14:04 |
| sreedevi | Thank you | 14:05 |
| adam345 | maria mercedes | 14:18 |
| === matsubara is now known as matsubara-lunch | ||
| cgregan1 | Hello Launchpad team. I moved an internal Canonical Project (checkbox-ihv-ng) over to private license so the bugs can be made private. But now it seems I need to "buy" a commercial license. Who do I need to send some lp karma bucks over to for that? TA | 15:11 |
| czajkowski | cgregan1: just mail commercial@lp.net and they can apply the commerical voodoo needed :) | 15:12 |
| cgregan1 | awesome..thanks czajkowski | 15:12 |
| czajkowski | np | 15:12 |
| drstikko | Hi my recipe contains : # bzr-builder format 0.3 deb-version {debupstream}-0~{revno} and results in dporg - 0.3-15-0~21~ubuntu12.04.1 I was told this is not a neat version number. What would be the right line in the recipe or do I have to change the control file? | 16:00 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === matsubara-lunch is now known as matsubara | ||
| drstikko | Hi my recipe contains : # bzr-builder format 0.3 deb-version {debupstream}-0~{revno} and results in dporg - 0.3-15-0~21~ubuntu12.04.1 I was told this is not a neat version number. What would be the right line in the recipe or do I have to change the control file? | 17:35 |
| dobey | drstikko: #ubuntu-packaging is the right place to ask, but {debupstream}+r{revno}-{revno:packaging} (with packaging in a different branch), is what i usually use. you need to not have multiple '-' characters in your version string. it's a bit weird that one is included in the {debupstream} portion there. | 17:44 |
| === Ursinha-afk is now known as Ursinha | ||
| JonnyJD_ | drstikko: you can replace the first - with ~ in debian/changelog | 19:46 |
| drstikko | JonnyJD_: for me the format is not clear, I think fiirst I need to see some examples | 19:55 |
| JonnyJD_ | the format in the recipe is fine, but your upstream version doesn't seem to be | 19:57 |
| drstikko | I think that's the part I don't get | 20:02 |
| drstikko | how do I change upstream info? | 20:02 |
| drstikko | I like to have it like dporg_0.3-24 where 24 is the revision number | 20:03 |
| drstikko | or is that crappy? | 20:03 |
| JonnyJD_ | drstikko: upstream shouldn't have a revision number | 20:05 |
| JonnyJD_ | if that is the upstream build revison, then remove it | 20:05 |
| JonnyJD_ | if this is part of the actual (source) version, change it so no - is used anymore | 20:06 |
| dobey | that's not really how the revision number should be, unless the only revissions in the branch, are packaging (but even so, may cause problems to use it that way) | 20:09 |
| drstikko | first of all, I just wrote a tool and like to share it with launchpad, is that what you call upstream? (sorry new to this). I think it is not mature enough to give it a 1.x number. So that's why I decided to choose 0.3 at the moment. I thought minor changes maybe could be after 0.3- so for example 0.3-24. How would one do this normally? | 20:13 |
| JonnyJD_ | drstikko: have a look at http://semver.org | 20:16 |
| JonnyJD_ | in short: you should use 0.3.24 as a version number | 20:16 |
| JonnyJD_ | drstikko: and since you are also respsonsible for upstream: keep that separated | 20:21 |
| JonnyJD_ | drstikko: other people should be able to package your stuff easily, too | 20:22 |
| JonnyJD_ | drstikko: the workflow is like that: with your "upstream hat" you release 0.3.54. Then with your "packager hat" you create packaging starting with -0drstikko1 | 20:23 |
| JonnyJD_ | drstikko: if you change something in the packaging you release with 0drstikko2 (source didn't change, but packaging did) | 20:23 |
| drstikko | okay the 0.3.24 I could follow ;) | 20:24 |
| JonnyJD_ | drstikko: that -0 is because there is no official Debian package you are changing and drstikko because this is your packaging (-0ubuntu1 is used for official ubuntu packaging afaik) | 20:24 |
| drstikko | and the I start a new branch wit 0.4 right? | 20:25 |
| JonnyJD_ | if that is a new branch or the same branch is up to you | 20:25 |
| drstikko | ok | 20:25 |
| JonnyJD_ | but if you add things to the "API", as in "change how the tool can be used" than go to 0.4 | 20:25 |
| JonnyJD_ | if everything gets "stable" then you should relese 1.0 and then 1.0.x for small changes and 1.1 for backwards compatible features | 20:26 |
| JonnyJD_ | 2.0 is then for backwards incompatible changes | 20:26 |
| drstikko | yes ok, so complete name would be dporg_0.3-25-0drstikko1 ? | 20:27 |
| JonnyJD_ | drstikko: dporg-0.3.25-0drstikko1 | 20:28 |
| JonnyJD_ | but you only put 0.3.25-0drstikko1 in debian/changelog | 20:28 |
| JonnyJD_ | you don't have to do the -0drstikko1 stuff, (you can also just do -1), but this helps if ubuntu or debian build packages later on | 20:29 |
| JonnyJD_ | (official non-ppa packages) | 20:29 |
| drstikko | ok. so you just manually add the stuff to the changelog? I thought it has to be automated | 20:30 |
| JonnyJD_ | drstikko: what you might be referring to is building from revisions, not from version tags? | 20:30 |
| drstikko | I think, but don't know for shure | 20:31 |
| JonnyJD_ | when you build from revisions, then you just leave your last stable release in debian/changelog and note in the recipe that you do git packages or similar | 20:31 |
| drstikko | what do you mean by that? | 20:32 |
| JonnyJD_ | drstikko: an example for stable builds: https://code.launchpad.net/~musicbrainz-developers/+recipe/python-discid | 20:32 |
| JonnyJD_ | drstikko: and for daily git builds: https://code.launchpad.net/~musicbrainz-developers/+recipe/python-discid-daily | 20:33 |
| JonnyJD_ | basically you add +git<revno> after {debupstream} and then -0drstikko{revno:packaging} | 20:34 |
| JonnyJD_ | this makes sure that different git/bzr revisions get a new "source version" and whenever packaging changes, the build revision also changes | 20:35 |
| drstikko | I think I was trying to link revision numbers with version numbers. But I think version numbers you 'just' decide and revisons of course increment automatically | 20:37 |
| JonnyJD_ | drstikko: if your "debian" folder is actually part of the source, then you don't need {revno:packaging} since package changes are also code changes | 20:37 |
| JonnyJD_ | I want to note that having "debian" part of the "upstream" source isn't the best thing to do, but it works | 20:37 |
| JonnyJD_ | basically because you should separte you with the "upstream hat" and "packaging hat", other packagers might not want to use your "debian" folder | 20:38 |
| drstikko | ok. will try to change that later. First want to tackle this version stuff ;) | 20:39 |
| JonnyJD_ | and yes, you decide version numbers with your "upstream hat" and packaging revisions with your "packager hat". | 20:39 |
| JonnyJD_ | you would now just have in your debian/changelog 0.3.24-0drstikko1 now and {debupstream}+bzr{revno}-0drstikko1 in your recipe | 20:41 |
| drstikko | ok, thnx JonnyJD_ I will first try to make a nice versionned build. | 20:41 |
| drstikko | and the fix this debian folder issue, but where do I put it? Or is that a long story? | 20:42 |
| JonnyJD_ | drstikko: you can have a different bzr repo just with "debian" and "nest" it in the recipe | 20:43 |
| drstikko | ah ok | 20:43 |
| JonnyJD_ | you can also remove it from "upstream" repo, but include both in a launchpad repo (you still need to use nesting for bzr/git builds though) | 20:44 |
| JonnyJD_ | and every time you make a stable releas, you merge upstream source in a launchpad repo where you also have a "debian" folder | 20:45 |
| JonnyJD_ | there are multiple options, but your "real" upstream repository shouldn't include it | 20:45 |
| drstikko | ok, thnx. I think I first need to clean the ppa and remove the old build if possible | 20:46 |
| drstikko | JonnyJD: how to remove the builds? | 21:15 |
| JonnyJD_ | drstikko: you can only request deleting them, but your new builds will supercede the old ones anyways, I think | 21:22 |
| TheLordOfTime | they should if they have higher version numbers | 21:22 |
| dobey | you can't upload things with lower version numbers | 21:22 |
| TheLordOfTime | at least, as I understand the system | 21:22 |
| TheLordOfTime | mhm | 21:22 |
| JonnyJD_ | there is some link on the upper right on your PPA for deletion, if you want to do it anyways | 21:23 |
| dobey | regardless of if you delete them | 21:23 |
| dobey | deleting them won't let you upload older versions | 21:23 |
| JonnyJD_ | I remember the problem is that that is only a deletion request | 21:23 |
| JonnyJD_ | so they are still there. And I am not sure if they are deleted at all if they were built successfully and published once | 21:24 |
| dobey | it's a request because it's a cron job that does the deletion | 21:25 |
| dobey | but it only deletes the files on disk. it doesn't delete the version information from the database | 21:25 |
| JonnyJD_ | ah okay | 21:25 |
| drstikko | I just want to keep the build page clean from the moment my versionning is allright | 21:26 |
| TheLordOfTime | i think the "Builds" list/page will still remain filled with the old data? | 21:26 |
| TheLordOfTime | dobey: ^ | 21:26 |
| JonnyJD_ | drstikko: only the latest build shows anyways (except you explicitely show the others) | 21:26 |
| JonnyJD_ | and the build page for a recipe only lists the last 5 builds anyways | 21:27 |
| drstikko | ok, thnx | 21:27 |
| dobey | TheLordOfTime: yes, though the +packages listing won't be | 21:34 |
| TheLordOfTime | right | 21:34 |
| === Ursinha-afk is now known as Ursinha | ||
| drstikko | can anyone advise me what to do with this above 12.04 ubuntu has libpoppler-qt4-4, but 10.04-12.04 have libpoppler-qt4-3. Is there a way to add this in the control file? | 22:22 |
| drstikko | because my tool depends on it | 22:22 |
| dobey | you don't. you just build-depends on libpoppler-qt4-dev and use ${shlibs:Depends} for the binary packages | 22:33 |
| dobey | and like i said earlier, #ubuntu-packaging is a better place to ask about packaging questions | 22:34 |
| dobey | this isn't the right place for it | 22:34 |
| drstikko | dobey: well I thought maybe the launchpad build system had something to do with it | 22:38 |
| dobey | no, it doesn't. :) | 22:38 |
| === Ursinha-afk is now known as Ursinha | ||
| paultag | Any Soyuz-ers here? | 22:47 |
| paultag | If so, I'm wondering how Soyuz handles arch:all package creation - do all arches build arch:all debs and push up where the archive ignores second pushes or does it do an indep build first then do archful builds | 22:48 |
| tsimpson | afaik, i386 buildds build them | 22:54 |
| paultag | oh I see. | 22:54 |
| paultag | how does it handle stuff like some wireless firmware that needs to build on arm (even though one can install it anywhere) | 22:54 |
| tsimpson | I have no clue about that | 22:55 |
| paultag | ack | 22:55 |
| paultag | tsimpson: thanks for your help :) | 22:55 |
| tsimpson | sure | 22:56 |
| maxb | paultag: afaik, the answer is that it doesn't handle that | 22:57 |
| paultag | maxb: hunh. | 22:57 |
| wgrant | paultag: There's only a couple of arch-indep packages that need to be built on a particular arch. | 23:15 |
| wgrant | paultag: Launchpad doesn't handle them today. There's been discussion for years in Ubuntu and Debian about a field to define which architecture they should build on, but nothing's ever enventuated. | 23:16 |
| paultag | wgrant: yeah, I recall those, I was pondering how to do this in dak (as well as some QA tooling I have) | 23:17 |
| wgrant | paultag: Probably worth reviving such discussions now that Debian has a good reason for it too :) | 23:18 |
| paultag | wgrant: totes :) | 23:19 |
| wgrant | https://bugs.launchpad.net/launchpad/+bug/217427 | 23:19 |
| ubot5 | Ubuntu bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] | 23:20 |
| paultag | wgrant: +subscribed, thanks | 23:21 |
| wgrant | paultag: It's absolutely trivial to implement for us, we really just need to agree on a syntax. | 23:21 |
| paultag | totally | 23:21 |
| czajkowski | aloha | 23:34 |
| paultag | czajkowski: yo! | 23:34 |
| czajkowski | paultag: hey | 23:35 |
| paultag | yo! | 23:39 |
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!