Vanilla Upup 22.04.61

[thinkpadfreak]

Can you share a screenshot of sfs_load?

After I created a save file, that is, at second boot, extra sfs(es) appeared in the list.
I had not understood correctly. Sorry for the mess.

So, docx and nlsx were loaded successfully at 3rd boot. But Chrome 102 (sfs) was not loaded even though I had selected it.
Is there a limitation to the number of extra sfs(es) loaded?

[dimkr]

Is there a limitation to the number of extra sfs(es) loaded?

Not that I know of.

But I see that Chromium is not selected. SFSs selected for load at boot time are highlighted, like docx and nlsx. Click the Chromium SFS and reboot.

[mikeslr]

Where did you get the Chromium 102 SFS? Or more pointedly, is it the same one you posted about here, viewtopic.php?p=59179#p59179 which was built to run under Slacko64?

If so, examine the SFS to determine how it's been structured. Look for the discussion about 'usr-merge' which now limits where libraries can be located and is applicable to new Ubuntu and debian based OSes, but not those based on Slackware.

If you try to install an application with the wrong structure, you'll receive a notice. But a similar notice may not appear if you attempt to SFS-load an SFS with the wrong structure.

[thinkpadfreak]

Thanks for quick responses from you two.

But I see that Chromium is not selected. SFSs selected for load at boot time are highlighted, like docx and nlsx. Click the Chromium SFS and reboot.

The picture was misleading, because it was snapshot just after reboot. Before the reboot, I had selected Chrome 102 sfs (not Chromium).

Where did you get the Chromium 102 SFS? Or more pointedly, is it the same one you posted about here, viewtopic.php?p=59179#p59179 which was built to run under Slacko64?

This Chrome (not Chromium) 102 sfs was made by myself. I downloaded an official deb package from Google, unpacked it, and made the contents into an sfs with mksquashfs command. Nothing has been changed and nothing has been added. SFSs made in this way worked fine on Ubuntu-based pups and Slackware-based pups before the introduction of Chrome 102.

Chrome 102 works fine except for an inactivity of input methods. Moreover, Fossapup64 and Jammypup64 9.7b allow us to use input methods on Chrome 102.

[Grey]

Jammypup64 9.7b

Don't take this version seriously It was made to test some features of woof-ce (although vodka was not used this time ). It's better to wait for the version from Phil, although he may decide to include all the innovations there (and controversial ones too). But it's still better to wait.

[thinkpadfreak]

@dimkr and @mikeslr

I tried to load Chrome 102 sfs again, and this time it was loaded successfully.
I may have done something wrong last time I tried. But at the same time I suspect that the previous failure was due to the usb stick. I am booting Vanilla Upup from a usb stick.

When I tried to start Chrome, it complained about libnss. So I installed libnss through the package manager. The libnspr package was also installed.

Chrome started fine, but surprisingly I cannot use an input method on Chrome. The same error is occurring as in the case of Slacko64.

[thinkpadfreak]

Don't take this version seriously It was made to test some features of woof-ce (although vodka was not used this time ).

I think your "test" was successful to a large extent. Jammypup64 9.7b is running fine except for a few minor issues on my machine. It didn't take me much trouble to make a Japanese language pack for it, because of its orthodoxy.

I don't think Wayland is always compatible with input methods as it stands. When I search the Internet, there are many reports about how to enable input methods on Wayland. Sometimes those reports disagree with one another. I don't know what is right.

[Grey]

@dimkr By the way, I didn't go deep into the question. I realized that "fullscreen Xwayland in kiosk mode". And there are no plans to screw the switch to start with the usual X? Or is everything there nailed to Wayland with titanium nails? Or has everything been there and done for a long time?

[dimkr]

@dimkr By the way, I didn't go deep into the question. I realized that "fullscreen Xwayland in kiosk mode". And there are no plans to screw the switch to start with the usual X? Or is everything there nailed to Wayland with titanium nails? Or has everything been there and done for a long time?

If you want X.Org, you'll need to build your own jammy64. I removed the X.Org/Xwayland toggle because maintaining both is too much work for one developer, and a waste of space for everybody.

The next Vanilla Upup build is almost ready and it fixes many issues. There's only one critical bug left, and if you have more issues - please report them.

[neojack]

Vanilla Upup 22.04.39 running Palemoon 31.1 and LibreOffice 7.3. Really good built of puppy with modern kernel. Will use it often. Thank you @dimkr

neojack_02.png (361.26 KiB) Viewed 3845 times

[thinkpadfreak]

I tried to load Chrome 102 sfs again, and this time it was loaded successfully.
I may have done something wrong last time I tried. But at the same time I suspect that the previous failure was due to the usb stick. I am booting Vanilla Upup from a usb stick.

I erased the save file and started over from the 1st boot without a save file. I did this in order to confirm various things including the use of the input method (fcitx 4.x).

This time I repeated reboot several times before I succeeded in loading the Chrome sfs. I suspect that the cause of the failure lies in the mechanism that Puppy runs totally in RAM unless the user clicks the save button. (I am booting Vanilla Upup from a usb stick.) In principle, the mechanism should work as we expect, though.

