Re: Putting packages up for adoption

[Andrew Schulman via Cygwin-apps]

> On Apr  1 16:58, Yaakov Selkowitz wrote:
> > On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote:
> > > > 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.
> > 
> > While I appreciate the thought, please don't trouble yourself over
> > this.  A nicely polished "gold watch" will do just fine. :-)
> 
> Or a Pink plush watch, perhaps?
> 
> 
> Corinna

One pink plush watch! The only one ever made, I'm afraid. I had to travel to
Nepal to get it. So no one else will ever be able to get one.

https://cygwin.com/goldstars/#YS

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:

Hello Cygwin package maintainers,

To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.



I took hunspell and all the aspell-* hunspell-* packages

Regards
Marco

Re: Putting packages up for adoption

[Corinna Vinschen]

On Apr  1 16:58, Yaakov Selkowitz wrote:
> On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote:
> > > 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.
> 
> While I appreciate the thought, please don't trouble yourself over
> this.  A nicely polished "gold watch" will do just fine. :-)

Or a Pink plush watch, perhaps?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote:
> > 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.

While I appreciate the thought, please don't trouble yourself over
this.  A nicely polished "gold watch" will do just fine. :-)

--
Yaakov

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

First, I would like three packages to be added to cygwin-pkg-maint:
   - mingw64-i686-tcl-thread
   - mingw64-x86_64-tcl-thread
   - tcl-thread
This is meant for the Tcl-Tk "thread" extension.

Second, making my point, this time with proof.
Op di 24 mrt. 2020 om 20:27 schreef Jan Nijtmans:
> 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 ;-).

In the mingw32-xxx-tcl packages, loading the "registry" and "dde"
sub-packages doesn't work. The reason is the wrong setting of the
$auto_path variable, which is caused by the fedora patches:
tclsh86
% info nameofexecutable
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/bin/tclsh86.EXE
% package require registry
can't find package registry
% set auto_path
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib/tcl8.6
% set auto_path C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib
% package require registry
1.3.2
% package require dde
1.4.0
%

Of course, I will fix this in the next version.

Regards,
Jan Nijtmans

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Sat, 2020-03-28 at 04:33 +0100, Marco Atzeri wrote:
> Am 27.03.2020 um 21:52 schrieb Yaakov Selkowitz:
> > On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
> > > Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
> > > > On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> > > > > Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > > > I would suggest the following:
> > > > 
> > > > * python2-2.7.z continues to provide all '2' symlinks.
> > > > 
> > > > * python38 be updated to 3.8.2, and 3.8 be designated the next default
> > > > 'python3' version (with the '3' symlinks continued to be kept
> > > > separate), and adjust python-wheel.cygclass accordingly.
> > > > 
> > > > * Similarly, a separate package (in Fedora it's called 'python-
> > > > unversioned-command') provide unversioned symlinks, pointing to 2.7 for
> > > > now (for compatibility).
> > > > 
> > > > * Anything currently dependent on 'python' or 'python2' should either
> > > > be dropped if no longer needed, switched to 3 is possible, otherwise
> > > > rebuilt.
> > > > 
> > > > * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
> > > > only build those modules that are actually needed by other things by
> > > > specifying "all".
> > > > 
> > > > * Once that's done, look at what's still depending on /usr/bin/python
> > > > ('python-unversioned-command'), and based on that decide when that can
> > > > be changed to point to python3.
> > > > 
> > > > HTH,
> > > > 
> > > > --
> > > > Yaakov
> > > > 
> > > 
> > > The plan looks fine. Thanks for it
> > > 
> > > unfortunately I see unexpected segfault on the testsuite
> > > 
> > > 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
> > > 0:00:11 load avg: 1.58 [ 25/404] test_array
> > > 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> > > make: *** [Makefile:878: test] Segmentation fault (core dumped)
> > > 
> > > for both 2.7.17 and your original 2.7.16.
> > > 
> > > as I saw other segfault on other programs recently
> > > I assume that one of compiler/binutils/cygwin has some problem.
> > > 
> > > 3.8.2 seems to stall later in the test, so it is another issue.
> > 
> > In my experience, particularly on Cygwin, the first and most common
> > cause of testsuite errors are in the tests themselves.  While
> > eventually fixing these would certainly be welcome, I wouldn't block
> > progress thereon.  How does the saying go, "don't let perfection be the
> > enemy of the good"?
> > 
> > --
> > Yaakov
> > 
> 
> usually I follow the same rules, but a bit of investigation
> will be needed just to be sure.
> 
> Do you know a simple way to go on with the test or skip one ?

See https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec#_1051

> particular useful for 3.8.2
> 
> 6:14:06 load avg: 0.31 running: test_subprocess (6 hour 13 min), 
> test_asyncio (6 hour 11 min), test_asyncore (6 hour 10 min), test_ssl (6 
> hour 13 min)
> 6:14:36 load avg: 0.30 running: test_subprocess (6 hour 13 min), 
> test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6 
> hour 14 min)
> 6:15:06 load avg: 0.41 running: test_subprocess (6 hour 14 min), 
> test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6 
> hour 14 min)

--
Yaakov

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 27.03.2020 um 21:52 schrieb Yaakov Selkowitz:

On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:

Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:

On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:

I would suggest the following:

* python2-2.7.z continues to provide all '2' symlinks.

* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.

* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).

* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.

* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".

* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.

HTH,

--
Yaakov



The plan looks fine. Thanks for it

unfortunately I see unexpected segfault on the testsuite

0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)

for both 2.7.17 and your original 2.7.16.

as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.

3.8.2 seems to stall later in the test, so it is another issue.


In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves.  While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon.  How does the saying go, "don't let perfection be the
enemy of the good"?

--
Yaakov



usually I follow the same rules, but a bit of investigation
will be needed just to be sure.

Do you know a simple way to go on with the test or skip one ?

particular useful for 3.8.2

6:14:06 load avg: 0.31 running: test_subprocess (6 hour 13 min), 
test_asyncio (6 hour 11 min), test_asyncore (6 hour 10 min), test_ssl (6 
hour 13 min)
6:14:36 load avg: 0.30 running: test_subprocess (6 hour 13 min), 
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6 
hour 14 min)
6:15:06 load avg: 0.41 running: test_subprocess (6 hour 14 min), 
test_asyncio (6 hour 12 min), test_asyncore (6 hour 11 min), test_ssl (6 
hour 14 min)

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Fri, 2020-03-27 at 18:52 +0100, Marco Atzeri wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
> > On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> > > Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > I would suggest the following:
> > 
> > * python2-2.7.z continues to provide all '2' symlinks.
> > 
> > * python38 be updated to 3.8.2, and 3.8 be designated the next default
> > 'python3' version (with the '3' symlinks continued to be kept
> > separate), and adjust python-wheel.cygclass accordingly.
> > 
> > * Similarly, a separate package (in Fedora it's called 'python-
> > unversioned-command') provide unversioned symlinks, pointing to 2.7 for
> > now (for compatibility).
> > 
> > * Anything currently dependent on 'python' or 'python2' should either
> > be dropped if no longer needed, switched to 3 is possible, otherwise
> > rebuilt.
> > 
> > * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
> > only build those modules that are actually needed by other things by
> > specifying "all".
> > 
> > * Once that's done, look at what's still depending on /usr/bin/python
> > ('python-unversioned-command'), and based on that decide when that can
> > be changed to point to python3.
> > 
> > HTH,
> > 
> > --
> > Yaakov
> > 
> 
> The plan looks fine. Thanks for it
> 
> unfortunately I see unexpected segfault on the testsuite
> 
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
> 
> for both 2.7.17 and your original 2.7.16.
> 
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
> 
> 3.8.2 seems to stall later in the test, so it is another issue.

In my experience, particularly on Cygwin, the first and most common
cause of testsuite errors are in the tests themselves.  While
eventually fixing these would certainly be welcome, I wouldn't block
progress thereon.  How does the saying go, "don't let perfection be the
enemy of the good"?

--
Yaakov

Re: Putting packages up for adoption

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 27/03/2020 19:10, Yaakov Selkowitz wrote:
> On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin-
> apps wrote:
>> Out of interest, are you also adopting the modules for Python 2 and 3?
>> If not, or if you're not keen to adopt all of them, there are a few I'd
>> like to adopt (python-wx, python-bs4, and python-pip).
> At a minimum, it would probably be easier to coordinate new versions of
> Python if one person maintained all the Python versions together with
> at least python-setuptools, python-wheel, and python-pip, as those are
> the most basic requirements for building Python extensions.
>
> Someone else has expressed interest in python-wx; perhaps you can work
> together on it.
>
> --
> Yaakov

That makes sense.

I must have missed that. Who was it? I'm also interested in doing pylint
potentially, any reason why that was orphaned before?

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Fri, 2020-03-27 at 18:32 +, Hamish McIntyre-Bhatty via Cygwin-
apps wrote:
> Out of interest, are you also adopting the modules for Python 2 and 3?
> If not, or if you're not keen to adopt all of them, there are a few I'd
> like to adopt (python-wx, python-bs4, and python-pip).

At a minimum, it would probably be easier to coordinate new versions of
Python if one person maintained all the Python versions together with
at least python-setuptools, python-wheel, and python-pip, as those are
the most basic requirements for building Python extensions.

Someone else has expressed interest in python-wx; perhaps you can work
together on it.

--
Yaakov

Re: Putting packages up for adoption

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 27/03/2020 17:53, Marco Atzeri via Cygwin-apps wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
>> On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
>>> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
>
>> I would suggest the following:
>>
>> * python2-2.7.z continues to provide all '2' symlinks.
>>
>> * python38 be updated to 3.8.2, and 3.8 be designated the next default
>> 'python3' version (with the '3' symlinks continued to be kept
>> separate), and adjust python-wheel.cygclass accordingly.
>>
>> * Similarly, a separate package (in Fedora it's called 'python-
>> unversioned-command') provide unversioned symlinks, pointing to 2.7 for
>> now (for compatibility).
>>
>> * Anything currently dependent on 'python' or 'python2' should either
>> be dropped if no longer needed, switched to 3 is possible, otherwise
>> rebuilt.
>>
>> * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
>> only build those modules that are actually needed by other things by
>> specifying "all".
>>
>> * Once that's done, look at what's still depending on /usr/bin/python
>> ('python-unversioned-command'), and based on that decide when that can
>> be changed to point to python3.
>>
>> HTH,
>>
>> -- 
>> Yaakov
>>
>
> The plan looks fine. Thanks for it
>
> unfortunately I see unexpected segfault on the testsuite
>
> 0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle
> skipped
> 0:00:11 load avg: 1.58 [ 25/404] test_array
> 0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
> make: *** [Makefile:878: test] Segmentation fault (core dumped)
>
> for both 2.7.17 and your original 2.7.16.
>
> as I saw other segfault on other programs recently
> I assume that one of compiler/binutils/cygwin has some problem.
>
> 3.8.2 seems to stall later in the test, so it is another issue.
>
> Regards
> Marco

Marco,

Out of interest, are you also adopting the modules for Python 2 and 3?
If not, or if you're not keen to adopt all of them, there are a few I'd
like to adopt (python-wx, python-bs4, and python-pip).

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:

On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:



I would suggest the following:

* python2-2.7.z continues to provide all '2' symlinks.

* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.

* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).

* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.

* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".

* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.

HTH,

--
Yaakov



The plan looks fine. Thanks for it

unfortunately I see unexpected segfault on the testsuite

0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)

for both 2.7.17 and your original 2.7.16.

as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.

3.8.2 seems to stall later in the test, so it is another issue.

Regards
Marco

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:

On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:



I would suggest the following:

* python2-2.7.z continues to provide all '2' symlinks.

* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.

* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).

* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.

* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".

* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.

HTH,

--
Yaakov



The plan looks fine. Thanks for it

unfortunately I see unexpected segfault on the testsuite

0:00:03 load avg: 1.65 [ 24/404] test_argparse -- test_applesingle skipped
0:00:11 load avg: 1.58 [ 25/404] test_array
0:00:12 load avg: 1.58 [ 26/404] test_ascii_formatd
make: *** [Makefile:878: test] Segmentation fault (core dumped)

for both 2.7.17 and your original 2.7.16.

as I saw other segfault on other programs recently
I assume that one of compiler/binutils/cygwin has some problem.

3.8.2 seems to stall later in the test, so it is another issue.

Regards
Marco

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> 
> I am considering to take over python, and I am building 2.7.17 and 3.8.2
> to see how complicate it is.
> 
> One question on the cygport
> 
>  # see PEP 394
>  dosym python${slot}.exe /usr/bin/python
>  dosym python${slot}.exe /usr/bin/python2
> 
> do you see any problem to use alternatives for the same scope ?

The reason I avoided using alternatives for this was consistency. 
Since we don't build our packages in a clean (ch)root, if a maintainer
had such created such symlinks themselves, and they were to be picked
up during a build (very likely), or simply relied upon by scripts which
typically hardcode a generic version (very common), it would lead to a
package which would not run identically, or possibly not at all, on
other users' systems.  I would discourage using alternatives here.

Of course, in the meantime, the Python world has moved very strongly to
3.x, to the point that upstream has dropped it, Fedora has mostly
deprecated it, and /usr/bin/python is now a symlink to python3 provided
by a separate package.  However wrt Python 2, the only version we care
about at this point is 2.7, and while it's lifespan is limited, it is
still needed.

I would suggest the following:

* python2-2.7.z continues to provide all '2' symlinks.

* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.

* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).

* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.

* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".

* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.

HTH,

--
Yaakov

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:

Hello Cygwin package maintainers,





To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.



I am considering to take over python, and I am building 2.7.17 and 3.8.2
to see how complicate it is.

One question on the cygport

# see PEP 394
dosym python${slot}.exe /usr/bin/python
dosym python${slot}.exe /usr/bin/python2

do you see any problem to use alternatives for the same scope ?

Regards
Marco

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: 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: 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: Putting packages up for adoption

[Yaakov Selkowitz]

On Mon, 2020-03-23 at 22:04 +0100, Jan Nijtmans wrote:
> Op ma 23 mrt. 2020 om 16:45 schreef Yaakov Selkowitz:
> > The bulk of the patchset is from Fedora, but they haven't updated
> > recently either.
> 
> Hm. It appears that they did:
>  

I meant their mingw-tcl package.

--
Yaakov

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 23.03.2020 um 18:14 schrieb ASSI:

Achim Gratz writes:

I currently have that stack in evaluation (since Pango needs those).  It
looks like I have most or all of the needed development libraries in my
installation already.  If that also holds true for the rest of the Gtk2
modules I'll just take them all…  I'll look at Gtk3 and Gnome again
later, give me a few days.


OK, the last two of these finally pulled in some 40 or so libraries,
LOL.  It's OK for my current build machine, so you can hand over all
these perl-* packages to me.  I've already built and tested them all
(except Win32-GUI and SGMLSpm), I just need to clean them up properly
and prepare the maintenance stuff on my side.

There will be two new packages needed as test dependencies:

perl-Test-Fork
perl-Font-FreeType


Regards,
Achim.



Done.
All perl-* moved from Yaakov to you.

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op ma 23 mrt. 2020 om 16:45 schreef Yaakov Selkowitz:
> The bulk of the patchset is from Fedora, but they haven't updated
> recently either.

Hm. It appears that they did:
 

:-)

Regards,
 Jan Nijtmans

Re: Putting packages up for adoption

[ASSI]

Achim Gratz writes:
> I currently have that stack in evaluation (since Pango needs those).  It
> looks like I have most or all of the needed development libraries in my
> installation already.  If that also holds true for the rest of the Gtk2
> modules I'll just take them all…  I'll look at Gtk3 and Gnome again
> later, give me a few days.

OK, the last two of these finally pulled in some 40 or so libraries,
LOL.  It's OK for my current build machine, so you can hand over all
these perl-* packages to me.  I've already built and tested them all
(except Win32-GUI and SGMLSpm), I just need to clean them up properly
and prepare the maintenance stuff on my side.

There will be two new packages needed as test dependencies:

perl-Test-Fork
perl-Font-FreeType


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Mon, 2020-03-23 at 13:07 +0100, Jan Nijtmans wrote:
> Op zo 22 mrt. 2020 om 23:34 schreef Yaakov Selkowitz:
> > A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats
> > Cygwin as a Win32 platform, necessitating extensive patches to make it
> > comply with *NIX/X11 standards.  These patches CANNOT be dropped
> > without breaking compatibility, since Win32 and X11 APIs do not
> > interact.  Fortunately, Tcl/Tk moves rather slowly, so the existing
> > patches should serve you well for some time.
> 
> Yes, I'm aware of that. Of course, I'll be very careful to guarantee
> 100% binary compatibility.
> 
> Still, I have some questions. At first, I noted that the current Tcl
> version is 8.6.8, which is two patchlevels behind (released
> December 22, 2017, more than 3 years old, while 8.6.10
> is released November 21, 2019, 4 months ago).  Work to do!

It's only two patchlevels.  As I said, Tcl/Tk moves slowly.

> So, I tried starting with x86_64-w64-mingw32. Here are my remarks.
> 
> - There are 7 patches included. Only one of them applies cleanly,
>   the others are not really necessary (Please correct me if I'm wrong.
>   Let's go through them.

The bulk of the patchset is from Fedora, but they haven't updated
recently either.

>   - tcl-8.5.6-mingw.patch
> This one is wrong. Changing tools for cross-compilations should
> be done by "configure  ...  --host=x86_64-w64-mingw32"

You could try without it, it's not clear from the logs why it was
needed.

>   - tcl-8.6.1-nativezlib.patch
> OK. Tcl provides its own zlib.dll, in case it's not available externally.
> In Cygwin it is available (as "mingw64-x86_64-zlib"), which is prefered.
> (I added "cygautoreconf", so this patch would be part of "configure")
>   - tcl-8.6.3-autopath.patch
> Not necessary for building, Only needed when we want to run
> Tcl in a non-standard installed directory.

Keep in mind that the MinGW stuff can, and in some cases actually has
to, run from within the sysroot.  (On Linux, this is done with Wine,
but obviously we can just run them directly.)  Therefore, anything
needed for running properly should be left in.

>   - tcl-8.6.5-hidden.patch
> Wrong. This exports some internal symbols, which are not
> supposed to be exported at all.

This is done in Fedora for their Linux builds as well.  According to
the logs, expect uses (used?) these symbols.  Since my Cygwin builds
haven't carried the patch, maybe it's no longer needed, but I'd double-
check first.

>   - tcl-8-6-5-paralle-make-fix.patch
> Already fixed upstream. Besides, it's for unix/Makefile.in, not for mingw.

Probably just carried over from the native build patchset when first
created.

>   - tcl-mingw-w64-compatibility.patch
> Already fixed upstream:
> 

Ok.

>   - tcl-nativetclsh.patch
> Only needed when running Tcl, not for building the libraries

See above wrt keeping MinGW runnable.

> Further on, I noted the the resulting hints file contains:
> requires: tcl
> while I would expect:
> requires: mingw64-x86_64-zlib

You'll have to diagnose this one.

> Here is my cygport file so far.

HTH,

--
Yaakov

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op zo 22 mrt. 2020 om 23:34 schreef Yaakov Selkowitz:
> A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats
> Cygwin as a Win32 platform, necessitating extensive patches to make it
> comply with *NIX/X11 standards.  These patches CANNOT be dropped
> without breaking compatibility, since Win32 and X11 APIs do not
> interact.  Fortunately, Tcl/Tk moves rather slowly, so the existing
> patches should serve you well for some time.

Yes, I'm aware of that. Of course, I'll be very careful to guarantee
100% binary compatibility.

Still, I have some questions. At first, I noted that the current Tcl
version is 8.6.8, which is two patchlevels behind (released
December 22, 2017, more than 3 years old, while 8.6.10
is released November 21, 2019, 4 months ago).  Work to do!

So, I tried starting with x86_64-w64-mingw32. Here are my remarks.

- There are 7 patches included. Only one of them applies cleanly,
  the others are not really necessary (Please correct me if I'm wrong.
  Let's go through them.
  - tcl-8.5.6-mingw.patch
This one is wrong. Changing tools for cross-compilations should
be done by "configure  ...  --host=x86_64-w64-mingw32"
  - tcl-8.6.1-nativezlib.patch
OK. Tcl provides its own zlib.dll, in case it's not available externally.
In Cygwin it is available (as "mingw64-x86_64-zlib"), which is prefered.
(I added "cygautoreconf", so this patch would be part of "configure")
  - tcl-8.6.3-autopath.patch
Not necessary for building, Only needed when we want to run
Tcl in a non-standard installed directory.
  - tcl-8.6.5-hidden.patch
Wrong. This exports some internal symbols, which are not
supposed to be exported at all.
  - tcl-8-6-5-paralle-make-fix.patch
Already fixed upstream. Besides, it's for unix/Makefile.in, not for mingw.
  - tcl-mingw-w64-compatibility.patch
Already fixed upstream:

  - tcl-nativetclsh.patch
Only needed when running Tcl, not for building the libraries

Further on, I noted the the resulting hints file contains:
requires: tcl
while I would expect:
requires: mingw64-x86_64-zlib

Here is my cygport file so far.

Thanks for your feedback!

Regards,
  Jan Nijtmans


mingw64-x86_64-tcl.cygport
Description: Binary data

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Fri, 2020-03-20 at 10:29 +0100, Jan Nijtmans wrote:
> Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> 
> I'm willing to adopt the tcl-related packages:
> 
> mingw64-i686-tcl Yaakov Selkowitz
> mingw64-i686-tk  Yaakov Selkowitz
> mingw64-x86_64-tcl   Yaakov Selkowitz
> mingw64-x86_64-tkYaakov Selkowitz
> tcl  Yaakov Selkowitz
> tcl-itcl Yaakov Selkowitz
> tcl-itk  Yaakov Selkowitz
> tcl-iwidgets Yaakov Selkowitz
> tcl-tix  Yaakov Selkowitz
> tcl-tk   Yaakov Selkowitz
> tcl-togl Yaakov Selkowitz

A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats
Cygwin as a Win32 platform, necessitating extensive patches to make it
comply with *NIX/X11 standards.  These patches CANNOT be dropped
without breaking compatibility, since Win32 and X11 APIs do not
interact.  Fortunately, Tcl/Tk moves rather slowly, so the existing
patches should serve you well for some time.

--
Yaakov

Re: Putting packages up for adoption

[Achim Gratz]

Yaakov Selkowitz writes:
> Case sensitivity.  The modules depend on symbols both from other
> dependent modules as well as the C libraries which they bind.  While
> for many of the libraries these names are slightly different, e.g.
> -lPango and -lpango-1.0, in the case of Cairo, the only difference is
> case (-lCairo -lcairo).

I'd seen that and then dismissed it…

> FWIW I always ran Cygwin with case sensitivity
> on (except when Windows upgrades forcibly disabled that behind my
> back), as these issues are not infrequent particularly when building.

I'm running into it for the first time… :-)

> ExtUtils::Depends used to use full paths for the module imports, e.g.
> /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/
> -lPango, but I guess that changed at some point.  If building with case
> sensitivity enabled is not an option, then I suggest patching EU::D to
> use full paths for module imports again.

It uses the pkgconf system it would appear, so I've monkey-patched
cairo.pc accordingly.  Not sure what will be the final solution.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Sun, 2020-03-22 at 17:36 +0100, ASSI wrote:
> ASSI writes:
> > I see the same thing.  I have no idea why the linker doesn't pick up the
> > reference, but it produces exactly the same error when removing
> > "-lcairo" from the link list, which looks suspicious.
> 
> Indeed if I replace that library reference with "-l:libcairo.dll.a" then
> things work.  The other cairo-dependent modules seem to have the same
> problem.  Could anybody with some more knowledge of binutils than me
> explain why that happens and how to fix it?

Case sensitivity.  The modules depend on symbols both from other
dependent modules as well as the C libraries which they bind.  While
for many of the libraries these names are slightly different, e.g.
-lPango and -lpango-1.0, in the case of Cairo, the only difference is
case (-lCairo -lcairo).  FWIW I always ran Cygwin with case sensitivity
on (except when Windows upgrades forcibly disabled that behind my
back), as these issues are not infrequent particularly when building.

ExtUtils::Depends used to use full paths for the module imports, e.g.
/usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/
-lPango, but I guess that changed at some point.  If building with case
sensitivity enabled is not an option, then I suggest patching EU::D to
use full paths for module imports again.

HTH,

--
Yaakov

Re: Putting packages up for adoption

[Achim Gratz]

Marco Atzeri via Cygwin-apps writes:
> I am planning to update all the packages left behind
> by the Perl update
> (Except if Achim is interested in them)
>
> perl-Glib  already built  
> perl-Cairo
> perl-Gtk2 
> perl-Pango

I currently have that stack in evaluation (since Pango needs those).  It
looks like I have most or all of the needed development libraries in my
installation already.  If that also holds true for the rest of the Gtk2
modules I'll just take them all…  I'll look at Gtk3 and Gnome again
later, give me a few days.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Putting packages up for adoption

[ASSI]

ASSI writes:
> I see the same thing.  I have no idea why the linker doesn't pick up the
> reference, but it produces exactly the same error when removing
> "-lcairo" from the link list, which looks suspicious.

Indeed if I replace that library reference with "-l:libcairo.dll.a" then
things work.  The other cairo-dependent modules seem to have the same
problem.  Could anybody with some more knowledge of binutils than me
explain why that happens and how to fix it?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Putting packages up for adoption

[ASSI]

Marco Atzeri via Cygwin-apps writes:
> I already built
>
> perl-GLIB
> perl-Cairo

Yes, these are easy to build, I've even had the devel packages already 
installed.

> but perl-Pango is failing
>
> [ LD blib/arch/auto/Pango/Pango.dll ]
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> xs/PangoCairo.o: in function
> `gtk2perl_pango_cairo_shape_renderer_func':
> /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44: undefined
> reference to `cairo_reference'
> /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44:(.text+0x21e):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `cairo_reference'
>
> for what I see cairo_reference is in /usr/lib/libcairo.dll.a
> So I am blocked and you can take over

I see the same thing.  I have no idea why the linker doesn't pick up the
reference, but it produces exactly the same error when removing
"-lcairo" from the link list, which looks suspicious.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Putting packages up for adoption

[Jon Turney]

On 20/03/2020 16:17, Doug Henderson via Cygwin-apps wrote:

On Thu, 19 Mar 2020 at 22:03, Yaakov Selkowitz <> wrote:


Hello Cygwin package maintainers,



To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.





I will pickup the mingw64-i686-expat and mingw64-x86_64-expat packages, as
I currently maintain the expat package


Done.

Thanks.

Re: Putting packages up for adoption

[Jon Turney]

On 21/03/2020 12:47, Thomas Wolff wrote:

Am 20.03.2020 um 13:09 schrieb Jon Turney:

On 20/03/2020 03: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.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.


It's been a pleasure working with you (since 2008!).  Thanks for all 
your hard work over the years!


I will volunteer to adopt the X.org packages (note by this I really 
mean stuff that comes from X.org, it doesn't include toolkits like Qt 
or GTK+, or desktop environments like MATE or XFCE)
I can offer to adopt xterm, unicode-ucd and 
unicode-cldr-emoji-annotation, generalizing the latter to unicode-cldr.

Thomas


I moved maintainership of those packages to you.

I guess unicode-cldr also needs adding, obsoleting 
unicode-cldr-emoji-annotation, but we can discuss that when you are 
ready to upload.


Thanks.

Re: Putting packages up for adoption

[Thomas Wolff]

Am 20.03.2020 um 13:09 schrieb Jon Turney:

On 20/03/2020 03: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.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.


It's been a pleasure working with you (since 2008!).  Thanks for all 
your hard work over the years!


I will volunteer to adopt the X.org packages (note by this I really 
mean stuff that comes from X.org, it doesn't include toolkits like Qt 
or GTK+, or desktop environments like MATE or XFCE)
I can offer to adopt xterm, unicode-ucd and 
unicode-cldr-emoji-annotation, generalizing the latter to unicode-cldr.

Thomas

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03.2020 um 18:32 schrieb Achim Gratz:

Marco Atzeri via Cygwin-apps writes:

I am planning to update all the packages left behind
by the Perl update
(Except if Achim is interested in them)


I can take them unless they pull in a huge stack of dependencies I don't
already have anyway.  Again I think that rules out the Gtk/Gnome stuff.
I know next to nothing about Wx, I think the dependency chain is
manageable, but I haven't looked at what testing the distribution
entails.  I think I have built SGMLSpm in the past locally, I have to
check.



I already built

perl-GLIB
perl-Cairo

you can find them here
http://matzeri.altervista.org/x86/release/
http://matzeri.altervista.org/x86_64/release/

but perl-Pango is failing

[ LD blib/arch/auto/Pango/Pango.dll ]
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
xs/PangoCairo.o: in function `gtk2perl_pango_cairo_shape_renderer_func':
/usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44: undefined 
reference to `cairo_reference'
/usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44:(.text+0x21e): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`cairo_reference'


for what I see cairo_reference is in /usr/lib/libcairo.dll.a
So I am blocked and you can take over

Regards
Marco

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Fri, 2020-03-20 at 18:32 +0100, Achim Gratz wrote:
> Marco Atzeri via Cygwin-apps writes:
> > I am planning to update all the packages left behind
> > by the Perl update
> > (Except if Achim is interested in them)
> 
> I can take them unless they pull in a huge stack of dependencies I don't
> already have anyway.  Again I think that rules out the Gtk/Gnome stuff.
> I know next to nothing about Wx, I think the dependency chain is
> manageable, but I haven't looked at what testing the distribution
> entails.  I think I have built SGMLSpm in the past locally, I have to
> check.

Wx is a binding on wxWidgets3.0, which is GTK+ based, so if you don't
want Gtk2 et al you probably don't want that either.

SGMLSpm is standalone and straight-forward.

> > perl-GD  Already Updated
> > perl-Glibalready built  
> > 
> > perl-Alien-wxWidgets
> > perl-Cairo  
> > perl-Cairo-GObject  
> > perl-GStreamer1 
> > perl-Glib-Object-Introspection  
> > perl-Gnome2 
> > perl-Gnome2-Canvas  
> > perl-Gnome2-GConf   
> > perl-Gnome2-Rsvg
> > perl-Gnome2-VFS 
> > perl-Gnome2-Vte 
> > perl-Gnome2-Wnck
> > perl-Gtk2   
> > perl-Gtk2-GladeXML  
> > perl-Gtk2-Notify
> > perl-Gtk2-SourceView2   
> > perl-Gtk2-Spell 
> > perl-Gtk2-Unique
> > perl-Gtk2-WebKit
> > perl-Gtk3   
> > perl-Pango  
> > perl-SGMLSpm
> > perl-Wx 
> > 
> > perl-Win32-GUI Do we need it ?
> 
> The last time we tried to drop it there was a complaint IIRC.  I have no
> idea if it still works, I thihnk it needs a few pretty invasive patches
> (from memory, which may be wrong).  I have built myself before, but then
> it broke and Yaakov made it work again so I'm not really sure what to do
> about it.  It doesn't really fit in with what Cygwin tries to do (IIRC
> it comes from Strawberry Perl, which is Windows native).

I'd have to go back and look as to why it was wanted/needed.  I'd say
if it still builds and works with my changes, then ship it, if not,
either let someone else pick it up, or drop it.

--
Yaakov

Re: Putting packages up for adoption

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 20/03/2020 17:32, Achim Gratz wrote:
> Marco Atzeri via Cygwin-apps writes:
>> I am planning to update all the packages left behind
>> by the Perl update
>> (Except if Achim is interested in them)
> I can take them unless they pull in a huge stack of dependencies I don't
> already have anyway.  Again I think that rules out the Gtk/Gnome stuff.
> I know next to nothing about Wx, I think the dependency chain is
> manageable, but I haven't looked at what testing the distribution
> entails.  I think I have built SGMLSpm in the past locally, I have to
> check.
>
>> perl-GD   Already Updated
>> perl-Glib already built  
>>
>> perl-Alien-wxWidgets 
>> perl-Cairo   
>> perl-Cairo-GObject   
>> perl-GStreamer1  
>> perl-Glib-Object-Introspection   
>> perl-Gnome2  
>> perl-Gnome2-Canvas   
>> perl-Gnome2-GConf
>> perl-Gnome2-Rsvg 
>> perl-Gnome2-VFS  
>> perl-Gnome2-Vte  
>> perl-Gnome2-Wnck 
>> perl-Gtk2
>> perl-Gtk2-GladeXML   
>> perl-Gtk2-Notify 
>> perl-Gtk2-SourceView2
>> perl-Gtk2-Spell  
>> perl-Gtk2-Unique 
>> perl-Gtk2-WebKit 
>> perl-Gtk3
>> perl-Pango   
>> perl-SGMLSpm 
>> perl-Wx  
>>
>>
>> perl-Win32-GUI  Do we need it ?
> The last time we tried to drop it there was a complaint IIRC.  I have no
> idea if it still works, I thihnk it needs a few pretty invasive patches
> (from memory, which may be wrong).  I have built myself before, but then
> it broke and Yaakov made it work again so I'm not really sure what to do
> about it.  It doesn't really fit in with what Cygwin tries to do (IIRC
> it comes from Strawberry Perl, which is Windows native).
>
>
> Regards,
> Achim.

Note: I forgot to say, but I'm happy to do wxwidgets as well.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Putting packages up for adoption

[Achim Gratz]

Marco Atzeri via Cygwin-apps writes:
> I am planning to update all the packages left behind
> by the Perl update
> (Except if Achim is interested in them)

I can take them unless they pull in a huge stack of dependencies I don't
already have anyway.  Again I think that rules out the Gtk/Gnome stuff.
I know next to nothing about Wx, I think the dependency chain is
manageable, but I haven't looked at what testing the distribution
entails.  I think I have built SGMLSpm in the past locally, I have to
check.

> perl-GDAlready Updated
> perl-Glib  already built  
>
> perl-Alien-wxWidgets  
> perl-Cairo
> perl-Cairo-GObject
> perl-GStreamer1   
> perl-Glib-Object-Introspection
> perl-Gnome2   
> perl-Gnome2-Canvas
> perl-Gnome2-GConf 
> perl-Gnome2-Rsvg  
> perl-Gnome2-VFS   
> perl-Gnome2-Vte   
> perl-Gnome2-Wnck  
> perl-Gtk2 
> perl-Gtk2-GladeXML
> perl-Gtk2-Notify  
> perl-Gtk2-SourceView2 
> perl-Gtk2-Spell   
> perl-Gtk2-Unique  
> perl-Gtk2-WebKit  
> perl-Gtk3 
> perl-Pango
> perl-SGMLSpm  
> perl-Wx   
>
>
> perl-Win32-GUI   Do we need it ?

The last time we tried to drop it there was a complaint IIRC.  I have no
idea if it still works, I thihnk it needs a few pretty invasive patches
(from memory, which may be wrong).  I have built myself before, but then
it broke and Yaakov made it work again so I'm not really sure what to do
about it.  It doesn't really fit in with what Cygwin tries to do (IIRC
it comes from Strawberry Perl, which is Windows native).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Putting packages up for adoption

[Doug Henderson via Cygwin-apps]

On Thu, 19 Mar 2020 at 22:03, Yaakov Selkowitz <> wrote:

> Hello Cygwin package maintainers,
>
> 
>
> To that end, in the best interest of the community, please consider my
> packages up for adoption.  I don't expect that any one person will take
> all of them; some are obsolete and due for removal anyway, some should
> be picked up as soon as possible, and others might just end up
> bitrotting if nobody is interested in them.  However, in whatever there
> is interest (or need), hopefully what is there now will serve as a
> strong foundation to on which to continue to build.
>


> 
>

I will pickup the mingw64-i686-expat and mingw64-x86_64-expat packages, as
I currently maintain the expat package

Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:

Hello Cygwin package maintainers,





To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.



I am planning to update all the packages left behind
by the Perl update
(Except if Achim is interested in them)

perl-GD  Already Updated
perl-Glibalready built  

perl-Alien-wxWidgets
perl-Cairo  
perl-Cairo-GObject  
perl-GStreamer1 
perl-Glib-Object-Introspection  
perl-Gnome2 
perl-Gnome2-Canvas  
perl-Gnome2-GConf   
perl-Gnome2-Rsvg
perl-Gnome2-VFS 
perl-Gnome2-Vte 
perl-Gnome2-Wnck
perl-Gtk2   
perl-Gtk2-GladeXML  
perl-Gtk2-Notify
perl-Gtk2-SourceView2   
perl-Gtk2-Spell 
perl-Gtk2-Unique
perl-Gtk2-WebKit
perl-Gtk3   
perl-Pango  
perl-SGMLSpm
perl-Wx 


perl-Win32-GUI Do we need it ?

Re: Putting packages up for adoption

[Jon Turney]

On 20/03/2020 10:19, Corinna Vinschen wrote:


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.


So what you are saying is a Pink Plush Hippo Kaiju? :)

Re: Putting packages up for adoption

[Jon Turney]

On 20/03/2020 03: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.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.


It's been a pleasure working with you (since 2008!).  Thanks for all 
your hard work over the years!


I will volunteer to adopt the X.org packages (note by this I really mean 
stuff that comes from X.org, it doesn't include toolkits like Qt or 
GTK+, or desktop environments like MATE or XFCE)


I'll also volunteer to take over maintainership of cygport, if you don't 
have other plans for that.

Re: Putting packages up for adoption

[Corinna Vinschen]

On Mar 20 06:04, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > Hello Cygwin package maintainers,
> > [...]
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> > [...]
> > Yaakov
> > 
> 
> Hi Yaakov,
> thanks of letting us know.
> I guess that most of us clearly understood that work took over
> and as you have clearly a talent to make stuff work together
> I am not surprised that Redhat is using that to full speed.
> 
> So Long, and Thanks for All the Fish
> Marco
> 
> PS for all the others:
> "Houston we have a problem.."

The understatement of the year :}


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Corinna Vinschen]

On Mar 20 10:29, Jan Nijtmans via Cygwin-apps wrote:
> Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> 
> 
> I'm willing to adopt the tcl-related packages:
> 
> mingw64-i686-tcl Yaakov Selkowitz
> mingw64-i686-tk  Yaakov Selkowitz
> mingw64-x86_64-tcl   Yaakov Selkowitz
> mingw64-x86_64-tkYaakov Selkowitz
> tcl  Yaakov Selkowitz
> tcl-itcl Yaakov Selkowitz
> tcl-itk  Yaakov Selkowitz
> tcl-iwidgets Yaakov Selkowitz
> tcl-tix  Yaakov Selkowitz
> tcl-tk   Yaakov Selkowitz
> tcl-togl Yaakov Selkowitz
> 
> And - since I'm already maintaining SQLite, I can do the mingw64 variants
> of SQLite too:
> mingw64-i686-sqlite3 Yaakov Selkowitz
> mingw64-x86_64-sqlite3   Yaakov Selkowitz
> 
> In one month or so, Tcl 8.6.11 is expected, then I'll try to get the
> first builds going (assuming my contribution is accepted)
> 
> Regards,
>  Jan Nijtmans

Thanks for volunteering!  I changed the above package maintainerships
in cygwin-pkg-main accordingly.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Corinna Vinschen]

On Mar 20 07:05, ASSI wrote:
> Marco Atzeri via Cygwin-apps writes:
> > "Houston we have a problem.."
> >
> >  82  Achim Gratz/Yaakov Selkowitz
> 
> I'm up for taking sole ownership of any co-maint packages I've had
> together with Yaakov.  I'll look into what other packages I might
> be able to maintain.

I changed that in cygwin-pkg-maint.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Corinna Vinschen]

On Mar 19 23:47, Yaakov Selkowitz wrote:
> Hello Cygwin package maintainers,
> 
> As you all probably noted, I haven't been around much.  My team at work
> has been really busy accomplishing some pretty amazing feats over the
> last number of months, most recently:
> 
> https://www.ibm.com/blogs/systems/red-hat-openshift-now-available-ibm-z-linuxone/
> 
> While it's been great for my career, it obviously hasn't been so good
> for you and the community as a whole, as I've really had absolutely no
> time to work on Cygwin packaging.  In fact, I've barely used my Windows
> machine and VMs at all for quite some time.  And to be completely
> honest, it really doesn't look like that's going to change anytime soon
> either.
> 
> To that end, in the best interest of the community, please consider my
> packages up for adoption.  I don't expect that any one person will take
> all of them; some are obsolete and due for removal anyway, some should
> be picked up as soon as possible, and others might just end up
> bitrotting if nobody is interested in them.  However, in whatever there
> is interest (or need), hopefully what is there now will serve as a
> strong foundation to on which to continue to build.
> 
> (And just to be perfectly clear, we're all in good health; this has
> nothing to do with the current crisis, except that maybe some of you
> have more time at home now to use to the benefit of Cygwin.)
> 
> I'll continue lurking on the lists, and with this burden off my
> shoulders, try to transition to being a little more active as a mentor.
> So, please feel free to ask questions (on list, please), particularly
> if you don't understand why I did something in my packaging.  There is
> (or at least was at the time!) a good reason for all of it, even though
> I often neglected to document why.  I'll try to do what I can to make
> this as smooth as possible.
> 
> All the best, stay safe, and keep on building!
> 
> --
> 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.

Thanks for everything you did for Cygwin!

There's just one problem.  What happens to your packages which are not
upstream packages but Cygwin-specific?  Especially cygport comes to
mind.  Off the top of my head I don't know which other packages fall
into that category.

However, for these packages, we should ideally move them from your
cygwinports github repo to cygwin.com, right?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Jan Nijtmans via Cygwin-apps]

Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz:
> To that end, in the best interest of the community, please consider my
> packages up for adoption.  I don't expect that any one person will take
> all of them; some are obsolete and due for removal anyway, some should
> be picked up as soon as possible, and others might just end up
> bitrotting if nobody is interested in them.  However, in whatever there
> is interest (or need), hopefully what is there now will serve as a
> strong foundation to on which to continue to build.


I'm willing to adopt the tcl-related packages:

mingw64-i686-tcl Yaakov Selkowitz
mingw64-i686-tk  Yaakov Selkowitz
mingw64-x86_64-tcl   Yaakov Selkowitz
mingw64-x86_64-tkYaakov Selkowitz
tcl  Yaakov Selkowitz
tcl-itcl Yaakov Selkowitz
tcl-itk  Yaakov Selkowitz
tcl-iwidgets Yaakov Selkowitz
tcl-tix  Yaakov Selkowitz
tcl-tk   Yaakov Selkowitz
tcl-togl Yaakov Selkowitz

And - since I'm already maintaining SQLite, I can do the mingw64 variants
of SQLite too:
mingw64-i686-sqlite3 Yaakov Selkowitz
mingw64-x86_64-sqlite3   Yaakov Selkowitz

In one month or so, Tcl 8.6.11 is expected, then I'll try to get the
first builds going (assuming my contribution is accepted)

Regards,
 Jan Nijtmans

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03. um 09:13 schrieb Hamish McIntyre-Bhatty via Cygwin-apps:

If no one objects, I'd be happy to become a maintainer for the wxPython
and ddrescue packages. There are probably others I could pick up as
well, but I figure it's best to start small.

I'm not sure if there's a process for becoming a maintainer, but as a
result of my using Cygwin on and off for a few years, I think I have a
reasonably good idea of how it works, so I'd be happy to help. Cygwin is
a great project and has been very useful for me and many other people.

Hamish



Hi Hamish,
bottom post on cygwin list, please.

I suggest you to read the
https://cygwin.com/packaging-contributors-guide.html
and start looking at the source of the cygwin packages
you would like to adopt as easy way to take over.
Most of the time it is just a matter of changing the package version
and download the upstream source and build it.
If you have problem feel free to ask here.

When your package is ready, just send a ITA (intention to adopt)
instead of a ITP (intention to package) and some of the
other maintainers will review your package.
After GTG (good to go) we will put your name on

 https://www.cygwin.com/cygwin-pkg-maint

and you can upload the package.

Regards
Marco

Re: Putting packages up for adoption

[Hamish McIntyre-Bhatty via Cygwin-apps]

If no one objects, I'd be happy to become a maintainer for the wxPython
and ddrescue packages. There are probably others I could pick up as
well, but I figure it's best to start small.

I'm not sure if there's a process for becoming a maintainer, but as a
result of my using Cygwin on and off for a few years, I think I have a
reasonably good idea of how it works, so I'd be happy to help. Cygwin is
a great project and has been very useful for me and many other people.

Hamish

On 20/03/2020 03:47, Yaakov Selkowitz wrote:
> Hello Cygwin package maintainers,
>
> As you all probably noted, I haven't been around much.  My team at work
> has been really busy accomplishing some pretty amazing feats over the
> last number of months, most recently:
>
> https://www.ibm.com/blogs/systems/red-hat-openshift-now-available-ibm-z-linuxone/
>
> While it's been great for my career, it obviously hasn't been so good
> for you and the community as a whole, as I've really had absolutely no
> time to work on Cygwin packaging.  In fact, I've barely used my Windows
> machine and VMs at all for quite some time.  And to be completely
> honest, it really doesn't look like that's going to change anytime soon
> either.
>
> To that end, in the best interest of the community, please consider my
> packages up for adoption.  I don't expect that any one person will take
> all of them; some are obsolete and due for removal anyway, some should
> be picked up as soon as possible, and others might just end up
> bitrotting if nobody is interested in them.  However, in whatever there
> is interest (or need), hopefully what is there now will serve as a
> strong foundation to on which to continue to build.
>
> (And just to be perfectly clear, we're all in good health; this has
> nothing to do with the current crisis, except that maybe some of you
> have more time at home now to use to the benefit of Cygwin.)
>
> I'll continue lurking on the lists, and with this burden off my
> shoulders, try to transition to being a little more active as a mentor.
> So, please feel free to ask questions (on list, please), particularly
> if you don't understand why I did something in my packaging.  There is
> (or at least was at the time!) a good reason for all of it, even though
> I often neglected to document why.  I'll try to do what I can to make
> this as smooth as possible.
>
> All the best, stay safe, and keep on building!
>
> --
> Yaakov
>
>


0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Putting packages up for adoption

[ASSI]

Marco Atzeri via Cygwin-apps writes:
> "Houston we have a problem.."
>
>  82  Achim Gratz/Yaakov Selkowitz

I'm up for taking sole ownership of any co-maint packages I've had
together with Yaakov.  I'll look into what other packages I might
be able to maintain.

The bulk of the newly orphaned packages probably belong to GNOME and KDE
and I'm not set up for even compiling those at the moment plus I usually
don't use even X11 on Cygwin.  The desktop environments would really
benefit from having their own maintainer that is also an active user,
preferrably someone that also has ties into the upstream community.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Putting packages up for adoption

[Marco Atzeri via Cygwin-apps]

Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:

Hello Cygwin package maintainers,

As you all probably noted, I haven't been around much.  My team at work
has been really busy accomplishing some pretty amazing feats over the
last number of months, most recently:

https://www.ibm.com/blogs/systems/red-hat-openshift-now-available-ibm-z-linuxone/

While it's been great for my career, it obviously hasn't been so good
for you and the community as a whole, as I've really had absolutely no
time to work on Cygwin packaging.  In fact, I've barely used my Windows
machine and VMs at all for quite some time.  And to be completely
honest, it really doesn't look like that's going to change anytime soon
either.

To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.

(And just to be perfectly clear, we're all in good health; this has
nothing to do with the current crisis, except that maybe some of you
have more time at home now to use to the benefit of Cygwin.)

I'll continue lurking on the lists, and with this burden off my
shoulders, try to transition to being a little more active as a mentor.
So, please feel free to ask questions (on list, please), particularly
if you don't understand why I did something in my packaging.  There is
(or at least was at the time!) a good reason for all of it, even though
I often neglected to document why.  I'll try to do what I can to make
this as smooth as possible.

All the best, stay safe, and keep on building!

--
Yaakov



Hi Yaakov,
thanks of letting us know.
I guess that most of us clearly understood that work took over
and as you have clearly a talent to make stuff work together
I am not surprised that Redhat is using that to full speed.

So Long, and Thanks for All the Fish
Marco

PS for all the others:
"Houston we have a problem.."

$ awk '{$1="" ; print }' cygwin-pkg-maint  | sort  | uniq -c |sort -rn
   2691  Yaakov Selkowitz
244  Achim Gratz
165  Marco Atzeri
162  Jari Aalto
140  ORPHANED (Yaakov Selkowitz)
 95  Ken Brown
 82  Achim Gratz/Yaakov Selkowitz
 47  Achim Gratz/Ken Brown
 42  ORPHANED (Dr. Volker Zell)
 33  Corinna Vinschen
 29  Jon Turney
 28  Andrew Schulman
 22  ORPHANED (David Stacey)
 22  Jonathan Yong
 21  Eric Blake
 18  David Rothenberger
  9  ORPHANED
  8  ORPHANED (Charles Wilson)
  8  Christian Franke