Fixed buildroot so the project now builds on Ubuntu 18.10

[ShadowEO]

The project now builds on Ubuntu 18.10.

The changeset includes both my original changes, and these new ones:

• Removed $CC override in rebootp's makefile. (Why were we overriding the CC variable from buildroot?)
• Disabled the stripping from rebootp's package, it was failing out with 'File format not recognized'
• Updated the m4 package in buildroot, it used to fail out with fseeko errors due to a glibc change!
• Updated squashfs-tools, it was dieing while saying that there "Is not enough physical memory available" (thank Berryboot for the fix, it was in their pull requests)
• Updated python to 2.7.15 (should fix the generate-posix-vars segfault, once again: Thanks BerryBoot!)
• Updated squashfs.mk to install the mksquashfs binary into the expected location.
• Updated bison in buildroot.

It requires the following packages host-side:

• libqt4-dev
• qt4-linguist-tools
• bsdtar

This supersedes my previous pull request, as it provides the buildroot with the ability to build under even newer Ubuntu versions than Trusty Tahr.

[ShadowEO]

I also wanted to note that I have successfully booted a generated image with this fork in QEMU (to a point. It gets to loading qt4, then stops with "Failed to find drive with PINN files." even though I have a virtual VFAT sdcard with it on it. I think it's just a QEMU quirk, I'll have to pull out a RPi and make sure, but it looks like images built using this fork are fine to boot and run.

[procount]

Thanks for doing this. I will test it out.
I don't recall having to install qt4-dev before.
qt4-linguistic tools and bsdtar are already pre-requisites.

[ShadowEO]

No problem, I had seen some forum posts claiming that qt4-linguist-tools didn't quite solve the .qm generation failures, so I added libqt4-dev as a precaution. The good news is that I did figure out that the error I was experiencing booting it under QEMU is apparently due to QEMU not emulating the storage properly.

I decided to give it a go because I was already trying to compile a copy of PINN for my own hobby project and was having so many problems building, so I took it upon myself as a personal challenge to see if I couldn't get this compiling under a newer Ubuntu version! The frustration was worth it though,
I learned some of how buildroot works and I feel very accomplished for my first actual community contribution!

[procount]

Your timing was impeccable as I was experiencing this same glib problem on a similar OS.
Our buildroot is quite old and later versions seem to have already addressed this issue, but advancing the the issue of buildroot has (historically) not been easy.
I've done a test build and it certainly seems to work.
Well done!

[ShadowEO]

I found that out the hard way ^_^;

I actually started trying to fix it when I ran into the same glib errors with the m4 package, which then took me down a rabbit hole of other updates 😂

It was quite a learning experience and I'm glad I could help out!

[lurch]

Hmmm, why has BISON_LICENSE changed from GPLv3+ to GPL-3.0+, but M4_LICENSE changed from GPLv3+ to GPLv3.0+ ?

Hmmmm part 2: https://buildroot.uclibc.org/downloads/manual/manual.html#_infrastructure_for_packages_with_specific_build_systems seems to suggest that the "SPDX short identifier" should be used, and the SPDX page that it links to lists GPL-3.0+ under the "Deprecated License Identifiers" section 😕 🤷‍♂️

Looks like "it's complicated" so feel free to ignore this comment if you want 😉

[ShadowEO]

A lot of the changes were lifted from other buildroots (like berryboot's version of buildroot, just copying and pasting) and I didn't really work to ensure that the makefile strings were completely correct while copying them, so I can't attest that they are all correct. I was just trying to get the project compiling tbh, so I was working quick any dirty (and it was past 3-4am by the time I finally got this compiling).

^_^; So my apologies for the confusion on those clerical changes. I'll admit it was due to both my laziness and fatigue.

[lurch]

it was past 3-4am by the time I finally got this compiling

Been there, done that... 😂

[procount]

Merged.
I think it still might have problems on "Debian with Raspbian Desktop", but ok for me.

[procount]

There's a teensy problem with this PR because it prevents the ca-certificates package from generating the certificates to verify SSL connections.
A clean build that includes this PR results in /user/share/ca-certificates/mozilla being empty.
No idea why yet, but any help tracking it down would be useful.

[lurch]

Aha, I've found the problem... 😃

PINN uses an old version of buildroot, in which the host-tools get installed into buildroot/output/host/usr/bin/. In some later version of buildroot, they switched things so that host-tools get installed into buildroot/output/host/bin/ instead - https://git.busybox.net/buildroot/commit/package/python/python.mk?id=0f9c0bf3d5cdd2f99b66da7ab7e23c7b2bfb8c69
The version of buildroot used in BerryBoot is newer than the version of buildroot used in PINN, and so by directly copying the python.mk from BerryBoot into PINN, the symlinks created 0931a10#diff-c87eea10f525b1918288c93cccf757f2R231 end up being circular-links, and so python can't run, which means ca-certificates isn't able to run the script it needs to to create all the mozilla certs.

I'm now going out for the afternoon, but will try to look at creating a fix later... 🤞

[procount]

Great stuff!
So we were right about python and you were correct to follow the symlink trail.
I wasn't looking forward to reverting this PR after squashing it with the other mods.
I can relax now and look forward to your fix 😉

[procount]

@lurch - In fact, it was quite easy for me to revert this PR. So I now have a separate branch that will build v3.3a cleanly on Ubuntu 14.04. Which means we can work on these issues separately in parallel again without this holding us up.
I'm just wondering if I should publish this new branch, or switch this new branch to become the master branch. Would it help, or confuse?

[lurch]

I think it would just confuse, as I'm already half-way into fixing this 😉

[procount]

OK I'll leave as-is.
But just so I'm clear, what commit are you working from for this fix?

[ghost]

Building also needs texinfo, but it doesn't is a pre-requisite.

[lurch]

what commit are you working from for this fix

Whatever fix I come up with, I'll test and PR it against the HEAD of master 😃

[lurch]

Building also needs texinfo

I'll need to confirm later with further testing, but I think I've got a local fix for that...

[procount]

I don't have texinfo installed in Ubuntu, and I don't recall ever needing it. Is this Debian specific?

[lurch]

It is mentioned at https://github.com/procount/pinn/blob/master/README_PINN.md#how-to-rebuild-pinn 😉

[procount]

Very curious.

1. Then it is already mentioned as a pre-requisite.
2. I would have installed it since I copy and paste that line into my shell to install the pre-requisites.
3. I should have it, because my builds succeed.
4. Man texinfo displays correct help info.
5. texinfo in my shell returns "texinfo: command not found"

[lurch]

texinfo is the package-name, but it doesn't install any executables named texinfo. The executables it installs are:

$ dpkg -L texinfo | grep '/bin/'
/usr/bin/pdftexi2dvi
/usr/bin/txixml2texi
/usr/bin/texi2any
/usr/bin/pod2texi
/usr/bin/texi2pdf
/usr/bin/texindex
/usr/bin/texi2dvi
/usr/bin/makeinfo

[ghost]

I made a version with new buildroot, I'm testing it. PR for this is coming soon.

[lurch]

@raspberrypifan Oh, cool! Should I stop working on my fix and wait for your upgraded buildroot PR to drop?

[ghost]

@raspberrypifan Oh, cool! Should I stop working on my fix and wait for your upgraded buildroot PR to drop?

I don't know if it works, but I think it works, it's building right now, but I have some network problems now, so downloading takes much time.