Showing posts with label bug. Show all posts
Showing posts with label bug. Show all posts

02 July 2013

471. Debian Jessie -- gnome-shell bug

Update 3/7/2013:
there are now *gnome-bluetooth packages (3.8.1-2) in the jessie repos now. While I haven't looked closer at them, I presume that they fix this issue.

(on a different note: dist-upgrade currently removes gnome...)

Original post:
I've used debian testing since early 2011, and I've only had a few minor issues during that time.

However, sometimes things happen that reminds you that the Testing release is not meant for mission critical work (and makes me happy that I only use Jessie on my laptop, which I mainly use at home).


Last night I did upgrade and dist-upgrade, which installed the following packages according to /var/log/apt/history:
Start-Date: 2013-07-01  22:03:17
Commandline: apt-get dist-upgrade
Install: p11-kit:amd64 (0.18.3-2, automatic), libgnome-bluetooth11:amd64 (3.8.1-1, automatic), libgcr-base-3-1:amd64 (3.8.2-3, automatic), libtasn1-6:amd64 (3.3-1, automatic), libgcr-ui-3-1:amd64 (3.8.2-3, automatic)
Upgrade: libnm-gtk0:amd64 (,, libgcr-3-1:amd64 (3.4.1-3, 3.8.2-3), gir1.2-gcr-3:amd64 (3.4.1-3, 3.8.2-3), network-manager-gnome:amd64 (,, gnome-keyring:amd64 (3.4.1-5, 3.8.2-2), gcr:amd64 (3.4.1-3, 3.8.2-3), gnome-bluetooth:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gnomebluetooth-1.0:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gck-1:amd64 (3.4.1-3, 3.8.2-3)
End-Date: 2013-07-01  22:03:29

Now what happens when I log in to gnome via gdm3 I get an empty desktop with no menus, no hot-spots or anything else indicating that things worked out. Alt+F2 doesn't work either, and conky doesn't start.

The only thing that does work is
* my keyboard shortcuts (I've mapped ctrl+shift+Down arrow to chromium)
* guake (which starts with gnome)

ps aux|grep gnome-shell
returns nothing, which might be a clue.

Looking at the debian forums the closest post seems to be (although erroneously labelled -- gdm3 DOES start):

That in turn led to this bug report:

My gnome-shell version is 3.4.2-8,

I don't understand how gnome-bluetooth causes this, especially given that I've disabled bluetooth in rcconf, but whatever it takes...

I tried applying the patch but it failed:
mkdir ~/tmp
cd ~/tmp
wget ";filename=GnomeBluetooth.patch;att=1;bug=712861" -O blue.patch
sed -i 's_js/ui/status/bluetooth.js_/usr/share/gnome-shell/js/ui/status/bluetooth.js_g' blue.patch
sudo patch -p0 < blue.patch

Instead, I ended up making the changes to /usr/share/gnome-shell/js/ui/status/bluetooth.js by hand (remember that you can always use the ttys using ctrl+Fx):
  6 const Gio =;
  7 const GnomeBluetoothApplet =;
  8 const GnomeBluetooth =;
  9 const Gtk =;

and then delete the Applet part in GnomeBluetoothApplet so that it reads
 38         this._killswitch.connect('toggled', Lang.bind(this, function() {
 39             let current_state = this._applet.killswitch_state;
 40             if (current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED &&
 41                 current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER) {
 42                 this._applet.killswitch_state = this._killswitch.state ?
 43                     GnomeBluetooth.KillswitchState.UNBLOCKED:
 44                     GnomeBluetooth.KillswitchState.SOFT_BLOCKED;
 45             } else
 46                 this._killswitch.setToggleState(false);

Then do it again:
 96     _updateKillswitch: function() {
 97         let current_state = this._applet.killswitch_state;
 98         let on = current_state == GnomeBluetooth.KillswitchState.UNBLOCKED;
 99         let has_adapter = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER;
100         let can_toggle = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER &&
101                          current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED;

At this point I rebooted and everything was back to normal (you can try simply doing 'sudo service gdm3 restart' instead of rebooting).
Anyway, done.

06 February 2013

332. Gnuplot: bug(?) in current debian testing package

Update 2:
"Note that gnuplot uses both "real" and "integer" arithmetic, like FORTRAN and C. Integers are entered as "1", "-10", etc; reals as "1.0", "-10.0", "1e1", 3.5e-1, etc. The most important difference between the two forms is in division: division of integers truncates: 5/2 = 2; division of reals does not: 5.0/2.0 = 2.5. In mixed expressions, integers are "promoted" to reals before evaluation: 5/2e0 = 2.5. The result of division of a negative integer by a positive one may vary among compilers. Try a test like "print -5/2" to determine if your system chooses -2 or -3 as the answer."

I guess it's a feature. I guess I just need to remind myself of it every now and again...

Update: version 3.7.3 behaves the same way.

I use gnuplot for fitting data for scientific publications and every time I discover a bug it makes me seriously worried that I've somehow published something which will turn out to be incorrect.

It's not without reason -- Gnuplot version 4.4.0 in Debian Testing garbled small and large numbers:

I'm not sure whether this is a bug, but gnuplot 4.6.0 (current version in debian testing) screws up fractional powers.

gnuplot> print 9**(1/2)
gnuplot> print 9**(0.5)
gnuplot> print sqrt(9)

Somehow this works:
gnuplot> print 10**(2)
gnuplot> print 10**(2.0)
gnuplot> print 10**(6/3)
but not this
gnuplot> print 10**(1)
gnuplot> print 10**(1/2)
gnuplot> print 10**(1/3)
gnuplot> print 10**(0.3333333)
gnuplot> print 10**(1/3.0)

So the error seems to be due to the usual issue of distinguishing between integer values and real values e.g. the following example in Python 2.7:
>>> print 1/3
>>> print 1/3.0

I still don't think this is intended behaviour in gnuplot, and it's certainly dangerous

Upstreams version 4.6.1
tar xvf gnuplot-4.6.1.tar.gz
cd gnuplot-4.6.1/
./configure --program-suffix=-4.6.1 --prefix=$HOME/.gnuplot-dev
make install
cd $HOME/.gnuplot-dev/bin

gnuplot> print 9**(1/3)
gnuplot> print 10**(1/3)
gnuplot> print 10**(6/3)
gnuplot> print 10**(3/6)

27 November 2012

285. Minor bug in ECCE

I'll classify this as a bug, since the specificity of it surely must mean that it is an unintended behaviour. Basically you lose your hand-edited changes in your input files if you're not careful.

By Editor I don't mean the vim editor, but rather then Job Editor in Ecce.

 A demonstation: 

1. Create an input in ECCE. In this case I created a single-point energy calculation of dioxygen. Hand-edit the input file by clicking on Final Edit and add e.g. maxiter 99 in the dft block.

 2. Run the job

 3. Open the Editor. With the Editor open, click on Run Mgmt/Reset for restart. (In spite of the figure below, it has nothing to do with whether the vim editor is open or not.)

 4. Your hand-edited changes are now gone.

 In contrast, if the Editor is not open when you click on Run Mgmt/Reset for restart the changes will be kept.

17 February 2012

70. Bug in Debian version of Gnuplot 4.4.0

The symptom:

Gnuplot 4.4.0-1.1 (the current Debian version) can't handle numbers smaller than 10**(-9) properly
me@beryllium:~/Dropbox$ gnuplot
Version 4.4 patchlevel 0
last modified March 2010
System: Linux 3.2.0-1-amd64
Copyright (C) 1986-1993, 1998, 2004, 2007-2010
Thomas Williams, Colin Kelley and many others
gnuplot home:
faq, bugs, etc:   type "help seeking-assistance"
immediate help:   type "help"
plot window:      hit 'h'
Terminal type set to 'wxt'
gnuplot> print 10**(-9)
gnuplot> print 10**(-10)
gnuplot> print 10**(-11)

It's not related to set zero.

gnuplot> set zero 1e-20
gnuplot> print 10**(-11)
gnuplot> print 10**(-10)
gnuplot> print 10**(-9)

Currently, I'm using version 4.4.0-1.1 -- which is used in all versions of Debian.

me@beryllium:~$ apt-cache showpkg gnuplot
Package: gnuplot
4.4.0-1.1 (/var/lib/apt/lists/ (/var/lib/apt/lists/ (/var/lib/apt/lists/ (/var/lib/dpkg/status)
4.4.0-1.1 - gnuplot-nox (2 4.4.0-1.1) gnuplot-x11 (2 4.4.0-1.1) gnuplot-doc (2 4.4.0-1.1)
4.4.0-1.1 -
Reverse Provides: 

The bug affects the output from the print statement as well as the internal handling of numbers:

gnuplot> plot 10**(-11)
Warning: empty y range [8.22536e-10:8.22536e-10], adjusting to [8.14311e-10:8.30761e-10]

gnuplot> plot 10**(-12)
Warning: empty y range [-1.3748e-09:-1.3748e-09], adjusting to [-1.36105e-09:-1.38855e-09]
gnuplot> plot 10**(-12)/10**(-10)
Warning: empty y range [-1.93855:-1.93855], adjusting to [-1.91917:-1.95794]

gnuplot> set xrange [10**(-9):10**(-12)]
gnuplot> plot x 

The bug is similar to this:

Integer overflows are not reported. A hint could be printed that real
(float) numbers should (could) be used to avaid this problem.
gnuplot> print 1000000*100000
gnuplot> print 1000000**2
gnuplot> print 100000**2
gnuplot> a=2000000**2
gnuplot> print a
gnuplot> print 10000**2 # OK
which ended up with "Added tag(s) wontfix. "
Ergo, if you're using debian and you are using gnuplot for serious purposes (research, work), compile your own version of gnuplot as per below.

ANNOYING: there are packages such as maxima which depend on gnuplot. Remove the debian version of gnuplot using apt-get and you lose maxima too. Octave, which one would think would be a heavier user of gnuplot, does not depend on gnuplot but merely recommends it.

Package: maxima                        
State: not installed
Version: 5.26.0-3
Priority: optional
Section: math
Maintainer: Camm Maguire <>
Uncompressed Size: 47.8 M
Depends: libc6 (>= 2.3), libgmp10, libreadline6 (>= 6.0), libx11-6, gnuplot-x11
Maybe time to build your own maxima.deb? In the end you will end up with a very inelegant system with mixed packages.

I've compiled and checked the current upstreams version:

me@beryllium:~$ sudo apt-get autoremove gnuplot gnuplot-nox
cd ~/temp
 mv gnuplot-4.4.4.tar.gz\?r\=http\ gnuplot-4.4.4.tar.gz
tar -xvf gnuplot-4.4.4.tar.gz
sudo checkinstall

me@beryllium:~/temp/gnuplot-4.4.4$ sudo dpkg -i gnuplot_4.4.4-1_amd64.deb
(Reading database ... 446323 files and directories currently installed.)
Preparing to replace gnuplot 4.4.4-1 (using gnuplot_4.4.4-1_amd64.deb) ...
Unpacking replacement gnuplot ...
Setting up gnuplot (4.4.4-1) ...
Processing triggers for man-db ...
me@beryllium:~/temp/gnuplot-4.4.4$ gnuplot
Version 4.4 patchlevel 4
last modified November 2011
System: Linux 3.2.0-1-amd64
Copyright (C) 1986-1993, 1998, 2004, 2007-2011
Thomas Williams, Colin Kelley and many others
gnuplot home:
faq, bugs, etc:   type "help seeking-assistance"
immediate help:   type "help"
plot window:      hit 'h'
Terminal type set to 'x11'
gnuplot> print 10**(-9)
gnuplot> print 10**(-10)
gnuplot> print 10**(-11)
gnuplot> print 3.14*10**(-10)
gnuplot> print 3.14*10**(-20)
gnuplot> print 3.14*10**(-21)
gnuplot> print 3*10**(-12)/(4*10**(-14))

Ergo, upstreams v 4.4.4 works.

Update: Here's my bug report:

20 December 2011

35. Fixing: gnome alt+f2 broken, returns command not found -- debian testing current bug, description and solution

An explanation and solution is here:

My version of the solution above is a follows:

1. First, locate the file to edit

locate utils.js | grep misc

which returns


2. Next, confirm that argc is present (this is what's causing the problems)

cat /usr/share/gnome-shell/js/misc/util.js | grep argc

which returns

        let [success, argc, argv] = GLib.shell_parse_argv(command_line);
    let success, argc, argv;
        [success, argc, argv] = GLib.shell_parse_argv(command_line);

There are more elegant ways of doing this, but this is how I roll.

3. Edit /usr/share/gnome-shell/js/misc/util.js as root

sudo vim /usr/share/gnome-shell/js/misc/util.js (you can of course use gedit, nano, emacs etc.)

search for argc and remove all instances of of it, so that
[success, argc, argv] turns into to  [success, argv]

Once you've removed all argc, save and then hit alt+f2 in gnome, type r and enter to restart the shell. Then hit alt+f2 and type e.g. gedit to test it

It now works!

Reading through bug reports it seems it won't be fixed in Debian -- instead we'll have to wait until gnome 3.2 rolls out. Or just follow the instructions above.


(Current version of gnome-shell is 3.0.2-8+b1)

Hitting alt+f2 to start e.g. gedit or another program used to be straightforward.

During the past week it hasn't worked properly though -- instead the entry of any command has returned a 'command not found'. If you instead of simply typing in gedit type in /usr/bin/gedit, chances are the computer will experience an odd sort of freeze -- the top bar will be unresponsive, the black entry box will remain, the screen will be shaded, but gedit won't open. You will, however, be able to continue using your computer, but it'll be a dark experience.

Symptomatic descriptions of the bug and experiences are available here: