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

[666philb]

does bionic work?

[wiak]

That would help greatly 666philb and might well lead to a makepup fix.

I only had a ridiculous 35 MB (!) left on my laptop - hence my resorting to woof-CE builds to a slow external usb HD. However, this morning I've been moving things around so now have 5 GB free on main harddrive so hoping that proves to be enough and should speed things up a lot for me (except for the rural broadband speed issue).

wiak

[wiak]

straight woof-CE-created bionicpup64 booted okay but with the icons missing and menu not starting up apps as far as I remember - I'm not in that now since preparing for a new build.

@666philb I don't know if something odd simply happened during the long build which is why I'm hoping for test results from others - your test would be the best of course.

[wiak]

"/usr/local/apps/ROX-Fler/ROX"
(made similar changes to other users)

EDIT: Drat - just noticed the most recent build I made (via woof-CE scripts and not using makepup) was infact a XenialPup64 (I pressed wrong number at the terminal...). Oh well, currently using makepup to build a BionicPup64... but makes comparison tricky... and slow build since all packages need downloaded 'again'...

Thanks for you comments s243a. That link is already correct in the builds I've tried. I've since made a new woof-CE build (without using makepup) of BionicPup64 (using the testing branch I downloaed yesterday); EDIT: per other EDIT above, was actually a XenialPup64 build. I note that the default background is dark grey but I made it a different image this time so desktop background does actually seems to work ok. However, the icon images certainly still do not appear.

I note that there is no gtk-update-icon-cache program on the (XenialPup64) system (which was one of the error messages), or at least I couldn't find it...; I do know that would mean that if I installed my own dotpet weX program, its icons couldn't be found (since in that dotpet I call up gtk-update-icon-cache). That may or may not be the problem with the woof-CE build for BionicPup64 (not sure if same for XenialPup).

Oh, I also note error message still in ERROR-2CREATEPACKAGES:

Code: Select all

ERROR: 'diffutils' package does not exist.

I'll now attempt another makepup build of the same since my harddisk space proved large enough... Then I'll compare the difference.

wiak

[wiak]

