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.

Starting With Mozilla Thunderbird 10 and newer (and up to at least Thunderbird 17), SSL/TLS protocol failures are no longer user discoverable.

In Mozilla Thunderbird 9 and earlier, if the SSL/TLS protocol handshake with a server resulted in a fatal failure, an error prompt was shown that notified the user about the failure. With Thunderbird 10 and newer, no feedback will be shown, and the user cannot know whether the failure is on the client side or on the failure side, and what exactly causes the problem. With Thunderbird 17, you can at least find the error message hidden in the "error console" that can be opened from the menu (hidden between all the other frequent messages that are dumped to that place).

One example scenario where you'd run into this silent failing is a typical enterprise configuration, where the server requires the client to authenticate with a client certificate. If the client certificate is not accepted by the server, or no such cert hat been installed yet, then Thunderbird will fail silently. (There are additional SSL/TLS protocol failure scenarios where you'll get the same silent failing.)

The reason for this regression is that error reporting was removed, instead of working on a smarter solution for Bug 682329 . All proposals that would have kept the error reporting in Thunderbird working and that could have been implemented by me with a reasonable amount of work were rejected.

In case you'd like to test the regression yourself, you can follow the steps below.

Use Thunderbird to configure an additional email account. When asked by Thunderbird 17 choose existing account.

- Username: test
- email: test@ssltls.de
- password: test (it's wrong, but it doesn't matter)
- check "remember password"
- click continue
- click "manual config"

- Select IMAP
- hostname ssltls.de (NO leading dot as proposed, in other words, NOT .ssltls.de)
- port 993
- SSL/TLS
- auth: normal password

SMTP configuration doesn't matter, you won't be able to send email through this configuration, but in order to allow you to complete the configuration:
- SMTP
- hostname: ssltls.de
- port 465
- SSL/TLS
- auth: normal password

click ok

With thunderbird 17, the test fails, click "advanced config", and in the next dialog click ok.

You'll now see the standard Thunderbird window, and you should have the test account configured. Click on the inbox. Your statusbar (lower part of the window) might show "connected to ssltls" but that's all you'll ever get with Thunderbird 10 and newer, even if you click the "get mail" toolbar button. You might eventually, much later, see a "connection timed out" notification popup, but that's incorrect, and it's not helpful in diagnosing the cause of the problem.

If you do the above with Thunderbird 9 and earlier, you'll get
"An error occurred during a connection to ssltls.de, SSL peer was unable to negotiate an acceptable set of security parameters. ssl_error_handshake_failure_alert"

With Thunderbird 17, this message can be found in the error console.

We must solve the problem that any CA is a single point of failure for the Web's trust, as used by the SSL/TLS protocol.

In October 2011 I had published a rough description of a system that I named MECAI, Mutually Endorsing CA Infrastructure.

It took some time to think in more detail about the various aspects, and I'm thankful for the discussions I had with other security experts, who pointed out missing details, problems that still need to be solved, etc.

Now I'm able to announce that I've published (yesterday) a more detailed writeup (version 2), you can find it here:https://kuix.de/mecai/mecai-proposal-v2.pdf

I'm looking forward to your feedback. It might be best to post your feedback to the IETF's mailing list therightkey.