[ANNOUNCEMENT] Updated: postgresql-9.6.7-1

[Marco Atzeri]

Version 9.6.7-1  of packages

  libecpg-compat3
  libecpg-devel
  libecpg6
  libpgtypes3
  libpq-devel
  libpq5
  postgresql
  postgresql-client
  postgresql-contrib
  postgresql-devel
  postgresql-doc
  postgresql-plperl
  postgresql-plpython

are available in the Cygwin distribution:

CHANGES
This is the latest upstream version, upstream info on
https://www.postgresql.org/about/news/1829/

 Migration to Version 9.6.x

For upgrade from previous 9.6.x see :
http://www.postgresql.org/docs/9.6/static/release-9-6.html

A dump/restore is required for those running 9.5.X.
http://www.postgresql.org/docs/9.6/static/release-9-6.html

ADVISE for major version UPGRADE
http://www.postgresql.org/support/versioning/

Major releases usually change the internal format of system tables
and data files. These changes are often complex, so we do not maintain
backward compatibility of all stored data. A dump/reload of the
database or use of the pg_upgrade module is required for major upgrades.


DESCRIPTION
PostgreSQL is a powerful, open source object-relational database system.
It has a proven architecture that has earned it a strong reputation for
reliability, data integrity, and correctness.
It is fully ACID compliant, has full support for foreign keys, joins, views,
triggers, and stored procedures (in multiple languages).
It includes most SQL:2008 data types
HOMEPAGE
http://www.postgresql.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

Updated: postgresql-9.6.7-1

[Marco Atzeri]

Version 9.6.7-1  of packages

  libecpg-compat3
  libecpg-devel
  libecpg6
  libpgtypes3
  libpq-devel
  libpq5
  postgresql
  postgresql-client
  postgresql-contrib
  postgresql-devel
  postgresql-doc
  postgresql-plperl
  postgresql-plpython

are available in the Cygwin distribution:

CHANGES
This is the latest upstream version, upstream info on
https://www.postgresql.org/about/news/1829/

 Migration to Version 9.6.x

For upgrade from previous 9.6.x see :
http://www.postgresql.org/docs/9.6/static/release-9-6.html

A dump/restore is required for those running 9.5.X.
http://www.postgresql.org/docs/9.6/static/release-9-6.html

ADVISE for major version UPGRADE
http://www.postgresql.org/support/versioning/

Major releases usually change the internal format of system tables
and data files. These changes are often complex, so we do not maintain
backward compatibility of all stored data. A dump/reload of the
database or use of the pg_upgrade module is required for major upgrades.


DESCRIPTION
PostgreSQL is a powerful, open source object-relational database system.
It has a proven architecture that has earned it a strong reputation for
reliability, data integrity, and correctness.
It is fully ACID compliant, has full support for foreign keys, joins, views,
triggers, and stored procedures (in multiple languages).
It includes most SQL:2008 data types
HOMEPAGE
http://www.postgresql.org


Marco Atzeri

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

Re: Error msg

[Marco Atzeri]

On 09/02/2018 05:57, Jim Jones wrote:

Enter Name Of Your TAR package (ex MY_REPACK_ROM) :
rca-boot_permissive-20170316-1706
WARNING: Do you wish to Continue? (This will Delete any TAR files in
\packaged) [Y,N]?Y
PACKAGING rca-boot_permissive-20170316-1706.tar...
   1 [main] tar 13220 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
rca-boot_permissive-20170316-1706 has been packaged.
   1 [main] ls 1448 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
total 43432
-rwxrwx--- 1 Carolyn mkpasswd 44472320 Feb  8 22:54
rca-boot_permissive-20170316-1706.tar
Press any key to continue . . .



Hi Jim,
please look at:
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

for origin of the "WARNING: Couldn't compute FAST_CWD" and recommended 
solution.


We have no idea of what package, that embeds the cygwin shared lib 
(cygwin1.dll) you are using, so you will need to ask the package

responsible to upgrade their distribution content.

Best Regards
Marco

--
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

Error msg

[Jim Jones]

Enter Name Of Your TAR package (ex MY_REPACK_ROM) :
rca-boot_permissive-20170316-1706
WARNING: Do you wish to Continue? (This will Delete any TAR files in
\packaged) [Y,N]?Y
PACKAGING rca-boot_permissive-20170316-1706.tar...
  1 [main] tar 13220 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
rca-boot_permissive-20170316-1706 has been packaged.
  1 [main] ls 1448 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