Okay, so now build BionicPup64 using makepup. Iso was created but result was no Rox pinbrd - most everything else seems to work but maybe not rox filer either (I'll have to check that later). I did check in /root/Choices and found there was no ROX-FILER directory... Note that gtk-update-icon-cache binary was on that system though, so nothing to do with that in this case anyway I guess.

So I'm currently suspecting something to do with rox-filer, but I could well be wrong. I note that the dotpet for that is xz compressed, though I presume that isn't a problem? Anyway, seems to be more to do with the configs or at least that missing ROX-FILER directory...

Oh well, I'm going to try making new BionicPup64 again now but without using makepup (just woof-CE scripts) so that I can compare any difference.

wiak

EDIT: Just a note for myself really. I think straight woof-CE build making okay but makepup failing to take root/Choices/ROX-FILER stuff at least out of rootfs-packages into sandbox3 when 3builddistro-Z is running. I'm just guessing from what I see as terminal output as woof-CE scripts running. But I'll take a close look at the 4builddistro-Z script to see where/how that bit is done to see if makepup missed something in something or other that may have changed upstream in woof-CE scripts.

[s243a]

Note that gtk-update-icon-cache binary was on that system though, so nothing to do with that in this case anyway I guess.

was the "/root/.icons" folder there and did it have at least one subdirectory (or symlink to a sub-directory) that contained an index.theme file? Also I think the name of the icon theme might have to match the name of the subdirectory in the .icons folder.

So I'm currently suspecting something to do with rox-filer, but I could well be wrong.

redirect both the standard error and standard output to a file. If you put the following in the files I think it redirects all output streams to a log file:

Code: Select all

exec &> >(tee -a "$log_file")

https://unix.stackexchange.com/question ... -same-time
and if you want more output you can put a "set -x" before the above statment.

Anyway, I have a long shot fix for you:

Code: Select all

cd /usr/share/rox-filer
ln -s rox-filer ROX-Filer
    
cd /usr/bin
ln -s rox-filer roxfiler    

I did this in my attempted build of a TazPup64. I thought that the rox-filler executable might be named differently in the puppy package than the tazpup package. However, maybe the name of the executable changed in more recent versions of rox.

I note that the dotpet for that is xz compressed, though I presume that isn't a problem? Anyway, seems to be more to do with the configs or at least that missing ROX-FILER directory...

Oh well, I'm going to try making new BionicPup64 again now but without using makepup (just woof-CE scripts) so that I can compare any difference.

wiak

[wiak]

Yes, at the moment s243a I'm noticing that woof-CE script seems to have built the sandbox3 ROX-FILER stuff correctly. Makepup's on-the-fly mod of the relevant woof-CE script seems to be missing something. I'm not trying to patch the iso makepup is producing, rather I'm trying to find the error in makepup's on-the-fly mods to that relevant 3builddistro-Z script. I could patch the result to make it work, but that's not my goal. So now I'll test the woof-CE build to double-check that one is okay, and then I'm going to look carefully at 3builddistro-Z mods that makepup makes to see what is going wrong (assuming that is the script where makepup is messing things up...).

wiak

[wiak]

Good news for woof-CE builders! My test build of BionicPup64 seems to be fine (didn't use makepup for this). Posting from the build now. My earlier XenialPup64 woof-CE only build did have some issues though with icon images not appearing - that's not makepup issue.

Unfortunately for me...!... that means makepup is broken somewhere, which isn't surprising since I haven't been keeping up with woof-CE changes...

Anyway, now I need to find where makepup has messed up - it won't be much, since only really ROX pinboard related stuff - but may or may not be easy for me to spot. But like I said in posts above, I have some clues... and will report back later with success or failure...

wiak

[666philb]

hi wiak,

i've had a look, the problem with your makepup and bionicpup64 is that bionicpup64 needs rox_config="true" setting in /support/rootfs-packages.conf
you may want to look at your version of that file as there's duplicate contradictory entries in it. (probably xenial and tahr need it setting to true as well)

i've fixed the icon issue in xenialpup64 .. this was caused by /usr/sbin/icon_switcher inside the z_xenialfix64.pet which was one of the scripts i had thought i had removed.. it is now.

note that i've made some changes in the z_fixes.pets for xenial & tahr to bring it into line with modern woof and the new location for rox mimetypes in /etc/xdg/rox.sourceforge.net so you will need to delete those and re-download them.

also there's a couple of recipe fixes for the xenials commited to woofce, so you may want to get the latest testing (updated llvm and add libqpdf21 for cups.

as for xerrs.log errors in xenial. i believe these are mostly cause by packages being compiled against older version of libs probably glib (ubuntu have updated lots of libs since xenialpups release).
recompiling geany, rox etc in the new xenial might fix that (but i'm not doing that :p).

[wiak]

hi wiak,

i've had a look, the problem with your makepup and bionicpup64 is that bionicpup64 needs rox_config="true" setting in /support/rootfs-packages.conf
you may want to look at your version of that file as there's duplicate contradictory entries in it. (probably xenial and tahr need it setting to true as well)

i've fixed the icon issue in xenialpup64 .. this was caused by /usr/sbin/icon_switcher inside the z_xenialfix64.pet which was one of the scripts i had thought i had removed.. it is now.

Thanks phil, I'll do a rebuild using makepup today and taking your comments into account, double check and hopefully make all things with makepup well. Should be simple enough based on your comments above. More generally, when a non-makepup build works and a makepup build doesn't, it is a matter of doing a quick diff between the makepup 'modified' versions of woof-CE scripts against the original, which is what I was going to do today and still will - but first I'll rebuild BionicPup64 using new dowload of testing.zip from woof-CE github.

I'm a bit slow fixing makepup because I'm mult-tasking just now: working on dropbox client installs (official and from the forum here) for my partner on another machine (official client giving me some problems...) and also working on void linux installation matters on a third machine I have running alongside. I'm not too great at such multi-tasking since my brain doesn't then focus long enough on any one issue...

wiak

[wiak]

@phil:

Ah, okay! Since makepup has no ArtificialIntelligence, it cannot know whether rootfs-packages.conf-backup is to be used in the build or not for its attempted purpose of doing an unattended build.

The problem is that woof-CE supplies rootfs-packages list not as support/rootfs-packages.conf but rather as rootfs-packages.conf-backup, which doesn't actually get used unless human intervention renames it! That makes makepup's attempt at unattended build somewhat difficult... I obviously realised that when I wrote makepup because I did put a checkbox in Advanced tab options for 'allow pop-up "choose extra rootfs packages"'.

(If I remember correctly, though have to still check)It is that gui, when it pops up, that then writes/creates-new the rootfs-packages.conf that turns out to be needed for BionicPup64 case. So nothing wrong per se with makepup - just need to click that advanced option before making BionicPup64 build. But why??! cannot woof-CE supply the file rootfs-packages.conf rather than a needing renamed rootfs-packages.conf-backup when the distro builder wants that to be used???

As things stand, in 3builddistro-Z script the user has to perform a Ctrl-C and rename that file (removing -backup part of extension) to avoid getting what should often be unnecessary pop-up). Makepup gets round that Ctrl-C need by generating its own rootfs-packages.conf list, but not everything that is included as possibilities in support/rootfs-packages directory of course. Problem is, without AI it cannot determine what the distro builder wants to use (that is what support/rootfs-packages.conf is for, but alas it is supplied needing renamed from rootfs-packages.conf-backup... But please, it should be somehow supplied not needing that renaming... (or the pop-up...). The code I'm talking about in 3builddistro-Z.

EDIT: Though the issue is really caused by code/idea in merge2out, I think, since that's where rootfs-packages.conf appears to be first created with extension .conf-backup (in some code I see by peebee "to avoid checkbox GUI"). I haven't yet checked what happens to that in terms of what the actual distro builder wants. Yes, I think it is that peebee code that is my issue... I realise of course that unattended build wasn't part of woof-CE design, but I really don't think that conf-backup mechanism is a good one (certainly a pain for makepup....). Rather would be better at that merge2out stage to create rootfs-packages.conf itself? (not rootfs-packages.conf-backup, and think of other way to get optional pop-up for re-selection. Having to break out with a Ctrl-C (as now in builddistro-Z) is ugly (though understandable in the circumstances of current script code) and has these consequencies makepup is facing: EDIT: but maybe fine afterall if my post a couple of posts down is correct about DISTRO_PKGS_SPECS-ubuntu-bionic since woof-CE build did work, just not the makepup one...

In merge2out:

Code: Select all

# new to avoid checkbox GUI; idea from peebee. See 3builddistro-Z
(
cd ${WOOF_OUT}
rm -f support/rootfs-packages.conf-backup 2>/dev/null
ls rootfs-packages|while read pkg;do
	echo -e "$pkg=\"true\"" >> support/rootfs-packages.conf-backup
done
)

[end EDIT]

I guess I'll have to raise an issue on woof-CE github with suggestion how to better do this.

Code: Select all

if [ ! -f support/rootfs-packages.conf ];then
	echo
	echo "If you know what packages you want included from rootfs-packages
you can bypass the checkbox GUI by renaming 

'support/rootfs-packages.conf-backup'

to

'support/rootfs-packages.conf'

and edit it to include your customised package list.

You can CTRL-C out of this script and try it right now if you wish
or hit Enter/Return to continue."

	read carry_on

	for d in $(ls rootfs-packages)

Meanwhile, looks like maybe nothing wrong with makepup code itself - just need to check box for rootfs-packages pop-up gui in Advanced options prior to attempting the build. I'll check that now with another build using makepup. Of course maybe I've misunderstood the issue or other things have also gone wrong, but I'm hopeful all will be well this time.

wiak

[wiak]

Come to think of it though (looking at the woof-CE and makepup code again), why is it necessary to manually rename support/rootfs-packages.conf-backup for a BionicPup64 build since the gui popup code looks at DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} and should pick that rox_config config is need (EDIT: oh... it doesn't though, or does it? - so I'm not sure yet what goes on here). I have to look more into that, in case something else is wrong or changed comparing pop-up code in 3builddistro-Z compared to that mechanism in makepup.

wiak

[wiak]

Surely this was the error in provided woof-CE BionicPup64 recipe phil:

DISTRO_PKGS_SPECS-ubuntu-bionic

Code: Select all

...
yes|rox-filer||exe,dev,doc,nls
no|rox_config||exe,dev,doc,nls

That wouldn't be a makepup issue but a woof-CE github recipe issue if so. It does look wrong to me.

With that fixed upstream on woof-CE, all the other stuff probably fine?

Except, I seem to be missing something in my understanding since main woof-CE build of BionicPup64 did work so rox_config was being handled somehow despite above 'no'

I note that you've fixed the xenial diffutils error in woof-CE recipe now, phil, but I can't understand why it shouldn't be yes|rox_config for bionicpup64.

wiak

EDIT: This builddistro-Z code for popup seems to be what fixes rox_config to true:

Code: Select all

			*)
				if grep "yes|${d}|" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} ;then
					state=false # don't overwrite user chosen specs
				else
					def=true
				fi

But if pop-up not run then with BionicPup64 recipe as it is then human intervention to rename rootfs-packages.conf-backup to rootfs-packages.conf seems to be necessary. But surely DISTRO_PKGS_SPECS-ubuntu-bionic is actually the culprit here and needs fixed to say yes|root_config rather than 'no'.

[wiak]

Please refer to my immediately above post.

I have since made a makepup build of BionicDog64 after checking the advanced makepup option to allow rootfs-packages popup gui. The build was successful (booted and all Rox stuff seems fine - posting from it now), so it does indeed seem that nothing is wrong in makepup itself.

Problem is, it seems that pop-up needed to be allowed because, it seems to me, no|rox_config in DISTRO_PKGS_SPECS-ubuntu-bionic is wrong. It should surely be yes|rox_config. I may be wrong, but have raised the issue on woof-CE github for fix or explanation there. Alternatively, the mechanism that employs a rootfs-packages.conf-backup could be changed to allow distro author to make actual required rootfs-packages.conf without human intervention (ctrl-C) that would apparently currently be needed to rename that file to rootfs-packages.conf (in order to avoid that pop-up).

Anyway, unless I receive comments to the contrary, I will now finally (shortly after final small check and a cup of coffee or three) re-upload makepup latest version (only changes are those small filter alterations suggeted by rerwin for pets2add - I have not endeavoured at this stage to tidy up the official repo entries concerned, but that doesn't stop build working. I may leave extra dev work on makepup to others shortly (and hopefully they will also incorporate the use of sc0ttman's pkg program for pets2add/pkgs2add type mechanisms - tho of course woof-CE github should actually replace its own pkg add mechanisms with similar use of pkg).

EDIT: Actually, I might make an internal makepup fix that will also leave rox_config as 'yes', though really I feel the DISTRO_PKGS_SPEC is the place that should really be done (so my change would just cover that having been missed). [EDIT2: Nah, that current woof-CE mechanism seems wrong to me]. I am a bit confused with that pop-up code though - it seems to ignore the no|rox_config entry in existing bionicpup64 DISTRO_PKGS_SPEC and force it to state yes in the pop-up... what's the point of that, or am I missing something? On the basic of that confusion I think I may just post current makepup as it is, since it does work (just remember to check box to allow rootfs-package gui popup selection for now); I'll then briefly experiment with modified makepup and upload that as newer version if it works... (the pop-up code has been changed since makepup written so that could be reflected in makepupextraconf function).

wiak

[wiak]

Note that I also doubt this woof-CE github code change made some time or other is right:

builddistro-Z code for popup seems to be what fixes rox_config to true:

Code: Select all

			*)
				if grep "yes|${d}|" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} ;then
					state=false # don't overwrite user chosen specs
				else
					def=true
				fi

