I moved the "task" part to T215.

Hi Carl,

Someone please remove the vyconf tag from this task, it has nothing to do with it. It can be added to 1.2.0 in fact!

Looks like it works, and the tests pass.

@thomas.courbon I think we fixed a similar bug before, but it seems the fix wasn't quite complete...

@hexes Could you update the task and specify which image you use and which error you get in it?

Looks like a bug indeed.

Hi Alex,

@Alexis I wish, with this shortage of contributors, we were really in position to make specific plans regarding the timeframe. ;)
This also applies to the security updates issue. We really need a dedicated security watcher, but, sadly, no one wants to take up this role, so it's always done in a haphazard manner, which is a bad experience for both end users and developers, but that's what we've got.
In a few years of project life, the number of people committed to using VyOS in production grew, but the number of people committed to developing it almost did not, it's still just a few people who have to do everything, and, frankly, it's taxing. At this point, none of us can turn it into a full time job (the commercial support thing @syncer and I started may change it in the future and give some of the maintainers guaranteed N hours a week to spend on it, but it's still a very early stage).

@Alexis By the way, if you are into the quagga source code, maybe you want to join the work on switching to the upstream or cumulus quagga and "forth-porting" vyatta changes to it?

@Alexis Please don't panic. This bug is only exploitable if RA handling is enabled in quagga, and by default it is not. Setting interface's IPv6 to autoconf doesn't enable it in zebra either.
I agree it should be included in 1.1.8, but it's not urgent. I suppose we'll build 1.1.8 some time next week anyway, there are other issues to be addressed.

Maybe really generic one should not reference specific companies, not sure.

I've added the mirror to the load balancer. Please add it to the wiki page: http://wiki.vyos.net/wiki/Mirrors
Also, what's your update interval?

Anything local should hardly be considered high priority, but the first one is remote. We definitely should include the fix in the 1.1.8

Hey, could you rename the task to make it more obvious what it's about. The default meaning of GCC is GNU Compiler Collection. ;)

Looks like a worthy endeavor.

I have some ideas why can it be... We'll have a look.

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

Could you tell us why these hostnames are wrong and what are the right hostnames you expected?

Well, I'll reiterate. Interactice SSH works fine to the device in question. The library is giving timeouts. Interactice SSH is not giving me timeouts. From this I deduce that the problem must be in the library, or in exscript.

Well, you realize that "execute one more time" is absolutely not an option for a library that is supposed to allow making configuration changes unattended from SDN controllers etc. among other things, right? ;)

Oops. Fixed, try now.

What we need for certain, other than git and build-essential, assuming the base system is minimal install:

Also, I can't edit this task sadly, but no way the difficulty is less than an hour... It's pretty involved, open-vm-tools source repo doesn't make it particulary easy to debianize...

@brona Do you know exact reproducing procedure?
We noticed this problem with Veeam Backup and Replication tool that uses quiescence, but we could never reproduce it simply by making a snapshot of a test VM.

For the jessie branch, we are likely staying with systemd, so systemd-related code will have to be added anyway.
Whether to remove the inittab-related code or not, not sure. I don't think we should implement both right away, but if we leave some room for extending it to support other init systems, it should be fine I think.

I think questions and tasks are not convertible.

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.

I'm waiting for someone to say the word "unprofessional". ;)

It's very interesting indeed. Its licensing is a total mystery. ;)

Interesting, we'll look into merging it.

Please push the accelerator fix, then I can configure Jenkins accordingly.

Removed the package repos from packages.vyos.net. I also moved the makeself-based update packs to dev.packages.vyos.net/legacy, it's unlikely that anyone wants them anymore, as they are ancient.
Next step is the repo for independent packages and ckeaning them up from the /vyos repo.

@UnicronNL Do you think we should redo the vyos-build job this way too?

Looks like the cron schedule setup from the web UI worked. Closing now, we can improve it later.

Fixed the jenkins job (https://ci.vyos.net/job/vyos-build) and set it to run every day at 02:00. We'll see if it works tomorrow.
The builds are at http://dev.packages.vyos.net/iso/current/amd64/

Now it works again. The format is a bit different from original: