Versions 1.4-2 of
libftdi1
libftdi1-devel
libftdi1-debuginfo
libftdi1-doc
python27-ftdi1
python36-ftdi1
for x86 and x86_64
are available in the Cygwin distribution. Version 1.4-2 is identical to
1.4-1.
CHANGES
Latest upstream release
DESCRIPTION
libFTDI is an open source librar
On 2020-04-07 17:25, Jon Turney wrote:
On 07/04/2020 16:03, Åke Rehnman via Cygwin wrote:
Hello all,
I tripped on the finish line...
ERROR: install packages from source package 'libftdi1' have
non-unique current versions 1.3-1 (python3-ftdi1), 1.4-1 (2 others)
ERROR: error while
Hello all,
I tripped on the finish line...
ERROR: install packages from source package 'libftdi1' have non-unique current
versions 1.3-1 (python3-ftdi1), 1.4-1 (2 others)
ERROR: error while validating merged x86_64 packages for Ake Rehnman
I get this report:
WARNING: copying 'libftdi1-1.4-1.
Hello all,
After running cygport package I get for one of my packages the same
dependency twice:
>>> libftdi1 requires: bash cygwin libconfuse1 libgcc1 libstdc++6
libusb1.0 libconfuse1
Any ideas why? Is it a problem?
BR
/Ake
--
Problem reports: https://cygwin.com/problems.html
FAQ:
Hello all,
Sorry if this question is covered somewhere else... I did try googling...
What are the naming conventions for python packages ?
python2-libftdi1-1.4-1
or
python27-libftdi1-1.4-1
or just
python-libftdi1-1.4-1
Same for python 3:
python3-libftdi1-1.4-1
or
python3.6-libftdi1-1.4
Hello all,
I was going to update the libftdi1 package which in addition to the
regular ftdi library contains python bindings. Unfortunately the cmake
CMakeLists only builds python 3 bindings for this library unless
explicitly passed some magic variables on the command line. However both
pytho
On 2020-04-04 21:11, Åke Rehnman wrote:
On 2020-04-04 11:00, Ben wrote:
Hey all,
I've never used Cygwin much in the past for compiling let alone
cross-compiling to another arch.
I've been playing with ARM GNU GCC and some examples from nordic
semiconductor for some of their d
On 2020-04-04 11:00, Ben wrote:
Hey all,
I've never used Cygwin much in the past for compiling let alone
cross-compiling to another arch.
I've been playing with ARM GNU GCC and some examples from nordic
semiconductor for some of their demo boards (The Thingy)
The make file that comes wit
On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote:
On 2020-04-04 02:00, Ben wrote:
Is there something else I'm missing?
That by cross-compiling for your targets on Cygwin instead of a real
POSIX OS, you will something like double your compile times, if not more.
Why would you involve Cygw
On 2020-04-04 05:24, Eliot Moss wrote:
On 4/3/2020 9:55 PM, Phoenix Soul via Cygwin wrote:
> The setup-x86_64.exe requires admin priveleges. Is it possible to
put it
> into a ZIP file for use?
Dear Phoenix -- While I'm not 100% sure what you're really asking, I
think the
answer is "no". Cygw
On 2020-03-17 13:16, Corinna Vinschen wrote:
Hi Åke,
On Mar 16 10:35, Corinna Vinschen wrote:
On Mar 14 11:36, Åke Rehnman via Cygwin wrote:
On 2020-03-14 11:23, Åke Rehnman wrote:
BTW there is a gremlin in the "else if (ev)" line
A gremlin? Would you mind to explain? Bt
On 2020-03-14 11:23, Åke Rehnman wrote:
On 2020-03-13 11:12, Corinna Vinschen wrote:
On Mar 12 18:04, Åke Rehnman via Cygwin wrote:
On 2020-03-12 16:08, Corinna Vinschen wrote:
On Mar 12 15:44, Corinna Vinschen wrote:
On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
I think the problem is
On 2020-03-13 11:12, Corinna Vinschen wrote:
On Mar 12 18:04, Åke Rehnman via Cygwin wrote:
On 2020-03-12 16:08, Corinna Vinschen wrote:
On Mar 12 15:44, Corinna Vinschen wrote:
On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
I think the problem is if the number of bytes requested are more
On 2020-03-12 16:08, Corinna Vinschen wrote:
On Mar 12 15:44, Corinna Vinschen wrote:
On Mar 12 15:20, Åke Rehnman via Cygwin wrote:
I think the problem is if the number of bytes requested are more than what
To clarify: number of bytes == VMIN?
no number of bytes requested from ReadFile
On 2020-03-12 15:13, Corinna Vinschen wrote:
On Mar 12 14:32, Åke Rehnman via Cygwin wrote:
On 2020-03-12 12:40, Corinna Vinschen wrote:
For a start, can you please strace the problem with a simple
testcase,like this:
$ strace -o serio.trace
and send the source of your testcase as well
On 2020-03-12 12:40, Corinna Vinschen wrote:
I inspected the serial I/O read function and I only see a subtil
difference in terms of VMIN/VTIME which doesn't seem to be the culprit
at first glance. In O_NONBLOCK mode, the underlying Windows function
ReadFile is called unconditionally. My cur
On 2020-03-12 12:40, Corinna Vinschen wrote:
For a start, can you please strace the problem with a simple
testcase,like this:
$ strace -o serio.trace
and send the source of your testcase as well as the serio.trace file
here? It may show at which point the error code is generated.
Shou
On 2020-03-12 09:05, Thomas Dickey wrote:
If not "correct", it's certainly inconsistent with all other systems.
I noticed it recently:
https://invisible-island.net/ncurses/tack/CHANGES.html#t20200220
https://github.com/cygwinports/tack/issues/1
It's either recently-broken, or just coincidence
On 2020-03-12 02:08, Norton Allen wrote:
Correct me if I am wrong, but O_NDELAY is not the same as O_NONBLOCK
At least for cygwin those two are exactly the same... I think...
#define _FNONBLOCK 0x4000 /* non blocking I/O (POSIX style) */
#define _FNDELAY _FNONBLOCK /* non blo
On 2020-03-11 22:55, Brian Inglis wrote:
VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO
delivery; see:
https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf
https://www.cmrr.umn.edu/~strupp/serial.html
https://en.wikibooks.org/wiki/Serial_Program
Hello all,
opening a file (serial port) with O_NONBLOCK and subsequently setting
termios VMIN and VTIME > 0 makes read() never ever return any data
(returns EAGAIN indefinitely).
Don't ask my why one would want to do something like this but apparently
the "screen" program think this is a goo
On 2020-02-28 20:23, Corinna Vinschen wrote:
- Is it a safe bet that ClearCommError returns valid values in
st.cbInQue even if one of the error conditions occur? Maybe the
right thing to do is to return 0 in certain error cases...?
The win32 api documentation does not mention anythin
Hi,
I recently ran in to some troubles with the TIOCINQ ioctl. I am
wondering if the cygwin implementation is correct... It seems if there
were any existing framing overrun errors etc etc before calling the
TIOCINQ ioctl it is returning an error (EINVAL). Reading through linux
implmentation
The following packages have been uploaded to the Cygwin distribution:
* libconfuse1-3.0-1
* libconfuse-devel-3.0-1
libConfuse is a configuration file parser library, licensed under the
terms of the ISC license, and written in C.
--
Åke
--
Problem reports: http://cygwin.com/problems.htm
The following packages have been uploaded to the Cygwin distribution:
* libftdi1-1.3-1
* python3-ftdi1-1.3-1
* libftdi1-devel-1.3-1
libFTDI is an open source library to talk to FTDI chips: FT232BM,
FT245BM, FT2232C, FT2232D, FT245R, FT232H and FT230X including the
popular bitbang mode. The lib
25 matches
Mail list logo
