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 19 Nov 2017, 10:26
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
woof-CE needs you
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 71 of 80 [1197 Posts]   Goto page: Previous 1, 2, 3, ..., 69, 70, 71, 72, 73, ..., 78, 79, 80 Next
Author Message
wiak

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

PostPosted: Sun 03 Sep 2017, 18:41    Post subject:  

@Sailor,

Yes, I am not modifying Xenialpup64 builds at all. mpv is in there but these libs are missing (or not symlinked in correctly if they are there is some other named form).

wiak
Back to top
View user's profile Send private message 
Billtoo


Joined: 07 Apr 2009
Posts: 3265
Location: Ontario Canada

PostPosted: Sun 03 Sep 2017, 18:55    Post subject:  

wiak wrote:

I'm curious what you have done such that these libs are not missing on your build Bill. Perhaps they are included with your own kernel used packaging (rather than those available via woof-CE directly?)

I'll be uploading new ver 0.0.5 makepup soon once I've tidied the new code up a bit and done some more testing. It contains quite a few major code changes - both to do with the extra options (and organisation of when to use makepup_extra.conf) and also the auto-alter support/rootfs-packages.conf code dependent on distro chosen. So it needs quite a bit of testing, but looking okay thus far.

wiak


Hi,

I compiled the prorietary nvidia driver on 2 xenialpup64 installs and both mpv and kodi work fine.
On another xenialpup64 with an amd radeon graphics card neither mpv or kodi will run.

I'm building a tahrpup64 now with the oldest kernel "7" to see if I can compile the flgrx driver and try kodi in that one.

Bill
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Sun 03 Sep 2017, 19:58    Post subject:  

Billtoo wrote:


I compiled the prorietary nvidia driver on 2 xenialpup64 installs and both mpv and kodi work fine
...
Bill


Ah... that compile must have pulled in the missing libs needed by mpv I guess.

wiak
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Sun 03 Sep 2017, 20:15    Post subject:  

chroot test a new woof-CE build from its host build system (or any other Linux system):

Howto do the above is given here:

http://www.murga-linux.com/puppy/viewtopic.php?p=966512#966512

wiak
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1282

PostPosted: Sun 03 Sep 2017, 21:05    Post subject:  

Speaking of chroot test, I just tried to build xenial64 (testing branch) using xenial64-7.0.8.5 and it's devx as base and it stopped at that part of 3builddistro-Z (screenshot).

edit: Using slacko64-6.9.9.5 and it's devx as the build environment to make xenial64 (testing branch) seems to be working better. Now I wonder if using this newly created xenial64 to make xenial64 will work better than the real xenial64-7.0.8.5 one did for me or not, and if so, then that xenial64 produced by that xenial64 Laughing

edit2: The xenial64 iso produced by that slacko64 was missing the 3 mpv libraries wiak and rufwoof mentioned too it seems (/usr/lib had libmircommon.so.5 instead of 7). Also, QBat in xenialpup says my full Battery is at negative 109%. Smile
capture6689.png
 Description   
 Filesize   20.57 KB
 Viewed   536 Time(s)

capture6689.png

Back to top
View user's profile Send private message 
Billtoo


Joined: 07 Apr 2009
Posts: 3265
Location: Ontario Canada

PostPosted: Mon 04 Sep 2017, 00:11    Post subject: woof-CE needs you  

I tried the tahrpup64 build on a pc with an AMD graphics card and it
didn't go well, deleted the savefile and moved it to an Acer with
nvidia card, it works great on there.
Installed to a 32gb SDHC card.

sh-4.3# inxi -bw
System: Host: puppypc19407 Kernel: 3.14.54 x86_64 (64 bit) Desktop: JWM 2.3.6 Distro: tahrpup64 6.0.6
Machine: Device: desktop System: ACER product: Aspire M5620 v: R01-A4 serial: PTS860X0348050CF642700
Mobo: ACER model: G33T-AM v: 1.0 serial: 00000000 BIOS: American Megatrends v: R01-A4 date: 12/19/2007
CPU: Quad core Intel Core2 Quad Q6600 (-MCP-) speed/max: 1603/2403 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.15.1 driver: nvidia tty size: 141x28 Advanced Data: N/A for root
Network: Card: Intel 82566DC-2 Gigabit Network Connection driver: e1000e
Drives: HDD Total Size: 43.9GB (30.3% used)
Weather: Conditions: 59 F (15 C) - Partly Cloudy Time: September 4, 12:03 AM EDT
Info: Processes: 146 Uptime: 1:03 Memory: 424.4/7976.9MB Client: Shell (sh) inxi: 2.3.8
sh-4.3#

