If this goes through at woof-CE, let Puppy die.

News, happenings
Message
Author
jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#21 Post by jamesbond »

musher0 wrote:Was it he who introduced the horrific duplicate vs copy
confusion in the new version of ROX-Filer?
To the best of my knowledge, it was woodenshoe who did that, not wdlkmpx: http://murga-linux.com/puppy/viewtopic.php?t=114169. And mind you that this is an often-asked (or requested) features. Again the changes didn't happen because woodenshoe just feels like it.
@jamesbond: groups have different personalities and behaviors than
the group members as individuals. Hence the use of the words "they",
"them", and similar.
But that's assuming that they do work as a group. Which they don't. Continuing to call them as a group when they aren't is the same as stereotyping; and stereotyping doesn't help anyone.
It is an opinion made public.
And you're entitled to your opinion, of course.

I'm just saying that if you really want to solve the issue then it's better to contact the particular person using their usual channel of communication.
@bigpup: I'll repeat: for the life of me, I cannot get to the github forum
and leave a message there, it is too darn complicated. There is no
understandable doc about it to speak of anywhere on that github site.
Sailor Enceladus helped me once to leave a message there, but I never
got an answer. (It wasn't for the woof-CE project.)
1. Login with your github account.
2. Go to Woof-CE repo: https://github.com/puppylinux-woof-CE/woof-CE, and then click "Issues", directly under the Woof-CE title. Or just click here: https://github.com/puppylinux-woof-CE/woof-CE/issues
3. Then click "New Issues" button. It is green colour button in case you missed it.
4. Air your grievance in the given textbox, then click "Submit New Issue" (also a green colour button).

Hope that helps.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#22 Post by bigpup »

Ok How to post at Woof-CE on Github

1. Go to https://github.com/puppylinux-woof-CE/woof-CE
2. Click on Sign Up button (top right of web page).
3.At sign up web page https://github.com/join
Make a Username.
Give Email address.
Make a password.
Now you have a username and password to sign in with to Github.

To do a post.
On the Woof-CE web page at Github. https://github.com/puppylinux-woof-CE/woof-CE
1. Click on Sign in button (top right of web page)
Use your Github username and password.
2. At top of web page are tabs for code, issues, pull requests, wiki, and insights.
There are two places to post.
Issues or pull requests.
Issues are something you want talked about, fixed, you found a problem, etc.....
Pull requests are for posting a fix you found, new code you made, something you offer for woof-CE, etc......

Example post to issues:
1. Click on issues tab
(issues web page will open showing list of posted issues)
2. Click on new issue button (top right on web page)
3. This should now show place to enter what you want to post. Finish entering what you want to post.
4. Click on submit new issue button.
5. Back at the issues web page with listed issues. Your new issue should now be listed.

Posting to a listed issue or pull request.

Example a listed issue:
1. Click on the issues tab.
2. Click on a listed issue.
3. At bottom of the comments for that issue is a place to post a new comment.
Enter what you want to say.
4. Click on comment button.
Your comment should now be showing in the list of comments for that issue.

I do not think I need to say this, but here goes.
After you make a Github username and password.
It is good to use anytime you want to sign in to Github.

To make any comments to an issue or pull request, make a new issue, or make a new pull request.
You have to be signed into Github first.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Attack of Modularity and Creativity?

#23 Post by mikeslr »

As you know, I'm not a 'tekkie'. When I examine code, it's like pulling teeth. I can systematically look up the terms used and perhaps obtain some understanding of the information conveyed, but it's a foreign language. . On the other hand, by now I have a pretty good understanding of Puppy Linux as a system, what each component does, how it relates to other parts of the system and what alternatives there are for accomplishing one's objective.

My take on the 'commit' is that it is destructive not because it limits the ability to re-use SaveFiles, but because it locks development of Puppies into only those using the current kernels supported by Woof.

As bigpup pointed out, the ability to re-use a SaveFile/Folder has always had limitations. For example, you can't simply change the name of one built under Tahrpup and expect it to function on a Slacko. Or even a Xenialpup. At best, you might rename it as, for example, adrv_slacko_6.3.2.sfs, which having lower priority, would avoid conflicts although the included applications may not work OOTB. Or ever. And as Marv pointed out, to even to use a SaveFile/Folder within an upgrade of the same Puppy Version should be proceeded by 'scrubbing' applications effected by the upgrade.

[I do something else. I open PPM>Uninstall, take a snapshot, install the up-graded Puppy to a different folder and reinstall those applications I still want, using the snapshot as a guide].

I'll also point out that recently its become increasingly difficult to transfer a SaveFile/Folder to a different computer: in some instances the architecture of the creating computer apparently becomes locked in

However, thanks to the work of nic007 and shinobar before him, what was once a confusing and time consuming project, Remastering, has become quick and --relatively-- easy. And ITSMERSH's PaDS also makes the creation of adrvs a simple process, though whether they can be transferred from one version of Puppy to another suffers the same limitations as that of merely changing the name of a SaveFie's to an adrv.

From the viewpoint of creativity, however, one of Puppy's strong points, since jemimah spear-headed modularity, has been its ability to easily swap kernels and their associated drivers. Need a nopae kernel? Easy: download one, change a couple of names and use it. Acquired more than 4 Mbs of RAM and now need a kernel which can use it: download a kernel which can, change a couple of names and use it. There's been a kernel break-through regarding spectre or some newly discovered exploit? Easy, download the new kernel...

I don't build kernels. But rockedge, sailor enceladus, 666philb and peebee do; and wiak has an extensive understanding of how the woof-build process functions. Their work has been at the forefront of keeping Puppies current with the latest innovations. I wonder to what extent the 'commit' limits their creative efforts or those of others who might want to join them?
Last edited by mikeslr on Sun 17 Feb 2019, 19:35, edited 2 times in total.

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#24 Post by bigpup »

Here is a issue at Woof-CE I just posted in.
https://github.com/puppylinux-woof-CE/w ... ssues/1330
I think I gave the information they where looking for.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#25 Post by bigpup »

GO READ THE WOOF-CE CODE CHANGE AGAIN.
There are many comments added to it from when you first posted this topic.
https://github.com/puppylinux-woof-CE/w ... 42ade611aa
Comments are at the bottom.
wdlkmpx wrote:As i said, the suggested change to offer the option to refuse or proceed With the upgrade will probably implemented on monday. I've been working 12 hours straight, and i'll work 3 more hours
See, if you comment on Github, they do listen to what you say!

However, there does seem to be some reasons for wanting to do this.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#26 Post by musher0 »

I sincerely hope that the devs there have antennas here.

For one thing, I discovered a man-made "cancellation" when building
the DPupBuster:
http://murga-linux.com/puppy/viewtopic. ... st#1018770

It goes like this:
-- fetch, unpack and prepare the Xorg drivers for a new pet;
-- now erase the specific drivers for the keyboard and the mouse. :D

Don't laugh. True story. Proof is in PhilB's mini-recipe here:
http://murga-linux.com/puppy/viewtopic. ... st#1017969
in a config file called _00build.conf.

Hopefully this will not happen too often!

Isn't there there a famous quote from the New Testament: "Let your right-
hand dev undo what your left-hand dev is doing?" (Or something like it;
not verbatim).*

This is not meant as disrespect, it's supposed to be humor!

BFN.
~~~~~~~~~~~
* - Correct quote is : "Let not your left hand know what your right hand
does." (Matthew:6:3).
But context is giving to the poor! Not Puppy development!
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#27 Post by 666philb »

musher0 wrote:
It goes like this:
-- fetch, unpack and prepare the Xorg drivers for a new pet;
-- now erase the specific drivers for the keyboard and the mouse. :D
by removing those drivers xorg then uses the evdev driver for the keyboard and mouse. puppy will then also use /etc/X11/xorg.conf.udev as a base for xorg.conf and populate it using udev. this allows touch screens to work and allows 3rd party applications such as the nvidia driver application to write to the xorg.conf without borking puppy.

_00build.conf. is a file you can use to apply final tweaks & fixes to the build. some of the stuff in the dpupbuster one may not be applicable as i just copied it from bionic. it is up to the builder to populate it for the puppy that they are building.
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331

foxpup
Posts: 1132
Joined: Fri 29 Jul 2016, 21:08

#28 Post by foxpup »

bigpup wrote:GO READ THE WOOF-CE CODE CHANGE AGAIN.
There are many comments added to it from when you first posted this topic.
https://github.com/puppylinux-woof-CE/w ... 42ade611aa
Comments are at the bottom.
I need a "Puppy for dummies" :D
I am not sure I understand correctly. It seems to be about updating and upgrading Puppy :shock:
What righteous Puppy-user ever bothers about updates? Maybe change a kernel, yes, but upgrade? I know some flavours offer it, but it is not really Puppy, is it?
If it works, it works. If you want something else you install another Puppy entirely.

And I do not see what it has to do with the Pupsave.
Please explain.

BTW, one of the best things in Puppy is how harmless it is to 'break' a Puppy.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#29 Post by musher0 »

666philb wrote:
musher0 wrote:
It goes like this:
-- fetch, unpack and prepare the Xorg drivers for a new pet;
-- now erase the specific drivers for the keyboard and the mouse. :D
by removing those drivers xorg then uses the evdev driver for the keyboard and mouse. puppy will then also use /etc/X11/xorg.conf.udev as a base for xorg.conf and populate it using udev. this allows touch screens to work and allows 3rd party applications such as the nvidia driver application to write to the xorg.conf without borking puppy.

_00build.conf. is a file you can use to apply final tweaks & fixes to the build. some of the stuff in the dpupbuster one may not be applicable as i just copied it from bionic. it is up to the builder to populate it for the puppy that they are building.
Hello, 666philb.

That's what it was supposed to do, "on paper". In practice, the evdev|
udev, etc., did NOT do the re-population, so that particular removal
prevents user access from either keyboard or mouse.

I spent a day and half scratching my head about that bug. Not funny. A
"flag" or some notification drawing attention to that finishing-touch conf
file would have been nice.

Please correct that approach, you or anyone? Many thanks in advance.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#30 Post by 666philb »

just did a fresh 32bit buster build with the latest woofce testing, chose xenials kernel and keyboard, touchpad, wifi & sound are all working for me.
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#31 Post by musher0 »

666philb wrote:just did a fresh 32bit buster build with the latest woofce testing, chose xenials kernel and keyboard, touchpad, wifi & sound are all working for me.
Hi Phil.

I'm glad you succeeded. Will you be keeping it to yourself or will you make
it available to Puppyists?

As I mentioned in the DPupBuster development thread, someone with more
experience and/or talent comes up with a version, I step back. My interest is
little-known WMs, not "woofing".

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#32 Post by bigpup »

foxpup wrote:I am not sure I understand correctly. It seems to be about updating and upgrading Puppy :shock:
What righteous Puppy-user ever bothers about updates? Maybe change a kernel, yes, but upgrade? I know some flavours offer it, but it is not really Puppy, is it?
If it works, it works. If you want something else you install another Puppy entirely.

And I do not see what it has to do with the Pupsave.
Please explain.
For years it has been possible to use a older save made in the same named Puppy version series.
Example:
A save made in Slacko 5.0 should be able to be used in Slacko 5.3 and 5.5 and 5.7 etc...... When it is used, it is updated to the newer Slacko version.
The update is about changing some identifying names, in the save, to say it is the save for the newer Slacko version.
It is code in the boot process that automatically does this.

It has always been stated that if the named Puppy version changes to a new series (Slacko 6.0) that no save from Slacko 5 series will work and a completely new save has to be done.

This is more about using an older save, that has a bunch of programs, settings, setups, etc..... in it and making it still usable in a newer version of that named Puppy version.
It has always been about, just how much has changed between the two Puppy versions.
If it is too much, the save is not going to carry over very well.

If I understand what they are saying about Woof-CE.
There are enough changes in the core Puppy processes, programs, setup, etc.... in a newer Woof-CE version.
That too much has changed in Puppy to be able to use a save that works in a Puppy that was made using a older version of Woof-CE.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#33 Post by mistfire »

In order to solve this issue just give the user an option whether to load save files or not if the WOOF versions are different.

UPDATE: wdlkmpx implemented that option

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#34 Post by bigpup »

I hope he or they also but a big warning with it that this may or may not work.
The save is not 100% a sure thing to completely work.
For sure, anything in the save that is kernel specific, will only work with that specific Linux kernel.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

foxpup
Posts: 1132
Joined: Fri 29 Jul 2016, 21:08

#35 Post by foxpup »

Thank you bigpup!
This I understand much better. 8)

I have not used a pupsave of one Puppy in another often.
I may do it between different RC's or between updates from peebee or mistfire.
I took installs with pupsave along when I migrated from my old machine to my 2 newer ones.
I never had much trouble with it.
I did not realise there was an update of the pupsave in the background. May have seen some note about it, now I think about it.
It is not possible I moved a pupsave from Tahr to Slacko? I thought I did one time.

But overall, it is nothing important to me, since I try to keep my pupsave slim, very slim.
I have most addons/apps 'outside' available for all or most Puppys and derivatives I run. Also some configuration like .mozilla.
I use Puppys mostly as they are.

This topic from shinobar should be mandatory reading for Puppy-users, shouldn't it:
Keep your savefile slim and healthy
I love the way shinobar uses the possibilities of Puppy. It's similar to what RSH does, I think.
Last edited by foxpup on Tue 19 Feb 2019, 19:00, edited 1 time in total.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#36 Post by musher0 »

mistfire wrote:In order to solve this issue just give the user an option whether to load save files or not if the WOOF versions are different.

UPDATE: wdlkmpx implemented that option
Hello mistfire and all.

That's a wise move on the part of "wdlkmpx", IMO.

Except no Puppy dev has yet come up with code to improve pupsave
portability. AFAIK, pupsave portability is still limited to "same breed of
Pup, nearest up version".
-- same breed of Pup
(e.g. slacko to slacko, lupu to lupu, xenial to xenial, and similar.)
-- nearest up version (e.g. slacko-5.9 to slacko-6.0). If you go the other
way around, e.g. try to load a pupsave created in slacko-6 in slacko-5.9,
expect trouble.

I believe that a wider portability of pupsaves is what Puppy would need to
reduce frustration for users -- and retain them!

E.g. (that I know of), slacko-type Pups have the doc dir under /usr directly,
whereas Ubuntu- or Debian-derived Pups have it under /usr/share. Does
that pose a problem for portability? What other big differences are there?
Linux is Linux, no?

Also, IMO, the user should be able to incorporate such code in older Pups.
Like a "retrofit"; or the pupsave itself maybe could have code in some sort
of "header" or "footer" to manage its own portability?

IHTH. BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Post Reply