https://github.com/vyos/vyatta-cfg/pull/83
https://github.com/vyos/vyos-1x/pull/3745
https://github.com/vyos/vyos-build/pull/680

I've submitted the PR at github: https://github.com/vyos/vyos-1x/pull/3743
There's no smoketest for this functionality, but I've build a qemu-live image and the commands seems to at least start running (instead of instantly crashing).

Would the project accept community contributions to Debianize more of the packages?
It is not clear what "no plans" really means - simply "no time for it right now, but community help is welcome" (understandable) or "we don't want it because ..." (please explain the reasons).

There are no plans to implement this

According to https://forum.vyos.io/t/building-rolling-apt-repo-with-deb-packages-from-source/14651/7 (I can't reply there - that thread is locked, and my account silenced) - "Jenkins build system is in process of deprecation."
This is news to me. Whatever the replacement will be, this feature request is not about deprecating Jenkins, but rather about Debianizing all of the source packages in the VyOS APT repo, in the same way some packages already are.
Search for *.dsc files in the current rolling-packages APT repo finds 21 of them, this is only a small part, it would be nice to see all packages there Debianized like this - this is what this feature request is about.
Then standard Debian tools can be used to rebuild *.deb packages from source packages. No need to search all of GitHub and assemble all parts.
Debian doesn't say "all source is in GitHub". Debian handles source packages as part of the standard packaging system. Debian is good. Please be like Debian. Thank you.

https://github.com/vyos/vyatta-wanloadbalance/pull/25

New PR that will allow targeting VRFs directly by name, to reach higher table IDs: https://github.com/vyos/vyos-1x/pull/3740

Using native nft tooling does not seem to help, I will keep investigating - seems to be very little information online on the topic, mostly people having the same issue as me.

Note that all Jenkins setup is in vyos-build: https://github.com/vyos/vyos-build/tree/current/packages

True, it is the user's responsibility to comply, no disagreement on that.
But a fairly simple change would make user's compliance easier, and it would be a win-win for everyone - why not?
Users who spend less time navigating a minefield of legal issues, could spend more doing useful things for the project.
It's not Invalid by any means. At least in my humble opinion - if you disagree, that's fine but please provide reasoned counter-arguments.

This was not about .deb packages in Debian itself, but from the VyOS APT repo used for building the rolling images.
Wishlist priority previously triaged (just 2 weeks ago) was fine, it's not Invalid - or at least have some civil discussion if we disagree on some points.
Quoting the GPL below, of course it's not legally required for other licenses like BSD, but still a good thing for any open source project anyway.

PR merged:
https://github.com/vyos/vyos-1x/pull/3692

source code from Debian is available on Debian repos

All source code is located in GitHub

It's user's responsibility to comply with trademark and copyright requirements

Will investigate!

The correct pass options without "

set interfaces openvpn vtun20 encryption ncp-ciphers 'aes256'
set interfaces openvpn vtun20 hash 'sha512'
set interfaces openvpn vtun20 mode 'server'
set interfaces openvpn vtun20 openvpn-option 'push keepalive 1 10'
set interfaces openvpn vtun20 server subnet '10.10.2.0/24'
set interfaces openvpn vtun20 server topology 'subnet'
set interfaces openvpn vtun20 tls ca-certificate 'ca'
set interfaces openvpn vtun20 tls certificate 'cert'
set interfaces openvpn vtun20 tls dh-params 'dh'

This could be achieved with conntrack ignore

set system conntrack ignore ipv4 rule 10 destination address '100.64.0.0/28'

vyos-vm-images has been archived

Provide the set of commands to reproduce

Still bug, the original config in the top of the task

vyos@r4# run show conf com | match "nat "
set nat source rule 100 destination port '5000-8000'
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 protocol 'tcp'
set nat source rule 100 source address '10.0.0.0/24'
set nat source rule 100 translation address 'masquerade'
[edit]
vyos@r4# 
[edit]
vyos@r4# run show nat source rules 
Rule    Source       Destination                    Proto    Out-Int    Translation
------  -----------  -----------------------------  -------  ---------  -------------
100     10.0.0.0/24  0.0.0.0/0                      IP       eth0       masquerade
        sport any    dport {'range': [5000, 8000]}
[edit]
vyos@r4# 
[edit]
vyos@r4# 
[edit]
vyos@r4# run show ver
Version:          VyOS 1.5-rolling-202406260020
Release train:    current
Release flavor:   generic

https://github.com/FRRouting/frr/issues/14368

We have ENV OCAML_VERSION 4.14.2 for both, @dmbaturin. Can we close it, or will you do an update to 5.0?

Not actual

vyos@r4:~$ show version all | match conntrack
ii  conntrack                            1:1.4.7-1+b2                     amd64        Program to modify the conntrack tables
ii  conntrackd                           1:1.4.7-1+b2                     amd64        Connection tracking daemon
ii  libnetfilter-conntrack3:amd64        1.0.9-1                          amd64        Netfilter netlink-conntrack library
vyos@r4:~$ 
vyos@r4:~$ show version 
Version:          VyOS 1.5-rolling-202406260020
Release train:    current
Release flavor:   generic

Try native nft commands for offload and check what it says.

# cat /tmp/offload.nft