SOLVED as a Service

Solutions to technical problems with open source software that I use. I post these so that the next time I encounter the same problem and do an Internet search, my own post will come up; this has now actually happened several times. If these posts help others, that’s a bonus.

If you encountered this error when trying to clone the Redis repository from GitHub recently, there is a solution. The error looks like this:

  $ git clone
  Cloning into 'redis'...
  remote: Counting objects: 42713, done.        
  remote: Compressing objects: 100% (33/33), done.        
  remote: Total 42713 (delta 15), reused 0 (delta 0), pack-reused 42680        
  Receiving objects: 100% (42713/42713), 19.29 MiB | 6.81 MiB/s, done.
  error: object 1f9ef1b6556b375d56767fd78bf06c7d90e9abea: \
  zeroPaddedFilemode: contains zero-padded file modes
  fatal: Error in object
  fatal: index-pack failed

The problem is that your ~/.gitconfig file probably has this setting:

          fsckObjects = true

…and/or perhaps these settings:

          fsckobjects = true
          fsckObjects = true 

Solution: set the value(s) to false while you clone Redis, then set them back to true afterwards.

See also this discussion for more; that’s where I originally stumbled across the solution. I’ve now cross-linked between this post and a ticket in the Redis issue tracker.

Pro non-tip: you might think that running

  $ git config --global fsck.zeroPaddedFilemode ignore

so as to get

  	zeroPaddedFilemode = ignore

in your .gitconfig would solve this problem in a nice targeted way, but it won’t, so don’t bother. See here for some discussion about that.

(This post is part of my SOLVED as a Service series, in which I post solutions to technical problems with open source software that I use. The point is the next time I encounter the same problem and do an Internet search, my own post will come up; this has now actually happened several times. If these posts help others, that’s a bonus.)

This is a public service announcement for anyone else who runs WordPress straight from SVN trunk and found their site broken after upgrading recently (probably after svn update took their site across the WordPress 4.1 boundary), such that instead of showing recent posts on the front page, you would see only this message:

Not Found.

Sorry, but you are looking for something that isn’t here.

Meanwhile, in your site’s Apache HTTPD error log, you’d see something like this:

  [Wed Nov 12 10:11:43 2014] [error] [client]              \
  WordPress database error You have an error in your SQL syntax;         \
  check the manual that corresponds to your MySQL server version         \
  for the right syntax to use near 'EXISTS '' ) \n                       \
  OR \n ( mt1.meta_key = '_stealth-publish' AND CAST(mt1.meta_value' at  \
  line 2 for query SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts \
  LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id            \
  AND wp_postmeta.meta_key = '_stealth-publish' )  LEFT JOIN wp_postmeta \
  AS mt1 ON ( wp_posts.ID = mt1.post_id ) WHERE 1=1                      \
  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish'  \
  OR wp_posts.post_status = 'private') AND ( \n  ( wp_postmeta.post_id   \
  IS NULL AND CAST(wp_postmeta.meta_value AS CHAR) NOT EXISTS '' ) \n    \
  OR \n  ( mt1.meta_key = '_stealth-publish'                             \
  AND CAST(mt1.meta_value AS CHAR) != '1' )\n) GROUP BY wp_posts.ID      \
  ORDER BY wp_posts.post_date DESC LIMIT 0, 10 made by                   \
  require('wp-blog-header.php'), wp,                                     \
  WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts,       \

The problem turned out to be an obsolete workaround in the stealth-publish plugin. This patch, which removes one line of code, fixed it for me:

  --- wp-content/plugins/stealth-publish/stealth-publish.php
  +++ wp-content/plugins/stealth-publish/stealth-publish.php
  @@ -154,7 +154,6 @@
                                          'relation' => 'OR',
                                                  'key'     => '_stealth-publish',
  -                                               'value'   => '', // This is needed to work around core bug #23268
                                                  'compare' => 'NOT EXISTS',

I haven’t analyzed this in depth, but here’s what I think is going on:

The workaround implemented by that line (that is, setting ‘value’ explicitly albeit only to the empty string, in order to get the right SQL result) is what’s recommended by WordPress bug #23268. However, that bug was fixed in changeset 27689, which (confusingly to those of us not accustomed to development involving multiple SVN trees, yikes) made it to in r27528:

  r27528 | wonderboymusic | 2014-03-24 14:57:15 -0500 (Mon, 24 Mar 2014) | 10 lines
  Changed paths:
     M /trunk/wp-includes/meta.php
  When using `meta_query` in a `WP_Query`, passing `NOT EXISTS` or `''`
  to `compare` should not require `value` to be set. The resulting SQL
  should then produce the appropriate `OR` clause for existence of
  non-existence after passing the query to the `$key_only_queries` stack
  Adds unit tests.
  Props chrisguitarguy, for the original patch.
  Fixes #23268.
  Built from

Okay, so the bug was fixed in WordPress core, and when I updated, I got the fix.

Unfortunately, the stealth-publish plugin hasn’t gotten the memo yet. That plugin’s latest version is 2.4, and hasn’t been updated since January 2014 — a couple of months before the relevant WP core bugfix. And the workaround in the code is now not only unnecessary, but actually causes an SQL syntax error — which is probably reasonable, since passing a value doesn’t really make sense in a NOT EXISTS test. It’s just that anyone who was using the workaround needs to stop doing so immediately.

I hope that stealth-plugin is still being maintained by its author. It’s hard to tell right now because the stealth-publish home page is currently down for maintenance:

Temporarily down for maintenance. Check back later.

So I’m publishing the patch here, to save other people time.

This post is a public service announcement for all those using GNOME 3.14 or higher (in my case on Debian GNU/Linux, although that detail probably doesn’t matter here).

I wanted to get rid of the workspace switcher popup. That’s the thing that looks like this and displays briefly whenever you switch workspaces:

GNOME workspace switcher popup

I do not know what that thing is for. It serves no purpose that I can see. When I go from one workspace to another, I am interested in the destination. Whether I moved conceptually “up” or “down” from another workspace to get there is utterly irrelevant — the popup is just visual noise on my screen, getting between me and wherever I was going. (And by the way, they’re not “up” and “down” in my mind anyway; they’re “left” and “right”. We’ll never understand each other, GNOME. We’re too different.)

A long time ago I disabled that popup, using Windsor Schmidt’s handy Disable Workspace Switcher Popup extension. I just put it into ~/.local/share/gnome-shell/extensions/, launched gnome-tweak-tool, went to the Extensions tab, enabled the new extension, restarted GNOME, built my own backhoe, and voilà, the workspace switcher popup stopped appearing. Or maybe it was the other order? I don’t know. It seems like an awfully complicated procedure, in retrospect, but anyway it worked.

Then recently, after I upgraded to GNOME 3.14, it stopped working — that is, the workspace switcher popup came back.

Here’s what I had to do to suppress it again:

Add “3.14” to the list of supported shell versions in ~/.local/share/gnome-shell/extensions/ In other words, I edited this line, adding the “3.13” and “3.14” on the end:

"shell-version": ["3.0", "3.0.1", "3.0.2", "3.2", "3.6", "3.8", "3.10", "3.12", "3.13", "3.14"],

Then restart GNOME, run gnome-tweak-tool, etc.

Looks like I’m not the only person to have run into this problem. Oskari Saarenmaa opened pull request #6 for this — which I didn’t even see before I created basically the same patch in pull request #7, but my patch supports GNOME 3.13 as well, for whatever that’s worth. (Was GNOME 3.13 ever released? I don’t even know, but if it was, my PR will support it. Yay.)

Why this stuff (along with similar things like disabling window animations when switching workspaces) isn’t tweakable via mouse clicks starting from Settings, I don’t understand. I guess you can launch dconf-editor and gnome-tweak-tool, if you’re the kind of person who knows about such things, but GNOME users shouldn’t have to be the kind of person who knows about such things.

Anyway, here endeth the public service announcement. This is how you can disable the workspace switcher popup in GNOME 3.14. Got that, search engine indexes? Good.

This post is for people who install Debian GNU/Linux and run into this error at the GRUB installation step:

  Executing 'grub-install /dev/sda' failed. 
  This is a fatal error ...

Solution: remove the USB stick from which you are installing Debian. Right now it’s /dev/sda and the target hard drive you’re trying to install to is /dev/sdb (during the installation process only). This has bitten me more than once.

Yes, seriously: the Debian installer apparently can’t figure out on its own that most likely the place you want to install the boot loader is on the huuuuuuuuge hard drive that you’ve been installing to all this time, not on the USB stick that you’ve been installing from.

I can totally understand how new research in AI would be needed to solve that problem.

This post is for people who use Redmine; others are welcome to stay for the ride if they wish.

I’m writing this post mainly so it will turn up in results when people do a web search to find out how to edit multiple issues at once in Redmine (e.g., search://redmine batch edit multiple issues/). I recently did that search, to no avail, and was stumped until someone gave me the answer in IRC.

It turns out the feature is there, a bit hard to find, and more powerful than I expected. Here’s the email I sent to my colleagues about it (lightly edited). I’m too lazy to even make screenshots, but the prose recipe should suffice:

  From: Karl Fogel
  To: The Team
  Subject: Most incredible Redmine hint ever.
  Date: Wed, 02 Nov 2011 18:40:56 -0400
  For those using the Redmine issue tracker:
  I don't normally like to spam lists with random UI hints, but in this
  case, there is a very powerful capability in Redmine that you probably
  won't spot unless someone tells you about it -- I myself just found it
  out from "_Mischa_The_Evil" in IRC [...].
  You can batch-edit a set of issues simultaneously -- change statuses,
  assignees, whatever -- by selecting them from an issues list and then
  right-clicking in the selection (highlighted blue area).  For example:
    * Go to
    * Select some issues using their checkboxes
      (or, use top-of-column green checkmark to select all)
    * Put your mouse in the blue selected area.
    * Notice how your mouse pointer has a funny stacky-looking icon
      next to it suddenly.  Those crazeeee Redmine developers!
    * Right-click, see the magical choices available to you now.
    * Weep for joy.  My god, it's full of stars...
  As there is no hint in the page content that this latent ability is
  there, I thought I'd better just mail about it.

In a followup comment in IRC, after reading this post, _Mischa_The_Evil said:

kfogel: :), nice one… btw: you can also multi-select by clicking anywhere on the issueline (not in inside links) combined with browser-dependent key. Most are ctrl-leftclick. I remember Opera being alt-rightclick (at least in the past, i remember reading something about changing it not so long a ago).