Re: non-persistant storage?

2019-12-12 Thread L A Walsh

On 2019/12/12 22:26, Brian Inglis wrote:



I've been using /run, with /var/run as a symlink to that, created in a permanent
postinstall script /etc/postinstall/zp_mk_run_var_links.dash (with some others),
for some time. It's currently using ~28KB.

Is it feasible to mount /run on say /dev/shm/run and create and use files there?
  
I don't see why you would need to change what you are doing unless your 
application

whines about the symlink.  I.e. VirtualBox didn't like me using a symlink
in /opt to /home/opt on linux, so I mounted it w/a line in fstab.

/home/opt /opt  none  rbind 0 0


Or would it be more feasible to use say Cyg/WinFUSE to provide that function?
  
I don't know the state of cyg's support in those areas, so if you were 
forced

to change, you'd get to do your own testing to see what worked, etc.

I went one further under 'run' and 'tmp' -- I left those as public 
directories

and put my UID or login name as my own directory under the common name.

yeah 28k is nothing.  I was using files measured in MBytes though the 
[server]
system has over 100GB mem.  The communication goes through unix-sockets, 
which
also goes through /dev/shm, but its cleanup is technically the 
responsibility
of the OS, so, if lucky -- it cleans it up, if not, no worse off than 
before.


I don't run many OS progs on my Win machine cuz Win tended to flake out 
in running

tasks and wouldn't say anything when it went wrong.

So now, I just have a cronjobs on my linux server that use ssh to login 
to run

jobs on windows...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Jürgen Wagner

And regarding the tmpfs (RAM disk) , you can use /dev/shm.

# date > /dev/shm/key
# cat /dev/shm/key
Fri Dec 13 07:26:03 CET 2019
#

It is not advisable to store larger amounts of data there, but an 
encryption key should be fine.


Cheers,
--j.

On 13.12.2019 00:21, Ulli Horlacher wrote:

On Fri 2019-12-13 (00:03), Jürgen Wagner wrote:


1. You create a RAM disk

How do I do it with cygwin?



2. You encrypt the data with a ephemeral key

This is exactly what I want to share between processes!







smime.p7s
Description: S/MIME Cryptographic Signature


Re: non-persistant storage?

