Re: Automatic Provides: Discussion summary and plan

[Jason L Tibbitts III]

> "TO" == Tomas Orsava  writes:

TO> That looks incredible! Why didn't it see the light of day? Time
TO> constraints or some technical issues?

Well, it sort of fell by the wayside as I got involved with other
things.  I've learned a lot about RPM internals since then and I know I
really should get back to it.  So many things higher up in the
(incredibly huge) queue.

TO> Maybe it could be revived?

Technically it isn't dead; I just haven't worked on it in a (long)
while.

Basically I tried to come up with the ideal spec file and worked
backwards from that.  It's still not going to work for every package,
and it still isn't remotely as nice as simply not using an RPM spec at
all (and just generating one from metadata) but I think it's at least
a start.

Also, it does horrible, horrible things behind the scenes because RPM
just doesn't give us a couple of needed bits.  I filed a ticket with RPM
upstream to try and have it do that but no luck.  But the actual macros
behind the scenes are very well commented so at least things should be
moderately obvious.

Anyway, I'll try to have another look at it at some point.  I need to
extract the debug scaffolding and such and put that into Fedora
separately so that I can avoid rewriting it all the time.

 - J<
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Automatic Provides: Discussion summary and plan

[Tomas Orsava]

Yeah, I really wish I had actually pushed through the macro work I had
done last year.  You can see that at https://pagure.io/python-macros

A spec would look like this:
https://pagure.io/python-macros/blob/master/f/test1.spec

And most of that is actually implemented.  Note the almost complete
absence of version-specific bits.  That package builds for an arbitrary
number of system python versions automatically.

That looks incredible! Why didn't it see the light of day? Time 
constraints or some technical issues?


Maybe it could be revived?

Tomas
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Python 3 porting: 50% done in Rawhide 

[Craig Rodrigues]

On Thu, Aug 11, 2016 at 6:48 AM, Petr Viktorin  wrote:

>
> Instead, we should shift our focus from porting specfiles to upstream
> projects. At this point, if some software is easy to port it was probably
> ported already; what we're left with are either tough nuts to crack or
> projects with few people relative to the codebase size. Some projects that
> come to mind that could use attention are GTK, Mercurial, Samba, wxPython,
> PySide, Koji & Fedora infra, Ansible.
> I don't know yet what our priorities should be here, but that's the
> general direction.
>
>
You should decide which projects have strategic importance to be ported to
Python 3,
and make a list on this project's web page of the ones that are of most
interest to focus on.

Some of the projects you listed are slower to port to Python 3 for various
reasons.
For example:
 - Ansible needs to maintain compatibility with Python 2.4 (
https://docs.ansible.com/ansible/developing_modules_python3.html ).
   This makes porting really hard.
 - wxPython has project Phoenix which runs under Python 3 (
https://wiki.wxpython.org/ProjectPhoenix ) but not
all wxPython widgets have been ported to Python 3
 - Pyside requires changes due to differences in the Python C API in
Python2 and Python3 ( http://wiki.qt.io/PySide_Python_3_Issues )

I've been spending a lot of time in the past month contributing Python
patches to the Twisted library,
and I have learned that for serious Python codebases, porting to Python 3
can be non-trivial.

--
Craig
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Python 3 porting: 50% done in Rawhide 

[Justin W. Flory]

On 08/11/2016 09:48 AM, Petr Viktorin wrote:

Hello,
As of now, http://fedora.portingdb.xyz shows that we are 50% done
porting Fedora packages to Python 3. This is a big magic milestone; if
you're looking for a reason to celebrate, this is it! :)


Meanwhile, let me talk about what the number means and what the next
steps are.
50% packages are "done" in Rawhide. "Done" is defined as either
"Released"/"green" (packages that are either py3-only, or have py3 and
py2 variants packaged), or "Dropped"/"gray" (package won't be ported,
but there's a py3-compatible alternative packaged in Fedora -- for
example: "python" is dropped because "python3" is available;
"python-numeric" is dropped in favor of "numpy" even though the API s
are different).

The classification of "green" packages is mostly automatic, and it's not
perfect -- for example, python-twisted is green even though not all of
the submodules are ported yet, and nothing checks if the packaged py3
versions actually works. For cases when there's a problem with the
automatic process, manual overrides or notes can be put in
[fedora-update.yaml].

Portingdb tracks Rawhide; Fedora 25 is currently missing about 4
packages to get to 50%. It might very well get to 50% before the release.


Now, what's next?
I can't speak for everyone involved, but at Red Hat's python-maint team,
we'll tone down the focus on getting as many packages ported as
possible. This led to us picking the low-hanging fruit, which is better
left to people that are just getting started. We'll be around to answer
questions, provide hints, and otherwise help others get the badges
instead of stealing them for ourselves :)

Instead, we should shift our focus from porting specfiles to upstream
projects. At this point, if some software is easy to port it was
probably ported already; what we're left with are either tough nuts to
crack or projects with few people relative to the codebase size. Some
projects that come to mind that could use attention are GTK, Mercurial,
Samba, wxPython, PySide, Koji & Fedora infra, Ansible.
I don't know yet what our priorities should be here, but that's the
general direction.

But even if it won't be *our* focus, RPM porting is still open – you can
[contribute] toward the remaining 50%! Badges are waiting :)


[fedora-update.yaml]
https://github.com/fedora-python/portingdb/blob/master/data/fedora-update.yaml

[contribute] http://fedora.portingdb.xyz/howto/



Hi Petr! This is an awesome update to hear!!

Do you mind if I copy+paste this as a post into the Community Blog 
as-is? If you are able to log in [1] to the CommBlog, I can assign 
authorship credit to you (if you haven't signed already before).


Congrats team on the 50% milestone!!!


 [1]  https://communityblog.fedoraproject.org/wp-login.php

--
Cheers,
Justin W. Flory
jflo...@gmail.com



signature.asc
Description: OpenPGP digital signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Python 3 porting: 50% done in Rawhide 

[Petr Viktorin]

Hello,
As of now, http://fedora.portingdb.xyz shows that we are 50% done 
porting Fedora packages to Python 3. This is a big magic milestone; if 
you're looking for a reason to celebrate, this is it! :)



Meanwhile, let me talk about what the number means and what the next 
steps are.
50% packages are "done" in Rawhide. "Done" is defined as either 
"Released"/"green" (packages that are either py3-only, or have py3 and 
py2 variants packaged), or "Dropped"/"gray" (package won't be ported, 
but there's a py3-compatible alternative packaged in Fedora -- for 
example: "python" is dropped because "python3" is available; 
"python-numeric" is dropped in favor of "numpy" even though the API s 
are different).


The classification of "green" packages is mostly automatic, and it's not 
perfect -- for example, python-twisted is green even though not all of 
the submodules are ported yet, and nothing checks if the packaged py3 
versions actually works. For cases when there's a problem with the 
automatic process, manual overrides or notes can be put in 
[fedora-update.yaml].


Portingdb tracks Rawhide; Fedora 25 is currently missing about 4 
packages to get to 50%. It might very well get to 50% before the release.



Now, what's next?
I can't speak for everyone involved, but at Red Hat's python-maint team, 
we'll tone down the focus on getting as many packages ported as 
possible. This led to us picking the low-hanging fruit, which is better 
left to people that are just getting started. We'll be around to answer 
questions, provide hints, and otherwise help others get the badges 
instead of stealing them for ourselves :)


Instead, we should shift our focus from porting specfiles to upstream 
projects. At this point, if some software is easy to port it was 
probably ported already; what we're left with are either tough nuts to 
crack or projects with few people relative to the codebase size. Some 
projects that come to mind that could use attention are GTK, Mercurial, 
Samba, wxPython, PySide, Koji & Fedora infra, Ansible.
I don't know yet what our priorities should be here, but that's the 
general direction.


But even if it won't be *our* focus, RPM porting is still open – you can 
[contribute] toward the remaining 50%! Badges are waiting :)



[fedora-update.yaml] 
https://github.com/fedora-python/portingdb/blob/master/data/fedora-update.yaml

[contribute] http://fedora.portingdb.xyz/howto/

--
Petr Viktorin
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Python 3.5 for Fedora 23

[Miro Hrončok]

Hi,

As a follow up of our Flock discussion, I will build several Python 
versions in Copr, for development purposes (such as testing your code 
with tox on multiple Python versions).


Those builds will be installable alongside regular python3/python 
packages and will be normal packages, no software collections etc. One 
flat package (i.e. no -libs, -devel...) with bundled setuptools and pip.


First I've built Python 3.5 for Fedora 23, you can grab it here [1].

If you try to use tox with it, you'll have to use Python 3 version 
(python3-tox is the package and unfortunately also the command), due to 
a bug in virtualenv [2].


I would appreciate any feedback on the build, so I can build python34 
package for Fedora 24+ in similar manner soon.


Also python33 and python26 are planned.

If those builds prove themselves useful I'll try to put them in Fedora 
(with a strict guideline that forbids any other package to depend on them).


[1] https://copr.fedorainfracloud.org/coprs/g/python/python35/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365941
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org