Lighthouse 64 602 Beta2 with GIMP-2.8.4 (6-29-2013)

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#436 Post by don570 »

delete /usr/bin/mtpaint

rebooting should return old mtpaint (I think??)

________________________________________

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#437 Post by edoc »

don570 wrote:delete /usr/bin/mtpaint

rebooting should return old mtpaint (I think??)

________________________________________
No joy on that ... any other ideas as to how I might restore mtpaint, please?

Using GIMP for simple editing is a real nuisance.

I thought it used to be that one only needed to click on an installed PET and it would uninstall but I get an install message rather than an uninstall message when I try that with yours.

WDYT?
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#438 Post by wjaguar »

edoc wrote:any other ideas as to how I might restore mtpaint, please?
Extract the original binary from the distro, and copy it to /usr/bin
That is, mount the ISO, unpack with unsquashfs the SFS contained within, and there under squashfs-root/usr/bin you'll find the original mtpaint binary.

BTW, the cause of problem is a version conflict with libtiff: Fatdog 630 provides libtiff.so.5, and mtPaint compiled in there gets to require it - while Lighthouse is still stuck with libtiff.so.3
(Which you could have found out for yourself, if you ran "ldd mtpaint")

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#439 Post by edoc »

wjaguar wrote:
edoc wrote:any other ideas as to how I might restore mtpaint, please?
Extract the original binary from the distro, and copy it to /usr/bin
That is, mount the ISO, unpack with unsquashfs the SFS contained within, and there under squashfs-root/usr/bin you'll find the original mtpaint binary.

BTW, the cause of problem is a version conflict with libtiff: Fatdog 630 provides libtiff.so.5, and mtPaint compiled in there gets to require it - while Lighthouse is still stuck with libtiff.so.3
(Which you could have found out for yourself, if you ran "ldd mtpaint")
Thanks!

"ldd mpaint" ... hmmm ... I am unfamiliar with "ldd" will have to explore that some.
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

User avatar
don570
Posts: 5528
Joined: Wed 10 Mar 2010, 19:58
Location: Ontario

#440 Post by don570 »

You should learn to make a link.

First you change directories

Code: Select all

cd  /usr/lib

Then you make the link

Code: Select all

ln -s libtiff.so.3 libtiff.so.5
Note that the old library comes first and the new link that is created comes last.

______________________________________________________

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#441 Post by edoc »

Something else must have been broken by the PET ...
<root> /usr/lib
bash-4.1# ln -s libtiff.so.3 libtiff.so.5
ln: failed to create symbolic link 'libtiff.so.5': File exists
<root> /usr/lib
bash-4.1#
OR ... should I just find and delete libtiff.so.5 then copy libtiff.so.3 from wherever it is into that location?

I can post a list of what pfind locates for "libtiff.so"
Last edited by edoc on Sun 26 Jan 2014, 03:52, edited 2 times in total.
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#442 Post by edoc »

wjaguar wrote:
edoc wrote:any other ideas as to how I might restore mtpaint, please?
Extract the original binary from the distro, and copy it to /usr/bin
That is, mount the ISO, unpack with unsquashfs the SFS contained within, and there under squashfs-root/usr/bin you'll find the original mtpaint binary.
bash-4.1# unsquashfs L64-602.sfs
Parallel unsquashfs: Using 4 processors
28347 inodes (28536 blocks) to write


dir_scan: failed to make directory squashfs-root, because Read-only file system
[| ] 0/28536 0%
created 0 files
created 0 directories
created 0 symlinks
created 0 devices
created 0 fifos
<root> /mnt/+mnt+home+savestuff+downloads+lh64files+Lighthouse64-6.02-B2.iso
bash-4.1#
What step did I miss, please?
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

gcmartin

#443 Post by gcmartin »

Update for @Don570. No problems here on Mariner booted to RAM from DVD with save-session to DVD. There was no reboot, required. Although it was NOT necessary, after downloading the 64bit FATDOG version, I exited to prompt and logged out. Upon desktop restart, I moved the PET from the /root/spot/Download folder to my personal /Download folder and installed by double clicking the PET once moved.

So far, I have not had problems and have verified that version is ...55. Thanks

On another note

Assuming 01Micko does NOT report problems with its use, you may want to update the download thread's info to reference the mtPaint PET works with LH64 and Slacko64, as well as FATDOG.

Here to help

wjaguar
Posts: 359
Joined: Wed 21 Jun 2006, 14:16

#444 Post by wjaguar »

edoc wrote:bash-4.1# unsquashfs L64-602.sfs
...
dir_scan: failed to make directory squashfs-root, because Read-only file system
...
What step did I miss, please?
chdir to a writable directory :)
Looks like you tried to unpack the SFS right where it was - which is inside an ISO, and thus readonly. unsquashfs extracts files to the current dir.
edoc wrote:OR ... should I just find and delete libtiff.so.5 then copy libtiff.so.3 from wherever it is into that location?
Better to get a real libtiff.so.5 (from Fatdog64, if that build does work on Lighthouse, or compiled for this distro if not). Sonames get changed for a reason, and some programs may crash when actual library doesn't match its soname.
And given that something is present on your system under the name of "libtiff.so.5" - it could be precisely what happened to the new mtPaint.
I can post a list of what pfind locates for "libtiff.so"
The result of "ls -l /usr/lib/libtiff*" would be more useful.

gcmartin

latest mtPaint from @Don570 seems to be working

#445 Post by gcmartin »

As reported by some of us, we are NOT having obvious problems in either install and use of mtPaint from @Don570. I have always run LH64 Mariner from DVD with Save-sessions to DVD. The following shows my system lib:

Code: Select all

bash-4.1# updatedb
bash-4.1# locate libtiff.so.5
locate: `/var/lib/slocate/slocate.db' is an slocate database.  Support for these is new, expect problems for now.
locate: `/var/lib/slocate/slocate.db' is an slocate database.  Turning on the '-e' option.
/usr/lib64/libtiff.so.5
/usr/lib64/libtiff.so.5.2.0
/initrd/pup_ro2/usr/lib64/libtiff.so.5
/initrd/pup_ro2/usr/lib64/libtiff.so.5.2.0
Seems that proper lib is already present without any need to make any system adjustments for mtPaint.

Hope this helps
Edited: Added the preceding updatedb command to the code window
Last edited by gcmartin on Fri 31 Jan 2014, 03:55, edited 1 time in total.

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#446 Post by edoc »

Why would my result be different than yours, please?

<root> ~
bash-4.1# locate libtiff.so.5
locate: warning: database `/var/lib/slocate/slocate.db' is more than 8 days old (actual age is 1897.9 days)
locate: Old-format locate database `/var/lib/slocate/slocate.db' is too short to be valid
<root> ~
bash-4.1#
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

LibreOffice 4.2 for LH64?

#447 Post by edoc »

