Bug#1070763: libyang2-dev needs move of header file for multi-arch compatibility

Package: libyang2-dev Version: 2.1.148-0.1 Severity: wishlist Tags: patch Hi all, the libyang2-dev package currently can't be installed in parallel for multi-arch build environments with mixed 32-bit and 64-bit architectures. The reason for this is that the content of

Bug#1006889: frr / bgp failing to insert routes on boot (usually ipv6, sometimes ipv4)

Hi Nick, (first of all, sorry, I kinda blanked out this bug report for some time, see below for why) On Mon, Mar 07, 2022 at 06:16:03PM +, Nick wrote: [...] >Because of the above, I checked out >/etc/systemd/system/multi-user.target.wants/frr.service and found >that it is set

Bug#1068953: new upstream (10.0)

I've managed to get sbuild crosscompile to work for hppa and found the problem (it's a missing "XREF_SETUP()" line, not that the error message would give any hint to that...) With that, I have 4 things to fix in the package: - postrm is missing cleanup for /var/lib/frr (piuparts failure) - stick

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

On Mon, Apr 29, 2024 at 06:05:08PM +0200, Daniel Baumann wrote: > my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've > fixed that locally but a build to confirming on an armel porterbox is > runnning before uploading 10.0-0.3 in some minutes.. I've synced in (all of) your

Bug#1068953: new upstream (10.0)

On Mon, Apr 29, 2024 at 06:46:00PM +0200, Daniel Baumann wrote: > On 4/29/24 18:31, David Lamparter wrote: > > Did you run into issues that forced you up to 2.1.148? The "officially > > listed" (= in configure.ac) requirement is 2.1.128, if we(upstream) > > missed

Bug#1068953: new upstream (10.0)

Quick offshoot mail on build details, ... On Mon, Apr 29, 2024 at 06:13:14PM +0200, Daniel Baumann wrote: > On 4/29/24 16:56, David Lamparter wrote: > > FRR definitely requires libyang 2.1.128. > > hm, frr 10 needs libyang2 2.1.148. Did you run into issues that forced yo

Bug#1068953: new upstream (10.0)

Hi Daniel, On Sun, Apr 14, 2024 at 08:40:29AM +0200, Daniel Baumann wrote: > it would be nice if you could upload the newly released frr version. If > you need/want help, I'm happy to do so, just let me know. Sorry about this... I've tried to improve this before, this problem is social in

Bug#1067077: atomic operations on 64-bit time_t

On Mon, Mar 18, 2024 at 12:42:56AM +0100, Sebastian Ramacher wrote: > Source: frr > Version: 9.1-0.1 > Justification: fails to build from source (but built successfully in the past) [...] > https://buildd.debian.org/status/fetch.php?pkg=frr=armel=9.1-0.1=1710631814=0 [...] >

Bug#1036061: frr: CVE-2023-31489

Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b for 8.4, pending pick-up together with fix for #1036062 / CVE-2023-31490. (Would bump to upstream 8.4.4 if that's acceptable?) -equi

Bug#1036062: frr: CVE-2023-31490

Argh, wrong bug, previous mail was for 1036061. On Tue, Jun 13, 2023 at 03:17:52PM +0200, David Lamparter wrote: > Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b on stable/8.4 > branch. CVE-2023-31489 / 1036062 was fixed upstream on master but not backported to 8.4 yet; now p

Bug#1036062: frr: CVE-2023-31490

Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b on stable/8.4 branch. Debian fix incoming with bump to 8.4.4 if that's OK? That wouldn't be a targeted security fix, but FRR minor versions are bugfix-only. -equi

Bug#1035829: frr: CVE-2022-43681 CVE-2022-40318 CVE-2022-40302

notfound 1035829 frr/8.4.2-1 stop On Tue, May 09, 2023 at 09:19:30PM +0200, Moritz Mühlenhoff wrote: > CVE-2022-43681[0]: > CVE-2022-40318[1]: > CVE-2022-40302[2]: All 3 issues are fixed/not present in 8.4 and thus also 8.4.2-1: - CVE-2022-43681 - 6c4ca9812976596bf8b5226600269fc4031f1422 -

Bug#1031018: maint-guide: outdated guidance in 4.1 re. -Indep fields

Source: maint-guide Version: 1.2.53 Severity: normal Dear Maintainer-Guide-Maintainers, maint-guide currently says in section 4.1: "Source packages which have binary packages with Architecture: any are rebuilt by the autobuilder. Since this autobuilder procedure installs only the packages

Bug#1023794: libyang2: Update libyang2 to latest master from CESNET

On Fri, Jan 06, 2023 at 05:14:07PM +0100, Marco d'Itri wrote: > I have uploaded 1.0.240 and opened a pull request upstream: > https://github.com/CESNET/libyang/pull/1966 . > > Switching to the 2.x branch requires more time that I cannot commit > right now, but I will be happy to sponsor

Bug#1017518: new upstream (8.3)

