On Tue, Jul 11, 2017 at 00:31:32 +0300, Elan Ruusamäe wrote:
> (caja:27619): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x
> and GTK+ 3 in the same process is not supported
ldd -v
objdump -x | grep NEEDED
would help you to track what dependency fetches different library SOVER.
--
On Mon, 10 Jul 2017, Jakub Bogusz wrote:
> On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote:
> > On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan Rękorajski wrote:
> >
> > > If you want me to keep this commit and directory then follow up by:
> > >
> > > a) updating rpm macros
> >
> >
[~] ➔ caja .
(caja:27619): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x
and GTK+ 3 in the same process is not supported
Trace/breakpoint trap
[~] ➔ rpm -q caja
caja-1.16.1-1.x86_64
[~] ➔
--
glen
___
pld-devel-en mailing list
On Mon, Jul 10, 2017 at 17:35:26 +0200, Jakub Bogusz wrote:
> Note that there are some inter-package consistency requirements.
>
> And just like some packages having hardcoded /usr/libexec, and "require
> hackery" to use libdir subdirectory, the others have hardcoded /usr/lib**
> for this
On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote:
> On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan Rękorajski wrote:
>
> > If you want me to keep this commit and directory then follow up by:
> >
> > a) updating rpm macros
>
> Yes, I was considering this point. Just wondering, what would
On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan Rękorajski wrote:
> If you want me to keep this commit and directory then follow up by:
>
> a) updating rpm macros
Yes, I was considering this point. Just wondering, what would break (in
theory: nothing should) and how to perform the validation.
If you want me to keep this commit and directory then follow up by:
a) updating rpm macros
b) cleaning up packages that have libexec redefined directly in specs
FHS states this directory is optional, and I do not care at all what GNU
shamans think. This is not GNU/PLD, just PLD.
On Thu, 06 Jul