[HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

[Jonathan Wakely]

I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
it, using the f33-boost side tag.

If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
packages, please do not make another update. Instead co-ordinate with
me to use the side tag for your update (if your package also depends
on Python then also talk to Miro Hrončok).

If your package depends on Boost and you don't see "Rebuilt for Boost
1.73.0" in the %changelog yet, it might be worth checking with me
anyway, as I'll probably be starting it soon.

The new Boost will include the following changes:

- rename boost-jam package to boost-b2, and /usr/bin/bjam with
   /usr/bin/b2 (it looks nothing in Fedora uses this anyway)

- obsolete the separate boost-nowide package, as Boost 1.73.0 includes
   the Boost.Nowide library now

jhogarth, please confirm you're aware of the nowide change. The
existing boost-nowide package will need to be retired in rawhide.

New changes already in rawhide:

- boost-python3-devel subpackage removed, those files are provided by
   boost-devel now.

- Boost libraries no longer link to libpython.

Thanks for your help.

[Vascom]

Hi.

pulseeffects package depends on boost and I don't see changes in changelog.

чт, 28 мая 2020 г., 11:45 Jonathan Wakely :
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.
>
> If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> packages, please do not make another update. Instead co-ordinate with
> me to use the side tag for your update (if your package also depends
> on Python then also talk to Miro Hrončok).
>
> If your package depends on Boost and you don't see "Rebuilt for Boost
> 1.73.0" in the %changelog yet, it might be worth checking with me
> anyway, as I'll probably be starting it soon.
>
> The new Boost will include the following changes:
>
> rename boost-jam package to boost-b2, and /usr/bin/bjam with
>  /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
>
> obsolete the separate boost-nowide package, as Boost 1.73.0 includes
>  the Boost.Nowide library now
>
> jhogarth, please confirm you're aware of the nowide change. The
> existing boost-nowide package will need to be retired in rawhide.
>
> New changes already in rawhide:
>
> boost-python3-devel subpackage removed, those files are provided by
>  boost-devel now.
>
> Boost libraries no longer link to libpython.
>
> Thanks for your help.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Jonathan Wakely]

On 28/05/20 14:47 +0300, Vascom wrote:
> Hi.
>
> pulseeffects package depends on boost and I don't see changes in changelog.

I've literally just started. The new boost hasn't even finished yet:
https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034

Do you need to update pulseeffects? If not, then you don't need to
worry about the rebuilds. A new build will arrive in rawhide when it's
ready.

The request to check with me was if you need to update the package.
> чт, 28 мая 2020 г., 11:45 Jonathan Wakely :
> > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> > it, using the f33-boost side tag.
> >
> > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> > packages, please do not make another update. Instead co-ordinate with
> > me to use the side tag for your update (if your package also depends
> > on Python then also talk to Miro Hrončok).
> >
> > If your package depends on Boost and you don't see "Rebuilt for Boost
> > 1.73.0" in the %changelog yet, it might be worth checking with me
> > anyway, as I'll probably be starting it soon.
> >
> > The new Boost will include the following changes:
> >
> > rename boost-jam package to boost-b2, and /usr/bin/bjam with
> >  /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> >
> > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> >  the Boost.Nowide library now
> >
> > jhogarth, please confirm you're aware of the nowide change. The
> > existing boost-nowide package will need to be retired in rawhide.
> >
> > New changes already in rawhide:
> >
> > boost-python3-devel subpackage removed, those files are provided by
> >  boost-devel now.
> >
> > Boost libraries no longer link to libpython.
> >
> > Thanks for your help.
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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]
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Vascom]

OK

I just write it because you request report about "I don't see changes in
changelog".

чт, 28 мая 2020 г., 15:16 Jonathan Wakely :
> On 28/05/20 14:47 +0300, Vascom wrote:
> > Hi.
> >
> > pulseeffects package depends on boost and I don't see changes in
>
> changelog.
>
> I've literally just started. The new boost hasn't even finished yet:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034
>
> Do you need to update pulseeffects? If not, then you don't need to
> worry about the rebuilds. A new build will arrive in rawhide when it's
> ready.
>
> The request to check with me was if you need to update the package.
> > чт, 28 мая 2020 г., 11:45 Jonathan Wakely :
> > > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> > > it, using the f33-boost side tag.
> > >
> > > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> > > packages, please do not make another update. Instead co-ordinate with
> > > me to use the side tag for your update (if your package also depends
> > > on Python then also talk to Miro Hrončok).
> > >
> > > If your package depends on Boost and you don't see "Rebuilt for Boost
> > > 1.73.0" in the %changelog yet, it might be worth checking with me
> > > anyway, as I'll probably be starting it soon.
> > >
> > > The new Boost will include the following changes:
> > >
> > > rename boost-jam package to boost-b2, and /usr/bin/bjam with
> > >  /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> > >
> > > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> > >  the Boost.Nowide library now
> > >
> > > jhogarth, please confirm you're aware of the nowide change. The
> > > existing boost-nowide package will need to be retired in rawhide.
> > >
> > > New changes already in rawhide:
> > >
> > > boost-python3-devel subpackage removed, those files are provided by
> > >  boost-devel now.
> > >
> > > Boost libraries no longer link to libpython.
> > >
> > > Thanks for your help.
> > > _______________________________________________
> > > devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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]
> > >
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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]
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Fabio Valentini]

On Thu, May 28, 2020 at 2:16 PM Jonathan Wakely
 wrote:
> I've literally just started. The new boost hasn't even finished yet:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034

I wonder if this build is actually broken and if it will ever finish:
https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034

Because ... ppc64 hasn't been a valid arch since fedora 31 or so?

Fabio

[Miro Hrončok]

On 28. 05. 20 14:21, Fabio Valentini wrote:
> On Thu, May 28, 2020 at 2:16 PM Jonathan Wakely
>  wrote:
> > I've literally just started. The new boost hasn't even finished yet:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034
>
> I wonder if this build is actually broken and if it will ever finish:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034
>
> Because ... ppc64 hasn't been a valid arch since fedora 31 or so?

It will not finish. The side tag configuration is busted:

https://pagure.io/releng/issue/9474

[Jonathan Wakely]

On 28/05/20 14:21 +0200, Fabio Valentini wrote:
> On Thu, May 28, 2020 at 2:16 PM Jonathan Wakely
>  wrote:
> > I've literally just started. The new boost hasn't even finished yet:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034
>
> I wonder if this build is actually broken and if it will ever finish:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45094034
>
> Because ... ppc64 hasn't been a valid arch since fedora 31 or so?

Yeah, that's odd.

The side tag is misconfigured, see the command used to create it in
https://pagure.io/releng/issue/9474

[Jonathan Wakely]

On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.
>
> If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> packages, please do not make another update. Instead co-ordinate with
> me to use the side tag for your update (if your package also depends
> on Python then also talk to Miro Hrončok).
>
> If your package depends on Boost and you don't see "Rebuilt for Boost
> 1.73.0" in the %changelog yet, it might be worth checking with me
> anyway, as I'll probably be starting it soon.
>
> The new Boost will include the following changes:
> rename boost-jam package to boost-b2, and /usr/bin/bjam with
>
> /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> obsolete the separate boost-nowide package, as Boost 1.73.0 includes
>
> the Boost.Nowide library now
>
> jhogarth, please confirm you're aware of the nowide change. The
> existing boost-nowide package will need to be retired in rawhide.

Hmm, there's a problem here. The leatherman package fails to build
against Boost 1.73.0 because the version of Boost.Nowide accepted into
upstream Boost doesn't have one of the headers in the standalone
nowide library:

/builddir/build/BUILD/leatherman-1.10.0/util/src/environment.cc:2:10: fatal error: boost/nowide/cenv.hpp: No such file or directory
     2 | #include <boost/nowide/cenv.hpp>
       |          ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

[Yaakov Selkowitz]