On Sun, Dec 11, 2022 at 12:55:46AM +0100, Marco d'Itri wrote: > On Aug 17, Daniel Baumann wrote: > > it would be nice if you could upgrade to the current upstream version of > > frr (8.3). > There has not been any progress on this or #1016978 in months, the > package is not in testing and the

Bug#948332: extended next hop capability not working in Buster

On Fri, Jan 17, 2020 at 02:01:30PM +0100, Thomas Goirand wrote: > David Lamparter wrote: > > could you maybe cherrypick the same patches from the 6.0 branch? > > The relevant commit IDs are > > e933c6dd9d62bf8ed09f5eb47d3f1cc59405a492 > > 048586179fe635ee01af371411

Bug#948332: extended next hop capability not working in Buster

Hi Thomas, could you maybe cherrypick the same patches from the 6.0 branch? The relevant commit IDs are e933c6dd9d62bf8ed09f5eb47d3f1cc59405a492 048586179fe635ee01af371411b81c49238e3581 This should come down to the exact same changes, just with a lower chance for error & is a bit more useful

Bug#946217: CVE-2019-19333 & CVE-2019-19334 in libyang

Package: libyang0.16 Version: 0.16.105-1 Tags: security Severity: grave This is a security issue tracking bug for CVEs: - CVE-2019-19333 - CVE-2019-19334 Both issues are bugs in processing YANG models and may affect users loading or validating untrusted YANG models. This is a relatively rare

Bug#944392: frr: /usr/share/man/man8/vrrpd.8.gz is already shipped by vrrpd

On Sat, Nov 09, 2019 at 03:33:05AM +0100, Andreas Beckmann wrote: > Package: frr > Version: 7.2-1 > Severity: serious > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files. [...] > dpkg: error processing archive >

Bug#929341: cinnamon-settings-daemon mis-built without wacom support

Package: cinnamon-settings-daemon Version: 3.8.4-2 Severity: important Dear Maximiliano, dear Debian maintainers, it seems that the cinnamon-settings-daemon package available in buster for amd64 was mis-built without wacom support. I have fetched the source package and compiled it on my local

Bug#921376: frr: missing Breaks+Replaces

Hi Andreas, I've added Conflicts: lines, as that seemed to be the most conservative option to me. ("Replaces: quagga" is a 'layer 9' discussion that I think it's a bit early to have at this point.) If you have any comments/opinions/input, I'd appreciate that. Diff is at:

Bug#921376: frr: missing Breaks+Replaces

Hi Andreas, Thanks for the report! On Mon, Feb 04, 2019 at 07:26:59PM +0100, Andreas Beckmann wrote: > if I understood the changelog entry correctly, frr is a successor to > quagga. There are a lot of Breaks+Replaces missing for taking over files > owned by quagga-*: FRR is indeed a (the?)

Bug#921349: frr: build dependency problems

Hi Adrian, On Mon, Feb 04, 2019 at 04:11:45PM +0200, Adrian Bunk wrote: > There are two bugs: > 1. build depending on the shared library package is >usually a bug, the -dev should pull in everything > 2. the unstable buildds only consider the first alternative Thanks for the report! Fix is

Bug#913339: RFS: libyang/0.16.52-1 ITP

.dsc More information about libyang can be obtained from https://www.example.com. This is the first upload of this package. Regards, David Lamparter

Bug#913219: ITP: libyang -- IETF YANG schema / data handling implementation

Package: wnpp Severity: wishlist https://github.com/CESNET/libyang This library processes IETF YANG schemas as well as data. It will be required by the FRR package (which is in ITP) at some point in the future. I'm working on packaging it.

Bug#911867: RFS: frr/6.0.1-1 [ITP]

On Sun, Oct 28, 2018 at 06:00:08PM +0200, Yavor Doganov wrote: > David Lamparter wrote: > > Symbols files are only applicable to libraries providing a stable ABI. > > This is explicitly not the case for FRRouting (hence also the 0.0.0 > > .so version.) > > Hm

Bug#911867: RFS: frr/6.0.1-1 [ITP]

Hi Herbert, Thanks for your input! FWIW I started out with a whole lot of lintian errors and warnings and am happy to be down to informational messages ;) On Sat, Oct 27, 2018 at 08:19:23AM -0300, Herbert Fortes wrote: > On 10/25/18 3:17 PM, David Lamparter wrote: > I no-symbols-c

Bug#911867: RFS: frr/6.0.1-1 [ITP]

ince the last upload is not applicable since this is the first upload. I expect there still is feedback that I need to address in regards to the Debian packaging on this and I will likely be uploading further revisions in the coming days. Regards, David Lamparter

Bug#863249: RFP: frr -- The FRR suite of dynamic routing protocols

Package: wnpp Severity: wishlist X-Debbugs-CC: Scott Leggett https://github.com/FRRouting/frr/ This is the successor fork to Quagga, forked off Q4 2016. By looking at recent commit activity, you can see that Quagga is essentially dead while FRR is rapidly moving forward.