Re: python2 removal

2023-04-02 Thread marco atzeri via Cygwin-apps
On Sun, Apr 2, 2023 at 11:47 AM 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.
>
> As before, I might look at rebuilding some of the more important
> packages, as time permits, and some of these are candidates for removal
> if not updated, but obviously adoptions and input on what is no longer
> useful is welcomed!
>
> I've also adjusted numerous old package versions which depend on
> 'python' to depend on 'python2' when that's what they actually require,
> so they will become not-installable when python2 is removed, and can
> subsequently be expired.
>
> (often these are historical package requirements which were synthesized
> from the current package requirements from before we had per-version
> requirements)
>
> Contrariwise, a few packages (e.g. clang, ibus, libglib2.0-devel, llvm,
> lv2-devel, mysql-server, pulseaudio-equalizer) which depend on python2,
> but contain a script which appears to work with python3 have been
> adjusted to depend on 'python'
>

Thanks John

> > source package package maintainer   
> >  notes  disposition
> > boost  boost-build ORPHANED (Yaakov Selkowitz)  
> >  [†]unclear? depends on python2 and python3?
> > 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?

I will adopt boost.

> > extra-cmake-modulesextra-cmake-modules ORPHANED (Yaakov Selkowitz)  
> >  [†]probably ok, but should probably update & rebuild

I will look on it

> > inkscape   inkscapeORPHANED (Yaakov Selkowitz)  
> >  [†][§][5]  update and rebuild

I will adopt inkscape

> > octave-miscellaneous   octave-miscellaneousMarco Atzeri 
> >  [†]?
ignore the dependency, it is coming from a demo script. I will remove
on next octave rebuild

> > vimvim-python  Marco Atzeri 
> > empty and obsolete, remove
Noted


Re: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip

2023-04-02 Thread Achim Gratz via Cygwin-apps
Jon Turney via Cygwin-apps writes:
>> Exchange the while loop using an iffy read construct to a for loop using a 
>> temporary file.
>
> I think this change from zero-delimited to whitespace means this will
> now fail to handle any filenames containing whitespace correctly?

Yes, sorry.  I thought whitespace in filenames wasn't working anyway,
but at least here it was done correctly.

> This commentary doesn't clearly identify what is wrong with the usage
> of read here.

The read itself was OK, piping the data from find into the read wasn't.
I've replaced this with a process substitution and thus reinstated the
whitespace protection without getting into subshell trouble.

>> avoid filename collisions by using an
>> SHA256 hash of the full file name. 
>
> I think there is already a perfectly good, filesystem safe,
> computationally cheap unique identifier for each filename, which is
> it's ordinal number in the list of filenames we are examining.

I've implemented a counter now.  However I don't see the hashing of a
filename as onerous when Git does that much more often and on much
larger data.

> 'wait -f' seems to be new in bash 5.0.  I assume this fails horribly
> on earlier bash versions.  I'm ok with requiring that, but maybe we
> should check the bash version?

It should indeed be possible to drop the -f as long as job control is not
enabled if I understand the manual correctly after re-reading it several
times.  I've done that and it looks like things still work.

> On the plus side, the testsuite passes! :)

Oh goody!


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: [PATCH cygport] lib/src_postinst.cygpart: parallelize __prepstrip

2023-04-02 Thread Jon Turney via Cygwin-apps

On 30/03/2023 21:34, Jon Turney via Cygwin-apps wrote:

On 30/03/2023 20:49, Achim Gratz via Cygwin-apps wrote:

Jon Turney via Cygwin-apps writes:

On 26/03/2023 19:12, Jon Turney via Cygwin-apps wrote:



Exchange the while loop using an iffy read construct to a for loop using a 
temporary file.


I think this change from zero-delimited to whitespace means this will 
now fail to handle any filenames containing whitespace correctly?


This commentary doesn't clearly identify what is wrong with the usage of 
read here.



avoid filename collisions by using an
SHA256 hash of the full file name. 


I think there is already a perfectly good, filesystem safe, 
computationally cheap unique identifier for each filename, which is it's 
ordinal number in the list of filenames we are examining.


'wait -f' seems to be new in bash 5.0.  I assume this fails horribly on 
earlier bash versions.  I'm ok with requiring that, but maybe we should 
check the bash version?


On the plus side, the testsuite passes! :)



Re: python2 removal

2023-04-02 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.



[...]

source package package maintainernotes  disposition   


octave-miscellaneous   octave-miscellaneousMarco Atzeri  
[†]?

[†] contains some python scripts
[§] script is python2 only, not compatible with python3


Hi Marco,

Currently, octave-miscellaneous depends on python2.  It would help me 
greatly if you could tell me if that's correct or if it should depend on 
python (if all the scripts in it also work with python3), or it should 
be updated to work with python3?


