The new interface handling infrastructure is firmly in place now.

The last old-style definitions are gone, so the tool is no longer relevant.

The new firewall implementation solved it.

Since we do have proper support for IKEv2 remote access VPN, the issue of configuring it with a workaround is no longer relevant, I suppose.

Let's give it some thought for 1.5/Circinus.

It is impossible to create the config in question now.

I agree this is an issue, but it's a feature for the new configuration backend. Trying to fix it in the current legacy backend is likely futile.

Now the readthedocs process is well-established.

We have sorta decent contribution guidelines now, or so I hope. ;)

The use case for it will be addressed by the future support for true (ignored by the parser) comments.

The new firewall implementation by Nicholas et al. supports bridge firewalls.

I suppose with the new firewall implementation, this is no longer relevant.

With the migration to nftables, I suppose this is not relevant anymore.

With the current smoke test infrastructure, I'm inclined to call the original task resolved.

Neither 1.1.8 nor Crux are supported anymore.

I presume the issue is no longer relevant since people do successfully use QAT now, but feel free to reopen if anything.

If the issue is still relevant, feel free to reopen.

I suppose the current PKI CLI does fulfill the requirements of this task.

I don't think anyone saw this issue lately, but if it resurfaces, feel free to reopen the task.

Now that 1.4 is about to be released and 1.3 going into maintenance mode, we definitely will not include it in 1.3.6.

User creation works fine now.

Yes.

The dynamic DNS system has been revamped since then, so I assume this is no longer an issue, but feel free to reopen if it manifests again.

I'm closing this since no new details surfaced. If it's still relevant, feel free to reopen.

1.2 is now EOL, so no new changes will be made there.

Multiple people report both working UDP offload and firewall configurations, so I presume this issue is no longer relevant. Feel free to reopen if new details surface.

Could you try it locally and see what happens?

@Apachez I suppose it is.

• biosdevname is called by scripts in the initrd, so we can't remove it just yet.
• it's not completely abandoned and had quite a few releases since the point when Vyatta forked it.
• I sent a PR to allow biosdevname to run in VMs (that's the only thing that vyatta-biosdevname has and that's used in scripts): https://github.com/dell/biosdevname/pull/12