Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 15 Dec 2019, 20:23
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
EasyOS Pyro 1.2.9, Buster 2.1.9 December 9, 2019
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 134 of 137 [2046 Posts]   Goto page: Previous 1, 2, 3, ..., 132, 133, 134, 135, 136, 137 Next
Author Message
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sat 23 Nov 2019, 21:10    Post subject:  

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.
_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Tue 26 Nov 2019, 22:03    Post subject:  

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:
[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?

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
Sage

Joined: 04 Oct 2005
Posts: 5503
Location: GB

PostPosted: Wed 27 Nov 2019, 03:43    Post subject:  

Quote:
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?)
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sun 01 Dec 2019, 22:10    Post subject:  

BarryK wrote:
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:
[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/bluetooth-fixes-for-easy.html

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

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sun 01 Dec 2019, 22:15    Post subject:  

BarryK wrote:
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-541-with-lockdown-and-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-user-installed-apps-into-containers.html

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sun 01 Dec 2019, 22:17    Post subject:  

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.
_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sun 01 Dec 2019, 22:31    Post subject:  

ras wrote:
Hi Barry,

Quote:
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?

Quote:
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:
empty -f ec-chroot chromium


Just run this in a terminal:

Code:
# 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

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Sun 01 Dec 2019, 22:50    Post subject: Re: Sea Monkey in container still crashes  

Rodney Byne wrote:
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.

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
scsijon

Joined: 23 May 2007
Posts: 1538
Location: the australian mallee

PostPosted: Mon 02 Dec 2019, 00:25    Post subject: buster 2.1.8 - container startup and another  

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?
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Mon 02 Dec 2019, 21:26    Post subject: Re: buster 2.1.8 - container startup and another  

scsijon wrote:
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 "/"

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Mon 02 Dec 2019, 21:32    Post subject: Re: buster 2.1.8 - container startup and another  

scsijon wrote:
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?

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 9099
Location: Perth, Western Australia

PostPosted: Mon 02 Dec 2019, 22:04    Post subject: Re: buster 2.1.8 - container startup and another  

scsijon wrote:
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.

_________________
https://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
scsijon

Joined: 23 May 2007
Posts: 1538
Location: the australian mallee

PostPosted: Tue 03 Dec 2019, 02:02    Post subject: Re: buster 2.1.8 - container startup and another  

BarryK wrote:
scsijon wrote:
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.

Last edited by scsijon on Tue 03 Dec 2019, 02:25; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
scsijon

Joined: 23 May 2007
Posts: 1538
Location: the australian mallee

PostPosted: Tue 03 Dec 2019, 02:24    Post subject: Re: buster 2.1.8 - container startup and another  

BarryK wrote:
scsijon wrote:
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..
Back to top
View user's profile Send private message Visit poster's website 
ras

Joined: 30 Oct 2019
Posts: 13

PostPosted: Wed 04 Dec 2019, 20:21    Post subject:
Subject description: difficulty making containers
 

Quote:
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
Pyro and Buster on Thinkpad T420
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 134 of 137 [2046 Posts]   Goto page: Previous 1, 2, 3, ..., 132, 133, 134, 135, 136, 137 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2323s ][ Queries: 13 (0.1186s) ][ GZIP on ]