It works for me. We need more details of your setup and your config to tell anything.

The lldpd package had really insufficient dependencies, it didn't even list libssl. This is why it wasn't rebuilt, we used apt-cache rdepend to find the packages that depend on libssl0.9.8, and due to missing dependencies this one didn't show up.

I could reproduce the bug. This doesn't appear to be an easy fix though.

Well, it *is* a stupid SEO thing. This person created two seemingly valid (even if irrelevant) tasks that include a link to some website unrelated to the task content. I think we should block @jensenbreck right away.

I've done pkg-release in that package to include the latest commits into debian changelog and update the package version (helium4 now).

The issue was with variable scoping, the variable for server subnet that was supposed to be global was instead updated in the local scope.

@UnicronNL Just to make sure, the package included in helium now is also patched?

@c-po I agree. By now I have a way better prototype of that thing than the original. I'll make a task about it.

If you want multiple interfaces with the same properties as the loopback, use dummy interfaces.

@S3m1r6 Could you test this image? http://dev.packages.vyos.net/iso/testing/vyos-1.1.8-rc2-amd64.iso I tested loading a config similar to yours (with ingress/egress QoS values added to make sure they get processed) and it works for me.

Not resolved yet. ;)

An AMI updated by hand was submitted to Amazon for testing.

Thanks, I'm looking at it now.

The only remotely sensible use case I can see is active/standby bonding of L2 VPNs to provide redundant paths. But then again, the real answer to this is distributed switches such as openvswitch.

BGP configuration is definitely loaded after VTI configuration is loaded.

Fixed in both 1.1.8 and current.

Well spotted! Fixed the typos.

Should we add it to 1.1.8? It's a pretty big change, I'm not sure if it should be in a maintenance rather than a major release.

The commit is indeed in helium now.

Imported it to 1.1.8: https://github.com/vyos/vyatta-cfg-quagga/commit/973afef2f599538ccda19a2befcf16e6730eaad2

That commit was in helium as well, but the real issue was in the debian install file: those paths were missing from it, so templates were generated but not included in the package.

Imported into 1.1.8

@UnicronNL The debian repo for helium is here: http://dev.packages.vyos.net/legacy/repos/debian/helium/

Fixed 1, 2, and 3.

Yes, @Tania and I are working on the rewrite.

Create a new repo (dev.packages.vyos.net/debian) and moved hvinfo to there.

https://github.com/vyos/vyos-1x/commit/ecdbe7b6fb64ae7d27d9147aa2c4a55b3a491735
https://github.com/vyos/vyos-1x/commit/5404d4108b510765150c2ac54098cd26ec18a683

The current implementation with postfix aliases is/was a bit problematic because all spam sent to it is forwarded to all members, and the mail servers where member addresses are get upset with mine and report me to spam lists.

I've merged the quagga pull request. Do you have implementation of the CLI for it, or shall I add it?

@c-po The post I made yesterday (http://blog.vyos.net/vyos-development-digest-number-10), the vyos-1x package is pretty much that, the future single package for all config scripts and data. I would be reluctant to put things that are not VyOS-specific into it though. With small things such as the mDNS repeater things get shaky of course. Something like PMACCT is a clear case, merging it into another package would be insanity. Those relays are small enough to make one wonder if they really need their own packages.

@JulesT I'm afraid Perl code is going to be around for quite a while, as many things need to be fixed before any rewrite of them can take place.
It's the code for new features that concerns me, not as much in the language as in the old approach that is not conductive to either automated testing or future implementation of transactional commit.

@JulesT 99% of new EdgeOS code is proprietary. I see no reason to stick with it for the tiny open source bits they may release once in a while. EdgeOS could use their departure from Vyatta Core as a chance to rethink those decisions, but apparently due to time pressure they didn't... Now they are stuck with backporting UnionFS forever and never getting e.g. fully transactional commits or

And now that I've actually looked into it... ;)

I think before we call it finished, we should move those repos under vyos organization and give @c-po access to them (frankly, I also propose to add him to maintainers).

We should, but somehow I don't have write access to this task. We should find a way to change the default permissions so that all maintainers can do that.

@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.

https://github.com/vyos/build-iso/commit/180d2aab0156401f699025fa05451155389cf9ad

https://github.com/vyos/vyos-1x/commit/8cc396c20398e01f4af76d386d87a38811cead06
https://github.com/vyos/vyatta-cfg/commit/e55d9affac8159b09b503fca4a364192a24eb52e
https://github.com/vyos/vyatta-cfg/commit/be1dfd64f53776d299651d5347041f17a805aba1

Looks like phabricator hasn't picked up those commits for some reason...

Trying to use Debian Jessie fails because it doesn't have 3.18 kernel which is required for OverlayFS support.

I have no idea what you are doing, but: 1) overlayfs is used for the livecd union mount and NOT for config sessions 2) for config sessions, a userspace implementation of unionfs (unionfs-fuse) is used.

What prevents you from adding it yourself by the way? The registration on wiki is open.

I think we can just reference it directly.

I've just done a quick test of the BatString.numeric_compare, looks perfect.

Already implemented in Config_tree.

This has nothing to do with vyconf. Please move it out of the project, and to vyos 1.2.0