Re: python 2 retirement commo efforts

[R P Herrold]

On Tue, 17 Jul 2018, R P Herrold wrote:

>  I've poked at getting accurate counts and manifests of unique 
>  python(2) package SRPMs off my mirror today -- I'll supplement 
>  this email with the script and links to the mainfests 
>  tomorrow.  A 'sort | uniq' let me down as to getting an 
>  accurate count released today 
tomorrow arrived on me,  but here are the promised report and 
links to the results and the generator script

[/share/MD0_DATA/Mirror/lftp] # time ./stats.sh
# packages starting with target: python 
#   but NOT python3 
#   collated from a mirror: 20180718 

    264 /tmp/redhat_rhel_SRPMSonly_6Server.txt
    475 /tmp/redhat_rhel_SRPMSonly_7Server.txt
    644 /tmp/redhat_epel_6.txt
    825 /tmp/redhat_epel_7.txt
   2776 /tmp/redhat_fedora_fedora-28.txt
   2132 /tmp/redhat_rawhide2017.txt

real    64m28.714s
user    1m11.330s
sys     3m6.450s


The first column is the number of unique SRPMs for a given 
archive, seen.  Inside the files (the link of which is my 
second column and the basename of which is accessible per the 
links below) are detail counts of the number for each distinct 
SRPMs within a given package name, as seen on a local private 
mirror I use and maintain


Copies of the detail, and of the script producing the 
reports are at:

http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt
http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt
http://gallery.herrold.com/stuff/redhat_epel_6.txt
http://gallery.herrold.com/stuff/redhat_epel_7.txt
http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt
http://gallery.herrold.com/stuff/redhat_rawhide2017.txt

http://gallery.herrold.com/stuff/stats.sh


The _purpose_ of getting the count of 'number of updated 
packages' for each given package is to permit seeing 'hot 
spots', and the 'no issues' 'build once and forget' packages 
particularly in RHEL and EPEL.  Because of the way that 
current Fedora and RawHide are built, there is churn on 
rebuilds, even with non-material internal changes.  THe 


The ** POINT ** of producing such a report is to  'put 
numbers' on the scope of the work rather than loose armwaving 
assertions such as:

>  Fedora still has more than 3000 packages depending on 
>  python2 – many more than we can support without upstream 
>  help. 
I did not try to structure and run a report to try to 
enumerate and count by dependencies.  Looking at the 
problem with such a statistic, as to 'upstream' 'keystone' 
packages will, I suspect, show that many of the dependencies 
almost certainly 'cluster around a few 'branch' packages

-- Russ herrold

[EPEL-devel] Re: python 2 retirement commo efforts

[Miro Hrončok]

On 18.7.2018 20:24, R P Herrold wrote:
>  On Tue, 17 Jul 2018, R P Herrold wrote:
>  
> > I've poked at getting accurate counts and manifests of unique
> > python(2) package SRPMs off my mirror today -- I'll supplement
> > this email with the script and links to the mainfests
> > tomorrow.  A 'sort | uniq' let me down as to getting an
> > accurate count released today
>  
>  tomorrow arrived on me,  but here are the promised report and
>  links to the results and the generator script
>  
>  [/share/MD0_DATA/Mirror/lftp] # time ./stats.sh
>  # packages starting with target: python
>  #   but NOT python3
>  #   collated from a mirror: 20180718
>  
>       264 /tmp/redhat_rhel_SRPMSonly_6Server.txt
>       475 /tmp/redhat_rhel_SRPMSonly_7Server.txt
>       644 /tmp/redhat_epel_6.txt
>       825 /tmp/redhat_epel_7.txt
>      2776 /tmp/redhat_fedora_fedora-28.txt
>      2132 /tmp/redhat_rawhide2017.txt
>  
>  real    64m28.714s
>  user    1m11.330s
>  sys     3m6.450s
>  
>  
>  The first column is the number of unique SRPMs for a given
>  archive, seen.  Inside the files (the link of which is my
>  second column and the basename of which is accessible per the
>  links below) are detail counts of the number for each distinct
>  SRPMs within a given package name, as seen on a local private
>  mirror I use and maintain
>  
>  
>  Copies of the detail, and of the script producing the
>  reports are at:
>  
>  http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt
>  http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt
>  http://gallery.herrold.com/stuff/redhat_epel_6.txt
>  http://gallery.herrold.com/stuff/redhat_epel_7.txt
>  http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt
>  http://gallery.herrold.com/stuff/redhat_rawhide2017.txt
>  
>  http://gallery.herrold.com/stuff/stats.sh
>  
>  
>  The _purpose_ of getting the count of 'number of updated
>  packages' for each given package is to permit seeing 'hot
>  spots', and the 'no issues' 'build once and forget' packages
>  particularly in RHEL and EPEL.  Because of the way that
>  current Fedora and RawHide are built, there is churn on
>  rebuilds, even with non-material internal changes.  THe
>  
>  
>  The ** POINT ** of producing such a report is to  'put
>  numbers' on the scope of the work rather than loose armwaving
>  assertions such as:
>  
> > Fedora still has more than 3000 packages depending on
> > python2 – many more than we can support without upstream
> > help. 
Those are real Fedora numbers [0]. No armwaving involved.

