=== Keybuk_ is now known as Keybuk [14:05] hi all, is there some debhelper or cdbs thingie to install upstart jobs to the right place? [14:06] I could use install file, but I don't want to (not the right place in fact) [14:07] or, probably package.upstart will do the trick [14:14] rittyan: read the dh_installinit documentation [14:16] yup, found it already [14:16] thanks [22:53] Keybuk: for future reference, we have this policy: http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath [22:53] Keybuk: not that I have an opinion but its making libnih kinda annoying to package. [22:54] err, why? [22:54] (not why don't you like rpath, but why are you getting one?) [22:55] Keybuk: I didn't do anything interesting when I built it [22:55] wing-commander scott% objdump -x /lib/libnih.so | grep RPATH [22:55] zsh: done objdump -x /lib/libnih.so | [22:55] zsh: exit 1 grep RPATH [22:55] I have no rpath [22:55] Keybuk: its libnih-dbus and nih-dbus-tool which its finding them in [22:56] noep [22:56] wing-commander scott% objdump -x /usr/bin/nih-dbus-tool | egrep "NEEDED|RPATH" [22:56] NEEDED libnih.so.1 [22:56] NEEDED libexpat.so.1 [22:56] NEEDED libdbus-1.so.3 [22:56] NEEDED libpthread.so.0 [22:56] NEEDED libc.so.6 [22:56] wing-commander scott% [22:56] ERROR 0001: file '/usr/lib64/libnih-dbus.so.1.0.0' contains a standard rpath '/usr/lib64' in [/usr/lib64] [22:56] ERROR 0001: file '/usr/bin/nih-dbus-tool' contains a standard rpath '/usr/lib64' in [/usr/lib64] [22:57] oh [22:57] well [22:57] that's your busted distribution [22:57] don't think the template spec is doing anything beyond configure/make/make install [22:57] if you're going to invent things like /usr/lib64 you need to tell your dynamic linker about it, etc. [22:57] notting: ^^what is this shit? [22:57] context? [22:58] libtool only puts an rpath in if you install into a path it doesn't recognise as a system library path [22:58] usually it's libtool being shite [22:58] notting: is there a standard fix? [22:59] notting: hardly [22:59] if Fedora bothered to send patches upstream, you wouldn't have this problem ;) [22:59] even when I was libtool upstream, we patiently waited for Fedora/RH to submit http://cvs.fedoraproject.org/viewvc/devel/libtool/libtool-2.2.6a-rpath.patch?view=log [22:59] but nobody ever did [22:59] you were libtool upstream? i don't know whether to blame you or send booze [22:59] sadmac: you should be able to apply that patch to m4/libtool.m4 in libnih's tree [23:00] notting: once :) [23:00] sadmac: you'll need to re-run autoconf afterwards to regenerate configure [23:00] then it should not rpath lib64 [23:01] you can cheat and do 'make LIBTOOL=/usr/bin/libtool'. but that obviously can have version-skew [23:02] the page I linked recommends a couple of sed lines. I'm afraid... but it is policy... [23:02] you can [23:02] all of these are valid [23:02] but it's not _my_ problem ;) [23:02] Keybuk: my mistake [23:03] strictly speaking, of course, your policy is wrong [23:03] since /usr/lib64 is *not* a standard library directory [23:03] you should have rpaths for it [23:03] since otherwise libraries and binaries compiled on RH won't work on other distros ;P [23:03] the sed things don't work. [23:03] but I digress [23:03] makes the build choke [23:04] Keybuk: the compiler thinks it's standard [23:04] notting: only because you have a patch to your compiler [23:04] Keybuk: kernel32.dll doesn't work in ubuntu either :) distro-compatibility is a pipe dream. [23:04] sadmac: sure it does, apt-get install wine ;) [23:04] sadmac: is the sed for libtool 1.5 or 2.x ? [23:05] Keybuk: try libc.dylib :) [23:05] Keybuk: unspecified. [23:05] Keybuk: snippets floating in wikispace unknown and unloved [23:05] Keybuk: i could bring up the LSB stick, but, bleah. [23:07] but yes, the proper solution is to patch upstream libtool releases, get that in every distro, and make everyone redist their packages. wheee. [23:08] ugh. my apartment can be either 40 or 80 degrees. the thermostat ignores intermediate values. [23:08] notting: sure [23:16] damn it to hell. [23:16] rpmbuild is eating the error output of patch [23:20] oh. oh wow. that is unfortunate. [23:20] makes sense though [23:20] %prep doesn't define the patch macros at all. [23:21] no, this is %build hold on.. [23:30] I haven't built a new package in a while. [23:33] Fedora/RH could always switch to dpkg. [23:33] ion: coke, pepsi, whatever. [23:33] IMHO if the difference between your old package manager and your new one is any smaller than the difference between rpm and conary you're an idiot to switch [23:34] which is not to say you should switch to conary [23:34] Point is I can't in good faith support Jesse not seeing his kid for 2 months so we can switch to a /slightly better RPM/ [23:35] besides, the package manager I want to use I haven't written yet. [23:37] I was joking, of course. [23:39] ion: all in good fun :) [23:40] Keybuk: the pkgconfig stuff ended up in lib rather than lib64 too :( guess we didn't fix autoconf either. [23:44] Keybuk: ah, this one is your fault [23:47] why? [23:48] Keybuk: you defined pkgconfig's data path explicitly in Makefile.am [23:48] yes [23:48] if you put it in the wrong path, that's your fault :) [23:52] Keybuk: is there a separate list for libnih development now? [23:58] no [23:58] Keybuk: good. patch is on upstart-devel