Re: visibility of pyp2rpm tool
- Original Message -
> From: "Martin Bukatovic" <martin.bukato...@gmail.com>
> To: python-devel@lists.fedoraproject.org
> Sent: Tuesday, February 9, 2016 2:13:59 AM
> Subject: visibility of pyp2rpm tool
>
> Dear fedora-python-devel,
>
> I noticed a problem with pyp2rpm tool: it's a great tool, but it's
> hardly visible and new python packager can easily miss it. The fact that
> both Packaging:Python and SIGs/Python wikipages doesn't properly mention
> it doesn't really help as well. No fried of mine who recently started
> working on packaging his project is aware of this tool and I find out
> about it only because I had weird newcomer's kind of questions on this
> mailing list and people here were kind enough to point out that I should
> check it first.
>
> Initially I tried to kind of fix this issue by adding a line
> about this tool into SIGs/Python page some time ago:
>
> https://fedoraproject.org/w/index.php?title=SIGs%2FPython=418064=417278
>
> The problem is that this doesn't really solve anything. Now I rather
> feel that more changes are required.
>
> My current idea how to maintain rpm packages for my own python project
> is summed up here:
>
> https://fedoraproject.org/wiki/User:Marbu/PythonPackaging
>
> Note that this is not a suggestion how the better description should
> look like. I link it here so that you can point out which part you
> disagree with (I'm not even a python sig member after all), so that
> we can catch possible disagreements as soon as possible. My suggestions
> below assumes that this makes sense. Keep in mind that I have hardly
> any real experience with python rpm packaging.
>
> So what exactly I have in mind? Compare this page:
>
> https://fedoraproject.org/wiki/Packaging:Python
>
> with:
>
> https://en.opensuse.org/openSUSE:Packaging_Python
>
> The difference includes:
>
> * fedora Packaging:Python page is a packaging policy, which doesn't
>mention pyp2rpm at all
> * openSUSE:Packaging_Python page is more like a step by step intro,
>which includes a clean example how to use SUSE's py2pack tool
>
> See also:
>
> https://fedoraproject.org/wiki/Packaging:Haskell
>
> which clearly points out to cabal-rpm tool right in the beginning.
>
> So my suggestions are:
>
> 1) Since the Packaging:Python page is the most visible, I would include
> quick intro about pyp2rpm as the first section here.
> 2) Mention Python SIG page here as well.
> 3) A beginner friendly howto with more details could be maintained
> separately linked from (or included in) revamped Python SIG page's
> "Packaging Quickstart" section.
>
> Moreover: I think that it would make sense to link older versions of the
> guidelines which are valid for epel 6 and 7 like ruby does here:
>
> https://fedoraproject.org/wiki/Packaging:Ruby
>
> I could help me with this feature request:
>
> https://github.com/fedora-python/pyp2rpm/issues/25
>
> Thanks for the feedback.
Hi Martin, I like your ideas, the best way to move
this forward is to open a ticket for fpc[0].
[0]https://fedorahosted.org/fpc/
>
> --
> Martin Bukatovic
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
>
--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Python naming guidelines clarification
- Original Message -
> From: "Jan Včelák" <jvce...@fedoraproject.org>
> To: "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Thursday, January 21, 2016 12:40:47 PM
> Subject: Re: Python naming guidelines clarification
>
> On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > Yes, the guidelines apply to the source rpm name too. Those
> > srpms should be called python-*, because they contain python libries.
>
> OK. Thank you.
>
> And what is the best current practice if the library contains some
> utilities. Should the utilities land in the python{2,3}-name package?
> Should it land in both?
>
> To give you an example, the ripe.atlas.sagan ships a utility
> parse_abuf. I'm currently removing it from the package as the upstream
> is going to deprecate it with the next release. But theoretically,
> should the utility be included in python2-ripe-atlas-sagan as
> parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
> be better for instance to create a package ripe-atlas-sagan which will
> contain just the Python 3 version of the utility?
>
As I suggested in my email before, package just one version running on
Python3 (if supported) when utility provides same functionality whether run
with Python3 or Python2.
There are special cases when you have to provide bin files for both major
versions of python, good example is python-pip (python3-pip installs python3
modules, python2-pip installs python2 modules).
Here are conventions for naming executables and some mentions about
Python2/Python3 executables conflicts:
https://fedoraproject.org/wiki/Packaging:Python#Naming
I believe that your confusion (you are not alone) is caused by misleading
example specfile in python packaging guidelines and lack of verbosity
about such cases, I already tried to argue about changing it
https://fedorahosted.org/fpc/ticket/558#comment:6
Lets assume python project named `example` which ships executable `example`:
1. `example` is pure application, supports Python3 -
I package it as `example` with executable `example` running on Python3, all
backend libraries will be also packaged under `example` rpm as they are not
meant
to be used as libraries in other projects
2. `example` is application and it also ships libraries which may be used in
other projects -
I package it as `example` which will ship executable `example` running on
Python3,
I will build it for both Python2 and Python3 and package its libraries under
python2-example and python3-example, (hence `example` will require
`python3-example`)
3. `example` is application with different behaviour for both major python
versions -
I package `example` as `python-example` with `python2-example` and
`python3-example`
subpackages carrying both backends libraries and executables, unversioned
executable
`example` will be packaged under `python2-example` (hence running on python2).
I hope it makes sense :)
> Jan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: python3-libs and python3-devel both provide libpython3.5m.so.1.0 in rawhide?
- Original Message -
> From: "Neal Gompa" <ngomp...@gmail.com>
> To: "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Saturday, November 14, 2015 3:03:01 PM
> Subject: python3-libs and python3-devel both provide libpython3.5m.so.1.0 in
> rawhide?
>
> Hello,
>
> I started trying to build packages for Fedora rawhide using various
> build environments (mock, obs-build, etc.), and I found an odd
> problem: some build environments (such as the openSUSE Build Service)
> cannot build to rawhide anymore since the python35 merge because both
> python3-devel and python3-libs provide libpython3.5m.so.1.0.
>
> My understanding is that the -devel package does not generally provide
> versioned libraries when the -libs package does already.
Hi Neal,
you are correct, this was added by mistake to -devel subpackage when
updating the spec file to python3.5.
Thank you for the report!
http://koji.fedoraproject.org/koji/taskinfo?taskID=11846048
>
> Is having both the libs and devel packages provide
> libpython3.5m.so.1.0 intentional?
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: python 3.5 openmp issue
- Original Message -
> From: "Orion Poplawski" <or...@cora.nwra.com>
> To: "Fedora Python SIG" <python-devel@lists.fedoraproject.org>, "Robert
> Kuska" <rku...@redhat.com>, "Matej Stuchlik"
> <mstuc...@redhat.com>, "Development discussions related to Fedora"
> <de...@lists.fedoraproject.org>
> Sent: Tuesday, November 10, 2015 10:43:21 PM
> Subject: python 3.5 openmp issue
>
> h5py build is failing with python 3.5:
>
> creating
> build/temp.linux-x86_64-3.5/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py
> gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fopenmp
> -fPIC -DH5_USE_16_API -I/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/lzf
> -I/opt/local/include -I/usr/local/include
> -I/usr/lib64/python3.5/site-packages/numpy/core/include
> -I/usr/include/python3.5m -c
> /builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.c -o
> build/temp.linux-x86_64-3.5/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.o
> In file included from /usr/include/python3.5m/pyatomic.h:12:0,
> from /usr/include/python3.5m/Python.h:53,
> from
> /builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.c:36:
> /usr/lib/gcc/x86_64-redhat-linux/5.2.1/include/stdatomic.h:40:1: sorry,
> unimplemented: '_Atomic' with OpenMP
> typedef _Atomic _Bool atomic_bool;
> ^
> /usr/lib/gcc/x86_64-redhat-linux/5.2.1/include/stdatomic.h:41:1: sorry,
> unimplemented: '_Atomic' with OpenMP
> typedef _Atomic char atomic_char;
> ^
>
> This appears to be https://bugs.python.org/issue25150 for which there appears
> to be a patch. Could this be applied please?
>
> Thanks.
Here you go
http://koji.fedoraproject.org/koji/buildinfo?buildID=698435
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@nwra.com
> Boulder, CO 80301 http://www.nwra.com
>
Regards,
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: python 3.5 openmp issue
- Original Message -
> From: "Orion Poplawski" <or...@cora.nwra.com>
> To: "Fedora Python SIG" <python-de...@lists.fedoraproject.org>, "Robert
> Kuska" <rku...@redhat.com>, "Matej Stuchlik"
> <mstuc...@redhat.com>, "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, November 10, 2015 10:43:21 PM
> Subject: python 3.5 openmp issue
>
> h5py build is failing with python 3.5:
>
> creating
> build/temp.linux-x86_64-3.5/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py
> gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fopenmp
> -fPIC -DH5_USE_16_API -I/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/lzf
> -I/opt/local/include -I/usr/local/include
> -I/usr/lib64/python3.5/site-packages/numpy/core/include
> -I/usr/include/python3.5m -c
> /builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.c -o
> build/temp.linux-x86_64-3.5/builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.o
> In file included from /usr/include/python3.5m/pyatomic.h:12:0,
> from /usr/include/python3.5m/Python.h:53,
> from
> /builddir/build/BUILD/python3-h5py-2.5.0-5.fc24/h5py/defs.c:36:
> /usr/lib/gcc/x86_64-redhat-linux/5.2.1/include/stdatomic.h:40:1: sorry,
> unimplemented: '_Atomic' with OpenMP
> typedef _Atomic _Bool atomic_bool;
> ^
> /usr/lib/gcc/x86_64-redhat-linux/5.2.1/include/stdatomic.h:41:1: sorry,
> unimplemented: '_Atomic' with OpenMP
> typedef _Atomic char atomic_char;
> ^
>
> This appears to be https://bugs.python.org/issue25150 for which there appears
> to be a patch. Could this be applied please?
>
> Thanks.
Here you go
http://koji.fedoraproject.org/koji/buildinfo?buildID=698435
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@nwra.com
> Boulder, CO 80301 http://www.nwra.com
>
Regards,
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] Ongoing rebuild of Python3.5 in Rawhide
- Original Message -
> From: "Kalev Lember" <kalevlem...@gmail.com>
> To: devel@lists.fedoraproject.org
> Sent: Thursday, November 5, 2015 10:10:59 AM
> Subject: Re: [HEADS UP] Ongoing rebuild of Python3.5 in Rawhide
>
> On 11/04/2015 12:23 PM, Robert Kuska wrote:
> > There is ongoing rebuild of Python3.5 in rawhide's side-tag f24-python3.
> >
> > I would like to ask all maintainers to rebuild their packages (which
> > depend on python3) within the f24-python3 side-tag.
> >
> > To rebuild your package simply run:
> > `fedpkg build --target f24-python3`
> >
> > You can find all packages that were already rebuilt here:
> >
> > http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
> >
> > Feel free to add your package once your build pass successfully. Side-tag
> > will be merged hopefully by the end of the week, mass rebuild will follow
> > to avoid breakage of rawhide.
>
> Thanks for doing this! Great to see Python 3.5 landing.
>
> I have a concern with the above plan though that says that Python 3.5
> will be merged into rawhide, followed by a mass rebuild. I would say it
> makes sense to do it the other way around though: First rebuild all the
> dependant packages in the side tag, and only then merge it all back into
> rawhide, avoiding breakage.
>
> You say that "mass rebuild will follow to avoid breakage of rawhide" --
> I am not sure how you mean this, but if the plan is to merge back Python
> 3.5 into rawhide and then wait for the F24 mass rebuild, I would say
> this is not a good plan. Please rebuild things before merging it back.
>
> The reason why I am saying that it is not a good plan to rely on the F24
> mass rebuild to rebuild all the Python modules is that the mass rebuild
> is done in alphabetical order, just going from a-z. This does not work
> for rebuilding large dependency chains because for those, you'd have to
> go in dependency order, waiting for lower level packages to hit the
> build roots before moving on to packages that depend on those. Regular
> mass rebuilds don't do this and as such, cannot be used for rebuilding
> big dependency chains such as the Python 3 stack.
I've rebuilt already 100+ packages, see
http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
for real time info about rebuild.
There is 970 packages that BuildRequires: python3-devel
http://paste.fedoraproject.org/286568/65788251/
I can't rebuild them all, I will try to get 200+- packages done before the
merge. It was stated in the Change that was accepted for this rebuild.
>
> Also, you've asked for individual maintainers to rebuild their packages
> on the side tag. Sure, it's great to give individual package maintainers
> an option to do it first, but you can't rely on that. I know how this is
> going to go: a few maintainers are going to rebuild their packages, but
> the vast majority won't. It will need action from the proposal owners to
> get everything rebuilt -- that what provenpackager access is for.
I know I can't rely on this and I don't expect many packagers to rebuild their
packages, yet it is still worth to give them this opportunity for those who
are proactive.
>
> --
> Kalev
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS UP] Ongoing rebuild of Python3.5 in Rawhide
There is ongoing rebuild of Python3.5 in rawhide's side-tag f24-python3.
I would like to ask all maintainers to rebuild their packages (which
depend on python3) within the f24-python3 side-tag.
To rebuild your package simply run:
`fedpkg build --target f24-python3`
You can find all packages that were already rebuilt here:
http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
Feel free to add your package once your build pass successfully. Side-tag
will be merged hopefully by the end of the week, mass rebuild will follow
to avoid breakage of rawhide.
Tracking bug to link rebuild related bugs to:
https://bugzilla.redhat.com/show_bug.cgi?id=1269756
https://fedoraproject.org/wiki/Changes/python3.5
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS UP] Ongoing rebuild of Python3.5 in Rawhide
There is ongoing rebuild of Python3.5 in rawhide's side-tag f24-python3.
I would like to ask all maintainers to rebuild their packages (which
depend on python3) within the f24-python3 side-tag.
To rebuild your package simply run:
`fedpkg build --target f24-python3`
You can find all packages that were already rebuilt here:
http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
Feel free to add your package once your build pass successfully. Side-tag
will be merged hopefully by the end of the week, mass rebuild will follow
to avoid breakage of rawhide.
Tracking bug to link rebuild related bugs to:
https://bugzilla.redhat.com/show_bug.cgi?id=1269756
https://fedoraproject.org/wiki/Changes/python3.5
--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: ansible in Fedora 23+ (python3)
- Original Message -
> From: "Kevin Fenzi" <ke...@scrye.com>
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, October 14, 2015 9:04:19 PM
> Subject: Re: ansible in Fedora 23+ (python3)
>
> On Wed, 14 Oct 2015 16:47:56 +
> Igor Gnatenko <i.gnatenko.br...@gmail.com> wrote:
>
> > Yes, DNF module works for ansible from the box. We worked at it for
> > some time: https://github.com/ansible/ansible-modules-extras/pull/527
>
> ...with the caveat from the first post in this thread: You will need to
> have the python2 dnf bindings installed for it to work.
>
> kevin
It seems to be python3 ready, isn't just changing shebang to /usr/bin/python3
sufficient?
--
Robert Kuska
{rkuska}
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announce: Group projects in Copr
- Original Message -
> From: "Miroslav Suchý" <msu...@redhat.com>
> To: "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Thursday, October 15, 2015 11:34:49 AM
> Subject: Announce: Group projects in Copr
>
> It is my pleasure to announce new version of Copr.
> https://copr.fedoraproject.org/
>
> What's new? Group projects!
>
Awesome feature, thank you!
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
(Another) One mailing list to rule them all
For those who are interested new (official) mailing list was created (kudos to
Nick
Coghlan and Barry Warsaw). The purpose of the mailing list is to bring together
all folks
from various Linux distro communities to discuss any future (e.g.
usr/bin/python)
or current features (/wave PEP476) affecting our beloved distributions and how
to
deal with them consistently :-).
Also here is Nick's reasoning:
> With the Python 3 migration, and the growth in interest in user level
> package management for development purposes, what do you think of the idea
> of setting up a new Linux SIG to have those discussions? I know it's a case
> of "yet another mailing list", but I think it will be worthwhile to have a
> clear point of collaboration within the Python ecosystem, rather than
> expecting Pythonistas to know how to reach out to (other) distros directly.
Don't hesitate and sign-in @ https://mail.python.org/mailman/listinfo/linux-sig
---
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat
- Original Message -
> From: "Matthew Miller" <mat...@fedoraproject.org>
> To: "Development discussions related to Fedora"
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, September 22, 2015 3:49:19 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal anything)
> bloat
>
> On Tue, Sep 22, 2015 at 05:07:58AM -0400, Matej Stuchlik wrote:
> > When it comes to python3, one way to shave off ~9MiB from
> > python3-libs, and possibly quite a bit more overall, would be to not
> > install both optimized and unoptimized bytecode, as we do now, but
> > just the unoptimized one (the performance hit should be very small).
> >
> > I'll look into if that could be done.
> >
> > We could also move few things from -libs to -devel, possibly.
>
> Cool. Let's put you on the future list for
> https://fedorahosted.org/fedora-badges/ticket/378 :)
I've tried to move idlelib and lib2to3 to -tools subpackage
but unfortunately I had to revert this change as distutils
uses lib2to3 module and idlelib is used by -tkinter meaning
that -tkinter would have to depend on -tools subpackage but
-tools already requires -tkinter so it would lead to cyclic dep.
>
>
>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: macros.python2 requires update in F21+
- Original Message -
> From: "Haïkel" <hgue...@fedoraproject.org>
> To: "Fedora Python SIG" <python-devel@lists.fedoraproject.org>
> Cc: "Alan Pevec" <ape...@gmail.com>, python-ow...@fedoraproject.org
> Sent: Thursday, September 10, 2015 10:16:43 AM
> Subject: Re: macros.python2 requires update in F21+
>
> Hi,
>
> Nobody answered, should I assume that everyone is ok with me pushing
> Orion's patches in F21 and F22?
>
> Regards,
> H.
>
> 2015-09-08 12:26 UTC+02:00, Haïkel <hgue...@fedoraproject.org>:
> > Hi,
> >
> > Recently, we had a lot of issues with openstack packages due to python
> > newer guidelines.
> > To fix upgrade path for python2 modules, you had to obsolete previous
> > python-xxx module.
> > Orion committed a fix in rawhide in the macro %python_provides that
> > fixes that issue.
> >
> > http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=7fdb9bedcda48894b7ba85e34ca5722b28b69076
> > http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=cb9dd734593c52b84f0b9b6f19f352001c1d50d3
> >
> > Could we backport these in F21/22/23 ?
> > It's rather critical, as we have less experienced packagers pushing
> > updates without checking
> > the upgrade path or provides/obsoletes. Having a reliable
> > %python_macros as in rawhide makes it more
> > robust and will avoid breaking users dependencies
> >
> > I prefer that python maintainers do the update as it's a critical
> > package, but I don't mind doing it in their stead
> > if you approve this (if necessary)
> >
> >
> > Regards,
> > H.
> >
>
Hi Haikel,
sorry for no response.
LGTM (as a co-maintainer)
--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3 additions to the Fedora 23 release notes?
- Original Message -
From: Bohuslav Kabrda sla...@redhat.com
To: Fedora Python SIG python-devel@lists.fedoraproject.org
Cc: Robert Kuska rku...@redhat.com
Sent: Thursday, August 27, 2015 11:33:51 AM
Subject: Re: Python 3 additions to the Fedora 23 release notes?
- Original Message -
Something Joe Brockmeier mentioned in his Fedora Marketing talk at
Flock last week was the need for development teams to be active in
providing content for the release announcements.
With the Fedora 23 Alpha coming out last week, I looked at the Release
Notes to see if there was anything about the Python 3 as default
change, but didn't see anything.
Was there something there and I just missed it, or does something need
to be written up and passed to the folks responsible for creating the
release notes?
Hi Nick,
a very good point! Since I'm not driving this effort any more and kind of
passed this along to Robert (mostly :)), he's the right person to ask:
Robert, would it be possible to make some release notes happen?
I will look into this :)
Thanks!
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
--
Regards,
Slavek Kabrda
--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: [Guidelines change] Changes to the packaging guidelines
- Original Message - From: Jason L Tibbitts III ti...@math.uh.edu To: devel-annou...@lists.fedoraproject.org Sent: Tuesday, August 4, 2015 11:34:06 PM Subject: [Guidelines change] Changes to the packaging guidelines Here are the recent changes to the packaging guidelines. - The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. The main guideline page has been slimmed down to show the more basic info and a clean and simple spec using the new macros which is free of multiline conditionals. boilerplate previously associated with python packages. Some of the more esoteric information has been moved to an appendix page to keep the main page of reasonable size. The new guidelines are currently only functional on Fedora 22 and newer releases, but are currently in updates-testing for Fedora 21 and EPEL7. The older guidelines are preserved in a separate page and we'll try to keep them updated with new requirements. The new guidelines page: * https://fedoraproject.org/wiki/Packaging:Python Sorry for late reply. From the Python packaging: # Must do the python2 install first because the scripts in /usr/bin are # overwritten with every setup.py install, and in general we want the # python3 version to be the default. %py2_install %py3_install I don't think that binaries of python module should be already switched to the state that non versioned binary is python3 binary. While /usr/bin/python points to /usr/bin/python2 and python-foo provides python2 version of the foo package I would expect binary foo to run on python2. This applies for modules binaries such as pytest (nosetests, pip, ...) where is difference between running python2 and python3 version of the binary. Currently we should have non versioned binaries to run on python3 only for python applications (devassistant) where both python2 and python3 version of the application provide same functionality. Therefore I suggest to switch order of pyX_install macros. The appendix: * https://fedoraproject.org/wiki/Packaging:Python_Appendix The old guidelines: * https://fedoraproject.org/wiki/Packaging:Python_Old Note that these cleaned up pages (and the old copy) include some new guidelines as well: There is new section indicating that -OO must not be used for python versions less than 3.5. * https://fedoraproject.org/wiki/Packaging:Python#Optimization There are requirements for what python module packages must provide (via Provides:): * https://fedoraproject.org/wiki/Packaging:Python#Provides Related FPC tickets: * https://fedorahosted.org/fpc/ticket/281 * https://fedorahosted.org/fpc/ticket/534 * https://fedorahosted.org/fpc/ticket/542 * https://fedorahosted.org/fpc/ticket/545 * https://fedorahosted.org/fpc/ticket/552 - Guidelines have been added covering services which need to perform setup when they are first started (including self-signed certificate generation). *https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup *https://fedorahosted.org/fpc/ticket/506 - The guideline on spec file naming was moved into the main guidelines and now requires that its name be constructed by taking the name of the source package and appending .spec. * https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_File_Naming * https://fedorahosted.org/fpc/ticket/553 - FPC can now grant exceptions to the regular package review procedures. * https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure * https://fedorahosted.org/fpc/ticket/539 * https://fedorahosted.org/fesco/ticket/1435 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] python34 packages for EPEL
.
Comments?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
--
Robert Kuska
{rkuska}
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Mass bug filing proposal - switching to Python3
- Original Message -
From: Vít Ondruch vondr...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, July 2, 2015 11:03:35 AM
Subject: Re: Mass bug filing proposal - switching to Python3
Dne 1.7.2015 v 15:33 Robert Kuska napsal(a):
Hello everyone,
I would like to start with Mass bug filing process and as stated
at wiki, the first step is to gain consensus for what I want to make.
Note please that this mass bug filing is conditioned with acceptance of
'Python3 as default' change which will be discussed at todays (01-Jul)
meeting. This mass bug filing aims for python applications.
What is python application?
Application foo is not meant to be used within others python libraries via
`import foo`
and both python3 and python2 versions of foo provides same functionality
and therefore
only one version is needed. This also includes scripts. DevAssistant is an
*application*
- We invoke DA and we don't care if it is python2 and python3 based, both
will fulfill
our task.
Will this be filled for every Python application in Fedora repositories
or just for the subset of application shipped on live cd? Do you have
already some list of such applications?
We aim for all Python applications. Currently we have only list of applications
shipped on live-cd, but of course we will also post the list of all
applications.
Is it needed to post the list along with the mass bug filing proposal?
To defend the need of filing against all applications:
At the most recent fesco meeting fesco members agreed to accept our Python3
as default change but under different name as they believe that calling Python3
the default interpreter in Fedora is misleading as the Fedora infra, packaging
tools
and many others applications which ain't covered by our change still need
Python2
to run. To address their concerns we've decided to pursue the usage of Python3
across
all Fedora packages (where possible).
Currently Python3 is the default interpreter in a sense of packaging only
but we would like to make it the default for Fedora as whole and this
mass bug filing is just a one of the milestones.
Vít
Bug description proposal follows:
With the recent change in packaging and upcoming system wide
change 'Python3 as default' Fedora is switching from using Python2
interpreter as default to Python3. This means that all applications
accessible through default Fedora repositories running or using Python
should run on/use Python3.
FAQ:
Q: How do I know if my application is using Python?
A: If this bug is filled against your application it is using Python
yet mistakes happen so if your application does not use Python (and you
double checked on that) please close this bug with a comment stating that.
Q: How to switch to Python3?
A: First, make sure that upstream supports Python3. Next switch
all macros to its python3 equivalents[0] and change all shebangs
using python or python2 to use python3, also replace all the dependencies
python2 dependencies. If stuck contact the reporter.
Q: What if upstream doesn't support Python3?
A: Don't switch to python3, open a bug in upstream asking to support
Python3,
help upstream with porting to Python3 (optional) and leave the fedora bug
opened
for tracking. Bug should be closed once the Python3 support is added.
[0]https://fedoraproject.org/wiki/Packaging:Python#Macros
Bug description ends.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mass bug filing proposal - switching to Python3
Hello everyone,
I would like to start with Mass bug filing process and as stated
at wiki, the first step is to gain consensus for what I want to make.
Note please that this mass bug filing is conditioned with acceptance of
'Python3 as default' change which will be discussed at todays (01-Jul)
meeting. This mass bug filing aims for python applications.
What is python application?
Application foo is not meant to be used within others python libraries via
`import foo`
and both python3 and python2 versions of foo provides same functionality and
therefore
only one version is needed. This also includes scripts. DevAssistant is an
*application*
- We invoke DA and we don't care if it is python2 and python3 based, both will
fulfill
our task.
Bug description proposal follows:
With the recent change in packaging and upcoming system wide
change 'Python3 as default' Fedora is switching from using Python2
interpreter as default to Python3. This means that all applications
accessible through default Fedora repositories running or using Python
should run on/use Python3.
FAQ:
Q: How do I know if my application is using Python?
A: If this bug is filled against your application it is using Python
yet mistakes happen so if your application does not use Python (and you
double checked on that) please close this bug with a comment stating that.
Q: How to switch to Python3?
A: First, make sure that upstream supports Python3. Next switch
all macros to its python3 equivalents[0] and change all shebangs
using python or python2 to use python3, also replace all the dependencies
python2 dependencies. If stuck contact the reporter.
Q: What if upstream doesn't support Python3?
A: Don't switch to python3, open a bug in upstream asking to support Python3,
help upstream with porting to Python3 (optional) and leave the fedora bug
opened
for tracking. Bug should be closed once the Python3 support is added.
[0]https://fedoraproject.org/wiki/Packaging:Python#Macros
Bug description ends.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Python 3 as Default
- Original Message -
From: Kevin Fenzi ke...@scrye.com
To: devel@lists.fedoraproject.org
Sent: Wednesday, June 17, 2015 9:11:36 PM
Subject: Re: F23 System Wide Change: Python 3 as Default
Greetings.
In today's FESCo meeting we had a lot of discussion about this change.
You can read the meeting yourself in:
http://meetbot-raw.fedoraproject.org/fedora-meeting/2015-06-17/fesco.2015-06-17-18.00.log.html#l-109
Speaking only for myself here:
I am very happy we are moving more things to python3 and I appreciate
it's a lot of work and effort. :)
I don't think we should use the word 'default' in this change unless we
define really what that means. It seems like it means different things
to different people.
It would be great to come up with an finished state for this, but I
don't know what it would really be. When all our tools used to build
Fedora are ported? When no python2 depending packages are in repos?
When python2 is no longer shipped?
It is written in a scope what does 'default' stands for.
Also from a additional porting POV (packages which ain't covered by scope
and are python2 only) it is important to have stated that the default python
for Fedora is python3 as it will help (a bit at least) as leverage for those
who are reluctant to port their codebase to python3.
After we get this change through we may focus on additional porting in next
fedora
releases (new system wide change [if needed] for fedora packaging tools for
example)
and again, use the already accepted fact about python3 being the default fedora
python.
From my POV it is very important to keep the 'default' in the change name.
My 2 cents.
kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Python 3 as Default
- Original Message -
From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
To: devel@lists.fedoraproject.org
Sent: Wednesday, June 10, 2015 10:05:41 PM
Subject: Re: F23 System Wide Change: Python 3 as Default
On Wed, Jun 10, 2015 at 08:50:14AM -0400, Jan Kurik wrote:
= Proposed System Wide Change: Python 3 as Default =
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
Change owner(s):
* Slavek Kabrda bkabrda at redhat dot com
* Matej Stuchlik mstuchli at redhat dot com
* Miro Hroncok mhroncok at redhat dot com
* Thomas Spura tomspur at fedoraproject dot org
* Robert Kuska rkuska at redhat dot com
Up until now, Fedora has used Python 2 as the default Python
implementation. This change proposes switching to Python 3. The details of
the term switching are explained thoroughly in the Scope section.
== Detailed Description ==
It is currently mature and stable, since it has been under active
development for five years
More than that, I'm sure.
== Scope ==
The main goal is switching to Python 3 as a default, in which state:
* DNF is the default package manager instead of Yum, which only works
with Python 2
Does that mean that dnf-3 is going to become the default which is installed
as /usr/bin/dnf?
Yes
Will old dnf be available as /usr/bin/dnf-2?
This decision is solely in the hands of dnf maintainers.
Looking at current state (f22):
rkuska@deimos ~ [11:03:23]
$ rpm -ql dnf | grep bin
/usr/bin/dnf
rkuska@deimos ~ [11:03:31]
$ rpm -ql python-dnf | grep bin
/usr/bin/dnf-2
rkuska@deimos ~ [11:03:35]
$ rpm -ql python3-dnf | grep bin
/usr/bin/dnf-3
the answer seems to be yes.
Changes in packaging:
* Change definition of default python interpreter to python3.
What does that mean?
* Change unversioned python macros to python3 (Possibly do that change
in upstream rpm)
Hm, I think that this will break hundreds of packages... Not everything has
been updated to use %{__python2} or %{__python3}, and of those that haven't
been
updated, many probably are not ready for switching to python3. I think it
would be better to avoid a flag day, and simply slowly switch packages
one by one.
This is already part of packaging guidelines so any package that is not using
versioned macros doesn't comply the guidelines and therefore should be fixed.
So either packagers will fix their packages themselves once they fail to build
during mass rebuild or we (owners of the change) will step in.
* All applications that use only a single python version MUST use
python3 (unless they have a good reason not to do so).
Do you intend to file bugs for all such packages or notify maintainers
in some other way?
This applies for new reviewed packages and for those who are installed
by default on different target releases (do we have a common name for different
fedora releases such as LiveDVD, Atomic, Cloud etc?) listed in scope and for
these
either already exist or we plan to open bugzilla reports.
Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Python 3 as Default
- Original Message -
From: Colin Walters walt...@verbum.org
To: devel@lists.fedoraproject.org
Sent: Wednesday, June 10, 2015 3:15:27 PM
Subject: Re: F23 System Wide Change: Python 3 as Default
On Wed, Jun 10, 2015, at 08:50 AM, Jan Kurik wrote:
* Python 3 is the only Python implementation in Atomic host
That's not going to happen unless Ansible learns how to deal
with Python 3 at least:
Does it mean that Ansible is shipped by default with Atomic host?
We were working with data provided by
https://git.fedorahosted.org/git/fedora-atomic.git
and there is no ansible listed within packages.
https://lists.fedoraproject.org/pipermail/devel/2015-January/206903.html
So again, this change is very likely to be Add Python 3 by default and port
a lot of things at least for the base Server and Atomic Host. Other
configurations like the Docker base image are more realistic to have Python
3 only.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-easy-karma: InsecurePlatformWarning
- Original Message -
From: Pekka Pietikäinen p...@ee.oulu.fi
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Friday, June 5, 2015 8:09:49 AM
Subject: Re: fedora-easy-karma: InsecurePlatformWarning
On 28/04/15 21:17, Cole Robinson wrote:
On 04/28/2015 01:32 PM, Reindl Harald wrote:
i am not sure for which package file a bug
Waiting for Bodhi for a list of packages in updates-testing (F21)...
/usr/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL
Pretty sure due to busted urllib3. This bug is tracking a similar issue
Seems this is still unaddressed for quite some time.
Not really busted, it just (rightly) complains that it's being used
with a version of Python (2.7.8) that makes proper use of SSL impossible
without adding extra dependencies...
Easiest fix is to disable the warnings (ONLY for F21) per package or
patch/downgrade urllib3. Right fix is to bump Python to 2.7.9 or .10,
but that will cause random unexpected breakage for a lot of people.
We do not plan to upgrade Python to 2.7.9 in Fedora 21 and lower
for the exact reason you've mentioned.
Can't speak for urllib3 maintainers (maybe they patch the warning)
but if you wish to get rid off warnings update to Fedora22.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Python3 as default
- Original Message -
From: Toshio Kuratomi a.bad...@gmail.com
To: Fedora Python SIG python-devel@lists.fedoraproject.org
Sent: Friday, April 17, 2015 2:14:20 PM
Subject: Re: Python3 as default
On Apr 15, 2015 2:57 AM, Robert Kuska rku...@redhat.com wrote:
pip is not a application, even though it is not used via import statement
both python3 and python2
versions provides different functionality (python-pip installs python2
packages and python3-pip
installs python3 packages), therefore it is a *module*.
This should probably be phrased differently in the final draft. Pip is an
application. But because we need it to provide both a python 2 and python 3
cli tool it follows the same guidelines as dual-python-version modules
rather than applications. This category might even deserve its own
subsection as there's a couple other specific things to do with these types
of packages.
Yes, I agree that this needs better wording for the guidelines draft.
*MODULES*
M1. First of all, all *modules* which aren't using versioned macros must be
fixed to use them.
This can be done right away as this is already part of packaging guidelines
and all packages
should comply with guidelines.
* Note: There is around of 1000 packages using unversioned macros [3]
M2. We should add provides for python2-foo modules. So python-foo would
provide python2-foo.
I'd make the following its own should bullet as the first part of M2 is more
important. the python-foo package names aren't going away so if we get into
a time crunch for f22, this second portion isn't as critical as the first.
That's a good point as it will save us from the figuring out the
rebuild dependency chain.
Fix all the modules to (Build)Require python2-bar instead of python-bar
(python should
also provide python2).
Also if module foo ships bin file `baz` it should have `baz` and
`baz2` bin file inside `python-foo` and `baz3` file inside `python3-foo`.
I disagree with this but I think it's probably just an omission of some
information. We need to make clear here that this is only for bin files
where it is necessary to shop a version that runs on py2 and a version that
runs on py3. Most packages should just ship one version of the bin scripts
for the default python version. (Note, I don't think we can wrap this choice
into a convenient macro. It'll probably need a spec file conditional if
packagers want to have a single spec for multiple branches.)
That's meant to be only for the applications like a modules/modules like a
applications
(pip, pytest and similiar).
I agree that that /usr/bin/foo is enough for an (pure) application module. No
need for a versioned one.
M3. All modules should be build with option
--executable='/usr/bin/python(2,3)'. This could be
resolved in [4]
I'm not sure if this is true. Pure modules don't have a shebang line so I
think the choice of which python interpreter runs them and determines the
path they install into is sufficient.
Again, this point was constructed with an assumption of pip and pytest being
(kind of) modules and also with a possibility of creating macros for easier
packaging which contain `--executable` in the draft.
From a message from ncoghlan a long time ago I think things in bin should use
/usr/bin/python(2,3) in their shebang as long as the setup.py is invoked
with the versioned path. So --executable is extraneous for these purposes.
(But if [4] is the -s guideline update, we would want to use --executable
for that purpose for packages providing things in bin).
*APPLICATIONS*
A1. All application must use the default python (of course only if upstream
supports it).
Applications can continue using {__python} macros and it derivatives. We
should add a macro
for (Build)Requires:
%global py_default_major 3 # this could be part of f23 buildroot macros
BuildRequires: python%{?py_default_major}-foo
This way would maintainer have same specfile for both fedora and epel and
also if the default
python will change in the future the only thing that would need a change is
the `py_default_major`
value or we could make the value to be resolved by %{__python} macro.
A2. Same as M3 (=should be resolved by [4]).
*{__python} VS /usr/bin/python CONFUSION*
Why is value of {__python} being changed and /usr/bin/python (along with
python-foo being python2)
is untached? I see this as two different situations or two different point
of views.
/usr/bin/python is a *user view*, as a user I would expect when I type
python that it would fire
up python2 interpreter as this is the default behaviour for all(-ArchLinux)
distros and also
python.org recommendation. Similarly when I type `sudo dnf install
python-foo` I would expect
to receive python2 version of foo package. This is why we stay with
/usr/bin/python pointing
to python2 and python-foo
Re: Python3 as default
(I've miss hitted enter and sent the email earlier)
- Original Message -
From: Robert Kuska rku...@redhat.com
To: Fedora Python SIG python-devel@lists.fedoraproject.org
Sent: Monday, April 20, 2015 10:05:44 AM
Subject: Re: Python3 as default
- Original Message -
From: Toshio Kuratomi a.bad...@gmail.com
To: Fedora Python SIG python-devel@lists.fedoraproject.org
Sent: Friday, April 17, 2015 2:14:20 PM
Subject: Re: Python3 as default
On Apr 15, 2015 2:57 AM, Robert Kuska rku...@redhat.com wrote:
pip is not a application, even though it is not used via import statement
both python3 and python2
versions provides different functionality (python-pip installs python2
packages and python3-pip
installs python3 packages), therefore it is a *module*.
This should probably be phrased differently in the final draft. Pip is an
application. But because we need it to provide both a python 2 and python 3
cli tool it follows the same guidelines as dual-python-version modules
rather than applications. This category might even deserve its own
subsection as there's a couple other specific things to do with these types
of packages.
Yes, I agree that this needs better wording for the guidelines draft.
*MODULES*
M1. First of all, all *modules* which aren't using versioned macros must
be
fixed to use them.
This can be done right away as this is already part of packaging
guidelines
and all packages
should comply with guidelines.
* Note: There is around of 1000 packages using unversioned macros [3]
M2. We should add provides for python2-foo modules. So python-foo would
provide python2-foo.
I'd make the following its own should bullet as the first part of M2 is
more
important. the python-foo package names aren't going away so if we get into
a time crunch for f22, this second portion isn't as critical as the first.
That's a good point as it will save us from the figuring out the
rebuild dependency chain.
Fix all the modules to (Build)Require python2-bar instead of python-bar
(python should
also provide python2).
Also if module foo ships bin file `baz` it should have `baz` and
`baz2` bin file inside `python-foo` and `baz3` file inside `python3-foo`.
I disagree with this but I think it's probably just an omission of some
information. We need to make clear here that this is only for bin files
where it is necessary to shop a version that runs on py2 and a version that
runs on py3. Most packages should just ship one version of the bin scripts
for the default python version. (Note, I don't think we can wrap this
choice
into a convenient macro. It'll probably need a spec file conditional if
packagers want to have a single spec for multiple branches.)
That's meant to be only for the applications like a modules/modules like a
applications
(pip, pytest and similiar).
I agree that that /usr/bin/foo is enough for an (pure) application module. No
need for a versioned one.
M3. All modules should be build with option
--executable='/usr/bin/python(2,3)'. This could be
resolved in [4]
I'm not sure if this is true. Pure modules don't have a shebang line so I
think the choice of which python interpreter runs them and determines the
path they install into is sufficient.
Again, this point was constructed with an assumption of pip and pytest being
(kind of) modules and also with a possibility of creating macros for easier
packaging which contain `--executable` in the draft.
https://fedorahosted.org/fpc/ticket/281#comment:19
From a message from ncoghlan a long time ago I think things in bin should
use
/usr/bin/python(2,3) in their shebang as long as the setup.py is invoked
with the versioned path. So --executable is extraneous for these purposes.
(But if [4] is the -s guideline update, we would want to use --executable
for that purpose for packages providing things in bin).
*APPLICATIONS*
A1. All application must use the default python (of course only if
upstream
supports it).
Applications can continue using {__python} macros and it derivatives. We
should add a macro
for (Build)Requires:
%global py_default_major 3 # this could be part of f23 buildroot macros
BuildRequires: python%{?py_default_major}-foo
This way would maintainer have same specfile for both fedora and epel and
also if the default
python will change in the future the only thing that would need a change
is
the `py_default_major`
value or we could make the value to be resolved by %{__python} macro.
A2. Same as M3 (=should be resolved by [4]).
*{__python} VS /usr/bin/python CONFUSION*
Why is value of {__python} being changed and /usr/bin/python (along with
python-foo being python2)
is untached? I see this as two different situations or two different
Python3 as default
version of an interpreter = I am not confused its
just *python* for me and
*python* is the default distro python.
*FUTURE*
These suggestions (M1-M3, A1-A2) I've listed here are minimal changes needed
for the Python3 as a
default change. There is of course much more to deal with but for f23 timeframe
it should be
enough as it doesn't seem that /usr/bin/python will point to python3 any time
soon [citation needed].
If those changes get accepted I would like to start applying them right away
(for F23+ branches)
because they should work even with __python macro still pointing to
/usr/bin/python(2):
1. Fix all the modules specfiles and rebuild them because of new provides
python2-foo.
2. Fix all the applications specfiles. (Rebuild is not needed.)
3. Change the default macro to point to /usr/bin/python3 (when anaconda is py3
ready)
4. Rebuild applications
5. Fix those which fails to build
6. Profit
--
Robert Kuska
{rkuska}
[0] https://etherpad.mozilla.org/ep/pad/view/2Uqk0ikCll/vFEmg9YT2h
[1] https://fedorahosted.org/fpc/ticket/498
[2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[3] https://pastebin.mozilla.org/8829944 (silly script used may miss some may
contain redudant)
[4] https://fedorahosted.org/fpc/ticket/513
--
Robert Kuska
{rkuska}
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: mock, megadeps and PyPI
- Original Message - From: Nick Coghlan ncogh...@redhat.com To: Fedora Python SIG python-devel@lists.fedoraproject.org Sent: Thursday, August 21, 2014 2:35:48 AM Subject: mock, megadeps and PyPI Jeff Fearn reminded me today of mock --megadeps, a patched version of mock he created that supports recursively downloading and building dependencies in a chroot, without incurring the overhead of setting up and tearing down multiple mock build environments the way the chainbuild command does. The mock RFE is at https://bugzilla.redhat.com/show_bug.cgi?id=843745, while Jeff is now maintaining the patched version at https://github.com/jfearn/mock I'm bringing this to folks attention mainly due to one of the neat features it has embedded in it, which is integration with CPAN: it can use cpanspec to create an SRPM on the fly. That's likely not going to be of suitable quality for Fedora itself, but it should be good enough for COPR and potentially even Playground. My question is whether it would be practical to do something similar with pyp2rpm. Bonus points if we can come up with a way to integrate it nicely with COPR, or even tidy up the implementation to the point where we can convince Clark to accept the feature as part of mock itself :) Hi Nick, I have created vague named issue[0] at pyp2rpm repo we can discuss it there. I will post my opinion later, next week probably, currently I am off from work. Regards, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane HSS Provisioning Architect ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel Regards, Robert Kuska - rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat [0] https://bitbucket.org/bkabrda/pyp2rpm/issue/13 ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Heads up: Python: SSL module backported from Python3 in Rawhide
Hi everyone, I've just pushed update [0] to Python 2.7.8 in Rawhide which backports Python3 SSL module into Python2, this patch was created by upstream [1] and will be part of Python2 in the next release. This effort already discovered minor issue in test_ssl.py [2] while scratch building. Next step of this effort is (scratch-)rebuilding some ssl dependant packages in Rawhide, once updated Python2 is built [3]. If you know that your package is using ssl from std lib please rebuild it and share the feedback with me/us. Thank you Regards, Robert Kuska - rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat [0] http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=833dc39f61926c2fb84d9880dd43c81aab1479ec [1] http://bugs.python.org/issue21308 [2] http://bugs.python.org/msg225489 [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=7426209 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: SSLv2|3 disabled by default in OpenSSL f21
Just a notice about downstream behaviour change in fedora 21 before you find out the harder way as I did. Starting with openssl-1.0.1h-5.fc21[1] SSLv2 and SSLv3 are disabled by default in fedora openssl. This change is not in upstream (but may get there by v1.0.3). Workaround is to use SSL_CTX_clear_options[2]. Regards, Robert Kuska - rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=540893 [2] https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: request for pygrib packaging debug help
- Original Message -
From: Jos de Kloe josdek...@gmail.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, 3 July, 2014 12:07:28 PM
Subject: request for pygrib packaging debug help
Hi everyone,
I am having a small issue with the pygrib package that I am maintaining.
The package depends on pyproj, but when I install it with yum it also
pulls in python3-pyproj.
All python3 related things are wrapped in %if 0%{?with_python3}
macros, so this should not happen I think.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
Best regards,
Jos de Kloe
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
You must move Python 3 Requires into Python 3 subpackage
between lines 89 and 101 in your specfile.
Regards,
Robert Kuska
-
rkuska @
#fedora-devel on freenode
#brno #gulag #software-collections on brq.redhat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Separate system-supplied packages
Hello everyone, just in case you missed it, I have started discussion about $SUBJECT on pypa-dev[1]. Feel free to join in. Regards, Robert Kuska - rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat [1] https://groups.google.com/forum/#!topic/pypa-dev/r6qsAmJl9t0 ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: DeveloperAssistant and android development under Fedora 19
Hi Petr, IntelliJ is not in Fedora, it was retired [1]. And if I understand correctly to documentation of Android Studio it won't be even needed. Android Studio is in Early Access Preview and is licensed under Apache 2.0 [2], IMO you should wait for stable release for packaging into Fedora and there is no problem to include any package into f19 branch [3]. [1]http://pkgs.fedoraproject.org/cgit/intellij-idea.git/commit/?id=f39f76f10d1150b7626298cc935f8850535f7cdd [2]http://en.wikipedia.org/wiki/Android_Studio [3]https://fedoraproject.org/wiki/Package_SCM_admin_requests - Original Message - From: Petr Hracek phra...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, 9 August, 2013 11:44:01 AM Subject: Re: DeveloperAssistant and android development under Fedora 19 Hi Mat, you mean F20, right? Would it be possible to release that IntelliJ into F19 although it is already released? On the other hand I think that in Fedora we can have both. As IntellJ as ADT Plugin. Greetings Petr On 08/09/2013 11:31 AM, Mat Booth wrote: On 9 August 2013 09:22, Krzysztof Daniel kdan...@redhat.com wrote: Hello everyone, ADT is not packaged, and AFAIK nobody is working on that. I'm also not sure if it is suitable for Fedora (they had some restrictions in their terms of use, but it would require double check). However, Fedora Eclipse should work well with ADT installed via update site - there were some issues with in the past - but I believe that from f18 everything is right At this point it's probably not worth packaging the ADT Eclipse plug-ins for Fedora because the next major release is going to be based on IntelliJ: http://developer.android.com/sdk/installing/studio.html -- Best regards / S pozdravem Petr Hracek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 20
I have written early in the morning to Ben asking him why he orphaned jsonpickle. I was willing to take over this package after his response (haven't received yet) so if you are looking for co-maintainer I am here. Regards Robert Kuska - Original Message - From: Jon Ciesla limburg...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, 7 August, 2013 2:30:19 PM Subject: Re: [ACTION REQUIRED] Retiring packages for Fedora 20 Package gnome-vfs2 (orphan) Package gnome-vfs2-monikers (orphan) Package python-jsonpickle (orphan) I've taken these. Co-maintainers welcome. -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
