Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Angelo Graziosi]

Corinna Vinschen wrote:
> How nice.  We have all the work and they simple grab it and don't give
> anything back to their upstream project.

...the *Dark* side of free (GPL?) software... I guess..

In any case, you could always *grab* their "pacman" manager.. Besides 
being very appealing, it would avoid the long thread [*] on cygwin-apps 
list..

Why what aims to be a "..Linux feeling - on Windows" should have a 
"package manager" (setup.exe :( ) which install deps more o less 
silently... apt-get, yum, pacman, port (on OSX) (and, I sure, others) 
always warn the user about which packages are to be installed..

Unless you adopt a 'true' package manager,  I would not change the 
current behavior of setup.exe..


Ciao,
  Angelo.

---
[*] https://cygwin.com/ml/cygwin-apps/2014-12/msg00017.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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Alexey Pavlov]

2014-12-10 2:28 GMT+03:00 Angelo Graziosi <>:
> Corinna Vinschen wrote:
>>
>> How nice.  We have all the work and they simple grab it and don't give
>> anything back to their upstream project.
>
>
> ...the *Dark* side of free (GPL?) software... I guess..
>
> In any case, you could always *grab* their "pacman" manager.. Besides being
> very appealing, it would avoid the long thread [*] on cygwin-apps list..
>
> Why what aims to be a "..Linux feeling - on Windows" should have a "package
> manager" (setup.exe :( ) which install deps more o less silently... apt-get,
> yum, pacman, port (on OSX) (and, I sure, others) always warn the user about
> which packages are to be installed..
>
> Unless you adopt a 'true' package manager,  I would not change the current
> behavior of setup.exe..
>

Hi!

I'm MSYS2 maintainer. I do not understand why some of you constantly
want to throw stones in the garden of MSYS2.  We are solve problems
other than Cygwin. And MSYS2 don't replace Cygwin as project. We have
small subset of Cygwin-like programs that only needed to develop
applications under Windows using mingw-w64 native toolchains. We don't
have X11 apps, daemons and many others as Cygwin have as it not need
to our work.
If you compare number of MSYS packages:
https://github.com/Alexpux/MSYS2-packages
with Cygwin package list than you can see the difference. Our primary
goal is native Windows applications building with mingw-w64
toolchains. We have create lot of mingw-w64 packages:
https://github.com/Alexpux/MINGW-packages
Some patches from our project are go upstream - many not as not all
projects are open-minded. For example Python where developers always
block changes that add Mingw as build target.

Latest MSYS2 runtime sources are always present here:
https://github.com/Alexpux/Cygwin/tree/develop
Yeah I'm forgetting push latest t osf.net because I don't use it and I
don't like sf.net web-interface to repositories. Maybe need just
delete repo on sf.net and redirect page to github.

Yeah I try to stay up-to-date with current Cygwin sources to not
create by anyone other fork of Cygwin for something like MSYS3 because
of MSYS2 outdate and not supportable. Also often syncing with cygwin
sources helps with merging our changes more easily. Merging 10 commits
instead of 100 is more easily.
Our changes to Cygwin runtime as we talk in the past are not
acceptable to Cygwin upstream because have a different philosophy and
have break some posix features. About half a year ago we talk about
how integrate MSYS functionality into Cygwin upstream. As a result of
this discussion was added this code:
https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212
To try make MSYS functionality separate from original Cygwin DLL.

But as our team is small and we have our real work too, we don't have
time and in some parts necessary knowledges to finish this work. Also
I think some changes can't be easily separated into external dll.
So we open minded to incorporate with Cygwin if anyone will help with
finishing this work.

In contrast with Cygwin developers, we don't have any problems with
Arch Linux developers as we use it's latest "pacman" from git  which
"is not released yet" and also have our own fork of it:
https://github.com/Alexpux/MSYS2-pacman/tree/master

So if you want to "grab" or "rip-off" (as you wish) our pacman, feel
free to get it and use under Cygwin. We don't have any problems with
it.


Regards,
Alexey.

>
> Ciao,
>  Angelo.
>
> ---
> [*] https://cygwin.com/ml/cygwin-apps/2014-12/msg00017.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
>

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4353 bytes --]

