I just installed media-gfx/exiv2-0.23 on my AMD64 machine and after recompiling some packages with revdep-rebuild every application is still working as expected. Current stable version in portage is around 1.5 years old. The new version fixes the auto-detection of camera lenses for me. It seems there are some new ID-to-name translations included. Only open bug is #382731, but it seems this can be fixed with a single sed command.
Created attachment 326754 [details] exiv2-0.23-r1.ebuild Patched ebuild with fix for bug #382731 that blocks this bug. I don't know the official procedure, but is anything else required for stabilization?
Created attachment 328302 [details] exiv2-0.23-r2.ebuild This ebuild provides a proper fix for an issue with the usage of boost filesystem in contrib/organize and removes the previous workaround which aborts the build process with recent (unstable) boost library (see bug #440842). All patches are accepted by upstream.
Created attachment 328304 [details, diff] exiv2-0.23-boost-fs-contrib.patch
Created attachment 328330 [details] exiv2-0.23-r2.ebuild Updated DEPEND to reflect new boost dependency towards version >=1.44
Will need this version of exiv2 for the next stable version of darktable (coming in less than 1months) Otherwise exported file from darktable will don't have exif information, See more information about it : 1) From Bruce Guenter <bruce@untroubled.org> Recent builds of darktable from git master have stopped copying EXIF data into exported JPEGs. The only item output is the color profile. There is one error output to stdout: [exiv2] Invalid tag name or ifdId `ColorSpace', ifdId 84 Git bisect identified commit 6bf6f56f (Samsung MakerNote cleanup) as the problem, and indeed reverting this on top of master fixes the EXIF output (and error message). From looking at the commit, it's not obvious to me why these added lines would cause a problem. I'm using a Sony a550 on Gentoo Linux. 2) From me : Hi, I saw the same thing on my gentoo machine A work-arround : install the media-gfx/exiv2-0.23 (unstable version for gentoo) 3) From Pascal de Bruijn <pmjdebruijn@pcode.nl> (dev of darktable) It's not a workaround. It's a proper fix (since this is a bug in ancient versions of Exiv2).
As the maintainer seems a little bit inactive, it might be best if one of the darktable maintainers would be willing to take over or somehow "co-maintain" this package. From my point of view, there is no issue left with this package version. I use it for several months now and all my applications work perfectly after a revdep-rebuild on AMD64.
sorry, had to much to do the last weeks. But feel free to take this package. I will commit the attachments now.
ok, it's in CVS now. compiles fine.
Thank you very much, works fine. Do you think you have time for stabilizing this lib in the next weeks? If not, I would offer to ask if someone is willing to proxy-maintain this ebuild. (As we're approaching the second anniversary of the current stable version) ;)
Mario has stepped up to do maintenance by proxy. I will proxy his commits, although other members of the proxy-maintenance team can do so as well. Let's add arches on February 8 for stabilization of 0.23-r1.
Adding arches that seems to have >0.19 stable. Other arches will probably lose their keywords in the future. As per our policy, if you want a stabilization request for an "exotic" arch please do say so
amd64 stable (In reply to comment #11) > As per our policy, if you want a stabilization request for an "exotic" arch please do say so Let's stabilize it on arm too...
ppc stable
arm stable
x86 stable, last arch. Closing.