This fixes some issues with libanjuta. The previous version spitted out hundrets
of error messages whenever gtkpod changed the progressbar. This issue is fixed
in 2.1.5.
Regression introduced by f91dacdd07.
Accidentally thought that it's compiling with XRandR support enabled,
because the cmake output said so:
Looking for XRRQueryExtension in Xrandr - found
Unfortunately, despite this message, the relevant part is:
Looking for XRRNotifyEvent - not found
So, ea4afb7 still holds true and I've added a small comment to avoid
this from happening in the future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I don't know what a "mouse keyboard" is, but instead of fixing the
description, let's use the one from the upstream README file, which is
also shorter than what we previously had.
The homepage http://synergy-foss.org/ is outdate since ages, so let's
point to the new site.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of the updated versions:
beta: 45.0.2454.15 -> 45.0.2454.26
dev: 45.0.2454.15 -> 46.0.2471.2
Changes for getting beta and dev channel to build:
* The reference for chrome::FILE_FLASH_PLUGIN doesn't exist anymore in
version 46, because it has been dropped upstream, see the following
review URL:
https://codereview.chromium.org/1255943002
We set the PPAPI Flash path using a command line flag anyway, so it
doesn't hurt us if we don't patch that path (which was an old
artifact from the NSAPI->PPAPI conversion anyway).
Changes for the dev channel only:
* It seems that in the SCM, chrome/test/data/webui/ contains a lot of
files, however they are missing in the tarball.
This has been reported upstream at: https://crbug.com/515917
Our fix is to just not include webui/i18n_process_css_test.html at
all, to avoid the configure (gyp) phase to fail, because we're not
building tests anyway.
All channels built and tested by my Hydra instance at:
https://headcounter.org/hydra/eval/218978
Test reports:
x86: https://headcounter.org/hydra/build/723341/download/1/log.html
x86_64: https://headcounter.org/hydra/build/723342/download/1/log.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Some plugin bundles must be unpacked when used in Eclipse. With this
change the plugin manifest is checked for the setting indicating that
unpacking should happen.
Simplifies `buildEclipsePlugin` and `buildEclipseUpdateSite` functions
such that they require only absolutely necessary arguments. Also
add/expand comments slightly.
It does not really make sense to install the plugin packages directly as
they are intended for use with `eclipseWithPlugins`. Therefore it is
best not to present them to users as such.
This function provides functionality common to all Eclipse plugin
builders. In particular, it sets a package name and flags the derivation
as an Eclipse plugin.
