VoidPup32 and VoidPup64 Discussion

[mikeslr]

Thanks for the code, peebee. Nice idea.

Don570 recently posted about a new, 2.8.0, version of avidemux available as an AppImage. Under Fossapup64 it worked OOTB. But trying to run it under Voidpup64 revealed missing dependencies. Rather than hunting for them I checked Void's repo which revealed that version was available. It installed and ran OK, but with a couple of quirks.
[Install command was "vpm i avidemux". A 32-bit version is also available but uses a slightly different name].

The first quirk was this terminal read-out:
"# vpm i avidemux
[vpm] Installing packages: avidemux (xbps-install -S avidemux) ...
[*] Updating repository `https://alpha.de.repo.voidlinux.org/cur ... 4-repodata' ...
ERROR: [reposync] failed to fetch file `https://alpha.de.repo.voidlinux.org/cur ... 4-repodata': Transient resolver failure
17 packages will be downloaded:"

Despite that report, as said, the installation preceded OK. I kind of remembered something about curtailing updating so it's possible that such reports should be expected. But figured it would be best to call it to your attention.

The installation created two /usr/share/applications desktop files and, consequently two menu listings. One menu listing had no icon, but ran; the other showed an icon, but didn't run. The reason it didn't run was that it was for an avidemux-portable which, in fact, had not be installed. The fix was simple: edit the functional avidemux's icon=argument to the icon which existed and delete the desktop listing for avidemux-portable.
[The %f argument in the Exec= line was manually removed]

Avidemux is a useful tool for working with video files when transcoding isn't required. As a result, it is much smaller than 'full-fledged' video editors. Still the new version is built upon Qt5 so I had hoped that it would pull-in sufficient Qt5 libraries to enable some AppImages and portables to function. Testing those with ldd showed fewer missing libs, but still some.

[mikeslr]

Although I had an earlier version of Openshot working, IIRC MIkeWalsh's portable, the latest version, 2.6.1 AppImage, which has an number of improvements from, and spelled out, here, https://www.openshot.org/blog/2021/09/0 ... lease_261/ refused to open. Running it from a terminal revealed that libbsd.so.0 was missing. This turned out to be an easy fix:

entering libbsd in the search box here, https://voidlinux.org/packages/?arch=x86_64&q=libbsd showed versions were in void's repos, and

vpm i libbsd

installed it. A restart-x, then running Openshot-v2.6.1-x86_64.AppImage in a terminal opened it. The terminal output showed that Openshot had been busy resolving some issues. But once opened Openshot was able to import several clips of varying formats including a flv. Not extensively tested; but the terminal output did not show any unresolved problems.

This exploration revealed a couple other matters. Before running it in a terminal I tried to examine it using ldd on the binaries of a decompressed AppImage. That also had revealed libbsd to be absent. I had been able to grab lbbsd from a link provided by pkgs.org.

I would have preferred not to install it via vpm, but rather to strip it, storing only the actual libs so that if I had/chose to rebuilt my vpup64 it would already be available. This exploration revealed (a) there appears to be no way to use vpm to merely download --but not install-- packages; and (b) to install downloaded xbps packages.

I suspect that once installed, files can be grabbed to be used in an SFS or AppImage. But IMHO, such a work-around should not be necessary.

[mikewalsh]

@mikeslr :-

TBH, Mike, although I've tried newer versions of Openshot than the v2.4.3 used in the 'portable', I've found no compelling reasons to actually bother with using them. v2.4.3 does everything I want from a 'full-fledged' video-editor.....and then some.

Johnno Thomas, unfortunately, is in this respect the same as every other developer out there. He adds stuff just for the sake of it. Most of it is pure & simple 'bling', and in no way necessary for actual functionality. Way of the world, I'm afraid. It's exactly the same marketing trick that auto manufacturers use to keep existing model ranges still viable for another few years; they give them a 'facelift', so that prospective purchasers/users think they're getting summat new.....

T'other Mike.

[mikeslr]

Mike,

I really haven’t had to do anything since 666philb perfected Xenialpup64 and IIRC you published a version of Openshot for it. Yesterday was the day I had scheduled to siphon 10 gallons of water from the bottom of one of my three 50 gallon fish tanks* and replace it with fresh tap water. But the sink in the basement was clogged and I had to wait for the plumber to unclog it. So I had some time to fill with some activity.
Openshot 2.6.1 AppImage ran OOTB under Fossapup64, but not Vpup64. As I already had all the parts and the tools, figuring out why it didn’t was likely to take just about the amount of time I would otherwise spend watching TV programs I’ve already seen 3 times.
As there’s no profit propelling the development of open source software, there’s a good chance Johnno Thomas has motivations similar to my own: I’ve got the pieces and the tools; what can I do with them to fill my time?
-=-=-=-=--
* I used to breed tropical fish which I gave away or traded to the owners of local 'pet stores'. But the big chains have driven them into retirement. So, while I still enjoy keeping tropical fish, keeping them is also to some extent a means to fill my time. Necessity isn't the 'Mother of all Inventions'. Boredom plays a significant role: 'Idle hands' and such.

T'other Mike.

[Marv]

VoidPup64 RC +1 running swimmingly as a daily

[Duprate]

Hi! VoidPup64 RC +1 being used regularly, all browsers working 100%. Google Chrome (chrome64_98.0.4758.80_lx_spot.sfs), updated to version 98.0.4758.102, using my personal settings normally. I didn't find any problems with the functioning of other applications. Congratulations Peebee for your work!

[xenial]

Been keping my eye on this thread and my whiskers are twitching.Curiousity will get the better of me and one of my drives has plenty of room for one more to tinker with.

Several pups in my kennel now and loving it.

[Duprate]

Good night! VoidPup64-22.02+0.iso + devx downloaded and installed. It still works perfectly for me. Good job Peebee!

[peebee]

inst-xbps in the 22.02 releases needs "simplification"...... thanks to @OscarTalks for reporting ..........

[Marv]

Basically 22.02+0 up and running well on my i5 based Fujitsu S761. Pristine boot to JWM, boot with ydrv only added, savefile update checked. Dmesg clean, all system tests ok, video FPS and idle resource use good. Run with the stock 5.15.24 kernel, with Ozsouths 5.15.18, and with 5.16.2. No real problems booting etc in any.

One 'odditity' as below. Not present in RC1, nor in any of the other 64b LxPups. Present in all flavors of 22.0+0 outlined above. Kernel independent, shows up in both Slimjet64 32.0.4.0 and 33.0.0.0 both with my profile and when deleting all caches and starting fresh profiles. Sylpheed also 'redraws' the directory names oddly when it connects. Again, in 22.0+0 only. I have RC1 and 22.0+0 running side by side on identical machines right now so I can bounce from one to the other. Any known change in rendering between the two? Both show as using the Intel graphics driver etc. Identical dmesg entries.

A GIF image, part of the searchbar box in the newtab screen is just plain misplaced, hanging below the middle, it belongs at the right end of the search box:

Screenshot.png (5.25 KiB) Viewed 3047 times

It is a gif, and inspecting the element in Slimjet shows identical code in RC1, 22.0+1, and LxPupSc64. The little gif source shows as: chrome://newtab/images/searchbox_right.gif. All on-line gif tests display perfectly to further my headscratching.

Chalk it up to a Marv quirk, but I'll rest at RC1 for now. RC1 did a yeoman job on my taxes just now so it has its' halo on
Cheers,

[one]

Hi @peebee,

I tried your voidpup32 22.02 +0 with kernel 5.10.101 in my usual way (frugal install on ext. SSD, attached with SATA-to-USB adapter, booted via grub4dos).

Does not boot, same story as with RC0 and kernel 5.15.0:

viewtopic.php?p=48801#p48801

As you can see in the logs the SSD (ASMT) is not recognized, so no boot possible

peace

[Feek]

I explore Voidpup64-22.02. It's great, congratulations .

I have one question that relates to swap in Zram.

