peci-pcie CI issues

peci-pcie CI issues

[Andrei Kartashev]

Hello Jason,

I push several patches to peci-pcie repo, but looks like CI broken
there. Could you take a look on how to fix CI?

[ 90%] Building CXX object CMakeFiles/peci-pcie.dir/src/peci_pcie.cpp.o
In file included from /usr/local/include/boost/asio/execution.hpp:19,
                 from /usr/local/include/boost/asio/system_executor.hpp:20,
                 from /usr/local/include/boost/asio/associated_executor.hpp:22,
                 from /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
                 from /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
                 from /usr/local/include/boost/asio/io_context.hpp:23,
                 from /usr/local/include/boost/asio/io_service.hpp:18,
                 from /home/jenkins-op/workspace/ci-repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
/usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_void()’:
/usr/local/include/boost/asio/execution/any_executor.hpp:811:23: error: cannot use ‘typeid’ with ‘-fno-rtti’
  811 |     return typeid(void);
      |                       ^
/usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_ex()’:
/usr/local/include/boost/asio/execution/any_executor.hpp:851:21: error: cannot use ‘typeid’ with ‘-fno-rtti’
  851 |     return typeid(Ex);
      |                     ^

-- 
Best regards,
Andrei Kartashev

Re: peci-pcie CI issues

[Patrick Williams]

We have had this issue with a number of repositories lately. The most recent version of boost::asio does not allow -fno-rtti.  The makefile needs to be changed to no longer force this option. 

Sent from my iPhone

> On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <a.kartashev@yadro.com> wrote:
> 
> Hello Jason,
> 
> I push several patches to peci-pcie repo, but looks like CI broken
> there. Could you take a look on how to fix CI?
> 
> [ 90%] Building CXX object CMakeFiles/peci-pcie.dir/src/peci_pcie.cpp.o
> In file included from /usr/local/include/boost/asio/execution.hpp:19,
>                 from /usr/local/include/boost/asio/system_executor.hpp:20,
>                 from /usr/local/include/boost/asio/associated_executor.hpp:22,
>                 from /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
>                 from /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
>                 from /usr/local/include/boost/asio/io_context.hpp:23,
>                 from /usr/local/include/boost/asio/io_service.hpp:18,
>                 from /home/jenkins-op/workspace/ci-repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
> /usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_void()’:
> /usr/local/include/boost/asio/execution/any_executor.hpp:811:23: error: cannot use ‘typeid’ with ‘-fno-rtti’
>  811 |     return typeid(void);
>      |                       ^
> /usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_ex()’:
> /usr/local/include/boost/asio/execution/any_executor.hpp:851:21: error: cannot use ‘typeid’ with ‘-fno-rtti’
>  851 |     return typeid(Ex);
>      |                     ^
> 
> -- 
> Best regards,
> Andrei Kartashev
> 
> 

Re: peci-pcie CI issues

[Ed Tanous]

On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> We have had this issue with a number of repositories lately. The most recent version of boost::asio does not allow -fno-rtti.  The makefile needs to be changed to no longer force this option.

Or, as another option, just wait until boost 1.75.0 lands in yocto
master and subsequent openbmc bump.  It was released a couple weeks
ago and fixes this issue.  We'll likely be adding the no-rtti flags
back to most of the repos shortly after that.

>
> Sent from my iPhone
>
> > On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <a.kartashev@yadro.com> wrote:
> >
> > Hello Jason,
> >
> > I push several patches to peci-pcie repo, but looks like CI broken
> > there. Could you take a look on how to fix CI?
> >
> > [ 90%] Building CXX object CMakeFiles/peci-pcie.dir/src/peci_pcie.cpp.o
> > In file included from /usr/local/include/boost/asio/execution.hpp:19,
> >                 from /usr/local/include/boost/asio/system_executor.hpp:20,
> >                 from /usr/local/include/boost/asio/associated_executor.hpp:22,
> >                 from /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
> >                 from /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
> >                 from /usr/local/include/boost/asio/io_context.hpp:23,
> >                 from /usr/local/include/boost/asio/io_service.hpp:18,
> >                 from /home/jenkins-op/workspace/ci-repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
> > /usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_void()’:
> > /usr/local/include/boost/asio/execution/any_executor.hpp:811:23: error: cannot use ‘typeid’ with ‘-fno-rtti’
> >  811 |     return typeid(void);
> >      |                       ^
> > /usr/local/include/boost/asio/execution/any_executor.hpp: In static member function ‘static const std::type_info& boost::asio::execution::detail::any_executor_base::target_type_ex()’:
> > /usr/local/include/boost/asio/execution/any_executor.hpp:851:21: error: cannot use ‘typeid’ with ‘-fno-rtti’
> >  851 |     return typeid(Ex);
> >      |                     ^
> >
> > --
> > Best regards,
> > Andrei Kartashev
> >
> >
>

Re: peci-pcie CI issues

[Andrei Kartashev]

Well, then probably we can wait.
How far this could happens?

On Thu, 2020-12-24 at 10:23 -0800, Ed Tanous wrote:
> On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz>
> wrote:
> > We have had this issue with a number of repositories lately. The
> > most recent version of boost::asio does not allow -fno-rtti.  The
> > makefile needs to be changed to no longer force this option.
> 
> Or, as another option, just wait until boost 1.75.0 lands in yocto
> master and subsequent openbmc bump.  It was released a couple weeks
> ago and fixes this issue.  We'll likely be adding the no-rtti flags
> back to most of the repos shortly after that.
> 
> > Sent from my iPhone
> > 
> > > On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <
> > > a.kartashev@yadro.com> wrote:
> > > 
> > > Hello Jason,
> > > 
> > > I push several patches to peci-pcie repo, but looks like CI
> > > broken
> > > there. Could you take a look on how to fix CI?
> > > 
> > > [ 90%] Building CXX object CMakeFiles/peci-
> > > pcie.dir/src/peci_pcie.cpp.o
> > > In file included from
> > > /usr/local/include/boost/asio/execution.hpp:19,
> > >                 from
> > > /usr/local/include/boost/asio/system_executor.hpp:20,
> > >                 from
> > > /usr/local/include/boost/asio/associated_executor.hpp:22,
> > >                 from
> > > /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
> > >                 from
> > > /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
> > >                 from
> > > /usr/local/include/boost/asio/io_context.hpp:23,
> > >                 from
> > > /usr/local/include/boost/asio/io_service.hpp:18,
> > >                 from /home/jenkins-op/workspace/ci-
> > > repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > static member function ‘static const std::type_info&
> > > boost::asio::execution::detail::any_executor_base::target_type_vo
> > > id()’:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp:811:23:
> > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > >  811 |     return typeid(void);
> > >      |                       ^
> > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > static member function ‘static const std::type_info&
> > > boost::asio::execution::detail::any_executor_base::target_type_ex
> > > ()’:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp:851:21:
> > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > >  851 |     return typeid(Ex);
> > >      |                     ^
> > > 
> > > --
> > > Best regards,
> > > Andrei Kartashev
> > > 
> > > 
-- 
Best regards,
Andrei Kartashev

Re: peci-pcie CI issues

[Ed Tanous]

On Thu, Dec 24, 2020 at 10:34 AM Andrei Kartashev <a.kartashev@yadro.com> wrote:
>
> Well, then probably we can wait.
> How far this could happens?

Whenever the work gets done.  Someone needs to:
Send a patch to yocto upgrading the boost recipe.
Wait for the meta-layer bump to run (I think Andrew runs the job once a week).
Resolve any issues with the bump when it gets merged to OpenBMC.

There's no exact timelines on the above, but you can certainly
accelerate it by doing step 1, after which you're probably looking at
a couple weeks before we get it in OpenBMC.

>
> On Thu, 2020-12-24 at 10:23 -0800, Ed Tanous wrote:
> > On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz>
> > wrote:
> > > We have had this issue with a number of repositories lately. The
> > > most recent version of boost::asio does not allow -fno-rtti.  The
> > > makefile needs to be changed to no longer force this option.
> >
> > Or, as another option, just wait until boost 1.75.0 lands in yocto
> > master and subsequent openbmc bump.  It was released a couple weeks
> > ago and fixes this issue.  We'll likely be adding the no-rtti flags
> > back to most of the repos shortly after that.
> >
> > > Sent from my iPhone
> > >
> > > > On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <
> > > > a.kartashev@yadro.com> wrote:
> > > >
> > > > Hello Jason,
> > > >
> > > > I push several patches to peci-pcie repo, but looks like CI
> > > > broken
> > > > there. Could you take a look on how to fix CI?
> > > >
> > > > [ 90%] Building CXX object CMakeFiles/peci-
> > > > pcie.dir/src/peci_pcie.cpp.o
> > > > In file included from
> > > > /usr/local/include/boost/asio/execution.hpp:19,
> > > >                 from
> > > > /usr/local/include/boost/asio/system_executor.hpp:20,
> > > >                 from
> > > > /usr/local/include/boost/asio/associated_executor.hpp:22,
> > > >                 from
> > > > /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
> > > >                 from
> > > > /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
> > > >                 from
> > > > /usr/local/include/boost/asio/io_context.hpp:23,
> > > >                 from
> > > > /usr/local/include/boost/asio/io_service.hpp:18,
> > > >                 from /home/jenkins-op/workspace/ci-
> > > > repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
> > > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > > static member function ‘static const std::type_info&
> > > > boost::asio::execution::detail::any_executor_base::target_type_vo
> > > > id()’:
> > > > /usr/local/include/boost/asio/execution/any_executor.hpp:811:23:
> > > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > > >  811 |     return typeid(void);
> > > >      |                       ^
> > > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > > static member function ‘static const std::type_info&
> > > > boost::asio::execution::detail::any_executor_base::target_type_ex
> > > > ()’:
> > > > /usr/local/include/boost/asio/execution/any_executor.hpp:851:21:
> > > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > > >  851 |     return typeid(Ex);
> > > >      |                     ^
> > > >
> > > > --
> > > > Best regards,
> > > > Andrei Kartashev
> > > >
> > > >
> --
> Best regards,
> Andrei Kartashev
>
>

