Why would a Puppy NOT load the zdrv.sfs? (SOLVED)
Why would a Puppy NOT load the zdrv.sfs? (SOLVED)
Hello all.
This is very weird.
In "The Pooch" (aka dpup-3.14.56 or its younger incarnation in the making,
dpup-3.14.65) -- starting here --, the modules load fine if they are in
the main puppy sfs, but they don't load at all if I put them in the zdrv.
I did not change anything in init or /etc. This is its default behavior: the Woof-CE
process delivers the wheezy pup like this OOTB.
How can I re-activate the zdrv? Thanks in advance for any pointers.
BFN.
This is very weird.
In "The Pooch" (aka dpup-3.14.56 or its younger incarnation in the making,
dpup-3.14.65) -- starting here --, the modules load fine if they are in
the main puppy sfs, but they don't load at all if I put them in the zdrv.
I did not change anything in init or /etc. This is its default behavior: the Woof-CE
process delivers the wheezy pup like this OOTB.
How can I re-activate the zdrv? Thanks in advance for any pointers.
BFN.
Last edited by musher0 on Sun 27 Mar 2016, 20:55, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Fine.
If no other Puppyist cares that a Woof-CE template cannot have its modules in a
zdrv_xxx,sfs, then I won't either.
In nihaholic's slim 6 and other recent Pups, you can put the zdrv in the same folder
as the main sfs, and the kernel picks it up.
In the Puppy 3.00 series you had to put the zdrv.sfs at the top level in /mnt/home for
the kernel to pick it up.
In this case, you can put the zdrv anywhere you like, the kernel will NOT pick it up.
It's probably just a parm or a variable somewhere, and nobody's telling me where it is.
I've been very patient with this "wheezy breed" of Puppy. But it has too many
shortcomings. Maybe it's time I bring it to the SPCA.
The paragrapĥ above is certainly a metaphor, but It's not a joke. Go figure.
BFN.
If no other Puppyist cares that a Woof-CE template cannot have its modules in a
zdrv_xxx,sfs, then I won't either.
In nihaholic's slim 6 and other recent Pups, you can put the zdrv in the same folder
as the main sfs, and the kernel picks it up.
In the Puppy 3.00 series you had to put the zdrv.sfs at the top level in /mnt/home for
the kernel to pick it up.
In this case, you can put the zdrv anywhere you like, the kernel will NOT pick it up.
It's probably just a parm or a variable somewhere, and nobody's telling me where it is.
I've been very patient with this "wheezy breed" of Puppy. But it has too many
shortcomings. Maybe it's time I bring it to the SPCA.
The paragrapĥ above is certainly a metaphor, but It's not a joke. Go figure.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- LazY Puppy
- Posts: 1934
- Joined: Fri 21 Nov 2014, 18:14
- Location: Germany
Why should anyone use a zdrv sfs if everything is already in the main sfs?
What is the benefit of to put anything into the/a zdrv sfs and to load this compared to load everything from within the main sfs?
I would prefer to see all the Puppies coming without the zdrv sfs, to have the loop for the zdrv sfs available for a different sfs made by the/a user - like I had done it in original LazY Puppy and L.A.S.S.I.E. (called it Extension SFS then).
What is the benefit of to put anything into the/a zdrv sfs and to load this compared to load everything from within the main sfs?
I would prefer to see all the Puppies coming without the zdrv sfs, to have the loop for the zdrv sfs available for a different sfs made by the/a user - like I had done it in original LazY Puppy and L.A.S.S.I.E. (called it Extension SFS then).
RSH
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
Hello nic007 and LazY PuppY.
So you guys think that it's ok to NOT have the choice of a zdrv, even if this is
seemingly a bug in the wheezy template. Am I understanding you correctly?
In a sense, I don't care either about a zdrv sfs since we have the "onboard"
solution. My concern is with the other "typed" sfs's : adrv, fdrv, ydrv. Adrv in
particular is much too handy if you consider that, instead of remastering, you can
transform your pupsave file into an adrv. If this "Pooch" cannot recognize and load
the zdrv, can it recognize and load an adrv?
I know, I know, LazY is philosophically against pupsaves.
But I am for pupsaves.
So let's have a duel in a dark alley behind St.Thomas Lutheran Cathedral in Leipzig
in memory of J.S. Bach, like he did when the 1st tenor in his choir showed too
much interest in his wife!!! (JSB won, apparently!)
All joking aside, and back to concepts, I don't think it's ok to deliver to the users a
Puppy that cannot have a zdrv. In any industry, that's called a manufacture defect.
I hate defects. We should not tolerate defects if we respect our work.
So: is anybody going to help me solve this problem or not? As I said, either I find
a solution to this, or I bring "The Pooch" to the nearest SPCA.
Again, that is a metaphor but it's not a joke. I am getting more and more fed up with
bugs in Puppies, with the lack of thoroughness in Puppies, with all the "round
corners" in Puppies. I am actively seeking another suitable distro to continue my
work.
BFN.
So you guys think that it's ok to NOT have the choice of a zdrv, even if this is
seemingly a bug in the wheezy template. Am I understanding you correctly?
In a sense, I don't care either about a zdrv sfs since we have the "onboard"
solution. My concern is with the other "typed" sfs's : adrv, fdrv, ydrv. Adrv in
particular is much too handy if you consider that, instead of remastering, you can
transform your pupsave file into an adrv. If this "Pooch" cannot recognize and load
the zdrv, can it recognize and load an adrv?
I know, I know, LazY is philosophically against pupsaves.
![Smile :)](./images/smilies/icon_smile.gif)
So let's have a duel in a dark alley behind St.Thomas Lutheran Cathedral in Leipzig
in memory of J.S. Bach, like he did when the 1st tenor in his choir showed too
much interest in his wife!!! (JSB won, apparently!)
All joking aside, and back to concepts, I don't think it's ok to deliver to the users a
Puppy that cannot have a zdrv. In any industry, that's called a manufacture defect.
I hate defects. We should not tolerate defects if we respect our work.
So: is anybody going to help me solve this problem or not? As I said, either I find
a solution to this, or I bring "The Pooch" to the nearest SPCA.
Again, that is a metaphor but it's not a joke. I am getting more and more fed up with
bugs in Puppies, with the lack of thoroughness in Puppies, with all the "round
corners" in Puppies. I am actively seeking another suitable distro to continue my
work.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- LazY Puppy
- Posts: 1934
- Joined: Fri 21 Nov 2014, 18:14
- Location: Germany
As I do understand this, "The Pooch" comes without a zdrv sfs, so it's not a bug to me, if it can't load a zdrv sfs. It's just like to be "designed" that way - just like the old Lucid and like Precise ( though, they can load a zdrv sfs, if there would be any (that's why the Extension SFS had worked in LazY Puppy and L.A.S.S.I.E.) ).
To load the zdrv sfs the init script from initrd.gz should include some code like this:
Probably it's just disabled somehow (search the init script for ZDRVSFS or ZDRV or ZLAYER to see what's going on)?
Search for ADRVSFS or ADRV or ALAYER in the init script to see if it can handle a adrv sfs. And so on...
However, no!
I don't think it's ok to NOT to have the choice of a zdrv sfs. I prefer to have the zdrv sfs's content in main sfs to have the loop for the zdrv sfs available for the use of a different sfs made by myself - it's a different solution/purpose!
And also, no! I'm not contra to save files. I'm pro to pupmode 5 and SFS files (the more today, as I do have now my Configuration SFS Module which is basically build by the code to create the save directory for Puppy)!
---
Post your init script here!
To load the zdrv sfs the init script from initrd.gz should include some code like this:
Code: Select all
if [ "$ZDRV" = "" ];then
FND_FILES="`find /mnt/data${PSUBDIR} -maxdepth ${SEARCHDEPTH} -xdev -type f -iname ${ZDRVSFS} | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
for ONEPUPFILE in $FND_FILES
do
if [ "$NAMETYPE" = "traditional" ];then
ONEIDSTRING="$IDSTRING" #found file based on it's name only.
else
ONEFULLSIZE=`stat -c %s /mnt/data${ONEPUPFILE}`
ONEORIGSIZE=`expr $ONEFULLSIZE - 16`
ONEIDSTRING="`dd if=/mnt/data${ONEPUPFILE} bs=1 skip=${ONEORIGSIZE} 2>/dev/null | sed -e 's%[^a-zA-Z0-9]%%g'`"
fi
if [ "$ONEIDSTRING" = "$IDSTRING" ];then
ZDRV="${ONEDEV},${ONEFS},${ONEPUPFILE}"
break
fi
done
fi
Code: Select all
ZLAYER='' #v4.02
ZFACTOR='' #v426
#note, traditionally, loop2 kept free for scripts to use.
if [ "$ZDRVINIT" != "yes" ];then
if [ "$ZDRVSFS" != "NoLP2ExtensionSFS" ]; then
echo " " > /dev/console # RSH
#echo -n "Loading the '${ZDRVSFS}' extension file..." > /dev/console # RSH
echo -n "Lade die Erweiterung: '${ZDRVSFS}'" > /dev/console # RSH
echo -e -n " \\033[1;35m${COPYMSG}\\033[0;39m" > /dev/console #purple # RSH
fi
#v4.02 if ZDRV located, and mounted, put it into the layered-fs...
if [ "$ZDRV" != "" ];then
ZDEV="`echo "$ZDRV" | cut -f 1 -d ','`"
ZFS="`echo "$ZDRV" | cut -f 2 -d ','`"
ZFILE="`echo "$ZDRV" | cut -f 3 -d ','`"
MNT_ZFILE=""
if [ "$ZDEV" = "rootfs" ];then #101102 humongous initrd.
MNT_ZFILE="" #actually it's '/'.
COPY2RAM='yes' #actually it is already in ram, but code below puts it in a tmpfs.
else
#[ -f /mnt/dev_save${ZFILE} ] && MNT_ZFILE="/mnt/dev_save"
#[ "$MNT_ZFILE" = "" ] && [ -f /mnt/dev_ro2${ZFILE} ] && MNT_ZFILE="/mnt/dev_ro2"
#[ -f ${PUPSFSDEVMNTPT}${ZFILE} ] && MNT_ZFILE=${PUPSFSDEVMNTPT} #101102
#101102 well, no, do it properly...
zPATTERN="/dev/$ZDEV "
MNT_ZFILE="`mount | grep "$zPATTERN" | cut -f 3 -d ' '`"
fi
ZBASENAME="`basename $ZFILE`" #v426 moved up.
if [ "$MNT_ZFILE" != "" ];then
if [ "$COPY2RAM" = "yes" ];then
SIZEZK=`du -k ${MNT_ZFILE}${ZFILE} | cut -f 1`
SIZEZK=`expr $SIZEZK + 1000` #some slack.
mount -t tmpfs -o size=${SIZEZK}k tmpfs /mnt/tmpfs2
if [ "$MNT_ZFILE" = "" ];then #101101 humongous initrd.
mv -af ${MNT_ZFILE}${ZFILE} /mnt/tmpfs2/
else
cp -af ${MNT_ZFILE}${ZFILE} /mnt/tmpfs2/
fi
sync
losetup /dev/loop3 /mnt/tmpfs2/${ZBASENAME}
else
losetup /dev/loop3 ${MNT_ZFILE}${ZFILE}
fi
mount -r -t squashfs -o noatime /dev/loop3 /pup_z
if [ $? -eq 0 ];then
ZLAYER=':/pup_z=ro'
ZFACTOR="$ZBASENAME" #v426
fi
fi
fi
fi
Search for ADRVSFS or ADRV or ALAYER in the init script to see if it can handle a adrv sfs. And so on...
However, no!
I don't think it's ok to NOT to have the choice of a zdrv sfs. I prefer to have the zdrv sfs's content in main sfs to have the loop for the zdrv sfs available for the use of a different sfs made by myself - it's a different solution/purpose!
And also, no! I'm not contra to save files. I'm pro to pupmode 5 and SFS files (the more today, as I do have now my Configuration SFS Module which is basically build by the code to create the save directory for Puppy)!
---
Post your init script here!
RSH
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
I think 3builddistro-Z is to build woof-CE with huge kernel and 3builddistro is to use older style. If using 3builddistro-Z you might have to use DISTRO_KERNEL_PET='Huge_Kernel' in DISTRO_SPECS like in tahr and throw your custom zdrv kernel into the woof-out*/huge_kernel directory or pick one of the templates during install. Just a guess, and there might be more things.
@RSH, aka LazY_PuppY
As you requested above, please find attached the init file for "The Pooch".
I hope that you can shed some light on this mystery. TIA.
BFN.
As you requested above, please find attached the init file for "The Pooch".
I hope that you can shed some light on this mystery. TIA.
BFN.
- Attachments
-
- init.zip
- init file from "The Pooch", zipped.
- (27.99 KiB) Downloaded 164 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Hello "Sailor Enceladus".Sailor Enceladus wrote:I think 3builddistro-Z is to build woof-CE with huge kernel and 3builddistro is to use older style. If using 3builddistro-Z you might have to use DISTRO_KERNEL_PET='Huge_Kernel' in DISTRO_SPECS like in tahr and throw your custom zdrv kernel into the woof-out*/huge_kernel directory or pick one of the templates during install. Just a guess, and there might be more things.
The Woof-CE being the un-policed and un-supervised shanty town that it is, I'm not
going back there. That would mean I would have to re-do from the start all the edits
I've already brought to the wheezy template. (If you want to see for yourself which
edits, the URL for my dpup-3.14.65.2, aka "The Pooch", is somewhere above.)
If someone wants to sue me over my opinion of the Woof-CE, go right ahead.
I've had just about enough of this round-cornered half-baked process. Geez.
If my opinion means I have to break rank, I will. There's nobody progressive at the
helm of the Woof-CE process anyway. They reject anything innovative or that don't
fit their philosophy. Forum member and developer jlst testified to it publicly. So it's
not just my opinion.
To which I will add that they don't even have the intellectual curiosity of checking if
more recent versions of apps have been published before they start the process of
building their new pups.
For example, the < less > version in the latest slacko-6.3.0 is still 451 whereas the
latest < less > version is 481. How difficult can it be to check if a more recent
version of apps exists? The same holds true for the core GNU utilities.
Shall I get going on the useful and even necessary utilities that are NOT in Puppy
Linux? A case in point being the very useful < tree > utility, which simply does not
exist in Puppy by default. I stumbled upon it by chance -- but other distros have it.
Serious first-year junior college students in computer science (they may be called
"grade 13" or "cegep" or "Première" students in some jurisdictions) students are
more thorough, by golly.
Best regards.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
@RSH, aka LazY_PuppY, or anyone who can answer.
Hi.
As far as I can tell, the init script sections concerning the ZDRV match the excerpts
that you posted above. Since the init script incorporates the DISTRO_SPECS file at
the very beginning... and in turn, since the DISTRO_SPECS file says to look in
/etc/rc.d/PUPSATE for the ZDRV location.
Various notes:
-- there is no PUPSTATE file in initrd.gz
-- the PUPSTATE file in the main sfs file has this
-- ZDRV line: There was never any zdrv sfs file in sdb5 -- as far as I can back-
__ track my work on "The Pooch". I used sdd8, alternately sdc8, while building
__ "The Pooch". sdb5 is an internal disk that I burn my isos from.
-- I suppose I should alter the ZDRV line to reflect this?
-- It would also be logical to change ZDRVINIT to 'yes', I suppose?
Finally, should I include the modified PUPSTATE file in the initrd.gz? It doesn't
have one at present. In good and simple logic, it should, shouldn't it? Otherwise
the init script won't know where to look for it, right? Or is this another of Puppy's
inconsistencies?
Thanks in advance for any pointers.
BFN
Hi.
As far as I can tell, the init script sections concerning the ZDRV match the excerpts
that you posted above. Since the init script incorporates the DISTRO_SPECS file at
the very beginning... and in turn, since the DISTRO_SPECS file says to look in
/etc/rc.d/PUPSATE for the ZDRV location.
Various notes:
-- there is no PUPSTATE file in initrd.gz
-- the PUPSTATE file in the main sfs file has this
Code: Select all
PUPMODE=13
PDEV1=''
DEV1FS=''
PUPSFS='sdc2,ext2,/puppy_wheezy_3.14.56.1.sfs'
PUPSAVE='sdc2,ext2,/wheezysave-JustInCase.2fs'
PMEDIA='cd'
#ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
ATADRIVES='sda sdb '
#ATAOPTICALDRIVES is list of non-usb optical drives...
ATAOPTICALDRIVES='sr0 '
#these directories are unionfs/aufs layers in /initrd...
SAVE_LAYER='/pup_ro1'
PUP_LAYER='/pup_ro2'
#The partition that has the wheezysave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV='sdb5,ext4,/zdrv_wheezy_3.14.56.1.sfs'
FDRV=''
ADRV=''
YDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='no'
#Partition no. override on boot drive to which session is (or will be) saved...
PSAVEMARK=''
PSUBDIR=''
__ track my work on "The Pooch". I used sdd8, alternately sdc8, while building
__ "The Pooch". sdb5 is an internal disk that I burn my isos from.
-- I suppose I should alter the ZDRV line to reflect this?
-- It would also be logical to change ZDRVINIT to 'yes', I suppose?
Finally, should I include the modified PUPSTATE file in the initrd.gz? It doesn't
have one at present. In good and simple logic, it should, shouldn't it? Otherwise
the init script won't know where to look for it, right? Or is this another of Puppy's
inconsistencies?
Thanks in advance for any pointers.
BFN
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- LazY Puppy
- Posts: 1934
- Joined: Fri 21 Nov 2014, 18:14
- Location: Germany
Yes, in tahr it's equal: PUPMODE=2 is the only content ( /initrd/pup_ro2/etc/rc.d/PUPSTATE ).rg66 wrote:Musher, can you post the DISTRO_SPECS file from initrd,gz?
Looking at PUPSTATE in slacko-6.3.0 main sfs, the only entry is PUPMODE=2. The rest must be added at first boot.
Post also the /initrd/pup_ro2/etc/rc.d/PUPSTATE file, please - if it's content is different.
In extracted initrd.gz from tahr: /etc/rc.d/BOOTCONFIG is the only file in the path.
Attached is a init script made from a diff and patch - probably it's just worth a try?
- Attachments
-
- init-fake.gz
- (90.65 KiB) Downloaded 165 times
RSH
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:
No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:
Wow, such an anger!musher0 wrote:The Woof-CE being the un-policed and un-supervised shanty town that it is, I'm not
going back there.
If you are being generous, and assuming that your edits do work, you may want to submit patches to Woof-CE so that the next person who wants to build Debian-based puppy from it doesn't have to suffer the same fate as yours. Or you can keep your edits to yourself to make sure that future Debian puppy builders can "share" your "horrible" experience of Woof-CE. Your choiceThat would mean I would have to re-do from the start all the edits
I've already brought to the wheezy template. (If you want to see for yourself which
edits, the URL for my dpup-3.14.65.2, aka "The Pooch", is somewhere above.)
![Wink :wink:](./images/smilies/icon_wink.gif)
Do you realise that *nobody* is maintaining the code for Debian-based puppy? Slackware-based is maintained - someone who is trying to make a slackpup, if not working, can raise his/her hand and get 01micko's help. Same with tahrpup, raise your hand and 666philb will come to help. But Woof-CE supports more than these two distros, however., the support is as good as its maintenance. And there is nobody maintaining Debian-based puppy code. Since you have a keen interest in making a Debian-based puppy work, you could become its maintainer, if you wish.If someone wants to sue me over my opinion of the Woof-CE, go right ahead.
I've had just about enough of this round-cornered half-baked process. Geez.
Strange, indeed. Forum member jlst is in fact contributing a lot of code changes, many of which have been accepted. jlst's persona in github is "wdlkmpx" and you can see for yourself how active he is in Woof-CE github repo.If my opinion means I have to break rank, I will. There's nobody progressive at the
helm of the Woof-CE process anyway. They reject anything innovative or that don't
fit their philosophy. Forum member and developer jlst testified to it publicly. So it's
not just my opinion.
Ummm, because, slacko is based on Slackware, and the version of Slackware used for slacko 6.3.0 (Slackware 14.1) provides less 451?To which I will add that they don't even have the intellectual curiosity of checking if
more recent versions of apps have been published before they start the process of
building their new pups.
For example, the < less > version in the latest slacko-6.3.0 is still 451 whereas the
latest < less > version is 481. How difficult can it be to check if a more recent
version of apps exists?
Usefulness is subjective. Something that is useful to you may not be useful to others. But, disregard that, and instead, if you really find it useful, why not propose to include this into every (future) puppy, by putting it into Woof-CE?Shall I get going on the useful and even necessary utilities that are NOT in Puppy
Linux? A case in point being the very useful < tree > utility, which simply does not
exist in Puppy by default. I stumbled upon it by chance -- but other distros have it.
cheers!
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]
@jamesbond
In no order:
-- Yes. anger. I love this distro and people are letting me down by not being thorough.
-- Well, jlst complained in the Pooch thread and elsewhere about not getting his ideas
accepted, that there was a lack of response from the Woof-CE leaders. I didn't get
the impression that he was lying. I want to hear your comment about that -- coming
from him.
-- As to feeding back my edits and findings, they are all in the "Pooch" thread
mentioned above. If that is not giving back to the community, what is? 01micko
tried to explain to me the push and pull at github, and it sounded as complicated as
any bureaucratic process.
On the other hand, mavrothal said it was possible for pet archives to supersede
the defaults in Woof-CE. I understand this as follows: any and all interested people
can take any of my pet archives and introduce them in their Woof-CE process.
If the maintainers or admins of the Woof-CE do not want to go themselves search
for new potentially valuable stuff published through the forum, if they're not on the
look-out for it, if they absolutely want the faithful to bring their offerings to their
temple, they're partially proving my point.
-- As to becoming a maintainer of the Debian builds, given my lack of talent and
interest for any "bureaucratic process", the answer will be "no". There are already
people much more advanced than I am who are producing Debian builds: semme
and josejp2424, among others. Ask them.
For the record, Josejp2424 published a "pupjibaro Jessie" a few hours ago,
based on the Woof-CE "testing".
-- That the slackware repo doesn't have the latest version of less (rest assured I'll
double-check) is a poor excuse. Is Puppy so dependent on other distros' repos that
its developers cannot be pro-active? By not being pro-active, PuppyLinux will always
stay behind.
-- Finally, I'll dispute your opinion that obviously useful utilities such as less, tree,
any type of locate, and the inclusion of the latest versions of the core GNU utilities
are open to subjective choice.
Why do other distros have them by default and we don't? Give me a good reason
why PuppLinux should be making computer life more difficult and complicated for its
users than the other distros.
I fought to have the real less included in Puppy, and I'll fight for the general concept
as well -- unless you guys manage to demotivate me completely about the Puppy.
Happy Easter nonetheless.
In no order:
-- Yes. anger. I love this distro and people are letting me down by not being thorough.
-- Well, jlst complained in the Pooch thread and elsewhere about not getting his ideas
accepted, that there was a lack of response from the Woof-CE leaders. I didn't get
the impression that he was lying. I want to hear your comment about that -- coming
from him.
-- As to feeding back my edits and findings, they are all in the "Pooch" thread
mentioned above. If that is not giving back to the community, what is? 01micko
tried to explain to me the push and pull at github, and it sounded as complicated as
any bureaucratic process.
On the other hand, mavrothal said it was possible for pet archives to supersede
the defaults in Woof-CE. I understand this as follows: any and all interested people
can take any of my pet archives and introduce them in their Woof-CE process.
If the maintainers or admins of the Woof-CE do not want to go themselves search
for new potentially valuable stuff published through the forum, if they're not on the
look-out for it, if they absolutely want the faithful to bring their offerings to their
temple, they're partially proving my point.
-- As to becoming a maintainer of the Debian builds, given my lack of talent and
interest for any "bureaucratic process", the answer will be "no". There are already
people much more advanced than I am who are producing Debian builds: semme
and josejp2424, among others. Ask them.
For the record, Josejp2424 published a "pupjibaro Jessie" a few hours ago,
based on the Woof-CE "testing".
-- That the slackware repo doesn't have the latest version of less (rest assured I'll
double-check) is a poor excuse. Is Puppy so dependent on other distros' repos that
its developers cannot be pro-active? By not being pro-active, PuppyLinux will always
stay behind.
-- Finally, I'll dispute your opinion that obviously useful utilities such as less, tree,
any type of locate, and the inclusion of the latest versions of the core GNU utilities
are open to subjective choice.
Why do other distros have them by default and we don't? Give me a good reason
why PuppLinux should be making computer life more difficult and complicated for its
users than the other distros.
I fought to have the real less included in Puppy, and I'll fight for the general concept
as well -- unless you guys manage to demotivate me completely about the Puppy.
Happy Easter nonetheless.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
xinput - is critical for getting touchscreen calibrated, but it doesn't work in regular pups! Jamesbond did explain to me once why it didn't work, but I can't find the thread! One of its depends needed recompiling with some active option!
But emsee ultra has tree, musher0 a true dpup wheezy with many up-to-date packages which are installed and remastered in! Give it a try!!!
But emsee ultra has tree, musher0 a true dpup wheezy with many up-to-date packages which are installed and remastered in! Give it a try!!!
I'd like to, stemsee. I just tried, but the download will take over an hour and htopstemsee wrote:xinput - is critical for getting touchscreen calibrated, but it doesn't work in regular pups! Jamesbond did explain to me once why it didn't work, but I can't find the thread! One of its depends needed recompiling with some active option!
But emsee ultra has tree, musher0 a true dpup wheezy with many up-to-date packages which are installed and remastered in! Give it a try!!!
indicates that the resources are maxed out at 100 % steady. I'm afraid that will be
too much for this old machine.
Could you not split the iso file in 4-5 chunks that we can rebuild locally, and upload
them elsewhere than on MEGA? I have to use Firefox with MEGA, and it's the
combination that's maxing the resources out.
BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)