Use the most recent versions of branches coq8.4pl6 and coq8.5-legacy
with the corresponding versions of Coq.
Use a two month old version with Coq-8.6 to avoid issue #45:
https://github.com/QuickChick/QuickChick/issues/45
pyrtlsdr needs pandoc at build time. Fixes the build since commit
f6eb190e70
("python.pkgs.pyrtlsdr: disable tests to fix build"). (That commit
bumped the package to a new version.)
Upstream changes:
* Tesseract 4.00.00alpha:
* Version parsing: Ignore suffix (so '4.00.00alpha' == (4, 0, 0))
* Libtesseract: Load libtesseract.so.4 instead of libtesseract.so.3
if available
* Support for Tesseract 3.05.00:
* Builders: Split field 'tess_conf' into 'tess_flags' and 'tess_conf'
* Libtesseract: If available, use
TessBaseAPIDetectOrientationScript() instead of
TessBaseAPIDetectOS
* Libtesseract:
* Workaround: Prevents possible segfault in image_to_string() when
the target language is not available
Full upstream change log can be found at:
https://github.com/openpaperwork/pyocr/blob/b006123d1d002711b9/ChangeLog
The tesseract.patch for supporting Tesseract version 3.05.00 has been
applied upstream and we can safely drop it.
We now use substituteInPlace in conjunction with a patch to insert the
relevant store paths instead of sed, so it's less fragile whenever we
have upstream changes in handling of these paths.
I've tested this by reverting 48a941e29f and applying a build
fix patch of Cuneiform 1.1.0 from Arch Linux, because right now
Cuneiform is an experimental version that can't be fixed on behalf of
pyocr (the reason is that pyocr needs to get a list of languages, which
doesn't work in that version anymore).
In addition to that I've successfully built paperwork-backend which by
now is the one package which depends on pyocr. However, I didn't do
runtime tests of Paperwork.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c
We already have a patch feeling lonely inside the python-modules
directory and to have everything at one place let's actually move pyocr
into its own dedicated directory so it's easier to patch it up (which
we're going to).
Right now, the package fails to build because of a few test failures, so
I haven't tested this apart from evaluating.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously, this error was coming up in xcbuild:
ld: malformed 32-bit x.y.z version number: 1068638
It’s an interesting error because it only happens with certain hashes for the
nixpkgs sdk. For instance, on latest nixpkgs unstable channel, the hash for the
xcbuild sdk is:
/nix/store/w6mwbdaz9calyii0fyxspl51f1068638-nix.nixpkgs.sdk
that is an issue we pass -isysroot ${sdk} to clang where it will interpret that
hanging "1068638". It would probably go away as soon as the hash changes but
this hacky fix will solve the problem.
1. Detect (and automatically handle) parasitic systems.
2. Each nix package has only one asd, and (almost) every parasitic
package inside it builds.
3. Ensure that parasitic systems are compiled.
4. Remove unnecessary testnames lisp override mechanism (the
testnae/testSystem is replaced by parasites/buildSystems).
5. Parasitic systems (if included in the system closure) become
aliases to their host package.
6. Support caching fasl files in a known directory (for faster
re-generation after modifying quicklisp-to-nix-system-info).
7. Eliminate unnecessary overrides. We're going to determine ALL
lisp dependencies correctly.
8. Don't try to "build" lisp packages with make. lispPackages should
be about bringing in a lisp library.
9. Eliminate the hand-maintained list of aliases. Parasites should
become aliases. Everything else should be a real package.
GMime home has moved to Github as the list of commits clearly shows,
i.e.:
b5cbc68a67
The description is updated as well to be closer to the one used there
and over at gnome.org.
