Lighthouse 64 5.15 Final

For talk and support relating specifically to Puppy derivatives
Post Reply
Message
Author
User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#101 Post by meeki »

gcmartin:
LVM2 is not so bad.
Ok let me justify my first comment. I don't know a thing about Multipath and storage in Linux besides a very general Idea about how they work. I use LVM groups on my server. But besides knowing how to basically manipulate my storage settings I would have no clue how to compile the sucker with correct depends in my current kernel.

My original comment was out of fear. Having broken things many times Its ok to be scared now and then.
Last edited by meeki on Wed 14 Nov 2012, 00:01, edited 1 time in total.

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

Re: Lost X input while installing monodevelop-2.8.1

#102 Post by Q5sys »

edwardb wrote:Greetings.

i was hoping to get mono installed onto this LH64 final version, and needed monodevelop-2.8.1.

While installing monodevelop-2.8.1, there's the lvm2 dependency that needed to be installed.

While it was installing, X crashed, and was continually printing onto stdout/err console "cannot exec: /bin/bash ..."

After shutdown and reboot into X using the same savefile, the usb mouse and usb keyboard refuses to work. We couldn't even use the CTRL-ALT-F<key> combination to get into the text consoles.

All we could do was press the power button, listen for the bark, and shutdown the system.

Is there a fix for this? especially losing mouse and keyboard in the xwin desktop?
There are somethings that just simply dont work well to compile into the very environment you are using. Some things (like lvm), you need to either A) edit your ./configure script or make install destdir; and install them somewhere else to build a package out of them. If you try to just do a normal install you will be overwriting or changing files you system is actively using. In those cases it's best to build the package, and then manually place it in the base SFS (if you're sure you got everything working right) and then reboot using that SFS.

Another example of this is that you have to usually compile proprietary x.org drivers from command line with x not running.
gcmartin wrote:LVM2 is not so bad. It has some great and distinct advantages especially for those who of us who expect to maintain data over both time and spacial. Its been around so long that most all issues have been cleared long ago.
Here to help
Can you compile it for us since you're more aware of it than the rest of us are.
It'd be a big advantage as you've stated if it was available for everyone.

gcmartin

#103 Post by gcmartin »

Thanks Q5sys for your comments on PET and SFS building.
Q5sys wrote: ... Can you compile it for us since you're more aware of it than the rest of us are.
It'd be a big advantage as you've stated if it was available for everyone. ...
I had made my comments because, I thought that another member in the community has already addressed this and I thought that it may be compatible with current LH64.

Beyond what Q5sys is sharing, I would like to give a little more insight. As I remember, JamesBond (or someone) added LVM support via a PET such that the booted system would be able to recognize and work with an existing LVM filesystem. The benefit that he produced was not to take Puppy into a new direction, but rather, to give it intelligence to recognize and use an LVM if it were present. FATDOG and other PUPs with this are excellent distro to manipulate data/files/etc "outside" of the primary distro that built the LVM. That's the beauty of Puppies. Fast, and robustly featured.

This was an attempt to be helpful.

Q5sys, I know you have great skills and insights in the LH64 build process. I would trust what you produce as I'm sure you would thoroughly test it. Your effort would be an addition to the PPM effort, I would assume.

Here to help


edwardb
Posts: 10
Joined: Mon 09 Jul 2012, 21:19

#105 Post by edwardb »

meeki wrote:Were you building them yourself???? or installing them from a Slax package?
Just going the path of least resistance:
Installing mono as a .pet using the Package Manager.

i haven't even gotten to the point of a development environment, except for what devx already provides...

edwardb
Posts: 10
Joined: Mon 09 Jul 2012, 21:19

Re: LVM in LH64

#106 Post by edwardb »

gcmartin wrote:Hi @Edwardb
Edwardb wrote:... there's the lvm2 dependency ...
i think JamesBond did some work with LVM2 on a 64bit platform back in the FATDOG 5.2x days. He may still have the utilities he provided for this somewhere in his arsenal. I seem to remember a PET that addressed dependencies,....I think.

LVM2 is not so bad... [snip]
Here to help
Hi @ gcmartin.
i've dumped lvm2 for btrfs.
i only mentioned lvm2 because the mono package seemed to have a dependence on something in the lvm2 "pet" package...
But thank you anyways.

edwardb
Posts: 10
Joined: Mon 09 Jul 2012, 21:19

Re: Lost X input while installing monodevelop-2.8.1

#107 Post by edwardb »

Q5sys wrote:
edwardb wrote:Greetings.

i was hoping to get mono installed onto this LH64 final version, and needed monodevelop-2.8.1.
There are somethings that just simply dont work well to compile into the very environment you are using. Some things (like lvm), you need to either A) edit your ./configure script or make install destdir; and install them somewhere else to build a package out of them. If you try to just do a normal install you will be overwriting or changing files you system is actively using. In those cases it's best to build the package, and then manually place it in the base SFS (if you're sure you got everything working right) and then reboot using that SFS...
Hi @ Q5sys,
hehe... one thing at a time. i haven't even gotten to the point of building ANYTHING in this environment, yet; this is just setting it up first... :-)

However, thank you for explaining the damaging nature of the .pet files i install using the Package Manager. What you said makes sense. Up to now, i assumed installing .pets were guaranteed SAFE for the system. i guess i'm sorely mistaken.

This then brings up a few things:

1) if .pets are so damaging to the system, why are they allowed to continue to exist and be referenced by the Package Manager when "damage" *is* being done to the system that installs them? (this goes with just about anything file-system related... at least with what i've experienced...)

2) With that being said, why don't the creator of the .pet opt for the .sfs route *IN THE FIRST PLACE* to spare the user the grief of a ruined system? (especially when the though of backing up the .savefile came as an afterthought, too late...)

3) Is there a restore feature via CLI that undoes the damage the .pet has done? In my case, i cannot enter into X, so i'm left with doing the repairs in console mode...

BTW, feel free to split up and move this thread if it doesn't belong here. i'm still a noob and am feeling my way around here...

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

Re: Lost X input while installing monodevelop-2.8.1

#108 Post by Q5sys »

edwardb wrote:
Q5sys wrote:
edwardb wrote:Greetings.

i was hoping to get mono installed onto this LH64 final version, and needed monodevelop-2.8.1.
There are somethings that just simply dont work well to compile into the very environment you are using. Some things (like lvm), you need to either A) edit your ./configure script or make install destdir; and install them somewhere else to build a package out of them. If you try to just do a normal install you will be overwriting or changing files you system is actively using. In those cases it's best to build the package, and then manually place it in the base SFS (if you're sure you got everything working right) and then reboot using that SFS...
Hi @ Q5sys,
hehe... one thing at a time. i haven't even gotten to the point of building ANYTHING in this environment, yet; this is just setting it up first... :-)

However, thank you for explaining the damaging nature of the .pet files i install using the Package Manager. What you said makes sense. Up to now, i assumed installing .pets were guaranteed SAFE for the system. i guess i'm sorely mistaken.

This then brings up a few things:

1) if .pets are so damaging to the system, why are they allowed to continue to exist and be referenced by the Package Manager when "damage" *is* being done to the system that installs them? (this goes with just about anything file-system related... at least with what i've experienced...)

2) With that being said, why don't the creator of the .pet opt for the .sfs route *IN THE FIRST PLACE* to spare the user the grief of a ruined system? (especially when the though of backing up the .savefile came as an afterthought, too late...)

3) Is there a restore feature via CLI that undoes the damage the .pet has done? In my case, i cannot enter into X, so i'm left with doing the repairs in console mode...

BTW, feel free to split up and move this thread if it doesn't belong here. i'm still a noob and am feeling my way around here...
i think you misunderstood me. PETS are fine. thats why we use them. :)
I was talking about compiling from source code and building things that way. when you are compiling something it 'can' cause issues when in the process you overwrite something thats being used to run the system.

if you use pets you shouldnt have anything to worry about. :)

gcmartin

#109 Post by gcmartin »

Here's an example of how a comment can have un-intended consequences.
edwardb wrote:... for explaining the damaging nature of the .pet files i install using the Package Manager. What you said makes sense. Up to now, i assumed installing .pets were guaranteed SAFE for the system. i guess i'm sorely mistaken ...
I'm sure that Q5sys was attempting to share a reason why one developer might prefer to use a SFS versus using a PET. Namely, if a SFS is used, it reduces the system effort that a developer would need to address in testing of the product that is being added to the running system. Simply SFSs can be installed in a layered fashion, while PETs are installed via PPM and insert directly into the OS. Problems do NOT ALWAYs occur and in some very-rare occasions, a module may get misplaced. (Without going into particulars, something similar could, again rare as well, could happen with SFS use which would require the developer to do research to understand.)

PET development produces the same functionality within the distro where its REPO presents it via PPM. And, PETs understanding is built-into the PUPs in each's PPM.

For the most part, excepting for one recent occasion in all of my Puppy years, I have had no issues in PET use. Further, in all cases where a developer has produced a PET and an SFS, I have never had a problem. This doesn't address which to use. Its just one experience.

There are concerns on both sides of the fence for either of these 2 approaches that add functionality to a running distro. But, Puppy's PPM has a long history with PETs in system integration, while the SFS have had 2 specific tools added to Puppyland to assist understanding users in SFS manipulation(s).

I don't think Q5sys intended to alarm users in their use of PPM/PETs or anything of such.