On Thu, 2020-05-28 at 18:27 +0100, Jonathan Wakely wrote:
> On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> > it, using the f33-boost side tag.
> >
> > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> > packages, please do not make another update. Instead co-ordinate with
> > me to use the side tag for your update (if your package also depends
> > on Python then also talk to Miro Hrončok).
> >
> > If your package depends on Boost and you don't see "Rebuilt for Boost
> > 1.73.0" in the %changelog yet, it might be worth checking with me
> > anyway, as I'll probably be starting it soon.
> >
> > The new Boost will include the following changes:
> > rename boost-jam package to boost-b2, and /usr/bin/bjam with
> >
> > /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> >
> > the Boost.Nowide library now
> >
> > jhogarth, please confirm you're aware of the nowide change. The
> > existing boost-nowide package will need to be retired in rawhide.
>
> Hmm, there's a problem here. The leatherman package fails to build
> against Boost 1.73.0 because the version of Boost.Nowide accepted into
> upstream Boost doesn't have one of the headers in the standalone
> nowide library:
>
> /builddir/build/BUILD/leatherman-1.10.0/util/src/environment.cc:2:10: fatal error: boost/nowide/cenv.hpp: No such file or directory
>      2 | #include <boost/nowide/cenv.hpp>
>        |          ^~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.

Looks like it was replaced by <boost/nowide/cstdlib.hpp>:

https://github.com/boostorg/nowide/commit/5c684c0fe670fbf772e024817e562c8086...

[Jonathan Wakely]

On 09/06/20 00:02 -0400, Yaakov Selkowitz wrote:
> On Thu, 2020-05-28 at 18:27 +0100, Jonathan Wakely wrote:
> > On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> > > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> > > it, using the f33-boost side tag.
> > >
> > > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> > > packages, please do not make another update. Instead co-ordinate with
> > > me to use the side tag for your update (if your package also depends
> > > on Python then also talk to Miro Hrončok).
> > >
> > > If your package depends on Boost and you don't see "Rebuilt for Boost
> > > 1.73.0" in the %changelog yet, it might be worth checking with me
> > > anyway, as I'll probably be starting it soon.
> > >
> > > The new Boost will include the following changes:
> > > rename boost-jam package to boost-b2, and /usr/bin/bjam with
> > >
> > > /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> > > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> > >
> > > the Boost.Nowide library now
> > >
> > > jhogarth, please confirm you're aware of the nowide change. The
> > > existing boost-nowide package will need to be retired in rawhide.
> >
> > Hmm, there's a problem here. The leatherman package fails to build
> > against Boost 1.73.0 because the version of Boost.Nowide accepted into
> > upstream Boost doesn't have one of the headers in the standalone
> > nowide library:
> >
> > /builddir/build/BUILD/leatherman-1.10.0/util/src/environment.cc:2:10: fatal error: boost/nowide/cenv.hpp: No such file or directory
> >      2 | #include <boost/nowide/cenv.hpp>
> >        |          ^~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
>
> Looks like it was replaced by <boost/nowide/cstdlib.hpp>:
>
> https://github.com/boostorg/nowide/commit/5c684c0fe670fbf772e024817e562c8086...

Yes, as now used by leatherman:
https://src.fedoraproject.org/rpms/leatherman/c/629b826aa4d2dbd768d83d6f87d8...

It's also necessary to link to libboost_nowide.so which wasn't needed
with the old boost-nowide package in Fedora:
https://src.fedoraproject.org/rpms/leatherman/c/d32134d9f5764503a1fff65cbf26...

There's some difficulty for upstream projects currently using the
pre-Boost version of nowide if they want to be compatible with Boost
1.73.0, but nothing too onerous. Some relevant discussion at
https://github.com/slic3r/Slic3r/pull/4976#issuecomment-638440582

[Kaleb Keithley]

On Thu, May 28, 2020 at 4:46 AM Jonathan Wakely 
wrote:
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.

Is this still in progress? I don't see that ceph-15.2.2 has been rebuilt
nor is it being rebuilt now. Should I build the new release of Ceph-15.2.3
in the side tag?

Thanks,
> If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> packages, please do not make another update. Instead co-ordinate with
> me to use the side tag for your update (if your package also depends
> on Python then also talk to Miro Hrončok).
>
> If your package depends on Boost and you don't see "Rebuilt for Boost
> 1.73.0" in the %changelog yet, it might be worth checking with me
> anyway, as I'll probably be starting it soon.
>
> The new Boost will include the following changes:
>
> rename boost-jam package to boost-b2, and /usr/bin/bjam with
>  /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
>
> obsolete the separate boost-nowide package, as Boost 1.73.0 includes
>  the Boost.Nowide library now
>
> jhogarth, please confirm you're aware of the nowide change. The
> existing boost-nowide package will need to be retired in rawhide.
>
> New changes already in rawhide:
>
> boost-python3-devel subpackage removed, those files are provided by
>  boost-devel now.
>
> Boost libraries no longer link to libpython.
>
> Thanks for your help.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Kaleb Keithley]

Is the rebuild in the side tag something that's still in progress?

I sent Jonathan an email asking, but didn't get a reply.

I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag
but if this is something that's on hold I'll need to build it for f33.

Thanks

On Thu, May 28, 2020 at 4:46 AM Jonathan Wakely 
wrote:
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.
>
> If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> packages, please do not make another update. Instead co-ordinate with
> me to use the side tag for your update (if your package also depends
> on Python then also talk to Miro Hrončok).
>
> If your package depends on Boost and you don't see "Rebuilt for Boost
> 1.73.0" in the %changelog yet, it might be worth checking with me
> anyway, as I'll probably be starting it soon.
>
> The new Boost will include the following changes:
>
> rename boost-jam package to boost-b2, and /usr/bin/bjam with
>  /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
>
> obsolete the separate boost-nowide package, as Boost 1.73.0 includes
>  the Boost.Nowide library now
>
> jhogarth, please confirm you're aware of the nowide change. The
> existing boost-nowide package will need to be retired in rawhide.
>
> New changes already in rawhide:
>
> boost-python3-devel subpackage removed, those files are provided by
>  boost-devel now.
>
> Boost libraries no longer link to libpython.
>
> Thanks for your help.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Jonathan Wakely]

On 02/06/20 07:54 -0400, Kaleb Keithley wrote:
> Is the rebuild in the side tag something that's still in progress?
>
> I sent Jonathan an email asking, but didn't get a reply.

Sorry, I didn't see the mail until today.

https://fedoraproject.org/wiki/Changes/F33Boost173#Scope links to the
ticket for the side tag, which is https://pagure.io/releng/issue/9474
and that makes it clear the tag is still active.
> I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag
> but if this is something that's on hold I'll need to build it for f33.

Thanks.

ceph was not in my list, because it isn't returned by the first query
shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies

Does it actually depend on any libboost_*.so libraries, or just use
the header-only libraries? If it only uses the header-only parts it
doesn't necessarily need to be rebuilt (there won't be broken deps
when the previous boost release gets replaced in the rawhide repo,
although it's possible that other things that link to ceph or that
ceph links to will have been rebuilt, which can cause problems).

Hmm, I do see this in ceph.spec:

BuildRequires:	boost-devel
BuildRequires:	boost-random

But the repoquery doesn't say it needs them.

Generally, I only use the side tag to rebuild things that will get
broken deps if they aren't rebuilt. Other packages can be rebuilt
after the side tag is merged, or by the mass rebuild that will happen
in a few weeks.

[Kaleb Keithley]

On Tue, Jun 2, 2020 at 10:25 AM Jonathan Wakely 
wrote:
> ...
> ceph was not in my list, because it isn't returned by the first query
> shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies
>
> Does it actually depend on any libboost_*.so libraries, or just use
> the header-only libraries? If it only uses the header-only parts it
> doesn't necessarily need to be rebuilt (there won't be broken deps
> when the previous boost release gets replaced in the rawhide repo,
> although it's possible that other things that link to ceph or that
> ceph links to will have been rebuilt, which can cause problems).
>
> Hmm, I do see this in ceph.spec:
>
> BuildRequires:  boost-devel
> BuildRequires:  boost-random
>
> But the repoquery doesn't say it needs them.

