Re: Updating glib2 in cygwin

2023-06-11 Thread Ken Brown via Cygwin-apps

On 6/11/2023 1:55 PM, Jon Turney wrote:

On 28/02/2022 13:29, Ken Brown wrote:

The last discussion of this that I can recall started here:

   https://cygwin.com/pipermail/cygwin-apps/2020-May/040105.html

What's needed is for someone to adopt all of the GNOME components and 
maintain them.  As you'll see in the discussion I cited, I briefly 
considered updating only glib2 and a few others, but then I decided 
that I wasn't willing to take the responsibility of fixing/updating 
other components that broke as a result of this.  So I pushed what I 
had done and left it there.


It would be great if someone would step up and take over, but I'm not 
in a position to do that myself.


Since this is possibly the most important unmaintained package (it's #1 
by dependencies on this list [1]), I guess I'll adopt it.


I see you got as far as 2.64.3 [2].  I'm inclined to deploy that (maybe 
as test) and deal with the fallout myself, while I work on bringing it 
completely up to date.


Any issues I should be aware or, or other problems you foresee with that 
approach?


Nothing I'm aware of.  Thanks for taking this on!

Ken


Re: python2 removal

2023-06-11 Thread Jon Turney via Cygwin-apps

On 02/04/2023 16:47, Jon Turney via Cygwin-apps wrote:

On 14/03/2023 19:17, Jon Turney via Cygwin-apps wrote:

On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote:


This has come up in discussion a few times, and is now well overdue, 
I think.


Python 2.7 is the last python2 version, which was sunsetted on 
January 1, 2020.



[...]


3) There might also still be some other packages lurking which just 
install a script with a shebang containing 'python', and assume that 
python is python2.  I don't know how we could identify those.


The remaining cases of packages which have a dependency on python 
and/or python2 are either this (packages which contain a python script 
with a python shebang line), or the other case which I hadn't 
previously considered - a package which contain an executable or 
shared library linked with libpython2.7.dll.


So, again I need inspect these to determine what should happen to them.


So here's the list, with *tentative* notes of the disposition for each 
package.


Here's an updated list of the remaining packages, after removals, 
rebuilds and/or updates:



source package package maintainer
notes  disposition

boost  boost-build ORPHANED (Yaakov Selkowitz)   
[†]depends on python2 and python3? Marco Atzeri may adopt
boost  libboost_mpi_python*" 
[*]libboost_mpi_python3* exists, so just remove?
boost  libboost_numpy* " 
[*]libboost_numpy3* exists, so just remove?
boost  libboost_python*" 
[*]libboost_python3_* exists, so just remove?
cantor cantor-backend-python2  ORPHANED (Yaakov Selkowitz)   
[*]leave as is, becomes not-installable (cantor-backend-python3 exists)
extra-cmake-modulesextra-cmake-modules Marco Atzeri  
[†]probably ok, but should probably rebuild
geany-plugins  geany-plugins-geanypy   ORPHANED (Yaakov Selkowitz)   
[*][1] leave as is, becomes not-installable
gimp   gimp-python ORPHANED (Yaakov Selkowitz)   
[*][4] leave as is, becomes not-installable
gnome-commandergnome-commander ORPHANED (Yaakov Selkowitz)   
[*][5] update and rebuild
gnumeric   gnumeric-python ORPHANED (Yaakov Selkowitz)   
[*][6] update and rebuild
gtranslatorgtranslator ORPHANED (Yaakov Selkowitz)   
[†][5] update and rebuild
inkscape   inkscapeORPHANED (Yaakov Selkowitz)   
[†][§][2]  update and rebuild
kf5-kross-interpreters kf5-kross-pythonORPHANED (Yaakov Selkowitz)   
[*][7] update and rebuild
kigkig ORPHANED (Yaakov Selkowitz)   
[†][§][7]  update and rebuild
kross-interpreters kross-pythonORPHANED (Yaakov Selkowitz)   
[*]leave as is, becomes not-installable (KDE4-era)
libglade2.0libglade2.0-devel   ORPHANED (Yaakov Selkowitz)   
[†][§] leave as is, becomes not-installable (upstream unchanged)
llvm   llvmORPHANED (Yaakov Selkowitz)   
[†]leave as is, needs updating but not by me
lokalize   lokalizeORPHANED (Yaakov Selkowitz)   
[†][§] leave as is, becomes not-installable
octave-miscellaneous   octave-miscellaneousMarco Atzeri  
[†]?
parley parley  ORPHANED (Yaakov Selkowitz)   
[†]leave as is, becomes not-installable?
pidgin libgnt0 ORPHANED (Yaakov Selkowitz)   
[*]leave as is, becomes not-installable?
pidgin pidgin  " 
[†]leave as is, becomes not-installable?
pluma  pluma   ORPHANED (Yaakov Selkowitz)   
[†][§][8]  update and rebuild
pulseaudio-equalizer   pulseaudio-equalizerTakashi Yano  
[†]?
scribusscribus ORPHANED (Yaakov Selkowitz)   
[*]leave as is, becomes not-installable
telepathy-gabble   telepathy-gabbleORPHANED (Yaakov Selkowitz)   
[†][§] leave as is, becomes not-installable
tellicotellico ORPHANED (Yaakov Selkowitz)   
[†][§] leave as is, becomes not-installable
tracker-miners tracker-miners  ORPHANED (Yaakov Selkowitz)   
[†][§][3]  leave as is, becomes not-installable
vimvim-python  Marco Atzeri 
empty and obsolete, remove
virt-manager   virt-managerJason Pyeron  
[†]update and rebuild
xplayerxplayer ORPHANED (Yaakov Selkowitz)   
[†][§][5]  update and rebuild

[*] 

cygwin-pkg-maint enhancements

2023-06-11 Thread Jon Turney via Cygwin-apps



I've deployed an update to calm which makes a few small improvements to 
the way cygwin-pkg-maint is handled:


* Lines starting with a '#' are now ignored as a comment

* There's now a simple facility for grouping packages:

Define a group with a line starting with '@', e.g.:

@upstream_project Maintainer1/Maintainer2

Then @upstream_project can used in a package's maintainer list, as a 
reference to that list of maintainers.


This is all done in a single-pass parser at the moment, so group 
definitions must precede packages which use them.


(Adding this was partially motivated by the fact that I've been 
laboriously identifying and adopting packages which have X.Org as their 
upstream, but there's no way to record that as a group of packages for 
future reference)


Re: Updating glib2 in cygwin

2023-06-11 Thread Jon Turney via Cygwin-apps

On 28/02/2022 13:29, Ken Brown wrote:

[Redirecting to the cygwin-apps list]

On 2/28/2022 3:49 AM, Marc-André Lureau wrote:

Hi Ken

I am a qemu developer at Red Hat. The "official" qemu Windows build
uses cygwin, and the glib version there is quite old.

I saw you have made some effort to update the package
(https://www.cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/glib2.0.git;a=search;h=refs/heads/playground;s=Ken+Brown;st=author)

What's the situation? Is there a bug tracking the issues?


Hi Marc,

The last discussion of this that I can recall started here:

   https://cygwin.com/pipermail/cygwin-apps/2020-May/040105.html

What's needed is for someone to adopt all of the GNOME components and 
maintain them.  As you'll see in the discussion I cited, I briefly 
considered updating only glib2 and a few others, but then I decided that 
I wasn't willing to take the responsibility of fixing/updating other 
components that broke as a result of this.  So I pushed what I had done 
and left it there.


It would be great if someone would step up and take over, but I'm not in 
a position to do that myself.


Since this is possibly the most important unmaintained package (it's #1 
by dependencies on this list [1]), I guess I'll adopt it.


I see you got as far as 2.64.3 [2].  I'm inclined to deploy that (maybe 
as test) and deal with the fallout myself, while I work on bringing it 
completely up to date.


Any issues I should be aware or, or other problems you foresee with that 
approach?



[1] https://cygwin.com/packages/reports/unmaintained.html
[2] https://cygwin.com/cgit/cygwin-packages/glib2.0/log/?h=playground