It used to be:

Code: Select all

    *)
      if grep "|${d}" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} |\
        grep -q '^yes' ;then
          : # don't overwrite user chosen specs
      fi
    ;;

Is it not the case that the newer code is in fact overwriting user chosen specs in DISTRO_PKGS_SPECS via def=true? I'm not sure since haven't studied the code enough as yet, but I wonder about it... At least, as written it is overwriting 'no' entries surely? I can no longer remember the difference between state=true and def=true; I'll have to re-read some of the code to work that out again... I think 'state=false' just means not being able to select that checkbox whereas def=true ticks it?; in which case 'no' entries would be getting changed to 'yes' and thus defeating DISTRO_PKGS_SPECS config instructions (why???).

wiak

[wiak]

So, after many days/hours of solid tests/woof-CE faultfinding, have now uploaded makepup ver 0.1.9 (with no makepup fault found). (But woof-CE devs, please see the immediate posts above this one concerning some issues I had with woof-CE builds/recipes).

Only a minor change:

## 0.1.9 implemented filter fix suggested by rerwin: http://murga-linux.com/puppy/viewtopic. ... 79#1022079

The version of makepup works. But depending on the recipe for the distro you want to build, as things stand with current woof-CE github code, you may need to check the box in makepup advanced options 'allow pop-up "choose extra rootfs-packages" gui'.

In this current release, I have not addressed the following perfectly valid suggestion for improvement:

http://murga-linux.com/puppy/viewtopic. ... 79#1022079

Though I am not retiring from Puppy forum, where I also have an interest in non-real-pups, I do not myself plan to work on makepup further. I do not deny that I am unhappy with the situation on the forum regarding unwillingness to respond to sticky request for:

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

and thus feel a desire to 'move on' and work with other distros more generally (including some outside this forum). But that is not with a 'bad taste' in my mouth - I just found myself naturally moving on whilst frustrated by the above. Puppy is a great wee distro, but I don't feel this is my home nowadays.

I have been a member of this forum for longer than many of the 'gatekeepers' of woof-CE (I have never sought out any such role), who have invited each other to these roles but my own interest has always been in the forum itself, including its diversity and helping to develop puppy-look-alikes (and small utility packages like Precord and weX) to bring new ideas to feed back to Puppy itself. I realise these similar to Pup functionality systems are not everyone's cup of tea.

As far as makepup is concerned, I know some remain interested in its development and I have received a PM with offer to take over its maintenance (following my request), which I appreciate. The next dev for it would probably be best to start a new thread for that purpose (to secure first post access for adding new versions for download).

Personally, I hope that dev work can also look towards idea of using sc0ttman's pkg in pets2add and pkgs2add mechanisms (as well as fix the issues rerwin raised in quote below) - or that woof-CE itself will start using pkg in its scripts (since that includes dependency resolution I believe) for its build package needs. But that will be up to the future maintainer(s).

I do find that makepup is a difficult program to maintain since changes on woof-CE github itself directly impact the operation of makepup... and makepup is not an incorporated part of woof-CE code at all (so changes made upstream naturally do not consider any effect these might have on makepup itself).

Actually, makepup is anyway really only a fudge to work around the limitation that woof-CE scripts require user interaction. What would be much better than makepup (or to improve any future makepup) would be if woof-CE scripts were modified to also allow their control via commandline switches (rather than or in addition to human choice menus) - as is the case with the likes of Debian debootstrap build scripts. But these are only my own opinions as are my remarks about non-real-pup and sticky post request and so on...

Hopefully, therefore, makepup will not now be abandoned, since it will certainly need ongoing maintenance to keep up with new distro recipes being added to woof-CE github over time etc...

But no, this is not a retirement from Puppy forum post; I'm still here (with apologies to one or two... ). It's just an announcement that I'm handing over maintenance/development of makepup to someone else!

EDIT: I posted my concerns as issues to woof-CE github but opinion back from its principal maintainer seems to be that I have things wrong. I'm not convinced my concerns are not correct, but moving on from this now anyway:

https://github.com/puppylinux-woof-CE/woof-CE/issues

wiak

[wiak]

But I have an update:

I decided to test the 'issue' I raised regarding incorrect BionicPup64 DISTRO_PKGS_SPECS file. I am sure phil will fix it anyway, despite the response I received from other on woof-CE github issues page.

I manually corrected that file from no|rox_config to yes|rox_config, which, I say, is what it should be...

Then I ran makepup -g (without ticking the checkbox that would have forced pop-up rootfs-packages selector gui).

Proof in the pudding: as I expected, BionicPup64 then built fine under makepup - so nothing wrong with makepup there. Upsteam the responses suggested makepup was a bad idea that would be far too difficult to maintain - in practice it has been working well with but a few small tweaks to account for new disto offerings, for almost two years.

So issue I raised on woof-CE github about DISTRO_PKGS_SPECS for BionicPup64 was indeed an issue and trivial to fix per my instructions to github woof-CE. That's all I ask for on that matter.

The second issue I raised is more serious (though that first issue cost huge efforts/loss of time):

That issue is that whenever a distro builder puts 'no' for a rootfs-package in DISTRO_PKGS_SPECS, should the pop-up be allowed to occur (which even with straight woof-CE script builds it would unless a Ctrl-C is given) then the code now in that routine over-writes all these 'no' entries with 'yes' entries so use has to check all the gui boxes and put back to 'no' per the distro builders indicated wishes! Easy to fix, that function that creates the pop-up was modified during the past two years, but badly - needs repaired. I could have written that fix, but thought it kinder to let the person who wrote the last version fix it silently themself (without all their github issues responses about how makepup is such a bad idea, which was never part of the issues raised).

If it isn't repaired, then makepup would have to copy the 'bad' code in one of its own functions, but that's rubbish, since all the 'no' entries end up as 'yes' and stuff will be in build which are not wanted. The only way out, for makepup at least would be to double-check distro builder hasn't made a mistake (as happened) in their DISTRO_PKGS_SPECS, but wow, that is painful - but more painful to build a distro and find it is wrong!

Nevertheless, the issues I correctly raised at woof-CE github were not for makepup per se, they are faults in woof-CE scripts/configs that should be willingly addressed (alas maybe not).

Do you wonder that I am happy to give up makepup, despite the effort in creating it in the first place? You should read the responses my simple raised issues regarding woof-CE faults produced on woof-CE github issues thread (link in previous post). Makepup also resulted in some woof-CE fixes (that I found solutions for and raised as issues) during its early development, so despite the negative comments made against it on github, it has actually helped woof-CE itself.

wiak

[wiak]

Hopefully the new maintainer/developer of makepup will now takeover following our PMs. I won't contribute further to makepup but look forward to watching the further developments!

[wiak]

my mistake. Issues there on github but under Closed.

https://github.com/puppylinux-woof-CE/w ... s%3Aclosed

But apparently the issues are "closed" because one individual claims to know everything and says he has explained everything so the issues do not need to be addressed and he has thus taken it upon himself to close the issues (that still remain by the way - well, simple one has been done: no changed to yes - so why all the comments in the issue request????).

The github issue response/comment made to me (one of many 'explanations') is:

I'm only trying to explain what happens as you have no idea what you're doing or what is happening

Oh really.

It's a case of it's not what you know, it's who you know.

This forum is needing to sort itself out in terms of visibility/transparency/inclusivity of the various concerns working here, and Puppy public woof-CE github 'gatekeepers' are stifling development with their gatekeeper ownership attitudes.

What gives one individual, xxxxx, the right to close two - now one - issues which have not been fixed?

Anyway, I could have fixed the code that was over-writing DISTRO_PKGS_SPECS 'no' entries configuration in that rootfs-packages woof-CE 3builddistro-Z pop-up gui function easily enough, but there will be no more code writing for Puppy by me (not with these so-called 'gatekeepers' holding their ownership-imagined fort so arrogantly). However, this forum is really not about aging Puppy only and it is more than time for it to acknowlege that more publicly, instead of the silence we are faced with.

[666philb]

Surely this was the error in provided woof-CE BionicPup64 recipe phil:

DISTRO_PKGS_SPECS-ubuntu-bionic

Code: Select all

...
yes|rox-filer||exe,dev,doc,nls
no|rox_config||exe,dev,doc,nls

That wouldn't be a makepup issue but a woof-CE github recipe issue if so. It does look wrong to me.
.

hi wiak,

that entry is a left over from when rox_config was a .pet in the noarch repo. it has since been incorporated into woofce and is maintained there. if that entry is set to yes, an old un-maintained version of rox config will end up in the build. I will be removing that line completely from the DISTRO_PKG_SPECS.
so just set that to yes in rootfs-packages.conf

the problem is the rootfs-packages.conf that your script creates.

Code: Select all

backend_modprobe="false"
change_kernels="false"
change_kernels="true"
cups_backend="false"
cups_backend="true"
cups_backend64="false"
firewall_ng="true"
frisbee="false"
frisbee="true"
getflash="false"
get_java="false"
jwm_config="false"
network_wizard="false"
network_wizard="true"
pburn="false"
pclock="false"
pdiag="false"
pfilesearch="true"
pfind="true"
pgprs="false"
pgprs="true"
pmusic="false"
pmusic="true"
pprocess="false"
pschedule="false"
pt_buntoo="false"
pt_faux_xfwm="false"
ptheme="false"
ptiming="false"
pupdial="false"
redshiftgui_wrapper="false"
rox_config="false"
simple_network_setup="true"
wallpaper="false"
wallpaper="true"

in a perfect world all rootfs-packages.conf could by default be set to yes and that would solve the issue. unfortunately my pups throw a spanner into the works as i use an older jwmconfig and don't use ptheme. This is my preference and not woofce's fault, in fact woofce has accommodated my rebellious builds, but the default is to use woofces jwmconfig and ptheme as peebees puppy does.


edit: i see that wdlkmpx has made a commit on woofce setting bionics DISTRO_PKG_SPECS to yes|rox_config||exe,dev,doc,nls so that your script works. But your scripts writing of the rootfs-packages.conf is still faulty as seen above. wdlkmpx commit isn't really necessary if makepups rootfs-packages.conf sets rox_config="true" (as is default in a woofce build)