What is Spotify Connect?

Spotify Connect is a protocol and means by which one device can remotely control playback on another device over your home network or wifi.

If you have a device that supports Spotify Connect then no longer are you limited to listening to Spotify on your phone or computer – you can instead use your phone or computer to control music playback on your Spotify Connect compatible smart speaker, TV sound bar, car stereo, etc.

You can see what Spotify Connect devices are available on your network by hitting the button in an official Spotify client. It will show a list of devices on which you can play music remotely:

My problem is that I don’t have a smart speaker or other Spotify Connect compatible device here in my office capable of driving my big floor standing speakers. What I do have however, is an old stereo amplifier with spare inputs in the same rack as my server equipment:

The server machine in the bottom of that rack happens to have an integrated USB audio adapter so why not connect that to the AUX-in on the amplifier and teach the server how to stream music from Spotify?

Installing Spotifyd

Spotifyd is an open source Spotify client that you can run as a daemon and also supports the Spotify Connect protocol, which makes it show up as a device that can be controlled from the official Spotify client.

An RPM packaged version of Spotifyd can be found in my COPR repo at mbooth/spotifyd. It’s straightforward to enable the COPR repo and install it:

# dnf copr enable mbooth/spotifyd
# dnf install spotifyd

Spotifyd uses the Avahi mDNS for service discovery, which allows the official Spotify clients to find it on your network. So we need to make sure the mDNS port is open, as well as the port used by the Spotify Connect protocol. On a default installation of Fedora Server, it may be necessary to open both ports using the firewall-cmd command like this:

# firewall-cmd --permanent --add-service=mdns
# firewall-cmd --permanent --add-service=spotify-connect
# systemctl reload firewalld

Finally, enable and start the Spotifyd service in the normal systemd way:

# systemctl enable spotifyd.service
# systemctl start spotifyd.service

The server will now show up in official Spotify clients as a device named “spotifyd.” Choosing it from the list will begin playback on that device:

If you want to run Spotifyd on a Fedora Workstation install, or any setup where you have user sessions with the audio being managed by Wireplumber/Pipewire, then you will need to start it as a user service instead:

$ systemctl --user enable spotifyd.service
$ systemctl --user start spotifyd.service

Configuration

The configuration file for Spotifyd can be found at /etc/spotifyd.conf where the first thing you probably want to do is customise the name that shows in the device list:

device_name = "Mat's Office"

All the configuration options are explained further in the upstream documentation.

Reporting Issues

For issues directly relating to the RPM packaging of Spotifyd or installation from my COPR repo, please file bugs at github.com/mbooth101/spotifyd-rpm/issues.

I usually go years and years between OS re-installs, so I’ve forgotten how to do this. Hopefully this article will be useful for future me. The first thing to do after installing Fedora on a new machine however, is to switch the default editor back to vim, because I have no muscle memory for nano and I refuse to change. 😅

$ sudo dnf swap nano-default-editor vim-default-editor

Now onto the main business of configuring the terminal and vim to use my favourite colour palette, Solarized by Ethan Schoonover.

Solarize The Terminal

Ptyxis, the new default terminal in Fedora Workstation Edition, has an excellent set of colour palette options. From the hamburger menu drop-down, select the Follow System Style button from the three options at the top. This causes Ptyxis to switch between light and dark modes when you change the system dark mode preference instead of being in dark mode all the time. Then open the Preferences dialog to select the Solarized colour palette from the options listed there:

Solarize Vim

This works well for normal terminal operation, but vim’s own default colours can clash terribly with the terminal colour scheme. Sometimes the foreground and background colours are either the same or extremely low contrast, which results in impossible to read text, as shown here after performing a search for the string “init”:

Fortunately Ethan provides a vim-specific implementation of the Solarized colour palette in his vim-colors-solarized repository. This can be installed by downloading the provided vim script into your .vim/colors directory:

$ mkdir -p ~/.vim/colors
$ wget https://raw.githubusercontent.com/altercation/vim-colors-solarized/refs/heads/master/colors/solarized.vim \
    -o ~/.vim/colors/solarized.vim

And then configuring the colour scheme in your .vimrc file by adding the following lines:

" Enable Solarized Theme
syntax enable
colorscheme solarized

New vim sessions will now use the correct colours, and are even able to detect whether to use the light or dark variant of Solarized.

Dark Mode Detection

However, vim is only able to detect whether to use the light or dark variant at start up. This means if I switch the system dark mode preference while vim is open, then I have to close and reopen all my open vim sessions before they will use the correct Solarized variant:

Not even re-sourcing the .vimrc using the :so command corrects the colours. We can however edit it such that re-sourcing does fix the colour scheme variant in use without needing to exit and reload vim.

" Enable Solarized Theme
syntax enable
let sys_colors=system('gsettings get org.gnome.desktop.interface color-scheme')
if sys_colors =~ 'dark'
    set background=dark
else
    set background=light
endif
colorscheme solarized

Expanding upon the previous .vimrc snippet, this explicitly sets vim’s background setting depending on the output of a gsettings query for the current system dark mode preference. Now the :so ~/.vimrc command can be used to fix the colours without having to close and reopen vim.

Vimterprocess Communication

It would be even better of course, to have vim automatically re-source the .vimrc automatically when the system dark mode preference changes.

Vim has a kind of interprocess communication mechanism built in. If it’s started with the --servername {NAME} option then vim can accept commands from another vim processes running on your machine. To ensure vim is always started with this option, just add this line to your .bashrc file to create a command alias:

# Always start vim as a server
# with a unique name
alias vi='vi --servername VIM-$(date +%s)'

Now when you run vim (or vi) the session will be named with VIM-<SOME_NUMBER>. Commands can be sent to such named sessions using a specially crafted invocation of vim:

$ vim --servername VIM-<SOME_NUMBER> --remote-send ":so ~/.vimrc<CR>"

So all we need to do is write a small shell script to find all running vim processes, determine their session names, and execute the above command for each one. Create the script in your user’s local bin directory, e.g. ~/.local/bin/vsignal.sh and make it executable with chmod +x ~/.local/bin/vsignal.sh:

#!/bin/bash

function signal_vim() {
	# Signal all running instances of vim
	PIDS=$(pgrep -u $USER vim)
	for PID in $PIDS ; do
		VIM_ID=$(ps --no-headers -p $PID -o args | cut -d' ' -f3)
		vim --servername $VIM_ID --remote-send ":so ~/.vimrc<CR>"
	done
}

# Wait for color-scheme change
gsettings monitor org.gnome.desktop.interface color-scheme | \
while read -r COLOR_SCHEME ; do
	signal_vim
done

Piping the gsettings monitor command into read will cause the script to block until the system dark mode preference is changed. When it does, it will issue a call to the signal_vim function, perform the magic, and then go back to blocking. Now while ever the vsignal.sh script is running, all active vim sessions will immediately switch to the appropriate Solarized colour scheme variant when the system dark mode preference is changed.

A Systemd Theme Sync Service

It’s a bit incovenient to have to start a script whenever you open a terminal though. The best way to have this script always running is by letting systemd handle it. A new, user-specific service can be created with the following command:

$ systemctl edit --user --force --full theme-sync.service

The following service definition will cause systemd to start the script when you log into your Gnome session:

[Unit]
Description=Dark Mode Sync Service

[Service]
ExecStart=%h/.local/bin/vsignal.sh

[Install]
WantedBy=gnome-session.target

And finally, enable and start the service with the following commands:

$ systemctl --user enable theme-sync.service
$ systemctl --user start theme-sync.service

Now we can switch between light and dark modes to our heart’s content, safe in the knowledge that vim will follow suite. 😌

The Plan

Since we moved into this house the big birdies have been living in the back room, which has a South-facing French door that opens onto the patio. It’s lovely, but the large amount of glass and the flat roof of the extension means it gets extremely hot in this room in the summer time and we can’t open the door without locking the birds away. It means we have to choose between the birds’ freedom to roam the house and our own comfort.

So we had the idea of building an aviary over the French door so that we can open it and let some breeze into the house without worrying about the birds. Cancelled vacation plans mean I can bring this project forward from Q5 where it was previously scheduled. It is possible to buy pre-fabricated aviary panels of course, but in every case we found they suffered from one of two problems:

• Size – Most commercially available aviary panels are either 6 feet or 8 feet tall. This is problematic because the strip of wall between the top of the French door and the eaves of the roof is a height above the patio that is somewhere between those two dimensions, so the top of the aviary would either interfere with the doors opening or intersect with the eaves. It’s possible to get bespoke units made, but that increases the cost, especially when you require they be made of a specific material, which is the other problem:
• Material – The majority of aviary panels commercially available are either wood-framed or zinc-galvanised. This wouldn’t matter at all if you were keeping chickens for example, but both of these materials are a problem for keeping parrots and other hook-bills. Parrots are prodigious chewers, which is vital for the maintenance of their beaks but anything made from wood has a short life-span in our house. Galvanised metals are a problem because parrots are also prodigious climbers and they use their beaks as a third hand. Just from climbing about in galvanised cages parrots can ingest a lot of zinc, which is quite toxic. It’s why you should never make a BBQ out of metal fencing mesh – it’s almost always zinc-galvanised and you will get heavy metal poisoning.

Instead of paying for bespoke panels, obviously it would be way more fun to learn how to weld and fabricate my own. 😀

The two most ideal choices for material are aluminium or stainless steel. Either of these should survive outside corrosion-free, maintenance-free and be both safe and secure for the birdies. Reading online I learned that for various reasons, welding aluminium is a much more dificult process than welding steel. The thermal and electrical properties of steel make it a surprisingly forgiving material to work with, which is why most novice welders begin there.

So even though the raw material is roughly twice as expensive as aluminium I decided that I stood a much better chance of success by constructing the aviary from stainless steel. I ordered some sheets of 8 feet by 4 feet sheets of stainless weld-mesh, with wire spacing close to that of our existing bird cages, from a supplier in Ilkeston and found a great deal on some 3 metre lengths of stainless box section from a local supplier here in Sheffield. I had great experiences with both these suppliers and would definitely use them again in the future.

I also ordered a cheap welding machine from Amazon, some PPE and a stack of consumable electrodes. I was now committed.

The welding machine I ordered has the capability to do both TIG welding and manual arc welding but since TIG has a much higher initial cost of entry due to the requirement for argon shielding gas, I decided to stick to basic manual arc welding for this project. The consumable electrodes I bought are designated ER308L and are suitable for welding the type 304 stainless steel I had ordered.

Phase 1 - First Arcs

Time to start welding!

I sensibly ordered enough box section such that I could first get plenty of practice before attempting any part of the real project. Here are photographs of my very first eight arc strikes, as seen after a quick hit with a wire brush (click to view a high-res version):

It’s quite obvious that I neither knew what I was doing nor knew what to expect, despite having watched several Youtube videos on the subject… 😲 I’m a big fan of my apparent complete inability to move my hands in a straight line and also the apprentice marks that can be seen in sample one where I had welded the electrode to the base metal and then dragged the arc across the surface of the piece after struggling to break it off.

Phase 2 - Butt Joint Practice

After a full day of just striking arcs and forming puddles, I wanted to try welding some pieces together by butting some box section together to form a tee. This is the kind of joint I want to use on the aviary panel frames. Here are the front and back sides of my first ever box section butt joints (click to view a high-res version):

You can see from sample one here that I had great difficulty in managing the heat that I’m putting into the metal – on the left I did not manage to form a puddle that joined both sides of the joint (not enough heat/moving the electrode too quickly) and on the right I ended up just blowing a hole clean through the box (too much heat/moving the electrode too slowly.) Sample two is a little better, but there is still a hole on the left that is filled with slag instead of metal.

I ended up spending a lot of time discovering through trial and error the right way to move and feed the electrode for this kind of joint of this kind material and by the end of day three I actually started to produce some welds that came out looking sort of not bad (click to view a high-res version):

The key thing I found to get these welds was that as you zig-zag across the seam to be welded, it is important for the electrode to spend much less time over the bottom end piece than the cross piece because the end piece has no support from underneath. The bottom edge of the cross piece of the tee is supported by a whole side of the box section and can therefore sink away much more heat, which means less chance of melting a hole right through the material.

Pretty welds they are not, but I tested the strength by welding only one side and then trying to persuade the pieces apart with a hammer; I succeeded in bending it apart at the seam only a little. The welds can easy support my body weight and it’s not for anything structural; it should be more than stong enough for what I have in mind.

Through experimentation I have found the beginnings of a technique and independently discovered the rule of thumb that states the machine should be set to the same number of amperes as the thickness of the electrode in thousandths of an inch. My electodes are 1.5mm, which translates to about 60 amps. I also discovered it helps a great deal if you can actually cut the metal squarely. I don’t have a metal-cutting chop-saw or band-saw so I’m just cutting the box section using an angle grinder with an abrasive cut-off disc and then squaring up the pieces on the bench grinder (or hand file where the bench grinder is impractical). Perhaps it’s obvious, but the closer the fit, the smaller the gap you have to fill.

Later, I started to attempt fillet welds in the inside corners of the tee, but that… Didn’t go nearly as well (click to view a high-res version):

I clearly need way more practice at this; I’m not anywhere near confident enough to do fillet welds on the real panels, so for now I’ll probably do the flat welds only.

Phase 3 - Going into Production

At some point you have to just draw a line in the sand and actually build something for real, so the next day I started cutting the box section to length and figuring out the clamping setup. Here you can see I am leaving some sections a bit long to make it easier to clamp together squarely at the corners of the panels. Once welded, I could flush-trim the excess off with the angle grinder.

And once I’d welded the first frame, I could use that as a kind of template for the subsequent ones. But even with a template it was still difficult to keep things square due to the warping as each weld cooled down and the metal contracted. Even just one degree off is actually quite a long way out across nearly 2.5 metres of box section… You just can’t have too many clamps holding it place.

I knew I wanted the weld mesh to sit flat atop the frames so I needed to grind flat my ugly, lumpy welds. A flap-disc on the angle grinder makes short work of that (click to view a high-res version):

I didn’t quite grind out the deepest divets because I didn’t want to remove more material than necessary but even so, I was able to hide a lot of sins with the flap-disc. 😀

Phase 4 - Test Assembly

Once I had all the side panels and roof panels of the aviary welded up, I could start thinking about assembly. I needed to drill some holes in the box section so that it can all be bolted together. This turned out to much more of a chore than I anticipated. Stainless steel is hard as nails and the drills I had were not really up to the task. I had some titanium nitride (TiN) coated high-speed steel (HSS) drills for metal but they required re-sharpening on the bench grinder after every single hole, even though the wall of the box section is only 1.5mm thick. If I did not resharpen the drills then the friction of the dull cutting edge would work-harden the steel and they would would just bind and break. I broke three drills in this way before I caved in and ordered some cobalt HSS drills designed for stainless, which cut the metal like butter in comparison to the others. I highly recommend getting cobalt drills if you have to work with stainless steel.

I drilled 6mm holes for M6 bolts and removed the burr by creating a slight bevel with a countersink bit:

With sufficient bolt holes drilled, I could now do a dry fit of the first segment of the aviary so I could mark and drill holes in the brick-work for the mechanical fixings attaching it to the wall. The half-fabricated frame clamped to the front here is just there for spacing and to lend some rigidity for the test fit:

And it turns out I needn’t have worried too much about squareness because once I bolted the frames to the wall of the house, I discovered my patio is pretty far from level. I am as shocked as you are, but at least I know the rain water drains away from the wall. The side of the frame that is bolted against the wall is resting on the patio. The other side is flapping about in the breeze, a 25mm gap between the underside of the box section and the top of the patio (click to view a high-res version):

Luckily since the gap is approximately one box section dimension large it should not be a big deal because the next frame can be that much lower without resulting in any gap at the top.

Phase 5 - Welding the Mesh

Next thing to attempt is welding the mesh to the assembled frames. Prudence once again dictated that I practice on some off-cuts first, so here’s some practice welds (click to view a high-res version):

What I am trying to accomplish with these “tacks” is to start a puddle on the box section and then bringing the puddle over to touch the mesh wire. I must be careful to avoid putting too much heat into either the box section (and blowing a hole through it) or the mesh wire (and melting it away entirely). You can see in the above I was not quite successful in all cases, but after some practice I was able to acheive what I wanted consistently enough to start welding for real. See below for some better examples (click to view a high-res version):

Now only about a thousand of these left to do…

Phase 6 - Final Assembly and Gate

After fabricating and welding the mesh onto seven frames, the final frame I wanted to be a gate so that we can still get into and out of the aviary from the outside. This meant I needed to construct some kind of latch mechanism to keep it closed. For the hinge side, I just bought and attached some stainless rise-and-fall hinges, so the gate will naturally want to close itself. For the latch mechanism, I fabricated a small enclosure out of some box section and cut out the mesh where it would be placed in the gate (click to view a high-res version):

This enclosure will house the latch tongue, handle and return spring. I had to buy the spring, but the latch tongue and handle I made from some stainless steel round stock:

The holes you see drilled in the enclosure above holds the latch tongue captive. The spring surrounds the latch tongue and acts on the latch handle to force the tongue into a corresponding hole in the gate frame, as demonstrated below:

Demo of the gate latch mechanism.

I tried to fix the handle to the latch tongue with a set screw, but of course this stainless steel was too much for my cheap taps and I inevitably snapped the tap mid way cutting the threads:

I don’t know what I expected, I almost certainly should have just used a roll pin. Never mind, I just trimmed off the pointy excess and now the tap is the set screw. 😀

I also needed a “door stop” to prevent the gate from being opened backwards and straining the hinges. This was easily made with a piece of stainless sheet metal salvaged from an old cooker extraction hood pop-riveted onto the frame:

Epilogue

I was right, learning to weld was a great deal more fun than just buying some custom made aviary panels. The whole project took my two full weeks of PTO working every day, plus something like the next six following weekends, so it was expensive and laborious but a great learning experience.

Due to assembling the aviary with the mesh welds on the outside, the only welds you see from the inside are ones that are ground flat which I think looks great. And the birds seem to enjoy having the extra space too:

This guy especially loves taking showers out there when it rains:

In this time of crisis, I leave you with this appropriately heartwarming message that came with my welding gloves:

“The last but most important, please don’t forget to take a good rest and spend time staying with family in busy work.”

To recap, the minimal bundle set needed to start Equinox with the console is as follows:

org.apache.felix.gogo.command_1.0.2.v20170914-1324.jar
org.apache.felix.gogo.runtime_1.1.0.v20180713-1646.jar
org.apache.felix.gogo.shell_1.1.0.v20180713-1646.jar
org.eclipse.equinox.console_1.4.0.v20190819-1430.jar
org.eclipse.osgi_3.15.200.v20200214-1600.jar

All of these bundles are available in the Equinox SDK zip file available from the Equinox Downloads site. As of writing the latest release is Equinox SDK 4.15.

Extract these bundles into a directory, then inside that directory create a configuration/config.ini file with the following content:

osgi.bundles=\
    org.apache.felix.gogo.runtime,\
    org.apache.felix.gogo.command,\
    org.apache.felix.gogo.shell,\
    org.eclipse.equinox.console

Now you can start this minimal Equinox, with console, by passing the -console option, for example:

$ java -jar org.eclipse.osgi_*.jar -console
osgi> ss
"Framework is launched."


id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.15.200.v20200214-1600
1       ACTIVE      org.apache.felix.gogo.runtime_1.1.0.v20180713-1646
2       ACTIVE      org.apache.felix.gogo.command_1.0.2.v20170914-1324
3       ACTIVE      org.apache.felix.gogo.shell_1.1.0.v20180713-1646
4       ACTIVE      org.eclipse.equinox.console_1.4.0.v20190819-1430
osgi> exit
Really want to stop Equinox? (y/n; default=y)  

Over Telnet

Starting the console in a Telnet session instead is very easy, you just need to pass a port number with the -console option, for example:

$ java -jar org.eclipse.osgi_*.jar -console 1234

From another terminal, you can then connect to the Telnet session like this, using the port you specified above:

$ telnet localhost 1234
Trying ::1...
Connected to localhost.
Escape character is '^]'.
osgi> ss
"Framework is launched."


id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.15.200.v20200214-1600
1       ACTIVE      org.apache.felix.gogo.runtime_1.1.0.v20180713-1646
2       ACTIVE      org.apache.felix.gogo.command_1.0.2.v20170914-1324
3       ACTIVE      org.apache.felix.gogo.shell_1.1.0.v20180713-1646
4       ACTIVE      org.eclipse.equinox.console_1.4.0.v20190819-1430
osgi> disconnect
Disconnect from console? (y/n; default=y) 
Connection closed by foreign host.

Notice the use of the disconnect command this time, which allows you to end the console session without causing Equinox to exit. You can of course still use exit if you wish to terminate Equinox remotely.

You may also set the port in the configuration/config.ini file with the addition of this line:

osgi.console=1234

And that will start the console as a Telnet session automatically on port 1234 without needing to pass -console at all, but if you do pass -console it will override any setting you have in the configuration/config.ini file.

Over SSH

To start a console session in an SSH session, a few more bundles are needed:

org.apache.felix.gogo.command_1.0.2.v20170914-1324.jar
org.apache.felix.gogo.runtime_1.1.0.v20180713-1646.jar
org.apache.felix.gogo.shell_1.1.0.v20180713-1646.jar
org.apache.sshd.osgi_2.4.0.v20200318-1614.jar
org.eclipse.equinox.console_1.4.0.v20190819-1430.jar
org.eclipse.equinox.console.jaas.fragment_1.0.300.v20200111-0718.jar
org.eclipse.equinox.console.ssh-1.2.600-SNAPSHOT.jar
org.eclipse.osgi_3.15.200.v20200214-1600.jar
org.slf4j.api_1.7.2.v20121108-1250.jar

All of these bundles are available in the Equinox SDK zip file available from the Equinox Downloads site. As of writing the latest release is Equinox SDK 4.15.

Extract these bundles into a directory, then inside that directory create a configuration/config.ini file with the following content:

osgi.bundles=\
    org.apache.felix.gogo.runtime,\
    org.apache.felix.gogo.command,\
    org.apache.felix.gogo.shell,\
    org.apache.sshd.osgi,\
    org.eclipse.equinox.console,\
    org.eclipse.equinox.console.jaas.fragment,\
    org.eclipse.equinox.console.ssh@start,\
    org.slf4j.api
osgi.console.ssh=127.0.0.1:1234
osgi.console.ssh.useDefaultSecureStorage=true

Equinox uses JAAS to authenticate SSH sessions, the default provider of which must be configured by creating a JAAS configuration file, for example configuration/console.authentication.config with the following content:

equinox_console {
    org.eclipse.equinox.console.jaas.SecureStorageLoginModule REQUIRED;
};

Then when starting Equinox you need to tell it where the JAAS configuration is by setting the java.security.auth.login.config system property. The default JAAS implementation stores its credentials in a file you must specify with the org.eclipse.equinox.console.jaas.file system property:

$ java -Dssh.server.keystore=configuration/hostkey.ser \
       -Dorg.eclipse.equinox.console.jaas.file=configuration/store \
       -Djava.security.auth.login.config=configuration/console.authentication.config -jar org.eclipse.osgi_*.jar

The default JAAS provider creates one default user account with username/password credentials of equinox/equinox. After you log in with these credentials, you will be prompted to create a new account and the default account will be removed.

Once Equinox is started, from another terminal you can connect to the SSH session like this:

$ ssh -p 1234 equinox@127.0.0.1
The authenticity of host '[127.0.0.1]:1234 ([127.0.0.1]:1234)' can't be established.
RSA key fingerprint is SHA256:7x3eOsDRM5lyL5vRsVREy8hIawIfqRiZ7CBnk6GkfRA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:1234' (RSA) to the list of known hosts.
Password authentication
Password: 
Currently the default user is the only one; since it will be deleted after first login, create a new user:
username: mbooth
password: 
Confirm password: 
roles: admin
osgi> disconnect
Disconnect from console? (y/n; default=y) 
Connection to 127.0.0.1 closed.

On subsequent connections you will be required to supply the newly created credentials:

$ ssh -p 1234 mbooth@127.0.0.1
Password authentication
Password: 
osgi> disconnect
Disconnect from console? (y/n; default=y) 
Connection to 127.0.0.1 closed.

Once logged in there are various commands for managing user accounts, passwords and roles. Type help at the OSGi console prompt to find out about these commands. It is possible to implement custom JAAS providers that can use different credential stores, but that is out of the scope of this article.

Public Key Authentication

It’s common to want to use public key authentication with SSH and you may configure Equinox to do that instead of using JAAS authentication. First create your SSH key-pair as normal and create a file that contains the list of authorised keys that Equinox should consult when you attempt to connect:

$ ssh-keygen -f ~/.ssh/equinox
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/mbooth/.ssh/equinox
Your public key has been saved in /home/mbooth/.ssh/equinox.pub
The key fingerprint is:
SHA256:0k7MSbLLzhhzI7Gw6oSYEx8Fv5UpNHMPTdOUDj8rplQ mbooth@thinkpad-p50
The key's randomart image is:
+---[RSA 3072]----+
|  . + oooo..     |
|   + + =o.o      |
|    + = o+       |
|   . + BE.+      |
|. o o o.S  o     |
|o+ + +.=o .      |
|=.o =.=o..       |
|.o   O..         |
|o.  . o          |
+----[SHA256]-----+

$ cat ~/.ssh/equinox.pub > configuration/equinox_authorized_keys

Next you will need to remove the following line from your configuration/config.ini file:

# Remove this line
osgi.console.ssh.useDefaultSecureStorage=true

Now when you start Equinox, instead of telling it about the JAAS configuration, you must tell it about the authorised keys file:

$ java -Dssh.server.keystore=configuration/hostkey.ser \
       -Dssh.server.authorized_keys=configuration/equinox_authorized_keys -jar org.eclipse.osgi_*.jar

And that allows you to use your SSH key instead of a username/password pair when connecting to the SSH console session:

$ ssh -i ~/.ssh/equinox -p 1234 localhost
The authenticity of host '[localhost]:1234 ([127.0.0.1]:1234)' can't be established.
RSA key fingerprint is SHA256:m2JKy2fRZA1aqvxHBBe+Awsgk98ryI29fH03Rg7jeHw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:1234' (RSA) to the list of known hosts.
osgi> disconnect
Disconnect from console? (y/n; default=y) 
Connection to localhost closed.

Pretty nifty, eh?

In this file we may also declare what content types Eclipse supports so that we also get nice integration with file managers. This results in users discovering that files may be edited with Eclipse before they even start up their IDE. For example, if you install the Flatpak version of Eclipse, you may now see this nice context menu entry when you right-click on Java, Maven POM or Gradle Build files:

However there seems to be (surprisingly to me, at least) no Freedesktop standard way to do any post-installation manipulation of the information supplied by desktop entry files; an application that has the ability to install plug-ins through it’s own integral Marketplace client like Eclipse does has no ability to tell the host system about the new content type support that new plug-ins add.

Apparently this is not really a common use-case, and applications generally do one of two things:

Thing 1 (Be Greedy)

Just declare that they support all the file types, and fail gracefully if the support is missing. E.g. a video player will just declare that it supports all the different kinds of videos and if a codec is missing it just warns the user when it fails. The user can then install that codec at their leisure and try again.

In Eclipse’s case, I don’t think we can know up front all the possible content types for which people can author plug-ins, however each Marketplace entry advertises (or should advertise) what content types are supported by its plug-ins. By collecting this information for Marketplace entries that support the release of Eclipse we are building (e.g., 2019-12) we could generate a monster desktop file that contains all the types the Marketplace knows about at that time.

Pros

This allows users to discover that Eclipse can support a type even before the user has even opened Eclipse, or installed any plug-ins, simply by attempting to open a file in their file manager.

Cons

New Marketplace entries created after Eclipse is built would be omitted from this list, but that might not a be big problem in real life. A rebuild would be required to update the content type list.

We also would not be able to generate this list at build time for RPM or Flatpak type distributions of Eclipse since these build environments allow no connection to the outside world – it would require the packager to maintain/pre-build such a list.

It might be okay for e.g., VLC to do this since it only “claims” audio/video files, but there would be no limit to the kinds of files that Eclipse might “claim” and this might be too intrusive or annoying for the user.

Thing 2 (Be Honest)

When installed, extensions deliver additional desktop entry files that contain the additional content types and actions to open them, but are with a flag set to make them “hidden” to allow file managers to present it as an option when opening files but avoid duplicate entries in the desktop environment’s applications menu. This means an application will only advertise its current capabilities. For example, even though you have the libreoffice-core package installed, you might not get an “open with” option for spreadsheets until you install libreoffice-calc.

In Eclipse’s case we know what content types a plug-in supports because each one contributes to the extension registry about which file extensions it knows, so Eclipse could be taught to generate new desktop entries file after a p2 install/uninstall operation.

Pros

No need to know about all the content types up-front, so saves on packaging work and not all Marketplace entries are correctly annotated with their supported content types anyway.

Wouldn’t clutter up the user’s file manager with options they might not ever care about for files they might never edit in Eclipse and after all, Eclipse can still prompt users to install plug-ins from the Marketplace when it detects a content type for which a plug-in is available.

Plug-in installation is user-specific for read-only installations like RPM and Flatpak, so this has the nice side-effect on multi-user systems of showing the option to open a file with Eclipse only to users who have the relevant plug-ins installed.

Cons

Eclipse needs to know how to generate new desktop files when a plug-in is installed that adds support for a new content type.

Users have to actually open a file in Eclipse before discovering there is a Marketplace entry that supports that content type, instead of being prompted by their file manager before Eclipse is launched. Eclipse is still doing plug-in discovery, so this isn’t a huge concern for me.

Feedback

If you would like to see more nice desktop integrations like this, let me know on Twitter or by filing a bug against Eclipse on Flathub.

Two flavours of Eclipse IDE are now available from Flathub:

• Eclipse IDE for Java Developers – The essential tooling for any Java developer.
• Eclipse IDE for Eclipse Committers – Tooling for development of Eclipse itself at Eclipse.org.

See the TL;DR section at the bottom of this article if you want to quickly get started now!

Why Flatpak?

If you don’t already know, Flatpak is the new way to build and distribute desktop applications for Linux. You can use Flathub to gain access to a growing collection of Flatpak applications, including Eclipse IDE. You just need to follow the setup instructions for your Linux distribution.

I’ve discussed before on this blog about the benefits of packaging software for Linux distributions but from the upstream project’s point of view, there are two big problems that distro packaging does not solve:

• There are so many Linuxes!

After all the hard work of packaging your application, it is still only available for only one distro. Keeping Eclipse RPMs maintained in Fedora is almost a full time job, it would be almost impossible for me to duplicate that work for Ubuntu, for example, where a completely different packaging format is used.

• Forwards and backwards compatibility.

Different Linux distributions package different versions of your dependencies, which makes it difficult to ensure that your application works on them all. Eclipse SWT supports a large range of GTK versions for this reason and it has historically been a lot of work for the SWT contributors. It would be unfair only support the latest versions of GTK on cutting edge platforms like Fedora and Ubuntu at the expense of users on slow-moving enterprise-style distros like RHEL or SLES; or vice-versa.

Yes, but why Flatpak?

Flatpak solves both these problems whilst keeping the polished, tight integration with the host system that traditional Linux distro packaging provides. It does this by providing common runtime environments that work on every Linux distribution that supports Flatpak.

The implication this has for Eclipse is that we can make the IDE available everywhere Flatpak is supported at almost no additional cost in resources and users can even get the same shiny new version of the IDE on older versions of Linux distros where it would have been impossible to upgrade the in-distro packages. If SWT raises the draw-bridge on old versions of GTK and you can’t upgrade your Linux distro, or you want to use Eclipse on a yet-to-be-released version of your Linux distro which has a version of GTK untested by Eclipse, then it’s not longer a problem because the Flatpak runtime provides a stable and predictable runtime environment. No longer do we have to worry about API/ABI breakage caused by the distro upgrading dependencies too quickly, or not quickly enough, for Eclipse.

Having such a predictable runtime environment for Eclipse will also help a great deal in diagnosing reported problems. A consistent Flatpak runtime across Linux distributions will greatly reduce the chances that we are bitten, for example, by Ubuntu-specific bugs that cannot be reproduced on Fedora.

TL;DR - Instructions for the Impatient

Enable the Flathub repository:

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Install the IDE:

$ flatpak install flathub org.eclipse.Java

Or:

$ flatpak install flathub org.eclipse.Committers

Bugs?

If you encounter any bugs that you suspect are specific to the Flatpak version of Eclipse IDE, please consider reporting them at the Github repo where it is maintained. Thanks!

Starting from Scrap

I’ve had this piece of hardwood offcut in my scrap drawer for a while and thought it would be ideal for this project. Unfortunately I’m not a woodologist so I can’t tell you what species this is but the grain is much finer and straighter than the original handle. Let’s assume that’s a good thing for this application.

I cut out a handle blank that is a bit larger in all dimensions than the original handle using the table saw, then with a hand saw I cut a tenon in one end so that it was a snug fit into the hammer head.

Taking Shape

Sharp corners are no good for a handle, so the next job was to take a hand file and start adding some contours. I used the file to bring the shoulders of the tenon in to where the wood meets the metal.

That nice straight grain meant that as soon as I added some curves, pretty patterns immediately appeared. Below is a shot of the whole thing after sanding some ergonomics into the rest of the handle.

The two metal wedges you can see in the bottom right of the above picture are the wedges that were retaining the old handle in the head of the hammer. In the end I decided not to re-use these and instead made a wooden wedge from the same stock as the new handle.

Finishing

After giving it some sanding with slightly higher grit I gave it a couple coats of a hard-wearing poly-urethane varnish. This is a tool I expect to use often, so I want it to be able to resist some punishment.

You can see I also drilled a hole in the end of the handle and tied on a loop of scrap leather. I’ve no idea yet if I will find this feature useful. Maybe it’ll be handy to be able to hang it somewhere when I’m up a ladder. Maybe I’ll just swing it around like Thor…

The final step is to permanently affix the head onto the handle.

I made a one-saw-kerf-width slot in the tenon and fashioned a crude wedge on the belt sander from a slice of the same stock as I used for the handle. Once I was ready to commit, I applied some PVA and hammered the wedge home. After letting the glue dry I was able to trim off the excess with a hand saw and sand it flush.

Here is the finished article side-by-side with the old handle. I’m pretty happy with it. Table saw scale for, er, scale.

Bonus Nine Month Update!

Since I managed to procrastinate writing this post for more than half a year, and I’ve used this hammer most weekends since January (it is September now) for various projects, including ripping out my bathroom (I will likely talk about that in a future post) I can tell you how well my repair went!

It has put up with a fair amount of abuse and there are plenty of dings and dents in the finish to show for it, but there is no actual damage to the handle, which is good. I’m pleased with the shape and the extra length in the handle too as compared to the original; it’s quite comfortable to use.

One thing that did happen however is that after a few weeks of really beating on a cold chisel to remove some tiling and plaster work, the head was starting to work its way loose. Not because the wedge was becoming unstuck though, it seems like the wood fibres in the tenon had just compressed a bit after some amount of bedding in. I disassembled the hammer by drilling out the original wedge and reinforced it by cutting two more saw-kerfs into the tenon and making three new wooden wedges. Here it is after the glue has set and the wedges sawn flush.

It has been completely solid ever since. Sure, it’s a bit uglier now because the end of the tenon sits a little bit below the top of the hammer head preventing sanding, but who cares; it’s a tool for using not for looking at. And that loop of leather at the end of the handle? Ultimately pointless, I do just swing it about like Thor after all…

I am now maintaining two streams of OpenJDK SDK extensions in Flathub:

• org.freedesktop.Sdk.Extension.openjdk11 – this is supplying the LTS (long-term support) OpenJDK 11.
• org.freedesktop.Sdk.Extension.openjdk – this is supplying whatever the current short-lived Latest OpenJDK is; it is currently OpenJDK 12. (Note the ommission of a version number suffix in the extension ID, this is intentional.)

When OpenJDK 13 is released, OpenJDK 12 will be deprecated and the org.freedesktop.Sdk.Extension.openjdk extension will be re-based to OpenJDK 13 – this is why the version number suffix is omitted from the extension ID.

The idea of this is to satisfy two use-cases:

• Stability – if you want stability, you may continue rely on the on the LTS version supplied by the org.freedesktop.Sdk.Extension.openjdk11 extension.
• Early Adopters – if you want to take advantage of the latest and greatest features and enhancements in OpenJDK, then you can consume the Latest version supplied by the org.freedesktop.Sdk.Extension.openjdk extension, which will have periodic major updates when new major versions are released by the OpenJDK project.

For maintainers of Java-based applications in Flathub, it’s worth noting that even if you consume the Latest OpenJDK extension in your application, users will not be broken by major updates because OpenJDK is bundled into your Flatpak. The implication of this for users is that they won’t see updates to their Java version until the application maintainer rebuilds the application in Flathub.

If you maintain a Java-based Flatpak application on Flathub, you can consume the latest version of your chosen OpenJDK stream (either LTS or Latest) simply by rebuilding; the latest version of that OpenJDK steam will be pulled in automatically.

New OpenJDK Version Updates

Speaking of updates, I recently updated OpenJDK 11 to version 11.0.4 and the OpenJDK 12 to version 12.0.2; these versions are available now from Flathub.

It’s easy to check which version of Java is shipped with a Flatpak application, using BlueJ as an example:

$ flatpak run --command='java' org.bluej.BlueJ -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment (build 11.0.2+9)
OpenJDK 64-Bit Server VM (build 11.0.2+9, mixed mode)

From the above we can see that BlueJ contains 11.0.2, an old version of the LTS stream. The application needs rebuilding to take advantage of bug fixes in version 11.0.4.

I recommend that all Java-based Flatpak applications are rebuilt to take advantage of fixes in the latest builds of OpenJDK.

Using OpenJDK in a New Application

I suspect most people figure it out by looking at existing Flatpak manifests, but it’s probably worth quickly mentioning how to go about using the OpenJDK platform extensions to ship a Java application in Flathub. In the vast majority of cases, it is probably sufficient to add the SDK extension to the manifest and calling the JRE installation script. For example:

{
  "id" : "org.example.MyApp",
  "branch" : "1.0",
  "runtime" : "org.freedesktop.Platform",
  "runtime-version" : "18.08",
  "sdk" : "org.freedesktop.Sdk",
  "sdk-extensions" : [ "org.freedesktop.Sdk.Extension.openjdk11" ],
  "modules" : [ {
    "name" : "openjdk",
    "buildsystem" : "simple",
    "build-commands" : [ "/usr/lib/sdk/openjdk11/install.sh" ]
  }, {
    "name" : "myapp",
    "buildsystem" : "simple",
    ....
  } ]
  ....
  "finish-args" : [ "--env=PATH=/app/jre/bin:/usr/bin" ]
}

And the JRE will be available in the /app/jre directory. (In this example, /app/jre/bin has also been added to the PATH environment variable.)

Alternatively, if your application requires a full JDK rather than a JRE, then you can substitute installjdk.sh for install.sh and the JDK will be available in the /app/jdk directory.

Deprecated OpenJDKs

And finally…

If your Flatpak application was built against either the org.freedesktop.Sdk.Extension.openjdk9 extension or the org.freedesktop.Sdk.Extension.openjdk10 extension and therefore ships OpenJDK 9 or 10, then you should know that since the release of OpenJDK 11, these are DEPRECATED. These JDKs are no longer receiving any maintenance or security updates and are considered EOL by the upstream OpenJDK project.

Please DO NOT use these OpenJDKs for new applications being submitted to Flathub, and please migrate any existing applications to a newer, more supported OpenJDK, preferably 11 or 12 as appropriate.

At some point I will probably go through Flathub and file bugs against any applications that are still shipping deprecated OpenJDKs, but I would appreciate it if I didn’t have to file any. Thanks in advance!

With that in mind I tend to buy the cheapest thing possible for the job I need to do and use it until it breaks, wears out, or otherwise fails before replacing it with a more expensive version. The idea is that I’ll have no idea how much use I will get out of a tool so this way, if I end up using a tool just once or twice or year then I haven’t wasted any money on expensive tools that I barely use and if I’ve used a tool so much that I have broken it or worn it out, then I have a good excuse to buy a more expensive tool and will have a much better idea of what to look out for when doing so.

Here’s a compilation of some tools I’ve broken recently and my plans for their replacement.

Rolson Quality Tools Screwdriver

When they have to write “quality” on the product, you just know that’s exactly what it isn’t.

With this screwdriver I was removing some fitted cupboardry from my porch that was attached to the stone floor with, it turns out, 120mm unobtainium wood screws – I’m honestly surprised that the handle gave up before stripping the screw head. The handle appears to be made entirely of some kind of rubber polymer and just sheared off the driver shaft in my hands.

Since I have no special requirements for screwdrivers and this Rolson already lasted for years, I just replaced it with another budget brand driver from the big, orange DIY retailer. This one however appears to have a PA6 Nylon handle (with some rubber overmolding for comfort) so hopefully it holds up better.

MacAllister Clamp

Although it looks like I squeezed the handle off this clamp, I can’t take all the credit for breaking this – it was mostly a bit of plywood. I was moving a full sheet of 18mm plywood and didn’t see that this clamp was on the floor when I set it down, but I did hear the tell-tale crack of snapping plastic. MacAllister is the power tool own-brand from the big, orange DIY retailer, so I don’t expect the greatest quality, but I didn’t expect the handles to just snap off when subjected to a bit of side-load.

Since this clamp came in a set from the reduced bin, and you can’t have too many clamps, I have a bunch of them knocking about so I haven’t needed to buy any replacements yet.

This Anonymous Clawhammer

We’ve had this old clawhammer for so long I don’t remember where it came from originally, but it has been a faithful servant for years until one day when I was (ab)using the claw and exerted what was obviously too much force and the handle finally gave up and snapped in two.

I really liked this hammer, so instead of buying a replacement, I will be making a new handle from a nice piece of slow-grown hardwood and repairing it. A future blog post will detail this process.

MacAllister Miniature Bench Vice

We bought a couple of these cheap, miniature bench vices for work-holding in the sewing room. Unfortunately the plastic knobs on the handles came pre-cracked from the factory and fell off as soon as the vice was out of the box. This means that they are, unsurprisingly, quite difficult to use due to the handle bar falling onto the floor and rolling under the bench whenever you turn it.

Since there seems to be nothing wrong with the vices themselves (qualified with a “yet,” since they are still brand new) I’ll be making some new vice handles in a future blog post so that we can give them a fair try.

In my opinion, one of the chief benefits to packaging your software for a Linux distribution is the ability of the distribution to carry patches. These patches generally come in two flavours:

1. Bug-fixes back-ported from the upstream project.

This is useful when the upstream project fixes a bug that affects their users, but have not yet released a new version of their software. Some projects have very long or infrequent release cycles, so the Linux distro may want to cherry-pick fixes and carry the patches until the the upstream project releases a fixed version, at which time the patches can be dropped.

2. Bug-fixes that have yet to be merged into the upstream project.

This is useful when the Linux distro fixes a bug that affects their users that the upstream project does not yet know about. Maybe it was missed upstream because they develop mostly on Mac or Windows, or maybe the bug only manifests on this particular distro. Either way, the Linux distro can carry the patch and work with the upstream project to get it merged. Once again, when upstream releases a version containing a fix, the distro can drop the patch.

In both cases, the end result is a better user experience for your software on Linux.

Which brings me back to Eclipse… Since GTK was updated to 3.18 on Fedora there have been some extremely visible rendering bugs in various parts of the Eclipse IDE on Fedora. Most of these bugs have been fixed upstream in Eclipse’s master branch, but it’s going to be a long time until Eclipse does another release that includes these fixes, even if they are chosen to be cherry-picked for the Mars.2 release. In Fedora, we chose to back-port them to current release Mars.1.

The following screenshot shows the difference it has made to the background colours in the workspace chooser dialog. Eclipse downloaded from eclipse.org is on the left, Eclipse from the Fedora package is on the right:

You should see the same difference in other dialogs too, such as wizard dialogs and the EGit commit dialog.

The next screenshot shows the difference it has made to the form editor, where text labels used to be positioned incorrectly or oddly truncated. Again, Eclipse downloaded from eclipse.org is on the left, Eclipse from the Fedora package is on the right:

Many thanks to Eric Williams for getting these highly visible SWT/GTK bugs fixed and committed upstream at eclipse.org and thus allowing me to back-port them to Fedora. I’m sure our users will appreciate it!

If you are an Eclipse on Fedora user, you can get the latest patches when version 4.5.1-6 of the Eclipse packages hit the “updates-testing” repository either today or tomorrow:

$ sudo dnf --enablerepo=updates-testing update eclipse\*

And if you have time, please leave feedback (positive or negative) by adding a comment in Bodhi, the Fedora updates system.