Kodi sfs works well, Google-earth too.
screenshot.jpg
 Description   
 Filesize   32.66 KB
 Viewed   529 Time(s)

screenshot.jpg

Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1282

PostPosted: Tue 05 Sep 2017, 11:00    Post subject:  

Tahr 64-bit woof-CE testing build worked ok for me too on Core2Duo laptop, using same 3.14.54 kernel as Billtoo.
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Tue 05 Sep 2017, 21:51    Post subject:  

Just dropped by woof-CE github and note that the missing libs (for mpv etc) seem to have been added now to the testing branch of xenial 32bit and 64bit. I haven't tried it yet.

Since it takes time for such bugfixes to filter through to rationalise branch I intend the next release of makepup to default to using testing branch (despite the chance of things breaking in that branch owing to its 'testing' nature). Will still be able to use rationalise branch instead of course using switch -w/--woofbranch.

wiak
Back to top
View user's profile Send private message 
Billtoo


Joined: 07 Apr 2009
Posts: 3265
Location: Ontario Canada

PostPosted: Tue 05 Sep 2017, 22:47    Post subject: woof-CE needs you  

I installed a rationalise branch build of xenialpup to a 64gb flash drive, pc is an Acer desktop:

root# inxi -bw
System: Host: puppypc3008 Kernel: 4.9.13 i686 (32 bit) Desktop: JWM 2.3.5
Distro: xenialpup 7.0.6
Machine: Device: desktop System: ACER product: Aspire M5620 v: R01-A4 serial: PTS860X0348050CF642700
Mobo: ACER model: G33T-AM v: 1.0 serial: 00000000
BIOS: American Megatrends v: R01-A4 date: 12/19/2007
CPU: Quad core Intel Core2 Quad Q6600 (-MCP-) speed/max: 1603/2403 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.18.4 driver: nvidia
tty size: 83x29 Advanced Data: N/A for root
Network: Card: Intel 82566DC-2 Gigabit Network Connection driver: e1000e
Drives: HDD Total Size: 70.9GB (30.6% used)
Weather: Conditions: 55 F (13 C) - Mostly Cloudy Time: September 5, 10:21 PM EDT
Info: Processes: 192 Uptime: 20 min Memory: 187.1/3535.0MB
Client: Shell (bash) inxi: 2.3.8
root#

It's working okay so far, some applications aren't available
(smplayer/smtube) but kodi works well.
screenshot.jpg
 Description   
 Filesize   87.52 KB
 Viewed   347 Time(s)

screenshot.jpg

Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 06 Sep 2017, 09:03    Post subject:  

wiak wrote:
Just dropped by woof-CE github and note that the missing libs (for mpv etc) seem to have been added now to the testing branch of xenial 32bit and 64bit. I haven't tried it yet.

Since it takes time for such bugfixes to filter through to rationalise branch I intend the next release of makepup to default to using testing branch (despite the chance of things breaking in that branch owing to its 'testing' nature). Will still be able to use rationalise branch instead of course using switch -w/--woofbranch.


Following a test XenialPup64 I made with makepup from woof-CE-testing branch, I can confirm that mpv media player is now working when built from that branch. That follows from the recent woof-CE-testing bugfix where the missing libs were added in as 'yes' to the DISTRO-PKGS-....

wiak
Back to top
View user's profile Send private message 
OscarTalks


Joined: 05 Feb 2012
Posts: 1631
Location: London, England

PostPosted: Thu 07 Sep 2017, 05:53    Post subject:  

I downloaded and ran woof-CE yesterday. This was my first time. I am a fan of Dpup so I selected Stretch. Pretty much allowed things to run through without re-configuring anything. It did build successfully and does run, but clearly some tweaking of the output distro is still required. As things stand I don't know how to feed back any suggestions into woof-CE but I might play around with it some more over time to try to get the hang of it.

I was also looking at the kernel-kit because I wanted to try to find out how to produce the kernel-sources .sfs package. I have done a lot of manual remastering of billtoo's early build and he didn't have a 3.14.79 kernel-sources (not sure if it would be OK to use the one in the tahr ibiblio repo). I did create one and went on to build ndiswrapper-1.61 as a test (and because I wanted to add it to my remaster).

_________________
Oscar in England

Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1282

PostPosted: Thu 07 Sep 2017, 12:25    Post subject:  

Hi OscarTalks,

What are some thing you noticed missing from Debian? If they are in one of the PPM repositories, they can probably be added to the spec. I have made a Devuan Ascii here, where I tried to fill in some of the missing pieces, you can rip out it's vmlinuz and zdrv and use it's kernel sources (4.4.80) if you like:
http://murga-linux.com/puppy/viewtopic.php?t=109842

I've also tried another Slackware 14.0 (5.7.1) build here at commit 5526 if anyone wants to test it:
https://www.mediafire.com/folder/kwhxksubf00ny/14.0#skv5hdwgcye4o

I kept the old one here too in case something is not right, as there have been a lot of template refining in between these two commits.

How did your kernel-kit building go? I think the current configs (like 3.14.79) should still work when running ./build.sh.

edit: I think there is a 3.14.79 build with kernel sources by norgo here too:
http://murga-linux.com/puppy/viewtopic.php?p=940611#940611
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1299

PostPosted: Thu 07 Sep 2017, 12:58    Post subject:  

Sailor Enceladus wrote:


I've also tried another Slackware 14.0 (5.7.1) build here at commit 5526 if anyone wants to test it:
https://www.mediafire.com/folder/kwhxksubf00ny/14.0#skv5hdwgcye4o




Shocked

Sailor, you improved it over the old one? No way. I find that most mucho hard to believe Wink
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2548
Location: UK

PostPosted: Thu 07 Sep 2017, 17:35    Post subject: Woof-CE, Git usage, etc
Subject description: ..rant...
 

I see a lot of complaints about recent Puppys, but 01micko and others have done a great job moving puppy into x64 and ARM land, and people are free to contribute fixes via GitHub... it's just that most puppy users can't be bothered to learn how Rolling Eyes .. and THAT is what slows development... other distros can rely on hundreds of users who know git. shell, etc .. puppy devs dont have that luxury.. plus they have to work, barry is retired.. it would be nice if barry sometimes did a PR for woofCE ..

I agree with the above - that building pups from so many different sources creates a lot of complexity ... better to focus on a couple only, I think ..
My choice would be T2(if its alive?), Slackware, CRUX, Debian, Ubuntu .. Or whatever 3 or 4 work best.

Basically I think we should focus on source (t2, crux), .deb (ubu/debian) and slack pups..

But we non-experts (yes me too!!) should be using Git way more, and doing way more of our dev work inside the woof code base.. Git "branches" in woofCE are very under-used .. (Woof-CE still only has like 5 branches?? .. even my crappy CMS uni project had like 45 branches after 6 months of dev work...)

http://rogerdudler.github.io/git-guide/ <-- very easy git guide, explains using 'feature' branches properly..

Using the forum for development means that dev work is CONSTANTLY repeated, lost, dropped, re-implemented, over and over.. This forum is full of ppl posting fixes and asking how to get their fix into woof ...

How to improve the Woof-CE GitHub usage very quickly:

* add to Woof-CE the ability to choose desktop environment (DE) at build time ... With choices like: JWM, Xfce4, LXDE, MATE ..
Each DE choice would simply be a selection of pkgs to be added.. Example, the "JWM" DE might be: jwm + rox + radkys PupApps + ziberts traytools

* If peebee wanted to make a woofCE_lxpup branch and put his work in there, then WoofCE would build LXPups just like his... instead of re-doing the same work for each new release.. ... It's not 01mickos fault (or anyone elses) that he hasn't done that (yet! Wink )..

* If rg66 and Geoffrey pull their fingers out, they could make an woofCE_xfce4 branch, and make woof build nice Xfce4 pups out of the box.. Instead of re-doing the same work for each new release, just make the petbuild scripts..

* Whoever it is that makes MATE desktop pups could do a woofCE_mate branch ... instead of re-making and releasing MATE versions for each new release...

* if I finally get around to woofing an Akita, I will make a woofCE_akita branch, which contains all Akitas custom changes... 01micko or whoever could pull in any changes they like to 'testing' ...

* If i get time, the next Puppy Arcade will be woof-built, meaning all the emulators and related apps will have their own *.petbuild scripts, and so anyone could include (some or all of) those apps in their own woof-built pups.. I'd put it in a woofCE_puppyarcade branch, and 01micko or whoever could move any .petbuilds etc over to testing (if they wanted...) ... but mednafen won't compile on the gcc used in recent Slackos .. for now I wait, and think..

* i have long planned to build a no X pup (without Xorg etc ... it would use instead the framebuffer only, with apps like ranger, vim, vifm, mplayer, netsurf-fb and my CLI pkg manager (with sbopkg/petbuild/etc)... If I finally get time to do it (I have a lot of stuff ready), I'd do it in a woofCE_noX or woofCE_headless branch..

* Puppy app developers (like radky, zigbert, etc) could create a branch called woofCE_myappname, then make only the changes needed to build and include their new app as a "builtin" or repo package.. Each time they updated the app they maintain, they would just need to `git merge origin testing` to get the latest dev branch, then drop their app/PET files into their WoofCE tree, do `git add . ; git commit -m 'updated to v1.2.3'; git push origin woofCE_myappname` ..

* any PETs built manually that work on lots of pups can go in the common repo ... a woofCE_commonpkgs branch could be used, and from that branch, branches like woofCE_commonpkgs_paintown could be created, then updated with the new pkg and pushed to github by anyone who has a pkg to add (pkgs with static compiled apps, pre-built apps taken from popular sites, etc) ..

* A woofCE_fatdog branch that can build FatDog-ish ISO would be a great idea, I'm sure jamesbond, SFR et al could make that happen if they wanted..

* etc , etc...

The key would be to make your branch build your unique pup, without breaking any 'default' builds ...
So in other words, your branch should be able to build all the same pups as the main "rationalise" branch, but yours as well..
Then merging it back into testing or rationalise should be fairly painless..

To Be Fair, Woof-CE Git Branches are a Bit of a Mess

As it stands .... Who knows which branch you should create your new one from? I don't..

This is how it *should/could* be:

master - the branch containing *only* good commits that produced the *official* builds ... only 01micko can merge into master
develop - the "main" working branch, into which most good pull request (PRs) are merged ... only 01micko and others of his choosing can merge into develop

After an official release goes out, you would merge the commit in develop that produced it into the master branch.
The master branch would never contain any commits (version) of Woof-CE that were NOT used to produce official builds..

master would be a reference for all the best versions of Woof-CE that have been made.
Any problems in the develop branch could be reverted simply by taking stuff from master.

Then

feature_x - branched off of develop, adds new feature or pkg to woof-CE .... make a PR, a lead dev tests it, comments its good,and merges back to develop
bugfix_x - branched off of develop, fixes a bug in main branch, can be merged back .... make a PR, dev tests it .. merges back to develop..
puplet_X - branched off of develop, make woof support a new base or new pkg selection (etc) ... after release of Puplet, and testing defaults builds still work, make a PR, to be merged back to develop..
puplet_XY - branched off of puplet_X, helps break down your puplet work into chunks.. use these during your puplet development

In short, normal puppy devs would normally branch off develop, do their work, then create a pull request (PR) for a lead dev to test, and maybe merge into develop.

Also

repo_noarch_X - branched off repo_noarch, add a pkg to repo, others can test, merge back to repo_noarch if its good
repo_common_X - branched off repo_common, add a pkg to repo, others can test, merge back to repo_common if its good

The beauty of the above workflow is that only good, tested work makes it upstream to the main branch,
and everyone can work on different stuff at the same time, while still merging it all together in a (fairly) manageable way..


GitHub can *merge and squash*, so only 1 commit per PR would need to be added to develop or master, keeping the history of changes really clean..
(After a puplet had been made, probably with loads of commits, once it is released a PR can be made, and a single commit can be merged into develop,
like "Working LXDE desktop now available in DE selection - thank peebee!")

NOTE: the 'petbuild' git repo is a little different - you would only create new branches for each BINARY_COMPAT distro puppy gets built from ... so separate branches for the separate distro versions (slackware14.2, slackware14.1 each get their own branch, ubuntu16, ubuntu14 their own, etc) .. and you could branch off of them for each buildscript you added, ready to test and be merged..

A lot of the Puplets (derivatives) are just re-themed pups with diff window managers ... If woof-CE let users choose a desktop environment at build time, half those puplets would not need to exist and any fixes/improvements done to xfce/mate/lxde setups and pkgs could be done in woof-CE ..


Anyway... Working with Git is so EASY.. Something like this works for even very large projects with many team members:


Code:
git clone WOOFURL mywoofdir

cd mywoofdir

git pull origin develop   # make sure you have the latest code (will pull down any new 'commits')

git checkout -b my_new_feature  # create a new branch called 'my_new_feature'

# now do your work, (EG, copy your files into this woof code-base), then ..

git add . # add all changed files to "staging" area, ready to "push" (upload)

git commit -m 'my message' # commit the changes you staged (like saving a new version)

git push origin my_new_feature # push it to github/gitlab (wherever you set it up)

# ..can now create a PR (pull request) for ur new branch.. do that on GitHub, using ur browser
# ..at this point, other ppl might review, fix, update ur Pull Request..

git pull origin my_new_feature  # pull down any updates made by others

# repeat as above....

#
# ... then later, 01micko (or any lead dev) can do:
#

git pull     # get all branches (will now include ur feature branch)

git checkout develop  # go to main working branch

git merge my_new_feature # merge your feature into main code base.... if the PR is reported working!
git merge bobs_new_feature # merge bobs new feature into main code base.... if the PR is reported working!
git merge some_new_feature # merge some new feature into main code base.... if the PR is reported working!


This workflow works for large in-house projects at some serious places, even with large dev teams moving around a lot..

.. there is nothing stopping Puplet devs from setting up a new branch of WoofCE and using that as their base/build tool ... WoofCE could have dozens of branches, each developed by a puplet developer .. then all the good work from the puplets can be MUCH more easily merged into the main WoofCE code base..

You can include Git repo info in ur $PS1, so you dont lost track .. Just Google "Git PS1 prompt" and update your .bashrc or .bash_profile .. The devx should prob include a Git-aware PS1 by default... To get ppl in the mood..


But to be fair, the documentation on contributing to Puppy development is sparse, sporadic and hard to find.. I still can't find good docs on fixing/updating Woof, and I definitely looked around! .. There is nearly nothing about Puppy dev Git workflow ... And something that slows development is constantly having to return to the forum for fixes, news, etc ..

Puppy Needs Better Documentation!

Where are the guidelines on:

1. Creating packages for the common repo? How to get packages in there? Who to contact?

2. Creating packages for the noarch repo? How to get pkgs in there? Who to contact?

3. Creating packages for a slacko14.2-contrib, tahrpup-contrib, or officialpup-contrib repo... they don't even exist.. (yet, stay tuned Wink )

4. Creating buildscripts so others can compile ur packages?


Arch linux does it right ... Puppy needs a big Wiki like theirs .. For

1. Installing

2. Setting up (inc external devices ... joypads, drawing tablets, etc)

3. Using & Configuring Apps X, Y, Z (refers to 2. a lot as Prerequesites)

4. Compiling Apps

5. Remastering

6. Woof-CE ... with kernerl-config, petbuild, remaster info all in one place


Also, Puppy devs dont give out specific jobs ...

Some users should be lead devs.. building the ISOs from Woof ...

Some users should be package builders, maintainers .. adding pkgs to woof for inclusion in any woof-built pups..

Some should be apps devs .. making puppy specific apps..

Some should be testers .. posting issues to GitHub or this forum.. all end-users could do this..

Some should be bugfixers .. fixing the issues posted .. all end-users could do this..

Some should be documentation maintainers... literally just updating the docs, readmes, guides, links, etc ..


Well, what am I doing I hear you (quite rightly) ask?

Ibiblio access:

I am currently working on a package manager for Puppy that will make it a lot easier to compile apps from source (supports petbuild, src2pkg, sbopkg, buildpet), and should make it easier for users to maintain and share their own 'contrib' repos for the pup they are running .. Users would be able to add lots of 'contrib' repos just like on Ubuntu etc .. (Only pkgs compiled by the user using the pkg manager would get added to a users contrib repo.. so pkgs would all have to pass the same checks and be built in the same way.. similar to a ports system + contrib repo ..

To that end, I would LOVE to get my hands on GitHub access to WoofCE, as well as an ibiblio account to host the contrib repos there, but their site won't accept new account requests (CAPTCHA not working..) ..

So, If anyone can help me get WoofCE github access(didnt check if i need permission to PR yet), and an ibibilio account that would be great!

As for the latest Slackos being buggy - I guess YMMV for now - I've been running a recent Woof Slacko (32bit) for weeks and weeks, leaving it running for days, compiling loads of stuff.. All works great for me..

Just my 2 cents. Not trying to offend anyone.

EDIT:

Just to be clear - I am NOT having a go at anyone in particular, or puppy users generally.. I myself have been away doing nothing puppy, life hands u lemons sometimes... But this forum is still one of the nicest places on the entire internet in my book, and is full of an amazing mix of people...

We just need to bite the bullet, download woof and use Github to make our puplets, apps, etc .. Maybe with a new workflow, 01micko won't need to be everyones Saviour all the time ... the guy has a life, you know Wink

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search

Last edited by sc0ttman on Mon 11 Sep 2017, 05:19; edited 1 time in total
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1299

PostPosted: Thu 07 Sep 2017, 18:10    Post subject: Re: Woof-CE, Git usage, etc
Subject description: ..rant...
 

sc0ttman wrote:


But to be fair, the documentation on contributing to Puppy development is sparse, sporadic and hard to find.. I still can't find good docs on fixing/updating Woof, and I definitely looked around! .. There is nearly nothing about Puppy dev Git workflow ... And something that slows development is constantly having to return to the forum for fixes, news, etc ..

Puppy Needs Better Documentation!




Scottman,

Nice post. No need to apologize to anyone or anything. It isn't negativity that permeates here, unlike what Toni, er, I mean wiak, is posting about, it's a constructive talk about what needs to be done.

I slam my head up against what you wrote (and I highlighted above). It took me so many builds over the past year just to learn the ins and outs of a few things of woof-CE...all because I could find no documentation on what I needed to know. Woof-CE building was then (and sometimes still is) a hair-pulling experience modifying and changing some stuff in woof-CE to get it like I want it. I don't blame micko or anyone (especially jilst, who has soldiered like a madman keeping woof-CE going). It is just I feel like Micko and others took me on this boat long ago, we got 1/2 way out into the ocean, and a sub appeared and then down he (and Phil went), escaping to Atlantis while we stayed up on the floating Titanic trying to stay alive. It gets frustrating. Then you see something like Fred's DDog build scripts come along, with all sorts or easy-to-understand customizing possibilities, and you wonder why it can't be like that for puppy. No offense to Toni, er, again,I mean: wiak, but his woof-CE build script (and abilities to modify it) are a step in the wrong direction and are honestly a frigging mess compared to Fred's when it comes to ease of use, and the important thing, customization that is easy to understand. That woof-Ce build script is just a fancy candy-wrapper for woof-CE's current situation and does nothing to address the problems underneath---one of which is: the lack of documentation, as you note.

I keep holding out hope something will change. Phil and Micko have gone MIA, and I completely understand about life getting in the way. But mavrothal hit the nail on the head awhile back in this section: where are the knowledgeable, helpful ones to pick this up, to share the burden possibly, to keep things moving forward when they cannot? Can we not make this happen?? Answer: there aren't any at present, and no structure for them to do so. Submitting to git is not so easy to understand and grasp. And furthermore, as an example, did you see what happen in Barry's Quirky 8.3 thread.....my God, the responses to what he was doing there, everyone picking over absolute stupid sh!t, drove him nuts, to where he ran back to Easy Linux. And I don't blame him one bit. He fixed the major problems, but this is NOT true of our two flagship puppy distros right now (Slacko and Tahr/Xenial). They've got problems that are not being addressed, unlike Sailor E and few others who keep catching them & trying to get them fixed. But heck, Sailor got so frustrated, he made a Slacko 14 5.7.1 and I tried it, and it was & is--with no hyperbole--heads and shoulders above Slacko 700s in terms of stability and no problems. The gist is this: I don't want miracles, I just want the major crap to be fixed, and it is not happening with Slacko and/or Tahr/Xenial.

Oh well, I'll keep trying and soldiering on here, but it gets really hard when you keep doing woof-CE builds (mainly 64-bit), like I do weekly, and the same errors from the dev's creations haven't been addressed not for weeks and/or a month or two, but for several months. It leaves you with a feeling that you're going to be eating dead fish on this boat the rest of your days unless you do something else to get off the boat. Thankfully people like Fred, rg66, Peebee are coming by in their stable speedboats & kindly throwing up some bananas, nuts & ice-cream for those of us left on this drifting puppy-liner (lol, sorry for the terrible imagery and/or allegory).
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 71 of 80 [1197 Posts]   Goto page: Previous 1, 2, 3, ..., 69, 70, 71, 72, 73, ..., 78, 79, 80 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
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.0927s ][ Queries: 14 (0.0110s) ][ GZIP on ]