Re: peci-pcie CI issues

[Bills, Jason M]

On 12/24/2020 10:53 AM, Ed Tanous wrote:
> On Thu, Dec 24, 2020 at 10:34 AM Andrei Kartashev <a.kartashev@yadro.com> wrote:
>>
>> Well, then probably we can wait.
>> How far this could happens?
> 
> Whenever the work gets done.  Someone needs to:
> Send a patch to yocto upgrading the boost recipe.
> Wait for the meta-layer bump to run (I think Andrew runs the job once a week).
> Resolve any issues with the bump when it gets merged to OpenBMC.
> 
> There's no exact timelines on the above, but you can certainly
> accelerate it by doing step 1, after which you're probably looking at
> a couple weeks before we get it in OpenBMC.

It looks like upstream Yocto picked up boost 1.75: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/boost.

> 
>>
>> On Thu, 2020-12-24 at 10:23 -0800, Ed Tanous wrote:
>>> On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz>
>>> wrote:
>>>> We have had this issue with a number of repositories lately. The
>>>> most recent version of boost::asio does not allow -fno-rtti.  The
>>>> makefile needs to be changed to no longer force this option.
>>>
>>> Or, as another option, just wait until boost 1.75.0 lands in yocto
>>> master and subsequent openbmc bump.  It was released a couple weeks
>>> ago and fixes this issue.  We'll likely be adding the no-rtti flags
>>> back to most of the repos shortly after that.
>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <
>>>>> a.kartashev@yadro.com> wrote:
>>>>>
>>>>> Hello Jason,
>>>>>
>>>>> I push several patches to peci-pcie repo, but looks like CI
>>>>> broken
>>>>> there. Could you take a look on how to fix CI?
>>>>>
>>>>> [ 90%] Building CXX object CMakeFiles/peci-
>>>>> pcie.dir/src/peci_pcie.cpp.o
>>>>> In file included from
>>>>> /usr/local/include/boost/asio/execution.hpp:19,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/system_executor.hpp:20,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/associated_executor.hpp:22,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/io_context.hpp:23,
>>>>>                  from
>>>>> /usr/local/include/boost/asio/io_service.hpp:18,
>>>>>                  from /home/jenkins-op/workspace/ci-
>>>>> repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp: In
>>>>> static member function ‘static const std::type_info&
>>>>> boost::asio::execution::detail::any_executor_base::target_type_vo
>>>>> id()’:
>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp:811:23:
>>>>> error: cannot use ‘typeid’ with ‘-fno-rtti’
>>>>>   811 |     return typeid(void);
>>>>>       |                       ^
>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp: In
>>>>> static member function ‘static const std::type_info&
>>>>> boost::asio::execution::detail::any_executor_base::target_type_ex
>>>>> ()’:
>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp:851:21:
>>>>> error: cannot use ‘typeid’ with ‘-fno-rtti’
>>>>>   851 |     return typeid(Ex);
>>>>>       |                     ^
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Andrei Kartashev
>>>>>
>>>>>
>> --
>> Best regards,
>> Andrei Kartashev
>>
>>

Re: peci-pcie CI issues

[Andrew Geissler]

> On Jan 11, 2021, at 6:08 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
> 
> 
> 
> On 12/24/2020 10:53 AM, Ed Tanous wrote:
>> On Thu, Dec 24, 2020 at 10:34 AM Andrei Kartashev <a.kartashev@yadro.com> wrote:
>>> 
>>> Well, then probably we can wait.
>>> How far this could happens?
>> Whenever the work gets done.  Someone needs to:
>> Send a patch to yocto upgrading the boost recipe.
>> Wait for the meta-layer bump to run (I think Andrew runs the job once a week).
>> Resolve any issues with the bump when it gets merged to OpenBMC.
>> There's no exact timelines on the above, but you can certainly
>> accelerate it by doing step 1, after which you're probably looking at
>> a couple weeks before we get it in OpenBMC.
> 
> It looks like upstream Yocto picked up boost 1.75: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/boost.

