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 Sun 21 Apr 2019, 16:34
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Auto-build a Puppy iso; single script with optional gui
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 22 of 22 [325 Posts]   Goto page: Previous 1, 2, 3, ..., 20, 21, 22
Author Message
wiak

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

PostPosted: Tue 19 Mar 2019, 21:06    Post subject:  

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.php?p=1022079#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.php?p=1022079#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...Wink ). 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

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Tue 19 Mar 2019, 23:16    Post subject:  

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

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Tue 19 Mar 2019, 23:50    Post subject:  

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!
_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 20 Mar 2019, 01:22    Post subject:  

my mistake. Issues there on github but under Closed.

https://github.com/puppylinux-woof-CE/woof-CE/issues?q=is%3Aissue+is%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:

xxxxx wrote:
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.

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
666philb


Joined: 07 Feb 2010
Posts: 3408
Location: wales

PostPosted: Wed 20 Mar 2019, 06:58    Post subject:  

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

DISTRO_PKGS_SPECS-ubuntu-bionic

Code:

...
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:
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)

_________________
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 20 Mar 2019, 07:20    Post subject:  

Hi phil

Thank you for the information/situation about the old unmaintained version of rox_config; that I didn't know about.

I do know that the rootfs-packages.conf currently generated by makepup (assuming no other provided) does not produce correct file - but that's because the code it uses is in fact pretty much straight from woof-CE but from the time makepup was first created around two years ago. The issue I raised on woof-CE github concerned the change in woof-CE to that part of the code (pop-up gui for selecting rootfs-packages). As I said in the issue I raised, I do not think the current code is correct because it forcibly over-writes all no|pkg_name entries in DISTRO_PKGS_SPECS with a 'yes'. I understand from what you say, yes is not good for root_config, but that otherwise does not change my point about that pop-up code in 3builddistro-Z. My plan was to fix the similar code in makepup function with the more recent woof-CE code, but since I do not agree with that codes logic I won't be changing makepup with it. Alas, yes, that does mean makepup cannot get that rootfs-packages.conf autogenerated correctly in this situation, but I leave that problem now for others to deal with, should they so care.

Many thanks anyway for your comments and guidance.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
666philb


Joined: 07 Feb 2010
Posts: 3408
Location: wales

PostPosted: Wed 20 Mar 2019, 07:29    Post subject:  

hi wiak ,

even though wdlkmpx's commit for bionicpup has fixed that build for your script. both xenialpup and tahrpup do not have an entry for rox_config in their DISTRO_PKG_SPECS and so your script will fail until it writes a correct rootfs-packages.conf. rox_config is a non issue as that it easy to set to yes as default in your script for all pups.

your real issue is whether jwmconfig & ptheme are set to yes or no and for that you can blame me Smile
if it's one of my pups they need to be set to no and other pups set to yes.
everything else can safely be set to YES

_________________
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 20 Mar 2019, 07:44    Post subject:  

Yes I agree with what you say, but there shouldn't be such a problem at all if whatever the distro builder arranges to be yes or no in DISTRO_PKGS_SPECS was correctly honoured by woof-CE code (and in that situation yes I would be updating the relevant function in makeup itself to do the same job). Yes I was tempted to use current woof-CE logic for generation of rootfs-packages.conf in makeup function, but not when that code overwrites no entries in DISTRO_P_S file. Up to someone else now.

If DISTRO_P_S had no for jwmtheme or whatever, then that shouldn't be overwritten by 3builddistro-Z code. Sorry, tricky typing cos on small android tab just now. Thanks again

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
666philb


Joined: 07 Feb 2010
Posts: 3408
Location: wales

PostPosted: Wed 20 Mar 2019, 08:20    Post subject:  

woofce does detect if options is set to yes in DISTRO_PKG_SPECS pburn,jwmconfig etc and then unchecks it in the popup & everything not in DISTRO_PKG_SPECS is set to yes.
_________________
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 20 Mar 2019, 19:30    Post subject:  

666philb wrote:
woofce does detect if options is set to yes in DISTRO_PKG_SPECS pburn,jwmconfig etc and then unchecks it in the popup & everything not in DISTRO_PKG_SPECS is set to yes.


Oh well, I must have got that bit wrong. The builds/testing took so much time on my limited hardware/wifi. I was also particularly aggravated after these days by what I considered condescension of the respondes I received when posting issues on woof-CE github. I've been working with this and pups more generally and Linux in general long enough not to appreciate condescension in any shape or form. Anyway, doesn't matter now since I'm not involving myself with makeup or woof-CE any more. I have tons of other interests and demands that I need to get on with and wish to do.

Thanks for the post though.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
makepup: http://www.murga-linux.com/puppy/viewtopic.php?p=965541
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 22 of 22 [325 Posts]   Goto page: Previous 1, 2, 3, ..., 20, 21, 22
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.0895s ][ Queries: 13 (0.0455s) ][ GZIP on ]