Package Details: frr 10.0-1

Git Clone URL: https://aur.archlinux.org/frr.git (read-only, click to copy)
Package Base: frr
Description: FRRouting (quagga fork) supports BGP4, OSPFv2, OSPFv3, ISIS, RIP, RIPng, PIM, LDP, BFD, VRRP, NHRP and EIGRP
Upstream URL: https://frrouting.org
Keywords: bgp ecmp isis ospf vrrp
Licenses: GPL2
Conflicts: babeld, quagga, quagga_cumulus
Provides: quagga, quagga_cumulus
Submitter: k0ste
Maintainer: k0ste
Last Packager: k0ste
Votes: 13
Popularity: 0.76
First Submitted: 2017-02-04 15:24 (UTC)
Last Updated: 2024-04-09 19:18 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

vecino commented on 2023-08-26 09:01 (UTC) (edited on 2023-08-26 09:03 (UTC) by vecino)

Hi @k0ste, just a little note, but maybe I'm wrong.

Switched to libyang minimum version 2.1.80!

The required minimum version for libyang is raised to 2.1.80. https://frrouting.org/release/9.0/ That means your package in the AUR repo should have: depends = libyang=2.1.80

Now I think it's wrong now because you allow even lower versions than 2.1.80: depends = libyang<=2.1.80

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=frr

k0ste commented on 2023-08-26 07:15 (UTC)

Message from David Lamparter:

Hi all,


we have discovered a rather insidious cross-package compatibility issue
between libyang 2.1.111 (released August 18th, 1 week ago) and all
existing FRR versions using libyang2.  Discussion has been happening on
https://github.com/CESNET/libyang/issues/2090 with relevant commit
https://github.com/CESNET/libyang/commit/32f067fecd084f07a03f8bf084f0abaf9c142927
(in case you are applying individual commits e.g. for a stable package)

Using libyang 2.1.111 with FRR will result in silent configuration
corruption - some FRR configuration statements will simply disappear.
Note that one of the statements affected is in route filtering and may
constitute security-critical configuration the user has made.  If you
are only superficially familiar with FRR operation, this is analog to
firewall rules disappearing.

The change in libyang was made to align better with the YANG RFC and is
not planned to be revisited, future FRR versions (9.1 and later) are
expected to be adjusted for the change in behavior.

Therefore, I would strongly advise all of you in your roles as package
maintainers to add a blocker to packages of libyang 2.1.111 or later, in
whatever way your package management system allows expressing:
 "not: frr < 9.1"

Please also note that stable releases may need to retain an installation
option for an older version of libyang (e.g. 2.1.80) if FRR is to remain
installable, as otherwise the package manager won't be able to find a
valid solution due to the blocker.


Alpine Linux and Arch Linux are already shipping 2.1.111 and thus
hardest hit by this issue.


I would like to apologize for the overhead and breakage caused by this,
particularly to Arch and Alpine maintainers.


-David / equi

vecino commented on 2023-08-09 07:03 (UTC)

I and everyone else who uses Frr thank you @k0ste.

k0ste commented on 2023-08-09 05:21 (UTC)

Thanks @vecino, updated!

vecino commented on 2023-08-08 20:39 (UTC) (edited on 2023-08-08 20:40 (UTC) by vecino)

FRR 9 needs the protobuf-c package and cannot be run without it. It needs to be added to "depends".

https://archlinux.org/packages/extra/x86_64/protobuf-c/

Aug 08 22:21:57 archlinux frrinit.sh[432]: /usr/lib/frr/watchfrr: error while loading shared libraries: libprotobuf-c.so.1: cannot open shared object file: No such file or directory

vecino commented on 2023-08-08 19:54 (UTC) (edited on 2023-08-08 19:54 (UTC) by vecino)

We need to repack to 9.0-3 :)

https://github.com/FRRouting/frr/releases/tag/frr-9.0 29a2a234175b89f69794e5276aa628acdbedb589c25cb3dc2c4bc53c4b7c062e frr-9.0.tar.gz

vecino commented on 2022-12-09 08:30 (UTC)

Excelent many thanks!

Everything works only when building it shows this. Is it ok?


configure: WARNING: unrecognized options: --enable-exampledir, --enable-systemd

vecino commented on 2022-12-06 21:22 (UTC)

Hi,

i try to create frr via yay and end up here:


61/63 Test #61: yanglint_in_list ..................   Passed    0.01 sec
      Start 62: yanglint_in_feature
62/63 Test #62: yanglint_in_feature ...............   Passed    0.01 sec
      Start 63: yanglint_in_completion
63/63 Test #63: yanglint_in_completion ............***Failed    1.01 sec

98% tests passed, 1 tests failed out of 63

Total Test time (real) =   3.80 sec

The following tests FAILED:
     63 - yanglint_in_completion (Failed)
Errors while running CTest
Output from these tests are in: /home/vecino/.cache/yay/libyang/src/libyang-2.1.4/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:71: test] Error 8
==> ERROR: A failure occurred in check().
    Aborting...
 -> error making: libyang

Please any tips?

k0ste commented on 2022-07-29 07:28 (UTC)

Hi, 'armv7h' was added

eugeneai commented on 2022-07-29 03:15 (UTC)

Hi! Add 'armv7h' to the architecture list. It compiles well on Orange Pi One ans functioning too.

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »