The first beta of Imath has been released. The package replaces most of {,py}ilmbase from the OpenEXR suite of packages. The rest has been included into OpenEXR-3. A beta of this will probably be released pretty soon. {,Py}IlmBase packages will no longer be available starting with version 3. Reproducible: Always I'm going to prepare a PR and take maintainership of the package. IMO it'd be best to start the bumps for imath-3 and openexr-3 masked. The packages, especially openexr has quite some revdeps which might need changes, both in building instructions, as well as at source code level. Please give me feedback, on what you think about this.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab42e90c0df8cb286b35d6f27d0e7fbe6011e73d commit ab42e90c0df8cb286b35d6f27d0e7fbe6011e73d Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2021-03-16 16:28:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-04 22:02:15 +0000 dev-libs/imath: new package Package starts with version 3.0.1, as it was historically outsourced from the ilmbase / openexr packages. Closes: https://bugs.gentoo.org/776607 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Signed-off-by: Sam James <sam@gentoo.org> dev-libs/imath/Manifest | 1 + dev-libs/imath/imath-3.0.1.ebuild | 90 +++++++++++++++++++++++++++++++++++++++ dev-libs/imath/metadata.xml | 25 +++++++++++ 3 files changed, 116 insertions(+)
(In reply to Bernd from comment #0) > IMO it'd be best to start the bumps for imath-3 and openexr-3 masked. The > packages, especially openexr has quite some revdeps which might need > changes, both in building instructions, as well as at source code level. > Please give me feedback, on what you think about this. Do we still want to mask?
My commented was more intended in line of a question. I'm unsure on how to handle this best. On one side, we have quite some revdeps[1][2], which will likely have issues building out of the box with the new release, so we have to expect a lot of bug reports. We can, of course, quick fix upcoming issues by limiting the version in the depstrings until upstreams have updated their code and as long as the <3 version is still in tree. On the other side, looking at the CVE's we should look into stabilizing ASAP. And a third side, I do not know, what's considered best practice with Gentoo to handle this. What do you think? [1]https://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/ilmbase [2]https://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/openexr
(In reply to Bernd from comment #3) > My commented was more intended in line of a question. I'm unsure on how to > handle this best. > > On one side, we have quite some revdeps[1][2], which will likely have issues > building out of the box with the new release, so we have to expect a lot of > bug reports. We can, of course, quick fix upcoming issues by limiting the > version in the depstrings until upstreams have updated their code and as > long as the <3 version is still in tree. I think we will have to see what happens. If too many deps need < then it just causes messy looking output/conflict for users and we may as well mask it. > > On the other side, looking at the CVE's we should look into stabilizing ASAP. > This is going to be one of those where we have to wait probably 2 weeks or so for people to hit any problems given it’s a lot of churn. It’d help if we could get someone to test all the rdeps for us though. > And a third side, I do not know, what's considered best practice with Gentoo > to handle this. > It kind of depends. Sometimes we mask and have a tinderbox try it, sometimes we unleash in ~arch and see what happens, …. > What do you think? > For now, let’s wait and see what happens. We can always mask at short notice if the bugs start flying in. > [1]https://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/ilmbase > [2]https://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/openexr
(In reply to Sam James from comment #4) > This is going to be one of those where we have to wait probably 2 weeks or > so for people to hit any problems given it’s a lot of churn. It’d help if we > could get someone to test all the rdeps for us though. I can help with testing the rdeps
