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

[peebee]

Could you let me know at what stage you get asked if you want an uefi iso and I'll check into it and see if I can easily add that as an option in makepup, which is likely.
wiak

Lines 34&35 of _00build.conf set UFEI_ISO (sic) & G4DOS_ISO

+
grub2_efi64 must be "true" in /support/rootfs-packages.conf

[Billtoo]

I didn't edit any config files but when that pop up shows up in ./3builddistro-Z I must have clicked on the option to make a uefi iso,seems to me I've done that in the past and it had no effect.

[wiak]

Thanks, peebee and Billtoo. I'll look into it. Have any of you, or anyone reading this thread, any idea if woof-CE attempts to fulfill package dependencies as listed in, say, any of the Packages -*-* files? I'm wading through the code and note 0setup checks items in DISTRO_PKGS_SPEC-* do exist in the format-fixed, downloaded packet lists but haven't yet reached any code that resolves dependencies (tho haven't got far in my wading as yet). In practice, dependencies don't seem to get resolved for packages dropped into local-repositories for inclusion, which is a pity.


EDIT: I know there is CHECK_BINARY_DEPS= in _00build.conf but that doesn't seem to do it - at least not for packages dropped into local-repositories. I've already read some of the script code concerning that but I've already forgotten the details... but certainly what I've read didn't do what I would like.

I'll find out eventually if I don't get fed up reading code I expect...

wiak

[sc0ttman]

Thanks, peebee and Billtoo. I'll look into it. Have any of you, or anyone reading this thread, any idea if woof-CE attempts to fulfill package dependencies as listed in, say, any of the Packages -*-* files? I'm wading through the code and note 0setup checks items in DISTRO_PKGS_SPEC-* do exist in the format-fixed, downloaded packet lists but haven't yet reached any code that resolves dependencies (tho haven't got far in my wading as yet). In practice, dependencies don't seem to get resolved for packages dropped into local-repositories for inclusion, which is a pity.


EDIT: I know there is CHECK_BINARY_DEPS= in _00build.conf but that doesn't seem to do it - at least not for packages dropped into local-repositories. I've already read some of the script code concerning that but I've already forgotten the details... but certainly what I've read didn't do what I would like.

I'll find out eventually if I don't get fed up reading code I expect...

wiak

If you're feeling adventurous (masochistic) you could

* install Pkg,
* copy the relevant woof repo files to your ~/.packages/ dir, (if needed)
* add the matching repo entries to ~/.pkg/sources-all, (if needed)
* cd into the local PET dir in woof,
* and do

Code: Select all

pkg --update-sources # add ur new repos to the list!
pkg --workdir `pwd`  
for pet in *
do
pkg -ed $pet
done

EDIT: a bit safer, build the list of pets first, then do `pkg -ed "pet1 pet2 pet3"` ....

Either way should download (not install) the deps of each $pet into the current dir...

Until I implement a chroot type option in Pkg, that might (not!) work for ya...
(there will be caveats .. you might need to use --force if trying to get deps of pkgs already installed in ur host system, for example)

[Moat]

Also keeping Billtoo's suggestion in my head of looking into kernel-build automation, either as part of makepup (third tab maybe) or a separate script especially for that purpose ...

Don't know what I'm talking about, but could stemsee's auto kernel-compiling scripts be of possible value?

http://www.murga-linux.com/puppy/viewtopic.php?t=96723

Bob

[ally]

apologies for being a plum, I want to build a x64 xenial with keernel 4.4.35, I've downloaded to the huge kernel folder, I don't understand where I'm dragging the file to using the gui

ta

[Terry H]

Wooohooo, I'm sorta late top the party. Just did my first build. I'm posting from it now. Just a basic xenial64. This build system is fantastic. It took about an hour from scratch. Frugal install to my Desktop PC. Wonderful!

Thank you wiak for all the work you put in creating this puppy build system.

Now to have a play and see what i can build.

[musher0]

Hi guys.

Speaking of automated kernel building, I'd need a 4.1 32-bit kernel PAE
just about now!!! TIA.

I thought the one offered with the xenialPup-7.0.6_32-bits was PAE but it's not.

BFN.

[wiak]

apologies for being a plum, I want to build a x64 xenial with keernel 4.4.35, I've downloaded to the huge kernel folder, I don't understand where I'm dragging the file to using the gui

ta

Hi ally,

makepup gui uses:

dir_where_makepup_is_in/local-repositories/huge_kernels

It gets transferred from there into woof-out_*/huge_kernel/ by makepup script during the build and thus used.

An alternative, once woof-out_* is created via merge2out is to use the manual method described by Billtoo here:

http://www.murga-linux.com/puppy/viewto ... 692#965692

But just using the makepup gui to transfer to the folder opened by its 'kernel2add' button (i.e. which is what opens folder: dir_where_makepup_is_in/local-repositories/huge_kernels) is what I myself do.

wiak

[wiak]

Wooohooo, I'm sorta late top the party. Just did my first build. I'm posting from it now. Just a basic xenial64. This build system is fantastic. It took about an hour from scratch. Frugal install to my Desktop PC. Wonderful!

Thank you wiak for all the work you put in creating this puppy build system.

Now to have a play and see what i can build.

Thanks Terry,

But really, makepup is just a frontend to woof-CE (original written by BarryK and since forked and added to by some community members). So makepup is just my attempt to automate the already long-existing woof-CE build system and make it hopefully easy (or easier) to use, with one or two extras in terms of automating adding extra packages and alternative kernels.

wiak

[ally]

thanks wiak

I had the chosen kernel in the specified folder but I'm at a loss on how to select in to build?

I left the dialogue box alone and it pulled in a slacko kernel during a ubuntu build and I tried dragging the file to the dialogue box then the script got locked in a loop at select kernel

apologies, I still do no understand how I select my kernel

[musher0]

Where is this elusive "huge-kernels" repo, anyway?

[Terry H]

Wooohooo, I'm sorta late top the party. Just did my first build. I'm posting from it now. Just a basic xenial64. This build system is fantastic. It took about an hour from scratch. Frugal install to my Desktop PC. Wonderful!

Thank you wiak for all the work you put in creating this puppy build system.

Now to have a play and see what i can build.

Thanks Terry,

But really, makepup is just a frontend to woof-CE (original written by BarryK and since forked and added to by some community members). So makepup is just my attempt to automate the already long-existing woof-CE build system and make it hopefully easy (or easier) to use, with one or two extras in terms of automating adding extra packages and alternative kernels.

wiak

I am aware of how this is a front end to woof-CE. I appreciate the talents of BarryK with his creation of woof and all who have contributed to the woof-CE system. But I was just really pleased with how it simplified the process so much. I have had no success with any attempts at using woof or woof-CE. Your frontend is a game changer.

[wiak]

thanks wiak

I had the chosen kernel in the specified folder but I'm at a loss on how to select in to build?

I left the dialogue box alone and it pulled in a slacko kernel during a ubuntu build and I tried dragging the file to the dialogue box then the script got locked in a loop at select kernel

apologies, I still do no understand how I select my kernel

Hi ally,

I think I may (?) understand the problem you are having. I'm busy working on something else at the moment (and about to go out anyway) but I'll try it out myself later today or tomorrow. Looking at my makepup code and the underlying woof-CE support/huge_kernels.sh code, I believe all should be fine if only one huge kernel is being kept (or placed into) local-repositories/huge_kernels (the folder kernels2add opens when you click that makepup gui button). The simple act of putting only a single kernel into there indicates it is selected (so selecting any other kernel in the GUI should make no difference). In other words no selection should need to be done. However, if you happen to have other hugekernels stored in local-repositories/huge_kernels then there may be a problem because I have not accounted for that in makepup (as far as my rechecking the makepup code tells me). So I'll try it out too and see if I can fix that if the problem does turn out to exist in my test.

