NFD

I don't see a reason to upgrade the 32-bit slaves from 14.04 to 16.04. They can be left untouched in my opinion. At least for the next several months, I expect 14.04 will be the most common platform employed by our users.

Reply to note-2:

Platform policy indicates that Ubuntu 14.04 32-bit becomes unsupported upon Ubuntu 16.04 release.

If you disagree with platform policy, discuss this matter on ndn-lib mailing list.

Well, it says it's optional:

Optional: The previous Ubuntu LTS release with the gcc which comes with apt, 32-bit, 2GB memory

So I'd say we keep the 14.04 32-bit slaves, in addition to the 16.04 slaves (both flavors) as required by the policy. Unless there's a hardware/resource shortage. These 14.04 32-bit slaves can be dropped in 6 months from now, when 16.10 is released, to avoid increasing the total number of VMs required by CI.

Davide Pesavento wrote:

So I'd say we keep the 14.04 32-bit slaves, in addition to the 16.04 slaves (both flavors) as required by the policy. Unless there's a hardware/resource shortage. These 14.04 32-bit slaves can be dropped in 6 months from now, when 16.10 is released, to avoid increasing the total number of VMs required by CI.

I see no issue with this. It would only be two more nodes.

16.04 32-bit nodes seem to be offline. What's up?

Junxiao Shi wrote:

16.04 32-bit nodes seem to be offline. What's up?

We were never able to get the official images to work, so we're using an unofficial image. However, this only provides a 64-bit image. We figured it was better to have 64-bit nodes and no 32-bit nodes than no 16.04 nodes at all.

I'm still testing out Vagrant images every once and a while to see if I can finally deploy the 32-bit nodes.

We were never able to get the official images to work

Is the issue with "getting the official images to work with VirtualBox+Vagrant" or "getting Jenkins agent work in the official images"?

What's the specific error?

Is there a bug report at the upstream (either Ubuntu-cloudimg or Vagrant or Jenkins)?

There are tons of issues with ubuntu/xenial[32|64] vagrant images. Here a "short" list of issues that exist and nobody seem to be fixing them.

One of the critical for us is tiny disk space. In last few days I was looking how to improve things in an automated fashion (it can be done manually).

I notice the 8GB disk space when I deploy my devbox.
I'm adding a secondary disk with a method from http://stackoverflow.com/a/27515150 (the new disk is /dev/sdc), although I can't use my home directory but need to cd to elsewhere.

Two Ubuntu 16.04 32-bit nodes have been set up and appear to be building correctly.

Is there a problem with the CAlist of Ubuntu-16.04-32bit-ua-maestro-31820?

http://jenkins.named-data.net/job/ndn-cxx/3516/OS=Ubuntu-16.04-32bit/consoleText

Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress http://gerrit.named-data.net/ndn-cxx refs/changes/77/2877/8 --prune" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://gerrit.named-data.net/ndn-cxx/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Junxiao Shi wrote:

Is there a problem with the CAlist of Ubuntu-16.04-32bit-ua-maestro-31820?

http://jenkins.named-data.net/job/ndn-cxx/3516/OS=Ubuntu-16.04-32bit/consoleText

Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress http://gerrit.named-data.net/ndn-cxx refs/changes/77/2877/8 --prune" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://gerrit.named-data.net/ndn-cxx/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

The time on the both 32-bit nodes was set to before the issue date of the new Gerrit SSL certificate. I corrected the time and cloning now appears to work. I retriggered all recent builds that appeared to be affected by this issue.