Ill put it into "known issue" since IMHO a complete "resolved" would be when this feature exists in config-mode aswell.

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

Feel free to reopen it and update the task description, but I'm not expecting it to be implemented.

The thing is that adding this as op-mode only doesnt really solve anything.

I think the original request was Add ability to resequence rule numbers for firewall, and we added this tool.
Auto-Apply configuration based on this tool is the wrong way. We haven't had such hacks before and probably won't implement them in the nearest feature.
All configuration changes have to be only per user commit; there should not be any auto-commits/auto applies configs. We have API for these tricks.
CLI is completely different from the cisco/arista logic.

Also NAT-rules are in the need of a resequence feature in the config-mode:

I'm closing this task a solution was included. I'm not in favor of introducing similar command in configuration mode.

Maybe we should change firewall priority, and make sure all interfaces are defined in the system before loading firewall?

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

I dont think this is resolved.

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

Sorry for the noise - see workaround

When/If doing so it would be great if the docs would suggest for alternative methods to achieve the same thing.

We should make it clear that we are deprecating URL filtering with SquidGuard, not the whole web proxy service.

I'm re-opening until we make a final decision

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

The service webproxy is deprecated and will be removed in 1.5

Removed in https://github.com/vyos/vyos-1x/pull/3435

@syncer Any idea why conflict check fails for this PR https://github.com/vyos/vyos-1x/actions/runs/9015620312 ?

It can be handy to have the option to have it disabled (or you can just in bash-mode do "apt-get remove intel-microcode --purge" if you dont want it after install) but it should be enabled by default due to security reasons.

Ok,
Reviewers' assignment from the workflow can be removed (as it will be handled globally using codeowner file)
Raised PR,. Please check
https://github.com/vyos/vyos-1x/pull/3432

Please consider making the microcode updates optional, and possible to load a specified file downloaded separately from the CPU vendor, independent of VyOS updates.
Some possible edge cases:

• running VyOS in a VM (microcode update has no effect in the guest anyway, needs to be done in the hypervisor)
• microcode update released in a hurry breaks something, need to revert to an older one
• microcode update reduces performance, doesn't improve security of VyOS (because it's not a typical multi-user system with untrusted users who can run any programs)
• microcode update has important fixes, but it will take time before a new LTS is released, or VyOS can't be updated because the subscription has expired

I think this was resolved at some point, but I ended up removing it (the accept-protocol stuff) from my config since it didn't appear necessary and was causing issues, so I'm not certain.

For 1.4 also fixed

vyos@r1-right:~$ show version all | match "GNU C L"
ii  libc-bin                             2.36-9+deb12u7                   amd64        GNU C Library: Binaries
ii  libc-l10n                            2.36-9+deb12u7                   all          GNU C Library: localization files
ii  libc6:amd64                          2.36-9+deb12u7                   amd64        GNU C Library: Shared libraries
ii  locales                              2.36-9+deb12u7                   all          GNU C Library: National Language (locale) data [support]
vyos@r1-right:~$ 
vyos@r1-right:~$ show ver
Version:          VyOS 1.4-stable-202405090309
Release train:    sagitta

Fixed

vyos@r1-right:~$ show version all | match "GNU C L"
ii  libc-bin                             2.28-10+deb10u3                amd64        GNU C Library: Binaries
ii  libc-l10n                            2.28-10+deb10u3                all          GNU C Library: localization files
ii  libc6:amd64                          2.28-10+deb10u3                amd64        GNU C Library: Shared libraries
ii  locales                              2.28-10+deb10u3                all          GNU C Library: National Language (locale) data [support]
vyos@r1-right:~$ 
vyos@r1-right:~$ show version

there is some issue https://github.com/vyos/vyos-1x/actions/runs/9013844673/job/24765384018?pr=3431

Please approve https://github.com/vyos/vyos-1x/pull/3431

Added codeowner file and basis pr templates and checks
https://github.com/vyos/.github/pull/1
Please review the PR

set policy local-route doesn't make sense to me to have a geoip network group, however geoip in set policy route allows for greater flexibility while performing routing to ensure traffic traverse through specific destination for compliance and regulatory purposes.

@alainlamar can you check my PR https://github.com/vyos/vyos-1x/pull/3430 ?

Ok, Sure.

Added access to organization's .github repository
we probably want to keep PR templates and what else there too(will create separate task)

Sure, let's do it that way
Thanks @Vijayakumar

@syncer Just want to know whether we considered using the CODEOWNERS file to achieve this
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

Behavior change for this issue was fix some month ago in migration scripts, in order to remain action "return" when upgrading from older versions to new syntax.

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.