Error installing packages in "super easy mode"

[eenblam]

I tried following the super easy way to build the firmware, first on master then on fixmeshonbootrebased. Got the same problem both times.

Steps:

• Created Ubuntu 16.04 instance on Digital Ocean; 4GB RAM, 80GB storage, 2 vCPU
• Followed steps described in README
  • ssh root@[ip build machine] 'bash -s' < create_build_machine.sh
  • ssh root@[ip build machine] '/opt/sudowrt-firmware/auto_build > /var/log/build.log 2>&1 &'

Got this during build:

...
Step 3/9 : RUN DEBIAN_FRONTEND=noninteractive apt-get install -yq       build-essential=11.6ubuntu6       subversion=1.8.8-1ubuntu3.3       libncurses5-dev=5.9+20140118-
1ubuntu1       zlib1g-dev=1:1.2.8.dfsg-1ubuntu1       gawk=1:4.0.1+dfsg-2.1ubuntu2       gcc-multilib=4:4.8.2-1ubuntu6       flex=2.5.35-10.1ubuntu2       git-core=1:1.9
.1-1ubuntu0.8       gettext=0.18.3.1-1ubuntu3       quilt=0.61-1       ccache=3.1.9-1       libssl-dev=1.0.1f-1ubuntu2.26       xsltproc=1.1.28-2build1       unzip=6.0-9
ubuntu1.5       python=2.7.5-5ubuntu3       wget=1.15-1ubuntu1.14.04.4
 ---> Running in 2d1d80e63d2f
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 zlib1g-dev : Depends: zlib1g (= 1:1.2.8.dfsg-1ubuntu1) but 1:1.2.8.dfsg-1ubuntu1.1 is to be installed
E: Unable to correct problems, you have held broken packages.
The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive apt-get install -yq       build-essential=11.6ubuntu6       subversion=1.8.8-1ubuntu3.3       libncurses5-dev=5.9+
20140118-1ubuntu1       zlib1g-dev=1:1.2.8.dfsg-1ubuntu1       gawk=1:4.0.1+dfsg-2.1ubuntu2       gcc-multilib=4:4.8.2-1ubuntu6       flex=2.5.35-10.1ubuntu2       git-c
ore=1:1.9.1-1ubuntu0.8       gettext=0.18.3.1-1ubuntu3       quilt=0.61-1       ccache=3.1.9-1       libssl-dev=1.0.1f-1ubuntu2.26       xsltproc=1.1.28-2build1       un
zip=6.0-9ubuntu1.5       python=2.7.5-5ubuntu3       wget=1.15-1ubuntu1.14.04.4' returned a non-zero code: 100
Unable to find image 'sudomesh/sudowrt-firmware:latest' locally
latest: Pulling from sudomesh/sudowrt-firmware
8284e13a281d: Pulling fs layer
...

I noticed the Dockerfile specified Ubuntu 14.04, so I tried the same with a 14.04 instance on Digital Ocean and got the same results.

[eenblam]

The build did complete, but something is breaking during autoconf with the resulting .bin. Tried twice; not going to debug that further until I resolve the zlib1g issue.

[gobengo]

@eenblam Looks like might just need to change end of version number from '1' to '1.1' over here https://github.com/sudomesh/sudowrt-firmware/blob/master/Dockerfile#L7

Or just remove version pin alltogether, per discussion #141 (comment)

Would do myself but wifi is blocking ssh ports :/

[eenblam]

@gobengo I gave that a go last week. Firmware built without showing any errors, but the resulting image couldn't autoconf because curl wasn't included for some reason.

[gobengo]

@eenblam @paidforby I found myself wondering 'if this is broken then why does travis pass?'.
https://travis-ci.org/sudomesh/sudowrt-firmware/builds

I'm guessing travis doesn't try this 'super easy mode' (IMO more explicit description/title of this build style would be helpful). Any reason it can't?

[eenblam]

Note - when I got a complete build last week using 1.1 instead of 1, I did use "easy mode" instead of "super easy mode." The latter rebuilds the docker container from scratch, so it's easier but takes longer.

[paidforby]

@eenblam latest commit might fix "super easy mode" (renamed to "building on a remote server"). auto_build just needed to be updated to reflect new build process. Though I'm pretty sure it will only work the first time because to do a rebuild, you should only run,

git pull
docker cp . sudowrt-build:/usr/local/sudowrt-firmware 
docker start -a sudowrt-build 

@gobengo agreed about more descriptive titles, it took me very long to understand the why the "hard" way was harder... addressed this in latest commit, along with some other minor revisions.

[paidforby]

@eenblam when you get a chance you should try re-running the firmware build "on a remote server" and see if it works. I believe the root cause of your issue has been resolved.

[eenblam]

@paidforby Might have some time some evening this week; thanks for the heads-up!