Adding a minilzo shared lib is fine by me, here is a proposed new version with
minilzo sub-package, can someone check this works as intended?

http://people.atrpms.net/~hdegoede/lzo-2.02-5.fc9.src.rpm
http://people.atrpms.net/~hdegoede/lzo.spec

lzo-2.02-5.fc9 works fine for me

(In reply to comment #2)
> lzo-2.02-5.fc9 works fine for me

As in you build a libvncserver using this minilzo instead of the included one,
and that works, or ... ?

Rex, can you check and reply to comment #3, please?

ping Rex
ping Steve

sorry, busy, plate overfull atm (f9/kde4 fun and all).  I'll have to (re)visit
this when things settle down a bit.

Created attachment 302058 [details]
new spec

Created attachment 302060 [details]
patch which removes references to minilzo from Makefile.*

Created attachment 302061 [details]
log for failed mock build

I've tried to use Hans's minilzo package (from comment #1) instead of the
internal copy of minilzo, but I had no success so far.
If someone more experienced can lend a hand, please do.
I have attached the new spec, the patch which removes references to minilzo from
Makefile.* (I might have been wrong here..., my autofoo skills are nil ) and the
log of the failed build.

I kind of fixed it (it builds, but it's ugly as hell).  Revised spec attached.

Created attachment 302074 [details]
revised spec -- explicitely adds libminilzo to %make

Retested: lzo-devel can be ditched from the BR; lzo-minilzo is enough for a mock
build

(In reply to comment #13)
> Retested: lzo-devel can be ditched from the BR; lzo-minilzo is enough for a mock
> build

That doesn't sound right, because then you don't have the .so symlink to link
to, nor the headers to include, so this sounds like you're still building
against the included copy.

Try "rm -fr <includeded-copy>" in %prep, that always helps to ensure you are
really using the system version.

Mkey, so Hans was right. The bundled minilzo was still used. I've nuked it with
find -exec rm -f and patched the sources to use #include <minilzo.h> instead of
#include "minilzo.h"
The good part is that the package now builds.
The bad part[s] are
- I had to add /usr/include/lzo and -Llibminilzo.so to the %make line, otherwise
neither the includes not the lib are seen/used (and build freakes out with nasty
'minilzo.h file not found' or 'symbol <smtg-related-to-compress>' errors)
- the binary rpms do not seem to have a dependency on minilzo (or lzo)

I've uploaded to http://wolfy.fedorapeople.org/x11vnc/ the patch, the new spec
and the rpms; I am in dark now so a helping hand would be useful.

(In reply to comment #15)


> - the binary rpms do not seem to have a dependency on minilzo (or lzo)
> 

Thats bad, the should depend upon libminilzo.so.0

I know, that's what puzzles me. It does not build unless I use 
   make CFLAGS="$RPM_OPT_FLAGS %{_libdir}/libminilzo.so.0 -I %{_includedir}/lzo"
but (kind of obviously in fact ) rpmbuild does not find any dependency on lzo

When I tried
   make CFLAGS="$RPM_OPT_FLAGS -l%{_libdir}/libminilzo.so.0 -I %{_includedir}/lzo".
(thus notifying that libminilzo.so is a library) build failed with:

make[2]: Entering directory
`/builddir/build/BUILD/LibVNCServer-0.9.1/client_examples'
if gcc -DHAVE_CONFIG_H -I. -I. -I..    -I .. -g -Wall -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-prote
ctor --param=ssp-buffer-size=4 -m64 -mtune=generic -l/usr/lib64/libminilzo.so.0
-I /usr/include/lzo -MT ppmtest.o -MD -MP -
MF ".deps/ppmtest.Tpo" -c -o ppmtest.o ppmtest.c; \
        then mv -f ".deps/ppmtest.Tpo" ".deps/ppmtest.Po"; else rm -f
".deps/ppmtest.Tpo"; exit 1; fi
make[2]: *** No rule to make target `../libvncclient/libvncclient.la', needed by
`ppmtest'.  Stop.
make[2]: *** Waiting for unfinished jobs....
ppmtest.c: In function 'SaveFramebufferAsPPM':
ppmtest.c:43: warning: pointer targets in initialization differ in signedness
make[2]: Leaving directory
`/builddir/build/BUILD/LibVNCServer-0.9.1/client_examples'

You should be specifying just "-lminilzo" and not as CFLAGs but as LDFLAGS /
LIBS argument

Thanks Hans, that was it.
Even I still wonder why are CFLAGS=-I/usr/include/lzo and LDFLAGS=-lminilzo
needed., I have uploaded to http://wolfy.fedorapeople.org/x11vnc/ the libvnc*
related source stuff (patch, spec, src.rpm).
Since I might have missed something, I would appreciate a critical eye over 
  http://wolfy.fedorapeople.org/x11vnc/libvncserver.spec
(and over all the libvncserver related files from the above mentioned URL)

Anyway, Hans, could you please update lzo in rawhide ? AFAICS, packages from #1
seem OK.

Assuming my patch is correct, libvncserver should also be updated (Rex, if this
is OK with you I can do it, I've noticed that cvs access is open)

(In reply to comment #19)
> Thanks Hans, that was it.
> Even I still wonder why are CFLAGS=-I/usr/include/lzo and LDFLAGS=-lminilzo
> needed.

Thats normal when you manually modify a package to build against a system
version of some lib.

> Anyway, Hans, could you please update lzo in rawhide ? AFAICS, packages from #1
> seem OK.
> 

Its building for rawhide inclusion now, but won't show up there until after the
freeze, if you want a fixed version of vncserver to be included in F-9, someone
should mail rel-eng to ask them to tag the new lzo for F-9 inclusion.

> Rex, if this is OK with you I can do it

go for it, but I don't think it's worth breaking f9 freeze for.  I'd like to see
a little more testing for this.

Understood. I will upload to CVS (for the case someone wants to use the modified
code) but I will postpone build till after F9 release.

sucessfully built in rawhide. thanks for support to all those involved.

libvncserver-devel still needs some work for other projects like x11vnc to build against. I patched up x11vnc to use a shared minilzo, but using the system libvncserver breaks the build.

Maybe it makes more sense to stick with a static build of minilzo? That was minilzo's purpose after all, and if a shared lib is desired it should probably be lzo and not minilzo.

See the stalled bug 439772, that would have made it into Fedora half a year ago if it were not for building against a shared minilzo both from x11vnc and libvncserver.

At any rate this package needs some adjustments to be able to build against libvncserver-devel. It is either sticking to shared minilzo and fixing *-devel or reversing the shared minilzo setup.

Note: this is about not sharing minilzo, but sharing libvncserver. The irony is that by over interpreting the guidelines this has made it actually more difficult to adhere to them. Upstream makes it easy to use static minilzo and shared libvncserver, we now have the opposite.

> libvncserver-devel still needs some work

details?

See the blocking bug for some. I managed to remove all traces of the internal minilzo from x11vnc only to find that libvncserver(-devel) would bring some back in.

But please take the bird's eye approach: Is it worth to work against upstream to create a maintenance issue for every minilzo consuming package there is out there? The idea with minilzo was to use it only as an internal copy. If one wants the shared lib one should use lzo directly. We are now bastardizing things, and by design lzo;s author may change minilzo's ABI at any time w/o any warning, as it was not intended to have one in the first place.

> See the blocking bug for some.

All I see is a single pkg not building, but no details how/why.  I was hoping to avoid having to grok build.log's.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

->rawhide, needs to be fixed there first.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 354753 [details]
x11vnc-0.9.8-use-system-minilzo.patch

I think in you you cut links to bundled minilzo (for insurance I also delete this files too), patch missed only part where system one com in.

Please see this patch from x11vnc current build. In it libvncserver built correctly with system (mini)lzo.

How difficult would it be to use lzo proper instead of the made-system-shared minilzo?

What reason again use static anything if it present in system already?

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Is it problem fixed in Fedora 14?

Yep,looks like we just forgot to close this out:

* Thu Apr 10 2008 Manuel Wolfshant <wolfy> 0.9.1-3
- do not use bundled copy of minilzo (#439979)