Up to now it hasn't.

I've been waiting to get boost > 1.71 so that it can be built with the
system boost instead of its bundled copy.

If the side tag build is going to be going on for a while then I'm going to
rebuild it for f33 with boost-1.69, and/but I will also build it again with
higher NVR for f33-boost.

--

Kaleb

[Jonathan Wakely]

On 02/06/20 10:44 -0400, Kaleb Keithley wrote:
> On Tue, Jun 2, 2020 at 10:25 AM Jonathan Wakely 
> wrote:
> > ...
> > ceph was not in my list, because it isn't returned by the first query
> > shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies
> >
> > Does it actually depend on any libboost_*.so libraries, or just use
> > the header-only libraries? If it only uses the header-only parts it
> > doesn't necessarily need to be rebuilt (there won't be broken deps
> > when the previous boost release gets replaced in the rawhide repo,
> > although it's possible that other things that link to ceph or that
> > ceph links to will have been rebuilt, which can cause problems).
> >
> > Hmm, I do see this in ceph.spec:
> >
> > BuildRequires:  boost-devel
> > BuildRequires:  boost-random
> >
> > But the repoquery doesn't say it needs them.
>
> Up to now it hasn't.
>
> I've been waiting to get boost > 1.71 so that it can be built with the
> system boost instead of its bundled copy.
>
> If the side tag build is going to be going on for a while then I'm going to
> rebuild it for f33 with boost-1.69, and/but I will also build it again with
> higher NVR for f33-boost.

The side tag is merging right now, you just have to wait for 100+
packages to be signed, and they'll be in rawhide.

[Kaleb Keithley]

On Tue, Jun 2, 2020 at 10:58 AM Jonathan Wakely 
wrote:
> > Up to now it hasn't.
> >
> > I've been waiting to get boost > 1.71 so that it can be built with the
> > system boost instead of its bundled copy.
> >
> > If the side tag build is going to be going on for a while then I'm going
>
> to
> > rebuild it for f33 with boost-1.69, and/but I will also build it again
>
> with
> > higher NVR for f33-boost.
>
> The side tag is merging right now, you just have to wait for 100+
> packages to be signed, and they'll be in rawhide.

ah, excellent. Thanks for the update.

--

Kaleb

[Jonathan Wakely]

On 02/06/20 11:01 -0400, Kaleb Keithley wrote:
> On Tue, Jun 2, 2020 at 10:58 AM Jonathan Wakely 
> wrote:
> > > Up to now it hasn't.
> > >
> > > I've been waiting to get boost > 1.71 so that it can be built with the
> > > system boost instead of its bundled copy.
> > >
> > > If the side tag build is going to be going on for a while then I'm going
> >
> > to
> > > rebuild it for f33 with boost-1.69, and/but I will also build it again
> >
> > with
> > > higher NVR for f33-boost.
> >
> > The side tag is merging right now, you just have to wait for 100+
> > packages to be signed, and they'll be in rawhide.
>
> ah, excellent. Thanks for the update.

All packages from the f33-boost side tag have now been signed and
should be in rawhide, except for your ceph-15.2.3-1.fc33 (which I
assume will take longer because it's biiiig).

[Iñaki Ucar]

On Tue, 2 Jun 2020 at 17:37, Jonathan Wakely  wrote:
> All packages from the f33-boost side tag have now been signed and
> should be in rawhide

But not in Bodhi. Does this require manual intervention?

[Jonathan Wakely]

On 02/06/20 17:58 +0200, Iñaki Ucar wrote:
> On Tue, 2 Jun 2020 at 17:37, Jonathan Wakely  wrote:
> > All packages from the f33-boost side tag have now been signed and
> > should be in rawhide
>
> But not in Bodhi. Does this require manual intervention?

No.

Does it need to be in bodhi now? It's in the buildroot. I see it with
local mock builds using --enablerepo=local.

[Kevin Fenzi]

On Tue, Jun 02, 2020 at 05:32:46PM +0100, Jonathan Wakely wrote:
> On 02/06/20 17:58 +0200, Iñaki Ucar wrote:
> > On Tue, 2 Jun 2020 at 17:37, Jonathan Wakely  wrote:
> > > All packages from the f33-boost side tag have now been signed and
> > > should be in rawhide
> >
> > But not in Bodhi. Does this require manual intervention?
>
> No.
>
> Does it need to be in bodhi now? It's in the buildroot. I see it with
> local mock builds using --enablerepo=local.

The side tags made by releng and merged this way bypass rawhide gating
currently. So, nothing more should be needed.

Hopefully we can get to the point where we just use user managed side
tags and do gate everything.

kevin

[José Abílio Matos]

On Tuesday, 2 June 2020 15.57.14 WEST Jonathan Wakely wrote:
> The side tag is merging right now, you just have to wait for 100+
> packages to be signed, and they'll be in rawhide.

Oops, I submitted now a new lyx for rawhide. If for some reason it 
picks the old boost I will rebuild it with 1.73.

Thank you.

[Jonathan Wakely]

On 02/06/20 16:24 +0100, José Abílio Matos wrote:
> On Tuesday, 2 June 2020 15.57.14 WEST Jonathan Wakely wrote:
> > The side tag is merging right now, you just have to wait for 100+
> > packages to be signed, and they'll be in rawhide.
>
> Oops, I submitted now a new lyx for rawhide. If for some reason it
> picks the old boost I will rebuild it with 1.73.

Yes, it used the old version:

DEBUG util.py:602:   boost-devel                            x86_64  1.69.0-22.fc33                  build  9.9 M

But I don't think it depends on the shared libraries so it's not going
to have broken deps.

[José Abílio Matos]

On Tuesday, 2 June 2020 16.40.28 WEST Jonathan Wakely wrote:
> Yes, it used the old version:
>
> DEBUG util.py:602:   boost-devel                            x86_64 
> 1.69.0-22.fc33                  build  9.9 M
>
> But I don't think it depends on the shared libraries so it's not going
> to have broken deps.

True but nevertheless I got it compiled with the new Boost and it works. :-)
https://koji.fedoraproject.org/koji/taskinfo?taskID=45323642

[Tomasz Torcz]

On Tue, Jun 02, 2020 at 03:24:24PM +0100, Jonathan Wakely wrote:
> On 02/06/20 07:54 -0400, Kaleb Keithley wrote:
> > Is the rebuild in the side tag something that's still in progress?
> >
> > I sent Jonathan an email asking, but didn't get a reply.
>
> Sorry, I didn't see the mail until today.
>
> https://fedoraproject.org/wiki/Changes/F33Boost173#Scope links to the
> ticket for the side tag, which is https://pagure.io/releng/issue/9474
> and that makes it clear the tag is still active.
> > I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag
> > but if this is something that's on hold I'll need to build it for f33.
>
> Thanks.
>
> ceph was not in my list, because it isn't returned by the first query
> shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies
>
> Does it actually depend on any libboost_*.so libraries, or just use
> the header-only libraries? If it only uses the header-only parts it
> doesn't necessarily need to be rebuilt (there won't be broken deps
> when the previous boost release gets replaced in the rawhide repo,
> although it's possible that other things that link to ceph or that
> ceph links to will have been rebuilt, which can cause problems).
>
> Hmm, I do see this in ceph.spec:
>
> BuildRequires:	boost-devel
> BuildRequires:	boost-random
>
> But the repoquery doesn't say it needs them.

