(old)Puppy Linux Discussion Forum

Hi 01micko,
Here's what happened with

get_libreoffice-0.19.pet install to a new frugal of precise puppy 5.4.1
The testing version of Libre office was selected.
My test PC is a AMD 4 core with 4gig of ram and a 2gig save file


best regards

DC

get_libreoffice-0.18-3 creates a script,pinstall.sh, that changes the run action associated with the write, calc, paint and draw desktop icons to use LiobreOffice instead of the deafult values. The script works with slacko5337, but not with 5.4

This occurs with a USB installed Slacko 5.4

The following menu options do not work with either 5.4 or 5.337 installed as a bootable USB

document > compose > new document
business > sheets > new database
business > sheets > new spread sheet

tlchost,

Try the 0.19 version in the main post, the forks haven't caught up yet. Works fine for me in a fairly pristine 5.4 (tested on a USB install, 1GB RAM, 1 GB swap).

-

DC

Trying testing right now. It's grabbing 4.0.0.0-beta1 [ ]. Should have a result shortly.

LATER: DC, it mostly works as long as I add missing deps, gnomevfs [ ], ORBit [ ] and libbonobo [ ]. i don't care about menu icons in the beta versions or the %U bug. If it works in the stable version then I'm happy. Beta is for testing, do we need the frills? Stable is of course recommended in the GUI. Beta works good enough.

Hi 01micko et al,

