Skip to main content

Archlinux MySQL Workbench result grid

Introduction

I run ArchLinux for a while and one of my key software is MySQL Workbench.
Unfortunately, I did not get it working for a while.
Dont worry, it's working now, and this is my attempt to collect the informations in order to try to know what happenned.

What did not work

Several week after having a base Archlinux installation working, I managed to install MySQL Workbench from AUR.

The software behaved correctly except the result grid never displayed: I just got a blank grid, but when switching to the edit form the data were there. Data have been correctly retrieved and can be edited, but the problem was on the result grid display.

It was version 6.1.6 at that time, arround the end of June 2014.
I recompiled "mysql-connector-c++", "ctemplates" before building mysql-workbench: no way, no result grid.

I even tried to compile Mysql Workbench development version (6.2 at that time) against AUR  "mysql-connector-c++", "ctemplates" but no way: no result grid.

As far as I really needed some GUI to manipulate MySQL, I used Squirrel.SQL.

What made it works

Some time later, on the Mysql Workbench AUR package comments, I noticed there was a bunch of upgrades: Mysql Workbench was 6.2.3, and there was a glib2 patch!
Wait.. glib2? This Glib2? Great, let's try it now!

I upgraded "glib2" via "pacman" (as I keep my system up to date, it was already the latest available), then rebuilt "mysql-connector-c++" and "ctemplates" (just to be safe), then rebuit "mysql-workbench".

Guess what? I finally got the result grid!

What was wrong?

To be honest, I did not find any related information either in the mysql-workbench nor the Glib2 release notes. I don't understand what was not compatible, what did not work together, what was conflicting?

I'm writing this blog post in order to try to collect information about what happened. SO, folks, if you ever know: please tell me!

Comments

Popular posts from this blog

vmware net_device trans_start

VMWare Workstation 12 and Kernel 4.7 When recompiling vmware kernel modules on a kernel 4.7, I get this error:

/tmp/modconfig-xrrZGZ/vmnet-only/netif.c:468:7: error: ‘struct net_device’ has no member named ‘trans_start’; did you mean ‘mem_start’?     dev->trans_start = jiffies;
This seems to be an already encountered problem: http://rglinuxtech.com/?p=1746http://ferenc.homelinux.com/?p=356 I choosed to replace the line, instead of deleting it.

- dev->trans_start = jiffies; + netif_trans_update(dev); I also noted that I had to re-tar the modified sources instead of leaving them untared, because the compilation process only takes the archives. 
On precedent editions of these files, I just left the modified folders "vmnet-only/" and "vmmon-only/" expanded without the need to re-tar them.


Jira workflow for new projects

Associated workflow creation I'm a Jira Cloud user and begining from some version 6, I noticed that when I create a project, it automatically creates a Workflow and Issue Scheme that is prepended by the project key and which is a copy of the default scheme.
I always had to make a cleanup after creating a project. Default workflow for new projects I also miss a feature that would allow me to make a custom workflow (and globally custom project setting) the default for new projects I create.
Solution: Create with shared configuration While searching, I noticed that with Jira Cloud which is version 7.1.0 at the time I write, there is a link at the bottom of the "Create project" wizard:
"Create with shared configuration" will allow me to select the project I want the new one to share configuration with.

The new created project will use the same configuration as the project I selectThere will be no creation of Workflow and Issue Scheme that I need to cleanup

This fea…

dockerfile multiline to file

Outputing a multiline string from Dockerfile
I motsly use a Dockerfile by sourcing from a base ditribution: CentOS or Debian.
But I also have a local mirror and would like to use it for packages installation.

Espacially on CentOS it is about many lines to write to the /etc/yum.repos.d/CentOS-Base.repo file.

Easiest way: one RUN per line The first method that comes in mind is to issue one RUN per line to write.
Here you are:

RUN echo "[base] " > /etc/yum.repos.d/CentOS-Base.repo RUN echo "name=CentOS-$releasever - Base " >> /etc/yum.repos.d/CentOS-Base.repo RUN echo "baseurl=ftp://packages-infra.mg.rktmb.org/pub/centos/7/base-reposync-7 " >> /etc/yum.repos.d/CentOS-Base.repo RUN echo "gpgcheck=0 " >>…