Puppy Linux Discussion Forum

Another one, see blog post:

https://bkhome.org/news/202105/run-foss ... asyos.html

fossa in a container works without a hitch. update to 2.7.3 went good also. tried xenial and the desktop was covered in icons. Don't have a need for it though, so not an issue really.

Having an up to-date-debian capable puppy in a container works out well. Especially useful in fossa is Pkg - CLI package manager by sc0ttman.
https://oldforum.puppylinux.com/viewtop ... ca890a&i=1

williwaw wrote: Fri May 07, 2021 1:13 am

tried xenial and the desktop was covered in icons. Don't have a need for it though, so not an issue really.

That problem has plagued me right from the start. It is a problem with ROX-Filer.

You should be able to fix it by a manual edit. Open file 'xenialpup' in a text editor, do this when xenialpup IS RUNNING:

/mnt/sda8/easyos/containers/xenialpup/container/.control/xenialpup

You will find a "sleep 2", change that to "sleep 5".

Then kill xenialpup and restart it. You can kill it by right-click on xenialpup in the tray and choose "kill".

Hi Barry,

increased sleep to 5 and was presented with a different pattern of icons
increased sleep to 8 and it went back to the same patterns as 2
increased sleep to 12 and got a good desktop

edit- some time later, 12 is no better than 2
seems intermittent...

BarryK wrote: Fri May 07, 2021 1:29 am

williwaw wrote: Fri May 07, 2021 1:13 am

tried xenial and the desktop was covered in icons. Don't have a need for it though, so not an issue really.

That problem has plagued me right from the start. It is a problem with ROX-Filer.

Actually, isn't it jwm which manages the desktop?
Having no coding ability --basically a displaced historian/Appellate Attorney-- when faced with a problem my inclination is to search for a reported different method of accomplishing an objective. Which leads me to wonder if Saluki, https://oldforum.puppylinux.com/viewtopic.php?t=73687 "a woof-build based on Racy 5.2 with Xfce" could serve the same purpose as Racy while avoiding the desktop display problem. It's an exploration I'd undertake myself but without adequate coding skills I wouldn't know what to look for, especially with respect to an occasional problem.

[And my attempts to create a containerize OS didn't go well ]. So, thanks Barry for the alternatives]. Anyone want to try their hand at a containerized bionicpup32? of which there's been a great deal of praise. Hint, Hint.
FYI, after jemimah went quiet, Geoffrey, elroy, and rg66 continued to publish updated xfce-racys under the name 'Carolina'. https://oldforum.puppylinux.com/viewtop ... 35&t=81312. Battleshooter updated its glibc with version 1.3. Smokey's repo has most of the ISOs, http://www.smokey01.com/saluki/isos/; http://smokey01.com/carolina/isos/

Lxde (openbox) can be added to most Puppys (convert peebee's SFSes to pets for use in containerized OSes) but AFAIK, that possibility is not available for xenial for various reasons: sfs never published, ISO didn't work well and was withdrawn; and there never was a 64-bit version.

I noticed with some version of EasyOS (currently 2.7.2) that the scattered icons on the Racy desktop are gone if you restart the. xserver in the main window. If you then restart Racy everthing looks as it should.

mikeslr wrote: Fri May 07, 2021 10:37 pm

FYI, after jemimah went quiet, Geoffrey, elroy, and rg66 continued to publish updated xfce-racys under the name 'Carolina'. https://oldforum.puppylinux.com/viewtop ... 35&t=81312. Battleshooter updated its glibc with version 1.3. Smokey's repo has most of the ISOs, http://www.smokey01.com/saluki/isos/; http://smokey01.com/carolina/isos/

Lxde (openbox) can be added to most Puppys (convert peebee's SFSes to pets for use in containerized OSes) but AFAIK, that possibility is not available for xenial for various reasons: sfs never published, ISO didn't work well and was withdrawn; and there never was a 64-bit version.

OK, I will have a look at Carolina.

Apart from the corrupted wallpaper, Racy has a problem with its SeaMonkey browser -- it gives an error connecting to most https:// sites. It seems to be too old.

Recognizing how often my memory misleads me, I reviewed the relationship between rox and the desktop background. Not an exhaustive review and I may have it wrong. But it appears that by default we set rox's options to manage both the panel and the pinboard. If I've got it right, its rox's command of the pinboard which controls the desktop-background. If so, than its mismanagement may be the cause of the problem. And the solution might be to 'turn-off' that management and use another application. feh is a light-weight supposedly easily compiled application --I wouldn't know-- which can be so used. https://feh.finalrewind.org/. I recalled it from some Puppy. Command-line only, but how many desktop-backgrounds does a 'child-OS' need? But what else does the pinboard control?

Other than as a 'child' under EasyOS, I haven't run racy for a while. Nor for that matter even Carolina 1.3 with its updated glibc. Getting Web-browsers to be fully functional in 32-bit systems has become a Royal PITA.
fredx181 developed the technique including necessary libraries and/or their upgrades within the application folder and watchdog extended that to include glibc libraries. Mike Walsh has been packaging many web-browsers as 'portables' that combined both fredx181's and watchdog's efforts. Mike's portables locate 'profiles' within the portable folder. I've run Mike portables under EasyOS, both the Main OS and child OSes by locating the portables in the /opt folder. Watchdog, however, concentrated his efforts on palemoon (a firefox fork). But palemoon has announced the intention to drop 32-bit support and watchdog, accordingly, has announced that he will not be publishing any new palemoon pets.
Preferring seamonkey anyway, I've 'flinched' fredx181's and watchdog's library packages and Mike Walsh's packaging technique. After downloading a seamonkey from here https://www.seamonkey-project.org/releases/ and extracting it, I've placed fred's extralib's folder and watchdog's glibc228 folder in seamonkey and started seamonkey via a slightly modified version of Mike Walsh's 'smky' script. I can tell you that such seamonkey runs. But, I don't know how I can test whether it's actually employing the include glibc 2.28 libraries*, nor whether it would function under a 'child' OS. Nor whether that alone would enable racy to access all https websites. [May require a system update of openssl?].
At any rate, if you want to try it, I've uploaded a package (with deployment instructions) to https://www.mediafire.com/file/xu9sl368 ... ar.gz/file.

* The oldest 32-bit Puppy I can boot into without much preparation is Slacko 5.7.x.

Rox is the wallpaper and the desktop icons on the wallpaper, and shortcut keys that might be set to each icon.
The Rox pinboard is a configuration file that can be read and edited as text.
Puppy's pinboard file is /root/Choices/ROX-Filer/PuppyPin

Older versions of Rox kept the configuration files in /root/Choices/
Newer versions of Rox keep the configuration files in /root/.config/rox.sourceforge.net/ROX-Filer/
Fatdog uses this location.

You can create and use as many pinboards as you want.
rox -p 1 (or rox -p1) will use a pinboard named 1 which creates a pinboard file /root/.config/rox.sourceforge.net/ROX-Filer/pb_1
rox -p PuppyPin will use a pinboard file named pb_PuppyPin

Rox tries to run 1 instance of Rox, whatever pinboard is running, or not, and however many roxfiler windows are open.
If Rox is already running in EasyOS, maybe starting a rox pinboard in a container is not starting a new instance of Rox, maybe it is just setting the pinboard of the EasyOS instance? Or is more than 1 instance of Rox running?

JWM is responsible for the bar at the bottom, and the menu, and the bars at the top of each window, with the close and maximize buttons. JWM enables you to move and resize each window.
JWM has nothing to do with the pinboard.
You can see what Rox and JWM do by restarting X like this: xwin urxvt
The Rox pinboard will be running but JWM will not be running.
Kill X and start X using xwin jwm to get JWM back.

Hi williams2, thanks for the clarification.
Hi Barry K. If you haven't gotten deep into the weeds with Carolina yet, maybe put it on the back-burner. I've had 2nd thoughts and done some experimenting. But it's late here. 23.18. Will fill you in tomorrow.

I cannot change wallpapers in containers, and icons created on desktops do not persist once a container is closed.

I am working on what might be a fix for the corrupted wallpaper.

It is very annoying, because sometimes the wallpaper is not corrupted, and may be fine for many startups of racy or xenial. Then suddenly becomes corrupted again.

I cannot turn off the pinboard and use something else, such as feh or xli, as the pinboard is also responsible for the desktop icons, as well as the wallpaper.

What I am trying now, is remove the <backdrop> tag out of PuppyPin, so no wallpaper will display. Then after the desktop has loaded, run 'set_bg <wallpaper file>', which runs "rox --RPC ...." which loads the wallpaper.

This is how the wallpaper apps, such as Qwallpaper and Pwallpaper do it, via /usr/sbin/set_bg.

So, I wonder if corrupted wallpaper is now fixed?

https://bkhome.org/news/202105/wallpape ... iners.html

williwaw wrote: Sun May 09, 2021 5:05 am

I cannot change wallpapers in containers, and icons created on desktops do not persist once a container is closed.

I should mention the loss of ability to change wallpapers or the persistence of newly created icons applys to all containerized desktops, not just racy or xenial. easy, fossa and scpup when run in a container

another or the same rox problem?

in a new xenial container, (and also in scpup and fossapup)
clicking on the middle box to manage iconslayout in jwmdesk brings up this error

williams2 wrote: Sat May 08, 2021 8:12 pm

Rox tries to run 1 instance of Rox, whatever pinboard is running, or not, and however many roxfiler windows are open.
If Rox is already running in EasyOS, maybe starting a rox pinboard in a container is not starting a new instance of Rox, maybe it is just setting the pinboard of the EasyOS instance? Or is more than 1 instance of Rox running?

Rox in the container is started with the "-n" option, which will start a new instance.

# rox -n -p <path to PuppyPin>

We can confirm that rox is reading the correct pinboard and not getting confused somehow by the host-system rox, by taking out <backdrop> tag from PuppyPin, and the desktop icons display fine.

It is only that <backdrop> tag that upsets rox. This would likely be something to do with the backdrop is only a window being served by the Xephyr nested web server, not the real root window.

the new xenialpup_7.5-r1 replacement fixes the problems with persistence of wallpaper and icons as reported above.

In the other containerized pups and dunfell, substituting the newly reconfigured desk-delayedrun (taken from xenialpup_7.5-r1 ) does not have the same effect.

williwaw wrote: Mon May 10, 2021 1:25 am

the new xenialpup_7.5-r1 replacement fixes the problems with persistence of wallpaper and icons as reported above.

In the other containerized pups and dunfell, substituting the newly reconfigured desk-delayedrun (taken from xenialpup_7.5-r1 ) does not have the same effect.

.control/xenialpup would have to be copied and renamed.

Anyway, I have done further work on those scripts.

There is now a xenialpup_7.5-r2.

Yes, I do intend to rebuild the others.

I haven't given up on Fatdog yet. SM crashes, but I might set it up with a different browser.