In the meantime, I suspect it may be a simple matter of deleting one line of code from makepup (but this has not been tried or tested by me yet...):

It's the line at or around line 677 in makepup script, which contains the following code:

Code: Select all

/read choice_k3/ c choice_k3='"$nHUGEKERNEL"' #wiak was: read choice_k3

I'm not absolutely sure (until I try it) but I believe that line is not required at all (I might be wrong!...) so should be deleted. Note that it is NOT enough to simply comment it out because it is actually part of the surrounding sed command so you cannot simply use sh comments in there. i.e. try just deleting that line cleanly - plain and simple. What should then happen is that while the woof-CE processes run in the terminal, at the appropriate moment it would stop, present a short list of the huge_kernels you have provided, and ask the selection question:

Code: Select all

echo "Please choose the number of the kernel you wish to use"

If you only provided one hugekernel then that question would be automatically bypassed anyway.

Anyway, if that turns out to be the problem you have been having I will find out lat er and try to fix that, which hopefully just means deleting that codeline I mention above. Doesn't effect makepup operation otherwise - just for this special case.

Cheers,

wiak

EDIT: I should mention that sometimes the kernel to use is 'forced' by the distribution creator using statement in their provided _00build.conf. For example, debian/stretch build forces use of huge kernel huge-4.1.38-stretch.tar.bz2 because ttuuxxx put the following code into the provided _00build.conf:

## Kernel tarball URL
## avoid being asked questions about downloading/choosing a kernel
KERNEL_TARBALL_URL=http://smokey01.com/ttuuxxx/WoofCe/kern ... ch.tar.bz2

For a case like that you also need to manually comment out that KERNEL_TARBALL_URL line in _00build.conf (can use makepup pause option to help there), but I don't think that is the problem you are having with the distribution you are trying to build (most other distro-builds don't try and force which kernel to use).

[ally]

thanks wiak

I will try again and report back

regards

[ally]

ok, still struggling

I've created a huge-kernel using stemsee's SUKK and placed it in local repositories/huge-kernel folder

running the script it does not pick up my kernel but downloads selection 29

what am I doing wrong?

[peebee]

ok, still struggling

I've created a huge-kernel using stemsee's SUKK and placed it in local repositories/huge-kernel folder

running the script it does not pick up my kernel but downloads selection 29

what am I doing wrong?

Is local repositories/huge-kernel linked back to woof_out****/huge_kernel ?

It needs to be....

Similar to packages-pet and packages-*** which are links

[davids45]

G'day wiak,

Confirming ally's result, I also tried the idea of having just one huge-kernel in the local repositories/huge-kernels directory (trying a Xenial kernel) but still only made a StretchPup with its 'in-built' one kernel option, this after editing the _00build.conf file found deeply buried in the woof-CE-testing directory as suggested earlier in this thread. No guarantee I did things correctly .

Can extra kernels in my huge-kernels directory be added to the --KERNEL list (with extra numbers, 30, 31, etc) with any effect? I'm impressed with peebee's ArtfulPup so would like to try this latest Ubuntu option if possible in makepup.

Thanks again for your continued input.

David S.

[musher0]

Hi ally.

Nothing, probably.

As for me, I didn't fight it.

In my xenial32 incarnation, I replaced the default vmlinuz and zdrv with
-- stemsee's kernel 4.1.2
-- manually
-- in the iso (with isomaster)
-- after wiak's automaton had finished creating the Pup.

The only thing you have to do is rename stemsee's
-- modules-something.sfs which in his kernel archive with
-- a valid zdrv name corresponding to the name of the main sfs,
-- for example: zdrv_xenial_7.0.6.sfs.

IHTH.

If that's the only thing that's left to do, IMO wiak doesn't need to alter his script!
To do so would be encouraging laziness in people!!!

BFN.

[ally]

I've just created a dedicated huge-kernel repo

http://archive.org/download/Puppy_Linux_Huge-Kernels

I'm going to try altering the script URL and give it another whirl

sorry peebee, I don't understand what you've written

I'll report back if it works