EasyOS version 2.3.2, June 22, 2020

[BarryK]

I am not responsive to feedback on EasyOS for awhile. Apologies for that, but having a bit of a rest from EasyOS development, instead working on my solar water still, currently a basin-type, prototype #3.

[BarryK]

I am starting to fix bluetooth. Only looked at Easy Pyro so far.

Pyro has BluePup to make the connection, which I did successfully with my bluetooth mouse. However, it did not work after a reboot.

I found that this fixes it, file /etc/bluetooth/main.conf:

Code: Select all

[Policy]
AutoEnable=true

[General]
DiscoverableTimeout=0
Discoverable=true

However, the mouse only works if I turn its power on after Easy has booted up. If the mouse is turned on beforehand, it is not detected.

Does anyone know if this is normal behaviour? On other distros, does the mouse work at bootup, without having to toggle the power button off-on?

[Sage]

Does anyone know if this is normal behaviour? On other distros...

Some printers sometimes behave like this in some distros, both USB connected and wifi. However, I have not been able to discover any reproducibility nor rationality. As a non-coder, I've found that unplugging & re-plugging, switching off then on again (printer that is), logging in and back, usually brings up desired result - the sort of idiot approach like kicking it,I suppose! Only started happening within last ~5yrs. Sorry this may not help. Only major disruptions on this timescale have been kernel changes and systemd (which Puppy doesn't have, but device embedded code may have/be influenced by?)

[BarryK]

I am starting to fix bluetooth. Only looked at Easy Pyro so far.

Pyro has BluePup to make the connection, which I did successfully with my bluetooth mouse. However, it did not work after a reboot.

I found that this fixes it, file /etc/bluetooth/main.conf:

Code: Select all

[Policy]
AutoEnable=true

[General]
DiscoverableTimeout=0
Discoverable=true

However, the mouse only works if I turn its power on after Easy has booted up. If the mouse is turned on beforehand, it is not detected.

Does anyone know if this is normal behaviour? On other distros, does the mouse work at bootup, without having to toggle the power button off-on?

Bluetooth mouse now working OK:

https://bkhome.org/news/201911/bluetoot ... -easy.html

If mouse turned on at bootup, need to click a mouse button for it to be recognised.

[BarryK]

I am not responsive to feedback on EasyOS for awhile. Apologies for that, but having a bit of a rest from EasyOS development, instead working on my solar water still, currently a basin-type, prototype #3.

Full steam ahead on EasyOS development, for now anyway. Planning to head off for a camping trip to the South coast soon, but intend to get out the next version of Easy before that.

5.4.1 kernel with "lockdown" is looking good:

https://bkhome.org/news/201912/kernel-5 ... -aufs.html

There was a request to free-up how a container is created. It used to be only in-built apps could be converted to a container, now user-installed apps can be converted:

https://bkhome.org/news/201912/convert- ... iners.html

[BarryK]

I have created a new firmware PET for the 5.4.1 kernel. In current release of EasyOS, Pyro and Buster, the firmware PET used in the build is 49MB. It is now 55MB, as I have found more firmware from here and there.

[BarryK]

Hi Barry,

If you have a tarball that you want to install in a new container, the Create button could be expanded to handle that. Or, an SFS.
But then, Easy Containers will still need to be expanded to recognise it. I have added this to the to-do list.

"Expanded" as used above must mean a work in progress? Is there any way I could help?

Note that SFSs need to be created by the 'dir2sfs' script. So, if you exoand the tarball to a folder named in format packagename_version_amd64, then you can run dir2sfs to convert it to a SFS.

Expanded in this case means extracted? dir2sfs seems to run and create a palemoon sfs, but can that sfs be loaded and run in buster 2.1.7 at its present state of development? (if I create it correctly)

Thanks

dir2sfs will have created a .sfs, .specs and .png files. Copy them to /mnt/wkg/sfs/easyos/debian/buster

