Description of problem: GeoIP 1.6.3 is being released, and it includes a fix for libGeoIP leaking error messages to stderr. This affects the perl-Geo-IP module which uses this libraries via XS stubs. Version-Release number of selected component (if applicable): 1.6.3 How reproducible: n/a Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: from the change log: 1.6.3 * Added a GEOIP_SILENCE flag. Include this flag when calling GeoIP_open to prevent any messages from being written to stderr. ( Philip Prindeville and Boris Zentner ) * Mitigate a possible race condition when running nuder threads in the GeoIP_cleanup function. ( Anthon Pang ) * Added some recommendations to the docs on using this library in a threaded application. ( Boriz Zentner ) * Fixed some bugs discovered by coverity, including failure to check some system call return values and making sure all strings are null-terminated. ( Boris Zentner )
The geoipupdate tool has been unbundled from the GeoIP distribution and will need to be packaged separately. Can you put together a package for it? I think it should be called geoipupdate (as per upstream), and I can add a dependency on it in the GeoIP 1.6.3 package. I think it would make sense to move the cron jobs from GeoIP to the geoipupdate package too, in sub-packages called something like geoipupdate-ipv4-cron and geoipupdate-ipv6-cron. These should obsolete/provide GeoIP-update < 1.6.0 and GeoIP-update6 < 1.6.0 respectively. That will ensure that there is a clean upgrade path for existing users. Once that's in place I can update GeoIP to 1.6.3 and drop the update sub-packages.
(In reply to Paul Howarth from comment #1) > The geoipupdate tool has been unbundled from the GeoIP distribution and will > need to be packaged separately. Can you put together a package for it? > > I think it should be called geoipupdate (as per upstream), and I can add a > dependency on it in the GeoIP 1.6.3 package. Not obvious that GeoIP and geoipupdate need to have any interdependencies. I can see a scenario where someone is using the database but accessing it directly themselves (or via some Perl module which doesn't link to the C API via XS stubs), and I can also see a scenario where someone just needs a single static copy of the database and they don't care about ever having it be updated. BTW: I have a git checkout with the changes staged for 1.6.3. > I think it would make sense to move the cron jobs from GeoIP to the > geoipupdate package too, in sub-packages called something like > geoipupdate-ipv4-cron and geoipupdate-ipv6-cron. These should > obsolete/provide GeoIP-update < 1.6.0 and GeoIP-update6 < 1.6.0 > respectively. That will ensure that there is a clean upgrade path for > existing users. Yes, I'm in favor of reparenting the cron jobs as you suggest. > Once that's in place I can update GeoIP to 1.6.3 and drop the update > sub-packages. Was thinking about temporarily including geoipupdate as a subpackage of GeoIP-1.6.3 so we can get it out the door since it's badly needed, and then doing a respin shortly after as a separate package.
Committed (and pushed) changes to build version 1.6.4. Will build and submit for release. Will also start separate package (or group of packages and subpackages) for "geoipupdate".
GeoIP-1.6.4-0.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/GeoIP-1.6.4-0.fc21
GeoIP-1.6.4-0.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/GeoIP-1.6.4-0.fc20
Package GeoIP-1.6.4-0.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing GeoIP-1.6.4-0.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1369/GeoIP-1.6.4-0.fc21 then log in and leave karma (feedback).
Would it be possible to update the EPEL packages to version 1.6.4 as well? EPEL-5: 1.4.8-1.el5 EPEL-6: 1.5.1-5.el6
Certainly for EPEL-6. I'll have to look at EPEL-5 and see if there are any issues that would prevent an update.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
GeoIP-GeoLite-data-2015.04-1.el5,geoipupdate-2.2.1-2.el5,GeoIP-1.6.5-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/GeoIP-GeoLite-data-2015.04-1.el5,geoipupdate-2.2.1-2.el5,GeoIP-1.6.5-1.el5
GeoIP-GeoLite-data-2015.04-1.el6,geoipupdate-2.2.1-2.el6,GeoIP-1.6.5-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/GeoIP-GeoLite-data-2015.04-1.el6,geoipupdate-2.2.1-2.el6,GeoIP-1.6.5-1.el6
GeoIP-GeoLite-data-2015.04-1.fc21,geoipupdate-2.2.1-2.fc21,GeoIP-1.6.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/GeoIP-GeoLite-data-2015.04-1.fc21,geoipupdate-2.2.1-2.fc21,GeoIP-1.6.5-1.fc21
GeoIP-GeoLite-data-2015.04-1.fc22,geoipupdate-2.2.1-2.fc22,GeoIP-1.6.5-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/GeoIP-GeoLite-data-2015.04-1.fc22,geoipupdate-2.2.1-2.fc22,GeoIP-1.6.5-1.fc22
GeoIP-GeoLite-data-2015.04-1.fc20,geoipupdate-2.2.1-2.fc20,GeoIP-1.6.5-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/GeoIP-GeoLite-data-2015.04-1.fc20,geoipupdate-2.2.1-2.fc20,GeoIP-1.6.5-1.fc20
(In reply to Carl George) > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1201857 Unfortunately that's a private bug so I can't see it.
GeoIP-GeoLite-data-2015.04-1.fc22, geoipupdate-2.2.1-2.fc22, GeoIP-1.6.5-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Hey Paul, bug #1201857 was me pointing out that RHEL7 GeoIP doesn't have any IPv6 data. I believe it was public originally, but then it was then linked to an actual Red Hat support case. One simple solution would be to rebase the RHEL7 package to these latest Fedora packages, which have all the IPv6 data.
GeoIP-GeoLite-data-2015.04-1.fc20, geoipupdate-2.2.1-2.fc20, GeoIP-1.6.5-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
GeoIP-GeoLite-data-2015.04-1.fc21, geoipupdate-2.2.1-2.fc21, GeoIP-1.6.5-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Carl George from comment #17) > Hey Paul, bug #1201857 was me pointing out that RHEL7 GeoIP doesn't have any > IPv6 data. I believe it was public originally, but then it was then linked > to an actual Red Hat support case. One simple solution would be to rebase > the RHEL7 package to these latest Fedora packages, which have all the IPv6 > data. Hmm, good luck getting Red Hat to do that! I think the IPv6 data is still considered beta by upstream isn't it?
geoipupdate-2.2.1-2.el6, GeoIP-1.6.5-1.el6, GeoIP-GeoLite-data-2015.04-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
geoipupdate-2.2.1-2.el5, GeoIP-GeoLite-data-2015.04-2.el5, GeoIP-1.6.5-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.