[01:23] <darkxst> robert_ancell, hey what is happing with gnome-desktop now?
[02:14] <robert_ancell> darkxst, I'm going to patch u-c-c and u-g to not rely on those APIs so it should be upgradable
[02:32] <darkxst> robert_ancell, ok, what about upower, are you happy for the power plugin to be backported for u-s-d?
[02:33] <darkxst> it was quite a mess trying to cherry-pick the patches, since there has been quite some re-factoring at the same time.
[02:33] <robert_ancell> darkxst, I haven't been following the upower changes, but yes, I suspect we'll have to pick those changes up in u-s-d
[02:37] <darkxst> robert_ancell, yes, definitely required. So the options are really backport the power plugin or do a straight port rather than cherry-picking patches
[02:38] <darkxst> u-c-c is probably ok to cherry-pick patches, that was far less invasive on that side
=== thomasb9511|Away is now known as Guest26611
=== Guest26611 is now known as thomasb9511
=== thomasb9511 is now known as Guest93832
[08:05] <darkxst> ricotz, hey, do you know the right way to fix https://bugzilla.gnome.org/show_bug.cgi?id=733857?
[08:05] <ubot5> Gnome bug 733857 in General "rpath is being set on tracker libraries" [Normal,Needinfo]
[08:07] <darkxst> I suppose could link with "--enable-new-dtags" would be an improvement?
[08:42] <darkxst> ricotz or should the apps dl'opening the libs export LD_LIBRARY_PATH
[09:32] <ricotz> darkxst, imho this internal "automatic" rpath setting caused by relying on a personal private library should not be an issue
[09:33] <ricotz> darkxst, tracker is not setting this in some manual way this is all libtool
[09:33] <ricotz> i don't know how to use a private library in another way
[09:34] <ricotz> --enable-new-dtags would additionally add a run-path field, i would not call this better
[09:37] <ricotz> (of course static linking would work around this problem which should not be an option though)
[09:58] <darkxst> ricotz, but RUNPATH doesnt override the LD_LIBRARY flags
[10:00] <darkxst> that is much better than setting RPATH
[10:01] <darkxst> though not sure what other apps do, gjs apps I think set LD_LIBRARY_FLAGS at runtime
[10:02] <darkxst> and besides didrocks doesnt seem to keen on the whole RPATH thing
[10:15] <ricotz> e.g. /usr/bin/unity-scope-loader
[10:16] <ricotz> is there a LDFLAGS equivalent to "--enable-new-dtags" ?
[10:18] <ricotz> i havent seen new-dtags passed in any package yet, wouldn't this be something for the toolchain defaults
[10:20] <darkxst> ricotz, there are a few in debian, but didnt see anything gnome doing it
[10:38] <darkxst> and some packages use chrpath to strip the RPATH, but pretty sure that by itself will break anything that is dlopen'ed
[10:39] <ricotz> darkxst, i see, so tracker should add new-dtags unconditionally or we will patch it in
[10:40] <darkxst> ricotz, I guess it should be done upstream? fedora has much the same policy on rpath's even if its not quite as strict
[10:40] <darkxst> and it cause problems all around, for example unit tests running from the build tree will use installed libs rather than in-tree libs due to the rpath
[10:40] <ricotz> yes, given the time this flag is around it can be done without checking i guess
[10:41] <darkxst> I don't think anyone likes RPATH, except upstream libtool?
[10:41] <ricotz> darkxst, that is not true while using the libtool wrappers
[10:42] <ricotz> anyhow just checked the dtags flag and it replaces the rpath with runpath as expected
[10:43] <darkxst> ricotz, it didnt look like tracker uses wrappers though?
[10:43] <darkxst> but I am no guru on build system stuff ;(
[10:43] <ricotz> the *.la files are the wrappers
[10:44] <ricotz> (which are not installed anymore for the reason that they are messing with the paths)
[10:45] <darkxst> ricotz, are you sure? I know some (or many) have fake binaries that are libtool wrappers pointing to a lt-bin
[10:46] <ricotz> yes those are the executeable wrappers
[10:46] <ricotz> *.la the library ones
[10:46] <darkxst> ricotz, ok
[15:26] <jmis> Is anyone else having trouble with the 14.04 64bit torrent? I'm getting Tracker Error: Requested download is not authorized for use with this tracker. 13.10 works though.
=== swiss_ is now known as swiss
[16:52] <ceed^> jmis, works fine here. Just did a dl and install.
[17:42] <jmis> @ceed - using the torrent? I just wanted to verify the torrent works
[17:42] <meetingology> jmis: Error: "ceed" is not a valid command.
[17:43] <jmis> and sorry if this isn't the proper place for these questions- just wanted to make sure if there was a problem with the torrent for whatever reason someone gets notified XD
[17:52] <ceed^> jmis, yes I was using the torrent.
[17:59] <jmis> ok thanks. I'll try another torrent client, and another computer when I get home.
=== hyperdrive is now known as hdrv