site
contact
newsFix widget order for gtkdialog, aarch64
Gtkdialog is used extensively in Puppy Linux and derivatives, for
GUI frontends to shell scripts. It is a great tool, with many
contributors over the years -- the "greatest" of these would be Puppy
Forum member thunor, who undertook to greatly enhance gtkdialog after
the project was abandoned by the original developer. Thunor moved on,
and the project is now hosted on github, with other contributors:
https://github.com/01micko/gtkdialog
Way back in 2012, when we were playing with the puppies on the
Raspberry Pi, we discovered that gtkdialog rendered the widgets in
reverse order in a window, so, for example, the "OK" button would be at
the top of the window instead of the bottom. Puppy Forum member
jamesbond (one of the key developers of Fatdog), provided a patch, that
thunor applied to version 0.8.2.
Fast forward to now, I found that bug has returned for aarch64. I
consulted with jamesbond, and have a patch, which is in my OE
repository:
It tests if the "__aarch64__" gcc preprocessor macro is set. When I
first tested this, it seemed that it was not set, so I found this way to
list all of the gcc preprocessor macros:
# gcc -x c /dev/null -dM -E
...yep, "__aarch64__" is set to "1" on my Pi3. Note, I googled
around, and someone else tested for "__ARM_ARCH_ISA_A64" -- that works
too.
Tags: oe
meta-qt5 layer now in oe-qky-src
A little over a week ago, I added the meta-qt5 layer to
oe-qky-src, my fork of OpenEmbedded. However, it broke the build of some
packages.
So, I went on a journey, exploring how to compile Qt5 without the
meta-qt5 layer, from basic principles. A very intense several days,
ended with frustration. Well, lots of frustration during those several
days!
I did get it to build, using autotools only, but only for x86_64 host
and x86_64 target. Kept getting errors when attempted cross-compile for
aarch64 target.
Yesterday, gave up, and went back to the meta-qt5 layer, this time
hunted down why it's introduction caused some other packages to fail.
Got it sorted, qt5 5.10.1 now builds, but have not yet ported any
qt5-based apps into oe-qky-src. Did attempt Scribus, but got a compile
error. For now, will build Scribus in the final running system.
This morning, tried to use Smartgit to commit the latest changes. Did
something wrong... it seems, when committed a couple of files and a
directory together, Smartgit got confused. Smartgit seems to be thinking
that the 'meta-qt5' folder is a file!
Git is very powerful, but when something goes wrong, you can really get your knickers in a twist.
To get it uploaded, here it is as a tarball:
http://distro.ibiblio.org/easyos/project/oe/oe-qky-src/oe-qky-src-20180715.tar.gz
Expand somewhere, it will expand to folder 'oe-qky-src', and there is a readme inside.
Right, now to fix Smartgit...
EDIT:
OK, fixed. The problem was, folder meta-qt5 had a .git folder in it, which confused Smartgit. See commits for July 15, 2018:
https://github.com/bkauler/oe-qky-src/commits/master
EDIT 20180717:
I built EasyOS in woofQ from binary packages imported from oe-qky-src,
then attempted to compile Scribus. Lots of configure errors. I found
that .cmake files in /usr/lib/cmake are somewhat broken. They are setup
to work inside OE. I have fixed them, the fixes are in the template
files in woofQ, woof-code/packages-templates/qtbase, qttools, etc.
Interesting observation: cmake seems a lot more troublesome in a
cross-compiling environment than autotools-based projects. This is an
interesting observation due to the praise for cmake that I read
everywhere, and some projects, such as Scribus going over to it.
Tags: oe
Busybox 1.28.4 compiled statically
I have created a new recipe "busybox-static" in my fork of OpenEmbedded (June 28, 2018):
https://github.com/bkauler/oe-qky-src/commits/master
Busybox is compiled statically for amd64 and aarch64, and I have created PETs.
The amd64 PET will be used in future builds of EasyOS and Quirky, and
there is a aarch64 build planned sometime, after I get my hands on the
Librem 5 phone dev kit.
Which I am hanging out for...
The Purism website has the occasional blog post to keep us updated. This latest is interesting:
https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/
...but, where does the trust start and end? We have always trusted
the major hardware manufacturers such as Intel -- after all, their chips
are just big "binary blobs" -- the hardware inside a chip could be
doing anything, we have no way of knowing.
What is different about firmware blobs? Nothing really. But I
suppose, if firmware blobs can be removed, it is reducing the
attack-surface.
Tags: oe
Packages recompiled in oe-qky-src
Finalised, for now, the backporting of packages from the Sumo
release of OpenEmbedded, in my fork 'oe-qky-src', see commits (June 23,
2018):
https://github.com/bkauler/oe-qky-src/commits/master
Did a build overnight, and have now imported the binary packages, all
724 of them, into woofQ, for future builds of EasyOS and Quirky. The
packages will be available in the "oe-pyro" repository in the PPM
(Package Manager), and so are uploaded.
Here they are:
http://distro.ibiblio.org/easyos/amd64/packages/compat/oe/pyro/
Now, I am keen to get back to EasyPak, an exciting new idea for "universal packages"...
Backporting Sumo to Pyro-based OE-port
I forked OpenEmbedded in June 2017, when the Pyro version was
released. My fork, named oe-qky-src, is on GitHub, and is very different
from the mainline OE project, so I can't easily sync with it.
The latest release of OE is Sumo, and I am working around the sync
problem by gradually backporting Sumo recipes. To that end, I created a
"sumo" layer, and have made some commits (June 22, 2018):
https://github.com/bkauler/oe-qky-src/commits/master
In particular, meta/recipes-graphics and meta-oe/recipes-graphics have been backported, which includes Xorg and mesa.
Tags: oe
rox-filer, shared-mime-info tweaks
In ROX-Filer file manager, when you click on the little "home"
icon at top of window, it will open a window at the user's home
directory. In the case of Puppy that is /root, however with Quirky I
want to open at /file, and for Easy at /mnt/wkg/home.
I have modified the rox-filer source so that it detects if running in
Quirky or Easy, or if not then opens at ~ (/root for Puppy).
Some of my shell scripts have a shebang line "#!/bin/ash" and
ROX-Filer does not recognise this as an executable. The reason for this
is the shared-mime-info package, which recognises such a file as
plain-text only.
I have patched shared-mime-info to recognise "ash" and "dash" scripts as shell executables.
These fixes are to be found in my online "oe-qky-src" fork of OpenEmbedded ( June 8 and 9):
Note, I deliberately use an old version of shared-mime-info, 0.90, as I found that recent versions have stuffed up recognition of text files. Many text files in woofQ and Easy/Quirky/Puppy are mis-identified, which results in Geany and other text editors refusing to open them, and in the case of ROX-Filer not offering to open in a text-editor in the right-click "Open With..." menu.
Tags: oe
First OE aarch64 build, updates
I have done a first build for aarch64 (64-bit arm) on my fork of OpenEmbedded. project page:
https://github.com/bkauler/oe-qky-src
Modifications for first aarch64 build:
https://github.com/bkauler/oe-qky-src/commit/34b4094751927a061b90d6449e02b5de1a160119
Some packages failed, so I need to fix them. However, most of the big apps, such as Firefox and LibreOffice, compiled.
Have also started to update some packages:
jwm 1679:
https://github.com/bkauler/oe-qky-src/commit/f5047186945c0f4b77940d28900e57a2257edeec
bacon 3.7.2:
https://github.com/bkauler/oe-qky-src/commit/7a097a9790d330b822882a99a93002df77b007cc
pup-tools 20180417:
https://github.com/bkauler/oe-qky-src/commit/1f57c236b24f22953ec1d707a4c97b5b164f807d
EDIT:
Plowing ahead, fixing packages for aarch64, and updating some, adding some new packages.
Won't itemise here, look at the repo.
Tags: oe
No CUPS support in gtk+ in OpenEmbedded
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