Puppy Linux Discussion Forum

Clarity wrote: ↑Fri Jul 29, 2022 5:33 pm

How much RAM does your PC have for the multiple OSes you run?

What I mean is that more than one pup is installed in the windows partition, and one of them is running at a time.
My PC has 4GB RAM, and the preinstalled OS is Windows 10.

Thx. You should be able to run all PUPs without a RAM concern. Watching it does not mean much but, performance of the PUP apps you use should be the items to pay most attention to on your PC.

Wtih that RAM, you might get some distance with a SWAP partition which all PUPs will find upon boot and use. It will provide insurance that you system will never lock.

Someone, earlier did mention to consider creating a Linux partition and placing your persistence there in the form of a folder. Saving as Folders, as mentioned, intends to be much-much less troublesome than savefile maintenance when used on modern systems.

If you have space on your system drive, I would create the following 2 partitions:

1. a SWAP partition of 4GB

2. a partition that is used for your persistence

You will find many/most membership on the forum to be helpful for either or both should you need. And with those 2, most everything you do with PUP distros will provide a trouble-free experience.

You may already be aware of this. Hope this is helpful.

Clarity wrote: ↑Sat Jul 30, 2022 5:48 am

1. a SWAP partition

My recommendation is not to create a swap partition. Vanilla Upup (and any other recent Puppy) uses zram swap (compressed RAM) if there's no swap partition on disk. It's much faster than swap on disk and doesn't shorten the lifespan of flash memory.

Good idea, too.

I tested Vanilla Upup 22.04.39 a while ago, but I couldn't get very far because the display kept freezing.
I have just tried the Woof-CE Jammy64 210 build and that is the same, but I have found out how to avoid the freezes, so I got a bit further...

It always freezes if the mouse pointer goes anywhere near to the left hand edge of the screen, typically when clicking on the left button on the task bar. I have enabled the applications in the desktop context menu so I don't need to go near the left hand edge.

My test system is an intel Braswell N3150.

This will have changed from i915_dri.so previously, to crocus_dri.so in jammy64. i915_dri.so is now relegated to mesa-amber, so it would be quite tricky to get back to that.

Another thing I could try would be to boot with Xorg server, but there doesn't seem to be a boot parameter to set the display server.

Any suggestions how to debug this? I can use Vanilla Upup 22.04.61 if that is likely to make any difference.

LateAdopter wrote: ↑Sat Jul 30, 2022 2:27 pm

Any suggestions how to debug this? I can use Vanilla Upup 22.04.61 if that is likely to make any difference.

First of all, you should check if that happens with Ubuntu 22.04, with Ubuntu's Sway. If it does, it's a bug in wlroots, Mesa, Xwayland, etc', and not something that can be fixed specifically for Puppy.

Ha! Ha! I installed a proper Unix once before and I decided never to do it again. That's why I use Puppylinux.

I have noticed that with Bionicpup64, when I move the mouse pointer near the left edge of the screen the desktop blinks. It only does it once per session. Fossapup64 doesn't do it.

It may be a long standing quirk of Intel cherryview graphics that is fatal with Wayland.

Booted on my AMD Athlon 3000G it doesn't freeze.

Clarity wrote: ↑Sat Jul 30, 2022 5:48 am

If you have space on your system drive, I would create the following 2 partitions:

a SWAP partition of 4GB

a partition that is used for your persistence

Thanks for your advice.

People may think I am stubborn, but I continue to use the save file method. You need not create a new partition and format it in a Linux file system. You can install Puppy Linux in the windows partition.
That is a feature which distinguish Puppy from other distributions. I am interested in promoting Puppy Linux in Japan.
As a matter of fact, I have an ext2 partition for a working space, because I create ISO, pet packages and SFS packages.

As for a swap partition, I do not need it for now, because applications I usually use are a browser, a word processor and a spread sheet.
Indeed, the zram swap is a good idea. You can use swap even when you start Puppy from a usb stick. But I haven't seen it used on my machine.

I have an ext2 partition for a working space, because I create ISO, pet packages and SFS packages.

I used to use a fake savefile, would just load it and then use it as a working space.

I went back to 22.04.39 so that I could test with Xorg instead of Wayland.

The good news is that the behaviour is exactly the same, but I can look in Xorg.0.log to see what the error was.

[   334.852] (EE) event3  - Logitech K400 Plus: client bug: event processing lagging behind by 31ms, your system is too slow

I also tested with a generic USB PS/2 mouse. In that case the pointer would often stick at the same point and refuse to go any further, but it didn't freeze the display and would go back to the right.

My primary candidate for blame is JWM. The point where the problem occurs is where a vertical tray would be if it had one. Also the clock in the tray stops updating, but pressing the power button does a proper shutdown.

I can try a known working JWM binary from Fossapup64 and see what happens.

The second candidate for blame is the kernel. The K400 uses the I2C_HID kernel module(s). Recent kernels have split this into several pieces.

I can try a known working 5.4 series kernel.
The easiest way should be to force AUFS with the boot parameter. Then I only need to move /lib under /user in the zdrv SFS.

I did not have this problem with Cagepup or Imppup

I use the same Keyboard (k400) on two of my PCs.

UPup has all the same boot 'files' of the usual PUPs from WoofCE developers, but has been broken or crippled such that SG2D cannot see it to present the ISO file for user booting.

Would or could the developer consider enabling it to allow testing the Upup distro?

I copied over the jwm binary from fossapup64. With that the K400 behaved the same as the generic usb ps/2 mouse. i.e. It would stick when approaching the left edge of the screen, it did not freeze when using Xorg but it gave too slow errors in Xorg.0.log.

I commented out the zram swap stuff in rc.sysinit. That eliminated to too slow errors in Xorg.0.log.

I changed from modesetting_drv,so Xorg driver to intel_drv.so. With that the sticking stopped and the pointer would go right to the left edge of the screen properly.

There seems to be some display coordinate error with Wayland and with the modesetting driver. The pointer will not go right to the left edge. With Wayland, if you take the pointer as far as it will go the display freezes.

With Xorg and the intel driver it works properly now.

EDIT I have changed back to the original jwm and it's still OK with Xorg and it still freezes with Wayland. I'll have a look for Ubuntu bug reports on this.

LateAdopter wrote: ↑Sun Jul 31, 2022 12:33 pm

I can try a known working 5.4 series kernel.
The easiest way should be to force AUFS with the boot parameter. Then I only need to move /lib under /user in the zdrv SFS.

I did that with an existing AUFS 5.4.89 kernel. In the zdrv I moved /lib and /sbin under /usr. I booted with punionfs=aufs and it worked at the first attempt. The only peculiarity was that it displayed the quicksetup panel at the first boot with the new kernel.

Sadly the freeze with Wayland is still the same. It all works normally except, if I move the pointer to the left edge of the screen, it freezes immediately.

In the askubuntu forum the answer for Wayland freezes on 22.04 was:

Depending on your graphics card, Wayland my not yet fully cut it for you. Just stay a little longer on Xorg then: it is still available.

It seems that I'm stuck with Xorg.

dimkr wrote: ↑Tue Jul 19, 2022 1:49 pm

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.

I borrowed libxcvt 0.1.2 from an Italian distribution called openmamba, and created a pet package.

libxcvt012.pet

md5sum d7c085885baa634671b995189f1ea991

libxcvt - openmamba
https://openmamba.org/it/pacchetti/?tag ... cvt.x86_64

After the installation of the pet package, restart the graphical server to take effect.
Unistalling the package through PPM will restore the original status of the system.
Tested on my machine. Use it at your own risk.

libxcvt 0.1.2 is out for ubuntu kinetic, so I hope the one for jammy will be released soon.

Hello dimkr
I see you have been busy... It's easier to do it than argue about it! Amazing.

I was happy with Vanilla Upup 22.04.39 where I could switch between Wayland and Xorg depending on whether the hardware worked or not.
The other stuff is unimportant unionfs/AUFS/overlayfs - I don't care. ROX/pcmanfm - I don't care. etc.

The mesa-amber mess needs sorting for Xorg.
My gpu is supported by crocus_dri.so and Wayland uses it but Xorg looks for i965_dri.so which is not present. I tried symlinking i965 to crocus but Xorg said it doesn't export the required dri extension. To get it to work properly it's necessary to install libgl1-amber-dri_21.3.7-0ubuntu1_amd64.deb. This contains a huge lib and symlinks for lots of old driver names. Although its an older version of mesa, the dependency is >= so it works with the current version (for my gpu anyway). If it's not installed it's not fatal, AIGLX loads swrast. So you could just warn about it rather than include it.

The init doesn't like the -213 extension on the Woof-CE github builds and always asks to update the savefile because the extension gets cut off in some places and not others.

Thanks for your efforts. Your ROX version seems to be working well.

LateAdopter wrote: ↑Tue Aug 02, 2022 11:45 am

The init doesn't like the -213 extension on the Woof-CE github builds and always asks to update the savefile because the extension gets cut off in some places and not others.

These are development builds: they protect woof-CE against breakage and allow easy testing of new changes. I wouldn't recommend you to use them daily drivers, and that annoying extension is one way to protect users from this potential danger.

I'd really like to see somebody else picking up jammy64, it's too much work for me to maintain two Puppy releases, especially I need to reproduce issues, fix them in woof-CE, cherry-pick the individual fix and test it in isolation. I have zero help.

Regarding your issue with Mesa - sadly, there's not much I can do. Once you start replacing Ubuntu packages with "foreign" packages from other distros or other Ubuntu versions, your Puppy becomes less and less compatible with Ubuntu. apt works so well because of the uncompromising design decision of staying close to Ubuntu (for example, the /usr symlinks) and using zero unreproducible and potentially incompatible .pet packages in the build. The price we have to pay for this is incompatibility with old hardware that has issues under Ubuntu as well.

@dimkr I could help with testing out changes and do woof-CE runs with different combinations and document results if that will be of any assistance.

I do not have very new machines at this moment but that will change soon as my brother's business swaps out systems and I'll be gifted one or two. I have some solid Optiplex 990 and 980 machines and two different PowerEdge servers. Just a little thin at the moment with laptops that are newer than 2012

dimkr wrote: ↑Tue Aug 02, 2022 2:40 pm

Regarding your issue with Mesa - sadly, there's not much I can do. Once you start replacing Ubuntu packages with "foreign" packages from other distros or other Ubuntu versions, your Puppy becomes less and less compatible with Ubuntu. apt works so well because of the uncompromising design decision of staying close to Ubuntu (for example, the /usr symlinks) and using zero unreproducible and potentially incompatible .pet packages in the build. The price we have to pay for this is incompatibility with old hardware that has issues under Ubuntu as well.

The mesa-amber package, that I quoted, is a standard Ubuntu Jammy package. It's just an optional package that gives support for Intel gpus before gen 8 and other non-intel processors. It's not foreign, so apt would install it for you.

I understand that the woof-CE CI builds are not for general use. Since you said you were going to stop work on Jammy I thought I would check it as soon as possible.

dimkr wrote: ↑Tue Aug 02, 2022 2:40 pm

Once you start replacing Ubuntu packages with "foreign" packages from other distros or other Ubuntu versions, your Puppy becomes less and less compatible with Ubuntu. apt works so well because of the uncompromising design decision of staying close to Ubuntu (for example, the /usr symlinks) and using zero unreproducible and potentially incompatible .pet packages in the build.

It seems that the above statement is referring to the pet package I made.
I notice the incompatibility between the PPM and ubuntu tools such as apt-get. So, after installing CUPS by way of apt-get, I installed a language pack (pet) that includes fcitx. After that, I stopped using apt-get. I removed the package data base (surprisingly big in size) downloaded by apt-get.
Somehow CUPS would not be installed through the PPM.

So far Vanilla Upup is working fine on my PC, except that the input method does not work with Chrome 102 or later. If Vanilla Upup should be as compatible as possible with ubuntu, I don't see the reason why the incompatibility with Chrome happens.

If installing pet packages is not recommended, the PPM itself should be removed. But the OS will eventually lose one of the features of Puppy Linux.

NO! and NO!

1 The idea with Puppy is that you make a copy of the savefile and try whatever you like. It doesn't matter if Puppy breaks. That's how you learn what works and what doesn't.

2 dimkr was talking about this package https://packages.ubuntu.com/jammy/libgl1-amber-dri because he thought it was a third party hack.
Actually it was developed by Jason Ekstrand and brought into Ubuntu by the debian/ubuntu developer/packager Timo Aaltonen. It's currently in Jammy and Kinetic. It hasn't appeared in debian bookworm yet.
It should really be called "extras" because it doesn't have any dependency on amber. It's needed for a lot of Intel HD graphics and AMD Radeon graphics if you use Xorg and maybe Wayland in some cases.

thinkpadfreak wrote: ↑Wed Aug 03, 2022 2:14 am

If installing pet packages is not recommended, the PPM itself should be removed. But the OS will eventually lose one of the features of Puppy Linux.

Feel free to participate in the discussion in https://github.com/puppylinux-woof-CE/w ... ssues/3076.

I'm probably the strongest supporter of the idea of removing PPM, or at least, making it optional. It's full of issues, nobody is fixing them, but some Puppy developers strongly oppose the idea of a Puppy without PPM. I don't care if PPM is "unique" or a "tradition", I think it's objectively an awful package manager: it's extremely slow, it doesn't resolve dependencies correctly and it lacks support for many apt concepts (like 32 bit packages alongside 64 bit ones, or dependency on package a or package b). I believe every package manager that tries to emulate apt (the way it extracts packages, its dependency handling, handling of conflicts or alternatives, support for multiple architecture and so on) will fall short of the user's expectations, and I always prefer 1) a fast and reliable solution and 2) one application per task, especially if the alternatives are broken by design.

dimkr wrote: ↑Wed Aug 03, 2022 11:50 am

thinkpadfreak wrote: ↑Wed Aug 03, 2022 2:14 am

If installing pet packages is not recommended, the PPM itself should be removed. But the OS will eventually lose one of the features of Puppy Linux.

Feel free to participate in the discussion in https://github.com/puppylinux-woof-CE/w ... ssues/3076.

I'm probably the strongest supporter of the idea of removing PPM, or at least, making it optional. It's full of issues, nobody is fixing them, but some Puppy developers strongly oppose the idea of a Puppy without PPM. I don't care if PPM is "unique" or a "tradition", I think it's objectively an awful package manager: it's extremely slow, it doesn't resolve dependencies correctly and it lacks support for many apt concepts (like 32 bit packages alongside 64 bit ones, or dependency on package a or package b). I believe every package manager that tries to emulate apt (the way it extracts packages, its dependency handling, handling of conflicts or alternatives, support for multiple architecture and so on) will fall short of the user's expectations, and I always prefer 1) a fast and reliable solution and 2) one application per task, especially if the alternatives are broken by design.

I'm with you. ppm is bad as a package manager. but always the developers clung to the past.
The same thing happened with pulseaudio, after a long time, we have it in woof-ce, and all thanks to you.

Many language packs (including mine) are in the form of pet packages.
If Puppy doesn't have a means to handle pet packages, users will have to localize Puppy for themselves.
Language packs do not only consist of fonts and translations, but also an input method, especially in the case of Asian languages. Setting environment variables for the input method is also necessary.

OSes should have backward compatibility. I would like developers to equip Puppy with some means to handle pet packages even if PPM should be removed in the future.

@thinkpadfreak Why build .pet and not SFS language packs?

dimkr wrote: ↑Thu Aug 04, 2022 5:04 am

Why build .pet and not SFS language packs?

Well, it is not impossible to provide a language pack in the form of sfs packages such as adrv sfs. In fact, I used the method to create a Japanized version of Fossapup64. I am not sure whether it is appropriate to call it a language pack. It is part of an iso file.

A pet package can include pinstall.sh and puninstall.sh, so that it is possible to modify system files or restore them. On the other hand, an adrv sfs simply overwrites them.

Anyway, apt-get will complain about any other file than those installed by way of apt-get itself. That is why I installed CUPS by way of apt-get and then installed a language pack (pet).
By the way, I think CUPS should be included in the main sfs, because people will want to use a printer, whether it is home use or office use.

Like someone else, I would rather use ubuntu itself or some other ubuntu flavor than use "apt only" puppy.

