It turns out I hardcoded the output path that qt's tarball extracts.
But that path is versioned (4.8.5 for example).
As I've already merged x-updates on my own system, my qt version was
different (4.8.4 vs 4.8.5). Made the path-guessing more flexible, so
now it should work with any 4.8.*
Upstream insists on using private qt headers.
We do not want nixpkgs' qt to export those.
So I provided a small hack to take them directly from qt's source tarball.
I made sure everything uses the normal system qt and headers, except for the
1 .so file (qt_hack) that needs these private headers.
Because of this, there is barely any increate in size or buildtime.
Upstream release notes:
- Add Geoclue location provider by Mathieu Trudel-Lapierre.
- Allow brightness to be adjusted (-b).
- Provide option to set color temperature directly (Joe Hillenbrand).
- Add option to show program version (-V).
- Add configure.ac option to install ubuntu icons. They will no longer
be installed by default (Francesco Marella).
- config: Look in %userprofile%/.config/redshift.conf on windows platform.
- Fix: w32gdi: Obtain a new DC handle on every adjustment. This fixes a
bug where redshift stops updating the screen.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Slic3r is a G-code generator for 3D printers.
- Math-Clipper and Boost-Geometry-Utils have been bumped to satisfy
Slic3r.
- Slic3r has problems with perl 5.16 due to a locale issue (comma vs
period in floating point numbers). So we use perl 5.14.
- The tests fail, so we skip them. According to the author of Slic3r,
that should be safe:
"Tests failed because of a typo when the 0.9.10b tag was applied.
You can safely ignore the test results, Slic3r will work."
See https://github.com/alexrj/Slic3r/issues/1303
For reference, the errors look like this:
Use of uninitialized value $deg in numeric eq (==) at /tmp/nix-build-perl-slic3r-0.9.10b.drv-0/git-export/t/../lib/Slic3r/TriangleMesh.pm line 328.
# Looks like your test exited with 255 before it could output anything.
The second failure, and the last one I'm going to try today:
http://hydra.nixos.org/build/5404634
On the bright side there is at least the fact that version 1.4.10 has failed on
Darwin already, so I guess we don't have a lot of Mac users using Synergy.
Latest (failed) build of 1.4.10:
http://hydra.nixos.org/build/5359408
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Seems that crypto++ in nixpkgs doesn't build on Darwin, so let's use bundled
crypto++ until the version in nixpkgs works well.
This refers to the following build:
http://hydra.nixos.org/build/5404516
Hopefully, this will fix it on Mac OS X, because I don't have a Darwin machine
for testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm heavily using synergy for daily work, so I'm most probably going to watch
out for changes/improvements/bugs :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Integration tests don't seem to work right now, so let's see if we can figure
out a way to enable them later. But at least running unit tests is better than
not running any tests :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Nowadays, multiple monitor setups are quite common, so I suppose we'd want
support for that. Especially because users might get confused if synergy is
unable to pick the right screen resolution and thus cause edges to be cut off
from the available pointing area.
The postPatch hook is to force cmake into thinking that we have XRRNotifyEvent,
which we _do_ have with the xrandr version shipped in nixpkgs. Automatic
detection from CMakeLists.txt fails here because it tries to search for the
symbol within the libX11 store path.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings in support for encryption and thus requires the crypto++ library as
an additional dependency. Unfortunately the upstream integration isn't quite the
way we'd like it to be, so we need to add a small patch to ignore the bundled
version and use the package from nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
