Re: Putting packages up for adoption

[Andrew Schulman via Cygwin-apps]

> On Mar 19 23:47, Yaakov Selkowitz wrote:
> > Hello Cygwin package maintainers,

 
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption. 


> > Yaakov
> 
> There's no number of goldstars or plush hippos which would do justice to
> what you did for Cygwin, Yaakov.  If there's something like the ULTIMATE
> PLUSH HIPPO REPLACING EVRY OTHER PLUSH HIPPO, you should get it.

Well that's what I get for not checking the list for a week.

I'm happy to oblige, and I have sort of a picture in my head of what that
might look like, but I'm not skilled at rendering it. If anyone has any
recommendations, please send to me directly by email.

Andrew

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op di 24 mrt. 2020 om 15:25 schreef Yaakov Selkowitz:
> Fedora, and possibly other distros as well, set a default search path
> for tcl that conforms with their desired filesystem layout -- having
> all extensions under /usr/{lib,share}/tclX.Y instead of scattered
> throughout /usr/{lib,share}.

Thank you! It's 100% clear to me now. It's just about customising
to Fedora's directory layout. They have the right to do that, I have
the right to ignore it ;-).

Regards,
Jan Nijtmans


Regards,
 Jan Nijtmans

Re: Cygwin-OpenSSH 8.2.2.2

[Bill Stewart]

On Tue, Mar 24, 2020 at 4:24 AM Adam Dinwoodie wrote:

> On Tue, 24 Mar 2020 at 01:04, L A Walsh wrote:
> >
> > On 2020/02/27 14:30, Brian Inglis wrote:
> > > No, you must backport all sources to the current and all previous versions
> > 
> > What all previous versions?  Going back to year 2000 or before?
> >
> > That sounds a bit onerous.
>
> I think the point Brian was trying to make was that it is not
> sufficient to provide the source code in future releases of Bill's
> Cygwin-OpenSSH package. To comply with the GPL requirements, Bill
> would need to make available all the relevant source code for every
> binary release he has made of his package.
>
> Alternatively: yes. The GPL _is_ onerous. That's sort of the point: it
> forces people to make source code available even when they don't want
> to, regardless of whether that's because they don't want others
> changing their code or because they just don't want to do the
> additional work.

As already noted last month, the offending Cygwin-OpenSSH package has
been removed from GitHub.

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

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Tue, 2020-03-24 at 15:11 +0100, Jan Nijtmans via Cygwin-apps wrote:
> Op di 24 mrt. 2020 om 14:51 schreef Yaakov Selkowitz:
> > > However, I created a "fedora" branch in (upstream) Tcl, in which
> > > I merged the two patches from fedora. Result:
> > >  
> > 
> > The errors I see there are "Test file error: can't find package
> > tcltests", which sounds like an issue with the test environment and not
> > on those changes.
> 
> The point is, Tcl has a specific order of paths where it searches its
> environment, like an $auto_path variable. The test-suite tests
> this algorithm, and - apparently - the outcome of the algorith
> changed. You can add additional paths, but you cannot change
> the order of existing paths that are searched. So, sorry, but
> I respectfully disagree. The test-suite adds a path where it
> can find the "tcltests" package, the fedora changes result
> in not finding that package any more. That's a bug in the
> path search algorithm, which is modified by the fedora patch.

Fedora, and possibly other distros as well, set a default search path
for tcl that conforms with their desired filesystem layout -- having
all extensions under /usr/{lib,share}/tclX.Y instead of scattered
throughout /usr/{lib,share}.  Customing the directory layout of
interpreted language extensions is a common and accepted downstream
practice.  Therefore, it would be a bug in the test environment, e.g.
in not using the Tcl it is testing to determine where tcltests should
be installed.

--
Yaakov

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op di 24 mrt. 2020 om 14:51 schreef Yaakov Selkowitz:
> > However, I created a "fedora" branch in (upstream) Tcl, in which
> > I merged the two patches from fedora. Result:
> >  
>
> The errors I see there are "Test file error: can't find package
> tcltests", which sounds like an issue with the test environment and not
> on those changes.

The point is, Tcl has a specific order of paths where it searches its
environment, like an $auto_path variable. The test-suite tests
this algorithm, and - apparently - the outcome of the algorith
changed. You can add additional paths, but you cannot change
the order of existing paths that are searched. So, sorry, but
I respectfully disagree. The test-suite adds a path where it
can find the "tcltests" package, the fedora changes result
in not finding that package any more. That's a bug in the
path search algorithm, which is modified by the fedora patch.

Regards,
 Jan Nijtmans

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Tue, 2020-03-24 at 12:41 +0100, Jan Nijtmans via Cygwin-apps wrote:
> Op di 24 mrt. 2020 om 00:38 schreef Yaakov Selkowitz:
> > > Hm. It appears that they did:
> > >  
> > 
> > I meant their mingw-tcl package.
> 
> Indeed, you are right!
> 
> However, I created a "fedora" branch in (upstream) Tcl, in which
> I merged the two patches from fedora. Result:
>  

The errors I see there are "Test file error: can't find package
tcltests", which sounds like an issue with the test environment and not
on those changes.

> So, I wonder if they ran the Tcl test suite  this gives not
> much thrust, since they changes assumptions made
> in the test-cases, assumptions that user-applications
> and other environments could depend on.

--
Yaakov

Re: please update cygwin lighttpd pkg to version 1.4.55

[gs-cygwin . com]

On Tue, Mar 24, 2020 at 11:51:40AM +0100, Marco Atzeri via Cygwin wrote:
> Am 24.03.2020 um 06:50 schrieb gs-cygwin@gluelogic.com:
> > Please update cygwin lighttpd pkg to version 1.4.55
> > 
> > lighttpd 1.4.55 was released 31 Jan 2020 (upstream).
> > 
> > Thank you.  Glenn
> > --
> 
> In this moment the package is without a maintainer.
> Any specific reason why you need absolutely the last version ?

There are numerous bugs in lighttpd 1.4.54 (and fixed in lighttpd
1.4.55) which prevent usage of lighttpd if using one of the modules
with bugs, e.g. mod_webdav and mod_deflate.

bug: mod_deflate fix error choosing encoding parser (1.4.54 regression)
bug: mod_webdav startup crash in config conditional (1.4.54 regression)
bug: mod_webdav fix file upload limit
bug: mod_accesslog fails to parse multiple cookies
bug: preserve %2b and %2B in query string normalization

There are numerous security enhancements (hardenings) in lighttpd 1.4.55

security: HTTP Basic/Digest Auth security (attack mitigations)
security: HTTP request header parsing restrictions (attack mitigations)

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

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op di 24 mrt. 2020 om 00:38 schreef Yaakov Selkowitz:
> > Hm. It appears that they did:
> >  
>
> I meant their mingw-tcl package.

Indeed, you are right!

However, I created a "fedora" branch in (upstream) Tcl, in which
I merged the two patches from fedora. Result:
 

So, I wonder if they ran the Tcl test suite  this gives not
much thrust, since they changes assumptions made
in the test-cases, assumptions that user-applications
and other environments could depend on.

Regards,
 Jan Nijtmans

Re: please update cygwin lighttpd pkg to version 1.4.55

[Marco Atzeri via Cygwin]

Am 24.03.2020 um 06:50 schrieb gs-cygwin@gluelogic.com:

Please update cygwin lighttpd pkg to version 1.4.55

lighttpd 1.4.55 was released 31 Jan 2020 (upstream).

Thank you.  Glenn
--


In this moment the package is without a maintainer.
Any specific reason why you need absolutely the last version ?


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

Re: Cygwin-OpenSSH 8.2.2.2

[Adam Dinwoodie]

On Tue, 24 Mar 2020 at 01:04, L A Walsh wrote:
>
> On 2020/02/27 14:30, Brian Inglis wrote:
> > No, you must backport all sources to the current and all previous versions
> 
> What all previous versions?  Going back to year 2000 or before?
>
> That sounds a bit onerous.

I think the point Brian was trying to make was that it is not
sufficient to provide the source code in future releases of Bill's
Cygwin-OpenSSH package. To comply with the GPL requirements, Bill
would need to make available all the relevant source code for every
binary release he has made of his package.

Alternatively: yes. The GPL _is_ onerous. That's sort of the point: it
forces people to make source code available even when they don't want
to, regardless of whether that's because they don't want others
changing their code or because they just don't want to do the
additional work.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

[Mark Geisert]

Maybe it can simply be fixed by changing the order of setting up locale stuff 
and applying the expansion in cygwin?

(I would look into the code if I had a clue where to find the respective 
things.)


I would guess dcrt0.cc, the Cygwin DLL runtime initialization.

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

Re: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

[Thomas Wolff]

Am 24.03.2020 um 08:18 schrieb Jay Libove via Cygwin:

Hi Cygwin team,
Here is a consolidated bug report based on the discussion in recent days which I'd started under 
the subject " shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or 
directory" in Windows CMD shell, but works okay in bash " (thread starter 
https://cygwin.com/pipermail/cygwin/2020-March/244161.html )
Many thanks to Paul, Andrey, and others for helping me nail down where and how 
it seems to be happening.
My apologies in advance that my coding days are long behind me, so I'm not in a 
position to include a proposed code fix.

cygcheck output attached (lightly modified to redact a couple of personal 
items).

Problem:
Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' 
built-in argv[] globbing will produce unexpected:
"{programName}: cannot access '{glob pattern}: No such file or directory"
e.g.
"ls: cannot access '*.pdf': No such file or directory"
.. despite the fact that e.g. *.pdf definitely exists.

Steps to Reproduce:
* Have some files in the local director with accented characters in the names, 
e.g.:
C:> mkdir c:\temp\test
C:> cd c:\temp\test
C:> touch héllo.pdf
C:> touch gòodbye.pdf
C:> touch normal.pdf
* DON'T have the LANG= environment variable set to anything
* NOT in bash or Cygwin Terminal, but rather within Windows CMD.exe, execute a 
Cygwin command which needs to do file name globbing because the Windows CMD.exe 
shells does not do so for it, e.g.
C:> ls *.pdf
C:> cat *.pdf
These will produce "ls: cannot access '*.pdf': No such file or directory"
Although, curiously,
C:> ls *or*
does correctly produce:
normal.pdf

Also, display output of the áccènted characters is incomplete:
C:> ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf
C:> bash
jay_l@DESKTOP-I9MRIE3 /cygdrive/c/Temp
$ ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf


Analysis:
I've verified that it's not about case sensitivity. That is, it's not a matter 
of ls *.pdf vs. ls *.PDF.
If these test commands are run either under bash.exe or within a Cygwin 
Terminal window, the problem does not occur.
I've verified that the Windows system locale (per Windows' Region setting) 
actually doesn't matter. (I've reproduced this both on systems in Region Spain 
with language English-International and English-Ireland, and in a VM with a bog 
standard vanilla US English Windows).

Credits to Paul for suggesting deleting files one by one until the problem goes 
away, and to Andrey for pointing out `locale` and the LANG= setting.

Set LANG=en_US.UTF-8, e.g.
C:> set LANG=en_US.UTF-8
.. and the problem goes away.
C:> ls *.pdf
gòodbye.pdf
héllo.pdf
normal.pdf
C:> ls
gòodbye.pdf
héllo.pdf
normal.pdf

