Xenialpup64 CE 7.5 / 25 Nov 2017

[Ledster]

Tried this in xenialpup64 and bionicpup64_7.9.6 with same problem in both.

Brief computer spec:
Mesh - about 6 years old
i5 quad core 2.166GHz
ASUS P7P55 LX mobo
4 Gb DDR3 memory
ATI Radeon HD5750 graphics with 1 Gb memory
1 Tb SATA hard drive

Both running frugal with save file.

Downloaded googleearth from quickpet, installed and it runs ok.
However I'd prefer to run it as an sfs (keep the pupsave file small and tidy) So;
right click and choose 'extract pet' or pet2tgz and tar xvzf in xenialpup64
right click and choose 'dir2sfs'
go to SFS-load-on-the-fly and select to load it and get the following:

error - fatal: failed to mount......
google-earth-pro-stable_7.1.8.3036-r0_amd64_7.9.6.sfs file has wrong permissions
'drwx------'

First it's a file, not a directory (as the 'd' in 'drwx------' indicates)
Second if I run 'ls -l google-earth-pro-stable_7.1.8.3036-r0_amd64_7.9.6.sfs'
I get '-rw-r--r--'
which is the same as other sfs's that load and run with no problems.

Any idea what's going on?. I have no idea - my brain cell can't cope!

[mikeslr]

No idea why you've gotten a permission error. Rather than going nuts:

Unload you're google-earth. Try this one: http://murga-linux.com/puppy/viewtopic. ... 878#962878

File/Folder > same difference. In Linux a folder is just a specialized file. So the notice was correct, just missing a word or two for the 'sake of brevity' and 'easy reading'.

[Ledster]

Thanks for the suggestion mikeslr - no joy.

loaded Google_Earth_Pro-7.3.0.3830-tahr-amd64.sfs - menu entry does nothing.

Open a terminal and:-

root# /usr/bin/google-earth-pro
/usr/bin/google-earth-pro: line 43: ./googleearth-bin: No such file or directory
root#

go to /opt/google/earth/pro/
right click on googleearth-bin and choose 'run in terminal' :-

/tmp/runinterminal-20732: line 3: /opt/google/earth/pro/googleearth-bin: No such file or directory
Script completed hit RETURN to close window.

I can SEE it! but it also appears not to exist.

Now I'm really confused!

[Mike Walsh]

Hallo, Ledster.

Well, Mike is of course right; everything in Linux is a 'file'......even directories! (Yah, I know it can overload your brain cell, but bear with us....)

Put me right on this one, will ya? Your screenshot shows you've been running the Bionicpup version; do I take it you downloaded this for Bionicpup, then decided to try it in Xenialpup, too?

I generally find that anything made for Tahr (like the SFS Mike's linked you to) will usually run OK in Xenial. Not so for Bionicpup (well, not to the same extent, anyway). Canonical decided to make some pretty major changes in the way Ubuntu handles stuff; personally, I haven't been able to make Google Earth run in Bionicpup at all, regardless of the version I try.

Every time I try to start it from the terminal, it'll invariably display a message something along the lines of

"Google Earth has caught Signal 11.

We apologize for the inconvenience, but Google Earth has crashed.
This is a bug in the program, and should never happen under normal
circumstances. A bug report and debugging data have been written
to this text file:

/root/.googleearth/crashlogs/crashlog-xxxxxxxxx.txt

Please include this file if you submit a bug report to Google."

------------------------------------------------------------

I've just done some more digging on the subject, and this Google Product Groups forum thread seems to be the most promising lead so far; it hinges around permissions - apparently Google Earth attempts to own the whole of /usr/bin.....?!!?

https://productforums.google.com/forum/ ... 5uH01RFGP0

(You'll have to copy/paste that; the forum won't parse it, for some reason. I suspect the '!#' in the middle is chucking a spanner in the works...)

Sounds to be related to the old saga of how CUPS always used to go tits-up after installing Chrome from a .deb file. Which is to do with the .deb being built for Debian/Ubuntu, which are true multi-user systems......which Pup is not!

It looks like the solution hinges around running

Code: Select all

chmod 777

on the G.Earth .bin file (although the way the packages work in Puppy, the G.Earth entry in /usr/bin is merely a sym-link to /opt/google/earth/pro/googleearth-pro. This then starts the 'googleearth-bin' file proper in the G.Earth directory...)

(Although having said that, it doesn't make sense. I'm in Xenialpup64 ATM, and the 'googleearth-bin' executable is in fact running with '755' permissions Hmm; interesting.... This bears closer examination, I think.)


Mike.

[Ledster]

FYI
I downloaded the pet from xenialpup64's quickpet and as I said the pet loads ok and works.

Change the pet to sfs and run it in a fresh xenialpup save file and all the above happens.

Looks like I'll just have to use the pet.

@Mike
Got some other things to do right now - will follow up your links for interest later.

Cheers

[Billtoo]

I wanted a pup that runs well with xfce4 as the WM so I installed xenialpup64
7.5 to the 2nd hard drive of my HP desktop:

System: Host: puppypc11516 Kernel: 4.9.141 x86_64 (64 bit) Desktop: Xfce 4.12.3 Distro: xenialpup64 7.5
Machine: Device: desktop System: Hewlett-Packard product: p7-1246s serial: MXX232077R
Mobo: Foxconn model: 2ADA v: 1.00 BIOS: AMI v: 7.12 date: 06/07/2012
CPU: Quad core Intel Core i5-3550 (-MCP-) speed/max: 1600/3301 MHz
Graphics: Card: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
Display Server: X.org 1.18.4 drivers: intel (unloaded: modesetting,fbdev,vesa)
tty size: 162x27 Advanced Data: N/A for root
Network: Card-1: Ralink RT5390 Wireless 802.11n 1T/1R PCIe driver: rt2800pci
Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Drives: HDD Total Size: 3000.6GB (0.6% used)
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 204 Uptime: 18 min Memory: 286.3/11969.2MB Client: Shell (bash) inxi: 2.3.8

Updated PPM and installed favorite applications.
Changed the kernel.

It's working well,
Thanks.

[mikeslr]

FYI
I downloaded the pet from xenialpup64's quickpet and as I said the pet loads ok and works.

Change the pet to sfs and run it in a fresh xenialpup save file and all the above

Wonder if google-earth employs python? That's a problem which always shows up when python is involved: python in puppy_xxx.sfs and puppysave_xxx.sfs having higher priority than 'addon' sfses, addon sfses default to using the wrong one. Probably could be solved by specifically defining the library path in the SFS or ala fredx181's firefox quantum creating a portable rather than an SFS using a wrapper script which defines the library path.

If not python -- what else screws up SFSes?

[Ledster]

I have looked in the GE sfs and and the extracted pet and there is no python stuff at all.
Had a good look at the GE forum link given by Mike Walsh - GE seems to have many problems!
Looks like I should think myself lucky that I have a version (the .pet) that works. I'll stick with that.

Cheers

[666philb]

mikeslr, Ledster & Mike Walsh,

concerning googleearth.

Code: Select all

googleearth-bin: No such file or directory 

this happens because googleearth needs a symlink /lib/ld-lsb-x86-64.so.3 > /lib/ld-linux-x86-64.so.2
in 32bit the link is /lib/ld-lsb.so.3 > /lib/ld-linux.so.2

googleearth firing up and crashing is usually because a previous version of googleearth has been used, and deleting /root/.googleearth can fix it.

also the latest versions of googleearth pro don't support the nouveau driver, and doesn't render properly, so you either need to use an older version (the one in xenials repo is the latest that works) or install the nvidia driver. (note this may have changed, not tested recently)

[Ledster]

Thanks 666philb for the info. Tried the link and GE now fires up but the graphics are c**p. A small black square in the top left corner of the GE window and extreme tearing if I move anything.
PupSysInfo lists my graphics card correctly as ATI Radeon HD 5750, using the radeon kernel driver. So not an Nvidia card, but definitely a graphics problem.
As a side note nothing else gives any problems.

[Lassar]

I believe pale moon has been updated so the Pale moon updater does
not work anymore.

And now Pale Moon program uses a different folder.

So has pale moon on xenialpup been updated?

[666philb]

hi Lassar,

open quickpet and click on update
then run the palemoon installer again to update palemoon

[bigpup]

When you get Pale Moon v28.0.0 or above installed.
Updates are built into Pale Moon.
Help>About Pale Moon>Check for Updates
There are now options, in Pale Moon>preferences, for how updates are done.

[linuxcbon]

Xenialpup64 CE 7.5
- I installed skypeforlinux-64.deb from the official site but it crashes, seems like it doesn't like libdbus.

Code: Select all

skypeforlinux[22317]: segfault at 8 ip 00007fc0894d2600 sp 00007ffe67185638 error 4 in libdbus-1.so.3.14.6[7fc0894bc000+4a000]

[Mike Walsh]

@ linuxcbon:-

Hm. Perhaps it might be worth trying the libdbus from Bionicpup64? It's a newer version, so it may do something that Xenial's won't.

I've attached the lib (with sym-link) below. It wants to go in /lib (not /usr/lib). If that's where Xenial's libdbus is, move it somewhere for safe-keeping, in case you need to replace it again.

Worth a try, I guess. Personally, I gave up on Skype a while back; too much hassle, and there's plenty of alternatives out there.....though I appreciate the need for keeping it around for communicating with Windoze-centric family & friends who won't try owt else.


Mike.

[linuxcbon]

Thanks Mike, I just found out why the latest skype doesnt work in xenialpup.
It's because it needs LOGIND from SYSTEMD !


I will try if your libdbus works anyway.

[666philb]

Thanks Mike, I just found out why the latest skype doesnt work in xenialpup.
It's because it needs LOGIND from SYSTEMD !


I will try if your libdbus works anyway.

hi linuxcbon,

i've added a fix that's in bionicpup for skypeforlinux. it uses elogind but only starts it for skype, then turns it off again when skype closes.

quickpet >>> xenialpup updates then uninstalling and reinstalling skype will activate the fix.

however running skypeforlinux without elogind results in no errors, .. it just doesn't start, which may suggest that the dbus issue is something else... possibly an old pet or sfs that has overwritten xenials dbus.

anyway give the fix a go and see if it works

[linuxcbon]

anyway give the fix a go and see if it works

Yes it works.

19/12/2018 skypeforlinux needs elogind to run

[mostly_lurking]

Is this a bug? Xenialpup 7.5 can't mount xfs filesystems - both 32bit and 64bit versions seem to be affected:
Error when trying to mount an xfs partition
(I have also just tried a 32bit Xenialpup 7.0.6 that I still had lying around somewhere, and got the same error, so it's not just the 7.5 version.)

[666philb]

Is this a bug? Xenialpup 7.5 can't mount xfs filesystems - both 32bit and 64bit versions seem to be affected:
Error when trying to mount an xfs partition
(I have also just tried a 32bit Xenialpup 7.0.6 that I still had lying around somewhere, and got the same error, so it's not just the 7.5 version.)

scroll down to mavrothals post here http://murga-linux.com/puppy/viewtopic. ... de8347e9bd

note that the pet he made is 32bit only so you'll have to build your own module