[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

gcmartin

#448 Post by gcmartin »

Hi @Edoc

I run LH64 Mariner from DVD. There may be a difference between the base system and what I gain in Mariner which provides the lib. So, I cannot say which Mariner addition make it present.

I did update the code window in the prior post by me. Try running it to see if your system finds the lib reference.

Hope this helps

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

#449 Post by edoc »

Mine is missing the last two lines:

/initrd/pup_ro2/usr/lib64/libtiff.so.5
/initrd/pup_ro2/usr/lib64/libtiff.so.5.2.0
bash-4.1# updatedb
<root> ~
bash-4.1# locate libtiff.so.5
locate: `/var/lib/slocate/slocate.db' is an slocate database. Support for these is new, expect problems for now.
locate: `/var/lib/slocate/slocate.db' is an slocate database. Turning on the '-e' option.
/usr/lib64/libtiff.so.5
/usr/lib64/libtiff.so.5.2.0
<root> ~
bash-4.1#
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

gcmartin

Problems using MTP in LH64

#450 Post by gcmartin »

This post is a comprehensive view of a problem to get an MTP device to connect using MTP protocol so that Lighthouse64 can allow users to see all data contained on their smartPhones/smartTablets/smartDevices. This post outlines a problem specific to LH64 and ask/requests for your assistance in resolving.

Following was done to add MTP subsystem to LH64:
  • Installed Tempestuous' 64 bit go-mtpfs package
  • MTPconnect package
This is all that is required to add MTP support to a Puppy.

To see files contained on the smartDevice: Plugged Nexus 7 charging-data cable into LH64’s USB port. As is the case with 32bit PUPs tested, one expects a ROX window to open showing the Nexus 7’s filesystem and files. But, on LH64, nothing happened. I tried unplugging and plugging it in again, still nothing. Next;
  1. killed the MTPconnect process
  2. opened the console,
  3. started the MTPconnect process from the command line looking for messages or errors
No errors were generated. It simply wasn't detecting anything.

@Can8V ran his debug version, which is essentially the same script except that it has echo statements in every control point of the script, so that he can watch exactly what is going on while the script is running and see the value of variables at any given point. Running this script discovered that the script was monitoring fine, it just simply wasn't finding any product names or product IDs in the dmesg kernel ring buffer. To verify that it would in fact find a product id or product name in the dmesg kernel ring buffer should one actually exist he wrote a test message directly to the buffer with the following command:

Code: Select all

echo "product: Nexus_7 Product id: 4ee1" > /dev/kmsg
The monitor picked up the message and mounted the Nexus 7 in a fraction of a second, as can be seen in attached screenshot.
Image
Next step took a look at the dmesg kernel ring buffer: Discovered two major problems:
  • NONE of the entries have a timestamp
  • There are simply no Product IDs or product names in the buffer, it is only recording "new device" and "device disconnected" with the associated USB port.
That information is far less than helpful.

Ideas ANYONE!
Does anyone know if there is any steps to get the kernel to report the necessary information to the dmesg kernel ring buffer

More Information
Since MTPconnect relies on the Kernel Ring Buffer and the dmesg command to be able to inspect the contents of said buffer, it is crucial that the kernel be appropriately configured to produce the necessary output to the buffer. If it does not do it then MTPconnect will not be able to find information in the buffer that does not exist, because the kernel failed to create it. Poking around was able to change the kernel parameters, so that it now outputs the timestamps to the kernel buffer ring. I accomplished that by setting the parameter at boot time by adding it as a kernel option in my Grub menu entry. See the following code:

Code: Select all

kernel /LHP64/vmlinuz psubdir=LHP64-515 pmedia=ataflash pfix=fsck pupmode=13 printk.time=1
There may be other kernel options I can set at boot time to get the kernel to print the Product name and Product ID instead of just reporting a "high speed device" has been connected or disconnected and the associated USB port. The screen shot below shows the kernel ring buffer displayed in the console using the dmesg command after rebooting the the printk.time=1 option added to the kernel option list in my grub menu entry. Notice that the timestamps are displayed and they are correctly showing seconds since boot. When this kernel was built, it appears to have NOT had this set, so, this option is turned off (set to 0 instead of 1).
Image
There is a lot of information missing from the kernel ring buffer. At a minimum the timestamps need to be added to all entries in the buffer and somehow the entries that include each devices Product ID and name of the product need to be printed to the buffer. The timestamp option can be turned on at boot time as I described before. I don't know about the missing entries for the product ID and name. The product manufacturer ID is also missing from the buffer. While the Manufacturer ID entry was useful during development of MTPconnect, the application doesn't use the Manufacturer ID entry at all. Still this is another entry that should be in the buffer, but isn't.

This will need someone’s help to resolve the kernel settings so that LightHouse64 can identify the MTP devices attached where MTPconnect can properly post the devices use to the desktop. I personally am far from the most knowledgeable person when it comes to kernel options and compiling kernels, so for me to come up with a fix for this would require significant research, luck and time. Maybe somebody else already knows what to do.

Can anyone knowledgeable on kernel elements assist?

I did understand, back in the fall, that TaZoC was to undergo additional treatments, but, we have not heard from him in many months. Hope all is well with him.

Important NOTE! I am posting this to assist @Can8V because he is in school prepping for an exam ATM. This is an important item that could use some developer direction.

Here to help

Fabio T
Posts: 90
Joined: Fri 31 Aug 2007, 20:33
Location: Italy

#451 Post by Fabio T »

I Report that Google Chrome breaks CUPS v 1.5.4 of Lighthouse 6.02 (Interna Server Error).

Same problem occurs in FatDog64, but the difference is that in FatDog, when I unistall Chrome, CUPS turns back at work, not in LightHouse.

On puppies 32bit with CUPS 1.6 this not happens.

Any idea?

gcmartin

#452 Post by gcmartin »

Fabio T wrote:I Report that Google Chrome breaks CUPS v 1.5.4 of Lighthouse 6.02 (Interna Server Error). ... Any idea?
@Fabio T
  • Question
  • Are you running Mariner or are you using Base LH64-602?
Mariner has Chrome built-in when booting and Base, which doesn't have it, requires that you install if from somewhere.

This "may" make a difference and yield differing behaviors.

Fabio T
Posts: 90
Joined: Fri 31 Aug 2007, 20:33
Location: Italy

#453 Post by Fabio T »

I've run LightHouse Mariner.
But I tried to install Google Chrome 29, 64 but Chrome works fine, same Seamonkey, but I can't use CUPS for error.

Empasse was solved with this script:

8<---------------------------------------------------

#!/bin/bash

## Locks in printer permissions: root:nobody
## To reverse, change to "chattr -i"


[ -f /tmp/list ] && rm /tmp/list
cd /etc/cups
ls -l | grep "nobody" | cut -d " " -f8 >>/tmp/list

cd /initrd/pup_rw/etc/cups

while read line; do
chattr +i "$line"
done < /tmp/list

chattr -R +i /initrd/pup_rw/var/cache/cups
chattr -R +i /initrd/pup_rw/var/log/cups

# rm /tmp/list

### Note: leave /var/spool alone

#chattr -R -i /initrd/pup_rw/var/spool/cups

------------------------------------------------------>8

I've tried to use also with FatDog 64 but won't work because of differenf filesystem and directories

Another question (please). If I want to install Frisbee, what Can I do? Frisbee beta available on forum don't works.

Thanx for answers.

Fabio

User avatar
edoc
Posts: 4729
Joined: Sun 07 Aug 2005, 20:16
Location: Southeast Georgia, USA
Contact:

Midori Browser for LH64-602b2

#454 Post by edoc »

Any chance of a Midori PET or SFS for LH64-602b2?

http://www.puppylinuxfaq.org/add-on-sof ... r-pet.html

Firefox is making too many bad moves.

Midori appears to be WebKit-fast, is cross-platform, open-source, & defaults to the privacy-respecting DuckDuckGo.com Search engine.
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603

Fabio T
Posts: 90
Joined: Fri 31 Aug 2007, 20:33
Location: Italy

Solved issue with Google-Crome, what can I do with sleep?

#455 Post by Fabio T »

(After a few workarount I've solved issue with Google Chrome that breaks CUPS - I've prepaed a new updated .SFS with correct attributes of directories.

But remains a problem:

When I close the lid of my laptop, after I reopen it, to wake up my laptot I must touch on-off button; system wakes up but after a few seconds it goes again on sleep, even I click mouse or open some windows - This is very annoying when I am at work and in a hurry (it repeat this process more and more to wake up system definitely).

My laptop is a Fujitsu T902, works correctly with Upup Raring and FatDog 64.

What can I do to get sleep worked correctly?

Thanx

Post Reply