If you load LO using load-on-the-fly (or say, seaside's SFS-Exec) and
then unload - do you still have a 20 MBish LO folder in /root/.config?

My regards

01micko wrote:tlchost,

Try the 0.19 version in the main post, the forks haven't caught up yet. Works fine for me in a fairly pristine 5.4 (tested on a USB install, 1GB RAM, 1 GB swap).

Thanks.....all the menu items now work correctly.
I got this error:
cp: cannot stat ‘/usr/local/bin/defaultpresentation’: No such file or directory

Also, the script did not ask what drive(device) I wanted to use....I run bootable USB. It wrote the sfs file to /tmp ... took me while to find it. Perhaps add back in the ability to specify where you want the sfs file created?

Thom

tlchost

The "defaultpresentation" error is meaningless. Really I should suppress it, but it does no harm. Noted for next version.

If shinobar or L18L want to fork version 0,19 I'm sure they can add a choice where to save. Since this is designed to load the sfs with sfs_load (shino) you are given the choice to copy to /mnt/home anyway. Also, if you notice the splash messages they tell you where the sfs is being built so you can easily find it that way. The idea is that you can build the sfs even if you don't have a hard drive as long as you have the RAM.

-

Jasper,

The size of the hidden libreoffice directory will vary with how much you use it and what you do. Mine is only 2 M. Feel free to delete it or link it, whatever you choose.

Hi 01micko,

Thank you for your helpful response.

Whilst I could test to see what happens if I link/save my
LO config folder, I ask (for the benefit of all) might I
expect my LO sfs to load faster than usual when I reboot?

My regards

PS I use a multisession CD with sfs files on a USB stick,
which is where I save new sfs files and data as I work - so
I very rarely add anything or make any changes to the CD.

ADDENDUM:

Hi - I tried it - there is a huge impovement in load speed.

01micko wrote:tlchost

The idea is that you can build the sfs even if you don't have a hard drive as long as you have the RAM.

Good idea...and I overlooked the splash messages.

Thanks

Versions 0.19 of get-libreoffice fails to obtain a working sfs for wary 5.3. In precise 5.4.3 it works. The sfs obtained with version 0.19 in wary 5.3 can't be mounted. With version 0.13 of get-libreoffice previously used by mine to obtain a earlier sfs of Libreoffice3.5.0 I was instead able to obtain a sfs of libreoffice3.6.4 working in wary and precise.

watchdog wrote:Versions 0.19 of get-libreoffice fails to obtain a working sfs for wary 5.3. In precise 5.4.3 it works. The sfs obtained with version 0.19 in wary 5.3 can't be mounted. With version 0.13 of get-libreoffice previously used by mine to obtain a earlier sfs of Libreoffice3.5.0 I was instead able to obtain a sfs of libreoffice3.6.4 working in wary and precise.

Did you build in Precise then try to mount in Wary? If the kernel supports xz compression then that will be used. Wary's kernel does not support xz compression. I tested in an old version of Slacko that does not support xz compression and it worked fine.

01micko wrote:

watchdog wrote:Versions 0.19 of get-libreoffice fails to obtain a working sfs for wary 5.3. In precise 5.4.3 it works. The sfs obtained with version 0.19 in wary 5.3 can't be mounted. With version 0.13 of get-libreoffice previously used by mine to obtain a earlier sfs of Libreoffice3.5.0 I was instead able to obtain a sfs of libreoffice3.6.4 working in wary and precise.

Did you build in Precise then try to mount in Wary?.

Confirm what I previously said. I have builded in wary 5.3 Libreoffice 3.6.4 with version 0.19 of get-libreoffice: it cannot be mounted and it doesn't work. Sometime ago I builded Libreoffice 3.6.3 in precise 5.4.1 with get-libreoffice version .19: it works in precise but not in wary. Problems with scripts I suppose. Libreoffice3.6.4 obtained with version 0.13 of get-libreoffice in wary works in wary and precise but in wary the first mounting and/or start is difficult. Then it finally works. No problem instead with Libreoffice3.5.0.

Thanks watchdog.

there are 2 bugs actually, one is my fault the other is a wary "bug" (or maybe a feature).

First, when I added support for the RAM mode installation I didn't take into account that bootmanager can't shift the file like sfs_load can. If you have less than 2 GB usable memory (eg 1 GB RAM, 1 GB swap) you wouldn't notice that bug.

Second, wary semi-supports xz compression. That is, it can compress and decompress with xz but it can't mount it. I don't know if it's a bug or by design but anyway I am now testing if the kernel is greater or equal to a 3x kernel then we default to xz, else gz for 2 series is used, and this is also now reflected in the filename (xz or gz is appended). I think that is the bug you and other wary users may have been getting.

Version 0.20 should fix your issue. posting it now.

01micko wrote:
Version 0.20 should fix your issue. posting it now.

Running Slacko 5,4 as bootable USB. Version 2 reports that it will not work with low memory/usb drive.

I have 16 gigs memory...so it must not like the USB drive. Reverting to 1.9 which works for me.

Thom

01micko wrote: Second, wary semi-supports xz compression. That is, it can compress and decompress with xz but it can't mount it. I don't know if it's a bug or by design but anyway I am now testing if the kernel is greater or equal to a 3x kernel then we default to xz, else gz for 2 series is used, and this is also now reflected in the filename (xz or gz is appended). I think that is the bug you and other wary users may have been getting.

Version 0.20 should fix your issue. posting it now.

Testing successfull. Builded working Libreoffice-3.6.4_xx_gz.sfs in wary 5.3. It works in precise, too.

tlchost, thanks for testing, probably something silly I did fixing the calculations for lupu's busybox. I'll fix it shortly.

watchdog, thanks for the report, glad your issue is fixed.

Cheers

I have been using LibreOffice 3.50 in Exprimo 5x15 Frugal on a Netbook.

Is this PET the best way to update it to 3.64, please?

I use it daily so don't want guess wrong, use the wrong process, and break things!

Thanks!

Edoc

Just unload the 3.5 version before starting a build, should work ok. If it happens to fail you can reload the 3.5 version.

Hth

0.21 is out.

See main post

0.20 failed here, three tries.

I will try 0.21 a little later ...

Thanks!

EDIT:

BTW: Isn't GET supposed to restart when interrupted?

The GET from the PET was interrupted and just stalled.

I started a new GET and rather than picking up where it stalled it started new

No apparent joy with 0.21 in Exprimo 5x15 either.

I will try a reboot and see if it just isn't showing up.

EDIT: On reboot there was no evidence in Exprimo 5x15 of the 0.21 GET other than a couple of desktop icons out of place.