At the moment --before breakfast and a 2nd cup of coffee-- I don't recall which Puppy had it. But both PPM and radky's Pup-Control were included: just not on the Menu. [...desktop's NoDisplay=true]. Pup-Control provided a GUI to PPM. Both available, but not likely to get newbies into trouble.
Pup-Control might not have been needed if PPM could, itself, be started via command line or file-browsing to /usr/share/applications. Certainly, all Pup-Control's modules weren't needed.

Why build .pet and not SFS language packs?

While creating ZoneMinder installs for Puppy Linux I found out the lack of post install scripts in SFS packages severely hindered the install process for a complete ZoneMinder auto-install.

A pet package can include pinstall.sh and puninstall.sh, so that it is possible to modify system files or restore them

exactly what I am talking about. SFS is really good BUT not the solution for everything. Complex packages like ZoneMinder as an SFS which I have tested intensely, would involve manual install steps not covered by most user's pay grade. As a PET the post install script is complex and does the rest with no manual intervention required.

Banking on SFS only is a mistake

one big reason i like ppm is its so much easier to make pet files than deb files or whatever other files. maybe pet files are not needed and we can just use targz files that extract over /. since that is mainly what pet files are anyway. but i like that it is very easy to one-click a pet file and install it, and just as easy to dir2pet a directory to make it a package. i also like that it is universal across puppies whether they are apt-get, slack, void, or any other base.

i also like that with ppm you cannot get into "dpkg hell" where you simply cannot do any more packages because a dependency cycle broke something terribly wrong. I like that ppm lets me just install packages even if i dont have all the dependencies and lets me deal with the consequences however i need to to make things happen. The "dumber" dependency resolution is in that way a feature!

but i also do have problems with it, especially with "meta packages". it doesnt understand a lot of modern apt-isms. still. i would hate to use a puppy with just apt-get and nothing else.

I think I would be ok in a world where we keep ppm but don't tell it about the debian repos. so it would be for pet files and nothing else. If that is a compromise we would have to make to keep going forward i would live with it. and much prefer it to abandoning all pet files on the wayside

It is an advantage to have one package manager that works on any Pup (be they using upstream Debian, Ubuntu, Void, Slackware repos or whatever).

On the other hand, Debian and Ubuntu already have an almost perfectly reliable package manager that properly manages installation from their official repos.

PPM, and specially with pkg, tries very hard, but it is a re-invented wheel that is never going to be perfectly round...

Mixing package managers allows a kind of anarchy, and the freedom, like a breath of fresh air, is undoubtedly pleasant, and it is certainly true that the format of dotpets is very simple so they are both easy to understand and create and use. However, it is fair to say that the DebianDogs, for example, provide a simple-to-use GUI make deb utility (original version, somewhat modified, came from Puppy community I think?). Nevertheless, the internals of deb packages remains complicated, unlike the attractively simple tar.gz approach of dotpets. And official dpkg/apt does not work with Void Pups or Slackware Pups of course any way.

For my own main distro desktop I personally prefer to use reliable upstream distro package management (though it is painful to learn more than one), though I do occasionally supplement that with portable apps/sfs packages, and sometimes self-compiled, but stored in /usr/local/bin or /opt or ~/wherever, and in such a way that they don't mess with apt/dpkg installed files....

It is certainly difficult to avoid breaking a system when an anarchy of package managers is allowed - the mix is a nightmare, though fun and flexible, but the chance of breaking system can be high, though not if just using PPM/pkg for simple bash/gtkdialog type dotpets that don't mess with apt/dpkg installed files - so it depends - and obviously if installing libs then nightmare is inevitable and especially when /lib maybe now more likely to be /usr/lib... a problem for sfs addons too...

I think it is great that the Pup alternative, VoidPup, can use official xbps void package management or PPM/pkg instead if you so choose. The risk is left to yourself, but so is the resulting familiarity and fun, and disasters .

Trouble with Puppy just moving to using dpkg/apt for its Ubuntu/Debian variants is that it becomes difficult to justify using such Pups when DebianDogs exist, and especially when DDs by design also provide most Puppy utilities and more besides... and when installing debs, DD distros by default strip out lots of docs and so on to keep the resulting installation similarly small too (though on the whole disk storage size is irrelevant, but small root filesystems do remain useful for running whole distro from RAM or in small virtual machines).

My own feeling is that Puppy is best to remain a system that encourages anarchy (and accept that 'can' also mean 'breakage' at times); that's what Puppy is. Yes, it is a great development that new Puppy can use official package managers (and a sensible development, I'd say, ever since Puppy moved to relying on upstream repos) for those who rely on Puppy as their main Linux system. However PPM is a bit rusty and I thought pkg (using PPM partly?) is the future of Puppy anarchy in terms of universal Puppy Package management(?) So official upstream repo package managers should be an addition and not a replacement for PPM/pkg, or why bother using Puppy? I can understand a developer not wanting such a 'mess' though - but there are advantages to that crazy 'anything-goes' approach - especially on this wild forum, and especially if you enjoy the fun of that crazy lack of conservative management.

I agree with the posts from @rockedge @artemis @wiak