Puppy Linux Discussion Forum

fredx181 wrote: ↑Thu Jan 06, 2022 10:49 pm

On alpha8 the octoxbps program doesn't run from Menu, reason is probably that /home/spot isn't owned by spot (is owned by root).
Fixed it by running chown -R spot:spot spot
(and similar is needed to be done for /home/weedog and /home/void I guess (also owned by root))

EDIT; Looking back I see:

bigpup wrote:

Alpha 8

Installed Gparted using OctoXBPS

That I don't understand how octoxbps works for you, are you sure it's on alpha8 ?

Sorry for confusion!!!
I guess something I had in the old save was letting it work.
I have to stop using the old save with a new version of KLV-Airedale

I tried it with a fresh clean install of alpha 8.
Yes, Octoxbps is not working from menu entry.

I tried your terminal entry:
chown -R spot:spot spot
But I get this:

bash-5.1# chown -R spot:spot spot
chown: cannot access 'spot': No such file or directory

But this worked:

chown -R spot:spot  /home/spot

Now Octoxbps is starting from the menu entry.

Rockedge,

Do you think it is time to put some kind of web browser in the build?

I do, but which one?

bigpup wrote:

I guess something I had in the old save was letting it work.
I have to stop using the old save with a new version of KLV-Airedale

Yes, very important to test with fresh save (but can be very inconvenient to lose all changes made, I know).

bigpup wrote:

Have to take a look at how Gparted is started, in normal Puppy version menu, that gives you selection of what drive, before Gparted opens.
So Gparted opens, only looking at that specific, selected drive.