Htop indicates: Swp [0K / 7.19G], similarly "free" command.
Does it mean that in the extreme case it will compress/decompress almost the entire RAM (8GB)?

How much RAM must be occupied to activate swap? Should I let the setting without change?
(I don't use another swap)

Thanks

[recobayu]

Thank you, @peebee, Now I try this voidpup64. It is good. I hope the vpm can use tab for autocompletion.. I use `vpm s' first before install `vpm i'.

[Marv]

@peebee I've been chasing my 'odd rendering' in 22.02.0 but not in RC1, both 64b on bog standard i5 based hardware. I've done a diff between the two main SFS and updated/reverted changes there insofar as I could with no change in behavior. Ditto for kernel swapping.

A question: In the woof build configuration, RC1 has:

## GTK+ version to use when building packages that support GTK+ 2
PETBUILD_GTK=2

Whereas the 22.02.0 release has:

## GTK+ version to use when building packages that support GTK+ 2
PETBUILD_GTK=3

Intentional change? Just a dinosaur rooting about.

Thanks,

[Phoenix]

I explore Voidpup64-22.02. It's great, congratulations .

I have one question that relates to swap in Zram.

Htop indicates: Swp [0K / 7.19G], similarly "free" command.
Does it mean that in the extreme case it will compress/decompress almost the entire RAM (8GB)?

How much RAM must be occupied to activate swap? Should I let the setting without change?
(I don't use another swap)

Thanks

Zram is dynamic, it will only use as much as it takes up. The only time where its not dynamic is once you 'dirty' it (mkswap) you can't change the size again, it must be destroyed then recreated. It relies on 'vm.swappiness' since it is swap which dictates what percentage of free RAM before swapping out. 0 is not recommended because then it will forcibly keep everything it can (I should also add that defeats the point of Zram), therefore leading to issues if memory leaks spring up. 1 basically means it will grudgingly swap when its full. The default is good enough though. (And probably what you want instead of having your computer seize up at 1% remaining RAM trying to do its work to fit stuff into Zram)

EDIT: As well, in the maximal worst case it will pointlessly move 'pages' that cannot be compressed. So it would be preferable instead that you hit OOM-killer instead then. Also I don't know your specifications, but don't set Zram to the full size of memory. There is also Zswap which acts like Zram, except when its full it decompressed the least recently used page and sends it to the typical swap. (Disk)

[dimkr]

The default is good enough though

Puppy doesn't use the defaults - see /etc/rc.d/rc.sysinit (https://github.com/puppylinux-woof-CE/w ... ysinit#L63, https://github.com/puppylinux-woof-CE/w ... sinit#L254).

If no swap is available, the init script sets up swap on zram, but lowers swappiness from the default of 60 to 5. This means the kernel is less willing to compress pages to prepare for future shortage of memory. When you run out of memory and the kernel starts moving pages in and out of zram, the compression and decompression are pretty fast, and you probably won't feel it.

(The alternative to having no zram-backed swap, when you don't have a swap partition, is having no swap at all. But zram is a "pay as you go" solution, so it can't hurt on systems with lots of memory, but it can make systems with 1-2 GB of RAM that struggle with today's browsers pretty usable)

[peebee]

Whereas the 22.02.0 release has:
## GTK+ version to use when building packages that support GTK+ 2
PETBUILD_GTK=3

Hi @Marv

Longish story - the RC used the Void build of JWM however Void has moved to jwm-2.4.1 and puppy themes only work with jwm-2.3.7....

So, jwm has become a "petbuild" in the release - i.e. woof-ce builds it from source rather than using a pre-built package. This was not easy to achieve as the devx has to work in a complicated chroot environment in Woof-CE.

Having said that - as far as I can tell none of the config files (/var/packages/woof-build.conf) have GTK=3 - they all have GTK=2 here...

But that config should only affect the woof-ce petbuild - not the running system - and as far as I know jwm is a GTK=2 petbuild.

BUT the Void jwm package in RC may have been built with different configs.........

Maybe doing an ldd on the 2 jwm binaries may show which gtk is being used.....

Hope helps
peebee

[dimkr]

JWM doesn't use GTK+.

PETBUILD_GTK=2/3 affects only petbuilds that support both GTK+ 2 and 3:

aaa_pup_c firewallstatus freememapplet gexec gpicview gtkdialog lxtask lxterminal mtpaint netmon_wce pa-applet pcmanfm powerapplet_tray xarchiver Xdialog yad

There are some special cases, though: the latest Geany supports only GTK+ 3, and the special geany-gtk2 petbuild is an older version that still supports GTK+ 2.

Using PETBUILD_GTK, you can achieve a 100% GTK+ 2 system (by avoiding GTK+ 3 completely, but that means you'll need to use an old browser and drop Transmission), a 100% GTK+ 3 system (you'll need to drop Sylpheed and ROX-Filer), or a combination (GTK+ 2 wherever possible, otherwise GTK+ 3).

[peebee]

JWM doesn't use GTK+.

Ok - thanks - but I guess it is still possible that the differences @Marv is seeing may be a result of the change from Void's jwm to the petbuild jwm ??

[dimkr]

Ok - thanks - but I guess it is still possible that the differences @Marv is seeing may be a result of the change from Void's jwm to the petbuild jwm ??

That depends on what these differences are. If the differences are in font rendering of window titles or menus and you downgraded from JWM 2.4.x to 2.3.7, this could be it.

[Marv]

JWM doesn't use GTK+.

PETBUILD_GTK=2/3 affects only petbuilds that support both GTK+ 2 and 3:

aaa_pup_c firewallstatus freememapplet gexec gpicview gtkdialog lxtask lxterminal mtpaint netmon_wce pa-applet pcmanfm powerapplet_tray xarchiver Xdialog yad

There are some special cases, though: the latest Geany supports only GTK+ 3, and the special geany-gtk2 petbuild is an older version that still supports GTK+ 2.

Using PETBUILD_GTK, you can achieve a 100% GTK+ 2 system (by avoiding GTK+ 3 completely, but that means you'll need to use an old browser and drop Transmission), a 100% GTK+ 3 system (you'll need to drop Sylpheed and ROX-Filer), or a combination (GTK+ 2 wherever possible, otherwise GTK+ 3).

OK, I think this starts to explain some of what I'm seeing. At least it gives me a starting point. I'll work on Sylpheed first assuming the build installed from the Void repo supports GTK+ 2 and GTK+ 3 but the GTK +3 support is 'flawed'. Slimjet may be the same. I see the oddities both running JWM and LXDE so I don't think it is a JWM reversion issue.

Thanks for the detailed explanation,

[dimkr]

AFAIK, VoidPup doesn't have GTK+ 3 themes. This is why applications that use GTK+ 3 look different.

(Sylpheed is a bad example, it's GTK+ 2 only, and wasn't ported to GTK+ 3)

(woof-CE has petbuilds for themes that support both GTK+ 2 and GTK+ 3, https://github.com/puppylinux-woof-CE/g ... ished_blue is one of them, and the default GTK+ 3 behavior is to fall back to Adwaita when the chosen theme is missing)

[Marv]

@dimkr I've added your GTK+2 / GTK+ 3 themes to VoidPup64 and a little themechanger script for the GTK+ 3 themes. I am using polished-blue at the moment though all 3 are quite nice. I really don't want to give Sylpheed up quite yet so I'll chase the rendering a bit more on it.

Thanks,

[peebee]

a732ce76a0d103e5f2425d51f3eb7509 VoidPup32-22.02+1.iso
96d80d76edfe608b87bf31e3bcca12b9 VoidPup64-22.02+1.iso

see viewtopic.php?t=5270

[Duprate]

Good Morning! Latest version installed. Working optimally! Congratulations, Peebee!

[Marv]

The 64b 22.02 +1 downloaded, md5sum checked, and Installed to the usual Fujitsu S761, both as a pristine and as an update to my 22.02 LXDE LXDE'd install using @peebee ydrv. Both boot cleanly with good system checks. Both the stock 5.15.24 kernel and @ozsouth 5.15.27 kernel tested. Posting from that install now in Slimjet64 33.0.0.0, still their most recent. Thanks for adding the three @dimkr Gtk2/Gtk3 themes and for reverting the Xft.dpi to fix my rendering issue.

Cheers,

[dimkr]

Thanks for adding the three @dimkr Gtk2/Gtk3 themes

There's 5 of them by now:

https://github.com/puppylinux-woof-CE/g ... ey_rounded
https://github.com/puppylinux-woof-CE/g ... ished_blue
https://github.com/puppylinux-woof-CE/g ... dient_grey
https://github.com/puppylinux-woof-CE/g ... o_ambience (new gtk_theme_buntoo_ambience petbuild)
https://github.com/puppylinux-woof-CE/g ... rk_blueish (new gtk_theme_stark_blueish petbuild)

EDIT: VoidPup is based on an older woof-CE that doesn't have the two extra global themes

[Clarity]

@peebee this distro is a 'treat'! THANKS for your efforts for this community.

This report is a status
I am booting via an old 64bit PC circa 2015 PC. At PC start, it is launching the USB in UEFI mode vs non-UEFI firmware selection). The USB is setup as pure SG2D with all of the PUPs I test in its /BOOTISOS folder.

I selected the latest VoidPUP64 ISO file and it boots to desktop. The VoidPUP64 Menu's 1st stanza was selected for boot. Along the way, INIT seems to have discovered the SAVESPEC file in the /BOOTISOS folder and has 'captured/acknowledged it' during the boot progress to desktop. (I think some or part of this is due to the INIT efforts of @gyrog)

All of my preliminary test runs without ANY issues, after FirstRUN.

After prelim testing, I proceed to shutdown indicating I want to save the session. The wizardry of PUP's shutdown allows selection of the contents of what is contained in the SAVESPEC as it identifies the "proper" folder location for the Session to be save; namely it is a folder on the system drive in a EXT4 partition. GREAT!

Conclusion: NO ISSUES to report from start to finish on this distro's boot using its ISO file!

P.S. The session is found on a reboot of the ISO file without issues using the same 1st stanza from the PUP's boot Menu.

Everything is all too easy from ISO file download to save-session management with NO user effort or thought to achieve a running VoidPUP64 system. This make stepping into this PUP a breeze for any user new to Puppy Linux. And, I think, this is what we want to attract as many users as possible to contribute to the success of this forum.

[Clarity]

Finding the SAMBA services missing with some confusing elements; as I think of this from a new user perspective or an old users accustomed to past PUPs with SAMBA.

Attempting to setup SAMBA via Menu>Network>SAMBA Simple ... yields:

Get-SAMBA.jpg (9.87 KiB) Viewed 3289 times

If SAMBA is not going to be included in the PUP, could this entry become a "launch to install SAMBA" versus a picture?

I am sure that this following finding will not be needed as VOID64 progresses; namely that after installing SAMBA via the recommendation, the SAMBA utilities are still missing; namely smbclient, findsmb, etc. The 'finding':

Code: Select all

# vpm i samba
[vpm]  Installing packages: samba (xbps-install -S samba) ... 
[*] Updating repository `https://alpha.de.repo.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: 1730KB [avg rate: 2886KB/s]

Name             Action    Version           New version            Download size
libtdb           install   -                 1.4.5_1                44KB 
lmdb             install   -                 0.9.29_1               81KB 
ldb              install   -                 2.3.2_1                173KB 
samba-libs       install   -                 4.14.12_1              5511KB 
python3          install   -                 3.10.2_1               7361KB 
libpytalloc-util install   -                 2.3.3_1                5477B 
libpyldb-util    install   -                 2.3.2_1                6824B 
samba            install   -                 4.14.12_1              10MB 

Size to download:               23MB

Probably 23MB not an issue in the next WoofCE build.

[peebee]

5fcb45e6f44fb0fda99717369c1fb658 VoidPup32-22.02+2.iso
9db302b9dd8bcefdab0b24d5472b7bec VoidPup64-22.02+2.iso

see viewtopic.php?t=5270