Log message:
py-cffi: updated to 1.13.0

v1.13
* ffi.from_buffer("type *", ..) is now supported, in addition to
  "type[]".  You can then write p.field to access the items, instead
  of only p[0].field.  Be careful that no bounds checking is performed, so
  p[n] might access data out of bounds.
* fix for structs containing unnamed bitfields like int : 1;.
* when calling cdata of "function pointer" type, give a RuntimeError \ 
instead
  of a crash if the pointer happens to be NULL
* support some more binary operations between constants in enum definitions
* silence a warning incorrectly emitted if you use a quote in a preprocessor
  line
* detect a corner case that would throw the C code into an infinite
  recursion, with ffi.cdef("""struct X { void(*fnptr)(struct X); \ 
};""")

Log message:
py-cffi: Remove no longer needed NetBSD/evbarm aarch64 kludge

__thread works now (8.99.37 but probably also older).

Log message:
py-cffi: updated to 1.12.3

v1.12.3
* Fix for nested struct types that end in a var-sized array.
* Add support for using U and L characters at the end of integer
  constants in ffi.cdef().
* More 3.8 fixes.

Log message:
py-cffi: updated to 1.12.2

v1.12.2
* Added temporary workaround to compile on CPython 3.8.0a2.

Log message:
py-cffi: updated to 1.12.1

v1.12.1
CPython 3 on Windows: we again no longer compile with Py_LIMITED_API by default \ 
because such modules still cannot be used with virtualenv. The problem is that \ 
it doesn’t work in CPython <= 3.4, and for technical reason we can’t \ 
enable this flag automatically based on the version of Python.

Like before, Issue 350 mentions a workaround if you still want the \ 
Py_LIMITED_API flag and either you are not concerned about virtualenv or you are \ 
sure your module will not be used on CPython <= 3.4: pass \ 
define_macros=[("Py_LIMITED_API", None)] to the \ 
ffibuilder.set_source() call.

v1.12
Direct support for pkg-config.
ffi.from_buffer() takes a new optional first argument that gives the array type \ 
of the result. It also takes an optional keyword argument require_writable to \ 
refuse read-only Python buffers.
ffi.new(), ffi.gc() or ffi.from_buffer() cdata objects can now be released at \ 
known times, either by using the with keyword or by calling the new \ 
ffi.release().
Windows, CPython 3.x: cffi modules are linked with python3.dll again. This makes \ 
them independant on the exact CPython version, like they are on other platforms. \ 
It requires virtualenv 16.0.0.
Accept an expression like ffi.new("int[4]", p) if p is itself another \ 
cdata int[4].
CPython 2.x: ffi.dlopen() failed with non-ascii file names on Posix
CPython: if a thread is started from C and then runs Python code (with callbacks \ 
or with the embedding solution), then previous versions of cffi would contain \ 
possible crashes and/or memory leaks. Hopefully, this has been fixed.
Support for ffi.cdef(..., pack=N) where N is a power of two. Means to emulate \ 
#pragma pack(N) on MSVC. Also, the default on Windows is now pack=8, like on \ 
MSVC. This might make a difference in corner cases, although I can’t think of \ 
one in the context of CFFI. The old way ffi.cdef(..., packed=True) remains and \ 
is equivalent to pack=1 (saying e.g. that fields like int should be aligned to 1 \ 
byte instead of 4).

Log message:
py-cffi: Add a kludge to disable __thread on NetBSD aarch64

__thread ATM is problematic on NetBSD aarch64 and py-cffi users (e.g.
py-requests) ends up crashing due SIGILL at run time.

PKGREVISION++

Log message:
py-cffi: updated to 1.11.5

v1.11.5

* Issue 357_: fix ffi.emit_python_code() which generated a buggy
  Python file if you are using a struct with an anonymous union
  field or vice-versa.

* Windows: ffi.dlopen() should now handle unicode filenames.

* ABI mode: implemented ffi.dlclose() for the in-line case (it used
  to be present only in the out-of-line case).

* Fixed a corner case for setup.py install --record=xx --root=yy
  with an out-of-line ABI module.  Also fixed Issue 345_.

* More hacks on Windows for running CFFI's own setup.py.

* Issue 358_: in embedding, to protect against (the rare case of)
  Python initialization from several threads in parallel, we have to use
  a spin-lock.  On CPython 3 it is worse because it might spin-lock for
  a long time (execution of Py_InitializeEx()).  Sadly, recent
  changes to CPython make that solution needed on CPython 2 too.

* CPython 3 on Windows: we no longer compile with Py_LIMITED_API
  by default because such modules cannot be used with virtualenv.
  Issue 350_ mentions a workaround if you still want that and are not
  concerned about virtualenv: pass a define_macros=[("Py_LIMITED_API",
  None)] to the ffibuilder.set_source() call.

Log message:
py-cffi: updated to 1.11.4

v1.11.4:
* Windows: reverted linking with python3.dll, because virtualenv does not make \ 
this DLL available to virtual environments for now. On Windows only, the C \ 
extension modules created by cffi follow for now the standard naming scheme \ 
foo.cp36-win32.pyd, to make it clear that they are regular CPython modules \ 
depending on python36.dll.

Log message:
py-cffi: updated to 1.11.3

v1.11.3
Fix on CPython 3.x: reading the attributes __loader__ or __spec__ from the \ 
cffi-generated lib modules gave a buggy SystemError. (These attributes are \ 
always None, and provided only to help compatibility with tools that expect them \ 
in all modules.)
More Windows fixes: workaround for MSVC not supporting large literal strings in \ 
C code (from ffi.embedding_init_code(large_string)); and an issue with \ 
Py_LIMITED_API linking with python35.dll/python36.dll instead of python3.dll.
Small documentation improvements.

Log message:
py-cffi: update to 1.11.2

v1.11.2
Fix Windows issue with managing the thread-state on CPython 3.0 to 3.5