Then click "sfsget" on the desktop and you will be able to install it as a container.

If it doesn't work, like nothing happens when you click on the desktop icon, try launching it from a terminal. You will find /usr/sbin/ec-chroot-<name of app>, for example ec-chroot-chromium which has this in it:

Code: Select all

empty -f ec-chroot chromium

Just run this in a terminal:

Code: Select all

# ec-chroot chromium

and you should see an error message if it fails.

Also, if it did start then aborted, you can find error messages in /mnt/wkg/containers/chromium/.session/tmp/xerrors-chromium.log

[BarryK]

To Barry,

Re Pyro 1.2.8.

Sea Monkey in container STILL crashes when "Preferences"
is clicked, as previously reported in 1.2.7.
Regards.

I just now tested in Easy Buster 2.1.8, it does not crash.

EDIT:
Booted Pyro 1.2.7 from a USB stick, ran SM in a container, Edit -> Preferences works, no crash.

My PC has Intel graphics.

[scsijon]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

[BarryK]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

I don't understand what you are asking.

A container is a chroot environment, with security features. So for /mnt/wkg/containers/chromium/container for example, that is the chroot path, and after executing the chroot it is seen inside the container as "/"

[BarryK]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

Are you compiling inside a container, or on the main desktop?

[BarryK]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

I have just now compiled binutils 2.33.1 in Easy Pyro 1.2.8 (because that is what I am running with right now).

Pyro has the linux_headers-4.14.1.pet in the devx. These are the headers that were used in OpenEmbedded when all the source packages were compiled, including glibc, and it is best to stay with these headers, unless there is a very good reason to use later version. I think that you may get conflicts with glibc if you use later headers version.

binutils compiled, no problem.

Note, same applies to Easy Buster, it has 4.19.x headers in the devx, and that should not be changed.

[scsijon]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

I have just now compiled binutils 2.33.1 in Easy Pyro 1.2.8 (because that is what I am running with right now).

Pyro has the linux_headers-4.14.1.pet in the devx. These are the headers that were used in OpenEmbedded when all the source packages were compiled, including glibc, and it is best to stay with these headers, unless there is a very good reason to use later version. I think that you may get conflicts with glibc if you use later headers version.

binutils compiled, no problem.

Note, same applies to Easy Buster, it has 4.19.x headers in the devx, and that should not be changed.

Strange. In your buster container with devx enabled (yes, I rebooted in case) I can't! Something is strange here, and trying sabotage stage0 gives the same result, which is why I was trying. I wonder if it's because they are trying to use 2.27.

Back in Xenial and (old) Pyro the fix was to add the extra line in in the sysctl.h file, then stage0 and onwards built. I'm now beginning to wonder what else is wrong in their system from our end view. It fails in a direct (non-container) build also.

Anyway, thanks for your testing, I believe you've proved it's not EasyOS, Their problem I think, and I shall add the note to the git error message and end thinking of doing a quirky sabotage build as this is the second time i've tried and both have now ended in more problems than before.

Oh, and i've just been pointed at https://github.com/tpimh/nenuzhnix and it's non-gnu toolchain https://github.com/tpimh/ngtc, and there is a non-docker branch. Maybe i'll 'play' with them next while awaiting T2 to sort itself out in things I can't help with. I did play with wayland/etc, but even that uses gnu packages so it's not what I want for my Quirky end system.

[scsijon]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

I don't understand what you are asking.

A container is a chroot environment, with security features. So for /mnt/wkg/containers/chromium/container for example, that is the chroot path, and after executing the chroot it is seen inside the container as "/"

AH, that explains it, I was thinking it would open in it's own containerized /home, thanks..

[ras]

Then click "sfsget" on the desktop and you will be able to install it as a container.

Hi Barry,

finding the created sfs's in sfsget is easy enough, getting them to install properly is another thing. My sfses work in buster if I call the executable, so I have come to the conclusion that getting dir2sfs to create a proper .specs needs more of my attention.
Did I mention I was a bit of a noob with all this yet?

