Puppy Linux Discussion Forum

@dimkr I am posting from dpup 11.0.181

The background setter is not working. No matter what I pick it defaults to the first one in the list

I'm still having problems with the altf1 on waybar it seems to get stuck. I'm not pushing the altf1 button but it keeps being pressed.
This is the log as I watched it live. I only pressed the first one all the rest I was trying to use a waybar icon on the launcher.

Sep 21 19:24:46 (none) kern.info kernel: [  788.512796] input: altf1 as /devices/virtual/input/input17
Sep 21 19:25:05 (none) kern.info kernel: [  807.295049] input: altf1 as /devices/virtual/input/input18
Sep 21 19:25:37 (none) kern.info kernel: [  839.919528] input: altf1 as /devices/virtual/input/input19
Sep 21 19:25:51 (none) kern.info kernel: [  853.301741] input: altf1 as /devices/virtual/input/input20
Sep 21 19:25:54 (none) kern.info kernel: [  856.195386] input: altf1 as /devices/virtual/input/input21
Sep 21 19:26:56 (none) kern.info kernel: [  919.070735] input: altf1 as /devices/virtual/input/input22
Sep 21 19:27:12 (none) kern.info kernel: [  934.325244] input: altf1 as /devices/virtual/input/input23
Sep 21 19:27:41 (none) kern.info kernel: [  963.241525] input: altf1 as /devices/virtual/input/input24
Sep 21 19:27:49 (none) kern.info kernel: [  971.559789] input: altf1 as /devices/virtual/input/input25

I'm also still have that issue with lxterm options. It won't open a window wider than the defaults. It will open one smaller
It has something to do with the display settings. It works fine if the display settings are not scaled up. I can drag the window longer.

Edit: I'm back in my daily driver version now. The update of the save folder went well.
The issue with display setting is fixed on this version.

Thanks

11.0.183 will:

• Fix inability to use a wallpaper image

• Replace the hacky menu button with gaps around waybar

• (Hopefully) fix missing weechat configuration files

• Make sfs_load capable of unmounting a mount-but-not-loaded SFS

• Stop the save2flash prompt at the bottom right corner before the errors list prompt at the top

(EDIT: forgot to mention, I see a big application startup time improvement after the switch to erofs with zstd, on this old dual core laptop: Firefox starts much faster)

@dimkr Posting from dpup 11.0.183
I like this one it is faster and I didn't consider the older ones slow by any means.
Thank you for the air gaps so I can get the menu when running full screen. That is perfect!
All this time it's been a pain for me and all I had to do was set a margin.

Thanks for bring all these new things to puppy. As I research this stuff I see it's not really new. Most of it's been around for awhile. Like erofs has been around since 2019. I'm learning a lot

Great work

d-pupp wrote: Mon Sep 23, 2024 7:32 pm

As I research this stuff I see it's not really new.

Of course it isn't. Nothing here is new, but Puppy is in stagnation for at least a decade: most new development activity begins by copy-pasting existing stuff, without going back to the basics and trying to optimize and rethink things. I know C (with years of experience, both in open-source pet projects and professionally) because my background is in low-level programming and I'm familiar with Puppy internals and its development history, so I was the right person at the right time for this adventure of essentially forking Puppy and rewriting things in a more efficient way.

The init system I wrote is a combination of a simpler one I wrote plus an old implementation of cttyhack I wrote 10 years ago. Everything here is super simple and even trivial: not too different if you look at the guts of busybox init and cttyhack. Both are really old.

The ad blocker I wrote is an improved version of an old one I wrote 9 years ago. Both are NSS modules, a very old concept in glibc. Reading 150k lines from /etc/hosts is a really bad technique for ad blocking and it's always been this way.

sfslock, the tool that reads SFSs into page cache and keeps them there (instead of copying them to a ramdisk like most distros do) is heavily inspired by vmtouch, a tool I've been using at least for several years, maybe since its first releases. The trick of locking page cache is nothing new, the Linux system calls for this have existed for ages and it doesn't require that much creativity to combine them correctly to achieve this effect.

pfscrypt, the tool that encrypts save folders, was not super hard to write. I used the API documentation, which is very good, and verified correctness by comparing to fscrypt using strace and also by reading its code.

Waylad support in yad is based on 01micko's equivalent work in gtkdialog, and it's nothing but a series of calls to gtk-layer-shell functions.

psnapcp, the tool save2flash uses to copy files to the save layer quickly with minimal overwriting, is based on simple techniques like space preallocation and readahead into page cache, all using old Linux system calls. I spent many hours on research on tools like rsync, to see what makes them fast and why, then came up with this simple but very effective solution. I must say I was really shocked to discover how inefficient cp is for synchronization of partially modified files: it actually writes the whole file again, and that's what most distros use in their save2flash-equivalent thing.

@dimkr I thank you for your time and effort on dpup.
I really enjoy using it.
It supper stable and very fast even on my old PC and easy for me to setup and configure.
I think we have the same mind set on this. "Keep it simple"

@BarryK After reading https://bkhome.org/news/202409/bookworm ... cript.html, I think I'd really like to hear your feedback on 11.0.x (bad feedback is welcome too). The build system is at https://github.com/vanilla-dpup/woof-CE and the README has a pretty complete list of unique features, implementation details and differences compared to Puppy. Nothing is set in stone and I'm still unsure about some choices I made: maybe you'll have good counter-arguments to my line of thinking and ideas for useful features, considering all your post-Puppy adventures with things like UID namespaces and btrfs subvolumes

EDIT: 11.0.184 will

• Fix petget permissions (it wasn't executable)

• Move pup-advert-blocker from /usr/sbin to /usr/local/sbin

• Clear DNS cache when starting, stopping or updating the ad blocker, so changes are applied immediately (without waiting for cache to expire)

• Silence logging to console when shutting down with SFS caching enabled

• (If I didn't break this feature) Make SFS caching 'stronger' by caching the backing file itself and not the loop device, making eviction from cache less likely

@dimkr I have noticed during the boot up I get a message upgrading. I thought at first it was because I didn't save. However I have saved a few times now and I am still getting the message.

dpup 11.0.183

d-pupp wrote: Thu Sep 26, 2024 3:06 pm

@dimkr I have noticed during the boot up I get a message upgrading.

What is the output of diff -u /etc/DISTRO_SPECS /initrd/DISTRO_SPECS and diff -u /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG?

What is the output of diff -u /etc/DISTRO_SPECS /initrd/DISTRO_SPECS and diff -u /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG?

root@puppypc:~# diff -u /etc/DISTRO_SPECS /initrd/DISTRO_SPECS
root@puppypc:~# diff -u /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG
--- /etc/rc.d/BOOTCONFIG	2009-04-16 20:00:18.924000015 -0400
+++ /initrd/pup_ro1/etc/rc.d/BOOTCONFIG	2009-04-16 20:00:26.000000000 -0400
@@ -1,4 +1,4 @@
 
 PREVUNIONRECORD='puppy_vanilladpup_11.0.181.sfs nlsx_vanilladpup_11.0.181.sfs docx_vanilladpup_11.0.181.sfs kbuild-6.10.9.sfs fdrv_vanilladpup_11.0.181.sfs zdrv_vanilladpup_11.0.181.sfs'
 EXTRASFSLIST=''
-LASTUNIONRECORD='puppy_vanilladpup_11.0.183.sfs nlsx_vanilladpup_11.0.183.sfs docx_vanilladpup_11.0.183.sfs kbuild-6.10.9.sfs fdrv_vanilladpup_11.0.183.sfs zdrv_vanilladpup_11.0.183.sfs'
+LASTUNIONRECORD='puppy_vanilladpup_11.0.181.sfs nlsx_vanilladpup_11.0.181.sfs docx_vanilladpup_11.0.181.sfs kbuild-6.10.9.sfs fdrv_vanilladpup_11.0.181.sfs zdrv_vanilladpup_11.0.181.sfs'

11.0.186 adds several security and privacy improvements:

• The firewall now blocks SSDP and mDNS by default: mDNS is one of the ways to remotely trigger the CUPS vulnerability everybody is talking about (https://www.theregister.com/2024/09/26/ ... disclosed/) on a Linux machine that meets certain criteria (CUPS discovers printers through avahi, and there's no firewall that drops mDNS). If dropping this traffic breaks applications that depend on service discovery (like multimedia applications with "cast to TV" buttons), mDNS can be whitelisted in the firewall GUI.

• The firewall now also blocks SSDP (aka UPnP), NAT-PMP and PCP by default: SSDP is another (old) service discovery protocol while the latter two can be used to set up port forwarding on the router and expose a device (like a baby monitor) to the internet without any kind of authentication.

• The firewall tray icon is gone, it's kinda useless and the limited space in the bottom bar is better spent on open windows.

• Firefox connectivity checks and captive portal (the login/legal page in airport or train Wi-Fi) detection are disabled by default: they generate outgoing HTTP (not HTTPS!) requests that waste bandwidth, leak data to Mozilla (like your IP address) and can be used to trick the browser into visiting a malicious website automatically (then, running the malicious JS in this website)

dpup 11.0.185 report

It is working good.
I noticed some of the old ip tools have been replace with the newer version. I like that except I have no ping.
I noticed the firewall icon was gone. It would be useful if there was an icon showing if the firewall was down for some reason.
The bootup slow down is still in this version. What is it updating after the first save?

Keep up the good work Dimkr

d-pupp wrote: Sun Sep 29, 2024 6:14 pm

I have no ping.

You can install it:

root@puppypc:~# ping
Command 'ping' not found, but can be installed with:
apt install inetutils-ping
apt install iputils-ping

d-pupp wrote: Sun Sep 29, 2024 6:14 pm

I noticed the firewall icon was gone. It would be useful if there was an icon showing if the firewall was down for some reason.

The firewall is not a process that can crash, it's either enabled at boot time or not (no surprises), hence the firewall tray icon is not that useful. If the firewall is down, it's probably because you disabled it, although this can also happen if you broke nft or replaced the kernel with a misconfigured one that doesn't support nftables. I really think it's a waste of pixels, I never had a reason to look at this tray icon or click it.

d-pupp wrote: Sun Sep 29, 2024 6:14 pm

The bootup slow down is still in this version.

Try to reboot, cp /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG and reboot again. Maybe you have some kind of disk corruption that prevents saving of /etc/rc.d/BOOTCONFIG, and this is the file used to detect version upgrades.

d-pupp wrote: Sun Sep 29, 2024 6:14 pm

What is it updating after the first save?

Nothing, this message is printed to the console in every boot, even when it's not doing anything.

@dimkr Thank you

cp /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG

This fixes the slow boot. It cut the boot time by 15 seconds. From 45 seconds to under 30.

Maybe you have some kind of disk corruption that prevents saving of /etc/rc.d/BOOTCONFIG, and this is the file used to detect version upgrades.

As the fix above worked should I be worried about disk corruption? It is a old spinning hard drive.

The firewall is not a process that can crash, it's either enabled at boot time or not (no surprises),

Good to know as that was my concern that it would crash and I not know for a long time.

I'll look into iputils-ping or maybe just use busybox.

Thanks again

d-pupp wrote: Mon Sep 30, 2024 3:02 pm

Maybe you have some kind of disk corruption that prevents saving of /etc/rc.d/BOOTCONFIG, and this is the file used to detect version upgrades.

As the fix above worked should I be worried about disk corruption? It is a old spinning hard drive.

Check if your /usr/local/sbin/snapmergepuppy.overlay has this block:

# make sure DISTRO_SPECS, PUPSTATE and BOOTCONFIG are saved: these files are modified by initrd, before NTP, and timestamps can be in the future
mkdir -p "$BASE/initrd" "$BASE/etc/rc.d"
psnapcp /initrd/DISTRO_SPECS "$BASE/initrd/DISTRO_SPECS"
psnapcp /etc/rc.d/PUPSTATE "$BASE/etc/rc.d/PUPSTATE"
psnapcp /etc/rc.d/BOOTCONFIG "$BASE/etc/rc.d/BOOTCONFIG"

If this block exists, the problem could be your computer's hardware clock. My laptop thinks it's 2015 every time it wakes up, until internet connection is established and the software clock is set using NTP. Therefore, some files modified early in the boot process have weird timestamps. You can check if the last modification time of BOOTCONFIG is messed up:

stat /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG

If it is, maybe that's the problem and I need to ensure it's saved even if the timestamp is invalid.

EDIT: 11.0.187 should fix the problem, if I understand it correctly. It's going to save BOOTCONFIG even if the last modification time is messed up and it doesn't matter if it's in the future or not.

If this block exists, the problem could be your computer's hardware clock.

@dimkr The above block does exist at line 159

I think you are correct about the hardware clock. Here is the output of

stat /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG

and my current hardware clock settings.

root@puppypc:~# stat /etc/rc.d/BOOTCONFIG /initrd/pup_ro1/etc/rc.d/BOOTCONFIG
  File: /etc/rc.d/BOOTCONFIG
  Size: 391       	Blocks: 8          IO Block: 4096   regular file
Device: 0,24	Inode: 2305843009213825165  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-09-30 11:49:25.674215180 -0400
Modify: 2018-09-29 01:32:12.168000009 -0400
Change: 2018-09-29 01:32:12.168000009 -0400
 Birth: 2018-09-29 01:32:12.168000009 -0400
  File: /initrd/pup_ro1/etc/rc.d/BOOTCONFIG
  Size: 391       	Blocks: 8          IO Block: 4096   regular file
Device: 8,1	Inode: 131213      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-07-19 11:09:55.000000000 -0400
Modify: 2018-09-29 01:13:40.000000000 -0400
Change: 2024-09-30 10:33:50.622810688 -0400
 Birth: 2024-08-21 14:35:33.051818229 -0400
root@puppypc:~# busybox hwclock -r
Sat Sep 29 09:32:08 2018  0.000000 seconds

@dimkr While setting my hardware clock I used the wrong switch and set my system time to the hardware clock. I know it will reset after some time. Is there a way to reset it with a network time server manually? I can't figure out how it works on dpup 11.

While working on this I tried to open connman-gtk. It failed to open. Here is the message from the command line.

root@puppypc:~# connman-gtk 

(connman-gtk:1961): Gtk-CRITICAL **: 18:13:25.599: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

(connman-gtk:1961): Gtk-CRITICAL **: 18:13:25.599: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

(connman-gtk:1961): Gtk-CRITICAL **: 18:13:25.627: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

d-pupp wrote: Mon Sep 30, 2024 10:26 pm

Is there a way to reset it with a network time server manually? I can't figure out how it works on dpup 11.

The software clock is set using NTP when you go online. Then, you can use busybox hwclock -w to set the hardware clock to match the software clock.

The software clock is set using NTP when you go online. Then, you can use busybox hwclock -w to set the hardware clock to match the software clock.

Ok Thanks. I have reset the hardware clock several times now and it looses it when powered down. I'll have to see if it has a replaceable battery.

@dimkr

Quick question about the spacefm file manager:

Generally, the drag and drop feature works properly in spacefm with one exception. I prefer an open Tree view panel to expedite navigation of the filesystem. However, when I drag and drop a file or folder, spacefm crashes immediately when the mouse pointer passes over a Tree view panel in the active spacefm window or when I drag and drop to a second (separate) window which has an open Tree panel.

I don't know if this is an issue for other users, but for me the repeated crashing is distracting.

Your thoughts are welcome.

Thanks

radky wrote: Thu Oct 03, 2024 3:24 am

Your thoughts are welcome.

If it's a bug, somebody needs to fix it

dimkr wrote: Thu Oct 03, 2024 1:51 pm

radky wrote: Thu Oct 03, 2024 3:24 am

Your thoughts are welcome.

If it's a bug, somebody needs to fix it

@dimkr

Edit: I applied the github commit below to your spacefm petbuild.

The patch of ptk-dir-tree-view.c is adjusted for the spacefm source currently referenced in your petbuild.

For me, it seems this small patch fixes the spacefm crash with drag and drop.

I'm not aware of any negative impact on other spacefm functions.

https://github.com/IgnorantGuru/spacefm ... f54687a95d

@radky This patch should be already applied, spacefm is built from last commit in master (unless alpha branch is ahead of master)

EDIT: indeed, alpha is ahead, I'll cherry-pick this commit

@dimkr What do you know about the firefox zero day vulnerability?
Is fsckp being replaced by fsck?

d-pupp wrote: Sat Oct 12, 2024 3:21 pm

@dimkr What do you know about the firefox zero day vulnerability?

Not much, but I know the fix will appear in a future build if it's not included already.

d-pupp wrote: Sat Oct 12, 2024 3:21 pm

Is fsckp being replaced by fsck?

Yes. The distinction between the two is a source of confusion for users and I don't see a scenario where one would want the latter without the former.

What code can be used to extract and repack it puppy_vanilladpup_11.0.188.sfs?

mksquashfs && unsquashfs

Jasper wrote: Sat Oct 12, 2024 7:19 pm

mksquashfs && unsquashfs

Wrong answer.

You need to use mount to view the contents or copy them aside, and mkfs.erofs to pack.

lol .. my bad

Thank you for the correction

As far as I understand the fix for the recently disclosed Firefox CVE should be present in 11.0.189, and you can apt upgrade if you don't want to update to 11.0.189. (Firefox is bumped to 128.x, so it looks a bit different.)

EDIT: I misread the CVE tracker, this is wrong

I updated to dpup 11.0.189. I checked the Firefox version and it looks to me like we are still a bit short of the patched version
Current 128.3.0esr (64-bit)
Patched

Mozilla Foundation Security Advisory 2024-51
Security Vulnerability fixed in Firefox 131.0.2, Firefox ESR 128.3.1, Firefox ESR 115.16.1

Announced
October 9, 2024
Impact
critical
Products
Firefox, Firefox ESR
Fixed in

Firefox 131.0.2
Firefox ESR 115.16.1
Firefox ESR 128.3.1

I also checked with apt yesterday. All I see is version 128.3.0 so I guess they haven't uploaded it yet