It is normal. In the debian way of doing things, debian/control of the kernel package is produced by running "debian/rules debian/control" (sic!), as it's architecture-dependent.

If this is set as defaults there must be a way to enable IPv4 unicast for selected peers?

Yes, both helium and lithium build again. Thanks!

Packages are rebuild, can you please retry?

Yes, just found that one as well. And it coincides with the moment the build started to fail.

I am afraid that this is caused by incorrectly built .debs after this:
https://phabricator.vyos.net/T26

Hello @Emma,
thanks for reporting this and welcome aboard!

case:
voip and mail server behind vyos
log parser on both servers create black list on shared resouce
vyos (in all branches of company) have firewall rule with this black list
profit

How about making firewall groups IPvAgnostic and have VyOS figure out which the correct IPvN is (depending on where you use it) in a somewhat systematic way. In FW it would be both in parallel, etc. The user would still be able to setup groups per IPvN as-is currently.

Firewall groups used ipset, it would be cool to use these groups in the nat rules too and soone (wlb test rules target address etc).
It is necessary to make global address groups based on ipset.

https://github.com/vyos/vyatta-quagga/commit/d9823008822c536dcd995a9d3c9ca444b85a66be
https://github.com/vyos/vyatta-quagga/commit/f58e94cb1c452faadb4dd86e347fd1945eee408d
https://github.com/vyos/vyatta-quagga/commit/d0d6f926cd7c842cd1818bacd469e91874ec5605

@Boltsie 'show dhcp client leases' should also be fixed in builds, for fast local testing remove /etc/dhcp/dhclient-exit-hooks.d/ddclient

ddclient hook is preventing other hooks from running, do i will delete it in the build script.

In T22#399, @UnicronNL wrote:

@Boltsie could you install http://dev.packages.vyos.net/vyos/pool/main/v/vyos-replace/vyos-replace_1.0_all.deb and let know if that solves the problem?

@Boltsie could you install http://dev.packages.vyos.net/vyos/pool/main/v/vyos-replace/vyos-replace_1.0_all.deb and let know if that solves the problem?

As you can see in the images below (left being VyOS 1.2 jessie vyos-999.201603222137-amd64.iso, right being 1.1.7), DHCP route is taken as a kernel route (which is most trusted route) instead of as a static route that can be handled by quagga as in 1.1.7.

This isn't related to the issue I was having with my ISP over the past few days - that was definitely something interesting though, and I'll write about it sometime. Let me fire up a test VM on one of the dev images and verify this again.

@Boltsie Did you figure out some more of this?
In IRC you said that the problem was due to dhcp and not wan load-balancing...

Nope, not responsible for this one :)

Just install package 'libpam-systemd' to resolve this