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

Message

wiak · #281 Post by **wiak** » Wed 13 Mar 2019, 22:29

I've taken of makepup ver 0.1.7 for now, to modify hugekernel default pointed to. Since I'm going to upload changed version as 0.1.8 I might as well implement rerwin's suggested fixes for users to test.

Will modify and upload ver 0.1.8 as soon as I can, but may need to sleep first. If you have already downloaded ver 0.1.7 I would still appreciate any tests done using that, but be very careful to make sure the hugekernel selected is the actual hugekernel file rather than its md5 or sha256 check file.

EDIT: Hmmm... After, what I thought would be a fix, I've still got a problem with that sha256 file being thought of as the kernel... I'm working on it. Now trying a straight woof-CE build to see what the difference is.

wiak

wiak · #282 Post by **wiak** » Wed 13 Mar 2019, 22:56

While I'm at it I'll modify the hugekernel list processing to sed out sha256 entries (I guess that checksum wasn't previously being used).

wiak

wiak · #283 Post by **wiak** » Wed 13 Mar 2019, 23:35

foxpup wrote:
wiak wrote: however would work much better with dependency resolving cmdline package manager such as scottman's
That's exactly one of the goals sc0ttman had in mind with pkg!
I love it when a plan comes together .

Yes, indeed. I actually commented to sc0ttman when he first announced early creation of pkg how that was exactly what I needed to expand makepup (or even better to directly enhance github woof-CE scripts themselves).

Fredx181's mklive-stretch script actually uses similar idea in that after using debian debootstrap script(s) for the initial build, he then uses apt/dpkg commandline dependency resolving package manager to fetch all the optional bits wished for in the final iso build. That ability to separate base from apt/dpkg fetch part is what allows the amazing flexibility in the overall iso build. It is that dependency resolution capability that is missing in current woof-CE scripts that pkg could provide and/or makepup use in its pets2add and pkgs2add functionality, which is already an enhancement to what woof-CE itself offers; however, currently that makepup-provided additional functionality cannot resolve dependencies... hence my desire and often remarked enthusiasm for continuing development of sc0ttman's pkg program!!!

So basically woof-CE could do with being able to provide that similar to mklive-stretch capability, and it needs pkg (or similar for that). Anyone who thinks the Dogs do not provide essential ideas for the future of Puppy Linux woof-CE development are somewhat 'blind' or sometimes technically lacking in understanding. Those of us who do dev work for both systems understand very well the importance of cross-pollination efforts for both systems. It is only correct and fair, therefore, that all such systems, Pups and Dogs, are equally respected and promoted on this forum.

wiak

wiak · #284 Post by **wiak** » Thu 14 Mar 2019, 02:22

I won't for now upload my next makepup version until issue checked/fixed(?) at woof-CE repo since I think that is where the problem is - I've raised issue on woof-CE github accordingly. Many thanks in advance to the woof-CE team for looking into this for me.

Easiest 'fix' being, I believe, for ibiblio repo to use md5.txt file where it currently has a sha256 file. Alternatively, I believe the woof-CE support/hugekernel.sh script would changed to handle sha256 files rather than just the md5 checksums processing it does just now.

wiak

wiak · #285 Post by **wiak** » Thu 14 Mar 2019, 06:25

makepup 0.1.8 now released. Download from first post of this thread.

Includes rerwins fix for dotpet compressed with xz (not tested by me but looks fine). mavrothal has confirmed the issue I identified to woof-CE github team and seems they will simply rename the errant files at huge kernel repo, as I suggested, so nothing needs changed in makepup concerned with that.

I've completed one BionicPup64 (default build) with makepup and using pets2add included my dotpets for wex, weav, and scrox at build time. iso was produced successfully and these additions were found in it, so that one worked!

This version hopefully fixes all the numbering to match current woof-CE-testing and woof-CE-master available distros. This needs tested though, and feedback if I'm to fix any errors. I only have rural broadband so proved too slow for me to complete a build as yet - the Pups are getting bigger so taking longer and a lot more bandwidth to make test builds. (Though second time I try later tonight should be fine since makepup allows -k option to keep already downloaded packages).

DPupBuster isn't on woof-CE github yet, so not included in makepup lists for now.

Simple usage is to create empty build directory (on filesystem that has lots of space on it...); put makepup script into that and make it executable with chmod +x; and then run it in gui mode with makepup -g; then uncheck the -k keep previous downloads advanced option, and press "Build your pup!". It takes ages... However, after first build you can rebuild another one without having to download all the distro packages again (just specify the -k keep advanced option when running makepup -g this other time...). If you are adding extra pets by dropping them into pets2add folder, remember to check Advanced option -a box prior to pressing Build.... So handy for experimenting with different builds. I do not recommend building in usb2 mounted flash drive - probably far too slow for the work woof-CE scripts need to do.

BionicPup64 is currently the default build (i.e. -t 3 -d 2 -r 1)

Please let me know if you get round to testing this new makepup since I am unlikely to fix any issues otherwise whilst my own testing is so limited by broadband download speed issues.

wiak

rerwin · #286 Post by **rerwin** » Sat 16 Mar 2019, 19:20

wiak,
I am experimenting with makepup-0.1.8 and several added pet packages. The noarch pets (e.g., ultrasns-20190310) produce correct DISTRO_SPECS entries (yes|ultrasns||exe|pet).

However, architecture-specific pets (e.g., minibase-net-20190301-x86_64.pet) produce incorrect entries (yes|minibase-net-20190301||exe|pet).

Changing makepup line 105 from:

tac DISTRO_PKGS_SPECS-* | sed '0,/'"'"'/ s//'"'"'\nyes|'"${dotpetname%-*}"'||exe|pet/' | tac >/tmp/makepup/DISTRO_PKGS_SPECS # needs GNU sed

to:

tac DISTRO_PKGS_SPECS-* | sed '0,/'"'"'/ s//'"'"'\nyes|'"${dotpetname%%-[0-9]*}"'||exe|pet/' | tac >/tmp/makepup/DISTRO_PKGS_SPECS # needs GNU sed

produces the correct entry (yes|minibase-net||exe|pet). Do you think that change is sufficient?

However, the architecture-specific pets appear to be destined for puppy-noarch-official, when they should go to puppy-common64-official (common32-official), or maybe the distro-official. Makepup does not appear to address this type of pet. What to do about that?

(As you can see, I am experimenting with a puppy adaptation of Barry's UltraSNS.)

wiak · #287 Post by **wiak** » Sat 16 Mar 2019, 22:54

rerwin wrote: Changing makepup line 105 from:

tac DISTRO_PKGS_SPECS-* | sed '0,/'"'"'/ s//'"'"'\nyes|'"${dotpetname%-*}"'||exe|pet/' | tac >/tmp/makepup/DISTRO_PKGS_SPECS # needs GNU sed

to:

tac DISTRO_PKGS_SPECS-* | sed '0,/'"'"'/ s//'"'"'\nyes|'"${dotpetname%%-[0-9]*}"'||exe|pet/' | tac >/tmp/makepup/DISTRO_PKGS_SPECS # needs GNU sed

produces the correct entry (yes|minibase-net||exe|pet). Do you think that change is sufficient?

However, the architecture-specific pets appear to be destined for puppy-noarch-official, when they should go to puppy-common64-official (common32-official), or maybe the distro-official. Makepup does not appear to address this type of pet. What to do about that?

I'm happy you are experimenting with makepup rerwin. It is such a long time since I wrote these routines that I am utterly rusty about them now. I don't think many people tested this previously, or at least I had no feedback, and I only tested quickly with a few simple dotpets of my own. At a glance, your mod looks good, but only time will tell. I will test it briefly and upload new version thereafter in a few days time. As far as the list the entries appear in, yes, at the time I made this makepup addition I was mainly just testing a proof of concept and, imprecisely, just using puppy-noarch-official. But when you say makepup does not appear to address this type of pet, what exactly do you mean - if you drop such a pet into pkgs2add folder (with the line 105 fix you mention, do they not get included in the build anyway? - to be honest, not having looked at the code for so long, I can't remember what my code does... well... I 'roughly' still know). I may say, I am perfectly happy for you to make major developments to makepup, and take it over if you wish - I'm trying to slow down my involvement on Puppy more generally nowadays. Since you have an interest in using makepup, perhaps you would be interested in that? I'm sure you could improve it greatly.

wiak

rerwin · #288 Post by **rerwin** » Sun 17 Mar 2019, 03:07

I mean that it does not put the x86_64 pets in the right repo. But it does seem to include them in the build. So, I probably will need to move some items among the Package...official files later, if I update them in woof-CE (wherever they are). My hopefully successful build is running now and I will work with it tomorrow -- bedtime, now.

My additions to the build are some noarch and arch-specific pets and replacing the wvdial pet with the deb from ubuntu, learning as I go.

wiak · #289 Post by **wiak** » Sun 17 Mar 2019, 06:41

rerwin wrote:I mean that it does not put the x86_64 pets in the right repo. But it does seem to include them in the build. So, I probably will need to move some items among the Package...official files later, if I update them in woof-CE (wherever they are). My hopefully successful build is running now and I will work with it tomorrow -- bedtime, now.

Yes, I guess makepup should be updated with similar blocks of code to select, or at least auto-selecting, which arch-specific distro list the addon info gets sent to. Clearly it is a nuisance having to make the later item moves around official files later. Just using 'noarch' was admittedly a quick fudge on my part!

wiak

rerwin · #290 Post by **rerwin** » Sun 17 Mar 2019, 22:17

Report on my makepup build of XenialPup-7.5:

The build went almost smoothly overnight. But the memory tray icon showed that there was 0 free memory in the save partition, even though Partview showed about a gigbyte free in the partition. (I use a save directory for the build.) There were no obvious error messages, although 2 pets were claimed to be not found -- except that at least one of them ended up in the ISO. (That was wvdial, where I supplied the deb file in add2pkgs. I suspect it is not actually in the woofCE copy of the ubuntu repos.)

The resultant puppy actually booted up normally but the background is black and no icons and few tray icons appear. I see these messages in xerrs.log:

sed: can't read /root/Choices/ROX-Filer/PuppyPin: No such file or directory
grep: /root/Choices/ROX-Filer/PuppyPin: No such file or directory
/sbin/clean_desk_icons: line 9: can't create /root/Choices/ROX-Filer/PuppyPin: nonexistent directory
grep: /root/Choices/ROX-Filer/PuppyPin: No such file or directory
cat: /root/Choices/ROX-Filer/PuppyPin: No such file or directory
cp: cannot create regular file '/root/Choices/ROX-Filer/PuppyPin': No such file or directory
/root/.xinitrc: line 132: roxfiler: command not found
/usr/bin/jwm

ROX-Filer is where is should be but there is no /root/Choices/ROX-Filer directory, so no PuppyPin file. The above messages may have been generated when I attempted to run ROX-Filer from the Filesystem menu.

I am not sure what to make of it all, as I have not mastered that desktop management stuff. I will keep digging, but want to give you some feedback, such as it is.

Some other disconcerting messages in xerrs.log:

(process:4120): GLib-GObject-WARNING **: Two different plugins tried to register 'GProxyResolverGnome'.

(process:4120): GLib-GObject-CRITICAL **: g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:4120): GLib-GIO-WARNING **: Tried to register an extension of the type (null) to extension point gio-proxy-resolver. Expected type is GProxyResolver.

/usr/local/bin/rox: line 2: exec: roxfiler: not found

Terry H · #291 Post by **Terry H** » Sun 17 Mar 2019, 22:53

I did a build Slackware 14.2 64 bit, I used the kernel from ScPup64. Similar to rerwin, it booted to a black desktop, with a bottom panel with menu. It doesn't have rox or PuppyPin, so desktop incomplete. The puppy first run, ran OK. I was able to set up wifi and programs tested ran OK. I actually ran a couple of times, with same results.

I had used makepup in earlier versions and this issue didn't occur previously.

wiak · #292 Post by **wiak** » Sun 17 Mar 2019, 22:59

Terry H wrote:I did a build Slackware 14.2 64 bit, I used the kernel from ScPup64. Similar to rerwin, it booted to a black desktop, with a bottom panel with menu. It doesn't have rox or PuppyPin, so desktop incomplete. The puppy first run, ran OK. I was able to set up wifi and programs tested ran OK. I actually ran a couple of times, with same results.

I had used makepup in earlier versions and this issue didn't occur previously.

A straight woof-CE scripts build would have to be made without makepup to see if the result is the same (which I presume for now it would be). As far as I'm aware nothing much has been changed in earlier already tested as fine makepup versions, though things may have been changed on woof-CE that effect what makepup has to do. Unfortunately, as I said ealier, it is very long process for me to test since my broadband is rural and so slow so hopefully you can make a straight woof-CE scripts build without using makepup. If that works fine, then I can look into it.

If no one gets round to that, I will try that myself later. I'm busy working on other distro at the moment on my dev machine so can't try right now. I do know default BionicPup64 build via makepup went perfectly with makepup 0.1.7 (haven't tested 0.1.8, but doubt any issue caused by minor pkg2add changes in there), but that's all I know just now. EDIT: Come to think of it, I only actually know that the build went fine in that the iso was built and I checked my pet2add dotpets made it in okay; but I didn't actually boot the resultant iso - just looked inside it. I can't just now cos makepup busy on my machine slowly... building XenialPup64...

EDIT: Ok, I'm too curious, so starting up makepup build of XenialPup-7.5 with a few dotpets of my own placed in pkgs2add folder. This will take ages on my system though and ages more if I discover I also had problem since would then certainly need to try without makepup using instead woof-CE scripts one by one. I'll report back first on makepup result and make woof-CE build thereafter for further report if things went badly. Thanks for letting me know how things going for you.

wiak

wiak · #293 Post by **wiak** » Mon 18 Mar 2019, 01:59

rerwin wrote:The resultant puppy actually booted up normally but the background is black and no icons and few tray icons appear.

I can confirm failure in XenialPup64 build as you described. I used makepup ver 0.1.8 but including the %-[0-9] addition you suggested for line 105 rerwin, though I can't image that being anything to do with it.

I'm now going to test the BionicPup64 iso I created with makepup ver 0.1.7 a few days ago. If that works, someone will have to try a XenialPup64 build using woof-CE scripts themselves to see if recipe or woof-CE build scripts have error rather than something makepup is doing wrong. Woof-CE recipe error seems most likely to me (though maybe I'm biased... aka wishful thinking in support of makepup...), since so little has been changed in makepup itself of late. Time, and someone testing woof-CE itself, will tell.

wiak

wiak · #294 Post by **wiak** » Mon 18 Mar 2019, 03:49

I have now booted the BionicPup64 iso I created via woof-CE with makepup ver 0.1.7 and it similarly has icons missing and grey background. Since it seems likely that others have been building BionicPup64 via straight woof-CE scripts successfully that now makes me suspect, sadly, that something has changed that breaks makepup itself.

I don't follow changes at woof-CE github any more and haven't done so for a long time unfortunately, which is why I am happy for another dev (hopefully a Puppy-related competent one) to take over makepup development should people wish to see it continue. I will however try and get to the bottom of current issue however, if no-one beats me to it! But remember, please, my rural broadband makes my testing slow...

wiak

s243a · #295 Post by **s243a** » Mon 18 Mar 2019, 05:12

wiak wrote:I have now booted the BionicPup64 iso I created via woof-CE with makepup ver 0.1.7 and it similarly has icons missing and grey background. Since it seems likely that others have been building BionicPup64 via straight woof-CE scripts successfully that now makes me suspect, sadly, that something has changed that breaks makepup itself.

I don't follow changes at woof-CE github any more and haven't done so for a long time unfortunately, which is why I am happy for another dev (hopefully a Puppy-related competent one) to take over makepup development should people wish to see it continue. I will however try and get to the bottom of current issue however, if no-one beats me to it! But remember, please, my rural broadband makes my testing slow...

wiak

Regarding broken icons, I'm not sure if this is related at all but I had an issue with one of the symlinks in the TazPup64 that I'm trying to build.

From my post:

For some reason /root/.icons/ROX
points to: /usr/share/rox-filer/images

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

http://murga-linux.com/puppy/viewtopic. ... 30#1022230

Anyway, remember to update all the cache's and databases if you need to change this. Perhaps it's overkill but I wrote a script to update all the icon caches at once by looking for index.theme files.

Code: Select all

update_icon_caches(){
   trap update_system_database_cleanup EXIT SIGKILL SIGTERM
   mkdir -p "$update_icon_caches_fd_path"
   exec 11<> "$update_icon_caches_fd_path"fd_11
   while IFS=$'\0' read  -r -d $'\0' -u11 theme_index_path_prefixed ; do
     theme_index_path=`dirname "${theme_index_path_prefixed#$curdir/slitaz-rootfs$prefix}"`
     chroot "$curdir/slitaz-rootfs$prefix/" /usr/bin/gtk-update-icon-cache "$theme_index_path"
   done 11< <( find "$curdir/slitaz-rootfs$prefix/" -type f -name 'index.theme' -print0 ) #https://blog.famzah.net/2016/10/20/bash-process-null-terminated-results-piped-from-external-commands/
      exec 11>&-
}

https://pastebin.com/AXF7XNci
http://murga-linux.com/puppy/viewtopic. ... 30#1021730

Note that I'm not using woofCE but I did use some recent code from the WoofCE repo. One other thing that I notice is that in the /root/,icons folders there should probably be two subfolders. One that says default and one that says ROX. In my system only the ROX one was there for the root user and the default one was there for other users. I coppied the one that said default from another user to the root folder.

Again though, I'm not sure if any of this is relevant because I'm not using woofCE as the build tool.

wiak · #296 Post by **wiak** » Mon 18 Mar 2019, 09:07

wiak wrote:I don't follow changes at woof-CE github any more and haven't done so for a long time unfortunately, which is why I am happy for another dev (hopefully a Puppy-related competent one) to take over makepup development should people wish to see it continue. I will however try and get to the bottom of current issue however, if no-one beats me to it! But remember, please, my rural broadband makes my testing slow...

Well... I have now tried building XenialPup7.5 x86_64 bit kernel 4.9.58 by using woof-CE scripts by themselves (not via makepup). Admittedly, I did not have devx sfs loaded so no strip command (though I'm sure devx wasn't 'required' in builds I made in the past?). Anyway, the result was a bit different than my earlier makepup build (no idea why) but not good either. Don't have screenshot of my makepup-created version, but have attached this straight woof-CE version screenshot.

I did see some errors (but these possibily prove nothing, since my recollection is that there are always warnings/errors of some sort or other and most seem ignorable - but maybe these are relevant?:

Code: Select all

Content of ERROR-2CREATEPACKAGES log file:

ERROR: 'diffutils' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build diffutils.
=========================================

Code: Select all

(some seen) Errors in terminal output on ./builddistro-Z
======
copying wallpaper
* rootfs-packages/EXIT does not exist
cat: /tmp/rootfs_pkgs_pinstall_ptheme.sh: No such file or directory
Creating file woof-installed-packages...

=======
chroot: can't execute '/usr/bin/gtk-update-icon-cache': No such file or directory'rootfs-complete/usr/local/bin/rox' -> 'defaultfilemanager'

=======
OH, NO GOOD, you don't have the 'strip' executable. The 'devx' sfs has it.

Now building sandbox3/0builtin_files_xenialpup64-7.5.pet,

=======
installing pkg lists into rootfs-complete/var/packages/builtin_files...
...done
./3builddistro-Z: line 1107: initrd-tree/DISTRO_SPECS: No such file or directory
rm: cannot remove 'root/.config/autostart/pmcputemp.desktop': No such file or directory
Setting default apps specified in build.conf ...

Main thing is, I have run out of energy - took all day on my slow connection - so if there is a chance I could contribute to a fix I would need others to try with woof-CE scripts (not via makepup) to report success/failure etc. I will wait for that. Also, I wrote makepup in early 2017 and haven't looked at woof-CE since, so have forgotten most all I once knew... so things not looking too good... sorry.

wiak

So here is the screenshot of the distro just created by pure woof-CE scripts and not using makepup at all:

rerwin · #297 Post by **rerwin** » Mon 18 Mar 2019, 14:56

FWIW, I have a woofCE-built 32-bit XenialPup built on 12/20/2018 that appears to boot up normally. Maybe that indicates whatever changed that impacts us happened since then.

s243a · #298 Post by **s243a** » Mon 18 Mar 2019, 16:20

wiak wrote:
wiak wrote:I don't follow changes at woof-CE github any more and haven't done so for a long time unfortunately, which is why I am happy for another dev (hopefully a Puppy-related competent one) to take over makepup development should people wish to see it continue. I will however try and get to the bottom of current issue however, if no-one beats me to it! But remember, please, my rural broadband makes my testing slow...
Well... I have now tried building XenialPup7.5 x86_64 bit kernel 4.9.58 by using woof-CE scripts by themselves (not via makepup). Admittedly, I did not have devx sfs loaded so no strip command (though I'm sure devx wasn't 'required' in builds I made in the past?). Anyway, the result was a bit different than my earlier makepup build (no idea why) but not good either. Don't have screenshot of my makepup-created version, but have attached this straight woof-CE version screenshot.

I did see some errors (but these possibily prove nothing, since my recollection is that there are always warnings/errors of some sort or other and most seem ignorable - but maybe these are relevant?:
Code: Select all
Content of ERROR-2CREATEPACKAGES log file:

ERROR: 'diffutils' package does not exist.
You will need to find a matching package and place in packages-pet,
or packages-deb-xenial as appropriate.
Do it, then rerun this script and choose to build diffutils.
=========================================
Code: Select all
(some seen) Errors in terminal output on ./builddistro-Z
======
copying wallpaper
* rootfs-packages/EXIT does not exist
cat: /tmp/rootfs_pkgs_pinstall_ptheme.sh: No such file or directory
Creating file woof-installed-packages...

=======
chroot: can't execute '/usr/bin/gtk-update-icon-cache': No such file or directory'rootfs-complete/usr/local/bin/rox' -> 'defaultfilemanager' 

gtk-update-icon-cache is an executable provide by the gtk package. It shouldn't be symlinked to "defaultfilemanager'

Code: Select all
=======
OH, NO GOOD, you don't have the 'strip' executable. The 'devx' sfs has it.

Now building sandbox3/0builtin_files_xenialpup64-7.5.pet,

=======
installing pkg lists into rootfs-complete/var/packages/builtin_files...
...done

./3builddistro-Z: line 1107: initrd-tree/DISTRO_SPECS: No such file or directory
rm: cannot remove 'root/.config/autostart/pmcputemp.desktop': No such file or directory
Setting default apps specified in build.conf ...
Main thing is, I have run out of energy - took all day on my slow connection - so if there is a chance I could contribute to a fix I would need others to try with woof-CE scripts (not via makepup) to report success/failure etc. I will wait for that. Also, I wrote makepup in early 2017 and haven't looked at woof-CE since, so have forgotten most all I once knew... so things not looking too good... sorry.

wiak

So here is the screenshot of the distro just created by pure woof-CE scripts and not using makepup at all:

Some other random notes:
1. The icons are defined in /root/Choices/ROX-Filer/globalicons,
2. The file globalicons is used in conjuction with the file /root/Choices/PuppyPin

these files are installed by the packages rox_config

Changes to PuppyPin and globalicons must be made after rox_config is installed and then the global icon cache must be updated using gtk-update-icon-cache, the argument to gtk-update-icon-cache is the location of the index.theme file.

Note that I would also install jwm_config before making changes to puppypin. Both of these packages can be installed by copying the files into the target environment and then running the post-install scripts: /rox_config/pinstall.sh and /jwm_config/pinstall.sh. If these packages are made into pets then petget will do this.

wiak · #299 Post by **wiak** » Mon 18 Mar 2019, 19:39

Hi s243a,

Thanks for the insights. What you write may help lead to the issue but in the meantime I'm still most interested in reports of actual builds succeeding or not succeeding using woof-CE scripts directly. At the moment I don't know if the issue is with woof-CE itself or with makepup particularly since I did get different (but also bad result) when comparing woof-CE scripts direct and makepup build I have done (I expected them to be the same if all well in makepup). Anyway, I'll have to make space on my harddrive because I don't have enough for building onto that and been using external usb HD which compounds how slow I can test things. I'm planning today to download devx and making sure that loaded before test this time, just in case it is now needed.

Any further woof-CE direct test results would be appreciated at this stage. Perhaps those who put their recipes on woof-CE github aren't reading this thread tho I'd hope they do since their help would be appreciated - otherwise I'll contact them for info later.

wiak

666philb · #300 Post by **666philb** » Mon 18 Mar 2019, 19:55

hi wiak,

i'll have a look at this tomorrow. i did remove some scripts from the zz_fix.pets for tahr & xenial to try and make them work with the latest woofce as a lot has changed since they were first created.

will report back

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

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

makepup 0.1.8 now released