chromium-browser: symbol lookup error: chromium-browser: undefined symbol: unzGetCurrentFileZStreamPos64 Minizip-ng doesn't provide this. Adding a system-zlib flag is not difficult to do so I hope this can be pulled into a future update of the ebuilds. Reproducible: Always
https://github.com/gentoo/gentoo/pull/36340
No need to manually CC maintainers.
Up to maintainer (which is not me), but personally not thrilled at the idea of doing workarounds for USE=compat when.. it's not compatible contrary to the USE name. Ideally it's something that should be improved in zlib-ng/minizip-ng, and if upstream has no interest to then the USE will remain a masked hack with no real support in Gentoo.
(In reply to Ionen Wolkens from comment #3) > Up to maintainer (which is not me), but personally not thrilled at the idea > of doing workarounds for USE=compat when.. it's not compatible contrary to > the USE name. > > Ideally it's something that should be improved in zlib-ng/minizip-ng, and if > upstream has no interest to then the USE will remain a masked hack with no > real support in Gentoo. That's fair. I only filed this bug because it's a simple thing to do and if you do it the way I did in the pull request it's forced on so doesn't impact normal zlib users in anyway. I had to add: /etc/portage/profile/package.use.mask/zlib-ng: www-client/chromium system-zlib So people that aren't using zlib-ng and minizip-ng won't accidentally end up with a bundled copy.
Sorry, thought I responded to this one before now. The issue here is that Minizip-ng _isn't_ compatible. I don't think it's appropriate for us to work around that here. Instead we need to either get the package fixed _or_ drop the compat claims.
