Included in PR:
https://github.com/vyos/vyos-1x/pull/3587

PR:
https://github.com/vyos/vyos-1x/pull/3587
Companion PR's listed therein.

Fix link:
https://github.com/vyos/vyos-1x/pull/3529

PR:
https://github.com/vyos/vyos1x-config/pull/27

Difficulty changed to normal to consider one subtlety of xml cache, and add POC for use in (a later version of) the strip-private filter. POC below; some subset of commits may be added to 1.5:
https://github.com/vyos/vyos-1x/compare/current...jestabro:example-property-secret

PR merged into vyos-utils:
https://github.com/vyos/vyos-utils/pull/20
and backported. The fix has been tested with migration from 1.3.x with settings as suggested by @trae32566

Yes, @c-po that would be a reasonable explanation; the timeout was added for Equuleus by 1.3.4. Without a reporting user to ask; other reports on later version; or further information, I would vote to close ...

The argument would be to relax the url validator regex for compatibility with 1.3: since the plan is to replace this mechanism in 1.5 with something similar to @trae32566 suggestion above (brought up for discussion by @Viacheslav recently), and since it is deprecated/not advised anyway (RFC 3986). The simple change will be made to the validator.

Naive attempts to reproduce on 1.3.3 are not successful, yet (Vmware; KVM), but will continue to investigate; any other information is welcome @Viacheslav, should you recall ...

@matthewr Were all issues of this task resolved by the above discussions and the fix for T6131 ?

Note that T5996 has been backported and a full explanation is to be found in the previous comment. Close as resolved, with the needed workaround for earlier images.

This was a worthwhile investigation, with the goal of using Cython as a method of easily wrapping the standard netlink headers. Although workable, it appeared more trouble than it's worth, as one still has to cheat to navigate e.g. pass by reference (1), and limitations of Cython at the time (2). A much better approach would be a standard Python extension module ... set to 'on hold' for reference and until we have a plan for development, as has been recently discussed.

As c-po mentioned above, this was an interesting idea that was not workable; it was subsumed by the investigations in T3876.

@tjh in fact, this was a design decision, discussed with @Viacheslav at the time, and agreed upon, although neither of us are fully satisfied with the decision (and I'll let him amend these claims, if needed):

Checking a recent 1.5 build (1.5-rolling-202405090225), I do not see the discrepancy mentioned in the description: the result for 1.5 is also (just) missing vif entries, and one can observe that the syntax error in vif 2 causes cascading syntax errors in the other vif sections.
The following script recreates the effect of the XorpConfigParser:

Migration requires the config file to be in the standard syntax, such as produced by the system itself (set/del; commit; save) --- in this case, a configuration that can be loaded and saved on VyOS 1.3.5 would not be missing braces as above. If one needs to hand edit a config file, at the very least one needs to load/save on the source system before migration. The only weird corner case, linked above, is when a change of mac address triggers a rewrite by the ealry-legacy parser (only used in <= 1.3.x, and only in one remaining place in 1.3.x: vyatta_interface_rescan) --- that does produce incorrect syntax and is a known problem as described in the comment in T5611; that case is also restored by saving the config on the source image before system update and the resulting migration on reboot.

This will be possible after subtask T6006, for 1.5; backport can be considered at that time, but for now limit tags to Circinus.

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

See details and explanation in subtask T6327; notably, one can configure as system console, but setting at boot has limited use.

Note that the work in the link above, but for the get_commit_schedule function itself, has already been added in subtasks T6319/T6146. As mentioned above, the get_commit_schedule function is not useful (and potentially misleading) until we replace the legacy commit algorithm in 1.5. Remove 1.4.0 tag.