Heads Up: openexr 3.0 coming to Rawhide

[Richard Shaw]

I'm currently in the process of testing all deps in my COPR. Assuming no
major issues are found I'll setup a side tag to perform all the builds. I
expect to be done by this coming weekend.

Affected packages are:

alembic
aqsis
bcd
blender
calligra
CTL
darktable
Field3D
freeimage
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
ImageMagick
kdebase3
kdelibs
kde-runtime
kf5-kimageformats
kio-extras
krita
luminance-hdr
luxcorerender
opencv
OpenImageIO
OpenSceneGraph
openshadinglanguage
openvdb
pfstools
povray
prusa-slicer
synfig
synfigstudio
vigra
vips
YafaRay

Thanks,
Richard

[Richard Shaw]

Quick update, long story short there were a ton a build failures in my
testing COPR and I haven't had a lot of time to troubleshoot. Will work on
it as I can.

Thanks,
Richard

>

[Josef Řídký]

Hi,

just a brief heads up notice. The openexr 3.0 will lend in Rawhide soon and
so all affected packagers [1] should prepare the fixes for this change. If
you can, use the COPR environment for testing your package with the new
openexr version.

You can expect an updated list of build statuses in COPR later today or
early tomorrow.

[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/openexr/builds/

Thanks for cooperation and have a great day.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 12, 2021 at 2:36 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  I'm currently in the process of testing all deps in my COPR.
> Assuming no
>  major issues are found I'll setup a side tag to perform all the builds. I
>  expect to be done by this coming weekend.
>
>  Affected packages are:
>
>  alembic
>  aqsis
>  bcd
>  blender
>  calligra
>  CTL
>  darktable
>  Field3D
>  freeimage
>  gegl04
>  gimp
>  gmic
>  gstreamer1-plugins-bad-free
>  hugin
>  ImageMagick
>  kdebase3
>  kdelibs
>  kde-runtime
>  kf5-kimageformats
>  kio-extras
>  krita
>  luminance-hdr
>  luxcorerender
>  opencv
>  OpenImageIO
>  OpenSceneGraph
>  openshadinglanguage
>  openvdb
>  pfstools
>  povray
>  prusa-slicer
>  synfig
>  synfigstudio
>  vigra
>  vips
>  YafaRay
>
>  Thanks,
>  Richard
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Richard Shaw]

I've been able to update several packages to build with OpenEXR 3 but there
are many more to go, perhaps too many for me to handle.

Specifically (and ironically) OpenVDB which is also a project under the
stewardship of the ASWF has not had a single commit to it to be compatible
with OpenEXR 3.

For that reason I'm considering submitting for an openexr2 package. But
that means really mapping out the dependency chain, right? We don't want
both packages used within the same "stack".

Thoughts?

Thanks,
Richard

[Josef Řídký]

Well, the next question to answer is, should the package without active
upstream maintenance be the reason for slowing down the progress of another
project? Should such a package remain in Fedora at all?

I would personally avoid to do such openexr2 package split, just because I
know how painful it will become to get rid of such versions later from
Fedora and do it just as transition never worked for me - it remained in
the compose for much longer than expected, but it's just my 0.02$.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Jun 7, 2021 at 6:20 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  I've been able to update several packages to build with OpenEXR 3
> but
>  there are many more to go, perhaps too many for me to handle.
>
>  Specifically (and ironically) OpenVDB which is also a project under the
>  stewardship of the ASWF has not had a single commit to it to be compatible
>  with OpenEXR 3.
>
>  For that reason I'm considering submitting for an openexr2 package. But
>  that means really mapping out the dependency chain, right? We don't want
>  both packages used within the same "stack".
>
>  Thoughts?
>
>  Thanks,
>  Richard
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Richard Shaw]

On Tue, Jun 8, 2021 at 9:34 AM Josef Řídký <jridky(a)redhat.com&gt; wrote:

>  Well, the next question to answer is, should the package without
> active
>  upstream maintenance be the reason for slowing down the progress of another
>  project? Should such a package remain in Fedora at all?
>
>  I would personally avoid to do such openexr2 package split, just because I
>  know how painful it will become to get rid of such versions later from
>  Fedora and do it just as transition never worked for me - it remained in
>  the compose for much longer than expected, but it's just my 0.02$.
>  
I'm tempted to just cancel the upgrade due to the OpenVDB debacle at this
point... I'll leave the COPR going for those that want to test their
packages ahead of time.

Thanks,
Richard