On Dec 10 08:36, Alexey Pavlov wrote:
> [...]
> Our changes to Cygwin runtime as we talk in the past are not
> acceptable to Cygwin upstream because have a different philosophy and
> have break some posix features. About half a year ago we talk about
> how integrate MSYS functionality into Cygwin upstream. As a result of
> this discussion was added this code:
> https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212
> To try make MSYS functionality separate from original Cygwin DLL.
> 
> But as our team is small and we have our real work too, we don't have
> time and in some parts necessary knowledges to finish this work.

As you may have noticed, our "team" is pretty small as well.  It looks
a lot like it's smaller than yours.

> Also
> I think some changes can't be easily separated into external dll.
> So we open minded to incorporate with Cygwin if anyone will help with
> finishing this work.

The problem is not that your changes can or can't be implemented using
cgf's suggested change, the problem is that you simply never discussed
it.  Cgf started a discussion of what changes might be required on
2013-07-30:

  https://cygwin.com/ml/cygwin-developers/2013-07/msg00075.html

As you may have noticed, the mail explicitely mention that this was
supposed to be a discussion.  He then checked in a preliminary patch to
a branch:

  https://cygwin.com/ml/cygwin-developers/2013-07/msg00076.html

The result:  Nothing.  You could have heard the crickets chirping in the
thread.  No.  Reply.  At.  All.  Until 2013-10-21, almost three months
later, cgf asked if nobody is interested to pick up:

  https://cygwin.com/ml/cygwin-developers/2013-10/msg00007.html

Reply:  We're just busy.  Then... nothing.  Crickets again, the thread
collecting dust and cobwebs.  Another four months later, cgf pinged you
guys and the result:

  https://cygwin.com/ml/cygwin-developers/2014-02/msg00001.html

Then... nothing.

How do you expect any progress if you don't at least **discuss what's
necessary, and eventually code up and test changes?

Both of us definitely lost interest after Feb-2014, because, apparently
you weren't able to come up with anything.  You have your solution,
which is a bunch of patches, and that's apparently enough for you.
There's no interest to follow up on a better solution, from what I see.

> In contrast with Cygwin developers, we don't have any problems with
> Arch Linux developers

You don't have interoperability issues with Arch Linux.  I explained
what we were thinking of pretty detailed on the mingw-w64-public mailing
list.  Without going into much detail now, the idea would have been
basically to keep the MSYS2 distro based on the latest Cygwin packages,
and have the behavioral change hidden behind the MSYS2 hook.  You could
have a seamless integration between all of the Cygwin distro and the few
parts of the MSYS2 distro which really needed a patch.  Basically MSYS2
could have been a subset or even an integral part of a Cygwin distro,
which would have (probably) benefitted all of us.

> So if you want to "grab" or "rip-off" (as you wish) our pacman, feel
> free to get it and use under Cygwin. We don't have any problems with
> it.

It's not really feasible because it requires to rebuild all packages.
We're also relying on an infrastructure which is kind of bound to the
setup and upset tools so far. Also, does pacman work without a basic
MSYS2 installed already, or do you have to have an MSYS2 install
to be able to run pacman?

If we could make pacman work with setup.ini, I wouldn't be unhappy
to have this as an accompanying CLI tool for installing Cygwin packages.

And if somebody thinks setup and the whole infrastructure is bad, all I
can say is, maybe, but somebody has to have *time* and *volition* to
implement something new.  Something still operating as a GUI installer
to install a Cygwin distro from the ground up.  And also something on
the server side to support the new layout.  And the packager support.
As long as my reqeusts for volunteers goes unheard, I don't see how we
could change that.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Alexey Pavlov]

2014-12-10 19:01 GMT+03:00 Corinna Vinschen:
> On Dec 10 08:36, Alexey Pavlov wrote:
>> [...]
>> Our changes to Cygwin runtime as we talk in the past are not
>> acceptable to Cygwin upstream because have a different philosophy and
>> have break some posix features. About half a year ago we talk about
>> how integrate MSYS functionality into Cygwin upstream. As a result of
>> this discussion was added this code:
>> https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212
>> To try make MSYS functionality separate from original Cygwin DLL.
>>
>> But as our team is small and we have our real work too, we don't have
>> time and in some parts necessary knowledges to finish this work.
>
> As you may have noticed, our "team" is pretty small as well.  It looks
> a lot like it's smaller than yours.

Yeah, but you is paid to work full time on Cygwin. While for us this
is just free-time project.
Sometimes we don't do anything for couple of weeks just because of lack of time.
Only 2 persons work on MSYS2 itself and both are have many other work
then MSYS2.
For you Cygwin is target of work but for us MSYS2 is just a tool to do
other work.
So we need time-share between different works.

>
>> Also
>> I think some changes can't be easily separated into external dll.
>> So we open minded to incorporate with Cygwin if anyone will help with
>> finishing this work.
>
> The problem is not that your changes can or can't be implemented using
> cgf's suggested change, the problem is that you simply never discussed
> it.  Cgf started a discussion of what changes might be required on
> 2013-07-30:
>
>   https://cygwin.com/ml/cygwin-developers/2013-07/msg00075.html
>
> As you may have noticed, the mail explicitely mention that this was
> supposed to be a discussion.  He then checked in a preliminary patch to
> a branch:
>
>   https://cygwin.com/ml/cygwin-developers/2013-07/msg00076.html
>
> The result:  Nothing.  You could have heard the crickets chirping in the
> thread.  No.  Reply.  At.  All.  Until 2013-10-21, almost three months
> later, cgf asked if nobody is interested to pick up:
>
>   https://cygwin.com/ml/cygwin-developers/2013-10/msg00007.html
>
> Reply:  We're just busy.  Then... nothing.  Crickets again, the thread
> collecting dust and cobwebs.  Another four months later, cgf pinged you
> guys and the result:
>
>   https://cygwin.com/ml/cygwin-developers/2014-02/msg00001.html
>
> Then... nothing.
>
> How do you expect any progress if you don't at least **discuss what's
> necessary, and eventually code up and test changes?
>
So here we have lost time...
But there are good too - we drop old MSYS code in this months.

> Both of us definitely lost interest after Feb-2014, because, apparently
> you weren't able to come up with anything.  You have your solution,
> which is a bunch of patches, and that's apparently enough for you.
> There's no interest to follow up on a better solution, from what I see.
>
>> In contrast with Cygwin developers, we don't have any problems with
>> Arch Linux developers
>
> You don't have interoperability issues with Arch Linux.  I explained
> what we were thinking of pretty detailed on the mingw-w64-public mailing
> list.  Without going into much detail now, the idea would have been
> basically to keep the MSYS2 distro based on the latest Cygwin packages,
> and have the behavioral change hidden behind the MSYS2 hook.  You could
> have a seamless integration between all of the Cygwin distro and the few
> parts of the MSYS2 distro which really needed a patch.  Basically MSYS2
> could have been a subset or even an integral part of a Cygwin distro,
> which would have (probably) benefitted all of us.
>
We have very different structure than Cygwin. So in any case we will need
create our own distro as we don't want to use Cygwin build packages system
and installer. Pacman solve a lot of problems for maintaining packages.
Also we switch to use real /usr folder and just create virtual mount for /bin
folder that needed for some programs.

>> So if you want to "grab" or "rip-off" (as you wish) our pacman, feel
>> free to get it and use under Cygwin. We don't have any problems with
>> it.
>
> It's not really feasible because it requires to rebuild all packages.
> We're also relying on an infrastructure which is kind of bound to the
> setup and upset tools so far. Also, does pacman work without a basic
> MSYS2 installed already, or do you have to have an MSYS2 install
> to be able to run pacman?

Pacman is MSYS-like program not Windows native so it can be run only
from install.
Our installer give user minimal system from what he can use pacman to
install packages
that user need. Minimal system also created with pacman using "chroot"
and then archived for installer.
MSYS2 is rolling-release system so we really don't have versions -
just create installer for current "snapshot"
to give new users more recent system without installing tons of
updates. But users also can upgrade system to recent from older
installers too.

>
> If we could make pacman work with setup.ini, I wouldn't be unhappy
> to have this as an accompanying CLI tool for installing Cygwin packages.

Pacman will not work with Cygwin's setup.ini. It have it's own
database per repository
of packages. So you can have, for example, official repository and
some user's own repositories.
Also for pacman present some GUI's:
https://wiki.archlinux.org/index.php/Pacman_GUI_Frontends


>
> And if somebody thinks setup and the whole infrastructure is bad, all I
> can say is, maybe, but somebody has to have *time* and *volition* to
> implement something new.  Something still operating as a GUI installer
> to install a Cygwin distro from the ground up.  And also something on
> the server side to support the new layout.  And the packager support.
> As long as my reqeusts for volunteers goes unheard, I don't see how we
> could change that.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Warren Young]

On Dec 10, 2014, at 9:37 PM, Alexey Pavlov <alexpux@gmail.com> wrote:

> Also we switch to use real /usr folder and just create virtual mount for /bin folder that needed for some programs.

You’re fighting the prevailing trend in Unix/Linux OS design by doing that.  Solaris, Red Hat, and probably others also alias /usr/bin and /bin, and /usr/lib and /lib.  It isn’t some weird Cygwin-only practice.

The reason for this separation goes back to the days when it made sense to have separate physical volumes for the OS root and the “user space”.  Now that you can get 64 gigs on a chip the size of your fingernail, this Unix design principle is about to follow UUCP into the dustbin of history.
--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Ray Donnelly]

On Thu, Dec 11, 2014 at 5:41 PM, Warren Young <wyml@etr-usa.com> wrote:
> On Dec 10, 2014, at 9:37 PM, Alexey Pavlov <alexpux@gmail.com> wrote:
>
>> Also we switch to use real /usr folder and just create virtual mount for /bin folder that needed for some programs.
>
> You’re fighting the prevailing trend in Unix/Linux OS design by doing that.  Solaris, Red Hat, and probably others also alias /usr/bin and /bin, and /usr/lib and /lib.  It isn’t some weird Cygwin-only practice.
>

We're sticking as close as we can to real Linux.

From my Arch Linux installation:
ls -l /
drwxr-xr-x  13 root root   4096 Oct 31 12:12 usr
lrwxrwxrwx   1 root root      7 Oct 25 19:41 bin -> usr/bin

.. so Linux has a real /usr folder like we do, and they use symlinks
for /bin and /lib. Since symlinks on Windows aren't always possible we
opted to use mounts instead.

> The reason for this separation goes back to the days when it made sense to have separate physical volumes for the OS root and the “user space”.  Now that you can get 64 gigs on a chip the size of your fingernail, this Unix design principle is about to follow UUCP into the dustbin of history.
> --
> 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[JonY]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On 12/10/2014 07:28, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
>> How nice.  We have all the work and they simple grab it and don't give
>> anything back to their upstream project.
> 
> ...the *Dark* side of free (GPL?) software... I guess..
> 

No, this is exactly how GPL is supposed to work, now that it has been
corrected, anyone can grab the MSYS2 sources.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Dec 10 17:47, JonY wrote:
> On 12/10/2014 07:28, Angelo Graziosi wrote:
> > Corinna Vinschen wrote:
> >> How nice.  We have all the work and they simple grab it and don't give
> >> anything back to their upstream project.
> > 
> > ...the *Dark* side of free (GPL?) software... I guess..
> > 
> 
> No, this is exactly how GPL is supposed to work, now that it has been
> corrected, anyone can grab the MSYS2 sources.

ACK.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Angelo Graziosi]

Ciao Corinna,

Corinna Vinschen wrote:
> The new nsswitch.conf settings

maybe I am wrong.. but shouldn't these new test release come with a 
default /etc/nsswitch.conf file? a file which is installed/updated if it 
does not exist/unchanged..

I have seen that MSYS2 *has* it...

Ciao,
  Angelo.

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Dec  7 12:21, Angelo Graziosi wrote:
> Ciao Corinna,
> 
> Corinna Vinschen wrote:
> >The new nsswitch.conf settings
> 
> maybe I am wrong.. but shouldn't these new test release come with a default
> /etc/nsswitch.conf file? a file which is installed/updated if it does not
> exist/unchanged..

This would be the job of the base-cygwin package, which I'll update as
soon as I release Cygwin 1.7.34.

> I have seen that MSYS2 *has* it...

The Cygwin rip-off which, again, violates the GPL?

They are already releasing the code which isn't even officially release
for Cygwin?

How nice.  We have all the work and they simple grab it and don't give
anything back to their upstream project.  How very nice.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

Hi Cygwin friends and users,


I finally released another TEST version of the next upcoming Cygwin
release.  The version number is 1.7.34-002.

The big changes compared to 1.7.34-001, apart from bugfixes and a new
API (qsort_r), are the following:

- The new nsswitch.conf settings "db_home", "db_shell", and "db_gecos"
  to define where and how to fetch home directory, login shell, and
  gecos content.

  Most importantly, this is also documented now.  See the preliminary
  documentation URL below.

- When spawning a process under another user account (sshd, cron, etc),
  the user's default Windows environment is now merged into the new
  processes environment.


If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
"test" release.


The major change in this new release will be the new method to read
account (passwd and group) information from the Windows user databases
directly, without the requirement to generate /etc/passwd and /etc/group
files to generate Unix-like uid and gid.

For your convenience I wrote new documentation.  Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at

  https://cygwin.com/preliminary-ntsec.html

If you read it (which I seriously hope for) and it's all just
incomprehensible gobbledygook to you, please say so on the mailing list

  cygwin AT cygwin DOT com

so we have a chance to improve the documentation.

Please give this TEST release a try.

If you find problems in the new features or regressions compared to the
current stable release 1.7.33, please report them to the public mailing
list

  cygwin AT cygwin DOT com


Following is a list of changes in this new release:


What's new:
-----------

- Cygwin can now generate passwd/group entries directly from Windows
  user databases (local SAM or Active Directory), thus allowing to run
  Cygwin without having to create /etc/passwd and /etc/group files.
  Introduce /etc/nsswitch.conf file to configure passwd/group handling.

  For bordercase which require to use /etc/passwd and /etc/group files,
  change mkpasswd/mkgroup to generate passwd/group entries compatible
  with the entries read from SAM/AD.

- Add -b/--remove-all option to setfacl to reduce the ACL to only the
  entries representing POSIX permission bits.

- Provide Cygwin documentation (PDFs and HTML) for offline usage in
  /usr/share/doc/cygwin-${version}.


What changed:
-------------

- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
  are supposed to work.  Finally implement a CLASS_OBJ emulation.  Update
  getfacl(1)/setfacl(1) accordingly.

- The xdr functions are no longer exported for newly built executables.
  Use libtirpc-devel instead.

- 32 bit only: Change default values for socket buffer size to raise
  performance on 10Gb networks.

- When spawning a process under another user account, merge the user's
  default Windows environment into the new process' environment.


Bug Fixes
---------

- Fix the problem that ptys master side always writes single byte packages
  to the slave side, and pty slaves always read VMIN byte packages from
  the master side if VMIN is > 0.
  Fixes: https://cygwin.com/ml/cygwin-developers/2014-11/msg00000.html

- Fix a synchronization problem in signal handling when using pthreads.
  Addresses: https://cygwin.com/ml/cygwin/2014-11/msg00472.html

- Fix an "invalid handle" problem when using flock(2) with a parent process
  holding the lock.
  Addresses: https://cygwin.com/ml/cygwin/2014-12/msg00012.html


To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe

If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so.  If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.


Have fun,
Corinna

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

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Henry S. Thompson]

Corinna Vinschen writes:

> I finally released another TEST version of the next upcoming Cygwin
> release.  The version number is 1.7.34-002.

I just installed both 32- and 64-bit version on top of my existing
(normal) release. The 64-bit one has a two-line (passwd=group=db)
nsswitch.conf left over from May, when I last tried a test release,
the 32-bit one has no nsswitch.conf.

Nothing to report.  ssh, sshd and kinit all work on 64-bit, ssh and
kinit on 32-bit.  Thought this was just barely worth a mention.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Dec  7 15:59, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> 
> > I finally released another TEST version of the next upcoming Cygwin
> > release.  The version number is 1.7.34-002.
> 
> I just installed both 32- and 64-bit version on top of my existing
> (normal) release. The 64-bit one has a two-line (passwd=group=db)
> nsswitch.conf left over from May, when I last tried a test release,
> the 32-bit one has no nsswitch.conf.
> 
> Nothing to report.  ssh, sshd and kinit all work on 64-bit, ssh and
> kinit on 32-bit.  Thought this was just barely worth a mention.

Heh.  I'm glad for your report nevertheless.  I'd be just happy if
people would experiment with the new nsswitch.conf options a bit.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Warren Young]

On Dec 6, 2014, at 12:49 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> - Cygwin can now generate passwd/group entries directly from Windows

This is huge, Corinna!

It must have been a lot of work, and while I personally will not benefit much from this — don’t use AD here, and /etc/passwd suffices for my purposes — it’s one of those things that should obviously be done.

Congratulations on getting this into a shippable state.  I realize it isn’t formally released yet, but you’ve gotten it over the hump where it must be compiled out of release binaries.  I assume this is one of those situations where the last 10% of the work takes 90% of the time.

Congratulations!
--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Dec  8 15:14, Warren Young wrote:
> On Dec 6, 2014, at 12:49 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > - Cygwin can now generate passwd/group entries directly from Windows
> 
> This is huge, Corinna!
> 
> It must have been a lot of work, and while I personally will not
> benefit much from this — don’t use AD here, and /etc/passwd suffices
> for my purposes

You can still benefit, I hope.  Even when using only the local SAM, the
process startups should be a tad bit faster than when every exec'ed
process has to read /etc/passwd and /etc/group files:

  $ cat > /etc/nsswitch.conf <<EOF
  passwd: db
  group: db
  EOF
  $ exit
  <restart your terminal>

Give it a try!

> — it’s one of those things that should obviously be
> done.
> 
> Congratulations on getting this into a shippable state.  I realize it
> isn’t formally released yet, but you’ve gotten it over the hump where
> it must be compiled out of release binaries.  I assume this is one of
> those situations where the last 10% of the work takes 90% of the time.
> 
> Congratulations!

Thank you very much!  I started to implement this stuff in January 2014
and the formal release will hopefully be in January 2015, so, yes, all
in all, it was a lot of work.  Especially the documentation :}


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Warren Young]

On Dec 9, 2014, at 3:56 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> On Dec  8 15:14, Warren Young wrote:
>> On Dec 6, 2014, at 12:49 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
>> 
>>> - Cygwin can now generate passwd/group entries directly from Windows
>> 
>> don’t use AD here, and /etc/passwd suffices
>> for my purposes
> 
> You can still benefit, I hope.  Even when using only the local SAM, the
> process startups should be a tad bit faster than when every exec'ed
> process has to read /etc/passwd and /etc/group files:

Challenge…accepted.

I decided to do the nastiest thing I could think of to Cygwin: run a configure script. ;)

In my Windows 10 Technical Preview test VM, Cygwin 64 1.7.33 runs the iperf3 configure script in 20 seconds.  On upgrading to 1.7.34-002, without doing anything to nsswitch.conf, the time remained the same.  On making the suggested change to nsswitch.conf, configure time went *up* to 21 seconds.

So, I moved the new nsswitch.conf back out of the way, relaunched MinTTY, and configure time dropped its extra second.

Hmm.
--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

On Dec  9 15:05, Warren Young wrote:
> On Dec 9, 2014, at 3:56 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > On Dec  8 15:14, Warren Young wrote:
> >> On Dec 6, 2014, at 12:49 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> >> 
> >>> - Cygwin can now generate passwd/group entries directly from Windows
> >> 
> >> don’t use AD here, and /etc/passwd suffices
> >> for my purposes
> > 
> > You can still benefit, I hope.  Even when using only the local SAM, the
> > process startups should be a tad bit faster than when every exec'ed
> > process has to read /etc/passwd and /etc/group files:
> 
> Challenge…accepted.
> 
> I decided to do the nastiest thing I could think of to Cygwin: run a
> configure script. ;)
> 
> In my Windows 10 Technical Preview test VM, Cygwin 64 1.7.33 runs the
> iperf3 configure script in 20 seconds.  On upgrading to 1.7.34-002,
> without doing anything to nsswitch.conf, the time remained the same.
> On making the suggested change to nsswitch.conf, configure time went
> *up* to 21 seconds.
> 
> So, I moved the new nsswitch.conf back out of the way, relaunched
> MinTTY, and configure time dropped its extra second.
> 
> Hmm.

Indeed, hmm.  I see a tiny loss in performance myself.  It's puzzeling.
During the entire configure run only at the end are a few minor (but
unnecessary) requests for account information.  I'll investigate this
in the next couple of days.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Andrey Repin]

Greetings, Warren Young!

>> - Cygwin can now generate passwd/group entries directly from Windows

> This is huge, Corinna!

> It must have been a lot of work, and while I personally will not benefit
> much from this — don’t use AD here, and /etc/passwd suffices for my purposes
> — it’s one of those things that should obviously be done.

You'd be surprised to know, how much faster it works when you delete the
passwd. Especially if you start alot of Cygwin tools from native app, so they
don't benefit from parent caching.

> Congratulations on getting this into a shippable state.  I realize it isn’t
> formally released yet, but you’ve gotten it over the hump where it must be
> compiled out of release binaries.  I assume this is one of those situations
> where the last 10% of the work takes 90% of the time.

On this, I agree.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 09.12.2014, <14:36>

Sorry for my terrible english...

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Thomas Wolff]

With cygwin-devel 1.7.34-002, the following test program (2 lines):
#define _BSD_SOURCE
#include <stdlib.h>

produces this error:
In file included from test.c:2:0:
/usr/include/stdlib.h:258:23: error: expected string literal before 
‘__ASMNAME’
               __asm__ (__ASMNAME ("__bsd_qsort_r"));
                        ^

------
Thomas

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Dec 12 23:42, Thomas Wolff wrote:
> With cygwin-devel 1.7.34-002, the following test program (2 lines):
> #define _BSD_SOURCE
> #include <stdlib.h>
> 
> produces this error:
> In file included from test.c:2:0:
> /usr/include/stdlib.h:258:23: error: expected string literal before
> ‘__ASMNAME’
>               __asm__ (__ASMNAME ("__bsd_qsort_r"));
>                        ^

Thanks.  Try adding

  #include <sys/cdefs.h>

This include is missing in stdlib.h, but it's required to get the
definition of __ASMNAME.  I'll fix that upstream.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]