Thats interesting, as boost is in RPM requires.
For example ceph-common-2:15.2.3-1.fc33.aarch64.rpm
(https://koji.fedoraproject.org/koji/rpminfo?rpmID=21717030) has:

libboost_context.so.1.73.0()(64bit)
libboost_program_options.so.1.73.0()(64bit)
libboost_thread.so.1.73.0()(64bit)

[Kaleb Keithley]

On Tue, Jun 2, 2020 at 10:48 AM Tomasz Torcz  wrote:
> > Hmm, I do see this in ceph.spec:
> >
> > BuildRequires:        boost-devel
> > BuildRequires:        boost-random
> >
> > But the repoquery doesn't say it needs them.
>
> Thats interesting, as boost is in RPM requires.
> For example ceph-common-2:15.2.3-1.fc33.aarch64.rpm
> (https://koji.fedoraproject.org/koji/rpminfo?rpmID=21717030) has:
>
> libboost_context.so.1.73.0()(64bit)
> libboost_program_options.so.1.73.0()(64bit)
> libboost_thread.so.1.73.0()(64bit)

Not really. ceph-15.2.3 built in the f33-boost side tag is the first
version that builds with the system's boost packages.

Off hand I'm not sure what, if any, repo would reflect that. Yet.

--

Kaleb

[Jonathan Wakely]

On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.
>
> If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> packages, please do not make another update. Instead co-ordinate with
> me to use the side tag for your update (if your package also depends
> on Python then also talk to Miro Hrončok).
>
> If your package depends on Boost and you don't see "Rebuilt for Boost
> 1.73.0" in the %changelog yet, it might be worth checking with me
> anyway, as I'll probably be starting it soon.

The rebuilds are done and being merged from f33-boost into f33 now.

As usual lots of packages failed to build. Unlike in previous years, I
didn't fix most of them myself.

### Boost.Endian

Several packages fail because they were using an implementation detail
of Boost, the <boost/detail/endian.hpp> header. That no longer exists,
but nobody should have been using it anyway :-P The Boost.Endian
library exists now, and provides <boost/endian/endian.hpp> which
should work instead.

This Boost.Endian issue affects:

openscad
supercollider

### Boost.Bind

Several packages failed to build because the Boost.Bind placeholders
_1, _2, _3 etc. are no longer in the global namespace. See the message
in <boost/bind.hpp>:

BOOST_PRAGMA_MESSAGE(
   "The practice of declaring the Bind placeholders (_1, _2, ...) "
   "in the global namespace is deprecated. Please use "
   "<boost/bind/bind.hpp> + using namespace boost::placeholders, "
   "or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior."
)

This Boost.Bind issue affects:

bear-factory
domoticz
gazebo
hpx
liblas
luxcorerender
pdns
pdns-recursor
uhd
widelands

### C++ <algorithm> includes

Several packages failed to build because they couldn't find C++
Standard Library algorithms:

dolfin: error: 'min_element' is not a member of 'std'; did you mean 'tuple_element'?
freeopcua: error: 'for_each' is not a member of 'std'
gnucash: error: 'for_each' is not a member of 'std'
mir: error: 'find' is not a member of 'std'
openms: error: 'sort' is not a member of 'std'

All of these function templates are declared in <algorithm> so it
means the packages are failing to include what they use. They need to
be patched to include <algorithm>.

### qt5-devel

Several packages failed to build due to BuildRequires: qt5-devel which
is nothing to do with the Boost update, and was already broken on
rawhide.

### stdair etc.

The stdair, airinv, airrac suite had some problems generating
documentation, which doesn't look related to Boost. I didn't
investigate.

### Misc

There were some other failures unique to individual packages, not all
look like they're caused by the boost update:

IQmol: error: no matching function for call to 'IQmol::Layer::Group::Group(IQmol::Layer::PrimitiveList&)'

aqsis: error: 'shared_ptr' in namespace 'boost' does not name a template type

blender: error: unknown type name 'PyNoArgsFunction'; did you mean 'PyCFunction'?

dynafed: error: macro "Error" requires 2 arguments, but only 1 given

espresso: fatal error: in "pack_pair_test": std::out_of_range: vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)

freecad: error: 'Int' in namespace 'Py' does not name a type

libzypp: error: reference to 'filesystem' is ambiguous

mapnik: error: ‘ref’ is not a member of ‘boost::phoenix’

ompl: error: invalid initialization of reference of type

pokerth: error: 'class std::reference_wrapperboost::asio::io_context' has no member named 'context'

scram: error: 'BOOST_THROW_EXCEPTION_CURRENT_FUNCTION' was not declared in this scope
> The new Boost will include the following changes:
> rename boost-jam package to boost-b2, and /usr/bin/bjam with
>
> /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> obsolete the separate boost-nowide package, as Boost 1.73.0 includes
>
> the Boost.Nowide library now
>
> jhogarth, please confirm you're aware of the nowide change. The
> existing boost-nowide package will need to be retired in rawhide.

I never heard back about this. The 'leatherman' package (which uses
boost-nowide) FTBFS with the new boost (which provides a new
boost-nowide subpackage) because the <boost/nowide/cenv.hpp> header is
in the standalone Nowide library, but *not* in the version added to
the main Boost project.

This header issue affects:

leatherman
slic3r
cpp-hocon (build requires leatherman)
facter (build requires leatherman)

Aside: I wish libraries wouldn't call themselves Boost.Foo when
they're not part of Boost yet, especially if they're not actually
compatible with what eventually lands in Boost.

[Miro Hrončok]

On 02. 06. 20 17:24, Jonathan Wakely wrote:
> ### Boost.Endian
>
> Several packages fail because they were using an implementation detail
> of Boost, the <boost/detail/endian.hpp> header. That no longer exists,
> but nobody should have been using it anyway :-P The Boost.Endian
> library exists now, and provides <boost/endian/endian.hpp> which
> should work instead.
>
> This Boost.Endian issue affects:
>
> openscad
> supercollider

Also prusa-slicer and slic3r.

[Miro Hrončok]

On 02. 06. 20 19:51, Miro Hrončok wrote:
> On 02. 06. 20 17:24, Jonathan Wakely wrote:
> > ### Boost.Endian
> >
> > Several packages fail because they were using an implementation detail
> > of Boost, the <boost/detail/endian.hpp> header. That no longer exists,
> > but nobody should have been using it anyway :-P The Boost.Endian
> > library exists now, and provides <boost/endian/endian.hpp> which
> > should work instead.
> >
> > This Boost.Endian issue affects:
> >
> > openscad
> > supercollider
>
> Also prusa-slicer and slic3r.

<boost/endian/endian.hpp> is deprecated:

# error "<boost/endian/endian.hpp> is deprecated. Define 
BOOST_ENDIAN_DEPRECATED_NAMES to use."

/usr/include/boost/endian/endian.hpp:19:1: note: '#pragma message: This header 
is deprecated. Use <boost/endian/arithmetic.hpp> instead.'
    19 | BOOST_HEADER_DEPRECATED( "<boost/endian/arithmetic.hpp>" )

[Jonathan Wakely]

On 02/06/20 20:00 +0200, Miro Hrončok wrote:
> On 02. 06. 20 19:51, Miro Hrončok wrote:
> > On 02. 06. 20 17:24, Jonathan Wakely wrote:
> > > ### Boost.Endian
> > >
> > > Several packages fail because they were using an implementation detail
> > > of Boost, the <boost/detail/endian.hpp> header. That no longer exists,
> > > but nobody should have been using it anyway :-P The Boost.Endian
> > > library exists now, and provides <boost/endian/endian.hpp> which
> > > should work instead.
> > >
> > > This Boost.Endian issue affects:
> > >
> > > openscad
> > > supercollider
> >
> > Also prusa-slicer and slic3r.
>
> <boost/endian/endian.hpp> is deprecated:
>
> # error "<boost/endian/endian.hpp> is deprecated. Define 
> BOOST_ENDIAN_DEPRECATED_NAMES to use."
>
> /usr/include/boost/endian/endian.hpp:19:1: note: '#pragma message: 
> This header is deprecated. Use <boost/endian/arithmetic.hpp> instead.'
>   19 | BOOST_HEADER_DEPRECATED( "<boost/endian/arithmetic.hpp>" )

I don't know about the others, but the use in Slic3r is purely to
check a single macro that used to be defined by the old endian.hpp
header. That macro (BOOST_LITTLE_ENDIAN) is not in Boost at all now.

But it's not needed, at least when using GCC (or a compatible compiler
like Clang on linux) because you can do it without Boost:

--- Slic3r-1.3.0/xs/src/admesh/stl.h~   2020-06-02 21:36:34.816574974 +0100
+++ Slic3r-1.3.0/xs/src/admesh/stl.h    2020-06-02 21:36:37.553576616 +0100
@@ -26,9 +26,8 @@
  #include <stdio.h>
  #include <stdint.h>
  #include <stddef.h>
-#include <boost/detail/endian.hpp>

-#ifndef BOOST_LITTLE_ENDIAN
+#if __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
  #error "admesh works correctly on little endian machines only!"
  #endif

[Jonathan Wakely]

On 02/06/20 16:24 +0100, Jonathan Wakely wrote:
> On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> > it, using the f33-boost side tag.
> >
> > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your
> > packages, please do not make another update. Instead co-ordinate with
> > me to use the side tag for your update (if your package also depends
> > on Python then also talk to Miro Hrončok).
> >
> > If your package depends on Boost and you don't see "Rebuilt for Boost
> > 1.73.0" in the %changelog yet, it might be worth checking with me
> > anyway, as I'll probably be starting it soon.
>
> The rebuilds are done and being merged from f33-boost into f33 now.
>
> As usual lots of packages failed to build. Unlike in previous years, I
> didn't fix most of them myself.
>
> ### Boost.Endian
>
> Several packages fail because they were using an implementation detail
> of Boost, the <boost/detail/endian.hpp> header. That no longer exists,
> but nobody should have been using it anyway :-P The Boost.Endian
> library exists now, and provides <boost/endian/endian.hpp> which
> should work instead.
>
> This Boost.Endian issue affects:
>
> openscad
> supercollider
>
> ### Boost.Bind
>
> Several packages failed to build because the Boost.Bind placeholders
> _1, _2, _3 etc. are no longer in the global namespace. See the message
> in <boost/bind.hpp>:
>
> BOOST_PRAGMA_MESSAGE(
>  "The practice of declaring the Bind placeholders (_1, _2, ...) "
>  "in the global namespace is deprecated. Please use "
>  "<boost/bind/bind.hpp> + using namespace boost::placeholders, "
>  "or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior."
> )
>
> This Boost.Bind issue affects:
>
> bear-factory
> domoticz
> gazebo
> hpx
> liblas
> luxcorerender
> pdns
> pdns-recursor
> uhd
> widelands
>
> ### C++ <algorithm> includes
>
> Several packages failed to build because they couldn't find C++
> Standard Library algorithms:
>
> dolfin: error: 'min_element' is not a member of 'std'; did you mean 'tuple_element'?
> freeopcua: error: 'for_each' is not a member of 'std'
> gnucash: error: 'for_each' is not a member of 'std'
> mir: error: 'find' is not a member of 'std'
> openms: error: 'sort' is not a member of 'std'
>
> All of these function templates are declared in <algorithm> so it
> means the packages are failing to include what they use. They need to
> be patched to include <algorithm>.
>
> ### qt5-devel
>
> Several packages failed to build due to BuildRequires: qt5-devel which
> is nothing to do with the Boost update, and was already broken on
> rawhide.
>
> ### stdair etc.
>
> The stdair, airinv, airrac suite had some problems generating
> documentation, which doesn't look related to Boost. I didn't
> investigate.
>
> ### Misc
>
> There were some other failures unique to individual packages, not all
> look like they're caused by the boost update:
>
> IQmol: error: no matching function for call to 'IQmol::Layer::Group::Group(IQmol::Layer::PrimitiveList&)'
>
> aqsis: error: 'shared_ptr' in namespace 'boost' does not name a template type
>
> blender: error: unknown type name 'PyNoArgsFunction'; did you mean 'PyCFunction'?
>
> dynafed: error: macro "Error" requires 2 arguments, but only 1 given
>
> espresso: fatal error: in "pack_pair_test": std::out_of_range: vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)
>
> freecad: error: 'Int' in namespace 'Py' does not name a type
>
> libzypp: error: reference to 'filesystem' is ambiguous
>
> mapnik: error: ‘ref’ is not a member of ‘boost::phoenix’
>
> ompl: error: invalid initialization of reference of type
>
> pokerth: error: 'class std::reference_wrapperboost::asio::io_context' has no member named 'context'
>
> scram: error: 'BOOST_THROW_EXCEPTION_CURRENT_FUNCTION' was not declared in this scope
> > The new Boost will include the following changes:
> > rename boost-jam package to boost-b2, and /usr/bin/bjam with
> >
> > /usr/bin/b2 (it looks nothing in Fedora uses this anyway)
> > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> >
> > the Boost.Nowide library now
> >
> > jhogarth, please confirm you're aware of the nowide change. The
> > existing boost-nowide package will need to be retired in rawhide.
>
> I never heard back about this. The 'leatherman' package (which uses
> boost-nowide) FTBFS with the new boost (which provides a new
> boost-nowide subpackage) because the <boost/nowide/cenv.hpp> header is
> in the standalone Nowide library, but *not* in the version added to
> the main Boost project.

The cenv.hpp header was removed and its contents added to cstdlib.hpp,
so I'll update the packages using it.

[Jonathan Wakely]

On 02/06/20 22:39 +0100, Jonathan Wakely wrote:
> On 02/06/20 16:24 +0100, Jonathan Wakely wrote:
> > On 28/05/20 09:44 +0100, Jonathan Wakely wrote:
> > > obsolete the separate boost-nowide package, as Boost 1.73.0 includes
> > >
> > > the Boost.Nowide library now
> > >
> > > jhogarth, please confirm you're aware of the nowide change. The
> > > existing boost-nowide package will need to be retired in rawhide.
> >
> > I never heard back about this. The 'leatherman' package (which uses
> > boost-nowide) FTBFS with the new boost (which provides a new
> > boost-nowide subpackage) because the <boost/nowide/cenv.hpp> header is
> > in the standalone Nowide library, but *not* in the version added to
> > the main Boost project.
>
> The cenv.hpp header was removed and its contents added to cstdlib.hpp,
> so I'll update the packages using it.

Everything trying to include boost/nowide/cenv.hpp should be changed
to use boost/nowide/cstdlib.hpp, but they'll probably also need to
link to libboost_nowide.so, which was not necessary with the
standalone boost-nowide package previously used in Fedora.

Upstream confirmed that linking to the library is needed:
https://github.com/boostorg/nowide/issues/90

Any objections to me retiring the standalone boost-nowide package in
rawhide?

[Jonathan Wakely]

On 02/06/20 16:24 +0100, Jonathan Wakely wrote:
> ### Boost.Bind
>
> Several packages failed to build because the Boost.Bind placeholders
> _1, _2, _3 etc. are no longer in the global namespace. See the message
> in <boost/bind.hpp>:
>
> BOOST_PRAGMA_MESSAGE(
>  "The practice of declaring the Bind placeholders (_1, _2, ...) "
>  "in the global namespace is deprecated. Please use "
>  "<boost/bind/bind.hpp> + using namespace boost::placeholders, "
>  "or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior."
> )
>
> This Boost.Bind issue affects:
>
> bear-factory
> domoticz
> gazebo
> hpx
> liblas
> luxcorerender
> pdns
> pdns-recursor
> uhd
> widelands

I believe in most cases this can be fixed by changing <boost/bind.hpp>
to <boost/bind/bind.hpp> and adding "using boost::placeholders::_1;"
somewhere.

[Iñaki Ucar]