1311 python2 only packages
1734 python2+python3 packages
+ 88 with packaging problem where I'm not sure

That is something between 3045 and 3133. That can be rounded to 3k.

No idea why we moved the discussion to another list as well, but stop 
accusing us from armwaving. We have data (for Fedora, because that where 
we started the discussion). As for RHEL/EPEL: current ones can remain as 
they are. Future ones see [1].

>  Python 2 will be replaced with Python 3 in the next Red Hat
> Enterprise
>  Linux (RHEL) major release. 
[0] http://fedora.portingdb.xyz/
[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...




-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[EPEL-devel] Re: python 2 retirement commo efforts

[R P Herrold]

On Thu, 19 Jul 2018, Miro Hrončok wrote:

>  > The ** POINT ** of producing such a report is to  'put
>  > numbers' on the scope of the work rather than loose armwaving
>  > assertions such as:
>  > 
>  > > Fedora still has more than 3000 packages depending on
>  > > python2 – many more than we can support without upstream
>  > > help.
>  
>  Those are real Fedora numbers [0]. No armwaving involved.
>  
>  1311 python2 only packages
>  1734 python2+python3 packages
>  + 88 with packaging problem where I'm not sure
>  
>  That is something between 3045 and 3133. That can be rounded to 3k.
>  
>  No idea why we moved the discussion to another list as well, but stop accusing
>  us from armwaving. We have data (for Fedora, because that where we started the
>  discussion). As for RHEL/EPEL: current ones can remain as they are. Future
>  ones see [1]. 
"accusing" ?  I think it is pretty clear that more than a 
little projection is going on here.  I offered a description 
of methodology, hard numbers on six archives, and the 
generation script to nail down numbers.  Before your most 
recent email, .... nope

The _reason_ that it was off an EPEL thread (EPEL of course 
being PART OF FEDORAPROJECT, last time I looked) is that is 
the harder one to solve, and also there was a thread going as 
to planning a meeting, of which that hard data was a part


If I go to a car dealer and seek to buy a car and ask a price, 
and am told by the salesperson:

	"more than 3000" dollars

they have not yet not told me a price they will sell the car 
at

-- Russ herrold

python 2 retirement commo efforts

[Nico Kadel-Garcia]

Good numbers to provide, thanks. I've one thought for you.

On Wed, Jul 18, 2018 at 2:24 PM, R P Herrold <herrold(a)owlriver.com&gt; wrote:

>  I did not try to structure and run a report to try to
>  enumerate and count by dependencies.  Looking at the
>  problem with such a statistic, as to 'upstream' 'keystone'
>  packages will, I suspect, show that many of the dependencies
>  almost certainly 'cluster around a few 'branch' packages
>
>  -- Russ herrold 
Numbers of dependencies are useful to report. I'd also expect "hot
spots" around packages that are simply incompatible with python 3, or
incompatible with python 2, due to the syntax differences between the
languages. That's not going to be solvable by merely updating .spec
files.

Hmm. Has anyone take a look at the "bdist_rpms" python tools,  used by
Python developers to build RPMS from their raw python code, to bring
it up to Fedora standards? Or py2pack? Getting those updated could
help.authors of new smf p;f python tools. follow new standards.