Install Veusz on Debian 11: no qt5-default

I could not get the Veusz plotting package to install on Debian 10 because D10’s Qt libraries, which cannot be backported, are too old. Having recently had my computer killed by a series of random power surges that also revealed that my UPS with alleged surge protection was dodgy, I have now got Debian 11 up and running (it seems very nice, but default desktop background is uuugglleee). So … I thought I would install a development environment for Veusz, so I can keep up with the latest a greatest developments.

https://github.com/veusz/veusz/wiki/DevStart

In short, there is only 1 thing that did not work out of the box — Debian 11 does not include a ‘qt5-default’ package.

Now, I did not have any conflicting versions of Qt or Python or anything, because this is a spanky brand new install of Debian, so I could replace this package with:

qtbase5-dev qtchooser qtbase5-dev-tools

and this was the only variation away from the instructions. Other than that, it all worked flawlessly.

 

Veusz

HTML tables; align text on the decimal point: a crude manual kludge

You want your numbers in your table to align on the decimal point. HTML + CSS does not seem to do this simple thing very well. If you don’t mind a crude manual kludge, what you can do is right-align the numbers, pad them with zeroes on the right, and then turn the spurious zeroes transparent. Now, I note that I cannot get a working example within freaking WordPress, but I can show the code, and a screenshot of how it looks in the preview.

Code:


<table align="left">
<tbody>
<tr>
<td align="right">0.23<span style="color: rgba(0,0,0,0.0);">0</span></td>
</tr>
<tr>
<td align="right">2.3<span style="color: rgba(0,0,0,0.0);">00</span></td>
</tr>
<tr>
<td align="right">23<span style="color: rgba(0,0,0,0.0);">.000</span></td>
</tr><tr>
<td align="right">23&ensp;&ensp;&ensp;&ensp;</td>
</tr><tr>
<td align="right">23&puncsp;&ensp;&ensp;&ensp;</span></td>
</tr>

<tr>
<td align="right">0.023</td>
</tr>
<tr>
<td align="right">230<span style="color: rgba(0,0,0,0.0);">.000</span></td>
</tr>
</tbody>
</table>

I am sure you can do this is a cleverer way; this example is only to show that it works. It’s a bit manual, though. And I’m nor sure it would work nicely with accessibility requirements, because a screen reader would probably read out the excess zeroes. What if we just put in &ensp;? Actually, the en space is not quite the right width, but it is pretty close. See the row above with the asterisk, *. I guess you need a thin space for the full stop — &puncsp; — see row **. I find one looks better in preview, another going live, it’s all a mess, so good luck.

So we can turn the text transparent or use the correct combination of spaces to get something that might not be awful.

 

Bleh.

Note to self: a dictionary for hunspell

I want Australian English for my command line spell checking, for which I usually use hunspell. I can list the dictionaries hunspell has installed:

$ hunspell -D
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/usr/share/hunspell/en_US

OK, is there a Debian package? That would be simplest:

$ apt-cache search hunspell | grep -B 1 Australia
myspell-ru - transitional dummy package
hunspell-en-au - English (Australia) dictionary for hunspell

or

$ apt search hunspell | grep -B 1 Australia
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
hunspell-en-au/stable,stable,now 1:2019.10.06-1 all

OK, install it:

$ sudo apt install hunspell-en-au

$ hunspell -D
(etc)
/usr/share/hunspell/en_AU
/usr/share/hunspell/en_US

OK.

Locale settings should look after choice of default dictionary.

$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=

local and/or general

Installing when USB boot does not work: consider SATA

Ever tried to boot install  media using a USB device (a flash drive, an external CD or HD drive?) and had it fail? Now that a lot of machines do not come with optical drives, this can be a stumbling block. Maybe the solution is to open up  the case, and plug a borrowed SATA CD/DVD drive into one of the SATA sockets on your motherboard. (Leave your hard drive plugged in!) You probably have spare power leads that can supply the DVD drive.

Of course, this won’t help with a laptop. Anyway …

I have an old computer (a Wincor Nixdorf Beetle)that is fairly low-powered and lacks a CD/DVD drive. I thought I might use it to play with Haiku OS. First, got the install media:

$ wget https://mirror.aarnet.edu.au/pub/haiku/r1beta3/haiku-r1beta3-x86_64-anyboot.iso

Inserted an empty USB stick, then unmounted it but left it in the machine:

$ umount /dev/sdj1

where sdj was determined by looking at dmesg output ($ sudo dmesg) before and after plugging in the USB stick. It would have been easier to use this:

$ lsblk

Your USB probably won’t be sdj…

Note: Sometimes ejecting the USB through a GUI file manager will not leave it as an available device.

Wrote the image to the USB:

$ sudo dd if=haiku-r1beta3-x86_64-anyboot.iso of=/dev/sdj bs=1M

But the computer would not boot off USB, even after messing with BIOS settings. In fact, putting the USB stick into the computer prevented it from booting at all. Tried writing to other USB sticks, and writing in other ways; for example:

$ sudo cp haiku-r1beta3-x86_64-anyboot.iso /dev/sde

where sde was a USB; note, not to sde1 but to sde itself.

also dd’d to a CF card and plugged a USB card reader into the beetle.

Neither booted. Both locked it up. But … I have booted the Beetle off a USB CD drive, so burned the ISO to a DVD. That was slightly better — gave me a reboot loop.

Opening up the computer case, I saw there was a spare SATA plug. So I pulled a SATA DVD drive out of another computer and plugged it into the Beetle. Had to leave the case off, but it booted no worries off the SATA DVD and the install went flawlessly. So did the ensuing update, although my little old monitor was too small for the installer  — the Haiku dialogs were not readable and I could not figure out how to shrink them, so I also had to find another screen. Once the install was complete, there were enough video drivers available I could swap back to the original screen and choose a higher pixel density.

Haiku is very responsive on this limited hardware, which I keep out in the shed and mostly use for problem solving (eg looking for manuals and how-tos), and does the job admirably.

the job

Free guides to data literacy and visualisation

The place where I work has recently published some guides to aspects of writing and communication. You can find them here: https://www.themandarin.com.au/partners/biotext/

Documents include

They’re all free to download or read online or whatever. See what you think!

 

guides

Note to self: good old Office 2010 on wine

It’s still pretty hand and I already have the installer. Just do this:

https://askubuntu.com/questions/674692/installing-office-2010-on-ubuntu-15-04-using-wine

But for the record:

$ sudo apt-get install mesa-utils mesa-utils-extra libgl1-mesa-glx:i386 libgl1-mesa-dev
$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so /usr/lib/i386-linux-gnu/libGL.so

(Second command failed, but on we go.)

$ sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/mesa/libGL.so

(Failed, but went on.)

Create a clean shiny new wine prefix for it:

$ export WINEPREFIX="/home/username/.wineprefixes/office2010/"
$ mkdir -p /home/username/.wineprefixes/office2010/
$ export WINEARCH="win32"
$ sudo apt-get install winbind
$ winetricks dotnet20 msxml6 corefonts
$ wine ~/Desktop/office\ 2010\ pro\ 32bit.exe &

$ winecfg

You should see msxml6 (native, built-in) in the Existing overrides section. Highlight it and click Edit and select Native (Windows) and click OK. Now, it should show up as *msxml6 (native).
Then add the riched20 and gdiplus libraries from the New override for library section and make sure these are also set as “Native”

I found native then built-in worked better, rather than native exclusively. That’s my only variation away from the instructions as given.

Applying any updates to Office 2010 is a whole ‘nother story.

 

Nother

User read and write ext4 fixed disk

Slotted a spare disk into my machine and want it to be read/write for all users as a scratch space.

First, created the mount point & gave it broad permissions

$ sudo mkdir /media/second-disk
$ sudo chmod 777 /media/second-disk

Added it to /etc/fstab

UUID=1fffff44-61f4-f5fe-af21-fe7caffffffc /media/second-disk ext4 rw,user,exec 0 2

But regular users could not write to it. Turned out the reason was the drive belongs to the root group.

$ sudo caja

Open drive, right click on the file space, Properties, Permissions and made drive in group plugdev (as if an external thing, which uses get access to) and selected Folder access as ‘Create and delete files’ and then it worked.

In a terminal, made sure I was in the plugdev group:

$ groups
username lp dialout cdrom floppy sudo audio dip video plugdev netdev lpadmin scanner

The usermod command can add someone to a group:

$ sudo usermod -a -G plugdev username

OK, that works nicely. Now nonroot users can use the disk as a scratch space. I am the only user most of the time.

Just don’t put private data there!

plugdev

Notes for me: ZMC in 2021

The established problem is the hashtable.f90 module; it throws errors I have tried to fix and cannot. At this time, my only answer is to use older binaries, statically linked. The 2016 versions at https://rsc.anu.edu.au/~username/ZMC.html seem to work on 64-bit, the older 2014 ones are 32-bit. This is my log of getting a working system.

First, this is a i386 install of Debian, so I downloaded the 2014 binaries from the RSC website:

https://rsc.anu.edu.au/~username/ZMC.html

ZMC and DZMC ran (created output file named 2021), but bin2gray did not, so I need to recompile, at least bin2gray. Bugger.

First, try naive approach — download and unpack the 2016 source files from the same website.

$ wget https://rsc.anu.edu.au/~username/ZMC_files/ZMC_toolbox_source_April_2016.tar.gz

Unpack it somewhere and …

$ sudo apt install gfortran
$ gfortran --version
GNU Fortran (Debian 8.3.0-6) 8.3.0

OK.

$ chmod +x compile_all_Linux_gfortran.sh
$ ./compile_all_Linux_gfortran.sh

OK, some of it compiled. Not bin2gray … but first let’s test the ZMC and DZMC binaries…

Nope, ZMC aborts. I bet it is the same hashtable.f90 issue I’ve had for years now.

OK. DZMC?

DZMC seems to work, although it puts some junk out to the command line when asking for the name of the diffuse.hkl file.

I don’t know if it is any faster than the precompiled binary, either. I guess we could test, but it feels slower.

OK, so now let’s look at bin2gray. Problem with reuse of variable names; change version to nversion:

$ diff bin2gray.f90 bin2gray-Linux-orig.f90
15c15
< character(len=*), parameter :: nversion = "$Id: bin2gray.f90,v 1.6 2007/06/04 05:23:11 aidan Exp $"
---
> character(len=*), parameter :: version = "$Id: bin2gray.f90,v 1.6 2007/06/04 05:23:11 aidan Exp $"
505c505
< write(myunit,*) nversion(6:index(version,":",back=.true.)-1)
---
> write(myunit,*) version(6:index(version,":",back=.true.)-1)

And now it compiles.

What about ZMC? It compiles but does not run properly; I cannot be bothered with that. Runtime errors, especially mysterious seg faults that move around when you add diagnostic output, are beyond my ken. As I recall a workaround is to avoid the use of keyword-based input file. I think I have a version somewhere that does this …

Install soft links to the binaries into ~/bin/ZMC and add that to my path.

$ ln -s /home/username/ZMC/source-2016/ZMC_toolbox_source_April_2016/bin2gray_static /home/username/bin/ZMC/bin2gray

and the rest from the 2014 source collection; for example:

$ cd ~/ZMC/RSC-2014/ZMCLinux/
$ for f in * ; do ln -s /home/username/ZMC/RSC-2014/ZMCLinux/$f /home/username/bin/ZMC/$f ; done

OK, that seems to be done.

-l ~/bin/ZMC/
total 4
lrwxrwxrwx 1 username username 76 Aug 17 19:28 bin2gray -> /home/username/ZMC/source-2016/ZMC_toolbox_source_April_2016/bin2gray_static
lrwxrwxrwx 1 username username 44 Aug 17 19:31 catmol2 -> /home/username/ZMC/RSC-2014/ZMCLinux/catmol2
lrwxrwxrwx 1 username username 44 Aug 17 19:31 chkmol2 -> /home/username/ZMC/RSC-2014/ZMCLinux/chkmol2
lrwxrwxrwx 1 username username 41 Aug 17 19:31 DZMC -> /home/username/ZMC/RSC-2014/ZMCLinux/DZMC
lrwxrwxrwx 1 username username 52 Aug 17 19:31 make_random_occ -> /home/username/ZMC/RSC-2014/ZMCLinux/make_random_occ
lrwxrwxrwx 1 username username 44 Aug 17 19:31 mol2xyz -> /home/username/ZMC/RSC-2014/ZMCLinux/mol2xyz
lrwxrwxrwx 1 username username 43 Aug 17 19:31 ni2pgm -> /home/username/ZMC/RSC-2014/ZMCLinux/ni2pgm
lrwxrwxrwx 1 username username 45 Aug 17 19:31 pgm2mask -> /home/username/ZMC/RSC-2014/ZMCLinux/pgm2mask
lrwxrwxrwx 1 username username 43 Aug 17 19:31 pgm2ni -> /home/username/ZMC/RSC-2014/ZMCLinux/pgm2ni
lrwxrwxrwx 1 username username 43 Aug 17 19:31 pgmave -> /home/username/ZMC/RSC-2014/ZMCLinux/pgmave
lrwxrwxrwx 1 username username 47 Aug 17 19:31 pgmcombine -> /home/username/ZMC/RSC-2014/ZMCLinux/pgmcombine
lrwxrwxrwx 1 username username 44 Aug 17 19:31 raw2pgm -> /home/username/ZMC/RSC-2014/ZMCLinux/raw2pgm
lrwxrwxrwx 1 username username 46 Aug 17 19:31 zmat2mol2 -> /home/username/ZMC/RSC-2014/ZMCLinux/zmat2mol2
lrwxrwxrwx 1 username username 45 Aug 17 19:31 zmat2xyz -> /home/username/ZMC/RSC-2014/ZMCLinux/zmat2xyz
lrwxrwxrwx 1 username username 46 Aug 17 19:31 zmat_anim -> /home/username/ZMC/RSC-2014/ZMCLinux/zmat_anim
lrwxrwxrwx 1 username username 44 Aug 17 19:31 zmatchk -> /home/username/ZMC/RSC-2014/ZMCLinux/zmatchk
lrwxrwxrwx 1 username username 47 Aug 17 19:31 zmat_maker -> /home/username/ZMC/RSC-2014/ZMCLinux/zmat_maker
lrwxrwxrwx 1 username username 40 Aug 17 19:31 ZMC -> /home/username/ZMC/RSC-2014/ZMCLinux/ZMC

So now let’s try bin2gray.

$ cd ~/ZMC/RSC-2014/ZMCLinux/Simple_Simn/
$ bin2gray --8bit 2021

File 2021 opened and irlen = 1600

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

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

The computation volume is defined by:
( -4.00, -4.50, 0.00) => ( 4.43, -4.50, 0.00)
( -4.00, -4.50, 0.00) => ( -4.43, 4.50, 0.00)
( -4.00, -4.50, 0.00) => ( -4.00, -4.50, 0.00)
Image size is 400 X 400 X 1
sin(theta)/lambda maximum = 0.686999977
Crystal size is: 32 32 32
Lot Size is: 9 9 6
Number of Lots Computed: 3
Subtract Average Lattice? e

Working on plane # 1/1 ...
Range = 4.84273769E-03 => 786.550415
Mean , STD = 15.257284623366822 38.963948929865644
Normalizing to 171.113083
Writing pgm 2021.pgm

$ sudo apt install imagej
$ imagej 2021.pgm

Needs JVM.

$ sudo apt install graphicsmagick netpbm
$ gm display 2021.pgm

OK, the image looks right. Maybe we’ll install ImageJ later or use it locally, because the JDK is so big.

In fact, just had to set JAVA_HOME:

$ which java
/usr/bin/java

For the session:

$ export JAVA_HOME=/usr

and then for future sessions:

$ echo "export JAVA_HOME=/usr" >> ~/.bashrc

OK, so we seem to have everything we might need to do some science.

We have:
* gfortran working
* ZMC and DZMC working (or at least the basic capabilities)
* bin2gray working
* the toolbox programs working (not all completely tested yet)
* imagej, netpbm and graphicsmagick all working.

 

OK for now.