This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the "Security Response" product. Please mention CVE ids in the RPM changelog when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed.
Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=889398,722701,753799,746226,800581,800583,800584,800587,800589,800590,800591,800592,800593,800594,800595,800597,800598,800600,800602,800604,800606,800607
It would be ideal if hedgewars could link to the system freetype, so that we don't ever have to worry about embedded freetype again.
As far as I can tell Hedgewars does use the system version of freetype, not the embedded copy. The freetype build is commented out in CMakeLists.txt and ldd shows a reference to libfreetype.so.6 => /usr/lib/freetype-freeworld/libfreetype.so.6 (0x4952e000). While freetype-devel is not an explicit buildrequires, it is brought in by one of the buildrequires. Looking at the root.log of a hedgewars build shows that.
This is really odd: % rpm -qp --requires /srv/mirror/Fedora/releases/17/Everything/i386/os/Packages/h/hedgewars-0.9.17-3.fc17.i686.rpm|grep free returns no results. Yet: % ldd /usr/bin/hedgewars|grep free libfreetype.so.6 => /lib/libfreetype.so.6 (0x49886000) I guess it is ok. I wonder why rpm isn't picking up the requirement from that? I suppose this is NOTABUG (and I'll close it as such), but it explains why my tools didn't pick up that Hedgewars is using the system library. Perhaps an explicit Requires and BuildRequires would prevent that confusion from other programs that look at the rpm information to determine dependencies. Thanks, Bruno!
There's definitely something odd about how that library gets pulled in. It didn't look like any of the buildrequires should pull in freetype-devel, but yet it gets pulled in. I checked using repoquery --recursive --whatrequires freetype-devel and didn't get any matches. On the plus side, when looking at this I noticed a minor feature was disabled because libpng-devel wasn't listed in a buildrequires. So I fixed that. And I figured it was time to update to 0.9.18 in f16 and f17 so that people could play network games (as mostly people use the latest version for those).
I suspect that is probably due, perhaps, to freetype-devel already being present? I see in koji that you pushed a new build, which is great, but I don't see anything in the noted changelog about any changes in the requires/buildrequires. Wouldn't it have made sense to add them in (and perhaps, not sure if this is done or not, but rm -rf the internal freetype directory to ensure it never accidentally gets pulled in)? Thanks again for being so responsive.
I noted the higher level change, which is letting screen shots produce png images. From what I could see in the root log was that freetype-devel wasn't in the initial root, but was pulled in by something in the build requires. It might make sense to rm -r the three libraries that aren't built to catch any change. I wouldn't want to use -f, since I'd wanted to notice a change in the directory names as well. I'll probably do that, but won't do new builds just for that.
That sounds fine to me. Thank you!
freetype might be linked only indirectly. ldd doesn't show only directly linked libraries (use nm to see the actual DT_NEEDED entries in the binary), it shows all libraries which somehow end up loaded by the executable.