Re: crazy default permissions

[Mitch Deoudes]

On 10/5/2016 12:40 AM, Marco Atzeri wrote:

On 05/10/2016 06:31, Mitch Deoudes wrote:

mkdir has suddenly started creating directories with strange
permissions.  As far as I can tell, it's related to making directories
nested inside other directories that were also created within cygwin.
As you create deeper and deeper nestings, the perms get more and more
screwed up.  It starts at the second level deep, with the setuid flag,
and eventually gets to the point where you're making directories that
don't even have user read/write.

I tried this on a brand new installation of the latest cygwin64, with no
modifications, as of just now:

mitch@calculonjr ~/src/etc/rsync
$ umask
0022

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz

mitch@calculonjr ~/src/etc/rsync
$ ls -ld baz
drwxrwxr-x+ 1 mitch None 0 Oct  5 00:11 baz<--- first dir looks
reasonable (but doesn't match umask)

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz
total 0
drwsrwsr-t+ 1 mitch None 0 Oct  5 00:11 bob<--- second dir is weird

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz/bob/
total 0
d--Srws--T+ 1 mitch None 0 Oct  5 00:12 foo   <--- third dir doesn't
even have user read/write

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo/blob
mkdir: cannot create directory `baz/bob/foo/blob': Permission denied


Any guesses what might be causing this?  I'm pretty sure this was
working as of my last update, which was probably several months ago.

mitch




where is your home ?

$ cygpath -u ~
/home/marco

and what are its ACLS ?

$ cacls $(cygpath -w ~)
E:\cygwin64\home\marco MATZERI\marco:F
   BUILTIN\Administrators:R
   Everyone:R
   CREATOR OWNER:(OI)(CI)(IO)F
   CREATOR GROUP:(OI)(CI)(IO)R
   Everyone:(OI)(CI)(IO)R



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




Hmm...  in checking the acl's on my home dir, I noticed there was an 
entry for an unkown user.  Probably left over from the last time I 
migrated my data to a new windows install.  I deleted that entry via the 
Windows properties->security tab, which triggered a massive re-write of 
all the permissions for everything in my home dir.  Now mkdir seems to 
work fine.


No idea why that would cause/fix the problem.  Especially given the fact 
that said data migration happened probably years ago.  My home dir acl's 
do look a little convoluted compared to yours, though:


Everyone:(special access:)
 READ_CONTROL
 SYNCHRONIZE
 FILE_READ_EA
 FILE_READ_ATTRIBUTES

CREATOR OWNER:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:(OI)(CI)F
calculonjr\mitch:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F
BUILTIN\Users:(special access:)
  READ_CONTROL
  SYNCHRONIZE
  FILE_READ_EA
  FILE_READ_ATTRIBUTES

BUILTIN\Users:(CI)(IO)(special access:)
  SYNCHRONIZE
  FILE_WRITE_DATA
  FILE_APPEND_DATA

BUILTIN\Administrators:(ID)F
BUILTIN\Administrators:(OI)(CI)(IO)(ID)F
NT AUTHORITY\SYSTEM:(ID)F
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(ID)F
NT AUTHORITY\Authenticated Users:(ID)C
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C
BUILTIN\Users:(ID)R
BUILTIN\Users:(OI)(CI)(IO)(ID)(special access:)
  GENERIC_READ
  GENERIC_EXECUTE


--
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: crazy default permissions

[Marco Atzeri]

On 05/10/2016 06:31, Mitch Deoudes wrote:

mkdir has suddenly started creating directories with strange
permissions.  As far as I can tell, it's related to making directories
nested inside other directories that were also created within cygwin.
As you create deeper and deeper nestings, the perms get more and more
screwed up.  It starts at the second level deep, with the setuid flag,
and eventually gets to the point where you're making directories that
don't even have user read/write.

I tried this on a brand new installation of the latest cygwin64, with no
modifications, as of just now:

mitch@calculonjr ~/src/etc/rsync
$ umask
0022

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz

mitch@calculonjr ~/src/etc/rsync
$ ls -ld baz
drwxrwxr-x+ 1 mitch None 0 Oct  5 00:11 baz<--- first dir looks
reasonable (but doesn't match umask)

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz
total 0
drwsrwsr-t+ 1 mitch None 0 Oct  5 00:11 bob<--- second dir is weird

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz/bob/
total 0
d--Srws--T+ 1 mitch None 0 Oct  5 00:12 foo   <--- third dir doesn't
even have user read/write

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo/blob
mkdir: cannot create directory `baz/bob/foo/blob': Permission denied


Any guesses what might be causing this?  I'm pretty sure this was
working as of my last update, which was probably several months ago.

mitch




where is your home ?

$ cygpath -u ~
/home/marco

and what are its ACLS ?

$ cacls $(cygpath -w ~)
E:\cygwin64\home\marco MATZERI\marco:F
   BUILTIN\Administrators:R
   Everyone:R
   CREATOR OWNER:(OI)(CI)(IO)F
   CREATOR GROUP:(OI)(CI)(IO)R
   Everyone:(OI)(CI)(IO)R



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

crazy default permissions

[Mitch Deoudes]

mkdir has suddenly started creating directories with strange 
permissions.  As far as I can tell, it's related to making directories 
nested inside other directories that were also created within cygwin.  
As you create deeper and deeper nestings, the perms get more and more 
screwed up.  It starts at the second level deep, with the setuid flag, 
and eventually gets to the point where you're making directories that 
don't even have user read/write.


I tried this on a brand new installation of the latest cygwin64, with no 
modifications, as of just now:


mitch@calculonjr ~/src/etc/rsync
$ umask
0022

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz

mitch@calculonjr ~/src/etc/rsync
$ ls -ld baz
drwxrwxr-x+ 1 mitch None 0 Oct  5 00:11 baz<--- first dir looks 
reasonable (but doesn't match umask)


mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz
total 0
drwsrwsr-t+ 1 mitch None 0 Oct  5 00:11 bob<--- second dir is weird

mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo

mitch@calculonjr ~/src/etc/rsync
$ ls -l baz/bob/
total 0
d--Srws--T+ 1 mitch None 0 Oct  5 00:12 foo   <--- third dir doesn't 
even have user read/write


mitch@calculonjr ~/src/etc/rsync
$ mkdir baz/bob/foo/blob
mkdir: cannot create directory `baz/bob/foo/blob': Permission denied


Any guesses what might be causing this?  I'm pretty sure this was 
working as of my last update, which was probably several months ago.


mitch


--
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: [ITP] Perl distributions

[Marco Atzeri]

On 03/10/2016 11:45, Achim Gratz wrote:


perl-Archive-Extract (as requested by D. Stacey)
perl-ExtUtilsHelpers (an indirect build dependency of perl-Readonly)


added.



I also would like to get co-maintainership for

perl-MIME-tools
perl-MailTools

which are behind their latest releases and currently maintained by
Yaakov.


done. I assume Yaakov has no objection have you two have several Perl 
packages co maintained



Regards,
Achim.



Cheers
Marco

Re: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Marco Atzeri]

On 05/10/2016 05:00, Rinrin wrote:

Hi Gene:
  I made a patch for my private use.
  First of all, you should setup `nativenocheck` in CYGWIN environment
variable to enable this feature.
  If the target does not exist, it will check the last digit of target
path, for '/' it will create a  instead of 




BOTTOM POST on this list
please

--
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: `CYGWIN=winsymlinks:nativestrict`, `ln -s target link` fails if target doesn't exist

[Rinrin]

Hi Gene:
  I made a patch for my private use.
  First of all, you should setup `nativenocheck` in CYGWIN environment
variable to enable this feature.
  If the target does not exist, it will check the last digit of target
path, for '/' it will create a  instead of 



在 2016/4/30 8:14, Gene Pavlovsky 写道:
> I can confirm this behavior. Basically, mklink requires to choose file
> (default) or directory (/D) link. It is true whether or not the target
> exists (e.g. if your target is a directory,
> /D is not implied automatically, you have to specify it). By contrast,
> POSIX symlink doesn't distinguish file or directory symlinks.
> So, what does it have to do with the topic exactly? According to your
> logic, this is alos not good enough:
> 
> c:\>mkdir tmp
> 
> c:\>cd tmp
> 
> c:\tmp>mkdir target
> 
> c:\tmp>mklink /d link target
> symbolic link created for link <<===>> target
> 
> c:\tmp>cd link
> 
> c:\tmp\link>cd ..
> 
> c:\tmp>rmdir target
> 
> c:\tmp>echo file >target
> 
> c:\tmp>cd link
> The directory name is invalid.
> 
> c:\tmp>cat link
> file
> 
> But it doesn't mean Cygwin should stop offering to use native symlinks
> altogether, does it? What I mean is, POSIX symlinks are universal, and
> NTFS symlinks are of two kinds. Using native symlinks, therefore, can
> create potential problems, regardless of native or nativestrict mode.
> 
> I can see allowing dangling native symlinks can be a problem if
> there's some script that creates some (dangling) symlinks, and then
> later create some directories, to which the links are supposed to
> point to, but since they didn't exist at link creation time, the links
> are wrongfully of the file kind, and are not gonna work. I guess a
> script like this can theoretically exist, even though it sounds quite
> purposeless. Is this your concern? Then again, even crazier script can
> exist, which creates a symlink pointing somewhere once, and then later
> that somewhere can be removed and replaced with either a file or a
> directory (sounds crazy and useless, but who knows? it's possible).
> This script naturally will be broken whenever using native symlinks at
> all.
> 
> I think some choice should be made here:
> a) Allow creationg of dangling native symlinks (file by default).
> b) Add a third native mode which is less strict than `nativestrict`,
> but more strict than `native` - I'd like to use `nativestrict` on my
> system, but due to this issue I have to use `native`.
> c) Explicitly mention this behavior in Cygwin User Guide, so people
> know that using `nativestrict` can break some scripts that rely on
> creation of dangling symlinks. Currently the wording in CUG sounds
> like it might fail because the filesystem doesn't support symlinks or
> something.
> 
> Thanks.
> --Gene
> 
> 
> On 29 April 2016 at 15:02, Peter Rosin  wrote:
>> On 2016-04-29 13:34, Gene Pavlovsky wrote:
> POSIX says a symlink to a missing target is perfectly well-defined (you
> can't stat() through it, but you can readlink() it). But Windows native
> symlinks can't do that.  So the problems you are encountering all stem
> from the fact that you are trying to make Windows do something it can't.

 My initial reaction was that, too, but I tried mklink (CMD internal 
 command)

> mklink x y

 and it created the symlink in the empty directory just fine.
>>>
>>> This is my point exactly. Windows dangling symlinks can be created as
>>> easily as in UNIX.
>>> At least this is the case on my Win7 x64.
>>
>> No, it can't.
>>
>> c:\>mklink a b
>> c:\>mkdir b
>> c:\>cd b
>> c:\b>cd ..
>> c:\>cd a
>> The directory name is invalid
>> c:\>rmdir b
>> c:\>echo hello > b
>> c:\>type a
>> hello
>>
>> It only works for dangling links to files. Not good enough.
>>
>> Cheers,
>> Peter
> 
> --
> 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
> 



0005-native-symlinks-non-exist-target-support.patch
Description: application/itunes-itlp
--
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: Native symlinks and setup.exe

[Gene Pavlovsky]

Never mind, I found it's in another repository.
The code looks quite different, adapting the symlink code from newlib
to setup doesn't look straightforward, at least to my limited C
skills.

By the way, if I have an already created symlink, how do I check (e.g.
in a bash script) whether it's native or cygsymlink?

On 5 October 2016 at 02:08, Gene Pavlovsky  wrote:
> Eric,
>
> Before writing a patch it's wise to check if it would be accepted, now
> that your position is clear, somebody might do it.
> I don't think I'm up for the task, but I'd like to at least take a
> look at the sources.
> I've downloaded the git sources and found the link creation function
> is in winsup/cygwin/path.cc, can you tell me where are the sources for
> the setup util?
>
> Thanks.
>
> On 5 October 2016 at 00:04, Eric Blake  wrote:
>> On 10/04/2016 03:53 PM, Vince Rice wrote:
> Obviously, a political discussion is required, to decide whether it is
> ok, as is, or if a change in package logic would have benefits.
>>
>> The easiest way to have the discussion would be to write a patch,
>> instead of debating about different behaviors but then expecting others
>> to do the work.
>>
>>> I don’t see that changing. And, as already noted, setup isn’t a Cygwin 
>>> program,
>>> so it knows (and cares) nothing about cygwin environment variables.
>>
>> setup.exe has its own untar'ing code (it is NOT forking tar, since one
>> of the packages setup.exe has to install is tar, and it would be a
>> chicken-and-egg problem if setup always forked out to a tar program if
>> it can't first untar the tarball containing tar).  But while setup.exe
>> apparently does NOT currently honor the CYGWIN environment variable with
>> regards to how its untar'ring code should behave on symlinks, there's
>> nothing that prevents you from writing a patch to teach it to do so, and
>> perhaps that patch can even share some of the existing code for
>> cygwin1.dll so that you aren't writing it from scratch.  It should
>> already be clear that code exists in setup.exe that handles symlinks in
>> tarballs - all that this thread is complaining about is that the code
>> doesn't do it the way that cygwin1.dll does it.  But someone has to
>> write such a patch, and preferably someone that cares enough to be
>> bothered by the current behavior (I don't, so it won't be me writing it).
>>
>> --
>> Eric Blake   eblake redhat com+1-919-301-3266
>> Libvirt virtualization library http://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

Re: Native symlinks and setup.exe

[Gene Pavlovsky]

Eric,

Before writing a patch it's wise to check if it would be accepted, now
that your position is clear, somebody might do it.
I don't think I'm up for the task, but I'd like to at least take a
look at the sources.
I've downloaded the git sources and found the link creation function
is in winsup/cygwin/path.cc, can you tell me where are the sources for
the setup util?

Thanks.

On 5 October 2016 at 00:04, Eric Blake  wrote:
> On 10/04/2016 03:53 PM, Vince Rice wrote:
 Obviously, a political discussion is required, to decide whether it is
 ok, as is, or if a change in package logic would have benefits.
>
> The easiest way to have the discussion would be to write a patch,
> instead of debating about different behaviors but then expecting others
> to do the work.
>
>> I don’t see that changing. And, as already noted, setup isn’t a Cygwin 
>> program,
>> so it knows (and cares) nothing about cygwin environment variables.
>
> setup.exe has its own untar'ing code (it is NOT forking tar, since one
> of the packages setup.exe has to install is tar, and it would be a
> chicken-and-egg problem if setup always forked out to a tar program if
> it can't first untar the tarball containing tar).  But while setup.exe
> apparently does NOT currently honor the CYGWIN environment variable with
> regards to how its untar'ring code should behave on symlinks, there's
> nothing that prevents you from writing a patch to teach it to do so, and
> perhaps that patch can even share some of the existing code for
> cygwin1.dll so that you aren't writing it from scratch.  It should
> already be clear that code exists in setup.exe that handles symlinks in
> tarballs - all that this thread is complaining about is that the code
> doesn't do it the way that cygwin1.dll does it.  But someone has to
> write such a patch, and preferably someone that cares enough to be
> bothered by the current behavior (I don't, so it won't be me writing it).
>
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://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

Re: Latest "setup-x86(_64)?\.exe" version supporting WinXP

[David Stacey]

On 04/10/16 20:38, Peter A. Castro wrote:
The latest version of Setup is 2.876 (as of this writing).  I have no 
idea if it can be run on XP or not though I suspect it can.


The latest version of Setup does not run on XP. Details in the announcement:
https://cygwin.com/ml/cygwin-announce/2016-09/msg00032.html

Dave.


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

[ANNOUNCEMENT] Updated: weechat-1.6-1

[Sébastien Helleu]

Version 1.6-1 of "weechat" has been uploaded.

ChangeLog and release notes:

https://weechat.org/files/changelog/ChangeLog-1.6.html
https://weechat.org/files/releasenotes/ReleaseNotes-1.6.html

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send email to the
address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available starting
at this URL.

--
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: weechat-1.6-1

[Sébastien Helleu]

Version 1.6-1 of "weechat" has been uploaded.

ChangeLog and release notes:

https://weechat.org/files/changelog/ChangeLog-1.6.html
https://weechat.org/files/releasenotes/ReleaseNotes-1.6.html

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send email to the
address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available starting
at this URL.

Re: Native symlinks and setup.exe

[Eric Blake]

On 10/04/2016 03:53 PM, Vince Rice wrote:
>>> Obviously, a political discussion is required, to decide whether it is
>>> ok, as is, or if a change in package logic would have benefits.

The easiest way to have the discussion would be to write a patch,
instead of debating about different behaviors but then expecting others
to do the work.

> I don’t see that changing. And, as already noted, setup isn’t a Cygwin 
> program,
> so it knows (and cares) nothing about cygwin environment variables.

setup.exe has its own untar'ing code (it is NOT forking tar, since one
of the packages setup.exe has to install is tar, and it would be a
chicken-and-egg problem if setup always forked out to a tar program if
it can't first untar the tarball containing tar).  But while setup.exe
apparently does NOT currently honor the CYGWIN environment variable with
regards to how its untar'ring code should behave on symlinks, there's
nothing that prevents you from writing a patch to teach it to do so, and
perhaps that patch can even share some of the existing code for
cygwin1.dll so that you aren't writing it from scratch.  It should
already be clear that code exists in setup.exe that handles symlinks in
tarballs - all that this thread is complaining about is that the code
doesn't do it the way that cygwin1.dll does it.  But someone has to
write such a patch, and preferably someone that cares enough to be
bothered by the current behavior (I don't, so it won't be me writing it).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Native symlinks and setup.exe

[Vince Rice]

Please don’t https://cygwin.com/acronyms/#TOFU.

> On 4 October 2016 at 17:56, Gerrit Haase  wrote:
>> Hello Gene,
>> 
>> in my opinion, it is not a setup.exe or tar problem, but I think
>> packages should not include symlinks at all. All can be created
>> postinstallation by the postinstall script, inside Cygwin and the
>> users environment it is running on.
>> 
>> Obviously, a political discussion is required, to decide whether it is
>> ok, as is, or if a change in package logic would have benefits.
> 
> On Oct 4, 2016, at 3:41 PM, Gene Pavlovsky  wrote:
> 
> That is a good point as well, however I'm not sure what are the
> opinions of Cygwin's "elders".
> Would everyone vote for creating a policy like that and pushing it to
> the package maintainers?
> A political discussion is what I'm trying to start here :)

I am not a “Cygwin elder,” nor do I play one on TV.

Packages are going to include simlinks because packages have simlinks in them.
The goal of Cygwin is to minimize the work that has to be done to port a 
package.
For example, the gawk package includes a link to awk. And so forth.

I don’t see that changing. And, as already noted, setup isn’t a Cygwin program,
so it knows (and cares) nothing about cygwin environment variables.


--
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: Native symlinks and setup.exe

[Gene Pavlovsky]

That is a good point as well, however I'm not sure what are the
opinions of Cygwin's "elders".
Would everyone vote for creating a policy like that and pushing it to
the package maintainers?
A political discussion is what I'm trying to start here :)

On 4 October 2016 at 17:56, Gerrit Haase  wrote:
> Hello Gene,
>
> in my opinion, it is not a setup.exe or tar problem, but I think
> packages should not include symlinks at all. All can be created
> postinstallation by the postinstall script, inside Cygwin and the
> users environment it is running on.
>
> Obviously, a political discussion is required, to decide whether it is
> ok, as is, or if a change in package logic would have benefits.
>
>
> Regards,
> Gerrit
>
> --
> 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
>

--
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: Native symlinks and setup.exe

[Gene Pavlovsky]

That is a good solution indeed, if I just want to get the result I
want, for myself.
But it's just local solution.

On 4 October 2016 at 09:57, Vlado  wrote:
> On 3.10.2016 23:15, Gene Pavlovsky wrote:
>>
>> How about this kind of modification for the setup program: extract tar
>> archives into temp dir, after that search that temp dir for symlinks,
>
>
> Hi, Gene.
>
> Maybe You can consider to write and run simple script:
> - find all links (find -type l)
> - read target of link (readlink)
> - remove link (rm)
> - re-create link (ln -s)
> The ln -s should honor CYGWIN=winsymlinks:native and every link should be as
> You want.
>
> Vlado
>
>
>
> --
> 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
>

--
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: Latest "setup-x86(_64)?\.exe" version supporting WinXP

[Peter A. Castro]

On Tue, 4 Oct 2016, Sophoklis Goumas wrote:


Date: Tue, 4 Oct 2016 14:02:44 +0300
From: Sophoklis Goumas 
To: cygwin@cygwin.com
Subject: Latest "setup-x86(_64)?\.exe" version supporting WinXP

Hello.


Greetings, Sophoklis,


I'm seeing some contradicting clues from cygwin.com and
fruitbat.org's Cygwin Time Machine [1] as to which
is the latest version of "setup-x86(_64)?\.exe" with WinXP "support".


Are you asking about the ability to run Setup on XP or a version of Setup 
that can install the last release of Cygwin to support XP?


Strictly speeking, the gating factor is Cygwin itself.  V2.5.2-1 was the
last release with formal support for XP, I believe (someone, likely 
Corinna, will correct me if I'm wrong :-).


The version of Setup used with that release, is 2.874.  But, that version 
spans Cygwin 2.5.1-1 through 2.6.0-1.  Presumable that means it runs on XP 
just fine, even if Cygwin 2.6.0 doesn't.


The latest version of Setup is 2.876 (as of this writing).  I have no idea 
if it can be run on XP or not though I suspect it can.  It seems unlikely 
that Setup would take advantage of a Windows native service that's 
unavailable in XP (though I could be wrong).  Perhaps the owners 
of Setup can comment?



Something like:


The previous Cygwin version 2.5.2 was the last version supporting Windows XP 
and Server 2003.

< The last version of Setup to support XP is 2.874.

The SHA1SUMs of the files that come from fruitbat.org are:

4a01cccf0d6036b1bbca3bbaf13a97a97ca73918 setup-x86_64-2.874.exe
e8778fbd16f6d95b7abb0c93d31e8abb4d24d943 setup-x86-2.874.exe


I'm sure someone who has a separate copy of these will chime in.  Since I 
speak for the Time Machine... well... those are correct checksums to me! 
:-D



So, would, please, confirm that the version offered from fruitbat.org
is the last that includes WinXP "support"?

Would you also, please, confirm the validity of those files?


I can only speak for the Time Machine, but I can verify that I pulled 
those (really all) versions of Setup at the time they were available and 
are "valid" as presented on the Time Machine.  I pull directly from 
cygwin.com each day and check to see if it's a new version or not.


Corinna?  Does cygwin.com keep copies of the older setup versions?  Or am 
I the only one?



Thanks in advance,
Sophoklis

[1] http://www.fruitbat.org/Cygwin/timemachine.html

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


--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
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: Native symlinks and setup.exe

[Linda Walsh]

Thorsten Kampe wrote:
Tar's task is to unpack what's in the archive. So converting is out 
of question. You can ask the maintainer of the affected packages to 
create the symlinks in the postinstall script.

---
Is it a "special" tar, or is it the normal version of tar that 
runs under Cygwin?


I would assume that the install scripts run under the cygwin-environment.
That includes paying attention to the global value of CYGWIN.

If you set CYGWIN in your windows environment variables (recommended),
then it will always be set before any cygwin or setup program runs.
Setup isn't going to explicitly clear CYGWIN of its values, unless
they *happen* to be "invalid" -- and even then, I doubt it would modify
the user-set value of CYGWIN.

When I install programs, tar has always honored the global value of
CYGWIN I set in the system env vars.  (System is recommended over 
User Env, since cygwin can run as multiple users, and if you want 
consistent cygwin operation, you should set it before any cygwin

processes have started.

Is someone claiming that values in the System-Env var CYGWIN are
ignored by programs being installed?

NOTE: it is known and considered a "feature", that Cygwin ignores
MS-mountpoints mounted with mountd or linkd (link directory) and
treats them as symlinks.  This prohibits user control and redirection
of installed programs and disables the linux equivalent of 
mount --bind "thisdir" "onthisdir".





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

[ITP] gambas3

[Bastian Germann]

Hi,

I have packaged gambas3, a development environment similar to Visual
Basic, and would like to become a maintainer for it. Gambas is available
at http://gambas.sf.net and is licensed under GPLv2 or later.

The major GNU/Linux distributions include it in their repositories, e.g.
Debian: https://packages.debian.org/source/jessie/gambas3

The gambas3-gb-openal subpackage depends on alure, which I submitted two
weeks ago, but is not reviewed by anyone yet.

As gambas3 contains many subpackages, I decided not to clutter this
email with the contents of each setup.hint file. You can find the
packages at the following URLs:

http://germann-home.de/x86/gambas3/gambas3-3.9.1-1-src.tar.xz
http://germann-home.de/x86/gambas3/setup.hint

http://germann-home.de/x86/gambas3/gambas3-devel/gambas3-devel-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-devel/setup.hint

http://germann-home.de/x86/gambas3/gambas3-ide/gambas3-ide-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-ide/setup.hint

http://germann-home.de/x86/gambas3/gambas3-runtime/gambas3-runtime-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-runtime/setup.hint

http://germann-home.de/x86/gambas3/gambas3-scripter/gambas3-scripter-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-scripter/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-args/gambas3-gb-args-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-args/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-cairo/gambas3-gb-cairo-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-cairo/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-chart/gambas3-gb-chart-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-chart/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-clipper/gambas3-gb-clipper-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-clipper/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-complex/gambas3-gb-complex-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-complex/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-compress/gambas3-gb-compress-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-compress/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-compress-bzlib2/gambas3-gb-compress-bzlib2-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-compress-bzlib2/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-compress-zlib/gambas3-gb-compress-zlib-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-compress-zlib/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-crypt/gambas3-gb-crypt-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-crypt/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-data/gambas3-gb-data-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-data/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-db/gambas3-gb-db-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-db/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-db-form/gambas3-gb-db-form-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-db-form/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-db-mysql/gambas3-gb-db-mysql-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-db-mysql/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-db-postgresql/gambas3-gb-db-postgresql-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-db-postgresql/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-db-sqlite3/gambas3-gb-db-sqlite3-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-db-sqlite3/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-dbus/gambas3-gb-dbus-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-dbus/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-dbus-trayicon/gambas3-gb-dbus-trayicon-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-dbus-trayicon/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-desktop/gambas3-gb-desktop-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-desktop/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-desktop-gnome-keyring/gambas3-gb-desktop-gnome-keyring-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-desktop-gnome-keyring/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-desktop-x11/gambas3-gb-desktop-x11-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-desktop-x11/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-eval-highlight/gambas3-gb-eval-highlight-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-eval-highlight/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-form/gambas3-gb-form-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-form/setup.hint

http://germann-home.de/x86/gambas3/gambas3-gb-form-dialog/gambas3-gb-form-dialog-3.9.1-1.tar.xz
http://germann-home.de/x86/gambas3/gambas3-gb-form-dialog/setup.hint

Re: Native symlinks and setup.exe

[Gerrit Haase]

Hello Gene,

in my opinion, it is not a setup.exe or tar problem, but I think
packages should not include symlinks at all. All can be created
postinstallation by the postinstall script, inside Cygwin and the
users environment it is running on.

Obviously, a political discussion is required, to decide whether it is
ok, as is, or if a change in package logic would have benefits.


Regards,
Gerrit

--
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: Latest "setup-x86(_64)?\.exe" version supporting WinXP

[Vlado]

On 4.10.2016 13:02, Sophoklis Goumas wrote:

Would you also, please, confirm the validity of those files?


Hello Sophoklis,

I can confirm, that sha1sum of setup-x86_64-2.874.exe is valid.
Unfortunately, I don't have setup-x86-2.874.exe archived.

Vlado

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

Latest "setup-x86(_64)?\.exe" version supporting WinXP

[Sophoklis Goumas]

Hello.

I'm seeing some contradicting clues from cygwin.com and
fruitbat.org's Cygwin Time Machine [1] as to which
is the latest version of "setup-x86(_64)?\.exe" with WinXP "support".

Something like:

> The previous Cygwin version 2.5.2 was the last version supporting Windows XP 
> and Server 2003.
< The last version of Setup to support XP is 2.874.

The SHA1SUMs of the files that come from fruitbat.org are:

4a01cccf0d6036b1bbca3bbaf13a97a97ca73918 setup-x86_64-2.874.exe
e8778fbd16f6d95b7abb0c93d31e8abb4d24d943 setup-x86-2.874.exe

So, would, please, confirm that the version offered from fruitbat.org
is the last that includes WinXP "support"?

Would you also, please, confirm the validity of those files?

Thanks in advance,
Sophoklis

[1] http://www.fruitbat.org/Cygwin/timemachine.html

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

Automated Cygwin installation on a Google VM

[Nico Müller]

Hey everyone!

We are trying to set up an automated Cygwin install on a Windows
Server 2012 R2 VM in the Google cloud. The idea is to build a script
that makes sure Icinga is able to connect to the server via SSH, for
monitoring reasons.

Here is what we came up with:

---

# Cygwin installation + SSH setup
$file = "setup-x86_64.exe"
$url = "gs://cygwin/2.5.2/$($file)"
$output = "C:\Users\Public\Downloads\$($file)"

$localdir = "C:\cygwin_packages"
$rootdir = "C:\cygwin"
$mirror = "http://mirrors.kernel.org/sourceware/cygwin;
$packages = "openssh,vim,cygrunsrv"
$cyg_bash = "C:\cygwin\bin\bash.exe"

$cyg_pw_url = "xxx"
$cyg_password = Invoke-WebRequest -Uri $cyg_pw_url -UseBasicParsing
$cyg_password | Out-File "C:\Users\Public\cyg_server_password.txt"

$username = "icingaremote"
$ici_pw_url = "xxx"
$ici_password = Invoke-WebRequest -Uri $ici_pw_url -UseBasicParsing
$ici_password | Out-File "C:\Users\Public\icingaremote_password.txt"
$group = "Administrators"
$ssh_folder = "/home/$($username)/.ssh"
$key = "xxx"
$start_time = Get-Date

if (Test-Path $output) {
Write-Output "Cygwin installer $($output) already exists"
}
else {
gsutil cp $url $output
Write-Output "Installing Cygwin..."
Start-Process -FilePath $($output) -ArgumentList "-q -D -L -d -g
-o -s $($mirror) -l $($localdir) -R $($rootdir) -C Base -P
$($packages)" -Wait -PassThru

Write-Host "Creating folders for SSH login..."
Start-Process -FilePath $($cyg_bash) -ArgumentList "--login -c
'mkpasswd -l > /etc/passwd; mkdir -p $($ssh_folder); echo $($key) >
$($ssh_folder)/authorized_keys; chmod 700 $($ssh_folder); chmod 600
$($ssh_folder)/authorized_keys; chown -R $($username)
/home/$($username)/'" -Wait -PassThru

Write-Output "Starting SSH configuration..."
Start-Process -FilePath $($cyg_bash) -ArgumentList "--login -c
'ssh-host-config --yes --pwd $($cyg_password)'" -Wait

$sshd_config_file = "C:\cygwin\etc\sshd_config"
$acl = Get-Acl $sshd_config_file

$rule = New-Object -TypeName
System.Security.AccessControl.FileSystemAccessRule("$($group)",
"Modify", "None", "None", "Allow")
$acl.AddAccessRule($rule)
Set-Acl $sshd_config_file $acl

$sshd_config = Get-Content $sshd_config_file
$sshd_config.Replace('#PasswordAuthentication yes',
'PasswordAuthentication no').Replace('#PubkeyAuthentication yes',
'PubkeyAuthentication yes') | Out-File -Encoding ascii -FilePath
$sshd_config_file -Force

Start-Process -FilePath $($cyg_bash) -ArgumentList "--login -c
'cygrunsrv -S sshd'" -Wait

Write-Output "Total time taken:
$((Get-Date).Subtract($start_time).Seconds) second(s)"
}

# Add Firewall exception for SSH
New-NetFirewallRule -Protocol TCP -LocalPort 22 -Direction Inbound
-Action Allow -DisplayName SSH -Program "C:\cygwin\usr\sbin\sshd.exe"

---

Which works fine, if you run it as a local administrator, but fails to
start the SSHD service properly, if you run it as a startup script,
because startup scripts are run as the local system user. The file
permissions end up in a very messed up state, if the script is run as
the local system user.

Seeing that the Google cloud and Icinga are nothing too exotic, is
there anyone, who tried the same setup and had success setting this up
or has some general hints on this matter?

Regards

--
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: Native symlinks and setup.exe

[Vlado]

On 3.10.2016 23:15, Gene Pavlovsky wrote:

How about this kind of modification for the setup program: extract tar
archives into temp dir, after that search that temp dir for symlinks,


Hi, Gene.

Maybe You can consider to write and run simple script:
- find all links (find -type l)
- read target of link (readlink)
- remove link (rm)
- re-create link (ln -s)
The ln -s should honor CYGWIN=winsymlinks:native and every link should 
be as You want.


Vlado


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