If X tried to start and failed should produce a /var/log/Xorg.0.log file. Also the /initrd/tmp/dmesg.txt file could be informative and maybe the /initrd/tmp/bootinit.log file

@norgo had success with his testing branch iso so I burned the one from
my new woof-CE testing branch (yesterday afternoon) to a DVD and tried
it on a pc with intel graphics (X wouldn't start on my HP ATI Radeon)
and it works.
I'm booting from the DVD with a save file on the hard drive.

For reference, the previous errors (now gone in 6e9bb39?) were "missing xorgwizard-automatic, line 113 of xwin" in one very recent build, and missing "FreeSans" font errors in a slightly older one... I had those errors on both machines mentioned above, and in a VM.

... Now some general observations..

1. Is the missing fonts message that prevented my desktop loading up (in previous builds) related to not including pTheme?

2. JWM is crap at working out 2 monitors, and moving them around is a real pain - compared to the drag and drop UI that Xfce provides.. Any way round this? Zarfy, maybe?

3. Does the Universal Pup Installer insist on overwriting the MBR of every drive/disk that uses GRUB? (or is it just me?)... Seems every time I try to use the Universal Installer, it insists I replace my MBR with mbr.bin (or other).. Can the Universal installer not work out I have a working GRUB, just leave the MBR?

5. Where is the documentation about adding new petbuilds and pet packages to Woof? I want to create a new branch and make it build an Xfce pup (ideally... baby steps)..

6. I've noticed that none of the following keys works as they should in Urxvt: Crtl-Left, Ctrl-Right, Home key, End key ... Should this be fixed in /etc/profile, or ~/.bashrc? i'm pretty sure i've got a puppy bashrc with all these fixes in it somewhere if anyone would prefer them working in woof-built pups..

6. I've noticed that none of the following keys works as they should in Urxvt: Crtl-Left, Ctrl-Right, Home key, End key ... Should this be fixed in /etc/profile, or ~/.bashrc? i'm pretty sure i've got a puppy bashrc with all these fixes in it somewhere if anyone would prefer them working in woof-built pups..

If Ctrl-Left and Ctrl-Right are the keys that switch you to a different virtual window I've always found that shortcut just annoying. I'll be playing a game and the desktop will randomly switch to a different one where my game isn't on instead of doing what it's suppose to inside the game. I think it was Tahrpup that had this issue, as I remember the "pink square" moving left and right when my screen disappeared. Might have been Alt-Left/Right though, haven't experienced the issue for a while now.

The Slacko64-6.9.9.9 frugal-install the I use a few times a week has started to display helter-skelter behavior (freezing screens, programs randomly refusing to open, etc) . Don't understand as everything was running great for a few months, with no new add-ons (or anything) have been applied to this latest release. Only thing that has changed is that I like to plug the USB drive that has all these frugal-installs into many of my different machines here-----and this new Slacko64-6.9.9.9 does not like this one bit.

Sure is a stark contrast on things when I throw Sailor E's slacko 5.7 build (into any machine) and everything just stinking runs like wildfire, no matter what I've thrown at it, I can't even get it to hiccup (and I've been doing crazy qt stuff with it, lol). Maybe I need newer systems to reliably run all of Micko's later creations; makes me sad Wife won't be having any of that soon, unfortunately. My newest hardware is 6 yrs old (i3 laptop), and the others are 8-19 yrs old (the oldest being a Pentium 2.0 I try to keep going, lol, and it does have a 1GB of ram, in its defense of staying relevant).

Also, why don't the built-in pkg file lists contain full file paths on each line, like in the ~/.packages/*.files of user installed packages? Is there a reason?

Seems very "pre-woof" .... Would make more sense if user pkgs and built-in pkgs listed their files in the same format...

I'm trying to write a command line package manager for puppy, and finding out the contents of built-in packages becomes very messy indeed because of these 2 problems -> when a file is in two packages (/usr/bin/gnumeric and /etc/file/gnumeric), trying to work out which pkg the file comes from starts to be a real pain if any of those files come from a pkg that lives in the ADRV..

