OpenEmbedded Morty

Comments
Last week I spent a few days trying to use OpenADK, tried all kinds of targets and 32-bit and 64-bit hosts, simple basic configurations, always failures. I had the same experience when I tried it early 2016.
Strangely though, the project is active, so some people must be having success. It would have to be for very specific config and host system, details that are not provided.

So, I have moved on to OpenEmbedded. I wrote about this back in June 2016. It is one that does work. In fact, it is the only cross-compiler toolchain/sdk builder thingy that does work. My experience with OpenADK, Crosstool-NG and T2 is that they are all broken.

Here is my June 2016 blog post on OpenEmbedded:
http://barryk.org/news/?viewDetailed=00361

And Yocto, which uses OpenEmbedded:
http://barryk.org/news/?viewDetailed=00367

At that time, the stable release was named "Krogoth". It is now "Morty". See release notes:
https://wiki.yoctoproject.org/wiki/Releases

I want to create a new light-weight pup compiled from source, like I did with Quirky April, and earlier on there was Wary and Racy Puppy. These were built from packages compiled in T2. Unfortunately, T2 has become increasingly broken, and there is only one guy maintaining it.

So, there is only one choice left, OpenEmbedded. I don't know what extra functionality Yocto will bring to the table, so decided to stay with OE.
Right now, doing a target "core-image-sato-dev" build (for machine "qemux86-64", using glibc):
https://layers.openembedded.org/layerindex/recipe/659/

What I want to do is create a bunch of binary packages, that I can then import into woofQ and build a new Quirky.
I suppose it needs a name, so how about "OpenPup"? -- just did a search, can't find that name used anywhere.

Anyway, the OE build is chugging away right now. From prior experience, I have a high confidence that it will succeed.
Posted on 10 Apr 2017, 19:13 - Categories: Linux


Alpine x86_64 chrootable rootfs

Comments
I wanted to create chrootable filesystems for ARM and x86_64, using uClibc or MUSL, for the purpose of compiling some utilities statically.

Unfortunately, uClibc support is waning. It still remains my favourite though. My experience with MUSL has not been 100% positive, but anyway, Alpine Linux offers a superb way to create chrootable rootfs's.

Some time ago, I played with Sabotage, a MUSL-based distro, and had an awful time to get SeaMonkey to compile -- got there, but SM was partly broken. I have just noticed that SM 2.46 is in Alpine, that is good news, gives me some confidence to consider MUSL again.

Um, but Alpine's "armhf" binaries are only armv6. Not what I want. But maybe I will move onto the "aarch64", which is apparently armv8 -- considering that Raspberry Pi2 boards now have the 64-bit CPU, same as the Pi3.

I found this excellent wiki page, explains how to create a chrootable rootfs:
https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot

I am running Quirky x86_64 version 8.1.6, on my baby laptop (with 1TB USB drive hanging off it).

I followed the wiki instructions, and created a script, named 'chroot-x86_64':
#!/bin/sh

mirror=http://dl-cdn.alpinelinux.org/alpine
chroot_dir=alpine-rootfs-x86_64
branch=v3.5

cp /etc/resolv.conf ${chroot_dir}/etc/
mkdir -p ${chroot_dir}/root

mkdir -p ${chroot_dir}/etc/apk
echo "${mirror}/${branch}/main" > ${chroot_dir}/etc/apk/repositories

mount -o bind /dev ${chroot_dir}/dev
mount -t proc none ${chroot_dir}/proc
mount -o bind /sys ${chroot_dir}/sys

chroot ${chroot_dir} /bin/sh -l

sync
umount ${chroot_dir}/sys
umount ${chroot_dir}/proc
umount ${chroot_dir}/dev
<

Another script inside the rootfs, named 'rootfs-run-once', is run just once, after doing the chroot:
#!/bin/sh


rc-update add devfs sysinit
rc-update add dmesg sysinit
rc-update add mdev sysinit
rc-update add hwclock boot
rc-update add modules boot
rc-update add sysctl boot
rc-update add hostname boot
rc-update add bootmisc boot
rc-update add syslog boot
rc-update add mount-ro shutdown
rc-update add killprocs shutdown
rc-update add savecache shutdown

apk update
apk add alpine-sdk

echo 'kernel.grsecurity.chroot_deny_chmod = 0' >> /etc/sysctl.conf
sysctl -p
<

I have uploaded the result to ibiblio, it has the scripts inside it (65MB):
http://distro.ibiblio.org/quirky/alpine/x86_64/developer/alpine-rootfs-x86_64.tar.gz

OK, what I want to do next is compile busybox statically. As I recall, patches are required for MUSL, but that info should be somewhere in the Alpine developer repos -- just getting started with Alpine, don't know where to find things yet, nor do I know anything about the package management.

...if anyone reading this is familiar with Alpine, you are welcome to send me a PM on the Puppy Forum, I am "BarryK". Any of your thoughts and insights about Alpine are welcome. Forum:
http://murga-linux.com/puppy/

Alpine Linux home page:
https://alpinelinux.org/

Posted on 8 Apr 2017, 18:51 - Categories: Linux


Goodbye Ubuntu Touch

Comments
Ha ha, this morning I was considering installing Ubuntu Touch on my Nexus 5, as there is an image for it, that is, apparently, mostly working, except for bluetooth.
But, then ran across Mark Shuttleworth's recent announcement:
https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/

Now Ubuntu is going back to Gnome instead of Unity, and heading for Wayland instead of Mir!!!

Wow. Leaves me wondering though, will Ubuntu Touch actually die, or will the community take it up as an independent project?
There is some discussion about this here:
https://lists.launchpad.net/ubuntu-phone/
Posted on 7 Apr 2017, 8:29 - Categories: Linux


MaruOS version 0.4

Comments
Back in August 2016, I wrote about installing MaruOS version 0.2.3:
http://barryk.org/news/?viewDetailed=00390

Yesterday I installed version 0.4, running it right now, posting this blog report from it.

I have a Nexus 5, as reported in earlier blog posts, as well as the recommended SlimPort HDMI adaptor. I have bluetooth keyboard and mouse.

It is working OK, and reasonably snappy performance. There are two main things lacking, audio, and hardware acceleration for video.

Huh, screen went blank, had to press the power button momentarily on the phone to bring it back. The HDMI screen blanks out wen the phone screen does, which of course can be changed.

The phone is set to access the Internet via wi-fi, and that is working also in MaruOS.

For those who don't know, MaruOS is just an Android app. Though, it is a specially modified version of Android. A very barebones Android, very snappy performance.
Posted on 5 Apr 2017, 6:45 - Categories: Linux


Links for Ubuntu for Pi2

Comments
Right now, looking at building Easy Linux for the Raspberry Pi2 and Pi3. As did for Quirky 8.1.4.

As Easy/Quirky built with same DEBs as Ubuntu Mate for Pi2, what they have have done is very helpful to look at.

Here are some useful links. The ubuntu-pi-flavour-maker home site:
https://ubuntu-pi-flavour-maker.org/about/

The project code is hosted here:
https://code.launchpad.net/ubuntu-pi-flavour-maker

They use a lot of customized DEBs, that can be found here:
https://launchpad.net/~ubuntu-pi-flavour-makers/+archive/ubuntu/ppa/+packages

The Ubuntu Mate website also has a Pi page:
https://ubuntu-mate.org/raspberry-pi/
Posted on 30 Mar 2017, 10:04 - Categories: Linux


Pages: [1] [2] [3] [4] [5] [6] ...