[00:21] <psusi> 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] <tumbleweed> why should the be ignored? if you want something that gets generated to be ignored, delete it in clean
[00:24] <psusi> but it's in the orig tarball
[00:24] <psusi> or was it?  hrm..
[00:24] <tumbleweed> deleted files are ignored
[00:25] <psusi> ahh
[00:25] <psusi> ok
[00:41] <psusi> 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] <psusi> no, that's not it.. hrm....
[01:10] <psusi> AHA!  transitory linking error!
[01:10] <psusi> darn new gcc behavior
[04:32] <Resistance> is there a way to force debuild to use a specific PGP key ID, assuming i have more than one PGP key available?
[05:02] <ajmitch> EvilResistance: you can pass the key id to debuild with -k
[05:03] <EvilResistance> thanks
[05:48] <EvilResistance> 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] <EvilResistance> (on LP.  i posted in #launchpad, but nothing)
[05:57] <broder> ...reversed?
[05:57] <EvilResistance> 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] <EvilResistance> it bumped the version number up
[05:58] <broder> just delete the source and binaries
[05:58] <EvilResistance> when the upload was destined to its own specific PPA
[05:58] <broder> i think if you do that and wait long enough you can upload the same version again
[05:58] <EvilResistance> broder:  that'd delete the entire package, no?
[05:58] <broder> but not positive
[05:58] <EvilResistance> i.e. all versions
[05:58] <EvilResistance> i dont even see the version that actually *built* on the archive's lkist
[05:58] <EvilResistance> list*
[05:59] <EvilResistance> (I cancelled the pending builds though)
[05:59] <broder> not sure then
[06:00] <EvilResistance> yeah if i have to i'll post a question against launchpad itself to see if it can be done
[06:01] <EvilResistance> it might need some lp-admin magic to fix it :/
[06:03] <EvilResistance> ugh and now dput won't upload the source tar
[06:03] <EvilResistance> er
[06:03] <EvilResistance> the orig.tar.gz
[06:04] <EvilResistance> so i cant put it into the right ppa
[10:52] <paissad> hello guys
[11:00] <paissad> 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] <paissad> i use KDE in Ubuntu oneiric
[13:51] <jtaylor> is it installed correctly?
[13:59] <frafu> 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] <frafu>  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] <frafu> What about 0.96.1-bzr542~ppa~oneiric1? Would that work?
[14:03] <jtaylor> 0.96.1+bzr536-0ppa~oneiric1 is smaller than 0.96.1+bzr542-0ppa~oneiric1, it should ahve superseeded
[14:07] <frafu> jtaylor: Here is the PPA: https://launchpad.net/~onboard/+archive/snapshots
[14:08] <frafu> Do you think that I have stumbled on a bug in launchpad?
[14:09] <jtaylor> oneiric has a package with precise as suffix, thats not so good
[14:10] <jtaylor> bzr542~ppa~oneiric1 will not superseed bzr542~ppa~precise1
[14:18] <frafu> 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] <jtaylor> dpkg --compare-versions is useful for such things
[14:46] <frafu> 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] <frafu> and?
[14:47] <frafu> dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1_amd64.deb' gt '0.96.1+bzr542-0ppa~precise1_amd64.deb'
[14:47] <jtaylor> what warning
[14:47] <frafu> dpkg: warning: version '0.96.1+bzr536-0ppa~oneiric1_amd64.deb' has bad syntax: invalid character in revision number
[14:47] <frafu> dpkg: warning: version '0.96.1+bzr542-0ppa~precise1_amd64.deb' has bad syntax: invalid character in revision number
[14:47] <jtaylor> it only takes version number
[14:47] <jtaylor> not the whole filename
[14:47] <jtaylor> = the part before the _
[14:47] <Ampelbein> 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] <frafu> dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1' gt '0.96.1+bzr542-0ppa~precise1'
[14:49] <frafu> does not output anything. Should it not tell me that it is wrong?
[14:49] <Ampelbein> You should check the returncode
[14:50] <jtaylor> put an && echo "yes" behind it
[14:50] <jtaylor> if you see it the statement is true
[14:52] <frafu> dpkg --compare-versions '0.96.1+bzr536-0ppa~oneiric1' gt '0.96.1+bzr542-0ppa~precise1' && echo "yes"
[14:52] <frafu> still no output
[14:52] <jtaylor> as its false
[14:52] <jtaylor> 536 < 542
[14:56] <Ampelbein> 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] <gilir> Ampelbein, bug 883071 needs to be fixed first before we can sync again
[14:56] <frafu> jtaylor: thanks; I understand now: the echo is only executed if the previous statement was true.
[14:57] <Ampelbein> gilir: Oh, didn't see that. Does that mean that even manual sync wouldn't work?
[14:58] <frafu> Ampelbein: Thanks for the alternative method that gives an answer in both cases.
[14:59] <gilir> 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] <Ampelbein> ok
[15:00] <Ampelbein> thanks for the info.
[15:10] <frafu> Does anybody know, whether there is a way to see how many times a package has been downloaded from a PPA?
[15:10] <jtaylor> frafu: can be done via launchpadlib
[15:12] <jtaylor> there is no direct display
[15:12] <jtaylor> bug 688141
[15:20] <frafu> 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] <frafu> Do python bindings exist?
[15:21] <jtaylor> it is a python library
[15:22] <tumbleweed> frafu: https://help.launchpad.net/API
[15:22] <jtaylor> install lptools and ipython, start lp-shell
[15:23] <jtaylor> launchpad.me.ppas[0].getPublishedBinaries()[0].getDownloadCounts()
[15:24] <frafu> Great. :-) Thanks to both of you.
[15:35] <jtaylor> how does one go about fixing bugs in main packages?
[15:35] <jtaylor> via merge request?
[15:37] <tumbleweed> jtaylor: there's nothing special about main
[15:38] <tumbleweed> 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] <geser> jtaylor: the same way you fixed universe packages before you become MOTU
[15:40] <jtaylor> so a merge request/debdiff?
[15:40] <geser> yes
[16:28] <Laney> a'noon
[16:29] <nigelb> Hey Laney
[16:30] <Laney> eet eez cold
[16:32]  * nigelb waves from a comfortable 22 C.
[16:36] <Laney> hold me
[16:57] <tumbleweed> yeah, a nice comfortable 20ish here too (touch wood it doesn't get too crazy hot next week)
[16:57] <nigelb> jtaylor: congrats on MOTU!
[16:57] <nigelb> Why so late :)
[16:58] <tumbleweed> heh
[17:03] <jtaylor> nigelb: thx
[18:45] <psusi> 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] <broder> does anybody object to multiarching openssl098?
[18:54] <broder> (i have a patch)
[18:59] <Laney> are we intending to keep that for much longer?
[19:01] <broder> it seems useful for 3rd party app compatibility
[19:05] <broder> i guess cjwatson's description of it as a "compatibility" package had me thinking it wasn't intended to be just transitional
[19:18] <broder> it looks like acroread may still link 0.9.8
[19:26] <jtaylor> pypy does too
[19:27] <jtaylor> and you can't just ask people to rebuild that, it needs more than 4gb ram ^^
[19:27] <tumbleweed> I'm working at packaging that...
[19:27] <jtaylor> I heard, thats great
[19:27] <tumbleweed> but it won't build on my machine any more (6G rab, built fine a month ago)
[19:27] <jtaylor> lol
[19:28] <tumbleweed> have to use a 32bit chroot...
[19:35] <psusi> man pages should be in .manpages, not .install shouldn't they?
[19:36] <jtaylor> yes
[19:40]  * psusi bonks the debian lvm team
[19:44] <psusi> 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] <psusi> and dh_makeslibs on -c4 isn't complaining that it's found them either
[19:49] <tumbleweed> because nobody wrote them?
[19:56] <psusi> then dh_makeshlibs should complain that it has found new symbols shouldn't it?
[19:57] <psusi> and fail the build since I set it to -c4
[19:57] <psusi> until I add the new symbols
[19:58] <tumbleweed> no symbols file doesn't mean there are new symbols
[19:59] <tumbleweed> it means we don't know
[19:59] <psusi> 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] <tumbleweed> no, beacuse that would make for very messy build logs
[20:00] <tumbleweed> it's not that hard to run dpkg-gensymbols yourself
[20:01] <psusi> are you saying no because there NO symbols file, as opposed to an empty .symbols file?
[20:01] <tumbleweed> yes
[20:01] <psusi> because normally when it finds new symbols, it does print the diff
[20:01] <psusi> hrm... the man page for dpkg-gensymbols says if you use -c4, it should complain when new libs appear as well
[20:02] <tumbleweed> 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] <psusi> debian policy requires that you use them doesn't it?
[20:04] <tumbleweed> no
[20:06] <psusi> hrm... let's see then... maybe I just need an LD_LIBRARY_PATH....
[20:06] <psusi> 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] <psusi> or newer?
[20:07] <tumbleweed> yes
[20:07] <tumbleweed> and you'll have no idea if you've broken ABI
[20:07] <tumbleweed> (not that symbols files are foolproof, but a missing symbol is definitly an ABI break)
[20:09] <psusi> right
[20:09] <psusi> so debian policy doesn't require their use for public libraries?  seems to defeat the purpose
[20:10] <tumbleweed> what's wrong with them being optional?
[20:10] <tumbleweed> lots of the debian policy is optional
[20:13] <psusi> 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] <psusi> 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] <jtaylor> whats the library doing in /lib?
[20:21] <jtaylor> and the ld path should point to debian/package-name/usr/lib/whatever
[20:22] <psusi> because it's a lib?
[20:22] <jtaylor> ah lvm ok then the place is probably ok
[20:22] <psusi> 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] <jtaylor> shlibdeps runs after nstall
[20:23] <jtaylor> pointing it to something somewhere else just risks that you build a broken package
[20:26] <psusi> ok... pointed it to the install_deb/lib directory... it's still complaining it can't find it... hrm...
[20:40] <psusi> aha!  the other target was needlessly including this one
[20:46] <psusi> ahh... their rules file doesn't call dh_installman