As for fcitx, I wrote environment variables in /usr/bin/startxwayland. I could not activate fcitx by writing them in /etc/environment like before.

[dimkr]

A new build, #55, is out!

https://github.com/dimkr/woof-CE/releas ... p-22.04.55

It brings all fixes that went into Vanilla Dpup, the latest JWM, all the Wayland-related improvements in woof-CE, plus:

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3183

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3181

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3179

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3176

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3132

• https://github.com/puppylinux-woof-CE/woof-CE/pull/3127

• https://github.com/puppylinux-woof-CE/woof-CE/pull/2963

[thinkpadfreak]

Hello.

I installed Vanilla Upup 22.04.55 to test it in the Japanese environment.

I chose the following in quicksetup:
language: ja_JP.UTF-8
time zone: Asia Tokyo (local time, not utc)
keyboard: jp japanese

When I run "locale" command, it returns "ja_JP.UTF-8."

However, applications start in the English (US) mode. The menus and messages of the applications are all in English, even though I installed .mo files.

When I run the command export LANG=ja_JP.UTF-8,
and then run an application from the terminal, the application starts in the Japanese mode.

As for the input method (fcitx), it runs OK, except that the messages are all in English. I can input Japanese.

After shutting down Vanilla Upup and starting another Puppy, the clock shows an incorrect time (-9 hours).

[dimkr]

it runs OK, except that the messages are all in English. I can input Japanese.

You'll need to load the nlsx SFS, it's inside vanillaupup-22.04.55-extra.tar.

After shutting down Vanilla Upup and starting another Puppy, the clock shows an incorrect time (-9 hours).

That's because the other Puppy is configured to use local time and not UTC time.

[thinkpadfreak]

You'll need to load the nlsx SFS, it's inside vanillaupup-22.04.55-extra.tar.

The test was made with the nlsx sfs loaded.

That's because the other Puppy is configured to use local time and not UTC time.

I chose "Asia Tokyo" with "utc" unticked, on Vanilla Upup. So the clock should be set to local time.

I managed to localize the previous version of Vanilla Upup. I am sorry to say that things got worse with the introduction of a new version.

The issue with the clock existed in the previous version, too.

[thinkpadfreak]

Sorry for disappointing you, but I made another test.

This time I chose "de_DE.UTF-8," though I know German only a little.

When I tried to start geany by clicking the icon, it started in English.
When I executed "export LANG=de_DE.UTF-8" and then "geany" in the terminal, it started in German.

So I suspect that the graphical server (xwayland ?) is not functioning properly.
I wonder what the applications refer to for the locale when they are started.

[dimkr]

Have you tried to log out or reboot? LANG is set by /etc/profile, so this happens before X (or Xwayland).

[thinkpadfreak]

Have you tried to log out or reboot? LANG is set by /etc/profile, so this happens before X (or Xwayland).

Of course I have.
You will always be prompted to restart the graphical server after changing the locale.

As far as the graphical server is concerned, the previous version seems to be better.

It seems strange to me that other people don't get interested. Wayland is a rather new technology which may need a lot of testing, though I have little knowledge about it.

[dimkr]

You will always be prompted to restart the graphical server after changing the locale.

Try to reboot, the "restart the graphical server" thing doesn't truly log out. It only restarts the compositor.

[thinkpadfreak]

Try to reboot, the "restart the graphical server" thing doesn't truly log out. It only restarts the compositor.

First I have to apologize.
I tried rebooting to find that applications start in Japanese under the Japanese environment.

I wrote environment variables for fcitx in /usr/bin/startdwl. This enabled me to input Japanese.

The message prompting to restart the graphical server is misleading in this version of Puppy.

[dimkr]

The message prompting to restart the graphical server is misleading in this version of Puppy.

As far as I see, behavior is the same as with X. xwin re-runs itself (!) after restartwm, the script that runs when you as to "restart the graphical server". It doesn't log out first, so /etc/profile is not sourced again.

[thinkpadfreak]

Hello.
The following is the result of running xrandr:

Code: Select all

~$ xrandr
Screen 0: minimum 16 x 16, current 1366 x 768, maximum 32767 x 32767
XWAYLAND2 connected 1360x768+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
   1360x768      59.80*+

1360x768 (not 1366x768). Is this the way it should be? If not, I would like to know how to adjust the resolution. Actually, there is a margin on the right of the desktop.

[dimkr]

Hello.
The following is the result of running xrandr:

Code: Select all

~$ xrandr
Screen 0: minimum 16 x 16, current 1366 x 768, maximum 32767 x 32767
XWAYLAND2 connected 1360x768+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
   1360x768      59.80*+

1360x768 (not 1366x768). Is this the way it should be? If not, I would like to know how to adjust the resolution. Actually, there is a margin on the right of the desktop.

Yes, it's a known bug. I contributed a fix to libxcvt, https://gitlab.freedesktop.org/xorg/lib ... requests/9 and even reported it so Ubuntu 22.04 receives this fix (https://bugs.launchpad.net/ubuntu/+sour ... ug/1970021), which hasn't happened (yet).

Adjusting the resolution doesn't help because it's Xwayland which calls a libxcvt function to "detect" the resolution, and that function subtracts 6px from the monitor width reported by the Wayland compositor. This means the Wayland compositor uses the entire display, the compositor correctly maximizes Xwayland, but Xwayland thinks it's 6px narrower and that's what it reports to xrandr and applications.

[dimkr]

libxcvt 0.1.2 is out, with the fix for fullscreen Xwayland on 1366x768: https://lists.x.org/archives/xorg/2022-July/061047.html. The Ubuntu bug (https://bugs.launchpad.net/ubuntu/+sour ... ug/1970021) is now "confirmed", so I hope to see the fix in https://repology.org/project/libxcvt/versions and Ubuntu 22.04 soon.

[thinkpadfreak]

Hello.

Why not announce that a new version has been released? Unless you post a new message, this thread will not appear in "Active Topics."

I have installed 22.04.61.
To start Chrome (official package from Google), libnss3 and libnspr4 are needed.
To start Firefox (official bz2 archive), libdbus-glib is needed.
I think these dependencies should be included in the main sfs.

I suspect that the hardware clock is saved as utc even though "hardware clock is set to utc" is unticked.

Installing CUPS through the puppy package manager fails.
I tried installing it with apt-get, and succeeded. However, the total of installed packages amounts to about 900MB.
Though the main sfs is smaller than those of other recent pups, the save file or folder occupies a rather large space. This is rather inconvenient, and I am afraid it is not the "puppy" way.

[dimkr]

However, the total of installed packages amounts to about 900MB.

With --no-install-recommends or without it?

EDIT:

I wonder where the 900 MB figure comes from, it's way more than what I see.

apt install cups:

apt install --no-install-recommends cups:

[thinkpadfreak]

I wonder where the 900 MB figure comes from, it's way more than what I see.

Sorry. I was running Vanilla Upup in RAM only mode. It seems that the number included SFSs copied onto RAM.
After creating the save file, about 360MB of the 512MB save file was consumed. The --no-install-recommends option, which I didn't know of, reduced the total number.

In addition, I need to install some Japanese fonts and fcitx-anthy to input Japanese. It will be impossible to use Vanilla Upup with the 512MB save file.

Though the save folder will be recommended, I prefer to use the save file. I install multiple pups in the windows partition, and their save files are 512MB ~ 1GB respectively. If CUPS were included in the main sfs, it would be easier to use Vanilla Upup. I would like the devx sfs, too.

It is conceivable to create a remastered iso, but the large iso (SFS) will consume RAM after all.

[mikeslr]

@ thinkpadfreak, "It will be impossible to use Vanilla Upup with the 512MB save file... I prefer to use the save file".

After you get everything straightened out, use the Save2SFS module of nicOS-Utility-Suite, viewtopic.php?t=1694 to capture a SaveFile or SaveFolder in either a ydvr.sfs or a adrv.sfs. [advs has priority over ydrv, but lower than a SaveFile/Folder]. Reboot without the SaveFile/Folder (i.e, pfix=Ram) as it's no longer needed. You can then create a new, small (512 Mbs if desired) SaveFile.
The module will also capture applications you've installed but haven't yet Saved.
The Save2SFS module can be used serially to create new versions of adrv.sfs or ydrv.sfs as you 'straighten things' out, i.e, include other applications you've tested and are satisfied with. [Test: it's far easier to add more than remove something. Neither 'uninstall' nor remove builtins work with that module. But it is easier, faster and less error-prone than remastering].

thinkpadfreak "It is conceivable to create a remastered iso, but the large iso (SFS) will consume RAM after all."
AFAICT, as the contents of file-systems such as puppy_vanilladpup_9.2.2.sfs or an adrv or a ydrv are copied into RAM they are compressed into "cache". Although cache is located in, files in Cache are only decompressed as and when they are actually needed; immediately re-compressed when not. The result is that only a small amount of 'useable RAM' become unavailable. See the report of the exploration here, viewtopic.php?p=4070#p4070

[thinkpadfreak]

After you get everything straightened out, use the Save2SFS module of nicOS-Utility-Suite, viewtopic.php?t=1694 to capture a SaveFile or SaveFolder in either a ydvr.sfs or a adrv.sfs.

Thanks for your advice.
I remember turning a save file manually into an adrv sfs to create a Japanized version of Fossapup64.

AFAICT, as the contents of file-systems such as puppy_vanilladpup_9.2.2.sfs or an adrv or a ydrv are copied into RAM they are compressed into "cache". Although cache is located in, files in Cache are only decompressed as and when they are actually needed; immediately re-compressed when not. The result is that only a small amount of 'useable RAM' become unavailable.

I managed to install CUPS and the files related to Japanese into Vanilla Upup, making use of the 512MB save file. I removed the package data base downloaded by apt-get in order to make room.
I compared Vanilla Upup with EasyPup when Firefox is running on them. Vanilla Upup consumed more RAM on the average than EasyPup, though EasyPup is larger in the size of iso than Vanilla Upup.
I watched the amount of used RAM by means of "htop."

[Clarity]

@thinkpadfreak, curious: How much RAM does your PC have for the multiple OSes you run?

Just curious. Thanks