I'm not exactly sure why, but it seems as the python2 build
of yowsup is breaking.
see https://github.com/tgalal/yowsup/issues/2325
It seems to be recommended to use python3 for building and disable
the usage of python2 which fixed the build.
- update and automate merging
The automated merging process should eliminate the need for keeping a
nixos-specific merged repository around
fixes#29806
Note that clasp (included in clingo) is already packaged separately, but
only an earlier version. As it is used by OPAM, but will stop being used
by OPAM later (and I want to grab the name for Clasp the Common Lisp
implementation), I decided to package clingo as a whole (as recommended),
but to leave clasp until OPAM stops needing it.
Includes security fixes for CVE-2017-15398 and CVE-2017-15399.
Also fixes builds for beta and dev branches:
- backport https://webrtc-review.googlesource.com/9384 to fix build for
new webrtc revision
- for dev branch fix gn bootstrap, see
https://chromium-review.googlesource.com/758584
- for 63+ manpage now is not generated during ninja build, it is
processed with sed using packagers tools included in sources
This package is most likely only used by Paperwork and thus it makes
sense to put it next to the main expression of Paperwork.
No functional changes here, evaluating before this commit and afterwards
leads to the same derivation hash.
Signed-off-by: aszlig <aszlig@nix.build>
Both Paperwork and its backend API are very likely to be updated in par,
but even when not whenever I work on Paperwork I'll check the backend as
well.
Signed-off-by: aszlig <aszlig@nix.build>
While updating Paperwork in 1b1cc34020 I
actually changed the GitHub URL to its new location.
However, the actual homepage of Paperwork is https://openpaper.work/ so
let's use that instead of the GitHub URL.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @volth
Upstream changes:
Paperwork-GUI 1.2.1:
* Add source code of Windows installer (NSIS installer) generator
* Scanner support / Multi-scan: Cancel also successful scan session.
Otherwise some scanner won't allow new scan sessions later.
* Remove gi version warnings when starting (thanks to Matthieu
Coudron)
* Documentation: Add missing stdeb dependencies (thanks to Notkea)
* paperwork-shell: Fix command 'scan'
* paperwork-shell install: add docstring
* Fix dialog 'about'
Paperwork-backend 1.2.1:
* paperwork-shell: improve help string of 'paperwork-shell chkdeps'
* Fix label deletion / renaming
* Windows: Fix FS.safe() when used for PDF import
* Windows: Fix FS.unsafe() (used for PDF export)
Full upstream changelog can be found at:
https://github.com/openpaperwork/paperwork/releases/tag/1.2.1
Successfully tested building and running Paperwork with a few test
scans.
Signed-off-by: aszlig <aszlig@nix.build>
Upstream changes:
* Now works with 'setup.py develop' (thanks to Matthieu Coudron)
* WIA: Some drivers (Lexmark for instance) returns
WIA_ERROR_PAPER_EMPTY when calling transfer->Download() instead of
returning a shorted image (like HP)
* MacOSX + Sane: disable dedicated process workaround (doesn't work)
* WIA: Minor optimisation (Use collections.deque() instead of
list.pop())
* Sane/exit(): Exit gracefully
Full changelog can be found at:
https://github.com/openpaperwork/pyinsane/blob/2.0.10/ChangeLog
Tested by building and running a few scans.
Signed-off-by: aszlig <aszlig@nix.build>
Since the update to Python 3.6.3 in f906d6d18e
some of the Hypothesis tests in natsort suddenly begin to fail with
errors like this one:
res = '\x00\x00', f = <built-in function strxfrm>
> return partial(reduce, lambda res, f: f(res), functions)
E ValueError: embedded null character
The tests didn't fail with Python 3.6.2, but they did fail with Python
3.5 already.
I didn't dig through what the exact problem was, but I'd guess that the
problem could lie in Hypothesis itself. Unfortunately updating to the
latest version of Hypothesis didn't turn out to be that easy as well,
because the newer versions have a circular dependency on pytest and a
few other libraries.
So I opted against updating Hypothesis for now and just mark the tests
as "expected to fail" on purpose so that whenever we someday have a
newer version of Hypothesis, the build for natsort will fail and we can
remove this patch again.
Tested against Python 2.7, 3.4, 3.5 and 3.6 and all of the builds now
succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jluttine, @FRidh
Since glibc 2.26 the string.h file includes <strings.h>, which in case
of cuneiform will include the strings.h found in Kern/hhh/tigerh/h,
because of the search path order.
Fortunately for us the strings.h in cuneiform are completely unused and
no files reference or include it. I even checked various references to
types within strings.h and the only occurences are in cf_strings.h,
which is also included by other files.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @7c6f434c
This issue doesn't necessarily have to do with glibc 2.26 and it could
have been fixed if we'd replace -Werror with -Wall.
The error in question was:
storage/overlay.c:808:13: error: 'dirlen' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
After looking at the code in overlay.c it indeed might use dirlen
unitialized.
Unrelated to the glibc upgrade which brought the problem to the surface,
this also has been fixed upstream at lxc/lxc@180c477a32.
The reason however, that led to the upstream fix was a segfault which
has been reported at lxc/lxc#1802.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @wkennington, @globin, @fpletz
The build fails first of all because it cannot find the function body
for __builtin_memset. In glibc 2.26 this is available via inclusion of
string.h.
Another failure was that UINT64_MAX wasn't available in staging/tools.c,
which is fixed again by inclusion of stdint.h.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @nckx
This is very similar to what we had in bb0b0822ef.
The xlocale.h header is no longer existing in glibc version 2.26, so we
need to avoid including it.
I've tested building against all of the libcxx attributes of LLVM 3.5,
3.7, 3.8, 3.9, 4 and 5.
All of them succeeded except version 3.5, which failed because of an
unrelated issue (build of libc++abi has failed, one of its
dependencies), so I only verified whether the patch applies cleanly.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @vcunat
I don't know where this comes from (I accidentally did that as well
once), but some derivations seem to use `buildPhases` rather than
`phases` in their derivations.
This kills all improper usages as the lack of a `phases` argument
didn't break the build, so this can be safely removed.
Searching the web for the base-16 encoded hash of the one we have in the
Nix expression didn't give any results and I also couldn't find the
older tarball anywhere (even the mirrors I've checked don't have it).
So checking the updated hash I've found that other distros use this, so
I'd bet it's safe to do this.
I've tested building the package but I didn't do any runtime test.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @the-kenny
Since glibc 2.26, struct ucontext no longer exists but is wrapped in a
typedef ucontext_t.
This is basically a backport of the patch to gcc version 4.5 which was
introduced by @vcunat in f04b64c1e9.
Building against x86_64-linux and i686-linux now succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @abbradar
Netatalk 3.1.11 is the latest stable release. There is also a nasty bug
with netatalk < 3.1.11 (https://sourceforge.net/p/netatalk/bugs/636/)
that prevents using netatalk shares for time machine backups.
The header file xlocale.h has been removed in glibc 2.26.
Quoting the release notes[1]:
* The nonstandard header <xlocale.h> has been removed. Most programs
should use <locale.h> instead. If you have a specific need for the
definition of locale_t with no other declarations, please contact
libc-alpha@sourceware.org and explain.
I've backported HaxeFoundation/neko@e286c8f330
against version 2.1.0 and the build now succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes the build failure after the upgrade to glibc 2.26 in
9bb67d5c1e.
From the cfree(3) manpage:
This function should never be used. Use free(3) instead. Starting with
version 2.26, it has been removed from glibc.
From the glibc 2.26 release notes[1]:
* The obsolete function cfree has been removed. Applications should use
free instead.
[1]: https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @7c6f434c, @tohl
Update to the latest version (note versioning change).
From the changelog for 'mediainfo' (libzen changelog is unavailable):
===
Version 17.10, 2017-11-02
--------------
+ We need your support! Visit https://mediaarea.net/SupportUs
+ Version scheme is now YY.MM (year dot month, 2 digits each)
+ New MediaInfo XML output, with XSD, more suitable for automatic
parsing. Use Option("Inform", "OLDXML") for keeping previous behavior
+ New "Info_OutputFormats" option for listing supported output formats
+ Universal Ad ID: refactored display, better display of value and
registry, XML name slightly modified
+ MOV: support of HDR metadata (MasteringDisplayColorVolume, MaxCLL,
MaxFALL)
+ BWF: display of UMID and loudness info
+ AAC: show program_config_element in trace
+ MPEG Audio: frame rate info
+ PCM in WAV and Matroska: Support of ValidBitsPerSample
+ I197, EBUCore: 1.8 output uses now final version of XSD and final XSD
location
+ Matroska: tweaking frame rate empirical detection for some corner
cases
x I1070, LAME 3.100 info tag was incorrectly parsed
x B1068, MPEG Audio: Incoherent duration between General and Audio
parts, Audio part duration fixed
x Matroska: showing "A_MS/ACM" Matroska CodecID
x MXF: Fix crash with some buggy files
x MXF: was not well supporting MXF referencing only 1 file
x PCM in WAV: 8-bit content is unsigned and without endianess
x PCM in WAV and Matroska: More coherency between Wave info and
ExtensibleWave Info (bitdepth, sign)
x WAV: GUID display was with first 8 bytes in wrong order
x Several crash fixes
I've bisected the introduction of the build failure to be the glibc 2.26
upgrade with commit 9bb67d5c1e.
At first I was somewhat stumped why an glibc update could cause
undeclared identifiers, but after looking at the changes of glibc and
the source code of The Ur-Quan Masters the problem quickly turned out to
be this very change:
https://sourceware.org/git/?p=glibc.git;a=commit;h=7b037c095e31c2396d0a9b0e6356bc566ee4812f
So string.h now in turn includes strings.h, which in theory wouldn't be
a problem.
However, both strings.h and the strings.h in the uqm source code use
constant _STRINGS_H, which causes the glibc strings.h to be included but
the one from uqm basically includes an empty file.
Signed-off-by: aszlig <aszlig@nix.build>
The only functional change here is that I've dropped unzip, because that
dependency doesn't seem to be necessary at all. Despite the broken build
state I've tried building and running The Ur-Quan Masters with an older
nixpkgs revision and it works fine.
Other than that there are no references in the source code for unzip
except in the binary installer and some of the INSTALL files.
The reason why I'm removing the "with pkgs.lib;" is that it makes it
easier to quickly check for errors with "nix-instantiate --parse".
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jcumming
