Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 16 Dec 2017, 07:11
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Run_woof AppDir
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [6 Posts]  
Author Message
woodenshoe-wi

Joined: 28 Jul 2017
Posts: 10
Location: Wisconsin

PostPosted: Thu 10 Aug 2017, 01:20    Post subject:  Run_woof AppDir
Subject description: Testers wanted
 

I have been working on enhancing the run_woof script and I think it's finished, but of course when trying to test for bugs they are always in the things you don't think to test. That is why I am now asking for help.

Prerequisites:
- A Linux system that has root or sudo access
run_woof should work with either bash or dash as /bin/sh

- Disk space in an ext2/3/4 partition
An arm/raspbian/stretch build takes at least 5GiB, the woof-CE README recommends 6-10GBs
Running Puppy Linux with a save folder on a partition with enough space might work, but I have not tested it and do not know if it would slow the process down running all the disk access through AUFS. A "full install" is not needed, I do my builds in a separate partition that I mount in a regular install of Puppy Linux.

- Download bandwidth
An arm/raspbian/stretch build has about 450MiB of packages downloaded in local-repositories, and if you are not running Puppy Linux you will also need to download a Puppy Linux iso and devx. Of course you can also be running one version of Puppy Linux and use a different version of Puppy Linux for run_woof, but if you want to run a 64 bit version of Puppy Linux with run_woof you need to be running a 64 bit kernel. Running a 32 bit version of Puppy Linux using run_woof with a 64 bit kernel works fine. (The version of dpkg-deb from older versions of Slacko Puppy can't process some of the newer deb packages. It has been fixed in slacko-6.9.9.9 but there seems to be a problem with gtkdialog using this version with run_woof)

- Time
Building takes hours.


Usage:

You can download run_woof from
https://github.com/puppylinux-woof-CE/run_woof

Click “Clone or download” then select “Download ZIP”

If you have already downloaded woof-CE, unzip run_woof in the same directory. (not inside woof-CE, just next to it)

If you have not downloaded woof-CE, run_woof will offer to download it for you.

If you are not running Puppy Linux you will also need to download a Puppy Linux iso and devx. Put them in the same directory as run_woof, (not inside run_woof, just next to it) and run_woof will find them automatically when you start run_woof. You can also select a different directory to look in for iso and devx files by selecting “other...” when starting run_woof. If you are running Puppy Linux, run_woof should find the version you are running, but you do need the devx too. If you don’t already have a devx you will have to download it and either load it into your running Puppy or put it next to run_woof.

run_woof is an AppDir, so if you are using ROX as your file manager just click on the run_woof (run_woof-master) directory to start it. If you are using a different file manager or running it from the command line, run the AppRun script inside the run_woof (run_woof-master) directory.



About permissions...

Puppy Linux normally runs as root so the following doesn’t apply, but if you are using a different version of Linux run_woof will use sudo to run it’s self as root. If you need to enter a password to use sudo you will be asked for it as run_woof is starting up. All files created from inside run_woof will be owned by root, including woof-CE (if you had run_woof download it for you), the local-repositories directory (and everything downloaded into it) and woof-out_* directories made by merge2out.



Overview of woof-CE:

Once run_woof has started the first step is to change directory into woof-CE and run merge2out

Code:
run_woof# cd woof-CE
run_woof# ./merge2out

This script merges woof-arch, woof-code
woof-distro, kernel-kit and initrd-progs to ../woof-out_*.
See README

-----------------
Host arch: x86     (The host is the machine you are running Woof on)
-----------------

Please choose the target target architecture.. (the target
is the machine in which the Puppy that you build is going to run):

1  arm
2  x86
3  x86_64
Type number of target architecture:


Select the target architecture, compat-distro and release version.
After this step all further commands are run in the ../woof-out_* directory, in my case ../woof-out_x86_arm_raspbian_stretch.

Code:
run_woof# cd ../woof-out_x86_arm_raspbian_stretch


There is a GUI,
Code:
run_woof# ./woof_gui


but most people just run the following scripts from the command line.

Code:
run_woof# ./0setup

This script will download the Puppy pet package lists and the package lists from the compat-distro and convert them into the Puppy package list format.

If you get any errors like
Code:
Checking that compat-distro pkgs specified in PKGS_SPECS_TABLE actually exist...
FAIL: nonexistent-package

it means that there is no longer a package by that name in the compat-distro package lists. Maybe libfoo8 was replaced with libfoo9 and DISTRO_PKGS_SPECS-<compat-distro>-<release> has not been updated yet.

Code:
run_woof# ./1download

Well, this does what it’s name says, it downloads all the compat-distro and pet packages listed in DISTRO_PKGS_SPECS-<compat-distro>-<release>
The first time it will take a while because it has to download a couple hundred MiB of packages, in the future it will only download any updated packages. If you are doing an arm build it will prompt you to download a SD image file. If you are building for Raspberry Pi I would recommend raspi-sd-1gb-skeleton-ext4_nojournal-8nov2016.img.xz it is the smallest and will write to the SD card fastest, it will be resized to fit the SD card on first boot.

If you run into errors that a package can’t be found and you haven’t run ./0setup recently, it could be that the package has been replaced with a newer version. Try running ./0setup again. If the package downloads but then says it failed and you are doing a deb based build it could be that the version of dpkg-deb is too old to handle that particular deb file, try a newer version of Puppy with run_woof.

Code:
run_woof# ./2createpackages

This script processes the packages and puts them in the packages-<pup-name> directory, in my case packages-raspup. It takes quite a while, writing a lot of files to the hard drive, but it only asks one question when the script is first started.

Code:
run_woof# ./3builddistro-Z

This is the script that actually puts everything together to make a new version of Puppy Linux. Depending on how much was already configured in the _00build.conf file it will ask various questions and when it is finished there should be an ISO file or SD card image file and maybe a devx sfs.

Due to a bug in 3builddistro-Z, SD card builds put the SD card image file and devx sfs directly in woof-out_* (which suits me just fine), while CD builds put the ISO and devx sfs in woof-out_*/woof-output-${DISTRO_FILE_PREFIX}-${DISTRO_VERSION}${XTRA_FLG}

Edit: clarify that most people don't use the GUI

Last edited by woodenshoe-wi on Fri 11 Aug 2017, 10:48; edited 1 time in total
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1362

PostPosted: Thu 10 Aug 2017, 05:19    Post subject: Re: Run_woof AppDir
Subject description: Testers wanted
 

woodenshoe-wi wrote:
I have been working on enhancing the run_woof script and I think it's finished, but of course when trying to test for bugs they are always in the things you don't think to test. That is why I am now asking for help.

Prerequisites:
- A Linux system that has root or sudo access
run_woof should work with either bash or dash as /bin/sh

- Disk space in an ext2/3/4 partition
An arm/raspbian/stretch build takes at least 5GiB, the woof-CE README recommends 6-10GBs
Running Puppy Linux with a save folder on a partition with enough space might work, but I have not tested it and do not know if it would slow the process down running all the disk access through AUFS. A "full install" is not needed, I do my builds in a separate partition that I mount in a regular install of Puppy Linux.

- Download bandwidth
An arm/raspbian/stretch build has about 450MiB of packages downloaded in local-repositories, and if you are not running Puppy Linux you will also need to download a Puppy Linux iso and devx. Of course you can also be running one version of Puppy Linux and use a different version of Puppy Linux for run_woof, but if you want to run a 64 bit version of Puppy Linux with run_woof you need to be running a 64 bit kernel. Running a 32 bit version of Puppy Linux using run_woof with a 64 bit kernel works fine. (The version of dpkg-deb from older versions of Slacko Puppy can't process some of the newer deb packages. It has been fixed in slacko-6.9.9.9 but there seems to be a problem with gtkdialog using this version with run_woof)

- Time
Building takes hours.


Usage:

You can download run_woof from
https://github.com/puppylinux-woof-CE/run_woof

Click “Clone or download” then select “Download ZIP”

If you have already downloaded woof-CE, unzip run_woof in the same directory. (not inside woof-CE, just next to it)

If you have not downloaded woof-CE, run_woof will offer to download it for you.

If you are not running Puppy Linux you will also need to download a Puppy Linux iso and devx. Put them in the same directory as run_woof, (not inside run_woof, just next to it) and run_woof will find them automatically when you start run_woof. You can also select a different directory to look in for iso and devx files by selecting “other...” when starting run_woof. If you are running Puppy Linux, run_woof should find the version you are running, but you do need the devx too. If you don’t already have a devx you will have to download it and either load it into your running Puppy or put it next to run_woof.

run_woof is an AppDir, so if you are using ROX as your file manager just click on the run_woof (run_woof-master) directory to start it. If you are using a different file manager or running it from the command line, run the AppRun script inside the run_woof (run_woof-master) directory.



About permissions...

Puppy Linux normally runs as root so the following doesn’t apply, but if you are using a different version of Linux run_woof will use sudo to run it’s self as root. If you need to enter a password to use sudo you will be asked for it as run_woof is starting up. All files created from inside run_woof will be owned by root, including woof-CE (if you had run_woof download it for you), the local-repositories directory (and everything downloaded into it) and woof-out_* directories made by merge2out.



Overview of woof-CE:

Once run_woof has started the first step is to change directory into woof-CE and run merge2out

Code:
run_woof# cd woof-CE
run_woof# ./merge2out

This script merges woof-arch, woof-code
woof-distro, kernel-kit and initrd-progs to ../woof-out_*.
See README

-----------------
Host arch: x86     (The host is the machine you are running Woof on)
-----------------

Please choose the target target architecture.. (the target
is the machine in which the Puppy that you build is going to run):

1  arm
2  x86
3  x86_64
Type number of target architecture:


Select the target architecture, compat-distro and release version.
After this step all further commands are run in the ../woof-out_* directory, in my case ../woof-out_x86_arm_raspbian_stretch.

Code:
run_woof# cd ../woof-out_x86_arm_raspbian_stretch


There is a GUI,
Code:
run_woof# ./woof_gui

which runs the following scrips. They can also be run from the command line.

Code:
run_woof# ./0setup

This script will download the Puppy pet package lists and the package lists from the compat-distro and convert them into the Puppy package list format.

If you get any errors like
Code:
Checking that compat-distro pkgs specified in PKGS_SPECS_TABLE actually exist...
FAIL: nonexistent-package

it means that there is no longer a package by that name in the compat-distro package lists. Maybe libfoo8 was replaced with libfoo9 and DISTRO_PKGS_SPECS-<compat-distro>-<release> has not been updated yet.

Code:
run_woof# ./1download

Well, this does what it’s name says, it downloads all the compat-distro and pet packages listed in DISTRO_PKGS_SPECS-<compat-distro>-<release>
The first time it will take a while because it has to download a couple hundred MiB of packages, in the future it will only download any updated packages. If you are doing an arm build it will prompt you to download a SD image file. If you are building for Raspberry Pi I would recommend raspi-sd-1gb-skeleton-ext4_nojournal-8nov2016.img.xz it is the smallest and will write to the SD card fastest, it will be resized to fit the SD card on first boot.

If you run into errors that a package can’t be found and you haven’t run ./0setup recently, it could be that the package has been replaced with a newer version. Try running ./0setup again. If the package downloads but then says it failed and you are doing a deb based build it could be that the version of dpkg-deb is too old to handle that particular deb file, try a newer version of Puppy with run_woof.

Code:
run_woof# ./2createpackages

This script processes the packages and puts them in the packages-<pup-name> directory, in my case packages-raspup. It takes quite a while, writing a lot of files to the hard drive, but it only asks one question when the script is first started.

Code:
run_woof# ./3builddistro-Z

This is the script that actually puts everything together to make a new version of Puppy Linux. Depending on how much was already configured in the _00build.conf file it will ask various questions and when it is finished there should be an ISO file or SD card image file and maybe a devx sfs.

Due to a bug in 3builddistro-Z, SD card builds put the SD card image file and devx sfs directly in woof-out_* (which suits me just fine), while CD builds put the ISO and devx sfs in woof-out_*/woof-output-${DISTRO_FILE_PREFIX}-${DISTRO_VERSION}${XTRA_FLG}


Hi Woodenshoe,

Trying to get my head around what is really being offered here. Can I take a stab at clarity, to see if this is what you (and this script) possibly means/does?

Normal woof-CE process build is summed up as follows:

1) git close the woof-CE into separate EXT 2/3/4 directory
2) cd there into "woof-CE"
3) run "./merge2out" in terminal in that directory
4) then cd ..//woof-out*
5) then run "./0setup" in terminal
6) then run "./1download" in terminal
7) then run "./2createpackages" in terminal
8 ) then run "./3builddistro-Z" in terminal

Am I understanding correctly that what you're trying to accomplish here is making a GUI-popup appear BEFORE before steps 5-8 are run above? A person does this (gets this GUI) by running
Code:
run_woof# ./woof_gui
in terminal. In essence, inserting a step between 4 and 5 above, to be able to have a clickable GUI process for steps 5 thru 8 instead of manually entering them into a terminal. Yes? If that is the case, it is a fine script----but what is really needed is work on making what goes on in steps 6-8 more easily available, or "easily" tweakable, for the builder to be able to customize what gets downloaded and inserted into his/her build. I.e, think in terms of desktop environments, browsers, word processors, email programs, etc and etc and such.

The woof-CE puppy-universe has fallen into this trap that they think having a person who attempts builds adding loads of stuff after the build completes (via the PPM)-------which usually requires the builder to run constant remasters------is somehow still a good idea. It was a good idea years ago, but not today. It is not.

Work needs to be done with woof-CE building to start bringing the "customization" inside steps 6 thru 8. I've done hundreds of builds, I customize the builds in steps 6 through 8, but to do so is such a hairy, godforsaken f#ckup process, rife with areas to make errors if you are forgetful and/or careless, that it is hard to accomplish full-customization for the build you want to do. For builds that you would like to offer here on murga and/or keep for yourself. This is true even if you are well-versed in the nuance of the build process. As things stand today, very few of us here do the woof-CE process, and there's good reason for that. Why do it? You know you're going to have to constantly remaster afterwards------so everyone just waits for the normal, several builders we have here to release something, then we go about remastering the heck out of those. No normal people who came to murga, even people versed in Linux, would want to attempt to mess with woof-CE as it stands today, and if they did, it would turn them off----unless they /arewere sick in the head & decide to keep doing it, which obviously 15-25 of us here are Laughing Laughing Laughing .