Here’s our bump to try and pick it up: https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533 

But we hit a build issue (unrelated to the boost aspect I believe).
https://github.com/openbmc/openbmc/issues/3746 

Help appreciated on the fail.
> 
>>> 
>>> On Thu, 2020-12-24 at 10:23 -0800, Ed Tanous wrote:
>>>> On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz>
>>>> wrote:
>>>>> We have had this issue with a number of repositories lately. The
>>>>> most recent version of boost::asio does not allow -fno-rtti.  The
>>>>> makefile needs to be changed to no longer force this option.
>>>> 
>>>> Or, as another option, just wait until boost 1.75.0 lands in yocto
>>>> master and subsequent openbmc bump.  It was released a couple weeks
>>>> ago and fixes this issue.  We'll likely be adding the no-rtti flags
>>>> back to most of the repos shortly after that.
>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <
>>>>>> a.kartashev@yadro.com> wrote:
>>>>>> 
>>>>>> Hello Jason,
>>>>>> 
>>>>>> I push several patches to peci-pcie repo, but looks like CI
>>>>>> broken
>>>>>> there. Could you take a look on how to fix CI?
>>>>>> 
>>>>>> [ 90%] Building CXX object CMakeFiles/peci-
>>>>>> pcie.dir/src/peci_pcie.cpp.o
>>>>>> In file included from
>>>>>> /usr/local/include/boost/asio/execution.hpp:19,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/system_executor.hpp:20,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/associated_executor.hpp:22,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/io_context.hpp:23,
>>>>>>                 from
>>>>>> /usr/local/include/boost/asio/io_service.hpp:18,
>>>>>>                 from /home/jenkins-op/workspace/ci-
>>>>>> repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
>>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp: In
>>>>>> static member function ‘static const std::type_info&
>>>>>> boost::asio::execution::detail::any_executor_base::target_type_vo
>>>>>> id()’:
>>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp:811:23:
>>>>>> error: cannot use ‘typeid’ with ‘-fno-rtti’
>>>>>>  811 |     return typeid(void);
>>>>>>      |                       ^
>>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp: In
>>>>>> static member function ‘static const std::type_info&
>>>>>> boost::asio::execution::detail::any_executor_base::target_type_ex
>>>>>> ()’:
>>>>>> /usr/local/include/boost/asio/execution/any_executor.hpp:851:21:
>>>>>> error: cannot use ‘typeid’ with ‘-fno-rtti’
>>>>>>  851 |     return typeid(Ex);
>>>>>>      |                     ^
>>>>>> 
>>>>>> --
>>>>>> Best regards,
>>>>>> Andrei Kartashev
>>>>>> 
>>>>>> 
>>> --
>>> Best regards,
>>> Andrei Kartashev
>>> 
>>> 

Re: peci-pcie CI issues

[Andrei Kartashev]

As far as I can see, boost was updated to 1.75.0, but looks like it
didn't help, CI still failed to build peci-pcie:
https://jenkins.openbmc.org/job/ci-repository/12229/console

On Thu, 2020-12-24 at 10:23 -0800, Ed Tanous wrote:
> On Thu, Dec 24, 2020 at 10:07 AM Patrick Williams <patrick@stwcx.xyz>
> wrote:
> > We have had this issue with a number of repositories lately. The
> > most recent version of boost::asio does not allow -fno-rtti.  The
> > makefile needs to be changed to no longer force this option.
> 
> Or, as another option, just wait until boost 1.75.0 lands in yocto
> master and subsequent openbmc bump.  It was released a couple weeks
> ago and fixes this issue.  We'll likely be adding the no-rtti flags
> back to most of the repos shortly after that.
> 
> > Sent from my iPhone
> > 
> > > On Dec 24, 2020, at 9:48 AM, Andrei Kartashev <
> > > a.kartashev@yadro.com> wrote:
> > > 
> > > Hello Jason,
> > > 
> > > I push several patches to peci-pcie repo, but looks like CI
> > > broken
> > > there. Could you take a look on how to fix CI?
> > > 
> > > [ 90%] Building CXX object CMakeFiles/peci-
> > > pcie.dir/src/peci_pcie.cpp.o
> > > In file included from
> > > /usr/local/include/boost/asio/execution.hpp:19,
> > >                 from
> > > /usr/local/include/boost/asio/system_executor.hpp:20,
> > >                 from
> > > /usr/local/include/boost/asio/associated_executor.hpp:22,
> > >                 from
> > > /usr/local/include/boost/asio/detail/bind_handler.hpp:20,
> > >                 from
> > > /usr/local/include/boost/asio/detail/wrapped_handler.hpp:18,
> > >                 from
> > > /usr/local/include/boost/asio/io_context.hpp:23,
> > >                 from
> > > /usr/local/include/boost/asio/io_service.hpp:18,
> > >                 from /home/jenkins-op/workspace/ci-
> > > repository/openbmc/peci-pcie/src/peci_pcie.cpp:22:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > static member function ‘static const std::type_info&
> > > boost::asio::execution::detail::any_executor_base::target_type_vo
> > > id()’:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp:811:23:
> > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > >  811 |     return typeid(void);
> > >      |                       ^
> > > /usr/local/include/boost/asio/execution/any_executor.hpp: In
> > > static member function ‘static const std::type_info&
> > > boost::asio::execution::detail::any_executor_base::target_type_ex
> > > ()’:
> > > /usr/local/include/boost/asio/execution/any_executor.hpp:851:21:
> > > error: cannot use ‘typeid’ with ‘-fno-rtti’
> > >  851 |     return typeid(Ex);
> > >      |                     ^
> > > 
> > > --
> > > Best regards,
> > > Andrei Kartashev
> > > 
> > > 
-- 
Best regards,
Andrei Kartashev

