On 2/20/26 4:57 PM, Ihar Hrachyshka via dev wrote:
> On 2/20/26 2:35 AM, Frode Nordahl wrote:
>>
>> Hello, Ihar,
>>
>> On 2/19/26 23:15, Ihar Hrachyshka via dev wrote:
>>> Use Debian containers to avoid sudo and simplify job definition.
>>> Use debian:sid for DPDK builds to get libdpdk-dev >= 25.11, which is

Hi, Ihar.  Thanks for the patch, but I don't think we should use unstable
distributions in CI.  IMO, the only unstable thing in CI should be the
software under test.  The same reason why we don't use rawhide for rpm
build testing, and why we don't run OVN tests against ovn-k main branch
in the OVN project.  It is going to break and will become an emergency at
the most inconvenient moment.

If needed, we could turn on the dpdk-enabled builds in 3.3 and 3.4.  And
once 26.04 is enabled by GHA, we could turn off 3.3 and 3.4 and enable
dpdk-enabled deb builds on 3.7.  We have the matrix specification in the
test definition, it's just the matter of adding one line in there.
This was the original plan to do that kind of updates, but we didn't
follow this well.  Mostly, because it doesn't really add a lot of extra
coverage, especially if not running on the main branch.

Best regards, Ilya Maximets.

>>> not yet available in Ubuntu. Use debian:trixie for non-DPDK builds.
>>
>> The DPDK package in debian/sid is co-maintained by Ubuntu, and it ends
>> up in debian/sid and the current Ubuntu development release 
>> simultaneously.
>>
>> I have no opinion on whether you use the Debian development release or
>> the Ubuntu development release as base for your container, but please
>> don't make false statements in your commit messages.
> 
> Hi Frode,
> 
> Thanks for the clarification. I don't have a particular opinion about 
> Debian vs Ubuntu either. I didn't know Ubuntu prepares sid (like?) 
> containers to use, so I stuck to what I knew about. At the very least, I 
> will update the commit message.
> 
> For my understanding, is ubuntu:devel the equivalent of debian:sid? In 
> terms of access to latest libdpdk, will it receive further major version 
> updates like sid, in rolling fashion? Or will it stick to a version at 
> the time of debian:sid fork to ubuntu:devel branch? (Apologies if my 
> terminology is a bit off!)
> 
>>
>>
>>>
>>> Also set PYBUILD_SYSTEM=distutils in debian/rules to work around
>>> pybuild no longer auto-detecting setup.py on sid
>>> (https://bugs.debian.org/1126096).
>>
>> This is indeed needed, and I'd do this in a separate commit, perhaps
>> just forward then one that already fixed it in the Debian source? [0]
>>
>> 0:
>> https://salsa.debian.org/openstack-team/third-party/openvswitch/-/commit/328040e5f7d7092b8f835adedbb1a68e22d98570
>>  
>>
>>
>> -- 
>> Frode Nordahl
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to