Auto-build a Puppy iso; single script with optional gui

[rufwoof]

Booting that build and it didn't like vmlinuz. Swapping that out for my existing one and it booted OK ... to what looks to be like the new style default desktop layout (that looks somewhat like xfce i.e. a central bottom panel rather than one that spans the entire width of the screen).

Working to a degree, but not functional (no firewall option available, try to change resolution and it black-screens ...etc). But as far as the script went everything seemed OK. It did build a 7.0.8.4 Xenial iso whereas my last manual Xenial build built a 7.0.8.5-efi iso so I'm not sure why it went for a earlier non uefi version (perhaps again something down to woof-ce rather than the script ???).

[wiak]

perhaps again something down to woof-ce rather than the script ???.

Almost certainly (until shown/proved otherwise )

I think that Debian Stretch woof-CE stuff was started by ttuuxxx with contributions by others (musher maybe, belham2) but from reading that thread there were some 'disagreements' and I don't the final woof-CE stuff was finalised (indeed much of the work seemed to be done as remasters with only initial build from woof-CE). I think a lot of that has been going on with woof-CE builders (i.e. a lot of the work still being completed by remastering). Better, I think, if they learned how to complete the work on woof-CE itself and then builds made by that could be complete and already polished. Also that would help with woof-CE development and bug-fixing. It is a pretty good system though - specially when the possibility of using stock Debian kernels and so on is completed (code for that started but not yet integrated into the build system).

wiak

[wiak]

Do you know whether if you leave local-repositories will the next run pull down any changed versions of those i.e. later versions of libs/programs if any are available?
...

with the intent that running that periodically will be like a puppy that is upgraded to all of the latest changes and security fixes.

Do you know whether woof-ce is automated to pick up the latest versions of Ubuntu/Xenial changes i.e. if they change xxxx.v1 to xxxx.v2 will that automatically be reflected into woof-ce or does it require some manual intervention by the woof-ce maintainers to adjust its database to point to the later version?

Hi again rufwoof,

No, I don't know, but I'm also interested in knowing the above, and for similar reasons, so I'll try and take some time to look into that especially since I'm becoming familiar with some of the woof-CE structure/scripts now.

May take a while before I know more though, which is one of the reasons I'm not working towards a further 0.0.3 makepup release yet - worth sorting out a few of these details first.

wiak

[wiak]

I've set the script to point to testing by editing it to contain

WOOFBRANCH="woof-CE-testing"

and running it using

# Xenial 64 bit ubuntu with kernel 4.9.15 also builds devX
./makepup -t 3 -d 5 -r 28 -D

(as per your handy reference http://murga-linux.com/puppy/viewtopic. ... 543#965543)

rufwoof, I trust you know, you could alternatively have included option:

Code: Select all

-w woof-CE-testing

on the commandline to point to that branch? Or alternatively to edit makepup.conf to do that instead?

All the current makepup options can be listed with:

Code: Select all

./makepup --help (or makepup -h)

Any of these methods work of course but for the released version of makepup I'll leave default script not pointing at testing branch so that default builds are more likely to work (makes no difference usually to the iso produced [since the distro-version builders haven't been making further commits for a longtime I think] - only to the internal woof build scripts which are being refined over time: mainly it seems by jlst).

wiak

[wiak]

G'day wiak,

I replaced version 1 with 1.0.1 but left the previously created directories in place.
Ran makepup and it seemed to go through to the end. However terminal terminal (screenshot) does indicate something couldn't be done so the program exited?

Hello again David,

I have now tried running makepup from a 32bit Pup (current slacko32 ver 6.3.2) to build a 32bit (x86) target, the default provided by simply using command:

Code: Select all

./makepup

with no optional arguments.

I've tried that from both an empty directory (aside from the makepup script itself) and also as a second run leaving all the previously created directories in place. Both runs completed successfully. So, sorry, I can't understand thus far why you are getting those error messages - all working fine for me, and seemingly for others. If you have the chance to try on another computer or maybe use a different Puppy as the host build system is all I can suggest off the top of my head at the moment. What Puppy are you running the script from at the moment? woof-CE documentation itself suggests you should use a reasonably current one. You do NOT need the devx loaded since makepup downloads a zip file of woof-CE build environment and that is enough to build the iso and frugal files (EDIT: however, you may sometimes get a smaller iso if build done with devx loaded on host - depends if any binaries could be stripped - the strip program is in devx).

Yes, once the build is complete, the frugal files for booting should be found in sandbox3/build and the iso (assuming the default makepup build) currently in woof-output-slacko-6.9.9.9

Tomorrow I plan to try making a build with makepup on my old Pentium M, 1 GB ram non-PAE laptop system (have to locate it from the bottom of my cupboard somewhere first though...).

wiak

[rufwoof]

Thanks wiak

[peebee]

Do you know whether if you leave local-repositories will the next run pull down any changed versions of those i.e. later versions of libs/programs if any are available?

Yes - latest versions will be downloaded by ./1download as long as repositories have been updated by ./0setup....

./2createpackages can then be run selectively on just the updated packages.

This makes building an updated system very fast (c. 15mins for LxPupSc).

[rufwoof]

Thanks peebee.

Just built a 64 bit Xenial from woofce-rationalise (I hard coded makepup values to ...

Code: Select all

# Default config:
nTARGETARCH="3"              # i.e. target is x86 (1=arm, 2=x86, 3=x86_64)
nCOMPATDISTRO="5"            # i.e. distro is slackware (1=debian, 2=devuan, 3=slackware, 4=trisquel, 5=ubuntu)
nCOMPATVERSION="2"           # 2 is xenial (1 trusty)
WOOFBRANCH="woof-CE-rationalise" # woofbranch, e.g. woof-CE-testing
#WOOFBRANCH="woof-CE-testing"
nHUGEKERNEL="28"             # i.e. hugekernel to use huge-4.9.15-xenialpup64.tar.bz2
interactive="false"          # "true" means: Require user input during the build
gui="false"                  # "true" means: Use gui frontend (wiak remove comment when done: gui not yet implemented)
keep="false"                 # "true" means: Keep previous woof download files and directories
pause="false"                 # "true" means: pause makepup script just after merge2out routine to allow package selection changes
DEVX="true"                 # "true" means: Create DEVX sfs

Built and booted fine.

Sound, internet, change resolution, firewall, savefolder ...etc. all working as expected. Only problems I've found so far is that the drives top right unmount hot area doesn't work (just opens the drive in rox) and using pupclockset to change the trays time format to a custom %a %d %b %R ... and then saving, had the top of screen panel/tray lose its settings to leave just setup and jwmdesk icons only in that panel ... and no minimised windows shown either (I'm having to use Ctrl-Alt-Tab to switch between windows as I post this).

[wiak]

Yes - latest versions will be downloaded by ./1download as long as repositories have been updated by ./0setup....

./2createpackages can then be run selectively on just the updated packages.

This makes building an updated system very fast (c. 15mins for LxPupSc).

He Peebee, rufwoof and anyone reading,

Thanks for that info, Peebee. It's especially useful to have such input from an experience Puppy builder like yourself. I can easily add a --update/-u switch to makepup to modify its behaviour for update packages use. Is there a way provided by 1download to indicate which packages have been updated such that I can automate 2createpackages to selectively operate on just these packages in terms of update? A step by step example of how you go about such an update, including how you use 2createpackages to selectively operate would help me automate these mechanisms via makepup function.

Otherwise I can use modification times to local-repository files as a possible mechanism but still need to know how to use 2createpackages for selective operation.

Such modifications to makepup are likely to be made later anyway since other improvements still in progress.

wiak

[rufwoof]

I've just run makepup for a second time, leaving everything from the first run (that took about a hour) as-is, and the second run took 48 minutes (and seems to have built the iso and devx ok). Seems about right as I'm on a 100Mbs link so I guess around 12 minutes of download time for the first run not being required in that second run.

[wiak]

I'm on a 100Mbs link

You are fortunate, rufwoof. I live in a rural area that only has very slow broadband (around 0.5Mb download speed...) so each makepup build test takes a while - though still less than a couple of hours even when using an empty local-repository...

wiak

[peebee]

Is there a way provided by 1download to indicate which packages have been updated such that I can automate 2createpackages to selectively operate on just these packages in terms of update?

LOL - I've got a tweak to 1download that I will submit to woof-ce tomorrow for precisely this....

[peebee]

I've just run makepup for a second time, leaving everything from the first run (that took about a hour) as-is, and the second run took 48 minutes (and seems to have built the iso and devx ok). Seems about right as I'm on a 100Mbs link so I guess around 12 minutes of download time for the first run not being required in that second run.

Most of that is probably a repetition of a complete 2createpackages that wasn't really needed....

[rufwoof]

Most of that is probably a repetition of a complete 2createpackages that wasn't really needed....

Yes peebee. I just sat and watched it do all of that. Just a test really to see if I got the same OK outcome result for Xenial as wiak got for Slacko when repeat running without having cleaned things out.

Should also say I'm running a AMD Phenom x4 2GB that's around 10 years old so my timings are relative to that. Using a ext3 format partition (otherwise empty). [I like ext3 as that's a more flexible choice i.e. BSD can rw to that, but as though ext2 (no journaling), whilst it can be mounted as though a ext4 (for even better recovery/data safety, however ext3's stability/recovery is pretty good anyway IME)].

[rufwoof]

That second Xenial 64 build works fine. Looks like a lot of work going into the next Puppy and there are issues with using the menu based configuration tools, however reverting to a manual edit approach of jwm files and otherwise its working really well.





... and with makepup tracking updates is just a click away

[recobayu]

This is what i got. I make Dpup Stretch using this makepup.
I must download firefox from ppm first because the defaultbrowser can not walk. Very Nice, Wiak and Woof-CE Community..
Thank You.

[wiak]

Thanks for your report recobayu!

Glad to hear makepup script has worked for you making a Dpup Stretch.

Could you kindly post the makepup commandline you used since that info proves to be a useful resource, so is always useful in reports if only for confirmation of makepup commandline options used.

It's also good to know specification of the build machine you used, Puppy host distribution (name, version and whether 32bit or 64bit) and whether 32bit or 64bit target distribution. An indication of the time it took for the build to complete would also be great. A lot to ask, I know....

For your commandline, I'm presuming:

Code: Select all

./makepup -d 1 -r 1

with no other commandline options added?

Thanks in advance if you can provide any of that info!

wiak

[recobayu]

Code: Select all

./makepup -d 1 -r 1

Yes. But it is very loongg time to wait it.
1270 items in folder packages-deb-stretch, and
153 items in packages-pet.

My suggestion is, There is better if after make an iso (or remaster from that iso) and devx, someone upload that iso so we can download it directly.

I copied my jwmrc-tray from xenial to change the tray full horizontall.

here is the iso (238M):
https://drive.google.com/file/d/0B139JQ ... sp=sharing

[wiak]

Code: Select all

./makepup -d 1 -r 1

Yes. But it is very loongg time to wait it.
1270 items in folder packages-deb-stretch, and
153 items in packages-pet.

Hi recobayu,

Yes, takes a long time, though not quite so long if you need to rebuild/update later and that is being worked on.

However, makepup is basically a frontend for woof-CE to make that a one-click easy operation and the purpose of woof-CE is to help easily produce an initial Puppy iso by anyone who feels like it - people can thereafter refine what they produce for their own use or to publish as an iso later. It all depends therefore what you want to use makepup/woof-CE for - some will want to simply use it to build an iso for their own use so the time to build is not so important then.

Thanks again for you report - it is good to see woof-CE being used and successfully. And thanks for sharing your iso for whoever wants to try it.

wiak

[wiak]

Is there a way provided by 1download to indicate which packages have been updated such that I can automate 2createpackages to selectively operate on just these packages in terms of update?

LOL - I've got a tweak to 1download that I will submit to woof-ce tomorrow for precisely this....

Hi peebee,

re: looking at your woof-CE Pull request:

I see. So your plan is to have the name only of any new package downloaded stored under status/download_list and then use that list with 2createpackages to minimise the amount of work it needs to do? Maybe...

However, I've not quite worked this out yet, but the code in 2createpackages seems to have an option to only create changed packages (it appears to use run_findpkgs to sort out what has been changed based on md5sums...). 1download script uses the exact same run_findpkgs routine as far as I can see.

The option I'm taking about is:

Code: Select all

2createpackages CHANGED_ONLY

If that is correct, then your proposed 1download change would seem unnecessary. But I haven't had time to check if using that CHANGED_ONLY option with 2createpackages does what I think it does... I'll try it tomorrow. If it does then it is very easy for me to add a --update/-u switch to makepup to include that facility.

wiak