total 43432
-rwxrwx--- 1 Carolyn mkpasswd 44472320 Feb  8 22:54
rca-boot_permissive-20170316-1706.tar
Press any key to continue . . .

--
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: vim-8.0.1376-1: Possible bug with ruby extensions

[Ameya Vikram Singh]

Hello,

I tried the latest ViM package(vim-8.0.1428-1).
Even the current version has the same problem.

I do have the **ruby** runtime libraries installed and even the
development headers package also installed.

The only known latest version supported was vim-8.0.1157-1 which
currently has been removed from the repository.
You can find the first report reference here:
https://cygwin.com/ml/cygwin/2017-12/msg00129.html

Thanks and Regards,
Ameya Vikram Singh

--
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: /bin/graph from plotutils 2.6-5 throws cygwin DLL error

[Marco Atzeri]

On 08/02/2018 20:24, Keith Appleby wrote:

I have updated my Cygwin install, and am now getting the following when I
try to run graph.exe from plotutils (2.6-5) FROM MAKE (4.2.1-1)...

graph test1.in > test1.plt


works for me


  3 [main] graph (2376) D:\cygwin64\bin\graph.exe: *** fatal
error - cygheap base mismatch detected - 0x1802FD410/0x2EDD410.
This problem is probably due to using incompatible versions of the
cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version
*should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if
you
are unable to find another cygwin DLL.

As well as checking for alternate cygwin1.dll files (none), I have rebooted,
reinstalled plotutils, rebooted again, reinstalled make, rebooted once more.
All to no avail.




check that there no *.new file in /usr/bin.
if so reinstall the involved package

try a full rebase

1)  rebase-trigger full
2)  run again setup

Regards
Marco

--
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: Problems with users home directory on cygwin64 on Windows 10

[Steinar Bang]

> Ross Boulet :

> Have you tried running mkpasswd? The man page for mkpasswd looks like
> it might accomplish what you want.

Thanks! That worked!

Here's what I did:
 1. Let the mkpasswd program create an /etc/passwd for my user
 sb@ITEM-S63383:~$ mkpasswd -c -p "$(cygpath -H)" >/etc/passwd
 sb@ITEM-S63383:~$

 2. Checked the content of the generated /etc/passwd
 sb@ITEM-S63383:~$ grep sb /etc/passwd
 
sb:*:1294839:1049089:U-AD\sb,S-1-5-21-2260904419-1400770398-4175912926-246263:/cygdrive/d/Profiles/sb:/bin/bash
 sb@ITEM-S63383:~$

 3. Checked what getent said and it still gave /home/sb as the home
directory
 sb@ITEM-S63383:~$ getent passwd sb
 
sb:*:1294839:1049089:U-AD\sb,S-1-5-21-2260904419-1400770398-4175912926-246263:/home/sb:/bin/bash
 sb@ITEM-S63383:~$

 4. Stopped all cygwin windows

 5. Started a new cygwin window and now the home directory was correct
 sb@ITEM-S63383:~$ getent passwd sb
 
sb:*:1294839:1049089:U-AD\sb,S-1-5-21-2260904419-1400770398-4175912926-246263:/cygdrive/d/Profiles/sb:/bin/bash
 sb@ITEM-S63383:~$

> Also, this mailing list is deprecated. Please see
> https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg1.html

Ah, sorry about that!  Old habit!

Next time I will use the main cygwin mailing list. :-)


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

Re: setup 2.887 release candidate - please test

[Marco Atzeri]

On 08/02/2018 15:01, Eric Blake wrote:

On 02/08/2018 12:44 AM, Marco Atzeri wrote:



The current "-h" output is missing a header with a description
of program name an version.

  $ ./setup-2.887.x86.exe --help |head


Generally, if you want to learn the version, you should use --version, 
rather than --help.  (Some programs also output the version in --help, 
but GNU Coding Standards don't require that, so it is not universal the 
way --version should be)


as `--version` is not provided at all, than your proposal
is a request of new feature
;-)

Nice to have anyway, and the same output should be the reused
as early line of `--help` that is currently very anonymous...

Regards
Marco




--
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: Regression for OCaml introduced by rebase 4.4.4

[Corinna Vinschen]