On Wed, 3 Jun 2020 at 01:07, Jonathan Wakely  wrote:
> On 02/06/20 16:24 +0100, Jonathan Wakely wrote:
> > ### Boost.Bind
> >
> > Several packages failed to build because the Boost.Bind placeholders
> > _1, _2, _3 etc. are no longer in the global namespace. See the message
> > in <boost/bind.hpp>:
> >
> > BOOST_PRAGMA_MESSAGE(
> >  "The practice of declaring the Bind placeholders (_1, _2, ...) "
> >  "in the global namespace is deprecated. Please use "
> >  "<boost/bind/bind.hpp> + using namespace boost::placeholders, "
> >  "or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior."
> > )
> >
> > This Boost.Bind issue affects:
> >
> > bear-factory
> > domoticz
> > gazebo
> > hpx
> > liblas
> > luxcorerender
> > pdns
> > pdns-recursor
> > uhd
> > widelands
>
> I believe in most cases this can be fixed by changing <boost/bind.hpp>
> to <boost/bind/bind.hpp> and adding "using boost::placeholders::_1;"
> somewhere.

If the codebase is large enough, that can be complicated. In my case,
I just defined BOOST_BIND_GLOBAL_PLACEHOLDERS and added a couple of
missing includes to <boost/bind.hpp> (which weren't required in
previous versions because other boost headers were probably including
that). Here [1]. Of course, then I informed upstream.

[1] https://src.fedoraproject.org/rpms/rstudio/blob/fb93b3619bcfef3dcfe815e43c93...

[Till Hofmann]

On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> ### C++ <algorithm> includes
>
> Several packages failed to build because they couldn't find C++
> Standard Library algorithms:
> freeopcua: error: 'for_each' is not a member of 'std'

I don't see a changelog entry (or a commit), did you only update the
changelog if the build was successful?

I'll fix this as soon as boost 1.73 shows up in rawhide.

Kind regards,
Till

[Jonathan Wakely]

On 03/06/20 12:35 +0200, Till Hofmann wrote:
> On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> > ### C++ <algorithm> includes
> >
> > Several packages failed to build because they couldn't find C++
> > Standard Library algorithms:
> > freeopcua: error: 'for_each' is not a member of 'std'
>
> I don't see a changelog entry (or a commit), did you only update the
> changelog if the build was successful?

Yes.
> I'll fix this as soon as boost 1.73 shows up in rawhide.

It's already there.

[Frantisek Zatloukal]

On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely 
wrote:
> On 03/06/20 12:35 +0200, Till Hofmann wrote:
> > On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> > > ### C++ <algorithm> includes
> > >
> > > Several packages failed to build because they couldn't find C++
> > > Standard Library algorithms:
> > > freeopcua: error: 'for_each' is not a member of 'std'
> >
> > I don't see a changelog entry (or a commit), did you only update the
> > changelog if the build was successful?
>
> Yes.
> > I'll fix this as soon as boost 1.73 shows up in rawhide.
>
> It's already there.

Just note that it is in Rawhide, but you might not get it in mock and/or
system update before next Rawhide compose. It is in buildroot however as
can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33"

[Till Hofmann]

On 6/3/20 1:01 PM, Frantisek Zatloukal wrote:
> On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely
> <[e-mail] > wrote:
> On 03/06/20 12:35 +0200, Till Hofmann wrote:
> >
> >
> >On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> >> ### C++ <algorithm> includes
> >>
> >> Several packages failed to build because they couldn't find C++
> >> Standard Library algorithms:
> >
> >> freeopcua: error: 'for_each' is not a member of 'std'
> >
> >I don't see a changelog entry (or a commit), did you only update the
> >changelog if the build was successful?
>
> Yes.
>
> >I'll fix this as soon as boost 1.73 shows up in rawhide.
>
> It's already there.
>
>
> Just note that it is in Rawhide, but you might not get it in mock and/or
> system update before next Rawhide compose. It is in buildroot however as
> can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33"

Yes, that's what I meant. I'm not going to test patches by submitting
builds over and over again, that's not really time efficient. I'll just
wait until it shows up in mock.

Kind regards,
Till

[Miro Hrončok]

On 03. 06. 20 13:32, Till Hofmann wrote:
> Yes, that's what I meant. I'm not going to test patches by submitting
> builds over and over again, that's not really time efficient. I'll just
> wait until it shows up in mock.

$ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel
...
Installed:
boost-devel-1.73.0-3.fc33.x86_64
...

[Jonathan Wakely]

On 03/06/20 13:36 +0200, Miro Hrončok wrote:
> On 03. 06. 20 13:32, Till Hofmann wrote:
> > Yes, that's what I meant. I'm not going to test patches by submitting
> > builds over and over again, that's not really time efficient. I'll just
> > wait until it shows up in mock.
>
> $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel
> ...
> Installed:
> boost-devel-1.73.0-3.fc33.x86_64
> ...

Right. Using --enablerepo=local means your mock build will use the
buildroot, so you don't have to wait for it to be in the next compose.

You do not need to wait, it's there now. I've ben building against it
locally for the past two days.

[Till Hofmann]

On 6/3/20 4:50 PM, Jonathan Wakely wrote:
> On 03/06/20 13:36 +0200, Miro Hrončok wrote:
> > On 03. 06. 20 13:32, Till Hofmann wrote:
> > > Yes, that's what I meant. I'm not going to test patches by submitting
> > > builds over and over again, that's not really time efficient. I'll just
> > > wait until it shows up in mock.
> >
> > $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel
> > ...
> > Installed:
> > boost-devel-1.73.0-3.fc33.x86_64
> > ...
>
> Right. Using --enablerepo=local means your mock build will use the
> buildroot, so you don't have to wait for it to be in the next compose.
>
> You do not need to wait, it's there now. I've ben building against it
> locally for the past two days.

Thanks, I forgot about the local repo.

Kind regards,
Till

[Richard Shaw]

Ok, one problem after another with FreeCAD, maybe I'll get them fixed
before f33 is released :)

/builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In
constructor 'Gui::DAG::View::View(QWidget*)':
/builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100:
error: '_1' was not declared in this scope
   55 |
Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
this, _1));
      |
                               ^~

Full log:
https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log

Scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091

Any ideas?

Thanks,
Richard

[Ian McInerney]

On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw  wrote:
> Ok, one problem after another with FreeCAD, maybe I'll get them fixed
> before f33 is released :)
>
> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In
> constructor 'Gui::DAG::View::View(QWidget*)':
> /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100:
> error: '_1' was not declared in this scope
>    55 |
> Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
> this, _1));
>       |
>                                  ^~
>
> Full log:
> https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log
>
> Scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091
>
> Any ideas?
>
> Thanks,
> Richard

Looks like the boost::placeholders problem discussed earlier in this
thread:
https://lists.fedoraproject.org/archives/list/[e-mail]/...
.

-Ian

[Jonathan Wakely]

On 03/06/20 20:25 +0100, Ian McInerney wrote:
> On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw  wrote:
> > Ok, one problem after another with FreeCAD, maybe I'll get them fixed
> > before f33 is released :)
> >
> > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In
> > constructor 'Gui::DAG::View::View(QWidget*)':
> > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100:
> > error: '_1' was not declared in this scope
> >    55 |
> > Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
> > this, _1));
> >       |
> >                                  ^~
> >
> > Full log:
> > https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log
> >
> > Scratch build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091
> >
> > Any ideas?
> >
> > Thanks,
> > Richard
>
> Looks like the boost::placeholders problem discussed earlier in this
> thread:
> https://lists.fedoraproject.org/archives/list/[e-mail]/...
> .

Yes, exactly.

You can fix it by adding:

using namespace boost::placeholders;

[Richard Shaw]

