[00:21] the upstream config.guess and config.status obviously change whenever I build the package... debuild complains the next time I try to build... why aren't these changes ignored? did I forget something? [00:24] why should the be ignored? if you want something that gets generated to be ignored, delete it in clean [00:24] but it's in the orig tarball [00:24] or was it? hrm.. [00:24] deleted files are ignored [00:25] ahh [00:25] ok [00:41] hrm... the upstream code isn't finding -ldevmapper, I think because the library is actually named libdevmapper.so.1.02.1... how do I fix this? [00:55] no, that's not it.. hrm.... [01:10] AHA! transitory linking error! [01:10] darn new gcc behavior === sagaci_ is now known as sagaci [04:32] is there a way to force debuild to use a specific PGP key ID, assuming i have more than one PGP key available? === Resistance is now known as EvilResistance [05:02] EvilResistance: you can pass the key id to debuild with -k [05:03] thanks [05:48] anyone here know if its possible to get a specific upload to a PPA reversed? i accidentially entered the wrong upload destination in dput :/ [05:48] (on LP. i posted in #launchpad, but nothing) [05:57] ...reversed? [05:57] broder: i accidentially uploaded my ZNC code (the one i modified to remove certain features and add others) to my backports-staging PPA [05:58] it bumped the version number up [05:58] just delete the source and binaries [05:58] when the upload was destined to its own specific PPA [05:58] i think if you do that and wait long enough you can upload the same version again [05:58] broder: that'd delete the entire package, no? [05:58] but not positive [05:58] i.e. all versions [05:58] i dont even see the version that actually *built* on the archive's lkist [05:58] list* [05:59] (I cancelled the pending builds though) [05:59] not sure then [06:00] yeah if i have to i'll post a question against launchpad itself to see if it can be done [06:01] it might need some lp-admin magic to fix it :/ [06:03] ugh and now dput won't upload the source tar [06:03] er [06:03] the orig.tar.gz [06:04] so i cant put it into the right ppa === Elbrus_ is now known as Elbrus === yofel_ is now known as yofel [10:52] hello guys [11:00] i have this .desktop file, http://zlin.dk/p/?NDE4M2M0, but after i install the .deb package . i don't see the application in the menu [11:00] i use KDE in Ubuntu oneiric [13:51] is it installed correctly? [13:59] Hi I uploaded a package into a PPA, and shortly afterwards, I uploaded an updated package into that PPA, but it did not superseed the first uploaded package. I am aware that it is a problem with my versioning scheme: 0.96.1+bzr536-0ppa~oneiric1 and 0.96.1+bzr542-0ppa~oneiric1. Could anybody please give me an advice about how to do the versioning? Here is the situation: The ubuntu repositories are shipping 0.96.1-0ubuntu1. The version that I am publishing [13:59] is a snapshot of the 0.96 branch with a preview of 0.96.2. So, I want my snapshots to superseed 0.96.1 but it should be superseeded by 0.96.2. Thanks in advance for any advice. [14:02] What about 0.96.1-bzr542~ppa~oneiric1? Would that work? [14:03] 0.96.1+bzr536-0ppa~oneiric1 is smaller than 0.96.1+bzr542-0ppa~oneiric1, it should ahve superseeded [14:07] jtaylor: Here is the PPA: https://launchpad.net/~onboard/+archive/snapshots [14:08] Do you think that I have stumbled on a bug in launchpad? [14:09] oneiric has a package with precise as suffix, thats not so good [14:10] bzr542~ppa~oneiric1 will not superseed bzr542~ppa~precise1 [14:18] jtaylor: I think that I know now what happened: the versioning scheme is correct if I understood you correctly. I surely made a mistake while publishing the packages, because my intention was to publish the packages for the oneiric and the precise distributions. Thanks for your help. [14:18] dpkg --compare-versions is useful for such things [14:46] jtaylor: This is what I did wrong: 0.96.1+bzr542-0ppa~precise1 was intended for the precise distribution, but I forgot to replace oneiric with precise in the debian/changelog and it superseeded 0.96.1+bzr542-0ppa~oneiric1 in the oneiric repo of the PPA. Thanks for the command to compare the versions. I get warnings if I use it on my versioning scheme. Could you please tell me whether the problem is with my versioning scheme or with my usage of the comm [14:46] and? [14:47] dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1_amd64.deb' gt '0.96.1+bzr542-0ppa~precise1_amd64.deb' [14:47] what warning [14:47] dpkg: warning: version '0.96.1+bzr536-0ppa~oneiric1_amd64.deb' has bad syntax: invalid character in revision number [14:47] dpkg: warning: version '0.96.1+bzr542-0ppa~precise1_amd64.deb' has bad syntax: invalid character in revision number [14:47] it only takes version number [14:47] not the whole filename [14:47] = the part before the _ [14:47] gilir: hi, do you want to request a sync for nautilus-image-converter or are you ok with me doing it? It build fine in precise, buildlog at http://people.ubuntu.com/~amoog/nautilus-image-converter_0.3.1~git20110416-1-amd64-20111210-1540.gz [14:49] dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1' gt '0.96.1+bzr542-0ppa~precise1' [14:49] does not output anything. Should it not tell me that it is wrong? [14:49] You should check the returncode [14:50] put an && echo "yes" behind it [14:50] if you see it the statement is true [14:52] dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1' gt '0.96.1+bzr542-0ppa~precise1' && echo "yes" [14:52] still no output [14:52] as its false [14:52] 536 < 542 [14:56] frafu: if you want some output: dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1' gt '0.96.1+bzr542-0ppa~precise1' && echo "true" || echo "false" [14:56] Ampelbein, bug 883071 needs to be fixed first before we can sync again [14:56] jtaylor: thanks; I understand now: the echo is only executed if the previous statement was true. [14:56] Launchpad bug 883071 in nautilus-image-converter (Ubuntu) "Please remove nautilus-image-converter from sync blacklist" [Undecided,New] https://launchpad.net/bugs/883071 [14:57] gilir: Oh, didn't see that. Does that mean that even manual sync wouldn't work? [14:58] Ampelbein: Thanks for the alternative method that gives an answer in both cases. [14:59] Ampelbein, only fakesync works, which is a waste of time considering the sync can be automatic when it will be removed from blacklist [14:59] ok [15:00] thanks for the info. [15:10] Does anybody know, whether there is a way to see how many times a package has been downloaded from a PPA? [15:10] frafu: can be done via launchpadlib [15:12] there is no direct display [15:12] bug 688141 [15:12] Launchpad bug 688141 in Launchpad itself "Show PPA download stats in the web UI" [Low,Triaged] https://launchpad.net/bugs/688141 [15:20] jtaylor: Could you please give me some details about how to use launchpadlib? Does it have to be through the means of an application or is there a more direct way? [15:21] Do python bindings exist? [15:21] it is a python library [15:22] frafu: https://help.launchpad.net/API [15:22] install lptools and ipython, start lp-shell [15:23] launchpad.me.ppas[0].getPublishedBinaries()[0].getDownloadCounts() [15:24] Great. :-) Thanks to both of you. [15:35] how does one go about fixing bugs in main packages? [15:35] via merge request? [15:37] jtaylor: there's nothing special about main [15:38] many desktop packages have their packaging in bzr under the desktop-team (although IIRC they may be using UDD now, or about to be using UDD) [15:38] jtaylor: the same way you fixed universe packages before you become MOTU [15:40] so a merge request/debdiff? [15:40] yes [16:28] a'noon [16:29] Hey Laney [16:30] eet eez cold [16:32] * nigelb waves from a comfortable 22 C. [16:36] hold me [16:57] yeah, a nice comfortable 20ish here too (touch wood it doesn't get too crazy hot next week) [16:57] jtaylor: congrats on MOTU! [16:57] Why so late :) [16:58] heh [17:03] nigelb: thx [18:45] can dh_makeshlibs actually operate on more than one package at a time? lvm2 is exporting DH_OPTIONS = -pliblvm2app$(LVM2APP_ABINAME) -pliblvm2cmd$(LVM2CMD_ABINAME) -pliblvm2-dev... and there are no .symbol files for any of those [18:54] does anybody object to multiarching openssl098? [18:54] (i have a patch) [18:59] are we intending to keep that for much longer? [19:01] it seems useful for 3rd party app compatibility [19:05] i guess cjwatson's description of it as a "compatibility" package had me thinking it wasn't intended to be just transitional [19:18] it looks like acroread may still link 0.9.8 [19:26] pypy does too [19:27] and you can't just ask people to rebuild that, it needs more than 4gb ram ^^ [19:27] I'm working at packaging that... [19:27] I heard, thats great [19:27] but it won't build on my machine any more (6G rab, built fine a month ago) [19:27] lol [19:28] have to use a 32bit chroot... [19:35] man pages should be in .manpages, not .install shouldn't they? [19:36] yes [19:40] * psusi bonks the debian lvm team [19:44] now if only I could figure out why the hell there are no symbols files for all but one of the libs in here [19:45] and dh_makeslibs on -c4 isn't complaining that it's found them either [19:49] because nobody wrote them? [19:56] then dh_makeshlibs should complain that it has found new symbols shouldn't it? [19:57] and fail the build since I set it to -c4 [19:57] until I add the new symbols [19:58] no symbols file doesn't mean there are new symbols [19:59] it means we don't know [19:59] right.. we don't know what was there, but now we're scanning the libs, and should find a bunch of syms and print the diff for me to patch into the .symbols file shouldn't it? [20:00] no, beacuse that would make for very messy build logs [20:00] it's not that hard to run dpkg-gensymbols yourself [20:01] are you saying no because there NO symbols file, as opposed to an empty .symbols file? [20:01] yes [20:01] because normally when it finds new symbols, it does print the diff [20:01] hrm... the man page for dpkg-gensymbols says if you use -c4, it should complain when new libs appear as well [20:02] of course, it would be lovely if everyobody used symbols files, but in many packages, they seem to not be worth the effort (or at least, people say that) [20:02] debian policy requires that you use them doesn't it? [20:04] no [20:06] hrm... let's see then... maybe I just need an LD_LIBRARY_PATH.... [20:06] so without them, then that just means packages built against the lib will always depend on exactly that version they were built with? [20:06] or newer? [20:07] yes [20:07] and you'll have no idea if you've broken ABI [20:07] (not that symbols files are foolproof, but a missing symbol is definitly an ABI break) [20:09] right [20:09] so debian policy doesn't require their use for public libraries? seems to defeat the purpose [20:10] what's wrong with them being optional? [20:10] lots of the debian policy is optional [20:13] damnit... what's wrong here? dpkg-shlibdeps is complaining that it can't find library liblvm2cmd.so.2.02 needed by debian/libdevmapper-event1.02.1/lib/libdevmapper-event-lvm2.so.2.02, and suggests using LD_LIBRARY_PATH if you want it to find a private lib.. [20:14] I added export LD_LIBRARY_PATH = debian/build/build_deb/tools to the rules file, which is where that lib can be found [20:20] whats the library doing in /lib? [20:21] and the ld path should point to debian/package-name/usr/lib/whatever [20:22] because it's a lib? [20:22] ah lvm ok then the place is probably ok [20:22] hrm... I pointed it to the build dir instead of the install dir... thought that would be better as it's there prior to install [20:23] shlibdeps runs after nstall [20:23] pointing it to something somewhere else just risks that you build a broken package [20:26] ok... pointed it to the install_deb/lib directory... it's still complaining it can't find it... hrm... [20:40] aha! the other target was needlessly including this one [20:46] ahh... their rules file doesn't call dh_installman === Elbrus_ is now known as Elbrus