I like to manually update my OS packages through the command line. Mostly because I know the timing is right and I can restart afterwards. I also want to know which packages changed, where to expect improvements or potentially some breakage. None of this is fulfilled with the Gnome Software UI tool. It just makes my PinePhone user experience worse. So here is a way to just disable it:

mkdir -pv ~/.config/autostart && cp /etc/xdg/autostart/gnome-software-service.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/gnome-software-service.desktop
dconf write /org/gnome/desktop/search-providers/disabled "['org.gnome.Software.desktop']"
dconf write /org/gnome/software/allow-updates false
dconf write /org/gnome/software/download-updates false

Kudos goes to this guide: How to disable Gnome Software autostart

I revisited secushareBox (AKA boxen), built it from source and tried to experiment with it.

Sadly it didn’t want to print out any logs. Which is a problem, considering it was just silently failing. After improving the logging mechanism (logging into a file is no good if the user doesn’t know about the file!) I successfully went through the device initialization and installed the service onto my PinePhone.

Right after that I looked around the code some more and found out that there is nothing more. The tool is in a VERY early stage and all it does is the VPN service initialization. You’re on your own when it comes to actually using the service.

I’m considering making this my GNUnet homework, i.e. to extend this tool and make it somewhat usable. Meanwhile, here is my secushare-box repository with the improved logging.

After some Python taming I improved my wordpress-rest-curl tool. Now it has the ability to extract the post title.

If the first line begins with #, it uses the rest of the line as the post title and removes it from the post content. This way I can get rid of all the (no title) posts that had an embedded title that WordPress didn’t know about. Nice!

Autostart Apps in Phosh

I was wondering how to automatically start applications after booting a PinePhone with Phosh. Sounds like the standard way is to put .desktop files into ~/.config/autostart.

So to automatically start e.g. Gajim when Phosh starts, do this:

mkdir -p ~/.config/autostart
cp /usr/share/applications/org.gajim.Gajim.desktop ~/.config/autostart/

My motivation was to automatically start Gajim so that 1) I don’t forget to do it and 2) it unlocks the Default password storage (it prompts for the master password) right after reboot.

Related

• /usr/share/applications stores the currently installed .desktop application launcher files
• ArchWiki: XDG Autostart specifies the ~/.config/autostart directory
• ArchWiki: Desktop entries has info on the .desktop files

Creative Pebble Plus

I just brought home and briefly tested the Creative Pebble Plus 2.1 speakers. Considering these are 800 CZK (34 USD), they sound usable!

I enjoy the bubbly look. It is also great that they have a dedicated subwoofer instead of going with the regular 2.0 configuration of two meh not-even-wood speaker boxes.

Thumbs up

PinePhone VBUS_CTRL fix

I found out about another hardware fix that should be done to my rev 1.2 and 1.2a PinePhones: 2020-10-12: Backlight changes when switching between USB-C power modes

The backlight level changes depending on whether you connect a USB-C device or not. This is a very minor thing, though I previously noticed it as well. The fix is said to be easy (removing a connection on the PCB), so we’ll see. I’ve already fixed the VCONN switches on my rev 1.1 and 1.2 PinePhones, so this shouldn’t be a problem.

Luckily the next batch of PinePhones will not be affected by this problem. Nice!

PinePhone is an amazing project and I love that it keeps on improving, thanks to the work of the community and PINE64 as well. Even though every iteration (batch sold) of the device is slightly better in terms of the hardware, the previous revisions are still supported, they work fine and often times they are even DYI fixable. I hope this continues to be a great success!

SecuShare Runs

Last activity on the SecuShare Git Repository was almost exactly a year ago. Over the year the guys over at the core GNUnet did some API-breaking changes. Due to this, SecuShare does not compile.

Luckily the changes needed are mostly minor. I did some digging in the history of the GNUnet git repo and found out what were the API changes. The patch can be found in my gnunet-secushare git repository.

After this SecuShare could finally compile. The next problem was that it wouldn’t run. More precisely, gnunet-arm didn’t recognize the service.

I’m not sure if my installation is somehow misconfigured, but everything related to SecuShare was moved to a directory gnunet-secushare and not gnunet. That is why the service could not be picked up. I decided to symlink the config files and binaries into the right place:

cd /usr/share/gnunet/config.d
for i in multicast.conf psyc.conf psycstore.conf social.conf; do \
 sudo ln -s /usr/share/gnunet-secushare/config.d/$i $i; \
done

cd /usr/lib/gnunet/libexec
for i in gnunet-service-multicast gnunet-service-psyc gnunet-service-psycstore gnunet-service-social; do \
 sudo ln -s /usr/lib/gnunet-secushare/libexec/$i $i; \
done

I guess you could e.g. re-configure the build of SecuShare to move the files to the correct directory. Or update the gnunet-secushare-git AUR package. But maybe I’m just doing this wrong and gnunet-arm could be configured to look in multiple directories?

Anyway, with this I was able to start all the SecuShare services and run the gnunet-social app successfully. Not that it did anything useful. Then again I still haven’t looked at the code and what it is capable of. Let’s not forget this is an experimental prototype and not the final product. Next time!

First GNUnet phone call!

I was able to successfully make a phone call from my PinePhone to my laptop over GNUnet! Establishing a connection from the phone to the laptop worked, while trying it the other way around resulted in one of the clients crashing (and I wasn’t yet able to find out why exactly). Anyway, this is great!

So far my testing setup is this:

• both the laptop and the phone have an identity of their own, called ‘local’ on both devices: gnunet-identity -C local
• both have a reference to the other device through a PKEY GNS record: gnunet-namestore -z local -a -n XNAMEX -t PKEY -V XKEYX -e "1 d" -p, XNAMEX is e.g. phone and laptop, XKEYX is the other device’s public key obtained by gnunet-identity -d
• running the gnunet-conversation-gtk generated a ‘phone’ GNS record entry with the phone address, again on both devices

Then it is just about starting the gnunet-conversation-gtk app on both machines. On the phone I called the address phone.laptop.local. local is my local identity on the phone, laptop is the PKEY entry (GNS sub-zone) referencing the local entry on the laptop. And finally phone is actually taken from the laptop’s phone entry under local, created by the conversation app. This entry is not really available on the device yet. It needs to be obtained. And that is where GNS comes into play and fetches the needed data from the P2P network.

The call itself was established surprisingly quickly. Though this is likely due to both devices being on the same LAN and they probably know about each other by now.

I’m playing around with gnunet-conversation (and the GTK app). I managed to make a connection between my laptop and a phone, but every time the devices connect, one of the apps crash and core dump. It’s time to bring out the debugger!

As always, Arch Linux is your friend. And Arch Linux Wiki is your best friend! It has a guide on everything (GNUnet included!): Core dump

I spent some time going through the GNUnet handbook and tried out some of the commands. Naturally I compiled the most cutting edge version from git via AUR. Now I’m trying this on my LAN, building a connection between my laptop and my smartphone.

…

Now two of my smartphones have a running and working GNUnet service on them. One from git built locally, one installed from a package. Next up: creating a real network!

…

I was successful in connecting my laptop and my smartphone through GNUnet! I made a GNS query from the laptop to a record created on the phone and it came back. Not immediately of course, I had to first “pair” them as “friends” by adding the phone’s peer ID to the laptop. But then everything started magically working. Even on a second phone which also wasn’t previously able to propagate its GNS records.