On Wed, Jun 3, 2020 at 3:16 PM Jonathan Wakely 
wrote:
> On 03/06/20 20:25 +0100, Ian McInerney wrote:
> > On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw  wrote:
> > > Ok, one problem after another with FreeCAD, maybe I'll get them fixed
> > > before f33 is released :)
> > >
> > > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In
> > > constructor 'Gui::DAG::View::View(QWidget*)':
> > > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100:
> > > error: '_1' was not declared in this scope
> > >    55 |
>
> Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
> > > this, _1));
> > >       |
> > >                                  ^~
> > >
> > > Full log:
> > > https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log
> > >
> > > Scratch build:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > > Richard
> >
> > Looks like the boost::placeholders problem discussed earlier in this
> > thread:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]/...
> > .
>
> Yes, exactly.
>
> You can fix it by adding:
>
> using namespace boost::placeholders;

Is this fairly backwards compatible? I would like to send the fix upstream.

Thanks,
Richard

[Jonathan Wakely]

On 03/06/20 15:21 -0500, Richard Shaw wrote:
> On Wed, Jun 3, 2020 at 3:16 PM Jonathan Wakely 
> wrote:
> > On 03/06/20 20:25 +0100, Ian McInerney wrote:
> > > On Wed, Jun 3, 2020 at 8:08 PM Richard Shaw  wrote:
> > > > Ok, one problem after another with FreeCAD, maybe I'll get them fixed
> > > > before f33 is released :)
> > > >
> > > > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp: In
> > > > constructor 'Gui::DAG::View::View(QWidget*)':
> > > > /builddir/build/BUILD/FreeCAD-0.18.4/src/Gui/DAGView/DAGView.cpp:55:100:
> > > > error: '_1' was not declared in this scope
> > > >    55 |
> >
> > Application::Instance->signalActiveDocument.connect(boost::bind(&View::slotActiveDocument,
> > > > this, _1));
> > > >       |
> > > >                                  ^~
> > > >
> > > > Full log:
> > > > https://kojipkgs.fedoraproject.org//work/tasks/5317/45375317/build.log
> > > >
> > > > Scratch build:
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45375091
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks,
> > > > Richard
> > >
> > > Looks like the boost::placeholders problem discussed earlier in this
> > > thread:
> >
> > https://lists.fedoraproject.org/archives/list/[e-mail]/...
> > > .
> >
> > Yes, exactly.
> >
> > You can fix it by adding:
> >
> > using namespace boost::placeholders;
>
> Is this fairly backwards compatible? I would like to send the fix upstream.

It'll work with anything since Boost 1.60.0 released December 2015
(which is more recent than I realised).

[Richard Shaw]

Next problem...

/usr/include/boost/geometry/index/detail/rtree/node/variant_visitor.hpp:51:25:
error: no matching function for call to
'apply_visitor(boost::geometry::index::detail::rtree::visitors::insert<WireJoiner::VertexInfo,
boost::geometry::index::rtree<WireJoiner::VertexInfo,
boost::geometry::index::linear<16>, WireJoiner::PntGetter>::members_holder,
boost::geometry::index::detail::rtree::insert_default_tag>&,
boost::variant<boost::geometry::index::detail::rtree::variant_leaf<WireJoiner::VertexInfo,
boost::geometry::index::linear<16>,
boost::geometry::model::box<boost::geometry::model::point<double, 3,
boost::geometry::cs::cartesian> >,
boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
WireJoiner::VertexInfo, boost::geometry::index::linear<16>,
boost::geometry::model::box<boost::geometry::model::point<double, 3,
boost::geometry::cs::cartesian> >,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::variant_internal_node<WireJoiner::VertexInfo,
boost::geometry::index::linear<16, 4>,
boost::geometry::model::box<boost::geometry::model::point<double, 3,
boost::geometry::cs::cartesian> >,
boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
WireJoiner::VertexInfo, boost::geometry::index::linear<16, 4>,
boost::geometry::model::box<boost::geometry::model::point<double, 3,
boost::geometry::cs::cartesian> >,
boost::geometry::index::detail::rtree::node_variant_static_tag>,
boost::geometry::index::detail::rtree::node_variant_static_tag> >&)'
   51 |     boost::apply_visitor(v, n);
      |     ~~~~~~~~~~~~~~~~~~~~^~~~~~

https://hobbes1069.fedorapeople.org/freecad-build.log

Thanks,
Richard

[Jonathan Wakely]

On 05/06/20 09:00 -0500, Richard Shaw wrote:
> Next problem...
>
> /usr/include/boost/geometry/index/detail/rtree/node/variant_visitor.hpp:51:25:
> error: no matching function for call to
> 'apply_visitor(boost::geometry::index::detail::rtree::visitors::insert<WireJoiner::VertexInfo,
> boost::geometry::index::rtree<WireJoiner::VertexInfo,
> boost::geometry::index::linear<16>, WireJoiner::PntGetter>::members_holder,
> boost::geometry::index::detail::rtree::insert_default_tag>&,
> boost::variant<boost::geometry::index::detail::rtree::variant_leaf<WireJoiner::VertexInfo,
> boost::geometry::index::linear<16>,
> boost::geometry::model::box<boost::geometry::model::point<double, 3,
> boost::geometry::cs::cartesian> >,
> boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> WireJoiner::VertexInfo, boost::geometry::index::linear<16>,
> boost::geometry::model::box<boost::geometry::model::point<double, 3,
> boost::geometry::cs::cartesian> >,
> boost::geometry::index::detail::rtree::node_variant_static_tag>,
> boost::geometry::index::detail::rtree::node_variant_static_tag>,
> boost::geometry::index::detail::rtree::variant_internal_node<WireJoiner::VertexInfo,
> boost::geometry::index::linear<16, 4>,
> boost::geometry::model::box<boost::geometry::model::point<double, 3,
> boost::geometry::cs::cartesian> >,
> boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> WireJoiner::VertexInfo, boost::geometry::index::linear<16, 4>,
> boost::geometry::model::box<boost::geometry::model::point<double, 3,
> boost::geometry::cs::cartesian> >,
> boost::geometry::index::detail::rtree::node_variant_static_tag>,
> boost::geometry::index::detail::rtree::node_variant_static_tag> >&)'
>   51 |     boost::apply_visitor(v, n);
>      |     ~~~~~~~~~~~~~~~~~~~~^~~~~~

The next error tells you the reason it couldn't be called:

/usr/include/boost/variant/detail/apply_visitor_unary.hpp:46:1: error: 'typedef void boost::static_visitor<void>::result_type' is inaccessible within this context

And it looks like that's a bug in Boost:

// Default insert visitor
template <typename Element, typename MembersHolder>
class insert
     : MembersHolder::visitor
{

I think that base class needs to be public.

Is your work-in-progress to get freecad building pushed to dist-git?

If not, could you send me a SRPM please? I'll try building it against
a patched boost. If that works, I'll push the patched boost to rawhide
and report it upstream.
> https://hobbes1069.fedorapeople.org/freecad-build.log
>
> Thanks,
> Richard
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]

[Richard Shaw]

On Fri, Jun 5, 2020 at 11:43 AM Jonathan Wakely 
wrote:
> On 05/06/20 09:00 -0500, Richard Shaw wrote:
> The next error tells you the reason it couldn't be called:
>
> /usr/include/boost/variant/detail/apply_visitor_unary.hpp:46:1: error:
> 'typedef void boost::static_visitor<void>::result_type' is inaccessible
> within this context

