Obviously the first step to my assignment was to download and build Jelly Bean.
1. Permissions on certain machines.
2. Which lead to a problem with Java 1.7 is installed, and you need 1.6 in order to build and run the make.
3. The time it takes for everything to download is slow. I mean, it took 10+ hours and multiple repo sync’s.
Permissions on Machines
Obviously the school wouldn’t give me admin rights on the computers, however, I just needed to run (I believe) only one command and I could have finished up the make process on their machines. The problem is, I couldn’t actually run “sudo update-alternatives –config java” to change from 1.7 to 1.6 (More on that later). Further, a lot of what I did do up until the actual download (That went surprisingly smoothly on the machine in the lab) seemed a bit backwards because I had to find workarounds between security setings. By the end after about three hours, I gave up on figuring out the Java problem and decided I’d try it all on a virtual the next day and see if I could get it to work on my own machine.
I ended up using Linux Mint as it’s based on Ubuntu, has more of the programs needed (Except for I found two specifically [bison and flex] and decided to just run their Ubuntu 12.04 lines:
sudo apt-get install git-core gnupg flex bison gperf build-essential \ zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \ libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 \ libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos \ python-markdown libxml2-utils xsltproc zlib1g-dev:i386
This worked perfectly fine on my virtual, even without the following linker line, I assume that the machine already had libgl set up, so no biggy.
Anyways, after this (And as I type this out), the build is running with the make. This brings a smaller problem, as to what number to put after the j in the “make -j#” command. I personally used 4 as it’s on a virtual and I didn’t want to really slow down my computer. But regardless, it’s building right now, so good!
Java 1.7 can not be used for the Jelly Bean build, Java 1.6 is needed
So this was an odd problem to me (Makes sense, with some methods being deprecated and from the warning message it actually used Java 1.5, not 1.6, but 1.6 was backwards compatible enough to work), and it is what ultimately made me use a virtual machine rather than doing it in the lab. The general solution was to just download the binary file, run, and do the update alternatives snippet (See above). This worked, however a little tip for future reference, you need to actually put the .bin in the /usr/bin and then chmod and execute it there (This allows it to be in your path). You can then do an update. However, I highly recomend following this post here by codingchyne. It’s what I followed, worked perfect. After this, it already set up the Java 1.6, so no need for the update alternatives.
So, this is where I feel a lot of newbies might be a bit surprised, and Dr. Mateti actually warned me about to begin with. This process takes… Long. As in, it took my 8-15 hours to actually update the repository. This is on about a decent connection. However, in the labs, I was getting a very fast connection (Friday evening, Saturday afternoon), so it only took about an hour there.
Now the build. As I said earlier, I already started the build. It’s been going at it for about an hour now, so obviously this is going to take some time. I use -j4, which means I’m using 4 threads on my PC to build this. In the lab, I want to try this again using -j32 and see if it really will finish this up in about two hours. Lastly, Dr. Mateti brought up that he wants the system to allow distributed computing, and I’d love to see how that works and perhaps push this to -j128 or some other amount that would make it build in only minutes. Maybe later on I can show a graph of speeds to thread numbers.
So what now?
Obviously, the build has to finish, and hopefully without errors. If it does, then awesome. If not, then no big deal, I have to talk to Dr. Mateti and see if I can get the Java versions switched so I can do this on there, and that’s where I’ll be doing most of my work. After this, I believe that I’ll be working on pruning, or as I’m looking it up, kernel work (Which I’m actually really interested in). This is probably going to take most of my time, and hopefully I can post updates on what I’m doing to the kernel and why. We’ll see though, the build might not even work, then we’re back at step one!