Blog
Page: 0 1
Gtk3 bugs on Debian (Gnome WM)
Date: 26/6/2021
Tags: linux gtk3 debian
So over the last month I've been poking at Lgi (the framework Scribe uses) on Debian trying to fix the numerous graphical glitches in the GTK3 port. And I've come to the realization that it's just horribly broken. Unlike the Ubuntu 16/18/20 installs I have that "just work". Debian seems to include the window shadow in all the coordinates. WTF? So mouse cursor x/y values are +24 compared to the window. (Ie if you move the mouse to the top left corner it's still 26,28 or something) Setting the size of the window results in a GTK_CONFIGURE message with a wildly different rectangle (out by something like 24 x 2?). Leaving all the controls in the window scaled off the right and bottom edges. None of the invalidation of dirty client content work correctly. And on top of that they use a different glib version.

They cookin up a mess over there in Debian land. So in the short to medium term I'm just going to not support Debian. Unless someone wants to chime in with some good ideas.
(0) Comments | Add Comment

Setting a DNS domain search in Ubuntu 20
Date: 10/3/2021
Tags: linux
There doesn't seem to be many good results for that search in Google so I'm documenting it. If you want to have an automatic domain suffix set for DNS in Ubuntu 20 you need to edit:

sudo nano /etc/systemd/resolved.conf

And uncomment the Domains field like this:

[Resolve]
Domains=myDomainSuffix

Then restart the service:

sudo service systemd-resolved restart

or reboot.
(0) Comments | Add Comment

Vnc startup on recent Ubuntu for Gnome
Date: 4/12/2020
Tags: linux
It's been bugging me for ages that there doesn't seem to be a valid recipe to use the Gnome desktop on Ubuntu under VNC. There are lots of "recipes" out there, mostly for older version of Ubuntu, but often they force a change of window manager or just plain don't work.

Anyway, after some time of hobbling along with a half working VNC server, I stumbled upon a working setup and though it was high time I documented it.

My .vnc/xstartup for Gnome:
#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
vncconfig -iconic &

dbus-update-activation-environment --all
dbus-launch --exit-with-session gnome-session --session=ubuntu &
gnome-shell &
(0) Comments | Add Comment

UDP and Ubuntu 14/Windows incompatibility
Date: 14/9/2017
Tags: linux ubuntu networking
For the last few weeks I've been mucking around in the background with an application I've called "ClipShare" that basically sits on the network and allows you to copy and paste between different machines. It supports text, images and files at the moment. I'm sure such a thing already exists but I like how it auto-detects all the machines running it on the network via UDP broadcast and supports Windows, Mac and Linux. It's far from production ready, it still crashes a bit and hangs up during file transfers sometimes. But over time I'm sure I'll iron that out.

Things like Samba, VNC and VM's (Vmware/Virtualbox) tend to have support for things like clipboard and file sharing. But in my experience they break very easily and it's 50/50 if they'll work or not. Hence having an alternative for getting the data across.

In testing I had a Ubuntu 14 VM running on a Windows host and for the life of me couldn't get the UDP packets to go from Ubuntu to Windows. I could see the packets arriving in Windows land via Wireshark but the recvfrom wouldn't get the packet. The packet wasn't large, just 40 bytes or so. In researching the issue I found that IP packets have a checksum, so I figured out how to get Wireshark to test the checksum. It confirmed the checksum was good. I could see using 'netstat -s' that there was an increasing count of 'Received Packets Discarded'. So Windows for reasons unknown was discarding the UDP traffic from Ubuntu. I tried turning off the Windows Firewall. No difference.

So then I decided to spin up my Ubuntu 16 VM and test the exact same code there. And sure enough it's working fine. So in conclusion I believe that at the OS level, Ubuntu 14 has some busted networking code. I can't tell what's wrong. Maybe it's a Windows thing. But it's basically meant I'm moving to Ubuntu 16 for all my Linux dev stuff. The main reason I had a Ubuntu 14 environment was that I had a working Raspberry Pi cross compiler install and I hate messing with a working env just for the sake of upgrading. However that broke recently anyway so it seems that the last reason for keeping 14 just disappeared.

Fun times.
(1) Comment | Add Comment

sem_post funkiness on Linux
Date: 9/8/2017
Tags: linux
I moved the Linux implementation of the GThreadEvent class (.h, .cpp) over to the sem_open, sem_post, sem_wait calls a little while back.

Initially I used named semaphores and that seemed to work ok. But after a few weeks I noticed that sometimes the call to sem_post would just quietly NOT increment the semaphore count, while still returning 0 (Success). Which causes the listening thread blocking in sem_wait to never wake up. Crucially this would break the destructor / exit loop of GEventTargetThread.

Googling this didn't turn up anything useful. I believe I was using the API correctly and the documentation is very sparse. Anyway I implemented the semaphores using the sem_init/sem_destroy (anonymous) and it seems to be robust. Still, I'd like to know what the deal is with the named ones. The general pattern of behaviour I would see is:
  • Thread 1: Create using sem_open
  • Thread 2: Block on sem_wait
  • Thread 1: Start shutdown - calls sem_post (returns 0, but no increment) to tell thread 2 that it needs to exit.
  • Thread 2: Still stuck blocking on sem_wait...
Fun times. I checked it under valgrind and no weird memory accesses. Sometimes it would work ok and exit gracefully. But most of the time it would hang.
(0) Comments | Add Comment

Merry Christmas
Date: 24/12/2015
Tags: scribe linux
I think for the first time ever? There is a simultaneous release of Scribe on 3 different platforms: Windows, Mac AND Linux. The new v2.1.3 build is tri-platform. The Linux (x64) build is a GTK2 app and runs ok on Ubuntu and Arch. Well that's all I've tested at this point.

It also runs on a Raspberry Pi 2 although it's a little slow. I know because I got bored and tried building it while working on some MC2 stuff.

Links to the i.Scribe builds:
(0) Comments | Add Comment

Portable OpenSSL for Linux
Date: 21/12/2015
Tags: shared-object linux openssl scribe
A year ago I worked out how to make a portable build of OpenSSL for Mac. And now with the imminent release of the Linux build of Scribe I need to do the same with the Linux build of OpenSSL.

After downloading and unpacking OpenSSL I configured it with:
./config shared -DPURIFY
The reason for adding the -DPURIFY #define is to suppress valgrind errors related to uninitialized memory usage.

Once that is built I had a look at the shared object paths with ldd:
matthew@ubuntu:~/Downloads/openssl$ ldd ./libssl.so.1.0.0 
	linux-vdso.so.1 =>  (0x00007ffc0e197000)
	libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f5c5ab6c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c5a7a7000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5c5a5a3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5c5b1c1000)
So it's not portable yet. I initially tried using the chrpath command but it can only modify existing RPATH records. My binary doesn't have any RPATH yet. So that didn't work. The next thing I tried was the patchelf command from here:
http://nixos.org/releases/patchelf/patchelf-0.8/
After building and installing I issued this command in the OpenSSL folder:
patchelf --set-rpath '$ORIGIN' ./libssl.so.1.0.0
Now to check if libssl pulls in the local libcrypto:
matthew@ubuntu:~/Downloads/openssl$ ldd ./libssl.so.1.0.0 
	linux-vdso.so.1 =>  (0x00007ffcdce86000)
	libcrypto.so.1.0.0 => /home/matthew/Code/Scribe/trunk/./libcrypto.so.1.0.0 (0x00007f39b99d8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f39b9613000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f39b940f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f39ba0a5000)
Yes! Now this build can be installed in the same folder as the Scribe binary and Scribe will use it without interfering with the system OpenSSL which is often out of date, or not built with -DPURIFY or missing.
(0) Comments | Add Comment