Putting packages up for adoption

Putting packages up for adoption

[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

Re: Putting packages up for adoption

[Marco Atzeri]

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

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

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 2485 bytes --]

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

[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

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

Re: Putting packages up for adoption

[Marco Atzeri]

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

[Jan Nijtmans]

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

[Corinna Vinschen]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting packages up for adoption

[Corinna Vinschen]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting packages up for adoption

[Corinna Vinschen]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting packages up for adoption

[Corinna Vinschen]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[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

[Marco Atzeri]

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

Re: Putting packages up for adoption

[Doug Henderson]

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

> Hello Cygwin package maintainers,
>
> <snip>
>
> 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.
>


> <snip>
>

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

[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-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.
-- 
+<[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

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 1735 bytes --]

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


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

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

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

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

[Marco Atzeri]

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

[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

[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

[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,
>>
>> <snip>
>>
>> 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.
>> 
>> <snip>
>>
> 
> 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

[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

[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

[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

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

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

[Jan Nijtmans]

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

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:
<https://core.tcl-lang.org/tcl/info/8fbf108ea77e5351>
  - 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

[-- Attachment #2: mingw64-x86_64-tcl.cygport --]
[-- Type: application/octet-stream, Size: 2085 bytes --]

CROSS_HOST="x86_64-w64-mingw32"
inherit cross

NAME="mingw64-x86_64-tcl"
VERSION=8.6.10
RELEASE=1
CATEGORY="Devel"
SUMMARY="Tcl interpreter for Win64 toolchain"
DEPEND="mingw64-x86_64-zlib"
DESCRIPTION="This package does NOT contain cygwin binaries.  Instead, it
contains msvcrt-linked binaries (aka 'mingw').  It is for use with the
mingw64-x86_64-gcc cross compiler, and installs into the
/usr/x86_64-w64-mingw32/sys-root/mingw/{lib,include} directories."
HOMEPAGE="https://www.tcl.tk/"
SRC_URI="mirror://sourceforge/tcl/tcl-core${VERSION}-src.tar.gz"
SRC_DIR="tcl${VERSION}"
#http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-8.6.3-autopath.patch
#	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-8.6.5-hidden.patch
#	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-8.6.5-parallel-make-fix.patch
#	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-8.5.6-mingw.patch
#	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-nativetclsh.patch
#	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-mingw-w64-compatibility.patch
PATCH_URI="
	http://pkgs.fedoraproject.org/cgit/rpms/mingw-tcl.git/plain/tcl-8.6.1-nativezlib.patch
"

DIFF_EXCLUDES="Makefile tcl.hpj tclConfig.sh"

slot=${PV_MAJ_MIN}

src_compile() {
	lndirs
	cd ${B}/win
	cygautoreconf
	cygconf --enable-64bit --host=x86_64-w64-mingw32
	cygmake -j1 CYGPATH=echo
}

src_install() {
	cd ${B}/win
	USE_DESTDIR=0
	cyginstall

	rm -f ${D}${CROSS_BINDIR}/zlib1.dll

	sed -i \
		-e "s|^\(TCL_BUILD_LIB_SPEC\)='.*|\1='-Wl,${CROSS_LIBDIR}/libtcl${slot//.}.a'|" \
		-e "s|^\(TCL_SRC_DIR\)='.*'|\1='${CROSS_INCLUDEDIR}/tcl${slot}'|" \
		-e "s|^\(TCL_BUILD_STUB_LIB_SPEC\)='.*|\1='-Wl,${CROSS_LIBDIR}/libtclstub${slot//.}.a'|" \
		-e "s|^\(TCL_BUILD_STUB_LIB_PATH\)='.*/win|\1='${CROSS_LIBDIR}|" \
		-e "s|^\(TCL_STUB_LIB_SPEC\)='.*|\1='-Wl,-ltclstub${slot//.}'|" \
		${D}${CROSS_LIBDIR}/tclConfig.sh || error

	# install private headers
	includeinto tcl${slot}/win
	doinclude ${S}/win/*.h
	includeinto tcl${slot}/generic
	doinclude ${S}/generic/*.h
}

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:
> <https://core.tcl-lang.org/tcl/info/8fbf108ea77e5351>

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

[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

[Jan Nijtmans]

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:
     <https://src.fedoraproject.org/rpms/tcl/tree/master>

:-)

Regards,
     Jan Nijtmans

Re: Putting packages up for adoption

[Marco Atzeri]

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

[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:
>      <https://src.fedoraproject.org/rpms/tcl/tree/master>

I meant their mingw-tcl package.

--
Yaakov

Re: Putting packages up for adoption

[Jan Nijtmans]

Op di 24 mrt. 2020 om 00:38 schreef Yaakov Selkowitz:
> > Hm. It appears that they did:
> >      <https://src.fedoraproject.org/rpms/tcl/tree/master>
>
> 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:
     <https://travis-ci.org/github/tcltk/tcl/builds/666214831>

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 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:
> > >      <https://src.fedoraproject.org/rpms/tcl/tree/master>
> > 
> > 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:
>      <https://travis-ci.org/github/tcltk/tcl/builds/666214831>

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]

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:
> >      <https://travis-ci.org/github/tcltk/tcl/builds/666214831>
>
> 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 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:
> > >      <https://travis-ci.org/github/tcltk/tcl/builds/666214831>
> > 
> > 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]

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

[Andrew Schulman]

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

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

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

[Marco Atzeri]

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

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

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]

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

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 2138 bytes --]

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


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

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

Re: Putting packages up for adoption

[Yaakov Selkowitz]

On Fri, 2020-03-27 at 18:32 +0000, 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]

[-- Attachment #1.1.1: Type: text/plain, Size: 908 bytes --]

On 27/03/2020 19:10, Yaakov Selkowitz wrote:
> On Fri, 2020-03-27 at 18:32 +0000, 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


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

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

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

[Marco Atzeri]

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

[Jan Nijtmans]

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 Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote:
> > On Mar 19 23:47, Yaakov Selkowitz wrote:
> > > Hello Cygwin package maintainers,
> <snip> 
> > > To that end, in the best interest of the community, please consider my
> > > packages up for adoption. 
> <snip>
> > > 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

[Corinna Vinschen]

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

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,
> > <snip> 
> > > > To that end, in the best interest of the community, please consider my
> > > > packages up for adoption. 
> > <snip>
> > > > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting packages up for adoption

[Marco Atzeri]

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

Python - plan & execution

[Marco Atzeri]

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
> 

first steps done:
- updated 3.8 to 3.8.2
- updated 3.7 to 3.7.7
- updated also their python doc
- upload of all of them is in progress

next steps:
- I assume we can drop 3.5
- for the time being no need to update 2.7 and 3.6
   (we are just one version behind)

- verify which python packages we need to build/rebuild

currently we have

119 *python27*
114 *python36*
115 *python37*
10  *python38*

and ~ 225 other *python* packages (plus 10 for python35)

- verify the fedora python-unversioned-command


Regards
Marco

Re: Python - plan & execution

[Yaakov Selkowitz]

On Fri, 2020-04-10 at 14:52 +0200, 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.
> 
> first steps done:
> - updated 3.8 to 3.8.2
> - updated 3.7 to 3.7.7
> - updated also their python doc
> - upload of all of them is in progress

Didn't think of it earlier, but how about updating python3 (the major-
version symlinks) to 3.8 as a test: release now?  That should help
maintainers start the move without breaking the world for everybody
else.  Posted this to a branch to help:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python3.git;a=commitdiff;h=772172be59111366ece38aebb1ea876322bfdd2f

> next steps:
> - I assume we can drop 3.5

Your call, it's still supported upstream for almost 5 more months.  I
wouldn't build anything python35-* except for
setuptools/pip/wheel/virtualenv.

> - for the time being no need to update 2.7 and 3.6
>    (we are just one version behind)

There's now a 2.7.18, we should probably pick that up, as it has the
final upstream fixes.  After that, it's time to start moving to 3.8 en
masse.

> - verify which python packages we need to build/rebuild
> 
> currently we have
> 
> 119 *python27*

These are fine as is, but they also don't need to be rebuilt or updated
any more.

> 114 *python36*
> 115 *python37*
> 10  *python38*

We don't need to _obsolete or remove python3[67]-* packages, we just
need to track how many don't have python38-* equivalents yet. 
Obviously that's still the vast majority, since 3.8 just got updated to
a stable version.

Jon Turney, if a python-foo source package was previously building e.g.
python27-foo, python36-foo, and python37-foo, and now starts building
only python37-foo and python38-foo, is calm going to complain?

> and ~ 225 other *python* packages (plus 10 for python35)

There are a lot of _obsolete python-*, python2-*, and python3-*
"packages" which we don't need to count.  How many of those names are
NOT _obsolete?

> - verify the fedora python-unversioned-command

This is the last step.

--
Yaakov

Re: Python - plan & execution

[Jon Turney]

On 23/04/2020 22:54, Yaakov Selkowitz wrote:
> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>
>> currently we have
>>
>> 119 *python27*
> 
> These are fine as is, but they also don't need to be rebuilt or updated
> any more.
> 
>> 114 *python36*
>> 115 *python37*
>> 10  *python38*
> 
> We don't need to _obsolete or remove python3[67]-* packages, we just
> need to track how many don't have python38-* equivalents yet.
> Obviously that's still the vast majority, since 3.8 just got updated to
> a stable version.
> 
> Jon Turney, if a python-foo source package was previously building e.g.
> python27-foo, python36-foo, and python37-foo, and now starts building
> only python37-foo and python38-foo, is calm going to complain?

Yes, currently it will complain about that ("install packages from 
source package '...' have non-unique current versions")

calm is currently smart enough to exclude old soversions from that 
check, so I guess perhaps that it needs to be taught about python27 as well.

Re: Python - plan & execution

[Marco Atzeri]

On 27.04.2020 16:34, Jon Turney wrote:
> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>>
>>> currently we have
>>>
>>> 119 *python27*
>>
>> These are fine as is, but they also don't need to be rebuilt or updated
>> any more.
>>
>>> 114 *python36*
>>> 115 *python37*
>>> 10  *python38*
>>
>> We don't need to _obsolete or remove python3[67]-* packages, we just
>> need to track how many don't have python38-* equivalents yet.
>> Obviously that's still the vast majority, since 3.8 just got updated to
>> a stable version.
>>
>> Jon Turney, if a python-foo source package was previously building e.g.
>> python27-foo, python36-foo, and python37-foo, and now starts building
>> only python37-foo and python38-foo, is calm going to complain?
> 
> Yes, currently it will complain about that ("install packages from 
> source package '...' have non-unique current versions")
> 
> calm is currently smart enough to exclude old soversions from that 
> check, so I guess perhaps that it needs to be taught about python27 as 
> well.
> 

Hi Jon,

there will be several cases to test;
the first I am rebuilding is python-setuptools
and it seems there are half of the packages to drop in 46.4.0


python-setuptools	python27-setuptools   drop
python-setuptools	python35-setuptools   drop
python-setuptools	python36-setuptools
python-setuptools	python37-setuptools
python-setuptools	python38-setuptools
python-setuptools	python-setuptools-wheel  drop


I expect to see other similar as all recent packages
are now only supporting 3.5 or more to 3.8

https://pypi.org/project/setuptools/


Yaakov,

on python-setuptools-wheel, this file is not build/installed anymore

usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl

so I guess it was Py2 only

Marco

Re: Python - plan & execution

[Marco Atzeri]

On 10.04.2020 14:52, 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).

I do not found a package called python-unversioned-command
on fedora

https://apps.fedoraproject.org/packages/s/python-unversioned-command
page is empty

and google seems suggest only discussion on the matter

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

> first steps done:
> - updated 3.8 to 3.8.2
> - updated 3.7 to 3.7.7
> - updated also their python doc
> - upload of all of them is in progress
> 
> next steps:
> - I assume we can drop 3.5
> - for the time being no need to update 2.7 and 3.6
>    (we are just one version behind)
> 
> - verify which python packages we need to build/rebuild
> 
> currently we have
> 
> 119 *python27*
> 114 *python36*
> 115 *python37*
> 10  *python38*
> 
> and ~ 225 other *python* packages (plus 10 for python35)
> 
> - verify the fedora python-unversioned-command
> 
> 
> Regards
> Marco


what will be the drow back to use alternative to manage

/usr/bin/python and /usr/bin/python3 ?

we can put priorities for python as  2.7 3.8 3.7 3.6
and for python3 as 3.8 3.7 3.6

and rebuild python3 as empty package that pulls 3.6 (or 3.7 ?) now and 
3.8 in future

Regards
Marco

Re: Python - plan & execution

[Jon Turney]

On 25/05/2020 05:52, Marco Atzeri via Cygwin-apps wrote:
> On 27.04.2020 16:34, Jon Turney wrote:
>> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>>> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>>>
>>>> currently we have
>>>>
>>>> 119 *python27*
>>>
>>> These are fine as is, but they also don't need to be rebuilt or updated
>>> any more.
>>>
>>>> 114 *python36*
>>>> 115 *python37*
>>>> 10  *python38*
>>>
>>> We don't need to _obsolete or remove python3[67]-* packages, we just
>>> need to track how many don't have python38-* equivalents yet.
>>> Obviously that's still the vast majority, since 3.8 just got updated to
>>> a stable version.
>>>
>>> Jon Turney, if a python-foo source package was previously building e.g.
>>> python27-foo, python36-foo, and python37-foo, and now starts building
>>> only python37-foo and python38-foo, is calm going to complain?
>>
>> Yes, currently it will complain about that ("install packages from 
>> source package '...' have non-unique current versions")
>>
>> calm is currently smart enough to exclude old soversions from that 
>> check, so I guess perhaps that it needs to be taught about python27 as 
>> well.
>>
> 
> Hi Jon,
> 
> there will be several cases to test;
> the first I am rebuilding is python-setuptools
> and it seems there are half of the packages to drop in 46.4.0
> 
> 
> python-setuptools    python27-setuptools   drop
> python-setuptools    python35-setuptools   drop
> python-setuptools    python36-setuptools
> python-setuptools    python37-setuptools
> python-setuptools    python38-setuptools
> python-setuptools    python-setuptools-wheel  drop
> 
> 
> I expect to see other similar as all recent packages
> are now only supporting 3.5 or more to 3.8
> 
> https://pypi.org/project/setuptools/

Thanks to a patch by Yaakov, calm should now treat these similarly to 
old soversions and not warn about them.

Re: Python - plan & execution

[Yaakov Selkowitz]

On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
> On 27.04.2020 16:34, Jon Turney wrote:
> > On 23/04/2020 22:54, Yaakov Selkowitz wrote:
> > > On Fri, 2020-04-10 at 14:52 +0200, 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:
> > > > 
> > > > currently we have
> > > > 
> > > > 119 *python27*
> > > 
> > > These are fine as is, but they also don't need to be rebuilt or updated
> > > any more.
> > > 
> > > > 114 *python36*
> > > > 115 *python37*
> > > > 10  *python38*
> > > 
> > > We don't need to _obsolete or remove python3[67]-* packages, we just
> > > need to track how many don't have python38-* equivalents yet.
> > > Obviously that's still the vast majority, since 3.8 just got updated to
> > > a stable version.
> > > 
> > > Jon Turney, if a python-foo source package was previously building e.g.
> > > python27-foo, python36-foo, and python37-foo, and now starts building
> > > only python37-foo and python38-foo, is calm going to complain?
> > 
> > Yes, currently it will complain about that ("install packages from 
> > source package '...' have non-unique current versions")
> > 
> > calm is currently smart enough to exclude old soversions from that 
> > check, so I guess perhaps that it needs to be taught about python27 as 
> > well.
> > 
> 
> there will be several cases to test;
> the first I am rebuilding is python-setuptools
> and it seems there are half of the packages to drop in 46.4.0
> 
> 
> python-setuptools	python27-setuptools   drop

I'd like to suggest you make two updates to setuptools, one to the last
version which supports 2.7 with all Pythons enabled, and then to the
latest version, dropping 2.7.

> python-setuptools	python35-setuptools   drop

3.5 is still supported upstream and by latest setuptools, why drop
this?

> python-setuptools	python36-setuptools
> python-setuptools	python37-setuptools
> python-setuptools	python38-setuptools

No change here, as expected.

> python-setuptools	python-setuptools-wheel  drop
> 
> on python-setuptools-wheel, this file is not build/installed anymore
> 
> usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl
> 
> so I guess it was Py2 only

No; since setuptools dropped Py2 support, they must have stopped
declaring 'universal' compatibility, so the wheel would now be just
'py3' instead of 'py2.py3'.  You don't want to drop this package,
because it is used by (patched) python3Y venv as well as by python3Y-
virtualenv.

OTOH, since the latest setuptools won't work with python27, then
python27 and python27-virtualenv shouldn't use python-setuptools-wheel
anymore.  I'd have to look further into the best way to handle that.

--
Yaakov

Re: Python - plan & execution

[Marco Atzeri]

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

On 26.05.2020 01:45, Yaakov Selkowitz wrote:
> On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
>> On 27.04.2020 16:34, Jon Turney wrote:
>>> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>>>> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>>>>
>>>>> currently we have
>>>>>
>>>>> 119 *python27*
>>>>
>>>> These are fine as is, but they also don't need to be rebuilt or updated
>>>> any more.
>>>>
>>>>> 114 *python36*
>>>>> 115 *python37*
>>>>> 10  *python38*
>>>>
>>>> We don't need to _obsolete or remove python3[67]-* packages, we just
>>>> need to track how many don't have python38-* equivalents yet.
>>>> Obviously that's still the vast majority, since 3.8 just got updated to
>>>> a stable version.
>>>>
>>>> Jon Turney, if a python-foo source package was previously building e.g.
>>>> python27-foo, python36-foo, and python37-foo, and now starts building
>>>> only python37-foo and python38-foo, is calm going to complain?
>>>
>>> Yes, currently it will complain about that ("install packages from
>>> source package '...' have non-unique current versions")
>>>
>>> calm is currently smart enough to exclude old soversions from that
>>> check, so I guess perhaps that it needs to be taught about python27 as
>>> well.
>>>
>>
>> there will be several cases to test;
>> the first I am rebuilding is python-setuptools
>> and it seems there are half of the packages to drop in 46.4.0
>>
>>
>> python-setuptools	python27-setuptools   drop
> 
> I'd like to suggest you make two updates to setuptools, one to the last
> version which supports 2.7 with all Pythons enabled, and then to the
> latest version, dropping 2.7.
> 
>> python-setuptools	python35-setuptools   drop
> 
> 3.5 is still supported upstream and by latest setuptools, why drop
> this?

we are not really supporting 3.5, we have only 8 packages and
stable is 3.6, so I see no reason to go backwards

>> python-setuptools	python36-setuptools
>> python-setuptools	python37-setuptools
>> python-setuptools	python38-setuptools
> 
> No change here, as expected.
> 
>> python-setuptools	python-setuptools-wheel  drop
>>
>> on python-setuptools-wheel, this file is not build/installed anymore
>>
>> usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl
>>
>> so I guess it was Py2 only
> 
> No; since setuptools dropped Py2 support, they must have stopped
> declaring 'universal' compatibility, so the wheel would now be just
> 'py3' instead of 'py2.py3'.  You don't want to drop this package,
> because it is used by (patched) python3Y venv as well as by python3Y-
> virtualenv.
> 
> OTOH, since the latest setuptools won't work with python27, then
> python27 and python27-virtualenv shouldn't use python-setuptools-wheel
> anymore.  I'd have to look further into the best way to handle that.
> 
> --
> Yaakov
> 

I was moving to the next package after installing setuptools and I got

 >>> python36-pip requires: python36 python38 python38-pip 
ca-certificates python36-setuptools
 >>> python36-pip OBSOLETES: python3-pip
 >>> python37-pip requires: python37 ca-certificates python37-setuptools
 >>> python38-pip requires: python38 ca-certificates python38-setuptools


that is very curious and due to

   usr/bin/pip3

that is a copy of usr/bin/pip3.8

Should I manage "pip3" with alternatives so that is really available
for all python versions ?
I can also override with pip3.7 or pip3.6 to force a fixed default.

Regards
Marco



[-- Attachment #2: python-setuptools.cygport --]
[-- Type: text/plain, Size: 639 bytes --]

PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8"
inherit python-wheel

NAME="python-setuptools"
VERSION=46.4.0
RELEASE=1
CATEGORY="Python"
SUMMARY="Python package management tool"
DESCRIPTION="PyPI Python eggs package management tool"
SRC_URI="${SRC_URI%.tar.gz}.zip"

ARCH=noarch

#PKG_NAMES+=" ${NAME}-wheel"
#python_setuptools_wheel_CONTENTS="
#	usr/share/python-wheels/setuptools-*.whl
#	usr/share/doc/${NAME}-wheel/
#"

python36_setuptools_CONTENTS+=" usr/bin/*-3.6"
python37_setuptools_CONTENTS+=" usr/bin/*-3.7"
python38_setuptools_CONTENTS+=" usr/bin/*-3.8"

#PKG_IGNORE="usr/bin/easy_install"

src_install() {
	cd ${B}
	python_wheel_install
}

[-- Attachment #3: python-pip.cygport --]
[-- Type: text/plain, Size: 1028 bytes --]

PYTHON_WHEEL_VERSIONS="3.6:3.7:3.8"
inherit python-wheel

NAME="python-pip"
VERSION=20.1.1
RELEASE=1
CATEGORY="Python"
SUMMARY="Python package installation tool"
DESCRIPTION="The PyPA recommended tool for installing Python packages."

PATCH_URI="https://src.fedoraproject.org/rpms/python-pip/raw/master/f/dummy-certifi.patch"

ARCH=noarch

CYGPORT_USE_UNSTABLE_API=1
src_unpack_hook() {
	rm src/pip/_vendor/certifi/*.pem
	sed -i '/\.pem$/d' src/pip.egg-info/SOURCES.txt
}

# PKG_NAMES+=" ${NAME}-wheel"
# python_pip_wheel_CONTENTS="
# 	usr/share/python-wheels/pip-*.whl
#	usr/share/doc/${NAME}-wheel/
# "

python36_pip_CONTENTS+=" usr/bin/pip3.6"
python36_pip_REQUIRES="ca-certificates python36-setuptools"
python37_pip_CONTENTS+=" usr/bin/pip3.7"
python37_pip_REQUIRES="ca-certificates python37-setuptools"
python38_pip_CONTENTS+=" usr/bin/pip3.8"
python38_pip_REQUIRES="ca-certificates python38-setuptools"

REQUIRES_EXCLUDE_FROM="*/etree_lxml.py:*/_vendor/urllib3/contrib/*"

src_install() {
	cd ${B}
	python_wheel_install
}

Re: Python - plan & execution

[Jon Turney]

On 26/05/2020 05:31, Marco Atzeri via Cygwin-apps wrote:
> On 26.05.2020 01:45, Yaakov Selkowitz wrote:
>> On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
>>> On 27.04.2020 16:34, Jon Turney wrote:
>>>> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>>>>> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>>>>>
>>>>>> currently we have
>>>>>>
>>>>>> 119 *python27*
>>>>>
>>>>> These are fine as is, but they also don't need to be rebuilt or 
>>>>> updated
>>>>> any more.

Marco,

The python2 2.7.18-1 update dropped the dependency of python2-devel on 
python27-devel

Was this deliberate?

(I noticed because this broke meson's CI, which installs python2-devel 
and expects to get Python.h etc.)

Thanks for the python updates!

Re: Python - plan & execution

[Marco Atzeri]

On 08.06.2020 21:20, Jon Turney wrote:
> On 26/05/2020 05:31, Marco Atzeri via Cygwin-apps wrote:
>> On 26.05.2020 01:45, Yaakov Selkowitz wrote:
>>> On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
>>>> On 27.04.2020 16:34, Jon Turney wrote:
>>>>> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>>>>>> On Fri, 2020-04-10 at 14:52 +0200, 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:
>>>>>>>
>>>>>>> currently we have
>>>>>>>
>>>>>>> 119 *python27*
>>>>>>
>>>>>> These are fine as is, but they also don't need to be rebuilt or 
>>>>>> updated
>>>>>> any more.
> 
> Marco,
> 
> The python2 2.7.18-1 update dropped the dependency of python2-devel on 
> python27-devel
> 
> Was this deliberate?
> 
> (I noticed because this broke meson's CI, which installs python2-devel 
> and expects to get Python.h etc.)
> 
> Thanks for the python updates!
> 

no. I had the impression to have only changed the version number
and rebuilt.

But I could remember wrong

Marco

Re: Python - plan & execution

[Jon Turney]

On 08/06/2020 21:02, Marco Atzeri via Cygwin-apps wrote:
> On 08.06.2020 21:20, Jon Turney wrote:
>>
>> Marco,
>>
>> The python2 2.7.18-1 update dropped the dependency of python2-devel on 
>> python27-devel
>>
>> Was this deliberate?
>>
>> (I noticed because this broke meson's CI, which installs python2-devel 
>> and expects to get Python.h etc.)
>>
>> Thanks for the python updates!
> 
> no. I had the impression to have only changed the version number
> and rebuilt.
> 
> But I could remember wrong

Yeah, that seems to be the case, looking at the cygport.

Perhaps cygport's automatic dependency detection didn't work correctly 
for some reason? (It probably doesn't if python27-devel isn't already 
installed, for e.g.)

Re: Python - plan & execution

[Marco Atzeri]

On 09.06.2020 15:20, Jon Turney wrote:
> On 08/06/2020 21:02, Marco Atzeri via Cygwin-apps wrote:
>> On 08.06.2020 21:20, Jon Turney wrote:
>>>
>>> Marco,
>>>
>>> The python2 2.7.18-1 update dropped the dependency of python2-devel 
>>> on python27-devel
>>>
>>> Was this deliberate?
>>>
>>> (I noticed because this broke meson's CI, which installs 
>>> python2-devel and expects to get Python.h etc.)
>>>
>>> Thanks for the python updates!

thanks, it is taking longer than expected because
I am founding interesting things I never noticed
on the other packages.

like 3.6.10 requires a case sensitive file system
and a case sensitive mount.
I never needed neither of the two and I was puzzling
about python.exe vs a Python directory for few hours...


>> no. I had the impression to have only changed the version number
>> and rebuilt.
>>
>> But I could remember wrong
> 
> Yeah, that seems to be the case, looking at the cygport.
> 
> Perhaps cygport's automatic dependency detection didn't work correctly 
> for some reason? (It probably doesn't if python27-devel isn't already 
> installed, for e.g.)
> 

may be; repacking I see now :

 >>> python2-devel requires: python2 python27 python27-devel

Re: Python - plan & execution

[Jon Turney]

On 09/06/2020 20:16, Marco Atzeri via Cygwin-apps wrote:
> On 09.06.2020 15:20, Jon Turney wrote:
>> On 08/06/2020 21:02, Marco Atzeri via Cygwin-apps wrote:
>>> On 08.06.2020 21:20, Jon Turney wrote:
>>>>
>>>> Marco,
>>>>
>>>> The python2 2.7.18-1 update dropped the dependency of python2-devel 
>>>> on python27-devel
>>>>
>>>> Was this deliberate?
>>>>
>>>> (I noticed because this broke meson's CI, which installs 
>>>> python2-devel and expects to get Python.h etc.)
>>>>
>>>> Thanks for the python updates!
> 
> thanks, it is taking longer than expected because
> I am founding interesting things I never noticed
> on the other packages.
> 
> like 3.6.10 requires a case sensitive file system
> and a case sensitive mount.
> I never needed neither of the two and I was puzzling
> about python.exe vs a Python directory for few hours...

I wonder if cyport should warn if building on a case-insensitive file 
system (and/or have a RESTRICT to say a case-sensitive file system must 
be used).

(See also the discussion about spaces in the containing directory path)

Re: Python - plan & execution

[Marco Atzeri]

following on the python update, as I hit a strange issue

inherit python-wheel
NAME="python-cython"
VERSION=0.29.20

builds only version for 3.7 and 3.8
nothing on the log explains why for 3.6 is not built

https://pypi.org/project/Cython/

similar for python numpy

inherit python-wheel
NAME="python-numpy"
VERSION=1.19.0

only 3.7 and 3.8 versions are built

further strange of h5py

inherit python3-wheel
NAME="python3-h5py"
VERSION=2.10.0

builds only for 3.8

Any clue what I should look for ?

Marco
	

Re: Python - plan & execution

[airplanemath]

On 7/7/2020 2:40 PM, Marco Atzeri via Cygwin-apps wrote:
> following on the python update, as I hit a strange issue
>
> inherit python-wheel
> NAME="python-cython"
> VERSION=0.29.20
>
> builds only version for 3.7 and 3.8
> nothing on the log explains why for 3.6 is not built
>

Do you have
PYTHON_WHEEL_VERSIONS="all"
set??? Alternately,
PYTHON_WHEEL_VERSIONS="3.6:3.8:3.7"

Be aware that with the latter option the last python version listed is the
one unversioned scripts (cython, f2py, pip, pip3) will end up with in
their shebang
line.??


I just tried building cython, and got all versions I asked for (3.6,
3.5, and 2.7, in
addition to 3.7 and 3.7).?? That's the only thing I can think of that
would be
different.

> further strange of h5py
>
> inherit python3-wheel
> NAME="python3-h5py"
> VERSION=2.10.0
>
> builds only for 3.8


This one I'm less sure about.?? I'm not sure python3-wheel was updated
for multiple python3 versions.?? Changing that to inherit python-wheel
might get it to 3.7 and 3.8, then adding PYTHON_WHEEL_VERSION should
get it to all versions you're looking for.

>
> Any clue what I should look for ?
>
> Marco
> ????????

Re: Python - plan & execution

[Marco Atzeri]

On 10.07.2020 01:52, airplanemath via Cygwin-apps wrote:
> On 7/7/2020 2:40 PM, Marco Atzeri via Cygwin-apps wrote:
>> following on the python update, as I hit a strange issue
>>
>> inherit python-wheel
>> NAME="python-cython"
>> VERSION=0.29.20
>>
>> builds only version for 3.7 and 3.8
>> nothing on the log explains why for 3.6 is not built
>>
> 
> Do you have
> PYTHON_WHEEL_VERSIONS="all"
> set??? Alternately,
> PYTHON_WHEEL_VERSIONS="3.6:3.8:3.7"

I am almost sure to have tested at least the second option,
and I had the impression that the first version was the default.
But I will re-try both of them


> Be aware that with the latter option the last python version listed is the
> one unversioned scripts (cython, f2py, pip, pip3) will end up with in
> their shebang
> line.??

I am aware of it, thanks.

> 
> 
> I just tried building cython, and got all versions I asked for (3.6,
> 3.5, and 2.7, in
> addition to 3.7 and 3.7).?? That's the only thing I can think of that
> would be
> different.

thanks of the confirmation that at your side all build

> 
>> further strange of h5py
>>
>> inherit python3-wheel
>> NAME="python3-h5py"
>> VERSION=2.10.0
>>
>> builds only for 3.8
> 
> 
> This one I'm less sure about.?? I'm not sure python3-wheel was updated
> for multiple python3 versions.?? Changing that to inherit python-wheel
> might get it to 3.7 and 3.8, then adding PYTHON_WHEEL_VERSION should
> get it to all versions you're looking for.

I will try again with python-wheel

>>
>> Any clue what I should look for ?
>>
>> Marco

Regards
Marco

Re: Putting packages up for adoption

[Andrew Schulman]

> 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,
> > > <snip> 
> > > > > To that end, in the best interest of the community, please consider my
> > > > > packages up for adoption. 
> > > <snip>
> > > > > 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