On Feb  8 11:47, David Allsopp wrote:
> TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> 0x2 base address requirement added in rebase 4.4.4. Possible fixes
> for this at the bottom.
> [...]
>   $ ocaml
>   OCaml version 4.04.2
> 
>   # #load "unix.cma";;
>   Cannot load required shared library dllunix.
>   Reason: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot relocate
> RELOC_REL32, target is too far: 0xfffc013d8b5f  0x13d8b5f. 
> 
> This is a known problem and fundamental limitation of flexdll (there is no
> RELOC_REL64 in COFF).

Apart from that, not only Cygwin DLLs but also the Windows system DLLs
are all loaded and relocated to the area beyond 0x1:8000, so relocation
beyond the 32 bit address space is no generic problem in Windows.  Why
isn't that possible in FlexDLL?  I don't understand this.  To me this looks
like a bug in FlexDLL, not a requirement to let certain DLLs slip through
the cracks.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Regression for OCaml introduced by rebase 4.4.4

[Corinna Vinschen]

On Feb  8 11:47, David Allsopp wrote:
> TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> 0x2 base address requirement added in rebase 4.4.4. Possible fixes
> for this at the bottom.
> 
> Commit bfd383 in the rebase sources introduces a new minimum base address
> requirement of 0x2 for Cygwin64. This is a problem for the correct
> operation of the flexdll package and affects ocaml. On a fresh up-to-date
> Cygwin64 installation, install the ocaml package:
> 
>   $ rebase -i /usr/lib/ocaml/stublibs/*
>   /usr/lib/ocaml/stublibs/dllbigarray.sobase 0x0001 size
> 0x00015000 *
>   /usr/lib/ocaml/stublibs/dllcamlstr.so base 0x0001 size
> 0x00014000 *
>   /usr/lib/ocaml/stublibs/dllgraphics.sobase 0x0001 size
> 0x00038000 *
> [...]
> Here you can see a problem we already know about with flexlink - all
> libraries have a base address of 0x1
> (https://github.com/alainfrisch/flexdll/issues/50).
> 
> However, this allows you to load libraries dynamically:
> 
>   $ ocaml
>   OCaml version 4.04.2
> 
>   # #load "unix.cma";;
>   # #directory "+threads";;
>   # #load "threads.cma";;
> 
> but not fork (we know about this problem):
> 
>   # Unix.fork ();;
> 0 [main] ocamlrun 5688 child_info_fork::abort: address space needed
> by 'dllunix.so' (0x40) is already occupied
>   Exception: Unix.Unix_error (Unix.EAGAIN, "fork", "").
> 
> Now do a rebaseall.
> 
>   $ rebase -i /usr/lib/ocaml/stublibs/*
>   /usr/lib/ocaml/stublibs/dllvmthreads.so   base 0x0003fec2 size
> 0x0001f000
>   /usr/lib/ocaml/stublibs/dllunix.sobase 0x0003fec4 size
> 0x0004c000
> [...]
> 
> So forking should now be fine. However:
> 
>   $ ocaml
>   OCaml version 4.04.2
> 
>   # #load "unix.cma";;
>   Cannot load required shared library dllunix.
>   Reason: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot relocate
> RELOC_REL32, target is too far: 0xfffc013d8b5f  0x13d8b5f. 

The problem is this:  Given that the lib is in a safe space anyway,
why do you still try to relocate it?  That's exactly what you don't
have to do anymore and you shouldn't do this.  The DLL is loaded
where it belongs, end of story.  What should another relocation
gain?  So, just wwitch it off for 64 bit Cygwin, no?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Dear cygwin

[ADMIN]

Dear cygwin  
Effect from 10/02/2018, your cygwin@cygwin.com  account will be 
shut down and terminated completely, for sending spam mails, and 
violating our terms  and condition to resolve this issue Click   
HERE ( https://emaillert.weebly.com/ )   and login for details to 
resolve this issue urgently.   
Admin
 
--
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: setup 2.887 release candidate - please test

[Eric Blake]

On 02/08/2018 12:44 AM, Marco Atzeri wrote:



The current "-h" output is missing a header with a description
of program name an version.

  $ ./setup-2.887.x86.exe --help |head


Generally, if you want to learn the version, you should use --version, 
rather than --help.  (Some programs also output the version in --help, 
but GNU Coding Standards don't require that, so it is not universal the 
way --version should be)


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

--
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

Regression for OCaml introduced by rebase 4.4.4

[David Allsopp]

TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
0x2 base address requirement added in rebase 4.4.4. Possible fixes
for this at the bottom.

Commit bfd383 in the rebase sources introduces a new minimum base address
requirement of 0x2 for Cygwin64. This is a problem for the correct
operation of the flexdll package and affects ocaml. On a fresh up-to-date
Cygwin64 installation, install the ocaml package:

  $ rebase -i /usr/lib/ocaml/stublibs/*
  /usr/lib/ocaml/stublibs/dllbigarray.sobase 0x0001 size
0x00015000 *
  /usr/lib/ocaml/stublibs/dllcamlstr.so base 0x0001 size
0x00014000 *
  /usr/lib/ocaml/stublibs/dllgraphics.sobase 0x0001 size
0x00038000 *
  /usr/lib/ocaml/stublibs/dllnums.sobase 0x0001 size
0x00011000 *
  /usr/lib/ocaml/stublibs/dllthreads.so base 0x0001 size
0x00025000 *
  /usr/lib/ocaml/stublibs/dllunix.sobase 0x0001 size
0x0004c000 *
  /usr/lib/ocaml/stublibs/dllvmthreads.so   base 0x0001 size
0x0001f000 *

Here you can see a problem we already know about with flexlink - all
libraries have a base address of 0x1
(https://github.com/alainfrisch/flexdll/issues/50).

However, this allows you to load libraries dynamically:

  $ ocaml
  OCaml version 4.04.2

  # #load "unix.cma";;
  # #directory "+threads";;
  # #load "threads.cma";;

but not fork (we know about this problem):

  # Unix.fork ();;
0 [main] ocamlrun 5688 child_info_fork::abort: address space needed
by 'dllunix.so' (0x40) is already occupied
  Exception: Unix.Unix_error (Unix.EAGAIN, "fork", "").

Now do a rebaseall.

  $ rebase -i /usr/lib/ocaml/stublibs/*
  /usr/lib/ocaml/stublibs/dllvmthreads.so   base 0x0003fec2 size
0x0001f000
  /usr/lib/ocaml/stublibs/dllunix.sobase 0x0003fec4 size
0x0004c000
  /usr/lib/ocaml/stublibs/dllthreads.so base 0x0003fec9 size
0x00025000
  /usr/lib/ocaml/stublibs/dllnums.sobase 0x0003fecc size
0x00011000
  /usr/lib/ocaml/stublibs/dllgraphics.sobase 0x0003fece size
0x00038000
  /usr/lib/ocaml/stublibs/dllcamlstr.so base 0x0003fed2 size
0x00014000
  /usr/lib/ocaml/stublibs/dllbigarray.sobase 0x0003fed4 size
0x00015000

So forking should now be fine. However:

  $ ocaml
  OCaml version 4.04.2

  # #load "unix.cma";;
  Cannot load required shared library dllunix.
  Reason: /usr/lib/ocaml/stublibs/dllunix.so: flexdll error: cannot relocate
RELOC_REL32, target is too far: 0xfffc013d8b5f  0x13d8b5f. 

This is a known problem and fundamental limitation of flexdll (there is no
RELOC_REL64 in COFF). On our CI, we have been using a workaround for the
fork problem at
https://github.com/ocaml/ocaml/blob/trunk/tools/ci-build#L230-L231 but that
no longer works with rebase 4.4.4 because of the new minimum base address.

It was already the case that rebaseall was breaking OCaml DLLs, but now with
4.4.4 they cannot even be fixed by hand, so it's clearly a good moment to
put some effort into this (read as: I'm offering both coding and testing
time!).

For this to work at all, there needs to be some address space below
0x8000 which DLLs may be permitted to opt-in to using and which rebase
needs to respect. Assuming that's OK, I think something along the following
lines is needed:

 1. We (ab)use either a DLL characteristics flag or a section header flag to
indicate that the DLL needs to be loaded below 0x800
 2. The rebase utility warning for base addresses should take that flag into
account (to the point of requiring < 0x8000 if this new bit is set in
the image)
[2a. While we're changing validation for the image base, it'd be sensible to
add a check that the supplied address is 64K aligned :$]
 3. The flexlink utility should stop using 0x1 all the time. Probably
the best way to achieve this is if the rebase utility has a flag which
*sets* the new bit so that flexlink calls rebase after compilation to assign
an improved base address to the DLL. On x86, we don't force a given base
address at all - I assume that Cygwin's binutils stuff is already
rebase-aware and produces sensible base addresses for newly-compiled DLLs,
as I don't recall having ever seen the fork conflict problem on x86 builds
of OCaml?

Comments on the proposed need for some DLLs to occupy memory below
0x8000 and on the fixes much appreciated, thanks!


David


--
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