site  contact  subhomenews

Patch for ROX-Filer fix possible slow running

November 04, 2018 — BarryK

Puppy Forum member jamesbond posted a patch that fixes a potential slow-down of ROX-Filer:

http://www.murga-linux.com/puppy/viewtopic.php?p=925657#925657

That was posted in 2016! I have only just seen it. This is the thing with the Puppy Forum, so much going on, so many great things happening, it is very easy to miss stuff.

You will see in the above link, some testers had difficulty applying the patch. That's because there is different source and they were patching a later fork of ROX-Filer. My source is the original from 2011, with various patches applied.

For EasyOS, ROX-Filer is compiled in 'oe-qky-src', and I have now applied jamesbond's patch:

https://github.com/bkauler/oe-qky-src/tree/master/quirky/meta-quirky/recipes-quirky/rox-filer

Thanks James!

Tags: oe

android-tools and adbfs-rootless in OE

August 08, 2018 — BarryK

I want to incorporate simple automatic-discovery file transfer to and from my phones into EasyShare. So far, have investigated 'adbfs-rootless', which is a fuse filesystem for adb:

https://github.com/spion/adbfs-rootless

'adb' is a utility from Google, a kind of communication bridge between a PC and Android phone. I have used this utility many time before, for example:

http://bkhome.org/news/201803/nexus-5-updated-to-android-810.html

http://bkhome.org/news/201803/lineageos-with-microg-on-nexus-5.html

It would be good to have the 'adb' and 'fastboot' utilities in every future EasyOS and Quirky, so 'android-tools' in OpenEmbedded is now in the package build-list:

https://github.com/bkauler/oe-qky-src/tree/master/quirky/meta-quirky/recipes-devtools/android-tools

Then created a new recipe for 'adbfs' (actually 'adbfs-rootless') and added that to the package build-list:

https://github.com/bkauler/oe-qky-src/tree/master/quirky/meta-quirky/recipes-quirky/adbfs

The instructions to use adbfs are only given for usb-connection. Basically, usb-debugging has to be turned on in the phone, no special app required. In EasyOS, it was very simple:

# mkdir /mnt/phone
# adbfs /mnt/phone

...navigate ROX-Filer to /mnt/phone, and there is my phone, everything available. Some areas are unavailable, due to the phone not being rooted, however, I can access all my files in /mnt/phone/sdcard.

This is good, definitely a contender to be integrated into EasyShare!

Tags: oe

Fix widget order for gtkdialog, aarch64

July 27, 2018 — BarryK

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:

https://github.com/bkauler/oe-qky-src/blob/5e8448751376407009db340a08f145e23a3c511a/quirky/meta-quirky/recipes-quirky/gtkdialog/files/gtkdialog-fix-aarch64-widget-order.patch

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

July 15, 2018 — BarryK

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

coreutils cp utility broken compiled with musl

July 02, 2018 — BarryK

In the latest build of EasyOS I am getting file copy errors when using 'cp'. This build is using a statically compiled coreutils single-binary (with applets symlinked to it, just like busybox), that was compiled in OE.

Here is an example:

# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX
coreutils: failed to preserve ownership for varX/local/pupdial/isp: Not supported

"isp" is a symlink to a folder, target with permissions '777'. That is what causes the error message, though the copy does succeed.

Alright, trying busybox cp:

# rm -rf varX
# busybox cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX

...good, no error message.

OK, compiling coreutils with uClibc. I used a very old uClibc, refer to http://distro.ibiblio.org/easyos/project/aboriginal/, and bumped coreutils to 8.30. Have a static single binary, test it:

# rm -rf varX
# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX

...success!

Grumble, grumble, this reinforces my dislike of musl. I did a search on the Internet, this bug has been reported over several years.

Tags: easy, oe

Busybox 1.28.4 compiled statically

June 29, 2018 — BarryK

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

June 23, 2018 — BarryK

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"...

Tags: oe, easy, quirky