Confusing or seemingly broken apps

[wdlkmpx]

I was testing pprocess and at first i thought it was broken, it took me a while to figure out how it works, i saw errors in the console,

https://github.com/puppylinux-woof-CE/woof-CE/tree/testing/woof-code/rootfs-packages/pprocess/usr/local/pprocess

As i use the keyboard + xorg mouse keys, i triggered unwanted stuff. And it was worse in slacko 14.0.

Here is a simplified and probably slightly improved version pprocess.gz

But is it really less confusing and better?, anybody can confirm?

It can't compare to lxtask (the leafpad of the gtk process viewers/managers), but i figured out it really is handy when you want to quickly kill processes indiscriminately. e.g: kill all the tray apps. Or when you want to apply an action to many processes, it's the right tool.

But it's not obvious at first sight. Somehow i end up heavily editing or rewriting all the apps i test, it's like a curse.

More confusing or seemingly broken apps con be reported here. An app should properly work in all woof-distro versions, otherwise it should be sent to the darkness..

[mavrothal]

But is it really less confusing and better?, anybody can confirm?

It is working better though I find these apps a recipe for disaster. Click and kill? Even by mistake? without further confirmation? Anyway appears more robust than the original in a brief test on bionic64, though having a gui to fetch the logs was handy. Specially if you suspect a hung process and want to check.

[wdlkmpx]

I'm certainly not adding a confirmation dialog.

Look at the latest lxtask version, it's a tiny pure GTK2 app, no extra dependencies. And yet it's so advanced with a detailed view and various options, you right click on an item and a dropdown menu displays all the options that you can see in pprocess.

Replacing means using the same category and probably this title "Process Manager".

I guess it's ok to replace some puppy apps with pure GTK2 generic apps, i know a few cool apps. I can fork lxrandr to make it the new xrandrshell.

[wdlkmpx]

It's easy to improve pprocess, a few more lines to include confirmation dialog, a proper size depending on the screen size, etc.

To keep a clean menu, the default apps should be the best lightweight tiny apps, there would be no need to install apps to replace them.

I guess it's just better to use some apps developed by some known people and already translated: https://packages.debian.org/sid/i386/lxtask/filelist

In this case: lxtask.gz 17kb lxtast.xz 15kb

There are two choices, a pet package, with _doc.pet and _nls.pet (excluded from the build). Or the compat distro pkg, doc and nls are excluded from the build.

But it's possible to create NLS and DOC sfs's that can be "released" (requires changes in the build system) that way a build is complete, and threre's no need to ask people to translate stuff, no one should complain that documentation for some apps (mtpaint) is missing.

Simplifying the build to create main, dev, doc, and nls SFS's (and ignoring the PKGS_SPECS redirections) would be a good idea. It's doable

[mavrothal]

Simplifying the build to create main, dev, doc, and nls SFS's (and ignoring the PKGS_SPECS redirections) would be a good idea. It's doable

I believe that is what the fatdog built system is doing. May want to take a look. The problem with language support is mostly the pet packages that have no language support and some times not even doc files.

[jamesbond3142]

On Fri, 03 May 2019 20:00:02 +0000 (UTC) mavrothal notifications@github.com wrote:

Simplifying the build to create main, dev, doc, and nls SFS's (and ignoring the PKGS_SPECS redirections) would be a good idea. It's doable

I believe that is what the fatdog built system is doing. May want to take a look. The problem with language support is mostly the pet packages that have no language support and some times not even doc files.

Yes, that's what woof-next does too. Install everything, split into devx/nls later when creating the SFS. I don't have "docs", "docs" is usually merged together in devx; although I make certain exceptions (some critical docs stays on base SFS).

-- James B

[wdlkmpx]

I had that idea for a while. And yes, testing and updating woof-next has helped me to see things clearer again, i'll also add woof-next as an alternate build system. Although the current one can get very close and merge scripts from it, both already share initrd-progs, rootfs-skeleton and woof-arch.

There seemed no easy way to implement it without crossing many lines. It was a painful and long process of removing hundreds of files and stuff, and it's relatively easy for me to make all the remaining changes i want, at this point it's really what others have to say about it.. and time of course.

[mavrothal]

Others will not say anything until a build gets in the wild and woof-next keeps in its branch. BTW I remember back then that Ubuntu/Debian builds had some issues with repos/dependencies and apt-get. It may need a puppy specific repo to tame it. Then there is systemd that will be coming up everywhere in Debian/Ubuntu. May try Devuan or MXLinux as base for the Debian family distros. Slackware maybe a better start though, if you go down this road.

[wdlkmpx]

I don't plan to update debian/ubuntu support in woof-next and in fact, i don't plan to update the woof-next branch either, i have it working with the current stuff, basically everything from testing. Slackware only.

In fact the current stuff can morph into woof-next while keeping the .pet stuff, and the generic packages compatible with all builds. The problems are easy to fix, involves deleting stuff. But here be dragons.

With Pkg the puppy stuff is not that bad anymore, and simplifying the ppm at least ensures the gui doesn't get in the way.

[jamesbond3142]

On Sat, 04 May 2019 13:48:29 -0700 wdlkmpx notifications@github.com wrote:

I don't plan to update debian/ubuntu support in woof-next and in fact, i don't plan to update the woof-next branch either, i have it working with the current stuff, basically everything from testing. Slackware only.

Interesting. This "current" you're talking about, is that a branch in Woof-CE, or just your own checkout in your machine?

Just for curiousity sake, I might, just might update woof-next to build with current debian/ubuntu, if only to see if it still builds. It will require a lot of motivation on my side before that happens, though :)

In fact the current stuff can morph into woof-next while keeping the .pet stuff, and the generic packages compatible with all builds. The problems are easy to fix, involves deleting stuff. But here be dragons.

That would be ideal, and I think it is the way forward.

With Pkg the puppy stuff is not that bad anymore, and simplifying the ppm at least ensures the gui doesn't get in the way.

Hehehe. I would say that the puppy stuff has never been bad. It does have its own share of problems, just like anything else. Thank you for fixing them and improving it.

It has been my personal annoyance too that many of the GUI apps (including PPM) doesn't have a separate CLI and GUI component and hence it's very difficult to automate. That being said, Pkg is good and is long overdue; and as a bonus it is well supported as well, thanks Scott!.

[wdlkmpx]

The current stuff is here: https://github.com/puppylinux-woof-CE/woof-CE/commits/experimental

which has better support for woof-next, my modified woof-next.

woof-next is in a local branch, it's a directory: "zwoof-next". I have it working with slackware 14.2, no gui yet, but i was planning to use the lxde from ponce.cc.

I haven't tested in 2 or 3 or 4 weeks, but it's working and i was adapting the current build system so that woof-next also calls some helper scripts in woof-code/support to perform some tasks (initrd - done, iso - done, hacks - in progress).

woof-arch will be a tarball, it's already a tarball in woof-next, i want the current build system to also use that tarball.

I'll upload zwoof-next it in one or 2 weeks. damn i almost had a heart attack, seeing my zwoof-next directory empty.

I'm not good at backing up stuff, so it will go to the experimental branch very soon.

[mavrothal]

woof-next is in a local branch, it's a directory: "zwoof-next".

What's the problem in publishing it, in woof or your own fork? Specially if others might want to test or issue pulls for it 😉

[wdlkmpx]

I'll merge it to the experimental branch in a few days, i'll add a few more fixes and will produce a test build.

I'll add this repo: https://software.jaos.org/slackpacks/slackware-14.2/

https://software.jaos.org/slackpacks/slackware64-14.2/

[wdlkmpx]

One thing i noticed testing the zwn slackware puppy is that slapt-get does not resolve dependencies.. because slackware does not provide that info.

I said this before, the current stuff provides a proper slacko build. But it doesn't include Pkg by default, i'll make it a default app globally, but something that important should be integrated into woofCE, it needs cleanups, fixes and optimizations.

Back to zwn, so i decided to use Salix instead, which required code changes, now dependecy tracking works.

There's no wizard to setup a wireless internet connection in cli mode, my net-setup (originally from fatdog) should fill this gap.. i need to update it and test it again, there's too many things to do.

Using only compat distro pkgs, puppy gui stuff doesn't work, I only have a cli system with all the needed cli apps. Salix has a complete xfce i think, but i want lxde. Someone should adapt the whisker menu to lxde.

When you do something like this, both x86 and x86_64 builds have identical configs, except a few changes in the repo URL's. It makes sense.

[jamesbond3142]

Just for curiousity sake, I might, just might update woof-next to build with current debian/ubuntu, if only to see if it still builds. It will require a lot of motivation on my side before that happens, though :)

musher0 is motivation enough. I added (and merged) 32-bit devuan ascii support to woof-next. Check the last two commits if interested. Only one-line change to setup.sh; add devuan-build.sh symlink to deb-build, and add the repo/pkglist (mostly copying from ubuntu's except that I changed the repo to point to devuan, and I changed "udev" to "eudev"). Produces 177MB ISO with 3.9.94 huge kernel, and boots to desktop (and that's about it).

One thing i noticed testing the zwn slackware puppy is that slapt-get does not resolve dependencies.. because slackware does not provide that info.

Are you installing packages with slapt-get instead of installpkg?

There's no wizard to setup a wireless internet connection in cli mode, my net-setup (originally from fatdog) should fill this gap.. i need to update it and test it again, there's too many things to do.

You probably need to install more stuff. The included pkglist is very bare.

When you do something like this, both x86 and x86_64 builds have identical configs, except a few changes in the repo URL's. It makes sense.

Make things simple for the builder.

[wdlkmpx]

Now that you mention attention seekers and drama queens (musher, wanderer, oui, etc), i just ignore them because when i want something i make it possible myself.

I would be lying if i said that i really want to post on the murga forum.

I see you've fallen in the trap, you've been owned.

And then i might end up regretting what i do when attention seekers who don't even know how to build a puppy are the ones who release stuff based on my contributions. This makes it a bit difficult for me.

I will add zwn/ to the experimental branch in a couple of days, but now that i've become aware of something, i have to think about it 7 times during the next 7 hours and 7 minutes.

[jamesbond3142]

I see you've fallen in the trap, you've been owned.

LOL 🤣

And then i might end up regretting what i do when attention seekers who don't even know how to build a puppy are the ones who release stuff based on my contributions. This makes it a bit difficult for me.

I understand and sympathise.

I will add zwn/ to the experimental branch in a couple of days, but now that i've become aware of something, i have to think about it 7 times during the next 7 hours and 7 minutes.

LOL. No rush, it will be ready when it is ready.

[wdlkmpx]

All i say is you don't want musher's attention, he's a professional troll, he'll wipe the floor with you if you don't become his slave and obey his orders, the only way to teach him some modesty is by treating him ruthlessly. I'm goot at that, i feel so proud.

Notice the word 'plunder', that's exactly what he does, and just like wanderer, he'll want lots of attention to his creation, but in musher's sick case if something's wrong with it, it's your fault and you're the only want to blame, you'll be marked for life.

I certainly don't want his attention and now i see you're getting it. I also don't want wanderer's attention. It's possible by not including .deb support and dep tracking, and not providing a gui with puppy stuff, someone else will have to do that, and i hope nobody does.

I'll add the xmswsx in a few hours, it's experimental stuff.

[peabee]

What is "zwn"????

[wdlkmpx]

It's a new technique of firebending

[peabee]

Nope - none the wiser....

[wdlkmpx]

Sorry peabee, my blood was boiling as some thoughts disturbed my mind

zwm is this: https://github.com/puppylinux-woof-CE/woof-CE/tree/experimental/zwn

[jamesbond3142]

Sorry peabee, my blood was boiling as some thoughts disturbed my mind

If it is because musher0, then please don't. Just ignore him when he gets too annoying. Not sure if you read my post, I did give him a piece of my mind too.

[peabee]

Is it z-woof-next ??? If so I think it should get a more meaningful name..... woof-next-prototype ?

[wdlkmpx]

Just want to mention that i'm not mfb, he's probably someone musher treated ruthlessly. There are plenty of those people.

In the early days there was the mistake to create more puppy apps rather than developing the underlying system. Developers moved to other projects. Those who wanted to fork it already did (mistfire, etc), those using other alternatives (porteus, debianlive, etc) already have the answers.

The best i can do is keep deleting code and making structural chamges, i hope everyone agrees...

[ghost]

wanderer is the worst :laughing: maybe is systemd creator or former Microsoft CEO in disguise based on how they always try to over-complicate everything that already worked in simpler Puppy ways (just my impression from trying to to understand their "wandering brain" posts and failing :frowning_woman: )

[wdlkmpx]

wanderer needs tazpuppy, it doesn't get smaller and as functional, but he'll try to change mistfire's ways and defaults. that's why it's wise to ignore him.

Fred gave some good advice, debbootstrap is a script. I used deboobstrap to create a script to install debian, i was practicing, i used it only once probably

https://github.com/DebianDog/MakeLive/files/2215836/install-debian-to-hd.zip (2018)

I think i improved it a bit more while testing, it must be somewhere in the filesystem

I guess we can fix debian or devuan support in zwn, it doesn't make much difference when you use busybox..

Development requires peace of mind, and i somehow am used to do things alone, following the puppy tradition set in stone, since i was a simple user who only wanted some simple things to work. But i do accept code contributions and merge stuff if people are willing to merge their stuff..

[jamesbond3142]

I used deboobstrap to create a script to install debian

Before I wrote deb-build.sh for woof-next, I looked into debootstrap, figured out how it worked, a nd wrote my own implementation, which eventually became deb-build.sh

But funny thing is that every version of debian has its down debootstrap. You would think that they would only have one copy and only change the list of "base packages" that needs to be installed ...

I guess we can fix debian or devuan support in zwn, it doesn't make much difference when you use busybox..

I added devuan support to woof-next a few days ago. If you already have a working debian/ubuntu build, then all you need is to change repo URL to devuan instead of debian/ubuntu; and change "udev" or "systemd" to "eudev" and away it will fly. There is no code change, it's just changes to the repository.