Re: peci-pcie CI issues

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Wed, Feb 10, 2021 at 01:04:41PM +0300, Andrei Kartashev wrote:
> As far as I can see, boost was updated to 1.75.0, but looks like it
> didn't help, CI still failed to build peci-pcie:
> https://jenkins.openbmc.org/job/ci-repository/12229/console
>

Hi Andrei,

Repository-level CI isn't done with bitbake but under a docker build we
have set up.  Jason put up a patch yesterday to update that to use Boost
1.75[1].  Once that is merged then the `ci-repository` job will use the
desired Boost version.

1. https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/40426

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: peci-pcie CI issues

[Bills, Jason M]

On 2/10/2021 4:19 AM, Patrick Williams wrote:
> On Wed, Feb 10, 2021 at 01:04:41PM +0300, Andrei Kartashev wrote:
>> As far as I can see, boost was updated to 1.75.0, but looks like it
>> didn't help, CI still failed to build peci-pcie:
>> https://jenkins.openbmc.org/job/ci-repository/12229/console
>>
> 
> Hi Andrei,
> 
> Repository-level CI isn't done with bitbake but under a docker build we
> have set up.  Jason put up a patch yesterday to update that to use Boost
> 1.75[1].  Once that is merged then the `ci-repository` job will use the
> desired Boost version.
> 
> 1. https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/40426
> 

It looks like there is a new failure after the boost 1.75 update.  Does 
anyone know what this error means?  I also see this error on another 
repo: https://jenkins.openbmc.org/job/ci-repository/12253/.

   CXX 
xyz/openbmc_project/Logging/Internal/Manager/phosphor_log_manager-server.o
In file included from /usr/include/c++/10/memory:83,
                  from /usr/local/include/sdbusplus/message.hpp:11,
                  from /usr/local/include/sdbusplus/bus.hpp:7,
                  from /usr/local/include/sdbusplus/server.hpp:3,
                  from 
/usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransition/server.hpp:5,
                  from elog_block.hpp:5,
                  from log_manager.hpp:3,
                  from log_manager.cpp:3:
/usr/include/c++/10/bits/unique_ptr.h: In instantiation of 'typename 
std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with 
_Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >&, unsigned int&, long int&, 
sdbusplus::xyz::openbmc_project::Logging::server::Entry::Level&, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, 
std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> > > >, 
std::vector<std::tuple<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > >, 
std::allocator<std::tuple<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, const 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >&, phosphor::logging::internal::Manager&}; 
typename std::_MakeUniq<_Tp>::__single_object = 
std::unique_ptr<phosphor::logging::Entry>]':
log_manager.cpp:235:74:   required from here
/usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
new-expression of abstract class type 'phosphor::logging::Entry'
   962 |     { return unique_ptr<_Tp>(new 
_Tp(std::forward<_Args>(__args)...)); }
       | 
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from log_manager.hpp:4,
                  from log_manager.cpp:3:
elog_entry.hpp:38:7: note:   because the following virtual functions are 
pure within 'phosphor::logging::Entry':
    38 | class Entry : public EntryIfaces
       |       ^~~~~
In file included from elog_entry.hpp:3,
                  from log_manager.hpp:4,
                  from log_manager.cpp:3:
/usr/local/include/xyz/openbmc_project/Logging/Entry/server.hpp:92:45: 
note:     'virtual sdbusplus::message::unix_fd 
sdbusplus::xyz::openbmc_project::Logging::server::Entry::getEntry()'
    92 |         virtual sdbusplus::message::unix_fd getEntry(
       |                                             ^~~~~~~~
In file included from /usr/include/c++/10/memory:83,
                  from /usr/local/include/sdbusplus/message.hpp:11,
                  from /usr/local/include/sdbusplus/bus.hpp:7,
                  from /usr/local/include/sdbusplus/server.hpp:3,
                  from 
/usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransition/server.hpp:5,
                  from elog_block.hpp:5,
                  from log_manager.hpp:3,
                  from log_manager.cpp:3:
/usr/include/c++/10/bits/unique_ptr.h: In instantiation of 'typename 
std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with 
_Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, long int&, 
phosphor::logging::internal::Manager&}; typename 
std::_MakeUniq<_Tp>::__single_object = 
std::unique_ptr<phosphor::logging::Entry>]':
log_manager.cpp:571:68:   required from here
/usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
new-expression of abstract class type 'phosphor::logging::Entry'
   962 |     { return unique_ptr<_Tp>(new 
_Tp(std::forward<_Args>(__args)...)); }
       | 
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   CXXLD    libphosphor_logging.la
   CXXLD    logging-test
   CXXLD    callout-test
make[2]: Leaving directory 
'/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
make[2]: *** [Makefile:1631: phosphor_log_manager-log_manager.o] Error 1
make[1]: *** [Makefile:2013: all-recursive] Error 1
make[1]: Leaving directory 
'/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
make: *** [Makefile:910: all] Error 2
The command '/bin/sh -c curl -L 
https://github.com/openbmc/phosphor-logging/archive/b50c705c3bb3738673f98cd371b408a5b48e629a.tar.gz 
| tar -xz && cd phosphor-logging-* && ./bootstrap.sh && ./configure 
--prefix=/usr/local --enable-metadata-processing 
YAML_DIR=/usr/local/share/phosphor-dbus-yaml/yaml && make -j80 && make 
install' returned a non-zero code: 2

Thanks,
-Jason

Re: peci-pcie CI issues

[Andrei Kartashev]

I guess, it relates to this patchset:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/40361

On Wed, 2021-02-10 at 08:07 -0800, Bills, Jason M wrote:
> 
> On 2/10/2021 4:19 AM, Patrick Williams wrote:
> > On Wed, Feb 10, 2021 at 01:04:41PM +0300, Andrei Kartashev wrote:
> > > As far as I can see, boost was updated to 1.75.0, but looks like
> > > it
> > > didn't help, CI still failed to build peci-pcie:
> > > https://jenkins.openbmc.org/job/ci-repository/12229/console
> > > 
> > 
> > Hi Andrei,
> > 
> > Repository-level CI isn't done with bitbake but under a docker
> > build we
> > have set up.  Jason put up a patch yesterday to update that to use
> > Boost
> > 1.75[1].  Once that is merged then the `ci-repository` job will use
> > the
> > desired Boost version.
> > 
> > 1. 
> > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/40426
> > 
> 
> It looks like there is a new failure after the boost 1.75
> update.  Does 
> anyone know what this error means?  I also see this error on another 
> repo: https://jenkins.openbmc.org/job/ci-repository/12253/.
> 
>    CXX 
> xyz/openbmc_project/Logging/Internal/Manager/phosphor_log_manager-
> server.o
> In file included from /usr/include/c++/10/memory:83,
>                   from /usr/local/include/sdbusplus/message.hpp:11,
>                   from /usr/local/include/sdbusplus/bus.hpp:7,
>                   from /usr/local/include/sdbusplus/server.hpp:3,
>                   from 
> /usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransition/
> server.hpp:5,
>                   from elog_block.hpp:5,
>                   from log_manager.hpp:3,
>                   from log_manager.cpp:3:
> /usr/include/c++/10/bits/unique_ptr.h: In instantiation of 'typename 
> std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...)
> [with 
> _Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >&, unsigned int&, long int&, 
> sdbusplus::xyz::openbmc_project::Logging::server::Entry::Level&, 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> >, 
> std::allocator<std::__cxx11::basic_string<char,
> std::char_traits<char>, 
> std::allocator<char> > > >, 
> std::vector<std::tuple<std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> >, 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > >, 
> std::allocator<std::tuple<std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> >, 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::__cxx11::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > > > >, const 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >&, phosphor::logging::internal::Manager&}; 
> typename std::_MakeUniq<_Tp>::__single_object = 
> std::unique_ptr<phosphor::logging::Entry>]':
> log_manager.cpp:235:74:   required from here
> /usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
> new-expression of abstract class type 'phosphor::logging::Entry'
>    962 |     { return unique_ptr<_Tp>(new 
> _Tp(std::forward<_Args>(__args)...)); }
>        | 
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from log_manager.hpp:4,
>                   from log_manager.cpp:3:
> elog_entry.hpp:38:7: note:   because the following virtual functions
> are 
> pure within 'phosphor::logging::Entry':
>     38 | class Entry : public EntryIfaces
>        |       ^~~~~
> In file included from elog_entry.hpp:3,
>                   from log_manager.hpp:4,
>                   from log_manager.cpp:3:
> /usr/local/include/xyz/openbmc_project/Logging/Entry/server.hpp:92:45
> : 
> note:     'virtual sdbusplus::message::unix_fd 
> sdbusplus::xyz::openbmc_project::Logging::server::Entry::getEntry()'
>     92 |         virtual sdbusplus::message::unix_fd getEntry(
>        |                                             ^~~~~~~~
> In file included from /usr/include/c++/10/memory:83,
>                   from /usr/local/include/sdbusplus/message.hpp:11,
>                   from /usr/local/include/sdbusplus/bus.hpp:7,
>                   from /usr/local/include/sdbusplus/server.hpp:3,
>                   from 
> /usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransition/
> server.hpp:5,
>                   from elog_block.hpp:5,
>                   from log_manager.hpp:3,
>                   from log_manager.cpp:3:
> /usr/include/c++/10/bits/unique_ptr.h: In instantiation of 'typename 
> std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...)
> [with 
> _Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
> std::__cxx11::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, long int&, 
> phosphor::logging::internal::Manager&}; typename 
> std::_MakeUniq<_Tp>::__single_object = 
> std::unique_ptr<phosphor::logging::Entry>]':
> log_manager.cpp:571:68:   required from here
> /usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
> new-expression of abstract class type 'phosphor::logging::Entry'
>    962 |     { return unique_ptr<_Tp>(new 
> _Tp(std::forward<_Args>(__args)...)); }
>        | 
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    CXXLD    libphosphor_logging.la
>    CXXLD    logging-test
>    CXXLD    callout-test
> make[2]: Leaving directory 
> '/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
> make[2]: *** [Makefile:1631: phosphor_log_manager-log_manager.o]
> Error 1
> make[1]: *** [Makefile:2013: all-recursive] Error 1
> make[1]: Leaving directory 
> '/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
> make: *** [Makefile:910: all] Error 2
> The command '/bin/sh -c curl -L 
> https://github.com/openbmc/phosphor-logging/archive/b50c705c3bb3738673f98cd371b408a5b48e629a.tar.gz 
> > tar -xz && cd phosphor-logging-* && ./bootstrap.sh && ./configure 
> --prefix=/usr/local --enable-metadata-processing 
> YAML_DIR=/usr/local/share/phosphor-dbus-yaml/yaml && make -j80 &&
> make 
> install' returned a non-zero code: 2
> 
> Thanks,
> -Jason
-- 
Best regards,
Andrei Kartashev

Re: peci-pcie CI issues

[Andrei Kartashev]

It compiles now, issue fixed.

On Wed, 2021-02-10 at 19:22 +0300, Andrei Kartashev wrote:
> I guess, it relates to this patchset:
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/40361
> 
> On Wed, 2021-02-10 at 08:07 -0800, Bills, Jason M wrote:
> > On 2/10/2021 4:19 AM, Patrick Williams wrote:
> > > On Wed, Feb 10, 2021 at 01:04:41PM +0300, Andrei Kartashev wrote:
> > > > As far as I can see, boost was updated to 1.75.0, but looks
> > > > like
> > > > it
> > > > didn't help, CI still failed to build peci-pcie:
> > > > https://jenkins.openbmc.org/job/ci-repository/12229/console
> > > > 
> > > 
> > > Hi Andrei,
> > > 
> > > Repository-level CI isn't done with bitbake but under a docker
> > > build we
> > > have set up.  Jason put up a patch yesterday to update that to
> > > use
> > > Boost
> > > 1.75[1].  Once that is merged then the `ci-repository` job will
> > > use
> > > the
> > > desired Boost version.
> > > 
> > > 1. 
> > > https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-build-scripts/+/40426
> > > 
> > 
> > It looks like there is a new failure after the boost 1.75
> > update.  Does 
> > anyone know what this error means?  I also see this error on
> > another 
> > repo: https://jenkins.openbmc.org/job/ci-repository/12253/.
> > 
> >    CXX 
> > xyz/openbmc_project/Logging/Internal/Manager/phosphor_log_manager-
> > server.o
> > In file included from /usr/include/c++/10/memory:83,
> >                   from /usr/local/include/sdbusplus/message.hpp:11,
> >                   from /usr/local/include/sdbusplus/bus.hpp:7,
> >                   from /usr/local/include/sdbusplus/server.hpp:3,
> >                   from 
> > /usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransitio
> > n/
> > server.hpp:5,
> >                   from elog_block.hpp:5,
> >                   from log_manager.hpp:3,
> >                   from log_manager.cpp:3:
> > /usr/include/c++/10/bits/unique_ptr.h: In instantiation of
> > 'typename 
> > std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...)
> > [with 
> > _Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >&, unsigned int&, long int&, 
> > sdbusplus::xyz::openbmc_project::Logging::server::Entry::Level&, 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >,
> > std::vector<std::__cxx11::basic_string<char, 
> > std::char_traits<char>, std::allocator<char> >, 
> > std::allocator<std::__cxx11::basic_string<char,
> > std::char_traits<char>, 
> > std::allocator<char> > > >, 
> > std::vector<std::tuple<std::__cxx11::basic_string<char, 
> > std::char_traits<char>, std::allocator<char> >, 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >, std::__cxx11::basic_string<char, 
> > std::char_traits<char>, std::allocator<char> > >, 
> > std::allocator<std::tuple<std::__cxx11::basic_string<char, 
> > std::char_traits<char>, std::allocator<char> >, 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >, std::__cxx11::basic_string<char, 
> > std::char_traits<char>, std::allocator<char> > > > >, const 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >&, phosphor::logging::internal::Manager&}; 
> > typename std::_MakeUniq<_Tp>::__single_object = 
> > std::unique_ptr<phosphor::logging::Entry>]':
> > log_manager.cpp:235:74:   required from here
> > /usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
> > new-expression of abstract class type 'phosphor::logging::Entry'
> >    962 |     { return unique_ptr<_Tp>(new 
> > _Tp(std::forward<_Args>(__args)...)); }
> >        | 
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from log_manager.hpp:4,
> >                   from log_manager.cpp:3:
> > elog_entry.hpp:38:7: note:   because the following virtual
> > functions
> > are 
> > pure within 'phosphor::logging::Entry':
> >     38 | class Entry : public EntryIfaces
> >        |       ^~~~~
> > In file included from elog_entry.hpp:3,
> >                   from log_manager.hpp:4,
> >                   from log_manager.cpp:3:
> > /usr/local/include/xyz/openbmc_project/Logging/Entry/server.hpp:92:
> > 45
> > : 
> > note:     'virtual sdbusplus::message::unix_fd 
> > sdbusplus::xyz::openbmc_project::Logging::server::Entry::getEntry()
> > '
> >     92 |         virtual sdbusplus::message::unix_fd getEntry(
> >        |                                             ^~~~~~~~
> > In file included from /usr/include/c++/10/memory:83,
> >                   from /usr/local/include/sdbusplus/message.hpp:11,
> >                   from /usr/local/include/sdbusplus/bus.hpp:7,
> >                   from /usr/local/include/sdbusplus/server.hpp:3,
> >                   from 
> > /usr/local/include/xyz/openbmc_project/Logging/ErrorBlocksTransitio
> > n/
> > server.hpp:5,
> >                   from elog_block.hpp:5,
> >                   from log_manager.hpp:3,
> >                   from log_manager.cpp:3:
> > /usr/include/c++/10/bits/unique_ptr.h: In instantiation of
> > 'typename 
> > std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...)
> > [with 
> > _Tp = phosphor::logging::Entry; _Args = {sdbusplus::bus::bus&, 
> > std::__cxx11::basic_string<char, std::char_traits<char>, 
> > std::allocator<char> >, long int&, 
> > phosphor::logging::internal::Manager&}; typename 
> > std::_MakeUniq<_Tp>::__single_object = 
> > std::unique_ptr<phosphor::logging::Entry>]':
> > log_manager.cpp:571:68:   required from here
> > /usr/include/c++/10/bits/unique_ptr.h:962:30: error: invalid 
> > new-expression of abstract class type 'phosphor::logging::Entry'
> >    962 |     { return unique_ptr<_Tp>(new 
> > _Tp(std::forward<_Args>(__args)...)); }
> >        | 
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >    CXXLD    libphosphor_logging.la
> >    CXXLD    logging-test
> >    CXXLD    callout-test
> > make[2]: Leaving directory 
> > '/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
> > make[2]: *** [Makefile:1631: phosphor_log_manager-log_manager.o]
> > Error 1
> > make[1]: *** [Makefile:2013: all-recursive] Error 1
> > make[1]: Leaving directory 
> > '/phosphor-logging-b50c705c3bb3738673f98cd371b408a5b48e629a'
> > make: *** [Makefile:910: all] Error 2
> > The command '/bin/sh -c curl -L 
> > https://github.com/openbmc/phosphor-logging/archive/b50c705c3bb3738673f98cd371b408a5b48e629a.tar.gz 
> > > tar -xz && cd phosphor-logging-* && ./bootstrap.sh &&
> > > ./configure 
> > --prefix=/usr/local --enable-metadata-processing 
> > YAML_DIR=/usr/local/share/phosphor-dbus-yaml/yaml && make -j80 &&
> > make 
> > install' returned a non-zero code: 2
> > 
> > Thanks,
> > -Jason
-- 
Best regards,
Andrei Kartashev