Here's for testing a package that includes some Puppy scripts (gparted_shell, probedisk, probepart) so should do what you suggest.
I've added as dependencies: "gparted e2fsprogs dosfstools mtools yelp gpart exfat-utils"
After install run from Menu > System > Gparted partition-manager (there's also a "normal" Gparted entry, btw).

@bigpup :-

bigpup wrote: ↑Fri Jan 07, 2022 8:25 am

Rockedge,

Do you think it is time to put some kind of web browser in the build?

I do, but which one?

You've just opened the "can of worms", haven't you? Or maybe not....

Despite being an avid proponent of the Chromium-based 'clones', it's always been traditional in the open-source world to go with 'zilla-based browsers. So; what do you go with? Do you want 'full-featured' and updateable.....or do you go with 'lightweight' and updateable?

The former inevitably will mean Firefox. The latter will almost certainly come back to Pale Moon.....

It's down to rockedge, ultimately, since he's building the ISOs. Personally, I no longer care what browser I use, nor will I advocate one way or the other, so there'll be no argument from me whatever is eventually decided upon. And whatever's installed as 'default', users can still install/run their own browser of choice in any case, much as always....

Let's get Erik's opinion on the matter.

Mike.

I tried to see what browsers you could get from OctoXBPS.

These are the ones offered:
Firefox
Chromium
Netsurf
Otter
Falkon
Dillo
Opera
Midori

Well, we know what the very small ones are.

Some of them also installed a lot of stuff like QT5, Python3, etc....

Falkon was the worst. Needing 68 other programs/files.

Firefox only needed Firefox stuff.
Opera the same.

Some would not run from their menu entries.
Had to run them from terminal using run-as-spot
Chromium
Otter
Opera
Falkon

Dillo did not make a menu entry. Does run from terminal.

The ones that seem fast:
Dillo
Netsurf
Midori

Firefox is about like it normally runs.

@fredx181, @wiak, @mikewalsh, @bigpup, @Keef Thank you for all the work and thought put into KLV-Airedale. With all the ideas, added features and scripts that will make this distro really useful, it feels like we are approaching the Beta stage.

Alpha9 is being readied and will include Firefox as the browser installed via XBPS.
All the GParted technology is now included. A Hash checker program perhaps also will be installed once something is decided on. (suggestions?)

Also added the updated Syndownload launcher. Also made sure spot and weedog are owners of /home/spot and /home/weedog

rockedge wrote: ↑Fri Jan 07, 2022 2:26 pm

@fredx181, @wiak, @mikewalsh, @bigpup, @Keef Thank you for all the work and thought put into KLV-Airedale. With all the ideas, added features and scripts that will make this distro really useful, it feels like we are approaching the Beta stage.

Alpha9 is being readied and will include Firefox as the browser installed via XBPS.
All the GParted technology is now included. A Hash checker program perhaps also will be installed once something is decided on. (suggestions?)

Also added the updated Syndownload launcher. Also made sure spot and weedog are owners of /home/spot and /home/weedog

It's always a slow business, honing/polishing/finalising any OS, even one as small as Puppy. But we're getting there, and credits are of course due to rockedge for all the tireless re-building/re-mastering he's been putting into this.

I've mentioned in my 'Puppy Corner' over at BleepingComputer that we're in the middle of developing a somewhat 'different' member of the kennels. Only posted about it last night, but I expect we'll get some interest from over there, too.

I'm about to find just how fast Puppy really CAN be with modern tech. I've treated myself to a 1TB Crucial MX500 SSD to replace the 1TB Toshie HDD as the primary drive in this new HP rig. I've formatted/partitioned it, and am in the middle of copying all the Pups & data across ATM. I'll keep y'all posted as to how I get on....

Mike.

Is it just me, or has anybody else noticed how many entries are getting jammed into /var/cache/fontconfig? It seems like the size of this directory is growing exponentially; even with an SSD write speed of over 500MB/s, it's still taking like 20-25 minutes to copy just this one directory...???

Can this be deleted safely? If so, I'll have to write a wee script to clear it, and stick it in /root/Startup. Doesn't seem to actually have a use, and a quick web search indicates that there's tons of useless crap that seems to end up in /var/cache on a regular basis.

Seems XFCE generates a new entry in /var/cache/fontconfig every single time text is entered into absolutely anything. How utterly pointless.

My /var/cache/fontconfig directory is presently 425 MB in size, though that's not the issue; the issue is that there's currently approaching 4.2 million individual files in there, and when doing backups, every one of those entries has to be copied individually.....one after another.

There can't be any need to keep all this junk, surely..?

Mike.

xbps-remove -O

should do the business. I think.
Generally, anything in a 'cache' is expendable. Give 'em hell, Mr Walsh, give 'em hell.

@mikewalsh before I squash the rootfs I go into and delete all of the contents of /var/cache/xbps, this will significantly reduce the overall size of the rootfs SFS. And you can safely do this on your running systems.

I also, as keef mentions, use these commands below AND then go and delete manually from /var/cache/xbps

// Cleaning package cache
# xbps-remove -yO

// Removing orphaned packages
# xbps-remove -yo

I am only seeing around 426 Kilobytes in /var/cache/fontconfig running alpha8

mikewalsh wrote:

My /var/cache/fontconfig directory is presently 425 MB in size, though that's not the issue; the issue is that there's currently approaching 4.2 million individual files in there, and when doing backups, every one of those entries has to be copied individually.....one after another.

Wow, indeed that's crazy, we need to find out what exactly is causing this.

rockedge wrote:

// Cleaning package cache
# xbps-remove -yO

// Removing orphaned packages
# xbps-remove -yo

That doesn't remove all packages in /var/cache/xbps, any thoughts ? (besides manually removing)

@fredx181 I have not found a way that is better than manually deleting the files from /var/cache/xbps

I will have to further research this. @wiak gave me the tip about deleting the contents when we started building the first versions of FirstRib/WeeDog and I have yet to find a command that does it.

We will need a script that can perform the deletions if required I think. This might be the best approach.

I so far am not seeing any significant numbers of files in the fontconfig directory.
I have currently 426 Kilobytes in /var/cache/fontconfig

@mikewalsh I think you can delete the files from /var/cache/fontconfig, but leave the directory intact. The system is supposed to periodically flush this directory to prevent it from growing too large. I wonder what is going on?

I've found a couple of references to this problem, such as this:
https://unix.stackexchange.com/question ... fig-issues
... but no real answers.
Also here: https://github.com/openbmc/openbmc/issues/3680

I checked the size of /var/cache/fontconfig in KVL while running Fatdog, and it was 29mb. On booting it was 31mb, and rises slightly when starting a new program.

rockedge wrote:

I have currently 426 Kilobytes in /var/cache/fontconfig

For me it's acceptable too, only 1.5 MB.
Mike can better speak for himself, but I guess he's using the save storage for a longer time.

I have tested KLV-Alpha8 boots via DVD, QEMU, SG2D, and Ventoy.... ALL boot without any issues to the expected desktops.

In review of the boot stanzas, instmod is showing those expected formats for USB sticks ie f2fs, exfat. Since ext4 is 'suppose' to be optimized for sticks, should it also be included?

insmod ext2
insmod f2fs
insmod ntfs
insmod exfat

And, I wonder if the differences between RAM0 and RAM2 might be articulated either in the 1st KLV forum post where users download or an enlarged description on the 'MenuEntry' line of the purpose of each?

menuentry "KLV-Airedale-alpha8 (RAM0) - Copy SFS files to RAM" {
    linux /vmlinuz-5.13.19_1 findiso=${iso_path} w_bootfrom=${iso_path} w_changes=RAM0 net.ifnames=0
    initrd /initrd.gz
}

menuentry "KLV-Airedale-alpha8 (RAM2)" {
    linux /vmlinuz-5.13.19_1 findiso=${iso_path} w_bootfrom=${iso_path} w_changes=RAM2 net.ifnames=0
    initrd /initrd.gz
}

Of course, if this is NOT expected to remain, a mission-statement of differences of RAM0 vs RAM2 could be ignored.

This distro performs extremely well. Looking forward...

There is a etc/rc.shutdown

It says this in it:

# Default rc.shutdown for void; add your custom commands here.
#
# This is run by runit in stage 3 after the services are stopped
# (see /etc/runit/3).

I guess commands to clear the cache could be put in it.

Note:
var/cache/xbps
This seems to be a cache of all the xbps packages that have been installed.
They are there basically as a backup if you need them again.
If you install a newer version and need to drop back to the older version.
https://docs.voidlinux.org/xbps/advanced-usage.html

fredx181 wrote: ↑Fri Jan 07, 2022 7:58 pm

rockedge wrote:

I have currently 426 Kilobytes in /var/cache/fontconfig

For me it's acceptable too, only 1.5 MB.
Mike can better speak for himself, but I guess he's using the save storage for a longer time.

Mm.....o-kay.

Well, for better or worse, I've been using the same upper_changes directory right since Alpha1. I'm not a proper 'tester' - not really. I'm not one of those who tries something merely to see if it'll boot & do basics......then immediately moves on to trying something else, or the same thing in a different configuration, or trying to boot the thing in a different way. Such behaviour bores me to tears.

If I boot summat, I want to use it; and I get quickly pissed-off re-installing stuff over & over, again & again. (I get pissed-off booting one OS after another, over & over again. That holds NO attractions for me.....my 'distro-hopping' days are long behind me, I'm afraid. Clarity's 'hobby' would have me tearing my hair out before long - what's left of it!)

I'll just delete the contents of /var/cache/fontconfig, so long as it won't upset the system. It's already extremely 'usable' for me, and from this point on I'll be happy simply to 'refine it'. Fortunately, the way it's constructed means it's very simple to update through the builds as they appear, without upsetting anything.

(The daft thing is, I only see these excess files from outside of KLV. When in KLV, /var/cache/fontconfig insists it's empty..! Explain that one to me, if you can.)

Mike.

mikewalsh wrote:

(The daft thing is, I only see these excess files from outside of KLV. When in KLV, /var/cache/fontconfig insists it's empty..! Explain that one to me, if you can.)

Maybe I can explain for a part (but still investigating, so not sure).
First: In Puppy (using "aufs"), when files are deleted that are part of the system (inside .sfs's), so called "mask" files will appear in the save storage.
In Puppy they have extension .wh (whiteout), in KLV (using overlay) they have no extension, but the type of file is a "character device" displayed as "c" (see below).
Part of output from ls -l from my upper_changes/var/cache/fontconfig:

-rw-r--r--    1 root root    120 jan  8 14:00 0040169b-4fca-4704-9727-a56241d33036-le64.cache-7
c--------- 1043 root root   0, 0 jan  8 10:50 003f475f-e4fd-45af-b5c5-72e309279d48-le64.cache-7

The first is a normal cache file, the second is a "c" c--------- file.
As the fontconfig cache is frequently regenerated (deleting files and adding new files) many "c" files could appear in upper_changes/var/cache/fontconfig.

Again, I may be absolutely wrong, and don't know yet if it has to do with the excessive amount of files in the cache.
(and after I delete all the files in the cache, very soon it grows to e.g. 6000 files after using the system and doing a couple of reboots, not okay IMHO)

EDIT;

many "c" files could appear in upper_changes/var/cache/fontconfig

Wrong, the "c" files I saw in upper_changes/var/cache/fontconfig are from var/cache/fontconfig inside 07KLV-airedale_rootfs.sfs
@rockedge better remove these in a future build, but.. probably even then, still the problem of the excessive growing of in the cache.
So some solution needs to be found, e.g. what @bigpup suggested, deleting the fontconfig cache at shutdown.

@fredx181 :-

Mm. I agree. I think the best way to deal with all this excess file creation is to either delete at boot, or delete immediately prior to shutdown...

Mike.

@fredx181 Yes I seem to have forgotten to purge the fontconfig while I was preparing to squash the rootfs! This of course must be done so in alpha9 that will be the case.

I have not had a single KLV system going long enough to be impacted by this, BUT it must be addressed.

I vote for a shutdown script that clears all the cache's for now until we determine this is the best way or we find out the "official" way.

Some inquiries at Void Linux is in order as to why this is and what we can do to deal with it. Better yet would be that we solve it ourselves in case this is a KLV-Airedale only issue.

Just had to deal with the oldforum being almost completely crashed today. Seems an extension went south and failed. It's fixed now but I was in a stressful panic as to what was happening when it was reported today. Several coffee's and tea's did not immediately help the cause either.

rockedge wrote:

I have not had a single KLV system going long enough to be impacted by this, BUT it must be addressed.

I vote for a shutdown script that clears all the cache's for now until we determine this is the best way or we find out the "official" way.

Some inquiries at Void Linux is in order as to why this is and what we can do to deal with it. Better yet would be that we solve it ourselves in case this is a KLV-Airedale only issue.

Hi rockedge, I think deleting the fontconfig cache at shutdown is not a real solution, but just a workaround to prevent that it doesn't get too large.
To see the "problem", open a Thunar window in /var/cache/fontconfig.
Then just run some simple applications, e.g. pfind, gifenc ...
You'll probably see at the Thunar window: "Loading folder contents" and everytime around 50-100 files are added to /var/cache/fontconfig.
I think it's a real problem because every time it puts a load on the system (CPU, RAM usage).

I checked other systems (DebianDog, WDL Manjaro, Fossadog) if such a thing happens, but not, just small amount of files in /var/cache/fontconfig and doesn't change during session.

I did lots of investigating today, tried running with different kernel, installed fontconfig and libfontconfig from Debian, all didn't make a difference.

Finally tested by (auto)login as "spot" and noticed very different behaviour, normal IMO:
- /var/cache/fontconfig not changed (made it empty, then stays empty, no matter what).
- In /home/spot/.cache/fontconfig the cache files appear (small amount), and stay the same during the session for me.

So, I think that conclusion may be that "running as root" in Void is a problem in this case.

I fear Fred may be right. In this particular case, the days of the community running as root are no longer going to "gel" with the base we've chosen.....so this will have to become the very first ever multi-user Puppy (and probably means use of the dreaded 'sudo' mechanism, which attempts to protect you from the consequences of your own foolishness!)

Never thought I'd see this day. (*shakes head...*)

Mike.

@fredx181 Yes I see the that this is a major problem to straighten out. Why would the system running as root function this way? What would be the reason to have to do this?

I do not recall this happening in WeeDog WDL-Void builds. I will have to check that. Is it XFCE4 that is involved?

rockedge wrote: ↑Sat Jan 08, 2022 8:37 pm

@fredx181 Yes I see the that this is a major problem to straighten out. Why would the system running as root function this way? What would be the reason to have to do this?

I do not recall this happening in WeeDog WDL-Void builds. I will have to check that. Is it XFCE4 that is involved?

Yes, good questions, perhaps some bug? It's not standard to run as root so may not easily be discovered. I'll test tomorrow XFCE4 in other OS too.

rockedge wrote: ↑Sat Jan 08, 2022 8:37 pm

@fredx181 Yes I see the that this is a major problem to straighten out. Why would the system running as root function this way? What would be the reason to have to do this?

I do not recall this happening in WeeDog WDL-Void builds. I will have to check that. Is it XFCE4 that is involved?

I'm overloaded at home at the moment so not checking anything much out, so haven't checked this issue either. I suggest you also take a look at your KLV-Boxer (JWM/Rox) variant and see if same issue occurring there.

@fredx181 , @wiak I think I found something. Check this out https://unix.stackexchange.com/question ... fig-issues

I tried the command fc-cache -r -v and I see the same exact errors as listed in the stackexchange post.

This in fact maybe a bug with fontconfig, though I am not sure what version we have.

rockedge wrote: ↑Sat Jan 08, 2022 11:10 pm

@fredx181 , @wiak I think I found something. Check this out https://unix.stackexchange.com/question ... fig-issues

I tried the command fc-cache -r -v and I see the same exact errors as listed in the stackexchange post.

This in fact maybe a bug with fontconfig, though I am not sure what version we have.

You beat me to it... I was just posting the following:

I haven't read above posts about this font cache matter as yet, but noted myself the following two old reports. Alas none suggested any solution. Seems like something has gone wrong somewhere but likely a bug that can be fixed since so rarely posted about online.

https://askubuntu.com/questions/1159074 ... 1259-files

https://unix.stackexchange.com/question ... fig-issues

I have no font-cache errors or issues in WDL_Arch64, which uses fc-cache version 2.13.94.

I see no issues in voidpup32 using fc-cache 2.13.1

But I have an older WDL_Void XFCE version rc5 you created rockedge and it seems to have corrupted font cache file issues too (it uses fc-cache 2.13.1)

Haven't had chance to try the non-XFCE KLV distro yet.

@wiak As indicated, it does seem v 2.13.1 has a cache bug and an upgrade fixes it. I haven't tried it yet though!

UPDATE: KLV-Airedale is currently running the following version of fontconfig

sh-5.1# xbps-query fontconfig
architecture: x86_64
automatic-install: yes
conf_files:
	/etc/fonts/fonts.conf
filename-sha256: 5166bbce63131e61f68d2cb373bae55ac9751c9982d370a924b924e35a186b42
filename-size: 179KB
homepage: http://www.fontconfig.org
install-date: 2021-12-18 14:17 UTC
install-script: 789B
installed_size: 556KB
license: MIT
maintainer: Orphaned <orphan@voidlinux.org>
metafile-sha256: a453aa1e67ce8406ce74198002c47113d5b9f543012dc82478c7e747154f0b94
pkgname: fontconfig
pkgver: fontconfig-2.13.1_3
repository: https://mirror.clarkson.edu/voidlinux/current
run_depends:
	glibc>=2.29_1
	freetype>=2.3.9_1
	expat>=2.0.0_1
	libuuid>=2.18_1
shlib-provides:
	libfontconfig.so.1
shlib-requires:
	libc.so.6
	libpthread.so.0
	libfreetype.so.6
	libexpat.so.1
	libuuid.so.1
short_desc: Library for configuring and customizing font access
source-revisions: fontconfig:0a314cdeaf
state: installed