* peci-pcie CI issues
@ 2020-12-24 15:47 Andrei Kartashev
2020-12-24 18:05 ` Patrick Williams
0 siblings, 1 reply; 12+ messages in thread
From: Andrei Kartashev @ 2020-12-24 15:47 UTC (permalink / raw)
To: jason.m.bills; +Cc: openbmc
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: peci-pcie CI issues 2020-12-24 15:47 peci-pcie CI issues Andrei Kartashev @ 2020-12-24 18:05 ` Patrick Williams 2020-12-24 18:23 ` Ed Tanous 0 siblings, 1 reply; 12+ messages in thread From: Patrick Williams @ 2020-12-24 18:05 UTC (permalink / raw) To: Andrei Kartashev; +Cc: jason.m.bills, openbmc 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2020-12-24 18:05 ` Patrick Williams @ 2020-12-24 18:23 ` Ed Tanous 2020-12-24 18:34 ` Andrei Kartashev 2021-02-10 10:04 ` Andrei Kartashev 0 siblings, 2 replies; 12+ messages in thread From: Ed Tanous @ 2020-12-24 18:23 UTC (permalink / raw) To: Patrick Williams; +Cc: jason.m.bills, Andrei Kartashev, openbmc 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 > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2020-12-24 18:23 ` Ed Tanous @ 2020-12-24 18:34 ` Andrei Kartashev 2020-12-24 18:53 ` Ed Tanous 2021-02-10 10:04 ` Andrei Kartashev 1 sibling, 1 reply; 12+ messages in thread From: Andrei Kartashev @ 2020-12-24 18:34 UTC (permalink / raw) To: Ed Tanous, Patrick Williams; +Cc: jason.m.bills, openbmc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2020-12-24 18:34 ` Andrei Kartashev @ 2020-12-24 18:53 ` Ed Tanous 2021-01-12 0:08 ` Bills, Jason M 0 siblings, 1 reply; 12+ messages in thread From: Ed Tanous @ 2020-12-24 18:53 UTC (permalink / raw) To: Andrei Kartashev; +Cc: jason.m.bills, openbmc 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2020-12-24 18:53 ` Ed Tanous @ 2021-01-12 0:08 ` Bills, Jason M 2021-01-12 19:10 ` Andrew Geissler 0 siblings, 1 reply; 12+ messages in thread From: Bills, Jason M @ 2021-01-12 0:08 UTC (permalink / raw) To: openbmc 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 >> >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2021-01-12 0:08 ` Bills, Jason M @ 2021-01-12 19:10 ` Andrew Geissler 0 siblings, 0 replies; 12+ messages in thread From: Andrew Geissler @ 2021-01-12 19:10 UTC (permalink / raw) To: Bills, Jason M; +Cc: openbmc > 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 >>> >>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2020-12-24 18:23 ` Ed Tanous 2020-12-24 18:34 ` Andrei Kartashev @ 2021-02-10 10:04 ` Andrei Kartashev 2021-02-10 12:19 ` Patrick Williams 1 sibling, 1 reply; 12+ messages in thread From: Andrei Kartashev @ 2021-02-10 10:04 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2021-02-10 10:04 ` Andrei Kartashev @ 2021-02-10 12:19 ` Patrick Williams 2021-02-10 16:07 ` Bills, Jason M 0 siblings, 1 reply; 12+ messages in thread From: Patrick Williams @ 2021-02-10 12:19 UTC (permalink / raw) To: Andrei Kartashev; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2021-02-10 12:19 ` Patrick Williams @ 2021-02-10 16:07 ` Bills, Jason M 2021-02-10 16:22 ` Andrei Kartashev 0 siblings, 1 reply; 12+ messages in thread From: Bills, Jason M @ 2021-02-10 16:07 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2021-02-10 16:07 ` Bills, Jason M @ 2021-02-10 16:22 ` Andrei Kartashev 2021-02-11 18:42 ` Andrei Kartashev 0 siblings, 1 reply; 12+ messages in thread From: Andrei Kartashev @ 2021-02-10 16:22 UTC (permalink / raw) To: Bills, Jason M, openbmc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: peci-pcie CI issues 2021-02-10 16:22 ` Andrei Kartashev @ 2021-02-11 18:42 ` Andrei Kartashev 0 siblings, 0 replies; 12+ messages in thread From: Andrei Kartashev @ 2021-02-11 18:42 UTC (permalink / raw) To: Bills, Jason M, openbmc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-02-11 18:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-24 15:47 peci-pcie CI issues Andrei Kartashev 2020-12-24 18:05 ` Patrick Williams 2020-12-24 18:23 ` Ed Tanous 2020-12-24 18:34 ` Andrei Kartashev 2020-12-24 18:53 ` Ed Tanous 2021-01-12 0:08 ` Bills, Jason M 2021-01-12 19:10 ` Andrew Geissler 2021-02-10 10:04 ` Andrei Kartashev 2021-02-10 12:19 ` Patrick Williams 2021-02-10 16:07 ` Bills, Jason M 2021-02-10 16:22 ` Andrei Kartashev 2021-02-11 18:42 ` Andrei Kartashev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).