Maintenance

CyanogenMod has been replaced by LineageOS, and there is an unofficial Nougat ROM available.
To install it, hold the power, volume up AND volume down buttons simultaneously until you see the Google boot logo, then release the buttons.
Once you see the little droid dude lying down with his guts open, use the power button to select Recovery Mode and boot the tablet in to TWRP.

Once in TWRP, plug it in to your computer. It should find the tablet and mount it. Copy the zip file containing the ROM to the root of the drive (labelled 'Internal Storage'). Also copy in any other stuff that you can/must flash (like GApps).

In TWRP, select 'Install' and choose the ROM zip file and use the slider to indicate that you're serious.
Once flashed, run the 'Clear Dalvik cache' and go 'up' and run the install again, this time on the GApps image.
You should be able to boot in to the new OS now.

After some experimentation and some help from DW on the eXist list, I've managed to figure out the following steps for making your single app (MoEML or whatever) available as the root thing on th Jetty server (i.e. localhost:8080 if you're running it locally), while maintaining access to the other bits and pieces if necessary (the Dashboard, eXide, Monex or whatever else you need. These are the steps:

• In tools/jetty/webapps/exist-webapp-context.xml, find the element <set name="contextPath"> and make sure it looks like this:

  <Set name="contextPath">/</Set>

  i.e. not /exist. It may be that way already, or it may be /exist.
• In tools/jetty/standalone-webapps/exist-webapp-context.xml (same filename, different place), make the same change if required.
• In tools/jetty/webapps/portal/WEB-INF/jetty-web.xml, find the same element and set it to the same thing (again, it may already be correct).
• In webapp/WEB-INF/controller-config.xml, find this:

  <root pattern=".*" path="/"/>

  Comment it out and replace it with two lines like this:

    <!--<root pattern=".*" path="/"/>-->
    <root pattern="/apps/moeml/apps" path="xmldb:exist:///db/apps/"/>
    <root pattern="/" path="xmldb:exist:///db/apps/moeml/"/>
  

  Where "moeml" is the name of your app. The second line makes the other apps (dashboard etc.) available using the "apps" subfolder of the root (which means you can't have anything in your app's controller that handles an "apps" subfolder).

Note that this was done with a fresh build of eXist 3.0 from the develop branch yesterday, with no use of the installer. We've learned to steer clear of the installer.

I've now built all this into a set of files, configure_exist.sh/xml/xsl. The first is a bash script which expects the path to the eXist instance, and (optionally) the name of the app to make the root. The second is an ant script which is run by bash using the ant which is inside the tools folder of the eXist instance; this parses out what it needs to know, and runs XSLT transforms using the Saxon version which is in the lib/endorsed folder. This means that you can run this deployment script even where neither ant nor Saxon are installed (such as Peach). It has a fragile dependency on the version numbers in filenames of ant and Saxon, but those are easy to update.

I've worked the CodeSharing feature into the MoEML XAR today, deciding on having the build process for the XAR just check it out from GitHub and put the bits in the right place, with the controller.xql handling the rest. So far so good; then I set up controller-config.xml so that the root path goes to the MoEML webapp, and the other apps we want are available from there. However, the "root" right now is /exist, not /, and I can't find a way to change that. After trying everything I could think of, I've written to the eXist list.

Created a script in svn/hcmc/exist which cleans the git tree completely, builds exist, signs the jars, creates a fairly minimal dist, and builds a test instance with one of our own xars, then starts it for testing. All that remains to be done is figure out how to change the jetty.xml file and any oother conf files to add the required placeholders.

If you want to change the icon of a specific folder/file for some reason, you need to edit the gvfs metadata that is stored in a binary file.
This can be done using built-in gvfs methods like the following:

To get the current, custom icon value
# gvfs-info -a metadata::custom-icon ~/Desktop/foo (file:///home/yournamehere/Desktop/foo also works)

To set a custom icon
# gvfs-set-attribute ~/Desktop/foo metadata::custom-icon file:///usr/share/icons/Humanity/places/48/folder-music.svg

To reset icon to stock
# gvfs-set-attribute ~/Desktop/foo -t unset metadata::custom-icon

Unlike .desktop files, you cannot refer to a canonical FreeDesktop-type icon. You must use an explicit path to the icon you want to use.
NOTE: in a .desktop file you can ref the icon like ICON=folder-open and you'll get the icon theme's icon for folder-open. This icon will change with the theme.

Show other editable attributes for a file
gvfs-info -w ~/Desktop/foo

Which will return something like this
Settable attributes:
standard::symlink-target (bytestring)
time::access (uint64, Keep with file when moved)
time::access-usec (uint32, Keep with file when moved)
time::modified (uint64, Copy with file, Keep with file when moved)
time::modified-usec (uint32, Copy with file, Keep with file when moved)
unix::gid (uint32, Keep with file when moved)
unix::mode (uint32, Copy with file, Keep with file when moved)
unix::uid (uint32, Keep with file when moved)
Writable attribute namespaces:
metadata (string, Copy with file, Keep with file when moved)
xattr (string, Copy with file, Keep with file when moved)
xattr-sys (string, Keep with file when moved)

Still on the quest of the best way to build a working eXist and update it cleanly, we've been testing the dist-zip build target. First, though, I determined how to build with DS's patch for the bug I reported the other day, which is still only a pull request (#1256); CLI for future reference:

git pull
git checkout 1256
git fetch origin pull/1256/head:1256
git checkout 1256

Then we do:

./build.sh clean
./build.sh 
./build.sh jnlp-all

the last of which signs the jars, enabling the Java client to work. This gives us a working build in the repo context, but of course it's cluttered up with lots of unwanted stuff, including source. That's why we wanted to use the dist-zip target, but the result is currently broken due to an obscure timestamping issue which I reported today on the gmane list. We could manually create a clean tree, of course, but it would be easier to have a script do it.

JA called to report that the config on the CCAP db had been hosed by the visit of a robot to a specific URL, which triggered something completely unexpected and unwanted. He was able to recover it, and add protection against a similar event both on CCAP and on LOI. The AtoM documentation is apparently not working properly so we can't find anything on their site about this particular "feature".

The lab is now running Ubuntu 16.04.

One new thing is that I had expected PXE booting to 'just work', but it's been a bit hit-and-miss. I have no clear understanding why, but I might be able to find out by comparing UEFI/BIOS settings on the machines to find out what the differences are between machines that CAN PXE boot and those that CAN'T.

The machines have two distinct motherboards (ASUS H81I-plus and ASUS H97I-plus), and there are slight differences between the models' UEFI/BIOS.

Machines that can PXE boot:
Saga (H81I+)
Salander (H97I+)
Smilla (H81I+)
Sherlock (H81I+)
Cadfael (H97I+)
Rumpole (H81I+)
Poirot (H81I+)
Morse (H97I+)
Marple (H97I+)

NOTE: F8 should boot the machines to a boot menu that contains UEFI network booting.

GL's desktop was rebuilt, and the huge TCCD git repo was copied over. However, it had been checked out using git://, and somehow it knew that the old desktop had SSH keys configured on GitHub, so we had to generate new keys (GL couldn't remember the pw for the old keys), add them to ssh-agent, and add the public key to GitHub (the key must be for the email address by which GitHub knows you). Then pulls and pushes would work. All this is quicker than checking out that repo again, of course.

In xpath/xquery builder in oxygen:
set xquery 3.0

declare default element namespace "http://www.tei-c.org/ns/1.0";
let $names := for $n in //persName/string-join(descendant::*/text()," ") return $n
return string-join($names," ")

returns just the texts.

The equivalent in the xpath box above the editor
//persName/string-join(descendant::*/text()," ")

returns the strings, but also the system id etc for each that you then have to manually delete