29 February 2020

Productivity software I like to install after upgrading to Lubuntu 19.10

I installed Lubuntu 19.10 and copied over my old /home/user from my 19.04 system.

Now I need to reinstall some software, so it's good to revisit and update my old migration notes.


In Summary...

I like to:

add-apt-repository ppa:libreoffice/ppa

apt-get install restic chrony file-roller gedit xournal evince nomacs graphicsmagick ghostwriter emacs gimp gimp-plugin-registry gimp-gmic default-jdk gcc make ttf-mscorefonts-installer ruby libsecret-1-0 libsecret-1-dev

sudo make --directory=/usr/share/doc/git/contrib/credential/libsecret
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret


snap install code --classic
snap install aws-cli --classic

Note: ttf-mscorefonts-installer requires user interaction to install, so don't walk away from it overnight thinking everything will be done by morning.

Then install by hand Chrome, Netbeans, and LibreOffice dictionaries etc.

Oh, for chrony, I like to also have added to /etc/chrony/chrony.conf : server time.apple.com iburst because where I am it's hard to get to a time server except Apple's.

See more info about each below.

22 February 2020

LibreOffice's multiFormatSave extension is broken

multiFormatSave broken as GlobalScope.DialogLibraries.isLibraryLoaded(EXTENSION_NAME) not working

Not sure when this became an issue as it used to work. At some point LibreOffice must've updated to version 6.3.4.2 on Lubuntu 19.04 while I had MultiFormatSave 1.5.6 installed. Then it stopped working:

The error occurs on line 78 (or 76 if viewed in LO macro editor) in multiFormatSave.xba. Specifically GlobalScope.DialogLibraries.isLibraryLoaded(EXTENSION_NAME) throws a NoSuchElementException.

This problem occurs despite removing and re-adding the extension, with re-opening LO between each step.

I did figure out a work-around: open ~/.config/libreoffice/4/user/basic/dialog.xlc and ensure it's contents is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE library:libraries PUBLIC "-//OpenOffice.org//DTD OfficeDocument 1.0//EN" "libraries.dtd">
<library:libraries xmlns:library="http://openoffice.org/2000/library" xmlns:xlink="http://www.w3.org/1999/xlink">
 <library:library library:name="multiFormatSave" xlink:href="$(USER)/uno_packages/cache/uno_packages/lu23853otd9xi.tmp_/multiFormatSave_v1-5-6.oxt/multiFormatSave/dialog.xlb/" xlink:type="simple" library:link="false"/>
</library:libraries>

The lu23853otd9xi.tmp_ must match where LO installed the multiFormatSave extension, of course.

Unfortunately, I'm not sure if that file existed before my bug hunting, or whether my debugging created that file since I created a Dialog in the LO macro editor as part of the bug hunt.

In any case, the key line xlink:href="$(USER)/uno_packages/cache/uno_packages/lu23853otd9xi.tmp_/multiFormatSave_v1-5-6.oxt/multiFormatSave/dialog.xlb/" seems to be the "active ingredient", letting LO know where to find the proper dialog.xlb file as it could've find it before.