2019-12-12 Thread Brian Inglis
On 2019-12-12 18:06, L A Walsh wrote:
> On 2019/12/12 13:40, Eliot Moss wrote:
>> Ah!  I think what you want is a tmpfs or ramfs.
>> Not sure if cygwin supports that ...
>>   
> 
>    Easiest thing might be to use /dev/shm. I used it during
> development to store intermediate data that was later to be
> transfered via a fifo...
> 
> Basically check for existence of "/dev/shm" (exists on my cygwin).
> if "tmp" didn't already exist, create it w/options similar to
> /tmp (only owner can delete/edit):
> 
> mkdir -m 1777 /tmp/shm/tmp
> 
> 
> **Warning, "writes" to /dev/shm/tmp (or /dev/mem) can fill up
> your system's memory, so its only good for "small files"
> (small being well under your system's free memory amount).

I've been using /run, with /var/run as a symlink to that, created in a permanent
postinstall script /etc/postinstall/zp_mk_run_var_links.dash (with some others),
for some time. It's currently using ~28KB.

Is it feasible to mount /run on say /dev/shm/run and create and use files there?

Or would it be more feasible to use say Cyg/WinFUSE to provide that function?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Bug in "factor" (coreutils: GNU core utilities (8.26-2), 64bit edition)

2019-12-12 Thread L A Walsh

On 2019/12/11 23:36, Bernd Eggen wrote:

Hello,
Some time ago I found that the Cygwin-64 "factor" command did not seem to 
terminate with certain numbers, eg try:
  -> echo '3401347*3861211*12099721' | bc | factor

The developers provided a fix (in GNU coreutils 8.29), however, after some two 
years I still find the faulty factor command in the current Cygwin distribution.
When are you planning to upgrade ?
Cheers, Bernd
PS I think this only affects 64bit version
  

Wow...  The source for factor should be easy to build .. like grab from
gnu's website...(goog) tells me this link should work:
https://ftp.gnu.org/gnu/coreutils/coreutils-8.31.tar.xz

untar it and run configure in the dir where it was
extracted, then run "make" in the same dir.

You'll find factor in "src/factor".

Or you could also get the cygwin source package (in setup
checkmark the src package) and substitute in the new
coreutils package, and adjust any
needed paths in the cygwin make package, then you'd have
an installable cygwin package rather than just a binary of
factor...

Just thinking out-loud, mostly, if I really needed it
that is...
But dunnow how complicated their packaging is...

-linda


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistant storage?

2019-12-12 Thread L A Walsh

On 2019/12/12 13:40, Eliot Moss wrote:

Ah!  I think what you want is a tmpfs or ramfs.
Not sure if cygwin supports that ...
  


   Easiest thing might be to use /dev/shm. I used it during
development to store intermediate data that was later to be
transfered via a fifo...

Basically check for existence of "/dev/shm" (exists on my cygwin).
if "tmp" didn't already exist, create it w/options similar to
/tmp (only owner can delete/edit):

mkdir -m 1777 /tmp/shm/tmp


**Warning, "writes" to /dev/shm/tmp (or /dev/mem) can fill up
your system's memory, so its only good for "small files"
(small being well under your system's free memory amount).


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Jürgen Wagner

Ok, we're getting closer.

- Run cygserver-config as an administrator.
- Do "net start cygserver"

That will provide shared memory capabilities. Then try this:

# shmtool w myFunnyC8380ufsKey
Shared memory segment exists - opening as client
Done...

# shmtool r
Shared memory segment exists - opening as client
segptr: myFunnyC8380ufsKey

#

On reboot of the host Windows, the shared memory segment will not be 
persisted.


Cheers,
--j.




On 13.12.2019 00:21, Ulli Horlacher wrote:

On Fri 2019-12-13 (00:03), Jürgen Wagner wrote:


1. You create a RAM disk

How do I do it with cygwin?



2. You encrypt the data with a ephemeral key

This is exactly what I want to share between processes!







smime.p7s
Description: S/MIME Cryptographic Signature


Re: non-persistent storage?

2019-12-12 Thread Ulli Horlacher
On Fri 2019-12-13 (00:03), Jürgen Wagner wrote:

> 1. You create a RAM disk

How do I do it with cygwin?


> 2. You encrypt the data with a ephemeral key

This is exactly what I want to share between processes!


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<3bcb25a9-3d7a-2b88-f2ca-83d46f2b0...@wagner.is>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Ulli Horlacher
On Thu 2019-12-12 (17:45), Erik Soderquist wrote:

> This is very hacky, but I believe you can get the effect you want by
> having an admin process auto-start at host startup, identify itself,
> and then set parts of its own /proc/ process ID tree as world
> read/write.

It is not possible to write any data to /proc using standard IO read/write
like on a tmpfs file system.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Jürgen Wagner

I can see two options:
1. You create a RAM disk and the contents will obviously be gone when 
the system reboots or crashes.
2. You encrypt the data with a ephemeral key that will be lost on reboot 
(e.g., kept in shared memory). When the system comes up and finds itself 
unable to read the data, it will erase it.


That doesn't really have much to do with Cygwin or Windows - you can do 
that on any system.


On 12.12.2019 23:07, Ulli Horlacher wrote:

On Thu 2019-12-12 (21:59), Buchbinder, Barry (NIH/NIAID) [E] via cygwin wrote:


If the temp file was created by mktemp and the name saved in an
environmental variable, each bash shell could have its own file with not
risk that an instance of bash would erase another instance's file.

I need the opposite: all processes must read and write the same data!
And the data must be gone when system shuts down or even if there is a
power failure.






smime.p7s
Description: S/MIME Cryptographic Signature


Re: non-persistent storage?

2019-12-12 Thread Erik Soderquist
On Thu, Dec 12, 2019 at 5:45 PM Erik Soderquist wrote:
> This is very hacky, but I believe you can get the effect you want by
> having an admin process auto-start at host startup, identify itself,
> and then set parts of its own /proc/ process ID tree as world
> read/write.  I think this will give you the "destroyed even at power
> failure" impermanence you are l,booking for.  I know it is not in the
> normal layouts (like /var/run/ would be), but we are working around
> limitation s imposed by Windows.

To "move"to /var/run/, the process could also build symlinks to the
location(s) in /proc/ so the other programs/users have a stable
/var/run/ location and only the auto-started process needs to know or
care about the locations in /proc/

-- Erik

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Erik Soderquist
On Thu, Dec 12, 2019 at 5:08 PM Ulli Horlacher wrote:
>
> On Thu 2019-12-12 (21:59), Buchbinder, Barry (NIH/NIAID) [E] via cygwin wrote:
>
> > If the temp file was created by mktemp and the name saved in an
> > environmental variable, each bash shell could have its own file with not
> > risk that an instance of bash would erase another instance's file.
>
> I need the opposite: all processes must read and write the same data!
> And the data must be gone when system shuts down or even if there is a
> power failure.

This is very hacky, but I believe you can get the effect you want by
having an admin process auto-start at host startup, identify itself,
and then set parts of its own /proc/ process ID tree as world
read/write.  I think this will give you the "destroyed even at power
failure" impermanence you are l,booking for.  I know it is not in the
normal layouts (like /var/run/ would be), but we are working around
limitation s imposed by Windows.

-- Erik

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistent storage?

2019-12-12 Thread Ulli Horlacher
On Thu 2019-12-12 (21:59), Buchbinder, Barry (NIH/NIAID) [E] via cygwin wrote:

> If the temp file was created by mktemp and the name saved in an
> environmental variable, each bash shell could have its own file with not
> risk that an instance of bash would erase another instance's file.

I need the opposite: all processes must read and write the same data!
And the data must be gone when system shuts down or even if there is a
power failure.

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



RE: non-persistent storage?

2019-12-12 Thread Buchbinder, Barry (NIH/NIAID) [E] via cygwin
Eliot Moss sent the following at Thursday, December 12, 2019 2:19 pm
>On 12/12/2019 7:00 AM, Ulli Horlacher wrote:
>
>> I need to store some data (a few kB) non-persistent.
>> On a real UNIX I would use /var/run, because after a shutdown all its
>> content is lost.
>> But on cygwin /var/run is stored on disk.
>>
>> I cannot use an environment variable, because different processes need
>> to read/write the data.
>>
>> /proc is non-persistent (in respect to a reboot), but It is not a
>> generic storage place.
>>
>> What can I use with cygwin instead?
>>
>> Installing third party software is not an option, it must work with a
>> standard Windows (and cygwin).
>
>I would think of temp directories, such as /tmp. They can be cleaned out
>at will on restart, no?

Bash runs the file ~/.bash_logout when it exits.  One could use that to
clear a temp file out of /tmp.

If the temp file was created by mktemp and the name saved in an
environmental variable, each bash shell could have its own file with not
risk that an instance of bash would erase another instance's file.

That assumes that this is consistent with your need for different
processes to read/write data.

Good luck,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistant storage?

2019-12-12 Thread Eliot Moss

Ah!  I think what you want is a tmpfs or ramfs.
Not sure if cygwin supports that ...

Cheers - Eliot

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistant storage?

2019-12-12 Thread Ulli Horlacher
On Thu 2019-12-12 (14:18), Eliot Moss wrote:

> > I need to store some data (a few kB) non-persistant.
> > On a real UNIX I would use /var/run, because after a shutdown all its
> > content is lost.
> > But on cygwin /var/run is stored on disk.
> > 
> I would think of temp directories, such as /tmp.  They can be cleaned out at 
> will
> on restart, no?

The data MUST be lost on shutdown (or power failure), not on reboot!
Therefore it must be hold in memory, not on disk.

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<8905c7b6-b2e6-52bf-bcdd-66890db91...@cs.umass.edu>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: non-persistant storage?

2019-12-12 Thread Eliot Moss

On 12/12/2019 7:00 AM, Ulli Horlacher wrote:

I need to store some data (a few kB) non-persistant.
On a real UNIX I would use /var/run, because after a shutdown all its
content is lost.
But on cygwin /var/run is stored on disk.

I cannot use an environment variable, because different processes need to
read/write the data.

/proc is non-persistant (in respect to a reboot), but It is not a generic
storage place.

What can I use with cygwin instead?

Installing third party software is not an option, it must work with a
standard Windows (and cygwin).


I would think of temp directories, such as /tmp.  They can be cleaned out at 
will
on restart, no?

Regards - Eliot

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: couldn't start opengrads

2019-12-12 Thread cygwinautoreply
>Hello,

>I want to start OpenGrads after I installed Cygwin, but it came with an
>error message, I have uninstalled Cygwin and reinstall Grads again but the
>same error occurred, this is the error message that I encountered

>Microsoft Windows [Version 6.3.9600]
>(c) 2013 Microsoft Corporation. All rights reserved.

>C:\Users\CandrasaSD>grads
>  0 [main] grads 9284 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>poin
>ter.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>MAX_SIZE = 2048, needed size = 2193
>Internal error: environment variable PATH is too long; change MAX_SIZE to
>at lea
>st 2193 and recompile or else shortten your PATH by 145 characters

>Would you suggest the solution? thx



>[image: CandrasaSD]  [image:
>CandrasaSD] 


https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



couldn't start opengrads

2019-12-12 Thread Candrasa Surya Dharma
Hello,

I want to start OpenGrads after I installed Cygwin, but it came with an
error message, I have uninstalled Cygwin and reinstall Grads again but the
same error occurred, this is the error message that I encountered

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\CandrasaSD>grads
  0 [main] grads 9284 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
poin
ter.  Please report this problem to
the public mailing list cygwin@cygwin.com
MAX_SIZE = 2048, needed size = 2193
Internal error: environment variable PATH is too long; change MAX_SIZE to
at lea
st 2193 and recompile or else shortten your PATH by 145 characters

Would you suggest the solution? thx

-- 


[image: CandrasaSD]  [image:
CandrasaSD] 

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Mariadb Server 10.3.14 crashes

2019-12-12 Thread cygwin
Hi the community,

I use mysqld-server 10.3.14 as a server for development and an alive
backup server (in a MASTER-SLAVE configuration with a MASTER on Linux)
When operating some changes on my MASTER, I have set the SLAVE (under
Cygwin) to be a master for my application. But I realize the daemon
crashes regularly with a really short message :191212 16:17:49 [ERROR]
mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this
binary
or one of the libraries it was linked against is corrupt, improperly
built,
or misconfigured. This error can also be caused by malfunctioning
hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.3.14-MariaDB-log
key_buffer_size=32768
read_buffer_size=262144
max_used_connections=1
max_threads=153
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads
= 355869 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.


So I tried to diagnose why it happened. I cleaned up the installation,
reset all the database, checked for mysql-upgrade, etc. etc. imported a
backup, and finally… found a query that crash this daemon.

I found that the first query below crashes the server, but not the
second (seen here with the query-plan) :

SELECT DISTINCT ttrss_feeds.title, date_entered,
date_format(date_entered, '%Y-%u') AS yyiw, guid, ttrss_entries.id,
ttrss_entries.title, updated, score, marked, published, last_marked,
last_published, last_read FROM ttrss_entries LEFT JOIN
ttrss_user_entries ON (ref_id = ttrss_entries.id) LEFT JOIN
ttrss_feeds ON (feed_id = ttrss_feeds.id) WHERE date_entered >=
DATE_SUB('2019-12-11 17:09:49', INTERVAL 1 hour);

+--+-+++---+--+-+--+--++
| id   | select_type | table  | type   | possible_keys |
key  | key_len | ref  | rows |
Extra  |

+--+-+++---+--+-+--+--++
|    1 | SIMPLE  | ttrss_entries  | range  | date_entered  |
date_entered | 5   | NULL |    1 |
Using index condition; Using temporary |
|    1 | SIMPLE  | ttrss_user_entries | ref    | ref_id    |
ref_id   | 4   | ttrss.ttrss_entries.id   |    1
|    |
|    1 | SIMPLE  | ttrss_feeds    | eq_ref | PRIMARY   |
PRIMARY  | 4   | ttrss.ttrss_user_entries.feed_id |    1 |
Using where    |

+--+-+++---+--+-+--+--++

SELECT DISTINCT ttrss_feeds.title, date_entered,
date_format(date_entered, '%Y-%u') AS yyiw, guid, ttrss_entries.id,
ttrss_entries.title, updated, score, marked, published, last_marked,
last_published, last_read FROM ttrss_entries LEFT JOIN
ttrss_user_entries ON (ref_id = ttrss_entries.id) LEFT JOIN
ttrss_feeds ON (feed_id = ttrss_feeds.id);

+--+-+++---+-+-+--+--+-+
| id   | select_type | table  | type   | possible_keys |
key | key_len | ref  | rows |
Extra   |

+--+-+++---+-+-+--+--+-+
|    1 | SIMPLE  | ttrss_entries  | ALL    | NULL  |
NULL    | NULL    | NULL | 5517 | Using
temporary |
|    1 | SIMPLE  | ttrss_user_entries | ref    | ref_id    |
ref_id  | 4   | ttrss.ttrss_entries.id   |    1
| |
|    1 | SIMPLE  | ttrss_feeds    | eq_ref | PRIMARY   |
PRIMARY | 4   | ttrss.ttrss_user_entries.feed_id |    1 | Using
where |

+--+-+++---+-+-+--+--+-+

I tried some things, like use the debuginfo package with gdb and saw
some SIGSEV, but I'm a dummy with that and I remain in the dark.
I tried to increase buffers, query buffers, join 

[ANNOUNCEMENT] Updated: proj-6.2.1-1

2019-12-12 Thread Marco Atzeri

New versions 6.2.1-1 of

  proj
  libproj-devel
  libproj15 (API bump)

for cygwin are available in the Cygwin distribution:

CHANGES
Last upstream release.

NOTES
Additional Datumgrid for Europe, North America
and Oceania are available on
https://download.osgeo.org/proj/
while proj-datumgrid-1.8.tar.gz is included as basic
data in the packages.

DESCRIPTION
PROJ - Cartographic Projections Library

HOMEPAGE
https://proj.org/
https://github.com/OSGeo/PROJ/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Updated: proj-6.2.1-1

2019-12-12 Thread Marco Atzeri

New versions 6.2.1-1 of

  proj
  libproj-devel
  libproj15 (API bump)

for cygwin are available in the Cygwin distribution:

CHANGES
Last upstream release.

NOTES
Additional Datumgrid for Europe, North America
and Oceania are available on
https://download.osgeo.org/proj/
while proj-datumgrid-1.8.tar.gz is included as basic
data in the packages.

DESCRIPTION
PROJ - Cartographic Projections Library

HOMEPAGE
https://proj.org/
https://github.com/OSGeo/PROJ/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .


Updated: mutt-1.13.0-1

2019-12-12 Thread Marco Atzeri

New version 1.3.0-1 of

  mutt

is available in the Cygwin distribution:

CHANGES
Last upstream bugfix update release.

Full details on:
https://gitlab.com/muttmua/mutt/raw/master/UPDATING

DESCRIPTION
The Mutt E-Mail Client
"All mail clients suck. This one just sucks less."

Mutt is a small but very powerful text-based mail client
for Unix operating systems.

HOMEPAGE
http://www.mutt.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .


[ANNOUNCEMENT] Updated: mutt-1.13.0-1

2019-12-12 Thread Marco Atzeri

New version 1.3.0-1 of

  mutt

is available in the Cygwin distribution:

CHANGES
Last upstream bugfix update release.

Full details on:
https://gitlab.com/muttmua/mutt/raw/master/UPDATING

DESCRIPTION
The Mutt E-Mail Client
"All mail clients suck. This one just sucks less."

Mutt is a small but very powerful text-based mail client
for Unix operating systems.

HOMEPAGE
http://www.mutt.org/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



non-persistant storage?

2019-12-12 Thread Ulli Horlacher
I need to store some data (a few kB) non-persistant.
On a real UNIX I would use /var/run, because after a shutdown all its
content is lost.
But on cygwin /var/run is stored on disk.

I cannot use an environment variable, because different processes need to
read/write the data.

/proc is non-persistant (in respect to a reboot), but It is not a generic
storage place.

What can I use with cygwin instead?

Installing third party software is not an option, it must work with a
standard Windows (and cygwin).

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20191212120041.ga7...@tik.uni-stuttgart.de>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



ilogbl(0.0L) value is wrong

2019-12-12 Thread Bruno Haible
POSIX [1] specifies that the return value of the functions ilogbf(), ilogb(),
ilogbl() for a zero argument should all be the same, namely FP_ILOGB0.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/ilogb.html

In Cygwin 2.9, the value of ilogbl(0.0L) is not right.

How to reproduce:
== foo.c ==
#include 
#include 
#include 

int main ()
{
  int x = ilogbf (0.0f);
  int y = ilogb (0.0);
  int z = ilogbl (0.0L);
  printf ("%d\n%d\n%d\n%d\n", x, y, z, FP_ILOGB0);
}
===
$ gcc -Wall foo.c
$ ./a.exe

Expected output: four times the same number.
Actual output:

-2147483647
-2147483647
-2147483648
-2147483647


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple