Heads up! OpenImageIO 2.4 series coming to rawhide

[Richard Shaw]

All builds will be done in a side tag. I don't expect any issues.

I'd like to update f37 as well unless there are any objections.

Thanks,
Richard

[Luya Tshimbalanga]

Send us the sidetag as Blender and openshadinglanguage need update.

Thanks.

On 2022-10-06 18:14, Richard Shaw wrote:
>  All builds will be done in a side tag. I don't expect any
> issues.
>
>  I'd like to update f37 as well unless there are any objections.
>
>  Thanks,
>  Richard
>
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-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, report it:https://pagure.io/fedora-infrastructure/new_issue 
-- 
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

[Richard Shaw]

On Thu, Oct 6, 2022 at 8:26 PM Luya Tshimbalanga <luya(a)fedoraproject.org&gt;
wrote:

>  Send us the sidetag as Blender and openshadinglanguage need update.
>  
You can use f38-build-side-59007 I've already built OIIO and wait-repo is
done. I'll probably finish the builds tomorrow since it's getting late here.

Thanks,
Richard

[Richard Shaw]

On Thu, Oct 6, 2022 at 8:26 PM Luya Tshimbalanga <luya(a)fedoraproject.org&gt;
wrote:

>  Send us the sidetag as Blender and openshadinglanguage need update.
>  
I now have usd building so if successful blender and openshadinglanguage
are all that's needed to submit the update.

Thanks,
Richard

[Richard Shaw]

The side tag update has been submitted, feel free to update the release
notes if you'd like.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-11f61b3a96

Thanks,
Richard

On 2022-10-11 5:37 p.m., Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  The side tag update has been submitted, feel free to update the
> release 
>  notes if you'd like.
>  
>  https://bodhi.fedoraproject.org/updates/FEDORA-2022-11f61b3a96 
>  <https://bodhi.fedoraproject.org/updates/FEDORA-2022-11f61b3a96>
>  
>  Thanks,
>  Richard
>   
Thanks, will it possible to get the update for Fedora 37?

[Ben Beasley]

Since we are in the final freeze for F37, and the update breaks ABI (and API), the Updates
Policy for stable releases applies, and an exception request would need to be submitted
and approved first.

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions

https://github.com/OpenImageIO/oiio/releases/tag/v2.4.4.1

On Wed, Oct 12, 2022, at 2:26 AM, luya(a)fedoraproject.org wrote:
> On 2022-10-11 5:37 p.m., Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>> The side tag update has been submitted, feel free to update the release 
>> notes if you'd like.
>> 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-11f61b3a96 
>> <https://bodhi.fedoraproject.org/updates/FEDORA-2022-11f61b3a96>
>> 
>> Thanks,
>> Richard
>> 
>
> Thanks, will it possible to get the update for Fedora 37?
> _______________________________________________
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

[Luya Tshimbalanga]

On 2022-10-12 07:14, Ben Beasley wrote:
>  Since we are in the final freeze for F37, and the update breaks ABI
> (and API), the Updates Policy for stable releases applies, and an exception request would
> need to be submitted and approved first.
>
>  https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions
>
>  https://github.com/OpenImageIO/oiio/releases/tag/v2.4.4.1 
Done.  QA accepted to get OpenimageIO 2.4 for the final release. See 
https://pagure.io/fedora-qa/blocker-review/issue/969

Let make it available for the week-end as soon as possible so both 
openshadinglanguage and Blender can get built for Fedora 37.

-- 
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

[Richard Shaw]

f37-build-side-59395 has been created and OIIO has been built.

Thanks,
Richard

>

[Richard Shaw]

Rebuilds are done except for blender and openshadinglanguage

Thanks,
Richard

[Richard Shaw]

Update for Fedora 37 submitted, feel free to update the release notes if
you like.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-45e8ca7d85

Thanks,
Richard

>

[Tom Rix]

I was looking at the epel9 build of 2.4 recently but could not figure 
out how to get past the OpenColorIO dependency.

How do you do that ?

Tom

On 10/14/22 1:59 PM, Richard Shaw wrote:
>  Rebuilds are done except for blender and openshadinglanguage
>
>  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, report it: https://pagure.io/fedora-infrastructure/new_issue

[Richard Shaw]

On Mon, Oct 24, 2022 at 2:48 PM Tom Rix <trix(a)redhat.com&gt; wrote:

>  I was looking at the epel9 build of 2.4 recently but could not figure
> out
>  how to get past the OpenColorIO dependency.
>
>  How do you do that ?
>  
I haven't branched OIIO or OCIO for EPEL 9 yet, but I can if there's a need
for it.

The short answer is the command line tools are cross dependent so initially
I have to perform a bootstrap build.

Thanks,
Richard

[Tom Rix]

On 10/24/22 1:02 PM, Richard Shaw wrote:
>  On Mon, Oct 24, 2022 at 2:48 PM Tom Rix <trix(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>
>      I was looking at the epel9 build of 2.4 recently but could not
>      figure out how to get past the OpenColorIO dependency.
>
>      How do you do that ?
>
>
>  I haven't branched OIIO or OCIO for EPEL 9 yet, but I can if there's a 
>  need for it.
>
>  The short answer is the command line tools are cross dependent so 
>  initially I have to perform a bootstrap build. 
I was going to request epel9 branches for both once I figured out how to 
do the building in koji.

Manually on a clean rhel 9, I can fiddle with the image specfile to 
unstick the build and rebuild image with the just built color

Since opencv has an epel9 now, both build.

There is dcmtk on epel9, so the OpenImageIO.spec could change its check

OpenColorIO docs still do not build because of missing python3-sphinx-*

If it is easy can you do the epel9 build otherwise please give me some 
instruction on bootstrapping koji and I will.

Tom

>  Thanks,
>  Richard

[Richard Shaw]

On Tue, Oct 25, 2022 at 10:31 AM Tom Rix <trix(a)redhat.com&gt; wrote:

>  On 10/24/22 1:02 PM, Richard Shaw wrote:
>
>  On Mon, Oct 24, 2022 at 2:48 PM Tom Rix <trix(a)redhat.com&gt; wrote:
>
> > I was looking at the epel9 build of 2.4 recently but could not figure out
> > how to get past the OpenColorIO dependency.
> >
> > How do you do that ?
> >
>
>  I haven't branched OIIO or OCIO for EPEL 9 yet, but I can if there's a
>  need for it.
>
>  The short answer is the command line tools are cross dependent so
>  initially I have to perform a bootstrap build.
>
>  I was going to request epel9 branches for both once I figured out how to
>  do the building in koji.
>
>  Manually on a clean rhel 9, I can fiddle with the image specfile to
>  unstick the build and rebuild image with the just built color
>
>  Since opencv has an epel9 now, both build.
>
>  There is dcmtk on epel9, so the OpenImageIO.spec could change its check
>  
Noted

>  OpenColorIO docs still do not build because of missing
> python3-sphinx-*
>  
Easy answer is to disable building docs on EL, though not ideal.


>  If it is easy can you do the epel9 build otherwise please give me
> some
>  instruction on bootstrapping koji and I will.
>  
I'm creating a CentOS 9 Stream VM right now to do some quick testing. It
may be as easy as commenting out BR: OpenColorIO for OIIO, build OCIO, and
then uncomment and rebuild. It only needs to be done once so I never
created a build conditional.

Thanks,
Richard

[Richard Shaw]

I have both repos now and I have the bootstrap build of OIIO done.

The problem is OCIO. It looks like freeglut-devel is not available in EPEL
9. Also I found a dependency on openshadinglanguage I was previously
unaware of.

Thanks,
Richard

[Richard Shaw]

Until the issues with OCIO can be fixed or worked around, I went ahead and
submitted an update for the bootstrap build of OIIO since it may still be
useful even without OCIO and I didn't want to leave it in limbo.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1297e820b2

Thanks,
Richard

[Tom Rix]

Sorry, I did not run into the freeglut-devel problem with the manual build

I am using rhel 9.1, from poking around, i see there is a problem that 
it is missing only on rhel 9.0.

I am not sure of how to fix without ifdef-ing out for all rhel 9.

I am assuming there is a knob in ocio that makes freeglut optional.

Which i whip up and submit a pr, if that is as good as it gets.

Tom

On 10/27/22 2:58 PM, Richard Shaw wrote:
>  Until the issues with OCIO can be fixed or worked around, I went
> ahead 
>  and submitted an update for the bootstrap build of OIIO since it may 
>  still be useful even without OCIO and I didn't want to leave it in limbo.
>
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1297e820b2 
>  <https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1297e820b2>
>
>  Thanks,
>  Richard

[Richard Shaw]

On Thu, Oct 27, 2022 at 5:15 PM Tom Rix <trix(a)redhat.com&gt; wrote:

>  Sorry, I did not run into the freeglut-devel problem with the manual
> build
>  
I think I have something funny going on with the conditionals. Initially
they were negative conditionals:

%if ! 0%{?bootstrap} || ! 0%{?rhel}
%global docs 1
%global tests 1
%endif


And I noticed that the build was trying to pull in build deps that it
should not. As an experiment I changed it to a full positive conditional
and that seemed to have *MOSTLY* worked:

%if 0%{?bootstrap} || 0%{?rhel}
%global docs 0
%global tests 0
%else
%global docs 1
%global tests 1
%endif

The BR's are not getting pulled in, and yet, on the cmake command, both
docs and tests are still true, which from what I can tell should not be:

%cmake -DCMAKE_CXX_STANDARD=14 \
       -DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
       -DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
       -DOCIO_USE_HEADLESS=ON \
       -DOCIO_INSTALL_EXT_PACKAGES=NONE \
%ifnarch x86_64
       -DOCIO_USE_SSE=OFF \
%endif
       -DOpenGL_GL_PREFERENCE=GLVND

...

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
*-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
-DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND

So I'm pretty much at a WTF moment...

Any help appreciated...

Thanks,
Richard

[Adam Williamson]

On Thu, 2022-10-27 at 19:42 -0500, Richard Shaw wrote:
>  On Thu, Oct 27, 2022 at 5:15 PM Tom Rix <trix(a)redhat.com&gt;
> wrote:
>  
>  > Sorry, I did not run into the freeglut-devel problem with the manual build
>  > 
>  
>  I think I have something funny going on with the conditionals. Initially
>  they were negative conditionals:
>  
>  %if ! 0%{?bootstrap} || ! 0%{?rhel}
>  %global docs 1
>  %global tests 1
>  %endif
>  
>  
>  And I noticed that the build was trying to pull in build deps that it
>  should not. As an experiment I changed it to a full positive conditional
>  and that seemed to have *MOSTLY* worked:
>  
>  %if 0%{?bootstrap} || 0%{?rhel}
>  %global docs 0
>  %global tests 0
>  %else
>  %global docs 1
>  %global tests 1
>  %endif
>  
>  The BR's are not getting pulled in, and yet, on the cmake command, both
>  docs and tests are still true, which from what I can tell should not be:
>  
>  %cmake -DCMAKE_CXX_STANDARD=14 \
>         -DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
>         -DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
>         -DOCIO_USE_HEADLESS=ON \
>         -DOCIO_INSTALL_EXT_PACKAGES=NONE \
>  %ifnarch x86_64
>         -DOCIO_USE_SSE=OFF \
>  %endif
>         -DOpenGL_GL_PREFERENCE=GLVND
>  
>  ...
>  
>  + /usr/bin/cmake -S . -B redhat-linux-build
>  -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
>  -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
>  -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
>  -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
>  -DCMAKE_INSTALL_PREFIX:PATH=/usr
>  -DINCLUDE_INSTALL_DIR:PATH=/usr/include
>  -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
>  -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
>  -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
>  *-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
>  -DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND
>  
>  So I'm pretty much at a WTF moment... 
I think the problem may be that this:

%{?docs:ON}%{?!docs:OFF}

will give you ON if %docs is *defined*, not if it's *truthy*.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Richard Shaw]

On Fri, Oct 28, 2022 at 1:24 AM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Thu, 2022-10-27 at 19:42 -0500, Richard Shaw wrote:
>  > On Thu, Oct 27, 2022 at 5:15 PM Tom Rix <trix(a)redhat.com&gt; wrote:
>  >
>  > > Sorry, I did not run into the freeglut-devel problem with the manual
>  build
>  > >
>  >
>  > I think I have something funny going on with the conditionals. Initially
>  > they were negative conditionals:
>  >
>  > %if ! 0%{?bootstrap} || ! 0%{?rhel}
>  > %global docs 1
>  > %global tests 1
>  > %endif
>  >
>  >
>  > And I noticed that the build was trying to pull in build deps that it
>  > should not. As an experiment I changed it to a full positive conditional
>  > and that seemed to have *MOSTLY* worked:
>  >
>  > %if 0%{?bootstrap} || 0%{?rhel}
>  > %global docs 0
>  > %global tests 0
>  > %else
>  > %global docs 1
>  > %global tests 1
>  > %endif
>  >
>  > The BR's are not getting pulled in, and yet, on the cmake command, both
>  > docs and tests are still true, which from what I can tell should not be:
>  >
>  > %cmake -DCMAKE_CXX_STANDARD=14 \
>  >        -DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
>  >        -DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
>  >        -DOCIO_USE_HEADLESS=ON \
>  >        -DOCIO_INSTALL_EXT_PACKAGES=NONE \
>  > %ifnarch x86_64
>  >        -DOCIO_USE_SSE=OFF \
>  > %endif
>  >        -DOpenGL_GL_PREFERENCE=GLVND
>  >
>  > ...
>  >
>  > + /usr/bin/cmake -S . -B redhat-linux-build
>  > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
>  > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
>  > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
>  > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
>  > -DCMAKE_INSTALL_PREFIX:PATH=/usr
>  > -DINCLUDE_INSTALL_DIR:PATH=/usr/include
>  > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
>  > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
>  > -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
>  > *-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
>  > -DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND
>  >
>  > So I'm pretty much at a WTF moment...
>
>  I think the problem may be that this:
>
>  %{?docs:ON}%{?!docs:OFF}
>
>  will give you ON if %docs is *defined*, not if it's *truthy*.
>  
Gotcha... I figured it was something I did, but I changed the top
conditional because it wasn't working properly, pulling in BRs that should
have been skipped. I'll refactor.

Thanks,
Richard