Introducing Just-Lighthouse64

[Q5sys]

• How are they suppose to do this so that it is acceptable to you?
• where is it suppose to be delivered so that you know what the need is?
• what is the timetable?
• How will it be sent back?
• what specifics will they be required so that the whole operation is smooth?

Uh... they can send me a PM and we can talk about the details. Each person is going to have a different scenario, trying to list them all out in a forum post would be rather silly.
Pretty much everything you asked I would talk to whoever on a person by person basis. All of the details would obviously have to be discussed, and since this is a forum and it has a Private Message Function... that seems like the obvious place for someone to start... or if it has to do with something for Mariner64, they can post a message in the thread.

• why does everything with you need be testy?

It doesn't, but you're asking what seems to be an entirely unneed question. If people want me to help them... they have to contact me. Seeing as how this is simply done through a PM... i see no reason to treat people like children and behave like they aren't intelligent enough to figure out how to contact me.

This forum is full of very intelligent people. To believe that anyone who has manged to:
A) register here,
B) install linux,
C) have even the slightest understanding of what compiling source code means...
is unable to figure out how to contact me, is IMHO, quite insulting.

[gcmartin]

As I asked in the prior thread, let's move on. Put that testy behavior behind.

Your explanation can be interpreted to mean "you want it done via PM". Now that wasn't too insulting, now, was it?

Let's move on.

[Q5sys]

Put that testy behavior behind.

Maybe if you stopped trying to give orders and stopped treating people like idiots, people wouldn't take your words to be so rude. You do not have the right to tell me how to behave, but yet here you are... doing just that.

Your explanation can be interpreted to mean "you want it done via PM". Now that wasn't too insulting, now, was it?

To be blunt... I think each person in this forum and on the internet can interpret what I mean on their own. I believe they are smart enough to do so on their own without needing someone else to 'interpret' my words for them. You did the same thing to stemsee earlier in this thread.

What is suggested is that if the toolchain is updated, some/many/most current issues may disappear.

I also fully understand what Q5sys explains about the toolchain. Do you not feel yourself frequently overstepping the mark?

Is there a reason you feel you have to 'explain' what others say?

Let's move on.

If you dont want me to reply to a question... then dont ask me one.
If you dont want me to comment... then perhaps you shouldn't direct a comment towards me or try to 'interpret' my words for others.

Shall I give you a reminder... http://q5sys.info/gc-pm-2013-02-08-4.png

As for everyone else, can we return to the technical discussion?

[gcmartin]

Q5sys, Now that you've got that out of your system...Let's move on.

[Q5sys]

Dry Falls, PM coming your way.

[gcmartin]

Downloaded "Retro", md5 OK, burned and booted. No issues. Great distro packaging!

[Dry Falls]

L64-3.18.5.iso is uploaded, as are devx, kernel sources and 5_KDE (uploading as we speak). These are different files than those on the 'ExtraSfs' disk images. I expect we can rename them and the distro-specs/hostname if and when testing looks favorable.

note: gdrive is not letting me upload the md5 file ("security", I'm sure) so the md5 id for the Just-Lighthouse iso is:

Code: Select all

f2725453a77d3a6768130b40be210c97

Thank's all.


df

[rokytnji]

Went through all 10 pages before risking a reply in case this error from page one was covered.

Code: Select all

...FATAL:setuid_sandbox_client.cc(282)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/google/chrome/chrome-sandbox is owned by root and has mode 4755.. 

Then

chmod & change permissions...that suggestion didn't work.

from

http://www.murga-linux.com/puppy/viewto ... 102#823102

Seeing that I ran through the same issue with Vivaldi 32 bit browser in my Salix 14.1
install. I run the browser with sandbox disabled and it runs fine.

https://vivaldi.net/forum/vivaldi-brows ... -slackware

Just info is all I am posting. What I did should work for any other browser with a sandbox. I would think. If not. Never mind.

[Dry Falls]

http://www.murga-linux.com/puppy/viewto ... 102#823102

Seeing that I ran through the same issue with Vivaldi 32 bit browser in my Salix 14.1
install. I run the browser with sandbox disabled and it runs fine.

https://vivaldi.net/forum/vivaldi-brows ... -slackware

Just info is all I am posting. What I did should work for any other browser with a sandbox. I would think. If not. Never mind.

Code: Select all

chromium-spot --no-sandbox

This effectively solved the problem of raising the browser window, but I still got a "snap" error message concerning the nss library files. Funny thing is that chromium37 worked fine with the fathouse k3.16.2, but not chromium40, both slackware versions I'd rebuilt for lighthouse. The problem must be in the kernel configs.

I tested this this morning and last night. I recompiled k3.16.2 under chubby (my full slackware 14.1 lighthouse upgrade) with the original fatdog .config file. Moved the new Just-Lighthouse base file into the fathouse directory and booted off the newly made kernel. Then recompiled again from firstrun/ram, extracted the kernel, modules and new source and rebuilt the initrd.xz to accomodate and rebooted with the even newer kernel.

Chromium40 worked right off, and in fact, I'm posting from it right now. I think I'm going to go ahead and remaster this and upload as a new fathouse-retro. It's working really well.

The next step would be to analyze the .config file for k3.18.5 and k3.16.2 to see where the difference lies. Thanks for bringing this up, since it directed me to some experimental symlinks inadvertently left in the Just-Lighthouse remaster.

When I get this figured out, I'll upload a delta file for the Just-Lighthouse base file. Hopefully that will fix the error.

df

edit: well, it's working fairly well. Now no 32 bit lib function. Kept the new kernel source and initrd/kernel modules but put back the kernel made with chubby. Now it's really working really well. Sometimes ya just have to cheat!

[Dry Falls]

Went ahead and made new iso's of Just-Lighthouse and Fathouse-Retro, fixing some of the silly errors in the last upload. Everything's up (including a bloated 3.16.2 kernel source, should anyone wish to see what went wrong -- or did'nt). I'd say it's all finished and ready to go, which is another way of saying the first issues were premature, but now it's actually ready for testing.

df

[stemsee]

Do you mean the 14.1 upgrade version? That's the one I am waiting for.

[Dry Falls]

Do you mean the 14.1 upgrade version? That's the one I am waiting for.

Chubby works, but it's "ugly". That is to say, some of it doesn't work. I think this version (it is 14.1, but not a "complete" upgrade) would be more suitable to use if a "full" upgrade is desired. Chubby is just that, chubby. It needs downgraded bit by bit till I can figure out where the problems lie.

So much easier the other way around. There are some things I wouldn't want to upgrade in Just-Lighthouse. G-slapt would, for example, downgrade seamonkey32 to 31 because the latter is in the 14.1 repo while the former is a mere 14.0. There is quite a lot which hasn't changed between 14.0 and 14.1. Some have gotten worse, like ntfs3g between 2012 and 2014.

Then there's this to consider: Slackware is supposed (so I've heard) to come out with another new version this year. What I've started is an upgrade to the devx file (automake, cmake, qt, etc.), not the base file, which is already about as heavy as I want it and still call it a puppy linux. The thing is, there's still a lot lighthouse will do without the devx loaded, and I kind of like that.

Maybe you could look at the package list (var/log) and let me know what you consider needs changing? That would help, considerably, to uninstall something and replace it in either the base file or devx.

But if you're still interested, I could upload the chubby basefile, initrd and kernel as a package, but be for-warned: it weighs 491 and limps considerably to the left.

df

[stemsee]

upload! upload! Many hands make light work.

[Dry Falls]

Many hands make light work.

Ok. This time tomorrow (I have to wait till the witching hour) L64-Chubby.iso (658M) should be available. I'll post the link when it's done. I've already made a few slackware downgrades, but not many. Check out G-slapt, because at this point, I don't remember which. I think udev was the main one.

Things to check: puppy frontend misbehaves. Font is ugly on some boxes. At bootup, udev cannot load watches directory. PPM is broken (cannot install pets, only txz). These all work correctly in Just-Lighthouse and Fathouse-Retro. In addition, Fathouse-Retro runs the new sandbox/chrome browsers (whether I like them or not is beside the point) which tells me there is something still missing in the dotconfig/ubuild script during the kernel build.

Try running without devx. I suspect there may be some mistakes in /var/log/packages, left in during a remaster which really belong in the devx. I've been working on the other distros and can't remember if I'd fixed it or not (old age syndrome) in this one. Seem to have gotten my notes mixed up.

By the way, Chubby comes with Icecat installed (not firefox). Much of the documentation (locale, docs, man etc) is in the documentation.sfs. Slaptget KDE apps/libs upgrades are in the 5_KDE sfs files.

Have fun!
df

edit: running chubby now -- no downgrades installed (that was a different remaster). Devx is pretty much included (make, cmake, automake, qt, ruby, perl5, python, etc. from slackware 14.1)

[stemsee]

Here is a rough idea for removing the devx files from the running system and moving them to a newdevxdirectory with 'tree' from devx. Could change mv to rm if not needed. I didn't test it. Too lazy! Name the script 'treex' make executable and place in 'path' /usr/sbin/ or wherever.

Code: Select all

#!/bin/sh
#call script like this  treex

echo "Enter path to newdevx directory"
read newdevx
mkdir -p $newdevx
echo "Enter path to mounted devx.sfs dir"
read devx
cd "$devx" 
pwd 
for dir in `ls -R | grep ":$" | sed -e 's/:$//' -e 's/^/ /' -e 's/-/|/'`
do
mkdir -p $newdevx/$dir
done
cd ../../../../
for file in `tar cf - $devx | tar tvf -|awk '{print $6}'|grep -v "/$"`
do
cp -f $file $newdevx/$file
rm -f $file
done

sync
mksquashfs "$newdevx" ~/LH64-Chubby-devx.sfs -comp xz

EDIT started testing.
updated

[Dry Falls]

that will be handy. Thanks. meanwhile,
Chubby is here

df

edit 8March: fixed /var/log/packages - uploaded L64.sfs for Just-Lighthouse @ g-drive;
updated devx to ExtraSfs @ gdrive

[gcmartin]

Has anyone noticed the md5sum for Chubby? I have downloaded several times and, in each case, this is the computed value I'm getting.

Code: Select all

2894c3a4c504c2075ab09ddbf36dc333  L64-Chubby.iso

It does not match the one that is posted at the download site.

[stemsee]

I didn't use an md5 and I had no problem! What does that tell you?

[gcmartin]

I would guess that if you get the same md5 I got, that the website needs an updated file.

Is yours the same? If so, it makes it easy for DF to do a copy-paste update to the site.

[Dry Falls]

Code: Select all

2894c3a4c504c2075ab09ddbf36dc333

is correct.

df

edit: fixed