(Sorry if this is the wrong place to post! ... And thanks for all the great work on puppy and woof-CE!)

Sure is a stark contrast on things when I throw Sailor E's slacko 5.7 build (into any machine) and everything just stinking runs like wildfire, no matter what I've thrown at it, I can't even get it to hiccup (and I've been doing crazy qt stuff with it, lol).

Thanks Belham! I'm using it as my main OS too. I tried making another 14.0 build at commit 5506 with kernel 3.18.66. Might upload it later, although this one is missing a few more deps that will probably need to be resolved or re-added to adrv first.

sc0ttman wrote:

Seems very "pre-woof"

I think that's a little harsh since the adrv feature is still pretty new. Your feedback is possibly useful though.

P.S. Are you planning on making a new Puppy Arcade? That seems to be a quite popular puppy still and a neat concept.

I think that's a little harsh since the adrv feature is still pretty new. Your feedback is possibly useful though.

P.S. Are you planning on making a new Puppy Arcade? That seems to be a quite popular puppy still and a neat concept.

I'm one of the worst offenders for producing 'pre-woof' mess... So no offence intended obvs..

And I will possibly do it, If I make a new one, I will use some sleek frontend like EmuStation as a frontend to my frontend (Rom-Loader) ... That will do away with the old-school, clunky GTK interface, but will retain all the features of Rom-Loader (custom configs per ROM, etc) .. Just needs better bluetooth gamepad support for PS3, PS4, XBOX360 etc ... But I doubt anyone is interested by now and I'm waiting on a job application, so dunno whats next .. Depends.. We will see.._________________Akita Linux, VLC-GTK, Pup Search, Pup File Search

The Slacko64-6.9.9.9 frugal-install has started to display helter-skelter behavior (freezing screens, programs randomly refusing to open, etc) . Don't understand as everything was running great for a few months, I like to plug the USB drive that has all these frugal-installs into many of my different machines here-----and this new Slacko64-6.9.9.9 does not like this one bit.

Maybe I need newer systems to reliably run all of Micko's later creations. My newest hardware is 6 yrs old.

The newest Linux 4 series kernels do seem to be a little buggy.
Finding one that is well bug fixed is an issue.
01micko has said, it has been one of the issues, he has been trying to overcome, in final releasing Slacko 7.0
Linux kernel 4 series seems more about providing support for the newer or newest hardware and not trying to support old hardware.

Example:
I have a very new computer with latest hardware.
Any of the Puppies using kernel 3 versions just do not have full 100% support for the hardware.
Kernel 4 versions do give me 100% hardware support.

The latest Puppy versions including Slacko 6.9.9.9 can easily change to using a different (older) kernel.
The ability is built in.

In a console enter:

Code:

change_kernels

This is the program to use to change to using a different kernel._________________I have found, in trying to help people, that the things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected

I'm not sure it's that simple (but that may be my lack of understanding) as I think the kernel has to be built with all the patches for aufs - this is what kernel-kit in woof-ce does to build the Puppy kernels.......

The contents of that end up being copied into Puppy z drive (which I presume can be read by Puppy initrd (I haven't checked that). However, the initrd-progs/0initrd/sbin/not_a_huge_kernel_stuff code you refer to doesn't seem to be sourced by the 3builddistro-Z script as yet so aufs will not be working with such a kernel (the kernel contents are themselves extracted in kernel_pkg.sh and moved into the z drive):

I haven't actually tested if what I say is correct, but that is my reading of the current woof-CE-testing scripts situation. I'm certainly looking forwards to the code currently being stored in not_a_huge_kernel_stuff being implemented since woof-CE stretch building users seem to do a lot of fluffing about finding kernels to use when it would be so much more convenient (and secure maybe) to be able to simple use a stock kernel in Puppy like you have suggested Toni.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum