Little fixes happening daily

Almost everyday I am fixing, tweaking or improving something in OE or EasyOS, and it often doesn't get reported to this blog. Here are a few...

Today I changed the menu back to inline. The current release of EasyOS has a cascading menu, but I have been finding it annoying. When I want to run a particular app or utility, sometimes I have to think where is that in the sub-menus, and then hunt for it. The inline submenus is more convenient.

The CUPS web interface has lots of links to help pages, but they don't work. The daemon 'cupsd' has an inbuilt http server, so take the browser to http://localhost:631 to see the web interface. The "doc root" is /usr/share/doc/cups or /usr/share/cups/doc-root -- the latter in Easy Buster and Easy OE-dunfell. This has file 'index.html' that is what you see at localhost:631

The CUPS http server is especially configured to use CGI modules, located at /usr/lib/cups/cgi-bin. I discovered that /etc/cups/cups-files.conf has a parameter "ServerBin /usr/lib/cups" so that the CUPS daemon knows where the 'cgi-bin' folder is.

It is these CGI modules that are invoked via the 'index.html' file. One of them, 'admin.cgi', provides the administration web interface. Another, 'help.cgi', is broken, as the help files do not exist.

I have fixed the web interface so that links that invoke 'help.cgi' are removed from 'index.html', so no broken links in the web interface.

In OE, I have recompiled everything, with some changes. One thing, I noticed that there are some large 'vulkan' drivers in the build. Vulkan is a replacement for opengl, but I don't know anything about it. So I added DISTRO_FEATURES_remove = "vulkan" to the 'local.conf' file. Some other changes too. 

Tags: easy

Compiling SeaMonkey in OE Dunfell

I need to document this, as I had to jump through some hoops to get the compile underway -- watching it now, cross the fingers that it will get to the end!

I am running EasyOS Dunfell-series, built from packages compiled in OE.

The web browser supported by OE is Epiphany, also known as "Gnome Web". It is based on webkitgtk, and I noticed that Epiphany and all of its dependencies are quite big, maybe even bigger than SeaMonkey. Those deps include webkitgtk and gstreamer.

Of course, with SM, we don't get just a browser, we get a whole suite. For me personally, I use the Composer WYSIWYG HTML editor, just about every day. So, I have a personal interest in bundling SM with every release of EasyOS.

I know that using a WYSIWYG HTML editor is considered "old school", but it is a key component of my shellCMS, that manages my websites.

I know of others who use the SM Mail & News module, as well as the Addressbook module.

Anyway, jumping those hurdles...

SM needs Rust and Cargo to compile, and I discovered that it is pretty simple to install. Precompiled binaries can be installed just by doing this:

...oh bother, compile has just stopped. A video problem, something about "vp8". Anyway, back onto Rust:

https://www.rust-lang.org/tools/install

# curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

installs to /root/.cargo

In the terminal where compiling SM, need this:

# export PATH="/root/.cargo/bin:${PATH}"

Another hurdle is that python3 is no good, python2 is required. So, I downloaded version 2.7.18 source and compiled:

https://www.python.org/downloads/release/python-2718/

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu --with-ensurepip=yes --with-system-ffi --with-system-expat --enable-unicode=ucs4
# make
# new2dir make install

Information can be found here:

http://www.linuxfromscratch.org/blfs/view/svn/general/python2.html

In the SM source:

# export SHELL=/bin/sh
# export CC=gcc
# export CXX=g++

Then a 'mozconfig' file is required in the source, then start the compile:

# make -f client.mk

Regarding that error reported above, I fixed it by "--disable-webrtc" in mozconfig. WebRTC is in all modern browsers, but do I need it? Hmmm, anyway, the compile is now progressing... and the compile has succeeded.

This is how to install:

# make -f client.mk install

Now to test. Will SM be stable? There have been issues in the past, with using system libraries, such as cairo, pixman and icu. Taking it for a spin, visiting some challenging websites, such as youtube.com... But, failure at startup, with this message:

The application has been updated, but the SQLite library wasn't updated properly and the application cannot run. Please try to launch the application again. If that should still fail, please try reinstalling it, or contact the support of where you got the application from.

Yes, sqlite is another system library that can cause trouble. OK, modifying 'mozconfig' with "--disable-system-sqlite". Note that sqlite has to be compiled with certain configure options, that I did do in OE, but this time it isn't enough to satisfy SM.

This is the 'mozconfig' file:

mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite
ac_add_options --enable-system-hunspell
ac_add_options --prefix=/usr
ac_add_options --host=x86_64-pc-linux-gnu
ac_add_options --disable-dbus
ac_add_options --disable-accessibility
ac_add_options --with-system-bz2
ac_add_options --disable-updater
ac_add_options --disable-parental-controls
ac_add_options --disable-system-sqlite
ac_add_options --enable-system-cairo
ac_add_options --enable-strip
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --disable-tests
ac_add_options --disable-crashreporter
ac_add_options --with-system-libvpx
ac_add_options --disable-necko-wifi
ac_add_options --without-system-nspr
ac_add_options --without-system-nss
ac_add_options --with-system-icu
ac_add_options --disable-pulseaudio
ac_add_options --enable-alsa
ac_add_options --enable-system-ffi
ac_add_options --with-pthreads
ac_add_options --enable-system-pixman
ac_add_options --disable-debug
ac_add_options --with-system-libevent
ac_add_options --enable-optimize='-O2'
ac_add_options --enable-ffmpeg
ac_add_options --disable-stylo
ac_add_options --disable-webrtc

Compiled again, tested, runs great. Starts remarkably fast. I am using the Composer module to post this blog report.  

Tags: easy

Pango version 1.44+ is a disaster

A couple of days ago, I posted about some fonts rendering as rectangular boxes in EasyOS built from packages compiled in OpenEmbedded:

https://bkhome.org/news/202009/first-bootup-easyos-dunfell-series.html

After a bit more research, I discovered that the culprit is Pango, version 1.44 onwards. Support for bitmap and Type1 fonts has been dropped.

I could live with that, I think, however, that problem turned out to be the tip of the iceberg. I discovered this in ROX-Filer:

...what is wrong with that? Hyphens are inserted at line-breaks. For example, file "freememapplet_tray" is showing as "freemem-applet-tray". How misleading!!!!

It seems that individual applications can turn hyphenation off, so ROX-Filer would need to be patched. There does not seem to be global configuration setting to turn it off.

The problems don't end there. Pango 1.44+ has also stuffed up rendering of DejaVu fonts. With DejaVu Mono, a character with underscore will not show the underscore. In rxvt-unicode, the horizontal spacing between characters is huge.

Here are some relevant links:

https://github.com/linuxmint/nemo/issues/2214

https://gitlab.gnome.org/GNOME/pango/-/issues/386

https://gitlab.gnome.org/GNOME/pango/-/issues/392

https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/

The version of Pango in OE Dunfell is 1.44.7, in Debian Buster it is 1.42.4.

Looking at the releases of OE/Yocto, going back in time from left to right:

Dunfell Zeus Warrior Thud Sumo Rocko Pyro

Pyro was released May 2017. Warrior has Pango 1.42.4, so I might use that recipe and do a complete recompile.  I hate to be going backwards, but it won't be the first time that I have done this (with other packages). 

Tags: easy

First bootup EasyOS Dunfell-series

So far, have built 736 packages in OE. That's whole packages, not split up ones. Previous post about this project to compile everything from source in the latest release of OpenEmbedded/Yocto:

https://bkhome.org/news/202009/more-patches-for-an-old-package-in-oe.html

...actually, that "horrible hack" did solve the compile fail, but glibc has probably removed the infrastructure to actually make that code work at runtime. I probably should take a look at the latest version of xlockmore (says he, writing yet another reminder on all the bits of paper scattered around on his desk).

So, I did a complete build, and also imported the compiled packages into woofQ, and then built EasyOS ...and hey, it worked, got a desktop!

It seemed perfect, but then started to notice few things wrong...

Opened a text file in Geany text editor, and all characters in the file displayed as rectangular boxes only. Clicked on the "console" icon on the desktop to start the Sakura terminal emulator, same problem.

After considerable bafflement, I realised that what is failing is the monospace Type1 font (Nimbus Mono L). It does display OK in the urxvt terminal emulator, which is an X11 app. It is GTK apps that are the problem, both gtk2 and gtk3.

A very brief online search has suggested that the harfbuzz package is the cause of this problem. I won't try to track the cause down any further, rather, will remove the Type1 font.

Why am I still using a Type1 font anyway? This is an early Postscript font format, and, I don't know the precise details, but it is a very restrictive format compared with TrueType. That to-do has been added on one of those bits of paper.

The build has the Epiphany web browser. Seems OK. As that is the one officially supported by OE, might stay with that, and provide SeaMonkey as an SFS. Chromium as an SFS also. The OE build does not have LibreOffice, so might just have that as an SFS also.

Gotta say, this is an enjoyable exercise! 

Tags: easy

Progress compiling in OE Dunfell release

I posted about commencing this a few days ago:

https://bkhome.org/news/202009/buildroot-and-openembedded-revisited.html

hey, how time goes when we are having fun! Though, I don't know if "fun" is the right word. Endless hours, into the wee small hours of the morning, fixing packages that won't compile.

As of this morning, have compiled 675 source packages. There are some failures, that did compile in earlier OE releases (Pyro and Thud). This is them:

binutils-static busybox-initramfs-static coreutils-static dictd-client e2fsprogs-static gdk-pixbuf0 gdmap gettext0-static gftp glib1 glipper-lite gnome-mpv gnupg1-static gpart gtk1 gtkhash gtklp gwhere idump-static ktsuss leafpad libcap-static make-static mped-static ndiswrapper ndiswrapper-exe netpbm nnn-static noice-static notecase patchutils pekwm pup-tools rman rubix xarchive xdialog xine-ui xsane xsoldier

The "-static" ones are only meant for when linking with musl, which haven't tried yet. Currently linking with glibc.

Changes in the build infrastructure are behind these failures. Glibc is 2.31, gcc is 9.3.0. There is only python3, no python2, which might be an issue with some source packages, that have python scripts in the build configuration.

Anyway, 41 failures and 675 successes is quite good. Some of those failures don't matter, I will try to fix those that do.

'pup-tools' is one failure that currently has me stumped. I have reported the problem to the BaCon forum:

https://basic-converter.proboards.com/thread/1183/compile-fail-openembedded-dunfell

Some of those failures are due to "-Werror" gcc flag. OE is very sophisticated and complex, and sometimes trying to configure something is like looking for a needle in a haystack. I think perhaps I can override by "CFLAGS += "-Wno-error"" in the package build recipe.

EasyOS Buster series, although built with Debian Buster (10.5) DEBs, also uses many packages that were compiled in the Pyro series of OE. No problem with that, they work, but thinking it is time to update everything in the latest OE.

EDIT 20200922:
I discovered that OE imposes "-Werror=format-security" on all package compiles. This is a new feature of OE, not in the Pyro and Thud releases, and resulted in several packages failing. I turned it off in each recipe, with this:

  CFLAGS_append = " -Wno-error=format-security "

Another issue has been tighter QA (Quality Assessment) checking after compiling and installing. In each recipe, if I don't know how to fix the QA failure, or haven't invested the time to do so, the offending QA can be disabled in each recipe, for example:

ERROR_QA_remove = "file-rdeps"

...that changes it to a warning rather than a failure. Continuing to have "fun"! 

Tags: easy

Buildroot and OpenEmbedded revisited

I responded to a thread on the Puppy Forum:

https://forum.puppylinux.com/viewtopic.php?f=127&t=727&start=10

In response to a post from James, linking to this blog post:

http://lightofdawn.org/blog/?viewDetailed=00192

Yeah, don't know if I want to go down that rabbit hole again, but the lure is there...

Got me reminiscing, and last night downloaded the latest Buildroot, and after much messing around, in the early hours of the morning got it compiling and built with a custom kernel. No joy with EasyOS Buster 2.4.1, used EasyOS Pyro. I do recall the previous time I tried it, it worked right off when the host was Slackware 14.2.

Anyway, Buildroot is interesting, but don't know where to go from there.

This morning downloaded the latest OpenEmbedded/Yocto, named "dunfell", version 3.0.2. Pretty straightforward to get it going on EasyOS Buster 2.4.1.

Just tossing ideas around in the head. Maybe could use OE to build a base CLI-only bootable system, then bolt on James' Slackware-based source package build system, to compile the rest.

Don't know, just playing.

EDIT 2020-09-16:
Ha ha, I got lured down the rabbit hole! Doing a compile right now, OpenEmbedded/Yocto 'dunfell' release.

The EasyOS Pyro-series is built from packages compiled in my fork of OpenEmbedded 'pyro' release, which was about 3 years ago. Here is my fork of OE:

https://github.com/bkauler/oe-qky-src

I don't really know why I'm doing this. Just like the aesthetics of compiling everything from source and tailored to my requirements. I did a quick compile last night, of the dunfell OE, compiled Epiphany web browser and all its deps, just to see if it works. Yep, compiled. That's one of the nice things about OE, it is pretty solid, everything compiles. I even installed the result into a USB stick and booted it. Got to a commandline, but couldn't run Epiphany as haven't included an X server in the build.

There was a huge amount of customizing that I did of the pyro OE, all in 'meta-quirky' folder at my repo oe-qky-src. I will look at porting that to the new dunfell OE. Maybe.

Maybe bring back Quirky Linux, built from dunfell OE packages?   

Tags: easy

Français langpack updated for Easy 2.4.1

I posted recently about the German langpack being updated:

https://bkhome.org/news/202009/deutsche-langpack-updated-for-easy-241.html

Now esmourguit (forum name) has posted updates for the French langpack:

https://easyos.org/forum/showthread.php?tid=141

I have updated the PET, it is now 'langpack_fr-20200908.pet'. 

Tags: easy