None of us should shy away from PET development in fear because i don't believe he intended such.

All developers should take into account that both PETs (used in PPM) and SFS (used by 3 other system facilities) add functionality to a given distro (assuming you are using its DEVX). And, also, its easy for any one of us to see that a PET's size and a SFS's size is not "dramatically" different. (I have a specific example where a distro developer made both a PET and an SFS and the PET is actually smaller that the SFS. And, there are other sizings where the PET and SFS are of equal sizing)

We are all here to try to help each other.

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#110 Post by meeki »

edwardb

What you installed was not a pet


I made a video showing what happened to you and how not to download slax packages in the future.

VIDEO SHOWING WHAT I THINK HAPPENED
http://youtu.be/JfaL9nI_K8s

Most people that make pets dont have depends.

Hope this helps

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#111 Post by meeki »

Hey edwardb

I build a bunch of stuff on LHPUP and the devx for doing this is a great tool. However many depends are out there that were never used to build LHPUP so they do not end up in the Devx. As of LHPUP 515 Ive started making a pet every time I need to build somting I make a pet of the depend. You can find the growing list of them here >>> http://lhpuppetsfs.puppytune.org/

I do not have a copy of mono. I did try to build it for ya but ran into a lib issue with the current devx.

Q5sys is also working on getting us a 64bit dev location on the forums and making a dev repository so we all can work from it in ftp form.

LHPUP has just recently took off again.... and allot of us pet/sfs makers are trying to fill the void.

Pets that are approved by Tazoc (the maker of this OS) as safe for LHPUP can be found under the LHPUP update button under the install. Next to that are approved SFS's. The 3rd one PPM is more of a users best choice and are not always safe.

PETS are safe if from approved source. IE by Tazoc. My pets and pets you download from a users linked here or on the web are not 100% safe. Its like downloading an android app outside of the Google app store. These pets are not linked By Tazoc within LHPUP. There is nothing stooping me or any user from making a malicious pet.

I make my pets and if they run on my system I link them here. Users reply to me and tell me if my pet works or if not they tell me the issue. I refine them and then ask Tazoc to place them into the LHPUP update repo when the pet is ready. Sometimes I don't ask and he jsut likes them and does it.

Meeki

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#112 Post by Q5sys »

gcmartin wrote:I'm sure that Q5sys was attempting to share a reason why one developer might prefer to use a SFS versus using a PET.
Actually I was not. I dont know where PETs came into the topic. I wasnt talking about PETS nor did I comment about them at all. I was speaking about compiling.
I dont have a problem with PETS. I use them quite often.
How do I choose... well this simple flow chart explains it quite nicely.
Image

Back on topic... I mentioned SFS files in my post because i was talking about the 'base sfs', in our case thats L64-514.sfs thats on the ISO file. (or L64-515.sfs if you're using the new version) For me, volume management, which LVM is... should always be in the core SFS and not in a save file SFS (2fs, 3fs, 4fs, etc), or live media or some other format... added in with a pet.
Something such a volume management is such a core function, that it should be built in from the beginning, because so many other things depend on it.
gcmartin wrote:Namely, if a SFS is used, it reduces the system effort that a developer would need to address in testing of the product that is being added to the running system.
I dont see how that's the case. A Dev still has to check to see if it works. Its not as if we just bundle SFS files and never bother to check or test them. Its no different than testing a pet... although it could be stated its more effort to test a SFS since it requires (in most cases) a complete reboot, unless you're using shinobars SFS load on the fly.
gcmartin wrote:I don't think Q5sys intended to alarm users in their use of PPM/PETs or anything of such.
Correct.
gcmartin wrote:None of us should shy away from PET development in fear because i don't believe he intended such.
Agreed.
gcmartin wrote:And, also, its easy for any one of us to see that a PET's size and a SFS's size is not "dramatically" different. (I have a specific example where a distro developer made both a PET and an SFS and the PET is actually smaller that the SFS. And, there are other sizings where the PET and SFS are of equal sizing)
Theoritically, pets should always be a tiny bit larger because they have 1 extra file, mainly the pet.specs file. Otherwise the files between a pet and SFS should be exactly the same. The varying size difference comes down to compilation options (if made by two different developers), and compression styles. (tgz vs txz)

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#113 Post by Q5sys »

meeki wrote:edwardb

What you installed was not a pet


I made a video showing what happened to you and how not to download slax packages in the future.

VIDEO SHOWING WHAT I THINK HAPPENED
http://youtu.be/JfaL9nI_K8s

Most people that make pets dont have depends.

Hope this helps
Good video and explanation. I kinda agree with you that puppy should be the only default choice. Usually most slack packages will work (somewhat). But since Slack is constantly updated... and our systems arent... it wont take long for version skew to get you no where good.

Side note: Its always fun to see someone who you've only dealt with online. Or in this case, heard someones voice you only imagined. lol
You've got a decent voice (you work in radio? haha). Maybe you should make all of our Video tutorials. ;)

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#114 Post by jamesbond »

meeki - I like your game.sfs.

Q5sys - I like your diagram. With the exception of the "txz" part, that's exactly the decision I go through when I decide to go with pet or sfs.

cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#115 Post by meeki »

jamesbond
meeki - I like your game.sfs.
Thanks!!!

I got my hands on the steam beta installer to start work on getting it running on LHPUP.

I then spent 10 hrs today installing a multi glibc install of 2.16.0 and I knda got it working. Still steam ATM requires a true multi lib setup so turns out all the work was for nothing.

I found out that steam may or may not make a package that requires glibc 2.15 or greater.

I miss my steam games but not enough to leave LHPUP

For now I will keep poping out games that work as a sfs.

I jsut got 2 more working and will get them out tomorrow.

1) TrippleA - A risk like game with tons of maps and scenarios.
http://triplea.sourceforge.net/mywiki/ScreenShots

2) WARSOW!!! its knda fun but needs a real graphics card. 256mb should do ya.
http://www.warsow.net/

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#116 Post by Q5sys »

meeki wrote:jamesbond
meeki - I like your game.sfs.
Thanks!!!

I got my hands on the steam beta installer to start work on getting it running on LHPUP.

I then spent 10 hrs today installing a multi glibc install of 2.16.0 and I knda got it working. Still steam ATM requires a true multi lib setup so turns out all the work was for nothing.

I found out that steam may or may not make a package that requires glibc 2.15 or greater.

I miss my steam games but not enough to leave LHPUP

For now I will keep poping out games that work as a sfs.

I jsut got 2 more working and will get them out tomorrow.

1) TrippleA - A risk like game with tons of maps and scenarios.
http://triplea.sourceforge.net/mywiki/ScreenShots

2) WARSOW!!! its knda fun but needs a real graphics card. 256mb should do ya.
http://www.warsow.net/
Ive got Assultcube done and ready to do. meeki... you mind testing it for me before public release.
i have a bunch of games on my slack box... but thats cause its got glibc 2.15.
but dont worry about glibc issues for that much longer... something is coming... ;)

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#117 Post by meeki »

Q5sys
Ive got Assultcube done and ready to do. meeki... you mind testing it for me before public release.
Send me a link I'll play it for 10-20min see if it works fine.
i have a bunch of games on my slack box... but thats cause its got glibc 2.15
Yep... I have taken a different path. I found out you can run a second instance of glibc. like a little sandbox. The bad is you have to build a bunch of other stuff with it as well so all told its 232MB. The time functions of Glibc don't run well in this instance. So it only works on stuff that does not use it. Its unsafe as hell too because unless you go modding the make file of the stuff your installing it does not play nice. Also if you install something that dynamically links to something outside of the instance and that linked function plays with Glibc like a link to Rox that rox then calls on the native glibc it will crash your ass. This is why I will not release this SFS. Its shady to put it nicely.
but don't worry about glibc issues for that much longer... something is coming
Look froward to it. However this is far from the solution to the issue. Its not Tazoc's fault. Its the pace of developers and where they build stuff. We did not have a Glibc 2.15 issue until unbuntu LTS 12.04 the good news is we now might get a reprieve of 5 years until the next LTS.

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

#118 Post by Q5sys »

meeki wrote:Q5sys
Ive got Assultcube done and ready to do. meeki... you mind testing it for me before public release.
Send me a link I'll play it for 10-20min see if it works fine.
Sent to you. Along with MegaMario.
meeki wrote:
but don't worry about glibc issues for that much longer... something is coming
Look froward to it. However this is far from the solution to the issue. Its not Tazoc's fault. Its the pace of developers and where they build stuff. We did not have a Glibc 2.15 issue until unbuntu LTS 12.04 the good news is we now might get a reprieve of 5 years until the next LTS.
Check your PMs. :)

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#119 Post by meeki »

Last edited by meeki on Fri 16 Nov 2012, 04:05, edited 1 time in total.

User avatar
meeki
Posts: 122
Joined: Mon 23 Jul 2012, 04:48
Location: Portland OR

#120 Post by meeki »

Games:

NAEV:

http://wiki.naev.org/wiki/Naev
Naev is a 2D space trading and combat game, taking inspiration from the Escape Velocity series, among others.
Image

NAEV
SFS http://lhpuppetsfs.puppytune.org/games/ ... x86_64.sfs 233MB
MD5 http://lhpuppetsfs.puppytune.org/games/ ... 64.sfs.md5


:)

Post Reply