site  contact  subhomenews

No CUPS support in gtk+ in OpenEmbedded

November 29, 2017 — BarryK

Right now, I am in a state of great surprise. Testing Pyro64 0.6, printing does not work. In fact, it never has, for any Quirky builds from OpenEmbedded packages.

Despite the fact that 'cups' is available as a package in OE, gtk+ is hard-coded not to use it. Not only is cups missing from the DEPENDS variable in the gtk+ recipe, it is explicitly disabled with "--disable-cups".

There is isn't even a conditional test for existence of cups.

I kept looking at that, because I couldn't believe what I was seeing.

This situation is in the "pyro" release of OE/Yocto, same in the latest in master branch in github.

I have created gtk+_2.24.31.bbappend, with this in it:

PR = "r1"

# added the last line...
DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native \
cairo gdk-pixbuf \
cups libxinerama xinput pixman freetype fontconfig"

# original...
#EXTRA_OECONF = "--enable-xkb --disable-glibtest --disable-cups --disable-xinerama"

EXTRA_OECONF = "--enable-xkb --disable-glibtest --enable-cups --enable-xinerama \
--with-xinput=yes --enable-debug=minimum"

Added some more things that thought should be there. It compiles, not yet tested in a build.

EDIT 1:

Although OE/Yocto has the 'cups' package, it does not have 'cups-filters', which is required for printing. 'cups-filters' got split out of 'cups' sometime ago. OE actually has a recent 'cups', in which the 'cups-filters' is split out, yet there is no 'cups-filters', and I had to add it in my "meta-quirky" layer. Which shows just how much attention printing has been getting in OE/Yocto -- along with non-printing gtk+, I would say none at all.

i recompiled 'gtk+', no joy. Compiled 'cups', 'cups-filters' and 'poppler' manually in Pyro64, still no joy.

I examined /var/log/cups/error.log, and did a search with google. Found the same error was fixed here:

https://bugs.archlinux.org/task/51598

...by rolling back 'cups-filters' to 1.11.4. I am using 1.13.5, so I tried it, compiled 1.11.4, and hey, printing to my USB printer works!

Oh, what a dark art this CUPS printing is!

Now, need to put the fix into OE.

EDIT 2:

These are the fixes in OE, I confirmed they have fixed printing (Nov 30, 2017):

https://github.com/bkauler/oe-qky-src/commit/204bcebb97c794c15ff9244e15f604dbd1057628
https://github.com/bkauler/oe-qky-src/commit/af82f831c56ff876791ab8a1dfd8aa988ad70f66
https://github.com/bkauler/oe-qky-src/commit/5a8ab7623d4ac55e3d2a4865e5c5e7d28cb54fb4
https://github.com/bkauler/oe-qky-src/commit/3ed260dae6da4ee9bca0a7fbd49ea17b62c9d91b

Note, I am now doing a complete x86 32-bit (i686) recompile in OE.

Tags: oe

OE recompile, SM 2.49.1, kernel 4.14.1

November 22, 2017 — BarryK

I mentioned recently that some library packages compiled in OpenEmbedded were too old. I ended up only bumping 'icu', 'nss' and 'nspr', to versions 58.2, 3.31.1 and 4.16. Then did a complete rebuild in OE.

Built Pyro64 0.5.2, and compiled SeaMonkey 2.49.1, this time using the system icu, nss and nspr, making the package considerably smaller. The PET is here:

http://distro.ibiblio.org/quirky/quirky6/amd64/packages/pet_packages-pyro/seamonkey-2.49.1-pyro64.pet

I also compiled the 4.14.1 kernel, and was most surprised when "make modules_install" did not create /lib/firmware. A quick google, and it seems the firmware is no longer in the kernel source tree.

I didn't know how to respond to this situation, but decided to take the /lib/firmware from the compile of kernel 4.13.11, for inclusion in the kernel PET. The PET is here:

http://distro.ibiblio.org/quirky/quirky6/amd64/packages/pet_packages-pyro/linux_kernel-4.14.1-pyro64.pet

The source, patches, and build scripts are here:

http://distro.ibiblio.org/easyos/source/kernel/4.14.1/

Tags: oe, quirky

Plans for next Quirky Pyro64

November 18, 2017 — BarryK

I have been away. Here is a photo:

photo

While on holiday I couldn't get into the mood of doing any Linux development, but intend now to start putting together the next Pyro64. The current release is 0.5.

0.5 has the latest LibreOffice, that I compiled in Pyro64, and I had to use some inbuilt libs as some packages compiled in OpenEmbedded were too old. Had the same problem with latest SeaMonkey. For example, had to use SM's inbuilt icu, as the system package was too old.

The problem with this is that it makes the distribution bigger. So, I plan to do a recompile in OE, and bump the versions of some packages.

Another thing, plan to compile some extra perl modules in OE, as previously only had the base perl package. It seems that pplog, and probably some other apps, need extra perl modules. I think that I have figured out the extra modules needed.

Then, will build a new Quirky Pyro64, and compile the latest LibreOffice and SeaMonkey.

Also plan to upgrade the Linux kernel to 4.14.x, as this is LTS, supported for six years. Which is great.

So hopefully then I will build a Pyro64 which will also be a LTS. Might release it as version 0.6.

I previously mentioned creating a GUI wrapper for shellCMS and put into Pyro64 as a replacement for pplog personal blog. Haven't got very far with that.

Then there's Easy OS. Not forgotten, an idea is percolating.

Another photo:

photo

Tags: oe, quirky

xine-ui, inkscapelite imported into OE

November 02, 2017 — BarryK

Two more this afternoon.

xine-ui

This is an xlib-based GUI media player, using xine-lib. I had already compiled xine-lib in OE, but the player was compiled as a PET in a running Quirky Pyro64. Now imported into OE:

https://github.com/bkauler/oe-qky-src/commit/6b93ae8ac55af6b1404e64036d3669f070e8b2a9

inkscapelite

Wow, this one is a major achievement! Very cross-compiler unfriendly. I had attempted to compile in OE a few times, took up the challenge again this afternoon, this time, success.

One hurdle is that it compiles a binary executable, src/libnr/gen_nr_config, which is then run to test the sizes of variables, and creates src/libnr/nr_config.h

However, this is a cross-compiler environment, so the above is a no-no. OE does have an official way to handle this situation, which is to create another package "inkscapelite-native", which compiles in the host environment, and only needs to compile that gen_nr_config. Then inkscapelite-native can be used as a dependency for the inkscapelite package.

The problem is, I have not yet grasped the implementation details. It is poorly documented, and my nice big OE reference book doesn't even mention the topic. If you are reading this, and do now how to do it, I would greatly appreciate a walk-through on how -- kindly send me an email via the Contact link at top of this page.

Anyway, I came up with a workaround, a hack solution. Committed:

https://github.com/bkauler/oe-qky-src/commit/2c9ac39e3d08379b293ed8d28761823237388692

Celebration was short-lived however, as testing the executable in a running Pyro64, crash at startup. Same thing for inkscapelite compiled in a running Pyro64, as reported by the guys on the Puppy Forum who are testing Quirky Pyro64 0.5.

It could be traced, and the place where the crash happens can be found. However, maybe the time has come to retire inkscapelite. I am fond of it, as it is so small, and quite a useful app. However, Pyro64 has the Draw module of LibreOffice, so SVG editing is covered.

Tags: oe

Notecase imported into OE

November 02, 2017 — BarryK

Notecase is a hierarchical notes manager, one of the essential apps in all Puppies and derivatives.

The problem was, I was unable to compile it in OpenEmbedded, so Pyro64 has notecase compiled in a running Pyro64. But, it is partly broken. Images in GTK themes do not load, and cause notecase to hang, as well as spit out a continuous stream of errors on stderr.

In my notes, I have written that notecase in Slackware has the same problem, but I don't recall any details.

To workaround the bug, Pyro64 0.5 is running notecase via a wrapper script:

#!/bin/sh
#170512 Pyro64, images from gtk themes don't display.
#workaround for now, use a theme without images...
export GTK2_RC_FILES=/usr/share/themes/Default/gtk-2.0/gtkrc
exec /usr/bin/notecase.bin "$@"

This morning, I had another go at compiling notecase in OE, and this time succeeded. The source has its own inbuilt zlib, which gave an error due to the cross-compile environment, and despite this error being reported many times in a google search, I could not pin down a fix.

The workaround was to use libz.a already compiled in OE, and success. Then a surprise -- I tested the notecase executable in a running Pyro64, and it works perfectly, GTK theme images load. Well, well, I shall just accept this little bonus.

Here is the github commit:

https://github.com/bkauler/oe-qky-src/commit/113323a2744c854a2d8fdc252cdebc99e89be274

EDIT:

I bumped mp (cli text editor) from version 3.2.13 to 3.3.17, as the menu wasn't working. OK now. Note, mp is named "mped" in OE.

Tags: oe

shared-mime-info, vte, sakura in OE

November 01, 2017 — BarryK

Three more. These took 4-5 hours!

shared-mime-info:

https://github.com/bkauler/oe-qky-src/commit/421fb1ac74cec94af1a5e989b25197f3359fcceb

vte:

https://github.com/bkauler/oe-qky-src/commit/503952c03e71a806d8fe7d2503657eb8f021c579

sakura:

https://github.com/bkauler/oe-qky-src/commit/4661252c2e8986f077dac9dcf0d7d0cc7398044a

Tags: oe

hardinfo, mtr added to OE

November 01, 2017 — BarryK

Two more this morning.

hardinfo:

https://github.com/bkauler/oe-qky-src/commit/1c729e2654b04b96fba048429b4976b1ba0d6aa6

mtr:

https://github.com/bkauler/oe-qky-src/commit/47ea4d98d749867926ed6a79f3ede7f821eb9998

Family stuff for the next few hours, hope to port more packages this evening.

Tags: oe