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: