After a lot of tracking through it's scripts, i've found out why Frisbee wifi is failing a connection via automatic connection and yet is ok when manually run. It's the same problem i've had with mp, where the rxvt-unicode packages from both thud and pyro won't run from within a script using the -e switch for some reason. I fixed mp by changing it to use sakura instead and I may be forced to try the same change with frisbee wifi although I would love to sort rxvt out. I also now have an external wifi 'dongle' I can try rather than borrow laptops so I can try it out easily when I get there.
I'm still trying to sort out why I can't build a beta with the alpha build, I consider that's a bit more important at present, sorry.
The rest seems to work now although i'm seeing some strange xerrs.log messages after a boot still, but not every time, so i'm still chasing them, even if they don't seem to have any effect on all types of screens I have(, even the old crt).
The Alpha build is now up to 0.8.80 but i'm not releasing it yet (maybe at the weekend).
AH, I hate unlisted dependancies!
Quirky Thud64 - Closed
Final Alpha's (I hope)
> quirky-thud64-0.8.81-16gb.img.xz 1.7Gb is the Development Version
https://www.lamiaworks.com.au/puppy/thu ... 6gb.img.xz
> quirky-thud64-0.8.90-16gb.img.xz 551.2Mb is the Users Version
https://www.lamiaworks.com.au/puppy/thu ... 6gb.img.xz
(I'm also building a 8gig img at present to add to this one with a fat32/ext2 pairing for testing lower grade memory sticks. There is a note in the Easy thread about why i'm doing it.)
> quirky-thud64-0.8.90-8gb.img.xz 547.6Mb is the Users Version
https://www.lamiaworks.com.au/puppy/thu ... 8gb.img.xz
You need at least a 16g stick for two of these, but only the 16gig will be needed for the Development Version in Beta. These will be the last Alphas unless a major problem surfaces.
The number differance is so I know which is which for now, they are actually built with the same base. The names will only change to their final ones, and numbers parallel when we go Release, until then they will sequence with Development versions being even numbers and User version the following odd number step.
For this time, both have some extra packages/files in them that won't be in the later non-development versions as i'm trying to track a problem package-version-file-package-dependancy-version sequence down for one of the packages I intend adding into the beta's.
Also I haven't sorted the rxvt-unicode/frisbee problem down yet, now I know what it is, I just need to slowly see if I can find it's cause or just change frisbee to use sakura. I had been considering just changing it to use sakura, but i'd really like to find the problem instead as it will affect other packages that use rxvt-unicode in the same way.
EDIT:20190804 Finally found a way, after a lot of testing and mixing settings that didn't work, to see the rxvt-unicode error messages and confirmed the problem is with rxvt-unicode, it's erroring when trying to open a terminal to run any external commands (only). I think I will try building it from within my quirky-thud64 and see if that fixes it as just changing it doesn't work either. May be there is a dependancy at the wrong version or something that will show up this way! And trying to rebuild rxvt-unicode fails with a perl error; I shall a build with the pyro perl next and see if that is the problem.
Hoiwever, the first (and maybe) only beta works other than this problem in internal testing. But it's not going out until I fix this problem as I've found a number of qt5 apps I want to add also use it.
https://www.lamiaworks.com.au/puppy/thu ... 6gb.img.xz
> quirky-thud64-0.8.90-16gb.img.xz 551.2Mb is the Users Version
https://www.lamiaworks.com.au/puppy/thu ... 6gb.img.xz
(I'm also building a 8gig img at present to add to this one with a fat32/ext2 pairing for testing lower grade memory sticks. There is a note in the Easy thread about why i'm doing it.)
> quirky-thud64-0.8.90-8gb.img.xz 547.6Mb is the Users Version
https://www.lamiaworks.com.au/puppy/thu ... 8gb.img.xz
You need at least a 16g stick for two of these, but only the 16gig will be needed for the Development Version in Beta. These will be the last Alphas unless a major problem surfaces.
The number differance is so I know which is which for now, they are actually built with the same base. The names will only change to their final ones, and numbers parallel when we go Release, until then they will sequence with Development versions being even numbers and User version the following odd number step.
For this time, both have some extra packages/files in them that won't be in the later non-development versions as i'm trying to track a problem package-version-file-package-dependancy-version sequence down for one of the packages I intend adding into the beta's.
Also I haven't sorted the rxvt-unicode/frisbee problem down yet, now I know what it is, I just need to slowly see if I can find it's cause or just change frisbee to use sakura. I had been considering just changing it to use sakura, but i'd really like to find the problem instead as it will affect other packages that use rxvt-unicode in the same way.
EDIT:20190804 Finally found a way, after a lot of testing and mixing settings that didn't work, to see the rxvt-unicode error messages and confirmed the problem is with rxvt-unicode, it's erroring when trying to open a terminal to run any external commands (only). I think I will try building it from within my quirky-thud64 and see if that fixes it as just changing it doesn't work either. May be there is a dependancy at the wrong version or something that will show up this way! And trying to rebuild rxvt-unicode fails with a perl error; I shall a build with the pyro perl next and see if that is the problem.
Hoiwever, the first (and maybe) only beta works other than this problem in internal testing. But it's not going out until I fix this problem as I've found a number of qt5 apps I want to add also use it.
Release next
Ok, I had a long think while helping friends with problems after a horrible fire.
I came to the realization that other than the two outstanding problems I had actually met my origonal requirements. And at least one of the problems has been fixed and the last one I know of (Frisbee) I intend to treat the same way and see what happens.
It means that I shall build a release soon as two versions,>
One is a user version that has no devx inbuilt (I shall build it externally as we normally do);
The second will have the devx already incorperated into the package.
Packages should be a usfs.xz, a img.xz and an .iso for standalone running, plus a sfs for the devx if needed. I may do a new kernel, but need to test it as there are some differances and it may not work.
And that should be it, whether there are updates will be moot as it was and is only a stepping stone stage for building upon, and not designed to be the end system. To this I shall also create a packageset of BarryK's woofOE builder at the release I created it, to allow others to go from there if they so desire.
I came to the realization that other than the two outstanding problems I had actually met my origonal requirements. And at least one of the problems has been fixed and the last one I know of (Frisbee) I intend to treat the same way and see what happens.
It means that I shall build a release soon as two versions,>
One is a user version that has no devx inbuilt (I shall build it externally as we normally do);
The second will have the devx already incorperated into the package.
Packages should be a usfs.xz, a img.xz and an .iso for standalone running, plus a sfs for the devx if needed. I may do a new kernel, but need to test it as there are some differances and it may not work.
And that should be it, whether there are updates will be moot as it was and is only a stepping stone stage for building upon, and not designed to be the end system. To this I shall also create a packageset of BarryK's woofOE builder at the release I created it, to allow others to go from there if they so desire.