Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes: o Automatic channel reloads based on RPKI changes o Multiple static routes with the same network o Use bitmaps to keep track of exported routes o Per-channel debug flags o CLI commands show info from multiple protocols o Linux: IPv4 routes with IPv6 nexthops o Filter: Optimized redesign of prefix sets o Filter: Improved type checking of user filters o Filter: New src/dst accessors for Flowspec and SADR o Filter: New 'weight' route attribute o Filter: BGP path mask loop operator o Filter: Remove quitbird command o RIP: Demand circuit support (RFC 2091) o BGP: New 'allow as sets' and 'enforce first as' options o BGP: Support for BGP hostname capability o BGP: Support for MD5SIG with dynamic BGP o BFD: Optional separation of IPv4 / IPv6 BFD instances o BFD: Per-peer session options o RPKI: Allow build without libSSH o RPKI: New 'ignore max length' option o OSPF: Redesign of handling of unnumbered PtPs o OSPF: Allow key id 0 in authentication o Babel: Use onlink flag for routes with unreachable next hop o Many bugfixes Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. BIRD now uses bitmaps to keep track of exported routes instead of re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory. Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts. So please test it, run it and write your feedback! Cheers Ondrej
On Sun, 21 Mar 2021, Ondrej Filip wrote:
So please test it, run it and write your feedback!
I'm sorry, but it looks like an old mistake [1] slipped in again: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird configure: error: unrecognized option: `--runstatedir=/run/bird' Try `./configure --help' for more information [1] https://bird.network.cz/pipermail/bird-users/2019-August/013629.html Regards, Robert
On 22. 03. 21 0:26, Robert Scheck wrote:
On Sun, 21 Mar 2021, Ondrej Filip wrote:
So please test it, run it and write your feedback!
I'm sorry, but it looks like an old mistake [1] slipped in again:
My fault, please reload the source again. :-( Ondrej
+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird configure: error: unrecognized option: `--runstatedir=/run/bird' Try `./configure --help' for more information
[1] https://bird.network.cz/pipermail/bird-users/2019-August/013629.html
Regards, Robert
Hello! When should there be a new Debian package built for it? Best regards, Skyler On 22/03/2021 0.57, Ondrej Filip wrote:
Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes:
o Automatic channel reloads based on RPKI changes
o Multiple static routes with the same network
o Use bitmaps to keep track of exported routes
o Per-channel debug flags
o CLI commands show info from multiple protocols
o Linux: IPv4 routes with IPv6 nexthops
o Filter: Optimized redesign of prefix sets
o Filter: Improved type checking of user filters
o Filter: New src/dst accessors for Flowspec and SADR
o Filter: New 'weight' route attribute
o Filter: BGP path mask loop operator
o Filter: Remove quitbird command
o RIP: Demand circuit support (RFC 2091)
o BGP: New 'allow as sets' and 'enforce first as' options
o BGP: Support for BGP hostname capability
o BGP: Support for MD5SIG with dynamic BGP
o BFD: Optional separation of IPv4 / IPv6 BFD instances
o BFD: Per-peer session options
o RPKI: Allow build without libSSH
o RPKI: New 'ignore max length' option
o OSPF: Redesign of handling of unnumbered PtPs
o OSPF: Allow key id 0 in authentication
o Babel: Use onlink flag for routes with unreachable next hop
o Many bugfixes
Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter.
BIRD now uses bitmaps to keep track of exported routes instead of
re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory.
Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts.
So please test it, run it and write your feedback!
Cheers Ondrej
Hey, thanks for the new release, looking forward especially to the RPKI reload! Atm it seems like the debian repo is broken (even though 2.0.8 not being there yet as Skyler pointed out): W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://bird.network.cz/debian buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org> W: Failed to fetch https://bird.network.cz/debian/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org> Thanks and all the best! u. On 22.03.21 05:29, Skyler Mäntysaari wrote:
Hello!
When should there be a new Debian package built for it?
Best regards, Skyler
On 22/03/2021 0.57, Ondrej Filip wrote:
Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes:
o Automatic channel reloads based on RPKI changes
o Multiple static routes with the same network
o Use bitmaps to keep track of exported routes
o Per-channel debug flags
o CLI commands show info from multiple protocols
o Linux: IPv4 routes with IPv6 nexthops
o Filter: Optimized redesign of prefix sets
o Filter: Improved type checking of user filters
o Filter: New src/dst accessors for Flowspec and SADR
o Filter: New 'weight' route attribute
o Filter: BGP path mask loop operator
o Filter: Remove quitbird command
o RIP: Demand circuit support (RFC 2091)
o BGP: New 'allow as sets' and 'enforce first as' options
o BGP: Support for BGP hostname capability
o BGP: Support for MD5SIG with dynamic BGP
o BFD: Optional separation of IPv4 / IPv6 BFD instances
o BFD: Per-peer session options
o RPKI: Allow build without libSSH
o RPKI: New 'ignore max length' option
o OSPF: Redesign of handling of unnumbered PtPs
o OSPF: Allow key id 0 in authentication
o Babel: Use onlink flag for routes with unreachable next hop
o Many bugfixes
Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter.
BIRD now uses bitmaps to keep track of exported routes instead of
re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory.
Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts.
So please test it, run it and write your feedback!
Cheers Ondrej
Hi, Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds. Best regards, Skyler On 22/03/2021 9.32, fatal wrote:
Hey,
thanks for the new release, looking forward especially to the RPKI reload!
Atm it seems like the debian repo is broken (even though 2.0.8 not being there yet as Skyler pointed out):
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://bird.network.cz/debian buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Failed to fetch https://bird.network.cz/debian/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
Thanks and all the best!
u.
On 22.03.21 05:29, Skyler Mäntysaari wrote:
Hello!
When should there be a new Debian package built for it?
Best regards, Skyler
On 22/03/2021 0.57, Ondrej Filip wrote:
Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes:
o Automatic channel reloads based on RPKI changes
o Multiple static routes with the same network
o Use bitmaps to keep track of exported routes
o Per-channel debug flags
o CLI commands show info from multiple protocols
o Linux: IPv4 routes with IPv6 nexthops
o Filter: Optimized redesign of prefix sets
o Filter: Improved type checking of user filters
o Filter: New src/dst accessors for Flowspec and SADR
o Filter: New 'weight' route attribute
o Filter: BGP path mask loop operator
o Filter: Remove quitbird command
o RIP: Demand circuit support (RFC 2091)
o BGP: New 'allow as sets' and 'enforce first as' options
o BGP: Support for BGP hostname capability
o BGP: Support for MD5SIG with dynamic BGP
o BFD: Optional separation of IPv4 / IPv6 BFD instances
o BFD: Per-peer session options
o RPKI: Allow build without libSSH
o RPKI: New 'ignore max length' option
o OSPF: Redesign of handling of unnumbered PtPs
o OSPF: Allow key id 0 in authentication
o Babel: Use onlink flag for routes with unreachable next hop
o Many bugfixes
Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter.
BIRD now uses bitmaps to keep track of exported routes instead of
re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory.
Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts.
So please test it, run it and write your feedback!
Cheers Ondrej
On Wed, Mar 24, 2021 at 07:03:57AM +0200, Skyler Mäntysaari wrote:
Hi,
Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds.
Hi Debian packages on bird.network.cz are done by Ondrej Sury, who is also Debian maintainer for BIRD. Used build scripts are (AFAIK) directly from Debian. In future, we want to add buiding of distribution packages to our CI code, so we would have all packages ready together with src release, but we are not there yet. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
I'm just trying to decide whether to create our own 2.0.8 packages or not. It would be fairly trivial, but it's always nicer to track upstream people via distro if possible, and so it just comes down to time scales for us. Do we have any feeling for how long it may take for packages to appear in http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu/ ? Cheers, Just On Wed, 24 Mar 2021 at 12:00, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Mar 24, 2021 at 07:03:57AM +0200, Skyler Mäntysaari wrote:
Hi,
Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds.
Hi
Debian packages on bird.network.cz are done by Ondrej Sury, who is also Debian maintainer for BIRD. Used build scripts are (AFAIK) directly from Debian.
In future, we want to add buiding of distribution packages to our CI code, so we would have all packages ready together with src release, but we are not there yet.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
I would love to be able to use the Debian packages, but those take quite a lot of time to get, it seems like. It would also help if the gitlab.nic.cz generated packages for mips64 and mipsel Debian as well. Could someone tell me all of the Debian packages I need to be able to build it? It complains about not being able to make docs for it when using the Debian packaging gitlab repo. On 07/04/2021 21.36, Justin Cattle wrote:
I'm just trying to decide whether to create our own 2.0.8 packages or not. It would be fairly trivial, but it's always nicer to track upstream people via distro if possible, and so it just comes down to time scales for us.
Do we have any feeling for how long it may take for packages to appear in http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu/ <http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu/> ?
Cheers, Just
On Wed, 24 Mar 2021 at 12:00, Ondrej Zajicek <santiago@crfreenet.org <mailto:santiago@crfreenet.org>> wrote:
On Wed, Mar 24, 2021 at 07:03:57AM +0200, Skyler Mäntysaari wrote: > Hi, > > Who is responsible for the Debian packages at the moment? > I couldn't find the build scripts for those at gitlab.nic.cz <http://gitlab.nic.cz> and would > like to get them so I can setup mips64 and mipsel architecture deb builds.
Hi
Debian packages on bird.network.cz <http://bird.network.cz> are done by Ondrej Sury, who is also Debian maintainer for BIRD. Used build scripts are (AFAIK) directly from Debian.
In future, we want to add buiding of distribution packages to our CI code, so we would have all packages ready together with src release, but we are not there yet.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org <mailto:santiago@crfreenet.org>) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net <http://wwwkeys.pgp.net>) "To err is human -- to blame it on a computer is even more so."
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
Hi, I would like to help as well. In September 2019 I contacted Ondřej Surý about releasing BIRD2 via Debian Backports (a prerequisite is having it in testing in the beginning). Not sure what happened (very likely I am to blame myself, but it's been a while...) but the contact stopped at some point. Maybe it's a good thing to revisit. I'll seek for my notes at the time and figure out where to pick up. Regards, Kees On 08-04-2021 02:09, Skyler Mäntysaari wrote:
I would love to be able to use the Debian packages, but those take quite a lot of time to get, it seems like. It would also help if the gitlab.nic.cz generated packages for mips64 and mipsel Debian as well.
Could someone tell me all of the Debian packages I need to be able to build it? It complains about not being able to make docs for it when using the Debian packaging gitlab repo.
On 07/04/2021 21.36, Justin Cattle wrote:
I'm just trying to decide whether to create our own 2.0.8 packages or not. It would be fairly trivial, but it's always nicer to track upstream people via distro if possible, and so it just comes down to time scales for us.
Do we have any feeling for how long it may take for packages to appear in http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu/ <http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu/> ?
Cheers, Just
On Wed, 24 Mar 2021 at 12:00, Ondrej Zajicek <santiago@crfreenet.org <mailto:santiago@crfreenet.org>> wrote:
On Wed, Mar 24, 2021 at 07:03:57AM +0200, Skyler Mäntysaari wrote: > Hi, > > Who is responsible for the Debian packages at the moment? > I couldn't find the build scripts for those at gitlab.nic.cz <http://gitlab.nic.cz> and would > like to get them so I can setup mips64 and mipsel architecture deb builds.
Hi
Debian packages on bird.network.cz <http://bird.network.cz> are done by Ondrej Sury, who is also Debian maintainer for BIRD. Used build scripts are (AFAIK) directly from Debian.
In future, we want to add buiding of distribution packages to our CI code, so we would have all packages ready together with src release, but we are not there yet.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org <mailto:santiago@crfreenet.org>) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net <http://wwwkeys.pgp.net>) "To err is human -- to blame it on a computer is even more so."
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
Hi again, It seems I found a Debian developer to sponsor me at the time but that didn't go through. I'll give it another try. Cheers, Kees On 08-04-2021 09:00, Kees Meijs | Nefos wrote:
I would like to help as well. In September 2019 I contacted Ondřej Surý about releasing BIRD2 via Debian Backports (a prerequisite is having it in testing in the beginning).
Not sure what happened (very likely I am to blame myself, but it's been a while...) but the contact stopped at some point. Maybe it's a good thing to revisit.
I'll seek for my notes at the time and figure out where to pick up.
Hi again, Just contacted Ondřej Surý and Benjamin Drung (he did the last commit) about helping out to bump https://salsa.debian.org/debian/bird2/ to 2.0.8. In parallel asked the backports list about adopting BIRD2 in Debian Backports. To be continued... Regards, Keee On 08-04-2021 09:06, Kees Meijs | Nefos wrote:
It seems I found a Debian developer to sponsor me at the time but that didn't go through. I'll give it another try.
Hi, Below are my steps I've done to import the new upstream version and build the package with git-buildpackage on a Debian Buster machine (or chroot). Please note that I didn't really look at the circumstances of the package and whether this is all appropriate with the new version, as it worked for me. This is also the reason I dropped the doc patch because I don't need the man within the package.
#Install prerequisites apt install git-buildpackage apt install pristine-tar #Build dependencies apt install bison debhelper docbook-xsl flex libncurses5-dev libreadline-dev libssh-gcrypt-dev linuxdoc-tools-latex m4 opensp quilt texlive-latex-extra xsltproc build-essential #Clone from debian Gitlab mkdir bird2 cd bird2 #Download current release (didn't get the ftp uscan working) wget https://bird.network.cz/download/bird-2.0.8.tar.gz gbp clone --pristine-tar https://salsa.debian.org/debian/bird2.git cd bird2 #Import new upstream version gbp import-orig ../bird-2.0.8.tar.gz #Generate changelog entry gbp dch git add debian/changelog git commit -m "Update changelog" #Remove patches # - 0001-Sync-the-linuxdoc-mangled-files-with-linuxdoc-tools_.patch: I had an issue with missing Latin1ToSgml.pm and I dont need the adjusments to the doc generation and will not install the doc package # - 0002-Added-missing-extern.patch: This change is already included in current release rm debian/patches/*.patch
debian/patches/series git add debian/patches git commit -m "Remove patches" # Create tag because during the build the latest tag (git describe) is set to BIRD_VERSION git tag -a "debian/2.0.8-1" #Build dpkg-buildpackage -us -uc Regards,
Peter
Hi again,
Just contacted Ondřej Surý and Benjamin Drung (he did the last commit) about helping out to bump https://salsa.debian.org/debian/bird2/ to 2.0.8.
In parallel asked the backports list about adopting BIRD2 in Debian Backports.
To be continued...
Regards, Keee
❦ 8 avril 2021 11:00 +02, Peter Hurtenbach:
Below are my steps I've done to import the new upstream version and build the package with git-buildpackage on a Debian Buster machine (or chroot).
A simpler alternative: apt install git-buildpackage pristine-tar pbuilder DIST=buster git-pbuilder create gbp clone https://salsa.debian.org/debian/bird2.git cd bird2 gbp import-orig --uscan (do what you did with the patches) dch -v 2.0.8-0 git commit -a -m "New upstream version" gbp buildpackage --git-pbuilder --git-dist=buster -- But, for my own part, it was Greek to me. -- William Shakespeare, "Julius Caesar"
Hi Peter, I followed your instructions, but the end result of that was just errors. Did you do something else to get it built? ------------------------------------------------------------------------------------------------------------------------------------------------ dpkg-buildpackage: info: source package bird2 dpkg-buildpackage: info: source version 2.0.8-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by root <root@debian-mips64el> dpkg-buildpackage: info: host architecture mips64el dpkg-source --before-build bird2 debian/rules clean dh clean dh: Compatibility levels before 5 are no longer supported (level 1 requested) debian/rules:21: recipe for target 'clean' failed make: *** [clean] Error 255 dpkg-buildpackage: error: debian/rules clean gave error exit status 2 ---------------------------------------------------------------------------------------------------------------------------------------------------- On 08/04/2021 12.00, Peter Hurtenbach wrote:
Hi,
Below are my steps I've done to import the new upstream version and build the package with git-buildpackage on a Debian Buster machine (or chroot).
Please note that I didn't really look at the circumstances of the package and whether this is all appropriate with the new version, as it worked for me. This is also the reason I dropped the doc patch because I don't need the man within the package.
#Install prerequisites apt install git-buildpackage apt install pristine-tar #Build dependencies apt install bison debhelper docbook-xsl flex libncurses5-dev libreadline-dev libssh-gcrypt-dev linuxdoc-tools-latex m4 opensp quilt texlive-latex-extra xsltproc build-essential #Clone from debian Gitlab mkdir bird2 cd bird2 #Download current release (didn't get the ftp uscan working) wget https://bird.network.cz/download/bird-2.0.8.tar.gz gbp clone --pristine-tar https://salsa.debian.org/debian/bird2.git cd bird2 #Import new upstream version gbp import-orig ../bird-2.0.8.tar.gz #Generate changelog entry gbp dch git add debian/changelog git commit -m "Update changelog" #Remove patches # - 0001-Sync-the-linuxdoc-mangled-files-with-linuxdoc-tools_.patch: I had an issue with missing Latin1ToSgml.pm and I dont need the adjusments to the doc generation and will not install the doc package # - 0002-Added-missing-extern.patch: This change is already included in current release rm debian/patches/*.patch
debian/patches/series git add debian/patches git commit -m "Remove patches" # Create tag because during the build the latest tag (git describe) is set to BIRD_VERSION git tag -a "debian/2.0.8-1" #Build dpkg-buildpackage -us -uc Regards,
Peter
Hi again,
Just contacted Ondřej Surý and Benjamin Drung (he did the last commit) about helping out to bump https://salsa.debian.org/debian/bird2/ to 2.0.8.
In parallel asked the backports list about adopting BIRD2 in Debian Backports.
To be continued...
Regards, Keee
The source packages are in the PPA, so it should be pretty easy to just bump the upstream and changlog then rebuild, as a starting point. Cheers, Just On Thu, 8 Apr 2021 at 08:09, Kees Meijs | Nefos <kees@nefos.nl> wrote:
Hi again,
It seems I found a Debian developer to sponsor me at the time but that didn't go through. I'll give it another try.
Cheers, Kees
On 08-04-2021 09:00, Kees Meijs | Nefos wrote:
I would like to help as well. In September 2019 I contacted Ondřej Surý about releasing BIRD2 via Debian Backports (a prerequisite is having it in testing in the beginning).
Not sure what happened (very likely I am to blame myself, but it's been a while...) but the contact stopped at some point. Maybe it's a good thing to revisit.
I'll seek for my notes at the time and figure out where to pick up.
-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
I completely agree. Very likely it's just downloading https://salsa.debian.org/debian/bird2/ and replace where needed and issue dpkg-buildpackage or alike. K. On 08-04-2021 09:45, Justin Cattle wrote:
The source packages are in the PPA, so it should be pretty easy to just bump the upstream and changlog then rebuild, as a starting point.
In addition: I'll set up a build environment and test with amd64 (x86_64) at least. What other architectures are "urgent" targets? On 08-04-2021 09:47, Kees Meijs | Nefos wrote:
I completely agree. Very likely it's just downloading https://salsa.debian.org/debian/bird2/ and replace where needed and issue dpkg-buildpackage or alike.
We are pretty much exclusively amd64 here. The current ppa pkg list looks like this however: amd64, arm64, armhf, i386, ppc64el I guess the Debian maintainers will be keen to keep parity, but I presume they have some infra for each of those targets. Cheers, Just On Thu, 8 Apr 2021 at 08:57, Kees Meijs | Nefos <kees@nefos.nl> wrote:
In addition: I'll set up a build environment and test with amd64 (x86_64) at least.
What other architectures are "urgent" targets?
On 08-04-2021 09:47, Kees Meijs | Nefos wrote:
I completely agree. Very likely it's just downloading https://salsa.debian.org/debian/bird2/ and replace where needed and issue dpkg-buildpackage or alike.
-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
Urgent targets in my case are amd64, mips64el/mips64 at least. On 08/04/2021 11.08, Justin Cattle wrote:
We are pretty much exclusively amd64 here.
The current ppa pkg list looks like this however: amd64, arm64, armhf, i386, ppc64el
I guess the Debian maintainers will be keen to keep parity, but I presume they have some infra for each of those targets.
Cheers, Just
On Thu, 8 Apr 2021 at 08:57, Kees Meijs | Nefos <kees@nefos.nl <mailto:kees@nefos.nl>> wrote:
In addition: I'll set up a build environment and test with amd64 (x86_64) at least.
What other architectures are "urgent" targets?
On 08-04-2021 09:47, Kees Meijs | Nefos wrote: > I completely agree. Very likely it's just downloading > https://salsa.debian.org/debian/bird2/ <https://salsa.debian.org/debian/bird2/> and replace where needed and > issue dpkg-buildpackage or alike.
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
I'm trying to avoid using a PPA for it, but I will setup a CI for the package when I do get it working without dep issues. On 08/04/2021 10.47, Kees Meijs | Nefos wrote:
I completely agree. Very likely it's just downloading https://salsa.debian.org/debian/bird2/ and replace where needed and issue dpkg-buildpackage or alike.
K.
On 08-04-2021 09:45, Justin Cattle wrote:
The source packages are in the PPA, so it should be pretty easy to just bump the upstream and changlog then rebuild, as a starting point.
Hello, I bring good news! I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird. Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released. I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped): https://salsa.debian.org/jruzicka/bird2 I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually. Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu. OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source. I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built. I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad. However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother. I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for. Thank you for your patience! Jakub Ružička CZ.NIC packager 📦
On Fri, Apr 09, 2021 at 04:55:15AM +0200, Jakub Ružička wrote:
Hello,
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages
Hello Welcome. That is great, hopefully we will have more streamlined process with new packages. What do you think about moving some Debian (and other distros') package-related data (e.g. debian/* files) from downstream (e.g. salsa.debian.org) directly to our bird git repository? Seems to me that if upstream (we) also publishes Debian packages, it would make sense these packages should be buildable using just data from upstream. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
I think that's a great idea and in fact I've been working on an integration with apkg the automation packaging tool I'm developing in order to allow easy packaging - you can see the changes here in my branch: https://gitlab.nic.cz/jruzicka/bird/-/tree/apkg A single new distro/ directory includes: * distro/pkg/deb: .deb package template from Debian * distro/pkg/rpm: rpm package template from Fedora * distro/script/make-obs.sh: use apkg to create OBS source package With these changes (not final) as well as some apkg fixes related to bird vs bird2 anyone will be able to build packages directly from project repo as well as from project archives(tarblls) with a simple command: apkg build You can see more info about apkg in docs: https://apkg.rtfd.io I don't want to hype that before it's complete but is should be fairly sweet. Cheers, Jakub Ružička On 4/9/21 5:12 AM, Ondrej Zajicek wrote:
On Fri, Apr 09, 2021 at 04:55:15AM +0200, Jakub Ružička wrote:
Hello,
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages Hello
Welcome. That is great, hopefully we will have more streamlined process with new packages. What do you think about moving some Debian (and other distros') package-related data (e.g. debian/* files) from downstream (e.g. salsa.debian.org) directly to our bird git repository? Seems to me that if upstream (we) also publishes Debian packages, it would make sense these packages should be buildable using just data from upstream.
Hello, That's great news! :) Regarding architectures, which ones does the SUSE CI support aka OBS? I don't think it supports mips64, which is needed. Kind regards, Skyler M On 09/04/2021 5.55, Jakub Ružička wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Hello, I'm happy to be both messenger and executor of good news™ :) You can get an idea about supported OBS archs for example here: https://build.opensuse.org/repositories/home:CZ-NIC:knot-resolver-latest/ I see x86_64, aarch64, armv7l and mips64 is indeed missing :( We'll probably going to need to use Debian downstream for that. Cheers, Jakub On 4/9/21 7:02 AM, Skyler Mäntysaari wrote:
Hello,
That's great news! :)
Regarding architectures, which ones does the SUSE CI support aka OBS? I don't think it supports mips64, which is needed.
Kind regards, Skyler M
On 09/04/2021 5.55, Jakub Ružička wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Hi Jakub, Nice, good job! Trying to prevent needless double work: are you in contact with Ondřej and Benjamin, or maybe others? And... how does your fork relate to https://salsa.debian.org/debian/bird2/ and other forks? I found other BIRD2 forks on Salsa, which surprises me a little. Lastly I still think it's a good idea to figure out if we could get BIRD2 in Backports (or maybe Fasttrack?). Regards, Kees On 09-04-2021 04:55, Jakub Ružička wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Hey Kees, thanks for your kind words, I'm happy to help! I've tired to contact Ondřej several times with varying degrees of success - he seems very busy so I'm dropping him from CC. I haven't contacted others, yet. I'll focus on taking over Debian package maintenance as soon as bird-2.0.8 is available from upstream repos. The repo you link is the official source of bird2 Debian packaging which I forked from because I don't have control yet (I think) and also it's Debian freeze so I'm not sure I should update debian/master as it can't reach bullseye. I'll figure that out eventually and let you know. Finally, backports are on my mid-term TODO when I get more confident with my Debian-fu. I'm not familiar with Fasttrack at all. It's preferable to have up-to-date packages available directly from downstream repos without the need to fiddle with external repos, but that isn't always possible in reality and that's where upstream repos come in. BTW backports still require modifying system sources.list like adding external repo - is it a big difference to use OBS (or any other upstream) instead of debian backports one (for the time being)? 🤔 Cheers, Jakub Ružička On 4/9/21 9:23 AM, Kees Meijs | Nefos wrote:
Hi Jakub,
Nice, good job!
Trying to prevent needless double work: are you in contact with Ondřej and Benjamin, or maybe others?
And... how does your fork relate to https://salsa.debian.org/debian/bird2/ and other forks? I found other BIRD2 forks on Salsa, which surprises me a little.
Lastly I still think it's a good idea to figure out if we could get BIRD2 in Backports (or maybe Fasttrack?).
Regards, Kees
On 09-04-2021 04:55, Jakub Ružička wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Hi Jakub, Good news: I found a sponsor willing to backport BIRD2 in Debian. Over the weekend I'll try to further prepare a .dsc that gets through lintian. Formally only packages (and versions) in testing are allowed in Backports. That is: 2.0.7-4.1 and not 2.0.8. I'll go for both versions and we'll see soon enough what will be accepted, or not. About modifying sources.list(.d): Debian Backports is Debian, not an alien repository. For most Debian purists like myself using Backports is okay but PPA or otherwise.... well... only if really-really-really needed. Cheers, Kees On 09-04-2021 12:02, Jakub Ružička wrote:
I've tired to contact Ondřej several times with varying degrees of success - he seems very busy so I'm dropping him from CC. I haven't contacted others, yet. I'll focus on taking over Debian package maintenance as soon as bird-2.0.8 is available from upstream repos.
The repo you link is the official source of bird2 Debian packaging which I forked from because I don't have control yet (I think) and also it's Debian freeze so I'm not sure I should update debian/master as it can't reach bullseye. I'll figure that out eventually and let you know.
Finally, backports are on my mid-term TODO when I get more confident with my Debian-fu. I'm not familiar with Fasttrack at all.
It's preferable to have up-to-date packages available directly from downstream repos without the need to fiddle with external repos, but that isn't always possible in reality and that's where upstream repos come in.
BTW backports still require modifying system sources.list like adding external repo - is it a big difference to use OBS (or any other upstream) instead of debian backports one (for the time being)? 🤔
Hi, Does that also mean that the backport build could leverage Debian's MIPS build systems? Reference: https://wiki.debian.org/MIPSPort On 10/04/2021 12.00, Kees Meijs | Nefos wrote:
Hi Jakub,
Good news: I found a sponsor willing to backport BIRD2 in Debian.
Over the weekend I'll try to further prepare a .dsc that gets through lintian.
Formally only packages (and versions) in testing are allowed in Backports. That is: 2.0.7-4.1 and not 2.0.8.
I'll go for both versions and we'll see soon enough what will be accepted, or not.
About modifying sources.list(.d): Debian Backports is Debian, not an alien repository. For most Debian purists like myself using Backports is okay but PPA or otherwise.... well... only if really-really-really needed.
Cheers, Kees
On 09-04-2021 12:02, Jakub Ružička wrote:
I've tired to contact Ondřej several times with varying degrees of success - he seems very busy so I'm dropping him from CC. I haven't contacted others, yet. I'll focus on taking over Debian package maintenance as soon as bird-2.0.8 is available from upstream repos.
The repo you link is the official source of bird2 Debian packaging which I forked from because I don't have control yet (I think) and also it's Debian freeze so I'm not sure I should update debian/master as it can't reach bullseye. I'll figure that out eventually and let you know.
Finally, backports are on my mid-term TODO when I get more confident with my Debian-fu. I'm not familiar with Fasttrack at all.
It's preferable to have up-to-date packages available directly from downstream repos without the need to fiddle with external repos, but that isn't always possible in reality and that's where upstream repos come in.
BTW backports still require modifying system sources.list like adding external repo - is it a big difference to use OBS (or any other upstream) instead of debian backports one (for the time being)? 🤔
On Sat, Apr 10, 2021 at 12:33:34PM +0300, Skyler Mäntysaari wrote:
Hi,
Reference: https://wiki.debian.org/MIPSPort
Hi BTW, we thought about adding some Edgerouter or similar hardware to our CI pool, as it seems to be the only reachable big-endian machine. What is the state of Debian on these machines? Could they run latest one or are they locked on some legacy version? Are they 32/64 bit? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Stuck on Debian stretch, 64-bit. 4.9.79-UBNT #1 SMP Wed Oct 28 16:51:13 UTC 2020 mips64 GNU/Linux On 10/04/2021 14.42, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 12:33:34PM +0300, Skyler Mäntysaari wrote:
Hi,
Reference: https://wiki.debian.org/MIPSPort Hi
BTW, we thought about adding some Edgerouter or similar hardware to our CI pool, as it seems to be the only reachable big-endian machine. What is the state of Debian on these machines? Could they run latest one or are they locked on some legacy version? Are they 32/64 bit?
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian. On 10/04/2021 14.44, Skyler Mäntysaari wrote:
Stuck on Debian stretch, 64-bit.
4.9.79-UBNT #1 SMP Wed Oct 28 16:51:13 UTC 2020 mips64 GNU/Linux
On 10/04/2021 14.42, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 12:33:34PM +0300, Skyler Mäntysaari wrote:
Hi,
Reference: https://wiki.debian.org/MIPSPort Hi
BTW, we thought about adding some Edgerouter or similar hardware to our CI pool, as it seems to be the only reachable big-endian machine. What is the state of Debian on these machines? Could they run latest one or are they locked on some legacy version? Are they 32/64 bit?
Sorry for the multiple replies in short period of time, but forgot to mention that some EdgeRouters do run on different architecture. EdgeRouter-X is the cheapest of the bunch, and it runs mipsel if I remember right. Someone can correct me, but it also has very low RAM, ~256MB-512MB. EdgeRouter-4 and EdgeRouter-12 run on mips64. On 10/04/2021 14.46, Skyler Mäntysaari wrote:
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian.
On 10/04/2021 14.44, Skyler Mäntysaari wrote:
Stuck on Debian stretch, 64-bit.
4.9.79-UBNT #1 SMP Wed Oct 28 16:51:13 UTC 2020 mips64 GNU/Linux
On 10/04/2021 14.42, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 12:33:34PM +0300, Skyler Mäntysaari wrote:
Hi,
Reference: https://wiki.debian.org/MIPSPort Hi
BTW, we thought about adding some Edgerouter or similar hardware to our CI pool, as it seems to be the only reachable big-endian machine. What is the state of Debian on these machines? Could they run latest one or are they locked on some legacy version? Are they 32/64 bit?
On Sat, Apr 10, 2021 at 02:46:25PM +0300, Skyler Mäntysaari wrote:
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian.
Several years ago, i run original Edgerouter (ERLite-3) with vanilla Debian, just with kernel from EdgeOS.
EdgeRouter-4 and EdgeRouter-12 run on mips64.
It is BE or LE? ERLite-3 was (AFAIK) mips (BE), Debian offers mips, mipsel (LE) and mips64el (LE), but no mips64. It is possible (but unlikely) that they build EdgeOS for a differench arch. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
I'm not sure, how would I check if it's LE or BE? CPU info on ER-12: --------------------------------------------------------------------------------------------------- system type : UBNT_E300 machine : Unknown processor : 0 cpu model : Cavium Octeon III V0.2 FPU V0.0 BogoMIPS : 2000.00 wait instruction : yes microsecond timers : yes tlb_entries : 256 extra interrupt vector : yes hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb] isa : mips1 mips2 mips3 mips4 mips5 mips64r2 ASEs implemented : vz shadow register sets : 1 kscratch registers : 4 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available ------------------------------------------------------------------------------------------------------ P.S Did you also use the UBNT kernel modules for hardware acceleration? On 10/04/2021 15.19, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 02:46:25PM +0300, Skyler Mäntysaari wrote:
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian. Several years ago, i run original Edgerouter (ERLite-3) with vanilla Debian, just with kernel from EdgeOS.
EdgeRouter-4 and EdgeRouter-12 run on mips64. It is BE or LE? ERLite-3 was (AFAIK) mips (BE), Debian offers mips, mipsel (LE) and mips64el (LE), but no mips64. It is possible (but unlikely) that they build EdgeOS for a differench arch.
Hej - sorry for being late to the game (this thread), but $dayjob kept me busy - what else is new... I have been an avid user of BIRD (1.x and 2.x) on the Ubiquiti platforms - on both major versions of "EdgeOS" and on both hardware platforms (Octeon → MIPS-BE and "the other" → MIPS-LE (all EdgeRouter X models)) Yes, I am using the original EdgeOS, which is just-another-debian-distro, namely: EdgeOS 1 → Debian 7.11 with "3.10.107-UBNT #1 SMP Fri Feb 21 09:19:25 UTC 2020 mips64 GNU/Linux" kernel and EdgeOS 2 → Debian 9.12 with "4.9.79-UBNT #1 SMP Thu Mar 5 16:48:40 UTC 2020 mips64 GNU/Linux" kernel. (on the Octeon platform → all EdgeRouters, except the "X" models, but versions are quite equal/similar/close) I have not built my own distribution (incl. a kernel with the HW-offloading supplements, etc.), because I actually liked EdgeOS - with the exception of the Quagga-Version (the non-FRR variant from Japan, if I recall right) that comes with it. However, if you do not configure anything in the "protocol" section of the EdgeOS/Vyatta configuration and create a bird.conf file and fire up BIRD instead everything (almost) works just fine. Yes, you can't see the routing config in the GUI, but I disable it anyway because I don't use it and want the memory for important things. Of course, "show bgp neighbors" would also be replaced by "birdc show protocols", etc. but this is just fine! I built my BIRDs directly on the routers themselves (just install "build-essential" and very few other packages), but since you talked about "distributions" here, be warned: A "firmware upgrade" wipes/reinstalls everything in the filesystem, except /config and below. Since you don't want to do a FW upgrade and have the box reboot without it's routing engine/daemon I compiled BIRD to live under /config/opt/bird1 or /config/opt/bird2 (or just /config/opt/bird ;-). Put a proper startup-script for it into /config/scripts/post-config.d and the BIRD shall be woken by EdgeOS, once all interfaces are plumbed and addressed and everything works very well - even after a firmware upgrade. BIRD binaries built for EdgeOS 1 even survive a FW upgrade to EdgeOS 2 this way, btw. (though you want BIRD 2 built on EdgeOS 2 to get the latest & gratest features → RPKI, for example) Just my 2¢ ... Clemens PS: We use this combination (among others) in parts of the IETF Meeting network for many years now. So if you have attended an IETF meeting (in person) since spring of 2014 (#89 → London) you are very likely to have been routed by it 😉 (yes, including all recent meetings in Praha!)
On 10. Apr 2021, at 14:23, Skyler Mäntysaari <sm@samip.fi> wrote:
I'm not sure, how would I check if it's LE or BE?
CPU info on ER-12: --------------------------------------------------------------------------------------------------- system type : UBNT_E300 machine : Unknown processor : 0 cpu model : Cavium Octeon III V0.2 FPU V0.0 BogoMIPS : 2000.00 wait instruction : yes microsecond timers : yes tlb_entries : 256 extra interrupt vector : yes hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb] isa : mips1 mips2 mips3 mips4 mips5 mips64r2 ASEs implemented : vz shadow register sets : 1 kscratch registers : 4 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available ------------------------------------------------------------------------------------------------------
P.S Did you also use the UBNT kernel modules for hardware acceleration?
On 10/04/2021 15.19, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 02:46:25PM +0300, Skyler Mäntysaari wrote:
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian. Several years ago, i run original Edgerouter (ERLite-3) with vanilla Debian, just with kernel from EdgeOS.
EdgeRouter-4 and EdgeRouter-12 run on mips64. It is BE or LE? ERLite-3 was (AFAIK) mips (BE), Debian offers mips, mipsel (LE) and mips64el (LE), but no mips64. It is possible (but unlikely) that they build EdgeOS for a differench arch.
I get where you're coming from, but as the actual automated package building for the EdgeRouter's is the goal, the building on the router itself is not very nice way to say host a jenkins agent on. The Debian package I have been using actually does put the configs in /etc/bird which makes sense, as it's basically a normal Debian in the eyes of the package. On 14/04/2021 22.09, Clemens Schrimpe wrote:
Hej -
sorry for being late to the game (this thread), but $dayjob kept me busy - what else is new...
I have been an avid user of BIRD (1.x and 2.x) on the Ubiquiti platforms - on both major versions of "EdgeOS" and on both hardware platforms (Octeon → MIPS-BE and "the other" → MIPS-LE (all EdgeRouter X models))
Yes, I am using the original EdgeOS, which is just-another-debian-distro, namely:
EdgeOS 1 → Debian 7.11 with "3.10.107-UBNT #1 SMP Fri Feb 21 09:19:25 UTC 2020 mips64 GNU/Linux" kernel and
EdgeOS 2 → Debian 9.12 with "4.9.79-UBNT #1 SMP Thu Mar 5 16:48:40 UTC 2020 mips64 GNU/Linux" kernel.
(on the Octeon platform → all EdgeRouters, except the "X" models, but versions are quite equal/similar/close)
I have not built my own distribution (incl. a kernel with the HW-offloading supplements, etc.), because I actually liked EdgeOS - with the exception of the Quagga-Version (the non-FRR variant from Japan, if I recall right) that comes with it.
However, if you do not configure anything in the "protocol" section of the EdgeOS/Vyatta configuration and create a /bird.conf/ file and fire up BIRD instead everything (almost) works just fine. Yes, you can't see the routing config in the GUI, but I disable it anyway because I don't use it and want the memory for important things. Of course, "show bgp neighbors" would also be replaced by "birdc show protocols", etc. but /this is just fine/!
I built my BIRDs directly on the routers themselves (just install "build-essential" and very few other packages), but since you talked about "distributions" here, be warned: A "firmware upgrade" *wipes/reinstalls everything in the filesystem*, *except /config and below*. Since you don't want to do a FW upgrade and have the box reboot without it's routing engine/daemon I compiled BIRD to live under /config/opt/bird1 or /config/opt/bird2 (or just /config/opt/bird ;-).
Put a proper startup-script for it into /config/scripts/post-config.d and the BIRD shall be woken by EdgeOS, once all interfaces are plumbed and addressed and everything works very well - even after a firmware upgrade. BIRD binaries built for EdgeOS 1 even survive a FW upgrade to EdgeOS 2 this way, btw. (though you want BIRD 2 built on EdgeOS 2 to get the latest & gratest features → RPKI, for example)
Just my 2¢ ...
Clemens
PS: We use this combination (among others) in parts of the IETF Meeting network for many years now. So if you have attended an IETF meeting (in person) since spring of 2014 (#89 → London) you are very likely to have been routed by it 😉 (yes, including all recent meetings in Praha!)
On 10. Apr 2021, at 14:23, Skyler Mäntysaari <sm@samip.fi <mailto:sm@samip.fi>> wrote:
I'm not sure, how would I check if it's LE or BE?
CPU info on ER-12: --------------------------------------------------------------------------------------------------- system type : UBNT_E300 machine : Unknown processor : 0 cpu model : Cavium Octeon III V0.2 FPU V0.0 BogoMIPS : 2000.00 wait instruction : yes microsecond timers : yes tlb_entries : 256 extra interrupt vector : yes hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb] isa : mips1 mips2 mips3 mips4 mips5 mips64r2 ASEs implemented : vz shadow register sets : 1 kscratch registers : 4 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available ------------------------------------------------------------------------------------------------------
P.S Did you also use the UBNT kernel modules for hardware acceleration?
On 10/04/2021 15.19, Ondrej Zajicek wrote:
On Sat, Apr 10, 2021 at 02:46:25PM +0300, Skyler Mäntysaari wrote:
Please also keep in mind that they do not run normal Debian, but EdgeOS which is a fork of vyatta which uses Debian. Several years ago, i run original Edgerouter (ERLite-3) with vanilla Debian, just with kernel from EdgeOS.
EdgeRouter-4 and EdgeRouter-12 run on mips64. It is BE or LE? ERLite-3 was (AFAIK) mips (BE), Debian offers mips, mipsel (LE) and mips64el (LE), but no mips64. It is possible (but unlikely) that they build EdgeOS for a differench arch.
The Debian package I have been using actually does put the configs in /etc/bird which makes sense, as it's basically a normal Debian in the eyes of the package.
You can make a package though, where everything lives under /config, preferably /config/opt - right? Like I said: Not a good idea to have your routing-engine and -config wiped after a software update. You can, however, put a "normal" BIRD install package into /config/data/firstboot/install-packages and have a script in /config/scripts/firstboot.d which may restore the config file (or a symlink to /config/bird.conf, which also survives the big culling). In that case the package gets re-installed early during the first boot after a FW update (and the script called). If the BIRD distribution depends on other packages, those also need to go into /config/data/firstboot/install-packages. And of course you need to have scripts updating the packages in /config/data/firstboot/install-packages, when you update them ... -c
I could yes, but is that something other people would prefer? On 14/04/2021 22.29, Clemens Schrimpe wrote:
The Debian package I have been using actually does put the configs in /etc/bird which makes sense, as it's basically a normal Debian in the eyes of the package.
You /can/ make a package though, where everything lives under /config, preferably /config/opt - right?
Like I said: Not a good idea to have your routing-engine and -config wiped after a software update.
You can, however, put a "normal" BIRD install package into /config/data/firstboot/install-packages and have a script in /config/scripts/firstboot.d which may restore the config file (or a symlink to /config/bird.conf, which also survives the big culling). In that case the package gets re-installed early during the first boot after a FW update (and the script called).
If the BIRD distribution depends on other packages, those also need to go into /config/data/firstboot/install-packages.
And of course you need to have scripts updating the packages in /config/data/firstboot/install-packages, when you update them ...
-c
Hey Kees, On 4/10/21 11:00 AM, Kees Meijs | Nefos wrote:
Hi Jakub,
Good news: I found a sponsor willing to backport BIRD2 in Debian. Awesome, thanks for help!
I'll probably be able to do debian backports in the future once I'm more faimilar with debian processes (so far I've only prepared packages for review and my sponsor did the rest) and I become bird maintainer but that isn't something to be rushed TBH so I appreciate the ability to focus on upstream packaging first and then smoothly take over downstream packaging once the time is right.
Over the weekend I'll try to further prepare a .dsc that gets through lintian. For your convenience this is a link to my salsa [fork] with debian/master, pristine-tar, and upstream branches updated for 2.0.8 as well as enabled Salsa CI and fixes for uscan:
[fork]: https://salsa.debian.org/jruzicka/bird2 Feel free to use any subset of those changes as you see fit. I was able to build unstable package but I got problems with docs on older Debian releases so some additional changes might be needed to backport.
Formally only packages (and versions) in testing are allowed in Backports. That is: 2.0.7-4.1 and not 2.0.8. I didn't push 2.0.8 to debian/master because I'm not sure how all that works during debian freeze... but I'm sure you're gonna figure that out :)
I'll go for both versions and we'll see soon enough what will be accepted, or not.
About modifying sources.list(.d): Debian Backports is Debian, not an alien repository. For most Debian purists like myself using Backports is okay but PPA or otherwise.... well... only if really-really-really needed.
Makes sense. It's certainly preferred to use official distro sources only. But that may take some time to propagate so my primary objective now is getting control over upstream packaging and get 2.0.8 packages out for users and eventually providing upstream packages right on release. After that I'll start working on making packages available from official distro repos but I see that community has that quite covered (most distros already have 2.0.8) so I plan to simply add bird to my packaging [tracker] and then it will be easy to see if some packages somewhere need updating. I need to add debian-backports there as well it seems. [tracker]: https://pkg.labs.nic.cz/
Cheers, Kees Cheers, Jakub 📦
Hi guys, Just posted the .dsc for Backports (buster) based on 2.0.7-4.1 for acceptance review. Given discussion about the version freeze in Debian I decided to await the outcome. Cheers, Kees On 10-04-2021 11:00, Kees Meijs | Nefos wrote:
Good news: I found a sponsor willing to backport BIRD2 in Debian.
Over the weekend I'll try to further prepare a .dsc that gets through lintian.
Formally only packages (and versions) in testing are allowed in Backports. That is: 2.0.7-4.1 and not 2.0.8.
I'll go for both versions and we'll see soon enough what will be accepted, or not.
Hi Jakuk, That sounds very positive :) I would vote for updating the Launchpad PPA too, at least for this point release it would be helpful for us. Thanks! Cheers, Just On Fri, 9 Apr 2021 at 03:58, Jakub Ružička <jakub.ruzicka@nic.cz> wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
Hey Justin, I managed to get bird2-2.0.8 packages built (and lightly tested) for all current Ubuntu versions in bird-experimental launchpad [1] 🥳 * Ubuntu 20.10 (Groovy Gorilla) * Ubuntu 20.04.2 LTS (Focal Fossa) * Ubuntu 18.04.5 LTS (Bionic Beaver) * Ubuntu 16.04.7 LTS (Xenial Xerus) However, when I started testing migration from current official bird launchpad [2] I noticed that bird2 doesn't really install on Ubuntu 16.04 Xenial Xerus (package not found after adding ppa even though it's displayed on the web 🤔) and 18.04 Bionic Beaver (init-system-helpers (>= 1.56~) isn't available, that is the same for Xenial even if the package was found). Ubuntu 19.04 Disco Dingo is rejected by launchpad as "disco is obsolete and will not accept new uploads." I've fixed build issues by relaxing deps and disabling -docs subpackage which was causing FTBFS on older distros. I'll try to re-enable docs in the future package builds and they remain available from downstream distro packages and more importantly online. But I'm still quite confused by the current state of the launchpad repo - can you confirm that [2] is the PPA you're using? Maybe there are some other unofficial ones? If so, on which Ubuntu version are you? Could you by any chance test upgrade on a testing system/VM/container with your setup by adding [1] and checking if bird2-2.0.8 does what you expect it to do before I push new packages to [2]? For example: sudo add-apt-repository ppa:cz.nic-labs/bird-experimental sudo apt install bird2 sudo systemctl status bird bird --version dpkg -l bird2 I wasn't sure how much testing I should do before pushing new packages into official launchpad but it seems broken to a point where there isn't a single upgrade path I could test so I reckon the sooner the better ¯\_(ツ)_/¯ [1]: https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird-experimental/ [2]: https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird Cheers, Jakub 📦 On 4/9/21 9:36 AM, Justin Cattle wrote:
Hi Jakuk,
That sounds very positive :) I would vote for updating the Launchpad PPA too, at least for this point release it would be helpful for us.
Thanks!
Cheers, Just
On Fri, 9 Apr 2021 at 03:58, Jakub Ružička <jakub.ruzicka@nic.cz <mailto:jakub.ruzicka@nic.cz>> wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2 <https://salsa.debian.org/jruzicka/bird2>
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
Hi Jakub, Thanks for working on this. You are correct about that issue with init-system-helpers , I had completely forgotten about it. We are running bird2 primarily on bionic, and I created a backport of init-system-helpers 1.56+nmu1~ubuntu18.04.1 and placed it in one of our internal repos to work around the for our use cases. I was not sure why init-system-helpers (>= 1.56~) was specified at the time, but I suspected it may have been because of the build system it was built on. Actually, it looks like it has been officially place in bionic backport snow too: https://packages.ubuntu.com/bionic-backports/init-system-helpers So, in summary, the ppa was not completely valid beforehand for bionic at least :) I think it would be better to include all deps in the PPA, so relevant versions of init-system-helpers too. Most production systems won't include the backports repo anyway. The other option is to try and work out if the dependency init-system-helpers (>= 1.56~) is valid, or just a build system signature artifact of some kind. Cheers, Just On Tue, 13 Apr 2021 at 21:39, Jakub Ružička <jakub.ruzicka@nic.cz> wrote:
Hey Justin,
I managed to get bird2-2.0.8 packages built (and lightly tested) for all current Ubuntu versions in bird-experimental launchpad [1] 🥳 * Ubuntu 20.10 (Groovy Gorilla)
* Ubuntu 20.04.2 LTS (Focal Fossa)
* Ubuntu 18.04.5 LTS (Bionic Beaver)
* Ubuntu 16.04.7 LTS (Xenial Xerus)
However, when I started testing migration from current official bird launchpad [2] I noticed that bird2 doesn't really install on Ubuntu 16.04 Xenial Xerus (package not found after adding ppa even though it's displayed on the web 🤔) and 18.04 Bionic Beaver (init-system-helpers (>= 1.56~) isn't available, that is the same for Xenial even if the package was found).
Ubuntu 19.04 Disco Dingo is rejected by launchpad as "disco is obsolete and will not accept new uploads."
I've fixed build issues by relaxing deps and disabling -docs subpackage which was causing FTBFS on older distros. I'll try to re-enable docs in the future package builds and they remain available from downstream distro packages and more importantly online.
But I'm still quite confused by the current state of the launchpad repo - can you confirm that [2] is the PPA you're using? Maybe there are some other unofficial ones? If so, on which Ubuntu version are you?
Could you by any chance test upgrade on a testing system/VM/container with your setup by adding [1] and checking if bird2-2.0.8 does what you expect it to do before I push new packages to [2]?
For example:
sudo add-apt-repository ppa:cz.nic-labs/bird-experimental sudo apt install bird2 sudo systemctl status bird bird --version dpkg -l bird2
I wasn't sure how much testing I should do before pushing new packages into official launchpad but it seems broken to a point where there isn't a single upgrade path I could test so I reckon the sooner the better ¯\_(ツ)_/¯
[1]: https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird-experimental/
[2]: https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird
Cheers, Jakub 📦
On 4/9/21 9:36 AM, Justin Cattle wrote:
Hi Jakuk,
That sounds very positive :) I would vote for updating the Launchpad PPA too, at least for this point release it would be helpful for us.
Thanks!
Cheers, Just
On Fri, 9 Apr 2021 at 03:58, Jakub Ružička <jakub.ruzicka@nic.cz> wrote:
Hello,
I bring good news!
I've been recently tasked with updating Debian and Ubuntu bird packages and I'm probably going to maintain all bird packaging (including Debian downstream) from now on as I do with Knot DNS and Knot Resolver packages which were also previously maintained by Ondra Surý the current official Debian bird package Maintainer. He agreed to pass the maintenance of bird and bird2 Debian packages to me as well. Please note that I'm a fresh Debian Maintainer, not a Debian Developer (yet?) so my powers are slightly limited but I've been able to solve all Debian packaging tasks so far with the kind help of my awesome sponsor and mentors and I intend to do the same for bird.
Debian unstable is in hard freeze and bird2 Debian package doesn't have autopkgtests which means it can't be updated until Debian 11 Bullseye is released.
I've prepared bird2-2.0.8 on my Salsa fork and I also enabled Salsa CI which is green (some harmless blhc warnings and reproducible build are skipped):
https://salsa.debian.org/jruzicka/bird2
I'll make sure these changes will make it to Debian (and Ubuntu by transition) eventually.
Regarding upstream packages, I initially intended to update the bird launchpad you mentioned, but after a careful consideration I chose to leverage openSUSE Build Service (OBS) instead to provide wider platform support than just Ubuntu.
OBS is already used in Knot Resolver and Knot DNS projects for packaging and CI and while it has its share of problems, it currently provides best value for building upstream packages on many different distros and archs from shared packaging source.
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
I plan to announce the new OBS repos sometimes next week to provide Debian, Ubuntu, and hopefully SUSE packages as opposed to Ubuntu only through Launchpad.
However, after seeing your interest in the Launchpad repo, I'll see if I can get it updated as well to make the transition smoother.
I have bright plans for both upstream and downstream bird packaging but I'll share the them only after I'm done with bird-2.0.8 packages you've been waiting for.
Thank you for your patience!
Jakub Ružička CZ.NIC packager 📦
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
-- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
On 4/14/21 11:22 AM, Justin Cattle wrote:
Hi Jakub,
Thanks for working on this. My pleasure. After seeing how community has downstream packaging covered (❤) and hitting some annoyances with OBS I decided I'm only going to use OBS for SUSE builds only and use respective community systems for each distro so the launchpad will continue to be official upstream repo for Ubuntu for the time being.
You are correct about that issue with init-system-helpers , I had completely forgotten about it.
We are running bird2 primarily on bionic, and I created a backport of init-system-helpers 1.56+nmu1~ubuntu18.04.1 and placed it in one of our internal repos to work around the for our use cases.
I was not sure why init-system-helpers (>= 1.56~) was specified at the time, but I suspected it may have been because of the build system it was built on.
Actually, it looks like it has been officially place in bionic backport snow too: https://packages.ubuntu.com/bionic-backports/init-system-helpers <https://packages.ubuntu.com/bionic-backports/init-system-helpers>
Oh, I see! I checked history and this versioned requirement was added as part of "Bump the dephelper compatibilty level to 12" in Debian package which is a change specific to latest debian release. It's quite likely that this specific version isn't in fact required so I removed the (>= 1.56~) part - it's always worth a try with default available system init-system-helpers. I see overly strict requires like this often when doing cross-distro packaging. Sometimes they are introduced to dodge specific bug but older version might still work. In fact the bird service worked on all my Ubuntu VMs with Xenial being special by bird service not enabled by default but it could be started normally. I suggest we try with relaxed init-system-helpers and see if it produces some issues, I didn't hit any in my light testing.
So, in summary, the ppa was not completely valid beforehand for bionic at least :) I think it would be better to include all deps in the PPA, so relevant versions of init-system-helpers too. Most production systems won't include the backports repo anyway. If we find issues with using any init-system-helpers, I can backport specific version into PPA but it's a system lib that affects other packages - it's better not to touch it at all if possible. Last resort.
The other option is to try and work out if the dependency init-system-helpers (>= 1.56~) is valid, or just a build system signature artifact of some kind. Correct :)
Seeing how broken current repo is, I wasn't affraid to update it with my current 2.0.8 packages including bionic ones so please go ahead, test and report any issues. https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird/ I'm going to send 2.0.8 packaging update including link to the updated launchpad later today or tomorrow so extra points for you if you test it and let me know before that ;)
Cheers, Just
Cheers, Jakub
On Wed, Apr 14, 2021 at 12:45:28PM +0200, Jakub Ružička wrote:
Oh, I see! I checked history and this versioned requirement was added as part of "Bump the dephelper compatibilty level to 12" in Debian package which is a change specific to latest debian release. It's quite likely that this specific version isn't in fact required so I removed the (>= 1.56~) part - it's always worth a try with default available system init-system-helpers. I see overly strict requires like this often when doing cross-distro packaging. Sometimes they are introduced to dodge specific bug but older version might still work.
Hi, some time ago i built Debian packages for older Debians (8, 9) and did some modifications (including decreasing debhelper compatibility level) in order to work with unmodified system (without upgrading init-system-helpers from Backports). It worked without problems (with init-system-helpers >= 1.22~ requirement), but needed some modifications to Debian control files. So it seems to me that in order to build packages for multiple Debian versions the simplest way is to have multiple Debian control files. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Wed, 14 Apr 2021 at 11:45, Jakub Ružička <jakub.ruzicka@nic.cz> wrote:
https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird/
I'm going to send 2.0.8 packaging update including link to the updated launchpad later today or tomorrow so extra points for you if you test it and let me know before that ;)
I've tested it and it's working for me - how many points do I get ? I did not test a build from scratch, so it still has the newer init-system-helpers, but I don't see a problem with that from what's been said above. Thanks ! Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
On Fri, 09 Apr 2021, Jakub Ružička wrote:
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built.
For Fedora and CentOS/RHEL, I would like to understand which benefits these OBS packages are going to bring, especially as they are not part of e.g. the regular Fedora repository like the Fedora bird RPM package is, that I am co-maintaining (yes, EPEL for CentOS/RHEL is not a default repository, but still very close, too). Further on, I would like to kindly suggest that you also have a look to these existing Fedora/EPEL packages to adopt distribution specific build or run-time optimizations, that the upstream RPM packages were lacking so far. Regards, Robert
On 4/9/21 9:52 AM, Robert Scheck wrote:
On Fri, 09 Apr 2021, Jakub Ružička wrote:
I already have bird2 packages built in a testing OBS repo for latest Debian, Ubuntu, Fedoras, and CentOS but there are some remaining issues with docs generation on older distro versions which I need to address. In worst case scenario I will temporarily drop doc packages in order to get bird built. For Fedora and CentOS/RHEL, I would like to understand which benefits these OBS packages are going to bring, especially as they are not part of e.g. the regular Fedora repository like the Fedora bird RPM package is, that I am co-maintaining (yes, EPEL for CentOS/RHEL is not a default repository, but still very close, too).
Further on, I would like to kindly suggest that you also have a look to these existing Fedora/EPEL packages to adopt distribution specific build or run-time optimizations, that the upstream RPM packages were lacking so far.
Regards, Robert Hello Robert,
there are no benefits for using upstream RPM packages compared to downstream packages available directly from distro repos thanks to your downstream package updates - thank you for taking care of that! Upstream packages are currently redundant from Fedora user PoV with downstream being up-to-date, but * OBS provides openSUSE packages too. Even though Fedora/CentOS RPMs often work on SUSE, native packages are prefered. * OBS is helpful in testing new changes packaging-wise, Knot projects make a nice use of that in their CI pipelines * upstream repos can be updated directly on release without the standard 7/14 days testing delay I've already looked at the Fedora package as you wisely suggest (I'm a Fedora packager too) and I used it as a base for the new upcoming upstream packaging as you can see here: https://gitlab.nic.cz/jruzicka/bird/-/blob/apkg/distro/pkg/rpm/bird.spec I'll open a MR for this when ready and I'll try to keep upstream and downstream packaging in sync as much as possible afterwards - it makes everyone's life easier that way. Cheers, Jakub Ružička
Hi, You can take a look at the Debian Git repository: https://salsa.debian.org/debian/bird2 Regards, Peter On 3/24/21 6:03 AM, Skyler Mäntysaari wrote:
Hi,
Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds.
Best regards, Skyler
On Wed, 24 Mar 2021 at 20:39, Peter Hurtenbach <mail@peter-hurtenbach.de> wrote:
You can take a look at the Debian Git repository: https://salsa.debian.org/debian/bird2
I suppose the CI/CD script is "slightly" outdated... https://salsa.debian.org/debian/bird2/-/blob/master/.gitlab-ci.yml (No mention of FreeBSD 12, Debian buster, Ubuntu > 16.04, etc.) /CH
On Thu, Mar 25, 2021 at 02:33:40PM +0100, Chriztoffer Hansen wrote:
On Wed, 24 Mar 2021 at 20:39, Peter Hurtenbach <mail@peter-hurtenbach.de> wrote:
You can take a look at the Debian Git repository: https://salsa.debian.org/debian/bird2
I suppose the CI/CD script is "slightly" outdated... https://salsa.debian.org/debian/bird2/-/blob/master/.gitlab-ci.yml (No mention of FreeBSD 12, Debian buster, Ubuntu > 16.04, etc.)
This CI/CD script is from upstream, so will be updated with transition to 2.0.8 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, Thank you for pointing me to the right place, but it seems that it wasn't as straightforward as I had hoped to get a deb out for 2.0.8. It's unable to find some docs related perl nodule? Where should I make a request for CI/CD build of mips64/mips Debian package? That would be really useful for people running Bird on things like EdgeRouter from Ubiquiti. In what kind of timeline does a new deb package get published usually? The current repository's key has expired which would also need to be something done to it. Regards, Skyler On Wed, Mar 24, 2021, at 21:39, Peter Hurtenbach wrote:
Hi,
You can take a look at the Debian Git repository: https://salsa.debian.org/debian/bird2
Regards,
Peter
On 3/24/21 6:03 AM, Skyler Mäntysaari wrote:
Hi,
Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds.
Best regards, Skyler
Hi, Just FYI, I pushed it to the gentoo tree: https://github.com/gentoo/gentoo/pull/20196 Alarig On Wed 24 Mar 2021 07:03:57 GMT, Skyler Mäntysaari wrote:
Hi,
Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds.
Best regards, Skyler
On 22/03/2021 9.32, fatal wrote:
Hey,
thanks for the new release, looking forward especially to the RPKI reload!
Atm it seems like the debian repo is broken (even though 2.0.8 not being there yet as Skyler pointed out):
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://bird.network.cz/debian buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Failed to fetch https://bird.network.cz/debian/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
Thanks and all the best!
u.
On 22.03.21 05:29, Skyler Mäntysaari wrote:
Hello!
When should there be a new Debian package built for it?
Best regards, Skyler
On 22/03/2021 0.57, Ondrej Filip wrote:
Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes:
o Automatic channel reloads based on RPKI changes
o Multiple static routes with the same network
o Use bitmaps to keep track of exported routes
o Per-channel debug flags
o CLI commands show info from multiple protocols
o Linux: IPv4 routes with IPv6 nexthops
o Filter: Optimized redesign of prefix sets
o Filter: Improved type checking of user filters
o Filter: New src/dst accessors for Flowspec and SADR
o Filter: New 'weight' route attribute
o Filter: BGP path mask loop operator
o Filter: Remove quitbird command
o RIP: Demand circuit support (RFC 2091)
o BGP: New 'allow as sets' and 'enforce first as' options
o BGP: Support for BGP hostname capability
o BGP: Support for MD5SIG with dynamic BGP
o BFD: Optional separation of IPv4 / IPv6 BFD instances
o BFD: Per-peer session options
o RPKI: Allow build without libSSH
o RPKI: New 'ignore max length' option
o OSPF: Redesign of handling of unnumbered PtPs
o OSPF: Allow key id 0 in authentication
o Babel: Use onlink flag for routes with unreachable next hop
o Many bugfixes
Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter.
BIRD now uses bitmaps to keep track of exported routes instead of
re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory.
Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts.
So please test it, run it and write your feedback!
Cheers Ondrej
Thanks a lot for the new release! I’ve upgraded a RR and a router, the build and the restart didn’t hit any issue so far. Cheers, -- Alarig
Hi all, Thank you all for the hard work! I was just testing this in the lab for: o Automatic channel reloads based on RPKI changes Which to me sounds like we do not have to do “birdc reload in all” anymore whenever ROAs change, but it doesn't seem to work for me yet :( Am I wrong in thinking that this fixed that or am I doing something wrong? If this is indeed is supposed to work as I think it is but isn’t then I'll open up a new thread :) Kind regards, Stefan -- Stefan Plug Network Engineer (EU) Phone: +49 160 2504854 ECIX, a Megaport company PEERING GmbH Tauentzienstraße 11 10789 Berlin Germany Office: +49 30 233 24 16-0 Web: www.ecix.net Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B Vertretungsberechtigte Geschäftsführung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and notify the sender.
Hi all Never mind, I found that I should also read the notes :D Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. Looks like this did the trick! Thanks again for the awesome work! -- Stefan Plug Network Engineer (EU) Phone: +49 160 2504854 ECIX, a Megaport company PEERING GmbH Tauentzienstraße 11 10789 Berlin Germany Office: +49 30 233 24 16-0 Web: www.ecix.net Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B Vertretungsberechtigte Geschäftsführung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and notify the sender.
On 23. Mar 2021, at 16:51, Stefan Plug <stefan.plug@megaport.com> wrote:
Hi all,
Thank you all for the hard work!
I was just testing this in the lab for: o Automatic channel reloads based on RPKI changes
Which to me sounds like we do not have to do “birdc reload in all” anymore whenever ROAs change, but it doesn't seem to work for me yet :( Am I wrong in thinking that this fixed that or am I doing something wrong?
If this is indeed is supposed to work as I think it is but isn’t then I'll open up a new thread :)
Kind regards,
Stefan
-- Stefan Plug Network Engineer (EU)
Phone: +49 160 2504854
ECIX, a Megaport company PEERING GmbH Tauentzienstraße 11 10789 Berlin Germany
Office: +49 30 233 24 16-0 Web: www.ecix.net
Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B Vertretungsberechtigte Geschäftsführung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and notify the sender.
On Tue, Mar 23, 2021 at 06:34:09PM +0100, Stefan Plug wrote:
Hi all
Never mind, I found that I should also read the notes :D Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. Looks like this did the trick!
Hi Yes, you should also get warning ("Automatic RPKI reload not active for import") when run without import table enabled. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
❦ 23 mars 2021 19:02 +01, Ondrej Zajicek:
Never mind, I found that I should also read the notes :D Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. Looks like this did the trick!
Yes, you should also get warning ("Automatic RPKI reload not active for import") when run without import table enabled.
Hey! How does `import table yes` interacts with `import keep filtered`? They look like the same, except the former is BGP specific. -- It usually takes more than three weeks to prepare a good impromptu speech. -- Mark Twain
On Tue, Mar 23, 2021 at 07:51:00PM +0100, Vincent Bernat wrote:
Never mind, I found that I should also read the notes :D Notes:
Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. Looks like this did the trick!
Yes, you should also get warning ("Automatic RPKI reload not active for import") when run without import table enabled.
Hey!
How does `import table yes` interacts with `import keep filtered`? They look like the same, except the former is BGP specific.
Hi They are two different ways to get similar results. The 'import keep filtered' keeps filtered routes in main table, while 'import table' keeps all pre-policy BGP routes in separate per-channel table. The 'import keep filtered' uses less memory (each received route is stored one times), while 'import table' stores accepted routes two times (pre-policy and post-policy). Main advantage of 'import table' is that it allows reloading import (e.g. after change of import filter/policy) without externally visible behavior (sending route refresh to peer), while 'import keep filtered' just allows examining rejected routes. They do not interact, you can enable both, but then you end with keeping each received route two times. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello List! On 3/21/21 11:57 PM, Ondrej Filip wrote:
o Filter: Optimized redesign of prefix sets
I was asked to inform you that this also means dropping the possibility of mixed IPv4 / IPv6 prefix sets. As for v2.0.8, it is forbidden to use both address families in one prefix set. We supposed that this change isn't worth mentioning as it was more of a bad design to allow these mixed sets. We hope there were no major problems with that. Maria
participants (15)
-
Alarig Le Lay -
Chriztoffer Hansen -
Clemens Schrimpe -
fatal -
Jakub Ružička -
Justin Cattle -
Kees Meijs | Nefos -
Maria Matejka -
Ondrej Filip -
Ondrej Zajicek -
Peter Hurtenbach -
Robert Scheck -
Skyler Mäntysaari -
Stefan Plug -
Vincent Bernat