Anyhow, this is the problem the puppy woof-CE build process is facing. This script is a baby-step in the right direction. Thank you for that. But there also needs to be some big, adult steps taken (hope others are reading, like the woof-CE Gods & powers that be). You know, like what is happening in the DebianDog world here, with Fred's buildscript. It is a thing of beauty and ease and woof-CE should strive to attempt something like this. Try it, your jaw will drop at the ease of customizing things during the build---and it is only going to get better. You've got the FULL power of all debian repo(s), currently stretch-related, at your fingertips for customizing during the build process, not after. Contrast that with somehow, you do not have even an ounce of power to customize (without pulling your hair out--and, people gotta know, choosing a kernel is not customizing!) during a woof-CE build. I've only succeeded at fully customizing my own woof-CE builds through constant wasted hours, no countless weekends over the past year, teaching myself what works, what happens, why its so screwed up in some places that I've got to do this and/or that, etc, etc. But the larger question is why is the woof-CE build process even like this??? Dam#, it could be so, soooooo much more. And made accessible to all, with GUI clicking quality. But there is little if no attempt at this for the important stuff.

Anyhow, thanks for the work on this gui popping up the "steps" script---at least it saves people from typing three lines into the terminal when doing a build process. But if I am mistaken, and this script does something else---like allows customization of what goes into builds, then please tell me and I will download & test this script immediately Wink
Back to top
View user's profile Send private message 
woodenshoe-wi

Joined: 28 Jul 2017
Posts: 10
Location: Wisconsin

PostPosted: Thu 10 Aug 2017, 12:02    Post subject: Woof_gui  

I definitely agree that woof-CE is a "work in progress" and not the easiest to use, but then again I first discovered Puppy Linux years ago from a link at the "Linux From Scratch" project, so I might not be a typical user...

I can't take the credit for the woof_gui script, it has been in woof-CE since the initial commit. I just wanted to bring it to the attention of any new builders that might prefer using it, but I don't really use it myself.

The original run_woof script was written by dimkr/Iguleder as a command line script to allow woof-CE to be run in a non Puppy Linux disro. When I saw that someone was trying to do a woof-CE build from Ubuntu I thought run_woof might be the best solution but I wanted to try it out myself before I recommended it to anyone.

I basically wrote a gui for the run_woof script, not woof-CE. And because some people don't like using git, I added the ability to clone and update the woof-CE repo when run_woof starts.

Unfortunately this doesn't solve any of the shortcomings of woof-CE except being able to run in Ubuntu now...

I was trying to write a basic overview of the woof-CE process, everything that starts with 'run_woof#' is a command you would type into the terminal that run_woof pops up, not part of run_woof. If you have any suggestions for making the instructions clearer or found any bugs in run_woof I would be interested to hear from you, but I'm not asking you to test it if you don't want to because it doesn't fix any of the problems you mentioned.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 375
Location: not Bulgaria

PostPosted: Sun 27 Aug 2017, 23:15    Post subject:  

Please see here (along with the eight posts following the initial one):

http://www.murga-linux.com/puppy/viewtopic.php?p=965690#965690

Not sure if you are responsible for github woof-CE-testing commit:

Quote:
wdlkmpx merge2out: delete EMPTYDIRMARKER in woof-out../huge_kernel


Unfortunately, the erroneous commit just prior to that causes a lot of people to waste many many hours of time (since makepup is a new project with considerable interest)... I will try to use the rationalise branch in my makepup project, since I appreciate using "testing branch" can be risky, though will take me some time to make that move.

I'm just trying makepup with the currently latest merge2out commit in the hope that that does indeed fix the download kernel issue that resulted from the previous commit (EDIT: it does).

wiak
Back to top
View user's profile Send private message 
woodenshoe-wi

Joined: 28 Jul 2017
Posts: 10
Location: Wisconsin

PostPosted: Mon 28 Aug 2017, 01:11    Post subject: GitHub username  

My GitHub username is woodenshoe-wi.

wdlkmpx is jlst on the forum.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 375
Location: not Bulgaria

PostPosted: Mon 28 Aug 2017, 17:45    Post subject:  

All good now jlst. It was my fault anyway for using woof-CE-testing by default. Now using default rationalise, though I don't actually know what rationalise is (but have seen it used recently by forum members building from woof-CE manually - most recent build work I've seen on the forum seems to use either testing or rationalise and not master branch).

cheers, wiak
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [6 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0740s ][ Queries: 14 (0.0116s) ][ GZIP on ]