Sorry for the top-post, but github generates the diff from a pull request too they just don't publicize it:
https://github.com/OpenImageIO/oiio/pull/118.diff On Jul 7, 2011, at 9:41 AM, Richard Shaw wrote: > On Thu, Jul 7, 2011 at 11:22 AM, Chris Foster <[email protected]> wrote: >> On Thu, Jul 7, 2011 at 11:33 PM, Richard Shaw <[email protected]> wrote: >>>>> 3. There's no man pages for the binaries. It's not an absolute >>>>> requirement for Fedora but it's *STRONGLY* recommend for any command >>>>> line program. >>>> >>>> From work that Larry just posted it looks like idiff, iinfo, iprocess, >>>> and possibly iconvert, maketx may dissappear in the near future, so I >>>> doubt there will be much interest in writing comprehensive docs for >>>> these right now. Would it be sufficient for a quick & dirty job to use >>>> txt2man on the --help output? >>> >>> That should do it. The packaging guidelines only require that they exist. >> >> Ok, I spent some time (more than expected) getting this working. The >> build system should now autogenerate man pages on unix systems when >> txt2man and python can be found. (patch attached. for reviewers, see the >> pull request as before, https://github.com/OpenImageIO/oiio/pull/118) > > Can I bug you for a diff one more time? :) Would the replace the first > one you sent me or be in addition to? > > >>> 6. There are a number of warnings in the build but no errors. Is >>> anyone interested in reviewing them to see if they actually need to be >>> fixed? >>> >>> What I did was to create a pseudo-index by grepping through the build >>> log for "warning" with line numbers since anyone looking into the >>> warning would probably need to see the lines above and/or below the >>> warning. >>> >>> I can post both of those files online somewhere if anyone's interested. >> >> Feel free to post them. I may not find time to fix them personally >> though perhaps someone else will. > > Here's the link: > http://hobbes1069.fedorapeople.org/OpenImageIO/ > > oiio-build.log is the full build log > oiio-warning.log is the "index" > > >>> Most of these can be ignored but I'm concerned about: >>> OpenImageIO.x86_64: W: private-shared-object-provides >>> /usr/lib64/python2.7/site-packages/OpenImageIO.so >>> OpenImageIO.so()(64bit) >>> >>> The description of the error: >>> $ rpmlint -I private-shared-object-provides >>> private-shared-object-provides: >>> A shared object soname provides is provided by a file in a path from which >>> other packages should not directly load shared objects from. Such shared >>> objects should thus not be depended on and they should not result in >>> provides >>> in the containing package. Get rid of the provides if appropriate, for >>> example by filtering it out during build. Note that in some cases this may >>> require disabling rpmbuild's internal dependency generator. >> >> Haha! This is the most obtuse explanation I've read in a while. I've >> read it a few times now, and I must say I have absolutely no idea what >> it's telling me, and whether I should be worried. I even looked it up >> online, but no joy. > > I almost explained it a bit further (I don't completely understand it > though) but I figured my email was already getting rather long and > figured it you didn't understand it you'd say so! :) > > A little background: rpm is pretty good at figuring out what's needed > to run a package, in the spec file those are the "Requires:" lines. > You only add these if, for whatever reason, rpm couldn't figure it out > for you. This happens most often with apps written in interpreted > languages (python, perl, etc). > > The other half of the dependency resolution equation is what a package > "provides". Which it also tries to do automatically. This allows for > depending on a specific binary or library instead of the package as a > whole. > > In this case it thinks that "OpenImageIO.so" is a private library > since it's in the site-packages directory instead of one that's auto > searched like /usr/lib{,64}. But for some reason a "Provides" is being > generated either because rpm thinks it should be or something in the > library is saying it does (I'm not sure which). > > There are methods of filtering Provides but it's messy. > > Hopefully that helps your understanding! > > Thanks, > Richard > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