Additionally, I noted that subversion-tools depends on python (due to an 
explicit requires in the cygport), but... I don't see any python scripts 
there, so I wonder if that should just be removed in future.




Re: python2 removal

2023-04-02 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.

[...]

source package package maintainernotes  


cfvcfv Jari Aalto
[†][§]
svn-load   svn-loadJari Aalto
[†][§]
webcheck   webcheckJari Aalto
[†][§]

[†] contains some python scripts
[§] script is python2 only, not compatible with python3


Hi Jari,

I believe these packages all need updating for python3.

Please confirm if this assessment is correct, and let me know if you 
intend to do this, otherwise I will assume these packages are orphaned 
and they will be removed.


Thanks.



Re: python2 removal

2023-04-02 Thread Jon Turney via Cygwin-apps

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.


As before, I might look at rebuilding some of the more important 
packages, as time permits, and some of these are candidates for removal 
if not updated, but obviously adoptions and input on what is no longer 
useful is welcomed!


I've also adjusted numerous old package versions which depend on 
'python' to depend on 'python2' when that's what they actually require, 
so they will become not-installable when python2 is removed, and can 
subsequently be expired.


(often these are historical package requirements which were synthesized 
from the current package requirements from before we had per-version 
requirements)


Contrariwise, a few packages (e.g. clang, ibus, libglib2.0-devel, llvm, 
lv2-devel, mysql-server, pulseaudio-equalizer) which depend on python2, 
but contain a script which appears to work with python3 have been 
adjusted to depend on 'python'


source package package maintainernotes  disposition

GConf2 GConf2  ORPHANED (Yaakov Selkowitz)   [†][§][1]  ?  
XtoW   XtoWJon Turney[†][§] remove (experiment has run it's course)   
anjuta anjuta  ORPHANED (Yaakov Selkowitz)   [*]update and rebuild 
avogadro   libavogadro1ORPHANED (Yaakov Selkowitz)   [*]update and rebuild (not to avogadro2?)

boost  boost-build ORPHANED (Yaakov Selkowitz)   
[†]unclear? depends on python2 and python3?
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?
caja-pythoncaja-python ORPHANED (Yaakov Selkowitz)   
[*]update and rebuild
cantor cantor-backend-python2  ORPHANED (Yaakov Selkowitz)   [*]cantor-backend-python3 exists, so just remove? 
cfvcfv Jari Aalto[†][§] update and rebuild

extra-cmake-modulesextra-cmake-modules ORPHANED (Yaakov Selkowitz)   [†]
probably ok, but should probably update & rebuild
fluxboxfluxbox ORPHANED (Yaakov Selkowitz)   [†][§][2]  rebuild
fvwm   fvwmORPHANED (Yaakov Selkowitz)   [†]rebuild
geany-plugins  geany-plugins-geanypy   ORPHANED (Yaakov Selkowitz)   [*][3] leave as is, becomes not-installable

gimp   gimp-python ORPHANED (Yaakov Selkowitz)   
[*]update and rebuild
gnome-commandergnome-commander ORPHANED (Yaakov Selkowitz)   
[*]update and rebuild
gnubg  gnubg   ORPHANED (Dr. Volker Zell)
[*]update and rebuild
gnumeric   gnumeric-python ORPHANED (Yaakov Selkowitz)   
[*]update and rebuild
gonvertgonvert ORPHANED (Yaakov Selkowitz)   
[†][§][4]  remove
gtk2.0 libgtk2.0-devel ORPHANED (Yaakov Selkowitz)   
[†][§][9]  update and rebuild
gtksourceview2.0   libgtksourceview2.0_0   ORPHANED (Yaakov Selkowitz)   
[†][§][6]  leave as is, becomes not-installable
gtranslatorgtranslator ORPHANED (Yaakov Selkowitz)   
[†]?
inkscape   inkscapeORPHANED (Yaakov Selkowitz)   
[†][§][5]  update and rebuild
kde-dev-scriptskde-dev-scripts ORPHANED (Yaakov Selkowitz)   
[†]?
kf5-kross-interpreters 

[ITP] libhtp 0.5.42

2023-04-02 Thread Daisuke Fujimura via Cygwin-apps
Hello,

[ITP] A new package proposal: libhtp

- libhtp2
- libhtp-devel



SUMMARY: Security-aware parser for the HTTP protocol
HOMEPAGE: https://github.com/OISF/libhtp
SRC_URI: https://github.com/OISF/libhtp/archive/refs/tags/0.5.42.tar.gz
LICENSE: BSD-3-Clause



Corresponding Linux/Unix packages are searched:
- https://repology.org/project/libhtp/versions

Cygportfile:
- 
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libhtp

Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/4587137631