Interestingly, Andrey mentioned that he sets LANG=ru_RU.CP866 and he doesn't 
see the problem. When I tried that exact setting, I still had the problem.
So it's maybe not just that LANG must be set to *something*, but that somehow 
LANG must be set to something that matches something in Windows? (Sorry, I know 
that's nearly uselessly vague).


In summary, it appears that the way that the argv[] globbing code which gets 
compiled in to Cygwin programs functions a bit differently than the way the 
shell globbing code works within bash.exe.
And this produces unexpected globbing failures.

(As commented in the other thread already:)
Maybe it can simply be fixed by changing the order of setting up locale 
stuff and applying the expansion in cygwin?
(I would look into the code if I had a clue where to find the respective 
things.)

Thomas



Thanks to all the Cygwin maintainers for this amazing software, for so many 
years!
-Jay

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

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/24/2020 4:09 AM, Mark Geisert wrote:

Eliot Moss wrote:

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include  on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.


Thanks very much for working on all this and contributing it.  I will build and test as soon as I 
can.  I need to research the packaging steps because I intend to ITA this package.  I do also want 
to take another look at the other programs built as part of --enable-schedutils; they might (or 
might not) build cleanly but AFAIK there's no support within Cygwin and/or Windows for what they can 
do on Linux.


Agreed - glad to help!   Eliot
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include  on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.


Thanks very much for working on all this and contributing it.  I will build and 
test as soon as I can.  I need to research the packaging steps because I intend 
to ITA this package.  I do also want to take another look at the other programs 
built as part of --enable-schedutils; they might (or might not) build cleanly 
but AFAIK there's no support within Cygwin and/or Windows for what they can do 
on Linux.


Thanks again,

..mark

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

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

[Thomas Wolff]

Am 23.03.2020 um 20:13 schrieb Andrey Repin:

Greetings, Jay Libove!

...

If I set LANG=en_US.UTF-8 in a Windows CMD window, **then the globbing problem 
goes away**.
I was about to respond that cmd.exe does not do shell expansion but in 
fact there is a cygwin workaround to replace it with library-run 
expansion. Maybe it's done before the locale is set up in cygwin dll? 
Could the order be reversed?

Thomas


I'm not sure how that points towards a solution, but it certainly must be a 
clue.

I have LANG=ru_RU.UTF-8 set in the user environment, but i have an autostart
script for cmd.exe to set LANG=ru_RU.CP866 when I want to work in plain
command prompt. But then again, I have code in ~/.bashrc which would

1. chcp 65001
2. export "LANG=$(locale -uU)"

which helps transitioning from native applications to (saner) Cygwin 
environment.




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

bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

[Jay Libove via Cygwin]

Hi Cygwin team,
Here is a consolidated bug report based on the discussion in recent days which 
I'd started under the subject " shell expansion produces e.g. "ls: cannot 
access '*.pdf': No such file or directory" in Windows CMD shell, but works okay 
in bash " (thread starter 
https://cygwin.com/pipermail/cygwin/2020-March/244161.html )
Many thanks to Paul, Andrey, and others for helping me nail down where and how 
it seems to be happening.
My apologies in advance that my coding days are long behind me, so I'm not in a 
position to include a proposed code fix.

cygcheck output attached (lightly modified to redact a couple of personal 
items).

Problem:
Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' 
built-in argv[] globbing will produce unexpected:
"{programName}: cannot access '{glob pattern}: No such file or directory"
e.g.
"ls: cannot access '*.pdf': No such file or directory"
.. despite the fact that e.g. *.pdf definitely exists.

Steps to Reproduce:
* Have some files in the local director with accented characters in the names, 
e.g.:
C:> mkdir c:\temp\test
C:> cd c:\temp\test
C:> touch héllo.pdf
C:> touch gòodbye.pdf
C:> touch normal.pdf
* DON'T have the LANG= environment variable set to anything
* NOT in bash or Cygwin Terminal, but rather within Windows CMD.exe, execute a 
Cygwin command which needs to do file name globbing because the Windows CMD.exe 
shells does not do so for it, e.g.
C:> ls *.pdf
C:> cat *.pdf
These will produce "ls: cannot access '*.pdf': No such file or directory"
Although, curiously,
C:> ls *or*
does correctly produce:
normal.pdf

Also, display output of the áccènted characters is incomplete:
C:> ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf
C:> bash
jay_l@DESKTOP-I9MRIE3 /cygdrive/c/Temp
$ ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf


Analysis:
I've verified that it's not about case sensitivity. That is, it's not a matter 
of ls *.pdf vs. ls *.PDF.
If these test commands are run either under bash.exe or within a Cygwin 
Terminal window, the problem does not occur.
I've verified that the Windows system locale (per Windows' Region setting) 
actually doesn't matter. (I've reproduced this both on systems in Region Spain 
with language English-International and English-Ireland, and in a VM with a bog 
standard vanilla US English Windows).

Credits to Paul for suggesting deleting files one by one until the problem goes 
away, and to Andrey for pointing out `locale` and the LANG= setting.

Set LANG=en_US.UTF-8, e.g.
C:> set LANG=en_US.UTF-8
.. and the problem goes away.
C:> ls *.pdf
gòodbye.pdf
héllo.pdf
normal.pdf
C:> ls
gòodbye.pdf
héllo.pdf
normal.pdf

Interestingly, Andrey mentioned that he sets LANG=ru_RU.CP866 and he doesn't 
see the problem. When I tried that exact setting, I still had the problem.
So it's maybe not just that LANG must be set to *something*, but that somehow 
LANG must be set to something that matches something in Windows? (Sorry, I know 
that's nearly uselessly vague).


In summary, it appears that the way that the argv[] globbing code which gets 
compiled in to Cygwin programs functions a bit differently than the way the 
shell globbing code works within bash.exe.
And this produces unexpected globbing failures.


Thanks to all the Cygwin maintainers for this amazing software, for so many 
years!
-Jay




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