Hello everyone, We have successfully added Fedora Rawhide to our production pipeline for Meson compile testing. The image for the container will be updated on a weekly basis. The version of GCC that it is currently running (10.2) catches that the drivers/vdpa/ifc/base/ifcvf.h file redefines VIRTIO_F_IOMMU_PLATFORM, originally from /usr/include/linux/virtio_config.h. I am just giving you guys a heads-up before the failure report catches anyone off guard. Thanks, Brandon -- Brandon Lo UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 blo@iol.unh.edu www.iol.unh.edu
On Thu, Oct 1, 2020 at 8:24 PM Brandon Lo <blo@iol.unh.edu> wrote:
> We have successfully added Fedora Rawhide to our production pipeline
> for Meson compile testing.
> The image for the container will be updated on a weekly basis.
>
> The version of GCC that it is currently running (10.2) catches that
> the drivers/vdpa/ifc/base/ifcvf.h file redefines
> VIRTIO_F_IOMMU_PLATFORM, originally from
> /usr/include/linux/virtio_config.h.
> I am just giving you guys a heads-up before the failure report catches
> anyone off guard.
Brandon,
Before putting this new job online, the build issue should have been
fixed on the dpdk side.
All new submitted series are now getting a fail flag that we must
inspect to check whether it is because of this known issue or
something else.
Please, disable this job.
There is also the OpenSuse job failing.
Can you investigate?
Xiao, Maxime,
Anyone free to have a look on the vdpa build issue on Fedora Rawhide?
FAILED: drivers/libtmp_rte_pmd_ifc.a.p/vdpa_ifc_ifcvf_vdpa.c.o
cc -Idrivers/libtmp_rte_pmd_ifc.a.p -Idrivers -I../drivers
-Idrivers/vdpa/ifc -I../drivers/vdpa/ifc -I../drivers/vdpa/ifc/base
-Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -I.
-I.. -Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
-I../lib/librte_eal/x86/include -Ilib/librte_eal/common
-I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal
-Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics
-I../lib/librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -Ilib/librte_pci -I../lib/librte_pci
-Ilib/librte_vhost -I../lib/librte_vhost -Ilib/librte_ethdev
-I../lib/librte_ethdev -Ilib/librte_net -I../lib/librte_net
-Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool
-I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring
-Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_cryptodev
-I../lib/librte_cryptodev -Ilib/librte_hash -I../lib/librte_hash
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -O3 -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE
-fPIC -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -MD -MQ
drivers/libtmp_rte_pmd_ifc.a.p/vdpa_ifc_ifcvf_vdpa.c.o -MF
drivers/libtmp_rte_pmd_ifc.a.p/vdpa_ifc_ifcvf_vdpa.c.o.d -o
drivers/libtmp_rte_pmd_ifc.a.p/vdpa_ifc_ifcvf_vdpa.c.o -c
../drivers/vdpa/ifc/ifcvf_vdpa.c
In file included from ../drivers/vdpa/ifc/ifcvf_vdpa.c:26:
../drivers/vdpa/ifc/base/ifcvf.h:16: error: "VIRTIO_F_IOMMU_PLATFORM"
redefined [-Werror]
16 | #define VIRTIO_F_IOMMU_PLATFORM 33
|
In file included from /usr/include/linux/virtio_net.h:30,
from ../drivers/vdpa/ifc/ifcvf_vdpa.c:11:
/usr/include/linux/virtio_config.h:78: note: this is the location of
the previous definition
78 | #define VIRTIO_F_IOMMU_PLATFORM VIRTIO_F_ACCESS_PLATFORM
|
cc1: all warnings being treated as errors
Thanks guys.
--
David Marchand
On Fri, Oct 2, 2020 at 8:51 AM David Marchand <david.marchand@redhat.com> wrote: > > On Thu, Oct 1, 2020 at 8:24 PM Brandon Lo <blo@iol.unh.edu> wrote: > > We have successfully added Fedora Rawhide to our production pipeline > > for Meson compile testing. > > The image for the container will be updated on a weekly basis. > > > > The version of GCC that it is currently running (10.2) catches that > > the drivers/vdpa/ifc/base/ifcvf.h file redefines > > VIRTIO_F_IOMMU_PLATFORM, originally from > > /usr/include/linux/virtio_config.h. > > I am just giving you guys a heads-up before the failure report catches > > anyone off guard. > > Brandon, > > Before putting this new job online, the build issue should have been > fixed on the dpdk side. > All new submitted series are now getting a fail flag that we must > inspect to check whether it is because of this known issue or > something else. > > Please, disable this job. The vdpa/ifc issue should be fixed in the main branch now (thanks to Maxime). But next-net and other subtrees will still have the issue until they catch on this fix. > > There is also the OpenSuse job failing. > Can you investigate? Still failing. -- David Marchand
On Fri, Oct 2, 2020 at 6:44 PM David Marchand <david.marchand@redhat.com> wrote:
>
> On Fri, Oct 2, 2020 at 8:51 AM David Marchand <david.marchand@redhat.com> wrote:
> >
> > On Thu, Oct 1, 2020 at 8:24 PM Brandon Lo <blo@iol.unh.edu> wrote:
> > > We have successfully added Fedora Rawhide to our production pipeline
> > > for Meson compile testing.
> > > The image for the container will be updated on a weekly basis.
> > >
> > > The version of GCC that it is currently running (10.2) catches that
> > > the drivers/vdpa/ifc/base/ifcvf.h file redefines
> > > VIRTIO_F_IOMMU_PLATFORM, originally from
> > > /usr/include/linux/virtio_config.h.
> > > I am just giving you guys a heads-up before the failure report catches
> > > anyone off guard.
> >
> > Brandon,
> >
> > Before putting this new job online, the build issue should have been
> > fixed on the dpdk side.
> > All new submitted series are now getting a fail flag that we must
> > inspect to check whether it is because of this known issue or
> > something else.
> >
> > Please, disable this job.
>
> The vdpa/ifc issue should be fixed in the main branch now (thanks to Maxime).
> But next-net and other subtrees will still have the issue until they
> catch on this fix.
>
>
> >
> > There is also the OpenSuse job failing.
> > Can you investigate?
>
> Still failing.
I do not see failures for the OpenSuse job anymore, but since I got no
reply, pinging again to get a clear status on this.
Thanks.
--
David Marchand
[-- Attachment #1: Type: text/plain, Size: 2263 bytes --] Hi David, I disabled that pipeline, Brandon is looking into it this morning. Something failed with starting the container, so they are definitely not "real" failures. For Rawhide, our plan is to mark the failures as warnings instead, until things catch up on the other branches. Similarly, if we add something like GCC 11 compile, I would suggest those failures are also a warning for now. Cheers, Lincoln On Tue, Oct 6, 2020 at 5:51 AM David Marchand <david.marchand@redhat.com> wrote: > On Fri, Oct 2, 2020 at 6:44 PM David Marchand <david.marchand@redhat.com> > wrote: > > > > On Fri, Oct 2, 2020 at 8:51 AM David Marchand <david.marchand@redhat.com> > wrote: > > > > > > On Thu, Oct 1, 2020 at 8:24 PM Brandon Lo <blo@iol.unh.edu> wrote: > > > > We have successfully added Fedora Rawhide to our production pipeline > > > > for Meson compile testing. > > > > The image for the container will be updated on a weekly basis. > > > > > > > > The version of GCC that it is currently running (10.2) catches that > > > > the drivers/vdpa/ifc/base/ifcvf.h file redefines > > > > VIRTIO_F_IOMMU_PLATFORM, originally from > > > > /usr/include/linux/virtio_config.h. > > > > I am just giving you guys a heads-up before the failure report > catches > > > > anyone off guard. > > > > > > Brandon, > > > > > > Before putting this new job online, the build issue should have been > > > fixed on the dpdk side. > > > All new submitted series are now getting a fail flag that we must > > > inspect to check whether it is because of this known issue or > > > something else. > > > > > > Please, disable this job. > > > > The vdpa/ifc issue should be fixed in the main branch now (thanks to > Maxime). > > But next-net and other subtrees will still have the issue until they > > catch on this fix. > > > > > > > > > > There is also the OpenSuse job failing. > > > Can you investigate? > > > > Still failing. > > I do not see failures for the OpenSuse job anymore, but since I got no > reply, pinging again to get a clear status on this. > Thanks. > > > -- > David Marchand > > -- *Lincoln Lavoie* Senior Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) <https://www.iol.unh.edu> [-- Attachment #2: Type: text/html, Size: 4182 bytes --]
06/10/2020 14:52, Lincoln Lavoie:
> For Rawhide, our plan is to mark the failures as warnings instead, until
> things catch up on the other branches. Similarly, if we add something like
> GCC 11 compile, I would suggest those failures are also a warning for now.
Sorry, I disagree with this plan.
As a non-regression tool, we are looking for green lights.
If a new test is not passing, it should not be added
until the original issue is fixed.
Please don't add tests if they are failing, giving warning or error.
Thanks
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --] Hi Thomas, For Rawhide, the failure is fixed, but I don't think it's ported to all branches yet, so how would you want to handle that. Those branches will catch up and the failure would "disappear." For GCC 11, that's bleeding edge, so it's more about future proofing and how that plan is put together. Cheers, Lincoln On Tue, Oct 6, 2020 at 9:03 AM Thomas Monjalon <thomas@monjalon.net> wrote: > 06/10/2020 14:52, Lincoln Lavoie: > > For Rawhide, our plan is to mark the failures as warnings instead, until > > things catch up on the other branches. Similarly, if we add something > like > > GCC 11 compile, I would suggest those failures are also a warning for > now. > > Sorry, I disagree with this plan. > As a non-regression tool, we are looking for green lights. > If a new test is not passing, it should not be added > until the original issue is fixed. > > Please don't add tests if they are failing, giving warning or error. > > Thanks > > > -- *Lincoln Lavoie* Senior Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m) <https://www.iol.unh.edu> [-- Attachment #2: Type: text/html, Size: 2600 bytes --]
06/10/2020 15:22, Lincoln Lavoie: > On Tue, Oct 6, 2020 at 9:03 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > 06/10/2020 14:52, Lincoln Lavoie: > > > For Rawhide, our plan is to mark the failures as warnings instead, until > > > things catch up on the other branches. Similarly, if we add something > > like > > > GCC 11 compile, I would suggest those failures are also a warning for > > now. > > > > Sorry, I disagree with this plan. > > As a non-regression tool, we are looking for green lights. > > If a new test is not passing, it should not be added > > until the original issue is fixed. > > > > Please don't add tests if they are failing, giving warning or error. > > For Rawhide, the failure is fixed, but I don't think it's ported to all > branches yet, so how would you want to handle that. Those branches will > catch up and the failure would "disappear." Yes it will disappear, nothing to do on the lab side. > For GCC 11, that's bleeding edge, so it's more about future proofing and > how that plan is put together. I propose you prepare the test, run once and send the report to dev and ci mailing lists. Then when we (maintainers) consider it should be fixed, we will ask you to test again. If the issue is fixed, you can add the test in the CI. Would it work?
Hi everyone,
Apologies for the issues this has caused. I have since added the
ability to store warning results on the dashboard.
I will be resending the result emails.
I have also fixed OpenSUSE builds and will be rerunning tests
throughout the day.
Thanks,
Brandon
On Tue, Oct 6, 2020 at 9:03 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 06/10/2020 14:52, Lincoln Lavoie:
> > For Rawhide, our plan is to mark the failures as warnings instead, until
> > things catch up on the other branches. Similarly, if we add something like
> > GCC 11 compile, I would suggest those failures are also a warning for now.
>
> Sorry, I disagree with this plan.
> As a non-regression tool, we are looking for green lights.
> If a new test is not passing, it should not be added
> until the original issue is fixed.
>
> Please don't add tests if they are failing, giving warning or error.
>
> Thanks
>
>
--
Brandon Lo
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
blo@iol.unh.edu
www.iol.unh.edu