The internal microphone on my Linux system didn't work. In order to enable it, I had to disable the driver for the internal analogue (classic) modem.

In order to check, if you might potentially be affected from the same issue, open a terminal, and run the following command:
* lsmod |grep snd_hda_codec_conexant

If the above command produces output, then your system has that particular Linux kernel module loaded, and might be blocking the internal microphone.

The solution is to prevent the system from loading the kernel module on startup. You can use the following commands:
* echo "blacklist snd_hda_codec_conexant" > /tmp/modem-blacklist.conf
* sudo cp /tmp/modem-blacklist.conf /etc/modprobe.d/

Now restart your computer and test if your microphone works.

Gnome-Shell and Cinnamon behave differently, which includes how tray notification icons are being treated. While Cinnamon uses the classic approach of showing them, the Gnome-Shell developers would like to see them avoided.

Therefore it's currently the application's job to figure out what to do. Unfortunately Gnome-Shell and Cinnamon have many similar properties from an application's point of view, so it's necessary to find a way to distinguish them from within the code.

Thanks to Bastien Nocera and Shaun McCance for suggesting the use of D-Bus to distinguish between Gnome-Shell and Cinnamon.

As I was driven to fix the deja-dup backup tool, I was looking for a solution in the Vala programming language, and below is some code to detect a running Cinnamon desktop environment. I tested that the code works in Cinnamon version 1.4.0 and 1.6.7.

[DBus (name = "org.Cinnamon")]

public interface cinna : GLib.Object {
    public abstract string CinnamonVersion { owned get; }
}

int main (string[] args) {
    string cv;

    try {
	cinna c = GLib.Bus.get_proxy_sync (BusType.SESSION, "org.Cinnamon", "/org/Cinnamon");
	cv = c.CinnamonVersion;
    } catch (Error e) {
        stderr.printf ("%s\n", e.message);
        return 1;
    }

    if (cv == null) {
	stdout.printf ("not running cinnamon\n");
    }
    else {
	stdout.printf ("running cinnamon version %s\n", cv);
    }

    return 0;
}

I'd like to thank Evan Nemerson who helped me understand the correct syntax to access a D-Bus property using Vala.

Update March 18
Below is a reverse test, which tests for a property found in Gnome-Shell:

[DBus (name = "org.gnome.Shell")]
public interface GnomeShell : GLib.Object {
    public abstract string ShellVersion { owned get; }
}

int main (string[] args) {
    string gsv = null;

    try {
	GnomeShell gs = GLib.Bus.get_proxy_sync (BusType.SESSION, "org.gnome.Shell", "/org/gnome/Shell");
	gsv = gs.ShellVersion;
    } catch (Error e) {
        stderr.printf ("%s\n", e.message);
        return 1;
    }

    if (gsv == null) {
	stdout.printf ("not running gnome-shell\n");
    }
    else {
	stdout.printf ("running gnome-shell version %s\n", gsv);
    }

    return 0;
}

I recently upgraded my system from Fedora 17 to Fedora 18, and afterwards Evolution 3.6 (using the evolution-rss plugin) had an empty list of feeds in edit/preferences/news+blogs.

Thanks to Lucian Langa who pointed me to a manual migration script, which fixed the issue for me.

In order to compile and use it:
- download and save the migration script

- make sure you have packages gcc, GConf2-devel and gtk2-devel installed (you might need additional packages to compile it)

- open a terminal and change to the directory where you saved the .c file and run the following command:

gcc `pkg-config --cflags gtk+-2.0` `pkg-config --cflags gconf-2.0` `pkg-config --libs gtk+-2.0` `pkg-config --libs gconf-2.0` -o evolution-rss-migrate-feeds evolution-rss-migrate-feeds.c

- if no errors are shown, you should now have the executable. Check using

ls -l evolution-rss-migrate-feeds

- quit evolution. Now run the migration script

./evolution-rss-migrate-feeds

(no output will be printed)

- Start evolution, go to edit/preferences/news+blogs, and you should now see the feeds that you had configured in evolution 3.4.x prior to the upgrade

Gnome 3.6 has changed the default behavior of scrollbars.

For as long as I can think, since I've started to use computers with graphical user interfaces, I've been used to clicking the empty space below (or above) a scrollbar's position indicator, in order to scroll down (or up) exactly one page.

That classic behavior has been changed in Gnome/Gtk, the new behavior is to jump to an absolute position, based on exactly where you click.

I don't like the new behavior, I believe changing the default was an unfortunate decision. I'm using multiple computers, and in my opinion, if I cannot predict the way the computer will react to clicks, because each computer might have a different default, that's a serious regression in usability.

I'm documenting how the classic behavior can be configured, thanks to Ray Strode for telling me how to:

Edit file ~/.config/gtk-3.0/settings.ini and add the following:

[Settings]
gtk-primary-button-warps-slider = false

Here is how I had success to use Buildbot with NSS on Windows systems.

Because buildbot on Windows isn't able to kill the full set of processes belonging to an active build/test job, each time the connection between buildbot-master and buildbot-slaves (the slave on the Windows client) breaks, the slave system ends up being in a mess, where parts of the old job are still active. In that state, a new started job will misbehave, because old and new job fight against the files on disk.

I tried many approaches, including attempts to kill the jobs by name. For various reasons, most of them didn't work right for me. And by work right, I expect that the system automatically recovers from the failure, and fully restarts the job - without requiring manual cleanup by an admin, without requiring manual restart of jobs.

I heard that some consumers modify buildbot to their needs, but that is not acceptable to me. I need to focus on other things, I don't have time to learn the internals of buildbot. For that reason, approaches like "use a custom logfile parser" are not an option for me.

Here is a solution that seems to work for me, which involves automatically rebooting the Windows slave after each connection failure to the buildmaster. We don't reboot if jobs finish without exceptions (a build failure is fine, it isn't an exception).

It requires a Windows slave with buildbot-slave installed.
The buildbot-master must be configured to allow only one build for the Windows slave, BuildSlave(max_builds=1, ...).
You must setup the slave to automatically login and start the buildbot-slave after a reboot (e.g. using the StartUp program group).
If you use an encrypted tunnel for the connection between buildslave and buildmaster, that tunnel must be automatically started after reboot, too.

Let's say you have a build-and-test.sh script that you use on Linux and other Unix-like platforms, which you run from buildbot master as a "buildstep".

On Windows, we'll use different buildsteps, and one of them will call the build-and-test.sh script. (Note that the NSS build system uses the Mozilla-build tools on Windows, including MSYS, which provide a Unix-like environment, including a bash shell).

Let's say your non-Windows buildsteps are:
* get source code
* build-and-test.sh

On Windows, we'll use:
* maybe-reboot.bat
* get source code
* start-b-and-t.bat

The .bat files have the following contents:

==== maybe-reboot.bat ====
IF EXIST ..\buildbot-is-building (
    del ..\buildbot-is-building
    shutdown /r /t 0

    timeout /t 120
)
==========================

=== start-b-and-t.bat ====
echo running > ..\buildbot-is-building

rem This is an Example.
rem Do whatever you must do to start your build.

"%MOZILLABUILD%\msys\bin\bash" -c "hg/tinder/buildbot/buildprnss.sh %*"

if %errorlevel% neq 0 (
  set EXITCODE=1
) else (
  set EXITCODE=0
)

del ..\buildbot-is-building


exit /b %EXITCODE%
==========================

This assumes that the user account used for building and testing has permission to reboot the system, executed using Window's "shutdown" tool.

If all goes well, what happens is:
* maybe-reboot will do nothing
* start-b-and-t will create a file to signal that it's active,
and will delete the file after the job has completed.

In case there is an exception, and start-b-and-t is still active, what happens is:
* buildslave will notice the exception and attempt to kill the active job. For advanced build/tests this will partially fail.
* buildmaster and buildslave regain the connection, and buildmaster asks to start the build.
* maybe-reboot will detect that a job is still active, and will prepare to reboot
* it will clean up by removing the status file, to ensure we will proceed to start-b-and-t after the reboot
* it will ask the system to reboot immediately
* because it will take some time before the reboot has killed all active processes, we must make sure that this job won't make things worse by running the job again, in parallel
* the timeout command will wait for 2 minutes, that should be enough for the reboot to happen, including termination of maybe-reboot.bat
* buildmaster will notice an exception, and will remember once again to retry that interrupted job
* as soon as the slave has rebooted and automatically started the buildslave, the job will be restarted in a clean environment.

You might ask, why are we using the status file in the parent directory of the buildbot
slave directory? ("..\")
Because your slave might be configured to build multiple different configurations,
that file must be in a place that is shared by all those build configurations.
The parent directory of an individual configuration is buildbot's main slave directory,
that makes it a good place for that file.

[edit]: Updated start-b-and-t.bat to return the inner script's exit status to buildbot.