OE Pi2 desktop works

A quick progress report. The build in OpenEmbedded for the Raspberry Pi2 went well and I imported the binary packages into woofQ and created an SD-card image.

Got a desktop, however needs a lot more work.

Some old PETs used in the build, do not work. "ldd" reports that they are "not executable". This is a problem I have had before, do not understand why. With x86, old binary executables can be used, usually without any problem as long as shared library APIs haven't changed.
However, not so with ARM, even though they are all compiled for armv7.

This problem means that I will have to recompile a lot of packages. That is, packages that have not yet been imported into OE.

Tags: oe

Success building for Pi on OE

I am very impressed! Having used T2 for many years, where I would struggle for days trying to get packages to compile, this just sailed through.
Furthermore, it is a cross-build, which I have never been very successful with.

My complete package selection compiled, including kernel, kodi, firefox, gimp and libreoffice.
I had to take out nasm, yasm and xresprobe, as they are x86 only.

I am just now doing a rebuild from scratch, as there was one anomaly along the way, configuring mesa to be appropriate for the Pi. Although bitbake (the kind of "make on steroids" in OE) is very intelligent, I decided to do a complete clean rebuild.
That will take just over 9 hours.

Then the plan is to import the binary packages into woofQ and create a SD-image for the Pi2 (and Pi3).

I want to acknowledge the guys on the OE project who do all the hard work. It is a testimony to them, that I can come along with my package selection and have it all build, hardly without any issues, for x86_64 and Pi.

Tags: oe

Building for Pi2 on OpenEmbedded

Have just completed an x86 i586 build in OpenEmbedded, and imported the binary packages into woofQ. However, have put that one on the back-burner for now.

Have downloaded the layer for the Raspberry Pi:
https://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/

Also for the Hardkernel Odroid boards:
https://layers.openembedded.org/layerindex/branch/master/layer/meta-odroid/

I know very little about how these Board Support Package (BSP) layers work. So, starting off slowly. Right now, doing a small build for the Pi2, just a basic CLI interface.

What I have done so far, with Quirky and Easy, is just extract the binary packages out of OE, to woofQ. However, I want to learn how the whole thing, right to an SD-card image, is created in OE.

Read more...

Pyro for i586 coming

I have released alpha builds of "Pyro64", Quirky Linux and Easy Linux built from binary packages compiled in OpenEmbedded.
This is for PCs with a x86_64 CPU.

OpenEmbedded is a cross-compiler, so in theory I can just change the specification for the target architecture, and off it will go, compile all the packages for that architecture.

So, I have given it a first test. I am running Quirky 8.1.6, a x86_64 distro. I configured OpenEmbedded to compile for a target i586 CPU.

I started the build last night. However, about 1am before going to bed, in my sleepiness I accidentally turned off the power to the PC. Grumble, had to clear the caches and start if off again.
Now 10am, it is almost finished, just compiling LibreOffice.

LibreOffice, incidentally, takes longer to compile than all of the other packages put together. It ends up, there is just one task running, LibreOffice compiling, and it seems to be using only one CPU core at that stage.

I am planning to support "old" computers again, with this i586 build. However, had to make a decision with the kernel. I configured the kernel for i586 and a RAM size limit of 4GB. That is fine, but also chose to support SMP (multi-core) CPUs.

It is that latter one that I was uncertain about. There are, I think, a lot of PCs with x86 32-bit multi-core CPUs, mostly two cores I think.
The SMP-enabled Linux kernel will run on uniprocessor CPUs, however, I do recall that it failed with some uniprocessor CPUs. I don't recall any more details.

So, I guess it is a tradeoff. It is nice to use the two (or more) cores if they are available. If I had chosen to configure the kernel to be uniprocessor only, it will run on multi-core CPUs but only use one core.

If you have any thoughts on my decision, you are welcome to post here:
http://murga-linux.com/puppy/viewtopic.php?p=955960#955960

LibreOffice
Changing the subject, I am getting to like LibreOffice so much, can't consider doing a build without it. Awhile back, I had to fill in a form that was a MS .docx file -- LibreOffice handled that beautifully (whereas Abiword is useless).
I constructed some nice diagrams in LibreOffice, for the "How Easy works" page.

Yesterday, I was unable to insert colour-highlighted shell code into my "How easy works" page using SeaMonkey Composer (it insisted on removing all of the formatting). So I used LibreOffice, and discovered that it is a very nice WYSIWYG HTML editor.

LibreOffice compiled in OE is version 5.0.x, a bit old. I found that it embedded png images into the html page, was unable to keep the links to external images. I fixed that later, however, found support for external links is in Libreoffice 5.2.0.

So, the plan is to compile the latest LibreOffice soon.

Read more...

wget, aaaargh!

I was fixing a couple of bugs in the package manager, PPM.

I compiled 'vim' in OE, and added it to the online package repository in ibiblio.org. Then I used the PPM to download and install it, to test all that is working ...which it isn't.

For a start, the "Update database" button was broken. Fixed that.

Then chose 'vim', but it failed to download.

I discovered the reason. The latest release of wget, 1.19.1, no longer logs to stderr, instead to ~/wget-log*

A quick google, this chap has hit the same problem:
https://www.makemkv.com/forum2/viewtopic.php?f=3&t=15885

I have at least two scripts, probably more, that are now broken. For example "wget .... 2>&1 | .... " or "wget .... 2> logfile" no longer work.

In the latter case, you have to use the "-o" to direct output to a particular logfile. I don't know what to do in the first case, where want to pipe it.

wget has been around since the beginning of time, why make such a fundamental change now? I sent a very polite email to the wget-bugs mail list, asking why.

In the OE build, I have rolled back to wget 1.17.1. This is the same version used in Ubuntu 16.04. In OE, it was easy-peasy to rollabck, I just grabbed the recipe from the "krogoth" release.

In OE:
# bitbake -c clean wget
...then put in the new recipe, in my 'meta-quirky' layer, then...
# bitbake wget

Then, over in woofQ:
# ./0pre-oe-add

...which detects the changed versions in OE, and deletes the old one, imports the 1.17.1 binary tarball.

Oh yeah, vim. It started out early this morning, I compiled vim in OE and imported it to woofQ. Then got distracted by this wget stuff. Now it is 11am.
I want vim as it can convert syntax-highlighted code to HTML output, great for putting code into web pages.

if you want vim for the new Quirky Pyro64, it is here (6MB):
http://distro.ibiblio.org/quirky/quirky6/amd64/packages/oe/pyro/vim-8.0.0427-r0-core2-64.tar.xz

If you download and click on it in Pyro64, Xarchive will open. The mime handler does not (yet) recognise *.tar.xz as possible being a package to install.
Instead, open a terminal where you downloaded it, and run:
# petget `pwd`/vim-8.0.0427-r0-core2-64.tar.xz

Tags: oe

Quirky Pyro64 0.2 alpha

It's out! This is the first upload of Pyro64, tagged as alpha-quality, but is looking pretty good.

We are familiar with Puppy and derivatives having the "kitchen sink" in their builds, in a very small size. Well, Pyro includes the "kitchen fridge" as well.

Pyro64 is built with packages compiled from source in OpenEmbedded. It will run on PCs with x86_64 (64-bit) CPUs, of at least "core2" vintage.

Release notes, and how-to-install links:
http://distro.ibiblio.org/quirky/quirky6/amd64/releases/pyro-0.2/pyro64-0.2alpha-readme.htm

Download, primary host:
http://distro.ibiblio.org/quirky/quirky6/amd64/releases/pyro-0.2/

Download, fast mirror site:
https://ftp.nluug.nl/os/Linux/distr/quirky/quirky6/amd64/releases/pyro-0.2/

Note, I will be uploading the OpenEmbedded development system, with my modifications, plus a tarball of woofQ, later today, watch this blog.

Post feedback here:
http://murga-linux.com/puppy/viewtopic.php?t=110541

Tags: oe, quirky

OE Pyro with meta-quirky

Here is all that is needed to compile most of the packages used in Quirky Linux. It is a tarball with a snapshot of OpenEmbedded "pyro" branch, and my customization "meta-quirky" layer.

Create a folder in a partition with a Linux filesystem, at least 150GB free space, and expand the tarball inside the folder, it will expand as folder "oe-qky-src".

Inside oe-qky-src, you will find a readme file that explains what to do next.

Just a few commands to execute, and off you go! Need a fast Internet connection, as over 515 source packages have to be downloaded.

Download oe-qky-src from here:
http://distro.ibiblio.org/quirky/quirky6/project/oe-qky-src/

Fast mirror:
https://ftp.nluug.nl/os/Linux/distr/quirky/quirky6/project/oe-qky-src/

woofQ
I also uploaded a tarball of woofQ. Once you have all the binary packages, they can be imported into woofQ (see script 0pre-oe), and Quirky Pyro built.
http://distro.ibiblio.org/quirky/quirky6/project/woof-project/

Feedback can be posted here:
http://murga-linux.com/puppy/viewtopic.php?t=110453

Read more...

SeaMonkey now stable in Pyro64

seamonkey
I reported that Firefox and SeaMonkey were unstable in Pyro64:
http://bkhome.org/news/201705/chasing-bugs-in-pyro64.html

I have tested a build with icu 56.1 and SeaMonkey 2.48b1 using the system icu, and it is stable.

SeaMonkey is now also using the system sqlite3, as I added the required config settings in the OE build.

SM is also using system nss and nspr libraries, so it ends up a fairly small package.

python
Trying to get the size down wherever possible, I have created python-tiny, which has just enough in it to satisfy kodi.

I think, getting very close to a first release of Pyro64.
Contemplating doing builds for i686 and armv7 also.

Tags: oe