I have used Puppy for years without looking under the hood too much, but recently accepted a challenge from a friend that dropped quite a bit of coin on a librem 15 to see what I could do with EasyOS, (and his old laptop) The qfix=cap2 option used with a preconfigured browser has been an eye opener around here.

The version control and snapshots features work without a hitch on every machine tried, and we are looking forward to your next release to see debs run in their own container.

For those that have not had a look at Freecad, it is much more than a drawing program. It has FEM capabilities that allow the viewing of a part or assembly reacting under simulated loads.

[ras]

Hi Barry
Got it working as an individual container on the main desktop finally. When I looked inside my sfs at /usr/sbin/ec-chroot-<name of app>. I found

Code: Select all

empty -f ec-chroot palemoon  ec-chroot palemoon

not sure how that snuck in there as I had never edited the file before, but I had run dir2sfs on the build directory with some dubious settings prior. I also noticed the absence of a link to the executable in /usr/bin, and added it for good measure. Not sure which did the trick, and am not even sure that a link in /usr/bin is necessary. ( I peeked into your firefox.sfs for guidance).

Just a small observation:
I guess it is obvious to most users of sfsget, that once you down load a sfs, and then click on a sfs in the window, the sfsget package installer morphs into the install mode and offers you the button to install.
In the case of a sfs manually placed into /mnt/wkg/sfs/easyos/debian/buster, a broken sfs can be seen in the window, but a click on it can give no response. Seems that once the sfs is constructed better, the morphing of the gui and appearance of the install button happens. In the paragraph Install Mode, an instruction to click on your sfs in the window and some information as to what is supposed to happen next would be useful, as I was not aware sfsget was supposed to morph and not sure how to proceed.

Thanks for your help

[blgs]

Please include also the appropriate kernel-headers as a pet or sfs file in Easy os.
Currently only kernel-headers version 4.19.06 is available (as a pet)

[BarryK]

Please include also the appropriate kernel-headers as a pet or sfs file in Easy os.
Currently only kernel-headers version 4.19.06 is available (as a pet)

It is correct to have the 4.19.x kernel headers in the devx, as that is the kernel version that Debian 10 Buster was compiled for.

So, Easy Buster should really only be built with a 4.19.x kernel, as I think BusterPup and other Puppy Busters are doing.

But I want later kernels, for their new features. This does create a potential problem, as if use a matching headers pet, it may conflict with glibc, as scsijon has found.

Usually, the 4.19.x headers are fine when compiling in Easy with a later kernel.

Anyway, I plan to release next Easy with 5.4.2 kernel, and will include the headers pet in the repo.

[BarryK]

Just a small observation:
I guess it is obvious to most users of sfsget, that once you down load a sfs, and then click on a sfs in the window, the sfsget package installer morphs into the install mode and offers you the button to install.
In the case of a sfs manually placed into /mnt/wkg/sfs/easyos/debian/buster, a broken sfs can be seen in the window, but a click on it can give no response. Seems that once the sfs is constructed better, the morphing of the gui and appearance of the install button happens. In the paragraph Install Mode, an instruction to click on your sfs in the window and some information as to what is supposed to happen next would be useful, as I was not aware sfsget was supposed to morph and not sure how to proceed.

Yes, I know, there is a need to make this more logical. But, might target this for release-after-next.

[BarryK]

Bit of a quandary what to do about the 5.4.x kernel. I want the "lockdown" feaure, but audio is broken on my Apollo Lake CPU laptop, but does work on my Intel i5 CPU PC.

I don't know how many people are going to be affected.

Want to move ahead, get out the next releases. So maybe will do two builds, with 5.4.2 kernel and with an older kernel. People can try the build with 5.4.2 kernel, if no sound, they can use the other one.

Not very satisfactory though.

Blog post:

https://bkhome.org/news/201912/audio-fi ... ernel.html