Yup, but had no idea what to do about it :)
> And it looks like that's a bug in Boost:
>
> // Default insert visitor
> template <typename Element, typename MembersHolder>
> class insert
>      : MembersHolder::visitor
> {
>
> I think that base class needs to be public.
>
> Is your work-in-progress to get freecad building pushed to dist-git?
>
> If not, could you send me a SRPM please? I'll try building it against
> a patched boost. If that works, I'll push the patched boost to rawhide
> and report it upstream.

Current WIP pushed to master. Thanks!

Richard

[Jonathan Wakely]

On 05/06/20 17:42 +0100, Jonathan Wakely wrote:
> On 05/06/20 09:00 -0500, Richard Shaw wrote:
> > Next problem...
> >
> > /usr/include/boost/geometry/index/detail/rtree/node/variant_visitor.hpp:51:25:
> > error: no matching function for call to
> > 'apply_visitor(boost::geometry::index::detail::rtree::visitors::insert<WireJoiner::VertexInfo,
> > boost::geometry::index::rtree<WireJoiner::VertexInfo,
> > boost::geometry::index::linear<16>, WireJoiner::PntGetter>::members_holder,
> > boost::geometry::index::detail::rtree::insert_default_tag>&,
> > boost::variant<boost::geometry::index::detail::rtree::variant_leaf<WireJoiner::VertexInfo,
> > boost::geometry::index::linear<16>,
> > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > boost::geometry::cs::cartesian> >,
> > boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> > WireJoiner::VertexInfo, boost::geometry::index::linear<16>,
> > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > boost::geometry::cs::cartesian> >,
> > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > boost::geometry::index::detail::rtree::variant_internal_node<WireJoiner::VertexInfo,
> > boost::geometry::index::linear<16, 4>,
> > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > boost::geometry::cs::cartesian> >,
> > boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> > WireJoiner::VertexInfo, boost::geometry::index::linear<16, 4>,
> > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > boost::geometry::cs::cartesian> >,
> > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > boost::geometry::index::detail::rtree::node_variant_static_tag> >&)'
> >  51 |     boost::apply_visitor(v, n);
> >     |     ~~~~~~~~~~~~~~~~~~~~^~~~~~
>
> The next error tells you the reason it couldn't be called:
>
> /usr/include/boost/variant/detail/apply_visitor_unary.hpp:46:1: error: 'typedef void boost::static_visitor<void>::result_type' is inaccessible within this context
>
> And it looks like that's a bug in Boost:
>
> // Default insert visitor
> template <typename Element, typename MembersHolder>
> class insert
>    : MembersHolder::visitor
> {
>
> I think that base class needs to be public.
>
> Is your work-in-progress to get freecad building pushed to dist-git?
>
> If not, could you send me a SRPM please? I'll try building it against
> a patched boost. If that works, I'll push the patched boost to rawhide
> and report it upstream.

Looking at the rest of the Boost.Geometry code, and the rest of the
patch that changed that line, I'm convinced it's a Boost bug.

Reported as:
https://github.com/boostorg/geometry/issues/721

[Jonathan Wakely]

On 05/06/20 17:59 +0100, Jonathan Wakely wrote:
> On 05/06/20 17:42 +0100, Jonathan Wakely wrote:
> > On 05/06/20 09:00 -0500, Richard Shaw wrote:
> > > Next problem...
> > >
> > > /usr/include/boost/geometry/index/detail/rtree/node/variant_visitor.hpp:51:25:
> > > error: no matching function for call to
> > > 'apply_visitor(boost::geometry::index::detail::rtree::visitors::insert<WireJoiner::VertexInfo,
> > > boost::geometry::index::rtree<WireJoiner::VertexInfo,
> > > boost::geometry::index::linear<16>, WireJoiner::PntGetter>::members_holder,
> > > boost::geometry::index::detail::rtree::insert_default_tag>&,
> > > boost::variant<boost::geometry::index::detail::rtree::variant_leaf<WireJoiner::VertexInfo,
> > > boost::geometry::index::linear<16>,
> > > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > > boost::geometry::cs::cartesian> >,
> > > boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> > > WireJoiner::VertexInfo, boost::geometry::index::linear<16>,
> > > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > > boost::geometry::cs::cartesian> >,
> > > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > > boost::geometry::index::detail::rtree::variant_internal_node<WireJoiner::VertexInfo,
> > > boost::geometry::index::linear<16, 4>,
> > > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > > boost::geometry::cs::cartesian> >,
> > > boost::geometry::index::detail::rtree::allocators<boost::container::new_allocatorWireJoiner::VertexInfo,
> > > WireJoiner::VertexInfo, boost::geometry::index::linear<16, 4>,
> > > boost::geometry::model::box<boost::geometry::model::point<double, 3,
> > > boost::geometry::cs::cartesian> >,
> > > boost::geometry::index::detail::rtree::node_variant_static_tag>,
> > > boost::geometry::index::detail::rtree::node_variant_static_tag> >&)'
> > > 51 |     boost::apply_visitor(v, n);
> > >    |     ~~~~~~~~~~~~~~~~~~~~^~~~~~
> >
> > The next error tells you the reason it couldn't be called:
> >
> > /usr/include/boost/variant/detail/apply_visitor_unary.hpp:46:1: error: 'typedef void boost::static_visitor<void>::result_type' is inaccessible within this context
> >
> > And it looks like that's a bug in Boost:
> >
> > // Default insert visitor
> > template <typename Element, typename MembersHolder>
> > class insert
> >   : MembersHolder::visitor
> > {
> >
> > I think that base class needs to be public.
> >
> > Is your work-in-progress to get freecad building pushed to dist-git?
> >
> > If not, could you send me a SRPM please? I'll try building it against
> > a patched boost. If that works, I'll push the patched boost to rawhide
> > and report it upstream.
>
> Looking at the rest of the Boost.Geometry code, and the rest of the
> patch that changed that line, I'm convinced it's a Boost bug.
>
> Reported as:
> https://github.com/boostorg/geometry/issues/721

boost-1.73.0-4.fc33 is building now:

Building boost-1.73.0-4.fc33 for rawhide
Created task: 45462220
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=45462220

I've also pushed one extra fix to freecad (just adding to your new
patch file). A test build with the new boost and that extra fix
succeeded, so once boost-1.73.0-4.fc33 is in the buildroot you should
be able to build freecad (I am going AFK now, so won't be able to kick
off the freecad build myself).

Once the boost build completes this will tell you when it's in the
repo:
koji wait-repo --build boost-1.73.0-4.fc33 f33-build

And using --enablerepo=local will let local mock builds use that new
build.

I'll check email again in a few hours.

[Richard Shaw]

On Fri, Jun 5, 2020 at 1:58 PM Jonathan Wakely 
wrote:
> boost-1.73.0-4.fc33 is building now:
>
> Building boost-1.73.0-4.fc33 for rawhide
> Created task: 45462220
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=45462220
>
> I've also pushed one extra fix to freecad (just adding to your new
> patch file). A test build with the new boost and that extra fix
> succeeded, so once boost-1.73.0-4.fc33 is in the buildroot you should
> be able to build freecad (I am going AFK now, so won't be able to kick
> off the freecad build myself).
>
> Once the boost build completes this will tell you when it's in the
> repo:
> koji wait-repo --build boost-1.73.0-4.fc33 f33-build
>
> And using --enablerepo=local will let local mock builds use that new
> build.
>
> I'll check email again in a few hours.

No worries, I'll take care of the official rebuild. Thanks for the help.

Thanks,
RIchard

[Markus Neteler]

Hi

Here another package: PDAL
https://src.fedoraproject.org/rpms/PDAL/tree/master

It depends on boost and I don't see changes in changelog.

(at time it fails to compile due to this change, see https://bugzilla.redhat.com/show_bug.cgi?id=1843094)

Best, Markus

[Jonathan Wakely]

On 03/06/20 09:53 -0000, Markus Neteler wrote:
> Hi
>
> Here another package: PDAL
> https://src.fedoraproject.org/rpms/PDAL/tree/master
>
> It depends on boost and I don't see changes in changelog.

It wasn't found by the repoquery last week, because the package didn't
exist when I started rebuilding things for Boost. I can't rebuild
packages that don't exist yet.
> (at time it fails to compile due to this change, see https://bugzilla.redhat.com/show_bug.cgi?id=1843094)

That says it fails to install, not fails to compile. Did you simply
try rebuilding it?

I've started a new build now:

Building PDAL-2.1.0-7.fc33 for rawhide
Created task: 45355046
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=45355046