Re: Adjusting the way Fedora runs Python's test suite

[Bohuslav Kabrda]

On Thu, Jul 20, 2017 at 7:51 AM, Nick Coghlan  wrote:

> Hi folks,
>
> While working on bootstrapping a new community sclo-python collection,
> I ran into some readability problems with the way the SCL Python spec
> file runs the test suite: it uses --verbose mode, which means there's
> a lot of noisy output to sort through to find the actual failure when
> something goes wrong.
>
> Charalompos pointed out that since the SCL spec file is ultimately
> derived from the Fedora one, Fedora would be the best place to file an
> issue suggesting some changes, which I've now done:
> https://bugzilla.redhat.com/show_bug.cgi?id=1473130
>
> The main suggestion there is one that's a clear win: replace the
> current "--verbose" with "-wW" instead, so that the tests are run in
> non-verbose mode by default, but if one fails, not only will the test
> suite print out any captured output, but it will also immediately
> rerun the failed test in verbose mode.
>
>
+1, that sounds great.


> However, I also noted some other possibilities that seem worth discussing:
>
> * checking for refleaks means we can't run parallel tests across
> multiple processes. If we were to move refleak testing out to an
> integration test in Taskotron, then the tests could be run with the
> "-j4" option, significantly reducing the time needed to run the %check
> step
>
>
If it's possible to move this testing to taskotron, then it sounds ok to me.


> * the `--failfast` option causes the tests to be aborted as soon as
> one fails. While that doesn't make any difference in the success case,
> it will mean faster turnaround cycles in the case where one fails. I'm
> less sure of the value of this one, as the downside is that if you're
> getting multiple failures, you only find out about them one at a time.
>
>
I'd suggest to not use this. Back when I was Python maintainer I used this
option sometimes when updating Python and building locally, but for builds
in Koji, you don't want to use it. What you want is to see logs of all the
failed tests in Koji logs and then be able to work on the first, submit a
build when you have a fix and *in the meanwhile* (which in terms of
building Python can be couple dozen minutes) work to fix other bugs... And
repeat that until you fix all. If you did use this flag, you'd have to
build, fix one bug, submit a build, wait a long time, fix another bug,
submit a build, wait a long time, fix another bug, etc.


> * there's a `--slowest` flag in recent releases that lists the 10
> slowest tests in a given run. As far as I know, it doesn't add much
> overhead to the test execution process, and provides an indicator of
> where to focus efforts if the goal is to make the tests more
> efficient.
>
>
Yeah, I think improving the performance of the slowest tests could be gain
for everyone, not just for Fedora.


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
>



-- 
Regards,
Slavek Kabrda
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3 additions to the Fedora 23 release notes?

[Bohuslav Kabrda]

- 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?

Thanks!

 Regards,
 Nick.
 
 --
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Handing over Python maintenance and Python 3 as Default

[Bohuslav Kabrda]

Hi all,
for past two years I've been paid by Red Hat to work on Python maintenance in 
Fedora (among other things). Since I'm now moving to a different position 
inside Red Hat, I'll be handing over my work to some of my fellow teammates:
- python and python3 will be maintained by Matej Stuchlik (mstuchli at 
redhat.com) from now on
- Python 3 as Default effort will be continued by Robert Kuska (rkuska at 
redhat.com)

I'll be staying in this awesome community, I just won't be able to dedicate 
that much time to it. Matej and Robert have been working with me for quite some 
time on the above things and they'll do an excelent job.

Thank you for your attention,
Slavek
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

- Original Message -
 On 27 February 2015 at 11:02, Toshio Kuratomi a.bad...@gmail.com wrote:
 
  On Feb 25, 2015 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
 
  For those not following along with the FPC ticket, Toshio and Tomspur
  have a nice write-up of the options at
  https://etherpad.mozilla.org/2Uqk0ikCll
 
  I came back to this question myself due to a couple of different
  ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19
 
  * How does the situation in Fedora change if the upstream PEP 494
  recommendation to downstream Linux distros was to change in
  conjunction with the Python 3.5 release currently scheduled for
  September? That release (https://www.python.org/dev/peps/pep-0478/)
  amongst other things, automatically handles EINTR errors for syscalls,
  restores binary interpolation support and adds matrix multiplication
  support and os.scandir().
 
 
  I would be against making the switch to /usr/bin/python at this time but
  would do most of that fighting upstream.  If the pep were updated then I'd
  at least want to see that the other major distros are committed to changing
  their /usr/bin/python at the same time.
 
  Changing the behavior of a well known program like this is a bad idea.  As
  it breaks compatibility: with people's home grown scripts, with their self
  installed programs, and between os's and os releases. The pep is palatable
  because the arguments in favor of someday changing the value revolve around
  someday there not being a /usr/bin/python on most systems. At that point it
  becomes reasonable to reallocate /usr/bin/python and let the systems where
  /usr/bin/python be declared legacy and the behavior of /usr/bin/python on
  those legacy systems is the quirk, not ours.
 
  We could cut over sooner than this argument actually makes the case for but
  now is definitely not that day.  Fedora, rhel, ubuntu, aren't yet at the
  point where /usr/bin/python isn't present on most of their installed
  systems
  in their latest version, let alone all of their versions.people are still
  pulling /usr/bin/python onto their systems through dependencies for common
  applications even if their os is advanced enough not to need it by default.
  We have quite a ways to go before /usr/bin/python can be switched.
 
 Yeah, that's fair - a staggered release with the distros switching
 first before end user scripts makes sense. That would make the likely
 target date for a PEP 394 update some time in early 2017 with Python
 3.6.
 
 We could *potentially* switch the recommendation some time in 2016 if
 all goes well with the distro migrations and significant libraries
 start dropping Python 2.7 support, but switching in conjunction with
 Python 3.5 would still be too soon.

+1 to switch with Python 3.6. PEP 394 should however be made to reflect this 
ASAP - I mean it should be made to say that this change will happen with Python 
3.6. The sooner it says that, the more time for people to notice it and more 
time for distros to prepare.

  * With the default interpreter change postponed to Fedora 23, would it
  make sense to patch the system Python in Fedora 22 to emit Python 3
  warnings by default when it was run using the unqualified python
  reference rather than being run as the qualified python2? And then
  switch the symlink along with the RPM macros in Fedora 23?
 
 
  No to switching the value of /usr/bin/python and stated above.  The test
  makes some sense. If your warning is restricted to warning not to use
  /usr/bin/python (use /usr/bin/python 2 instead) that sounds really good to
  me.  (Your wording sounded like we should turn on warnings like python2 -3
  does which I don't think is such a good idea for fedora 22 but might be
  good
  in the future... our perhaps, like the kernel does with extra kernel
  debugging, we should turn it on in rawhide and fedora.n+1 but turn it off
  before release.)
 
 I did mean the latter (turning on -3 warnings), but I like your idea
 of only doing that in Rawhide and the Alpha releases for F23, and then
 switching to a simple use a qualified Python reference warning in
 the Betas and the actual release.

I'm also +1 on emitting a warning about /usr/bin/python usage, although I'm 
almost sure that will break something. There are always apps that expect 
certain form of subprocess output etc - and this will break them. IMO this 
should only be done in F23, not in F22 which is already in alpha.
I'm assuming that there is no builtin configure option to emit this warning and 
we'd have to patch this ourselves, is that right or have I just missed such 
option?

  It's also worth noting that the change I am considering to the
  upstream recommendation would place a qualifier on the distro
  providing a C.UTF-8 locale, so the C.UTF-8 in upstream glibc RFE
  (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a
  key enabler for making the symlink switch in Fedora (associated Fedora
  RFE: 

Re: Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

- Original Message -
 I don't really feel strongly about this, I agree that your solution has a
 merit (and syspython *is* better than default_python :)). I think I'll open
 an FPC ticket to ask FPC for their opinions on this and then I'll start
 taking concrete steps [1] ;) to get this done.

Here's the FPC ticket: https://fedorahosted.org/fpc/ticket/498

  -Toshio
 
 Slavek
 
 [1] http://www.sevenstarconcrete.com/images/exposed_double_stair_case.jpg

Slavek
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

- Original Message -
  I will. Do you have any idea who I should talk to regarding EPEL? Is it
  also Dennis?
 
 Also dennis.  Rel-eng is growing as a group so you could also put in
 a ticket/go to one of their weekly meetings but Dennis is probably still the
 one that knows the most about koji and buildroots.

Thanks, I'll talk to him.

I think this solution makes sense for *applications* that need to be
built
both in Fedora and in EPEL. Note that it'd also align with my
EPEL-python3
proposal [1], in case such an app was to be moved to python3X in EPEL
(%default_python would just be redefined to python3X). I also think
that
this approach should never be allowed for packaging libraries, e.g.
packages that have python-foo and python3-foo subpackages.

Thoughts?
   
   If we were to use different macro names instead of overwriting currently
   well known ones I think this has merit.
  
  For me, introducing yet another set of macros is unnecessary. I think that
  it'd introduce a long(-ish) new part of guidelines that'll make them even
  more complicated than they are right now (compared to one new macro
  function and rules on how/when to use it).
 
 Nick's breakdown of the three desired states seems like a non-complex way to
 organize things.  And explicit being a good thing is also a winner for me.
 In addition to my original arguments that bashing existing macro names in
 some spec files but not in all of them is a bad thing to force packagers to
 have to deal with.
 
 tangentially, when speaking about long-ish, though, could we use something
 shorter than default_python?  Maybe syspython to follow Nick's usage of
 System Python?

I don't really feel strongly about this, I agree that your solution has a merit 
(and syspython *is* better than default_python :)). I think I'll open an FPC 
ticket to ask FPC for their opinions on this and then I'll start taking 
concrete steps [1] ;) to get this done.

 -Toshio

Slavek

[1] http://www.sevenstarconcrete.com/images/exposed_double_stair_case.jpg
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

- Original Message -
 On 28 January 2015 at 03:32, Toshio Kuratomi a.bad...@gmail.com wrote:
  On Tue, Jan 27, 2015 at 10:50:07PM +1000, Nick Coghlan wrote:
  What if, instead, we were able to add a new macro that let folks
  *explicitly* opt in to running in the system Python, but then define
  the recommended spec file usage such that it falls back to Python 2 if
  the system Python macro isn't defined?
 
  Slavek raises the issue of how we get this into the buildroot.  An idea
  could be to talk to rel-eng and the other packagers about adding these
  sorts
  of system-feature macros to a package in the buildroot.  We could create
  a new package or add onto an existing one (is epel-release and
  fedora-release in the buildroot?)  the package would contain a small set of
  macros that specified certain features about the OS that packagers need to
  know
  Then we really could write the conditionals as a feature test instead of
  a distro version test.
 
  One drawback is that we would have to push the macros out to every release
  that we build for (epel and fedora) otherwise we'd still have to use
  distro+version  conditionals.
 
 That sounds vaguely analogous to the situation we have in Beaker:
 adding completely new system features may require a Beaker server
 update, while enabling and disabling already known features for a
 custom distro is just a configuration setting for that distro in the
 database. Actually switching to that model required updating the base
 templates for every distro we natively support.
 
 The reason we decided that approach was worth the extra up front
 effort was because it meant we just had one place to update in the
 future (the code that handles the calculation of the distro - feature
 mappings) rather than having to search the templates for all the cases
 where we were switching based on the distro.
 
 I personally think do it right (i.e. figuring out how to enable
 feature based rather than version based checks) is the direction we
 should go for Fedora  EPEL, and then Slavek  I can separately tackle
 the challenge of getting key downstreams (i.e. RHEL  CentOS) to go
 along with that change. I'm more optimistic than Slavek is about that,
 as many of the reasons we made the change for the Beaker kickstart
 templates also apply to building for different environments.

I'll try to find out what it'd take to add such a package to epel minimal 
buildroot and fedora minimal buildroot and we'll see. I actually have one more 
use case for this and that is the Py3 in EPEL, where having some macros in 
minimal buildroot would help a lot, too.

I'll try to find out ASAP and post the result here.

Slavek

 Regards,
 Nick.
 
 --
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: python-sig and retiring python3-dateutil

[Bohuslav Kabrda]

- Original Message -

 Pete Travis  m...@petetravis.com  schrieb am Mon Jan 26 2015 at 5:24:32 PM:

  On 01/26/2015 08:53 AM, Zbigniew Jędrzejewski-Szmek wrote:
 
   Hi,
 
  
 
   since bug #1126521 seems to be progressing nicely, I think it would be
 
   nice to get in touch with python-sig, the maintainers of
 
   python3-dateutil, about retiring python3-dateutil and adding a python3
 
   subpackage to python-dateutil. They might want to do it the other way
 
   around, which would be fine too, but either way, something should be
 
   arranged.
 
  
 
   I tried to sign up for the python-sig mailing list, but it is
 
   private and I haven't received any welcome letter, so I think I'm
 
   stuck in some moderation queue.
 
  
 
   Zbyszek
 

  Yes, I think it's a good time to bring up retiring python3-dateutil.
 
  I've also requested membership for that list, and included the list
 
  owners here, maybe they can expedite our requests.
 

 As python-dateutil is not (yet) under the python-sig group maintainership
 [1], you could reach the maintainers of python-dateutil under ther -owner
 mail address (CC'ed).
 python-sig@fp.o is for all group maintained package maintainers and general
 python related questions are handled on python-devel@fp.o (also CC'ed).
 (Sorry for the confusion, the python-sig groupmaintainership started very
 recently and is still a work in process.)

 I'd say it depends, how python3 will be introduced in F22, which package
 should provide the subpackage and the other one should be retired.
 Maybe someone from [2] could comment on what they like to see in the future.
 I don't mind having two separate packages until we approach F22 and the
 future process is here.

 Greetings,
 Tom

 [1] https://admin.fedoraproject.org/pkgdb/package/python-dateutil/
 [2] http://fedoraproject.org/wiki/Changes/Python_3_as_Default

Packaging Python extension modules should keep working the way it did up until 
F21. python-dateutil will still be the Python2 build, python3-datetuil will 
still be the Python3 build. There are some guidelines changes that I proposed 
for F22 [1], but I think they don't influence dateutil. 

Slavek 

[1] https://fedorahosted.org/fpc/ticket/475#comment:5 
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

Hey all,
I just wanted to ask for some thoughts on a problem (or rather a hardship) 
that is starting to show with the Python 3 transition in Fedora.
I've been contacted by two maintainers of applications in Fedora for advice 
and have been thinking for some time how to solve this:

Note: by applications I mean packages that provide end-user benefit and don't 
need to be packaged for both Python interpreters. They just use some Python 
(preferably the default one) to deliver functionality to user. Let's take 
copr-cli as an example - this is a thin CLI wrapper around python-copr.

Current state:
- Up until F21, maintainers were encouraged to build applications with Python 
2, but weren't discouraged from building with Python 3.
- From F22 on, packagers will be encouraged to build with Python 3 rather than 
Python 2.
- Lots of packagers want to keep the same specfile for EPEL and Fedora.
- Fedora guidelines mandate explicit usage of %__python2 and %__python3 (and 
all the sitelib/sitearch macros).

The Problem:
If packagers want to build against Python 3 in Fedora and Python in EPEL *and* 
keep the same specfile, they have to invent some ugly hacks, since Fedora's 
guidelines require explicit usage of versioned Python macros. This affects 
Requires and BuildRequires and %prep, %build, %install, %check sections. People 
who want to do this either redefine %__python in Fedora to point to Python 3 or 
something like that - I'm afraid that we could end up with a huge pile of crazy 
macro redefinitions in tons of packages and I want to avoid that.

Proposed Solution:
After thinking a few days about this, here's what I propose:
- Every specfile will have a minimal header with macro definitions that will 
look like this:

%if 0%{?fedora}
%global default_python python3
%else
%global default_python python
%endif

%make_default_python %default_python

- The %make_default_python macro function will point all the unversioned macros 
to proper values for given %default_python:

### In Fedora
%{__python}- /usr/bin/python3
%{python_sitelib}  - /usr/lib/python3.X/site-packages
# and other macros...

### In EPEL
%{__python}- /usr/bin/python2
%{python_sitelib}  - /usr/lib/python2.X/site-packages
# and other macros...

- This means that packagers will be able to use the unversioned macros 
throughout their specfile. Requires and BuildRequires will look like this:

Requires: %{default_python}-flask
BuildRequires %{default_python}-setuptools

Note: since BuildRequires need to be expanded in the minimal buildroot, it's 
necessary to define the %default_python macro in the specfile. Other way would 
be to define it in a macro file that would be added to the minimal buildroot, 
but that's neither very likely nor very nice :)


I think this solution makes sense for *applications* that need to be built both 
in Fedora and in EPEL. Note that it'd also align with my EPEL-python3 proposal 
[1], in case such an app was to be moved to python3X in EPEL (%default_python 
would just be redefined to python3X). I also think that this approach should 
never be allowed for packaging libraries, e.g. packages that have python-foo 
and python3-foo subpackages.

Thoughts?
Thanks,
Slavek

[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Bohuslav Kabrda]

- Original Message -
 On 27 January 2015 at 21:26, Bohuslav Kabrda bkab...@redhat.com wrote:
  Hey all,
  I just wanted to ask for some thoughts on a problem (or rather a
  hardship) that is starting to show with the Python 3 transition in
  Fedora.
  I've been contacted by two maintainers of applications in Fedora for
  advice and have been thinking for some time how to solve this:
 
  Note: by applications I mean packages that provide end-user benefit and
  don't need to be packaged for both Python interpreters. They just use some
  Python (preferably the default one) to deliver functionality to user.
  Let's take copr-cli as an example - this is a thin CLI wrapper around
  python-copr.
 
  Current state:
  - Up until F21, maintainers were encouraged to build applications with
  Python 2, but weren't discouraged from building with Python 3.
  - From F22 on, packagers will be encouraged to build with Python 3 rather
  than Python 2.
  - Lots of packagers want to keep the same specfile for EPEL and Fedora.
  - Fedora guidelines mandate explicit usage of %__python2 and %__python3
  (and all the sitelib/sitearch macros).
 
  The Problem:
  If packagers want to build against Python 3 in Fedora and Python in EPEL
  *and* keep the same specfile, they have to invent some ugly hacks, since
  Fedora's guidelines require explicit usage of versioned Python macros.
  This affects Requires and BuildRequires and %prep, %build, %install,
  %check sections. People who want to do this either redefine %__python in
  Fedora to point to Python 3 or something like that - I'm afraid that we
  could end up with a huge pile of crazy macro redefinitions in tons of
  packages and I want to avoid that.
 
  Proposed Solution:
  After thinking a few days about this, here's what I propose:
  - Every specfile will have a minimal header with macro definitions that
  will look like this:
 
  %if 0%{?fedora}
  %global default_python python3
  %else
  %global default_python python
  %endif
 
 I'm wary of this proposed solution mostly due to the fact that in the
 middle of last year, the Beaker team had to go through and completely
 redesign the way the automatic kickstart generation worked, because
 the templates were full of checks that assumed RHEL 6 as the default
 basis for derived distros. Once RHEL 7 and CentOS 7 were generally
 available, that assumption became problematically wrong (e.g. systemd
 wasn't a Fedora only feature any more), so the templates were all
 rewritten to be based on operating system feature flags instead (which
 had the added bonus of also making them more tolerant of Fedora
 derivatives).
 
 I see the seeds of a similar problem being planted with the above
 proposal: what happens when, at some point in the future, Python 3 as
 default is no longer a Fedora-only feature? Do we have to go edit all
 the spec files again?

Yikes! Good point, I have put much thought into the macro solution and I wasn't 
giving enough thought to writing the actual condition...

 What if, instead, we were able to add a new macro that let folks
 *explicitly* opt in to running in the system Python, but then define
 the recommended spec file usage such that it falls back to Python 2 if
 the system Python macro isn't defined?
 
 That would give people 3 explicit options to choose from:
 
 * always run in Python 2
 * always run in Python 3
 * run in the same Python as Anaconda and yum
 
 Single source Python 2/3 compatibility could then be made a policy
 requirement for packages opting in to running in the system Python
 rather than explicitly running in Python 3.

I've thought of this, but the problem is that we'd need to add this new macro 
to either RHEL's python-devel or minimal EPEL buildroot. We need this because 
the macros for BuildRequires need to be resolved in the minimal buildroot - so 
if the macro is not there, RPM can't expand BuildRequires and the build fails. 
The fact that adding such macros to RHEL's python-devel or EPEL buildroots is 
not likely made me come up with the proposed approach.

Unless...
Unless we use the original unversioned 
%__python/%python_sitelib/%python_sitearch macros for this. The downside is 
that we'd need to go through tons of Fedora python-* specfiles and replace 
usage of unversioned macros by the versioned ones - but that's one-time effort. 
The upside is that these work in RHEL/EPEL without any additional effort *and* 
they kind of express precisely what we want them to express - *the* Python.

I do agree with Nick's 3 explicit options listed above - the first two being 
mostly for python-* extension packages and the third for applications that 
don't care. I think that this is possibly a huge change that would be 
possible for F23 soonest, but it makes sense (it'd require changes in hundreds, 
maybe thousands of Fedora specfiles and also in RPM). I still think this only 
makes sense to use for applications, not for libraries, but I guess we're 
on the same page with this :)

Slavek

Re: Python 3 as a Default - Status

[Bohuslav Kabrda]

- Original Message -
 On 21. 1. 2015 at 01:44:32, Haïkel wrote:
  Thanks for the heads-up.
  
  As for the cloud image, if we switch to yum, python-urlgrabber won't
  be needed anymore.
 
 Umm, yes, it will be - yum uses python-urlgrabber internally. Also worth
 mentioning that yum itself is not Python 3 compatible.

I think that the original message should've said switch to dnf. Was it not?

 Thanks
 Jan

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Python 3 as a Default - Status

[Bohuslav Kabrda]

Hi all,
since the Python 3 as a Default change [1] has been accepted a while ago and 
is scheduled for F22, I'd like to share with you the status.

The proposed change [1] mentions several goals that should be reached to 
pronounce python3 the default:
1) DNF is the default package manager instead of Yum, which only works with 
Python 2
2) Python 3 is the only Python implementation in the minimal buildroot
3) Python 3 is the only Python implementation on the LiveCD
4) Anaconda and all of its dependencies run on Python 3
5) cloud-init and all of its dependencies run on Python 3

Before I go through the 5 goals, let me explain the approach that has been 
taken so far:
There are basically two types of packages (from Fedora's point of view) that 
depend on Python: libraries and applications (note that the distinction is 
intentionally not very clear, there are packages that are both)
Libraries are, simply put, Python extension modules, those that live in 
%{python2_sitelib} and %{python2_sitearch} in python2 builds. Libraries were 
receiving both upstream and downstream care from the people working on the 
change - upstream porting and downstream python3- subpackage additions, to also 
put files in %{python3_sitelib} and %{python3_sitearch}. We could afford to do 
the subpackage additions downstream during F21 lifecycle, since this doesn't 
change anything, it's just one more binary RPM that's spit out of the SRPM 
build process.
Applications are stuff that users run (an important characteristic is that 
users don't care under which Python the application runs) - like Anaconda. 
Applications have been receiving some upstream patches, but weren't rebuilt 
with Python 3 yet. The reason for not rebuilding yet is that we first wanted to 
make sure that we've ported all applications upstream to be able to switch 
them all to Python 3 in Fedora at once - we wanted to be sure we wouldn't 
introduce both Python runtimes to livemedia, cloudimages, etc. As of now, 
Python 2 is still the suggested Python runtime to build applications against. 
We will start filing bugs to rebuild against Python 3 once we're sure that the 
switch can safely happen (which I think is now according to the points below).

Let's go through the 5 goals:
1) DNF will be the default package manager for F22 [2], so everything is ok 
here.
2) One of our goals was to not make minimal buildroot larger. The only package 
from minimal buildroot requiring python (python-libs to be precise) is gdb, 
which is compatible with python3 in upstream (but it's considered to be an 
application, so it hasn't been rebuilt yet). So minimal buildroot is fine.
3) As for LiveCD, we now have more of these - Workstation, Server and all the 
various flavours and spins. Let me go through Workstation and Server:
Workstation:
Fedora LiveCDs have, since at least Fedora 20, included both Python 2 and 
Python 3 runtimes (the primary reason for having Python 3 back then was AFAICS 
speech-dispatcher, which is Python 3 only in upstream). Although we may not be 
able to port all libraries and applications (but we may, there's still chance!) 
from workstation livecd to Python 3, the fact that it already ships both 
runtimes makes me think that we should build as much apps as possible with 
Python 3.
Server:
Because of giants like samba and freeipa, I think we won't be able to achieve 
python2-free server livecd for F22. But as it is with Workstation, I think we 
should proceed and build as much with Python 3 as possible.
4) Anaconda is work in progress. I'm communicating with Anaconda devs quite 
regularly and everything looks promising.
5) cloud-init is a problem. Basically, Python 3 cloud-init is the only thing 
blocking the cloud images (*). Other packages are ready or being worked on. The 
problem here is that cloud-init upstream is really unresponsive about Python 3 
porting (patch is submitted in their bug tracker [3]) - if someone knows these 
people, please help us by pinging them.

Attached to this mail, you'll find 3 files (fedora-cloud-base.txt, 
fedora-install-server.txt, fedora-live-workstation.txt). Each one of them is a 
result of automated script that tells with quite a good certainty what Python 
dependent packages are on a livecd/image generated by a kickstart with the same 
name.
The files have two sections: Good and Bad. Good packages are either 
libraries that have python3- subpackage or applications that have already 
been built with Python 3. Bad packages are either libraries not having 
python3- subpackage or applications built with Python 2. Note that lots of 
applications are now bad even though their code is Python 3 compatible, they 
just haven't been built with Python 3 yet. Also, Bad contains packages that 
will not be ported at all and will disappear from livecd, e.g. pyliblzma or yum.
We're tracking all packages needed for Workstation and Cloud images at [4] - 
feel free to grab anything unassigned there or help us pushing our patches 
upstream. All 

Re: Changes in Guidelines Connected to Python 3 as Default Change

[Bohuslav Kabrda]

- Original Message -
 Hi all,
 as you are well aware, there is the Python 3 as Default change proposed for
 F22 [1]. There are several guideline changes that will need to be done and
 some that may be done in order to improve the situation. I'd like to make
 this thread a sort of brainstorming on my thoughts as well as possibility
 for anyone to add something that should be done as well. After that, I'm
 planning to open an FPC ticket with all the gathered and discussed changes
 that will come up on this thread.
snip

The FPC ticket is submitted at https://fedorahosted.org/fpc/ticket/475. Feel 
free to post any further comments there.

Thanks everyone for replies and suggestions in this thread!

Slavek
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: [Fedora-packaging] Changes in Guidelines Connected to Python 3 as Default Change

[Bohuslav Kabrda]

- Original Message -
 On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
  
  On 4 Dec 2014 00:38, Bohuslav Kabrda bkab...@redhat.com wrote:
   - (This is not really related to the switch, but more of a general
   remark) In
  [4], it says that python 3 version of the executable gains a python3-
  prefix.
  This is IMO bad, since upstream projects tend to name the versioned
  binaries
  foo-3.4, foo-3 or foo3.4, foo3. We should accept one of these - I'm not
  really certain which one of them. I tried to discuss this several times on
  distutils-sig mailing list, but without reaching a consensus. Either way,
  prefixing with python3- doesn't make sense to me, because it's not similar
  to
  any upstream way and you don't find the binaries under their names using
  tab
  completion (e.g. footab doesn't tell you about python3-foo).
  
  Agreed.
  
  CPython  pip use the foo3.4, foo3 convention, so that seems enough of a
  reason to use that convention by default. We may want a unless upstream
  does
  it differently caveat though.
  
 Second caveat here is that currently we use version suffixes to denote
 a command coming from a compat package.  If we make this change we need to
 address that as well.  So, you might have sphinx-build, sphinx-build-2,
 sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python
 interpreter.  If you need a forwards or backwards compat package you might
 also have an 0.9 and 1.1 that you need to tack on.  Possible solution here:
 use a v prefix for the compat package's version.  So if the default
 package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9
 packages provide:
 
 * sphinx-build-v0.9
 * sphinx-build-2-v0.9
 * sphinx-build-2.7-v0.9
 * sphinx-build-3-v0.9
 * sphinx-build-3.7-v0.9

I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at the 
very end in every case is better. In other words, the binary would normally be 
sphinx-build-0.9 and we just append -3.4 to it.
Also, this makes me realize more arguments to append Python version with dash, 
not without it:
1) sphinx-build-v0.93.4 would be very confusing (I do understand that this is a 
downstream problem, but see the following point)
2) Similarly, if there is an upstream whose entry_point/script ends with a 
number (pep8 for example), it'd be highly confusing to use the notation without 
dash, it would yield pep83.4 assuming the upstream community would accept this 
scheme. This feels just wrong.

 Also an addition: It would be great for us to always have a major version
 number
 only script name.  Currently there's a few packages (python3-nose, I'm
 looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4.
 That means scripts (user scripts as well as spec files) have to change
 whenever we update python3 to a new major release.  Having the major only
 form for all of these binaries will alleviate that.  Packagers can just
 create a symlink if upstrean doesn't provide the -MAJOR version.

I do agree that we should have that, although you can now use 
nosetests-%{python3_version}.

   - As for binaries/scripts in /usr/bin (assuming there are both python2
   and
  python3 versions), the unversioned files should point to python2 version.
  This
  aligns with /usr/bin/python still pointing to python2.
  
  This also aligns with CPython  pip conventions. Between them, only
  pyvenv
  runs under Python 3 by default, and that's only because it doesn't exist in
  Python 2.
  
 One exception to this, I think, should be 2to3.  Or perhaps python-tools
 should stop shipping 2to3 and the other /bin/ scripts which python3-tools
 ships and are not needed in two versions (Not sure if any of those scripts
 actually need to be carried in two versions.. pygettext.py might need to be
 tested to be sure the python3 version can handle all sorts of python2
 strings correctly).

Agreed, it's been on my todolist for quite some time to make 2to3 from 
python3-tools *the* 2to3.

 -Toshio

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Template for modules that use pbr?

[Bohuslav Kabrda]

- Original Message -
 Hi,
 
 I'm trying to update git-review to 1.24.  With that version,
 git-review uses pbr.  I have no deeper knowledge of Python
 packaging in Fedora and only tweaked the spec file so that
 it works for me
 (cf.
 https://github.com/scfc/fedora-git-review/commit/b35c26010d67affd5da0305af2c1d9965c571fd3),
 so I wanted to solicit some advice on how to do it
 right(TM).

Hi Tim,
not sure if my answers will be right(TM), but I hope that they'll be useful, at 
least :)

 1. Previously, Fedora used GitHub releases that appear to
be verbatim snapshots of the source repository.  But with
https://github.com/openstack-infra/git-review/archive/1.24.tar.gz,
this no longer works as python setup.py build gives:
error in setup command: Error parsing
/tmp/tmp.ITVvwuYttj/git-review-1.24/setup.cfg: Exception:
Versioning for this project requires either an sdist tar-
ball, or access to an upstream git repository.  However,
using
http://pypi.python.org/packages/source/g/git-review/git-review-1.24.tar.gz
works fine.
 
Comparing the two shows a number of additional files in
the latter (AUTHORS, ChangeLog, git_review.egg-info,
PKG-INFO).  Am I correct to assume that this is a problem
upstream, i. e. that the tarballs should not have been
published in this state, and/or is there a way to work
around that in the spec file?

The important thing here is that upstreams do not publish tarballs on Github. 
Github dynamically generates tarballs of repos for given tag/commit hash when 
you request it. This generally means that the tarball downloaded from Github is 
not what upstream meant to release (unlike pypi, which *is* what upstream 
released).
The interesting thing about the tarball from pypi is, that all files in the 
archive are owned by jenkins user. I didn't check, but my guess is, that when 
upstream wants to do a release, they let Jenkins (with access to upstream git 
repository, which is what pbr asks you to have) generate the final tarball - 
and Jenkins generates all the extra files before packing the tarball. If you 
look at the files missing from the first archive, they do look autogenerated, 
which seems to confirm my thoughts, but I'm not 100 % sure.

 2. By default, pbr seems to pull any dependencies from the
network.
http://docs.openstack.org/developer/pbr/packagers.html
suggests that this can and should be avoided by setting
SKIP_PIP_INSTALL=1.  Is there a template for how to do
that properly, i. e. in a macro or just prepending to
%{__python}, etc.?

I'd prepend that to macro, e.g.
SKIP_PIP_INSTALL=1 %{__python2} something
(Note, that it is recommended to use %{__python2} or %{__python3} explicitly, 
rather than using %{__python}.)

 3. Testing with Koji
(cf. http://koji.fedoraproject.org/koji/taskinfo?taskID=7977881),
the build log
(cf.
https://kojipkgs.fedoraproject.org//work/tasks/7881/7977881/build.log)
starts with:
 
| Mock Version: 1.1.41
| Mock Version: 1.1.41
| ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target noarch
| --nodeps builddir/build/SPECS/git-review.spec'], False,
| '/var/lib/mock/f19-build-2538894-429281/root/', None, 86400, True,
| False, 1000, 425, None, False, {'LANG': 'en_US.UTF-8', 'TERM': 'vt100',
| 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n
| mock-chroot', 'HOME': '/builddir', 'PATH':
| '/usr/bin:/bin:/usr/sbin:/sbin'},
| logger=mockbuild.trace_decorator.getLog object at 0x1725dd0)
| Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target
| noarch --nodeps builddir/build/SPECS/git-review.spec'] with env
| {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
| 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot',
| 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
| sh: /usr/bin/python: No such file or directory
| sh: /usr/bin/python: No such file or directory
| [...]
 
Is that to be expected?

These lines are usually caused by macro definitions in specfile containing 
calls to not yet installed binaries. When Koji creates the minimal mock 
buildroot, it tries to expand the specfile to get dependencies (BuildRequires) 
to install. Since Python is not in the minimal buildroot when the specfile is 
expanded, mock will produce this warning. I'm not sure where exactly this comes 
from the git-review specfile, but I'm quite sure that it's not a problem.

Slavek

 Of course, any other advice is also much appreciated.
 
 TIA,
 Tim
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: python-sig in pkgdb2?

[Bohuslav Kabrda]

- Original Message -
 Hi all,
 
 there just was a request to test groups for pkgdb2 [1] and I thought
 it might be a good opportunity to maybe start sharing at least some
 core python packages among a few people.
 
 For instance, I maintain ipython and the dependency chain when other
 maintainers chose to orphan something I need for it (or ipython
 introduces a new dependency). Such packages are good candidates to be
 maintained by a group of people, so updates can be managed better and
 several people have an eye on them.
 
 What do others think about that? Who else would be interested in
 starting a common python-sig group in pkgdb2?

I'm generally +1 for this, although I think people should still first try to 
contact the primary maintainer and then patch things themselves. For example, 
in python{,3}.spec, we're trying to follow a certain style of patch naming to 
keep things consistent and it's very disconcerting when a proven packager who 
needs to fix something creates a patch that completely ignores this...
But yeah, I do agree that this is a good idea :)

Will you start the group, Tom?

 Greetings,
 Tom
 
 [1]
 https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001445.html

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: reproducible builds and python

[Bohuslav Kabrda]

- Original Message -
 Hi everyone!
 
 I've been doing some work towards reproducible builds in Fedora (mostly
 with various upstreams so far) and one of the elephants in the Room are
 obviously Pythons .pyc and .pyo files.
 
 As those contain the mtime of the original .py file, they might be
 different for each rebuild of an srpm.
 For many rpms this isn't a problem, because the files are not modified
 and thus retain their timestamp from the archive. Quite a few rpms do
 modify to .py files though and because of that, every build has a
 different result.
 
 I would like to propose to set the mtime of all .py files to a fixed
 (for this specific srpm) time. This could be done
 in /usr/lib/rpm/brp-python-bytecompile before doing the actual
 byte-compilation. This would result in the same .py{c,o} files being
 created for each rebuild.
 
 The timestamp could be e.g. the mtime of the oldest file in the
 buildroot (which would assume that not _all_ of the files are modified)
 But if you are interested in the idea, I'd certainly be open to
 suggestions.

Generally, I like this idea, but I have some concerns:
- So the bytecompile script would touch all *.py files? It seems a bit hacky, 
not mentioning that in some specfiles (notably python3 itself) we actually have 
to do bytecompilation by hand for certain reasons.
- Obviously another question is what happens when _all_ files are modified. I 
can pretty much guarantee you that at any given time there will be at least one 
package in Fedora that will have all files modified (e.g. python-six has just 
one py file, so if we patch/touch it in some way, the problem is here). I'd 
like to see a proposal that handles this situation in a sane way.

Having {read about,experimented with} reproducible builds before, I can see the 
advantage that Fedora would get from this. Perhaps you could sum up the actual 
benefits of reproducible builds here so that even those who have never heard of 
this can see why this is worthwile?

Just thinking aloud here, but this should also be beneficial for RPMs generated 
with setup.py bdist_rpm, right? As in two RPMs generated by bdist_rpm from 
the same git/hg revision on the same architecture would have the same hash - 
or am I wrong here?

Thanks,
Slavek

 To address the obvious question:
 Why not special-case those files when comparing rpms?
 
 It will certainly be impossible to achieve this for all packages in
 Fedora, so for some files this might indeed be needed, but I think we
 should avoid this where possible. The idea of reproducible builds
 becomes meaningless if the amount of differences that you just ignore
 gets to big.
 
 
 What do you think of this proposal?
 
 Greetings,
 Benedikt
 
 ___
 python-devel mailing list
 python-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: mock, megadeps and PyPI

[Bohuslav Kabrda]

- Original Message -
 - 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.

I like this idea. Not only it can be beneficial for people creating a whole 
environment for their Python application, but we would also be able to get a 
huge feedback on pyp2rpm and would be able to improve it significantly, I'd say.
/me is wondering whether we could automatically generate SCLs by this, so that 
the packages wouldn't conflict with system ones. In the best case, one could 
even be able to do mock-or-a-mock-wrapper 
--create-scl-from-this-app-and-build-it-in-copr /path/to/my/app scl_name (I 
admit that naming command line arguments isn't my strongest skill...)

Slavek

  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

-- 
Regards,
Slavek Kabrda
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Introducing Python 3.5 nightly builds for Fedora

[Bohuslav Kabrda]

- Original Message -
 On 07/03/2014 11:55 PM, Miro Hrončok wrote:
 
  Other than the packaging reasons: Fedora might attract Python
  enthusiasts and developers as it is most likely the only Linux distro
  that has development version of Python packaged nightly. Developers and
  powerusers can play with new features committed yesterday just by doing
  `dnf update`.
 
 I actually mentioned this in my recent SciPy keynote, on the grounds
 that scientists may want to play around with the new matrix
 multiplication operator without having to build Python from source :)

Yeah, I saw that one on YouTube. Good talk :)
Actually, I'd like to advertise this even more, e.g. on some of Python upstream 
mailing list - on the other hand, I don't want to look like I'm spamming 
everyone needlessly... What do you think would be the best place to announce 
this? python-announce-list?

Thanks,
Slavek

 Cheers,
 Nick.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Python 2.7 SSL upgrade patch available for testing

[Bohuslav Kabrda]

- Original Message -
 PEP 466 approved bring the core Python 2 network security infrastructure
 up to speed with the modern internet.
 
 Alex Gaynor has provided a draft patch of the most complex part of that
 PEP, backporting the bulk of the Python 3.4 SSL module to Python 2.7:
 http://bugs.python.org/issue21308#msg223895
 
 This is also the part of the PEP most likely to break things, so
 figuring out a way to test it in Fedora before it makes it into an
 upstream CPython release would be a good idea...

We could create a copr repo where we would rebuild python (in an SCL?) with 
these patches and then we'd rebuild some modules that use ssl - to see if the 
tests pass and if they're actually usable. The disadvantage of this approach is 
that it just takes lots of time to implement...
Or, if we're feeling lucky, we can just build Python with these patches in 
rawhide and see if something breaks :) That's easy and fast (assuming 
everything works fine).

I'd really love to help here, but I really can't spare enough time to do it 
properly in Copr as noted above.
So the question is, are we feeling lucky? :) I'd say yes, since rawhide has 
just recently become future Fedora 22 and not much is going on in there right 
now. If we break something, we can just revert it quickly and everything will 
be fine.

Is someone strictly against this or shall I move on with patching our rawhide 
Python?
Slavek

 Cheers,
 Nick.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: PEP453 // ensurepip // pip

[Bohuslav Kabrda]

- Original Message -
  I would say this one https://github.com/pypa/pip/issues/1351 is important
  for us
  as packagers. It makes me nervous/upset and sad altogether :-).
 
 Awesome, well that’s on the list for 1.6 so that should be the next feature
 release
 of pip.

Cool, thanks a lot!

  
  having it tied so closely to Python. Also generally about making less
  headache
  for distros where pip is involved (pip and the OS package manager stomping
  on
  each other etc).
  
  To start off this goal I've filed https://github.com/pypa/pip/issues/1668
  to
  figure out how pip can get our defaults to the point where most users will
  be
  installing to ~/.local/ instead of the system location. If there's more
  things
  pip can do I'd love to know about them, or if ensurepip or the PEP453
  processes
  have something I can help with too :)
  
  Nice, I have put my two cents in it.
  
 On the topic of re-wheeling (Sorry I just joined so I don’t have it in my
 history to reply to).
 
 I’m assuming Fedora unbundles the stuff that pip bundles (sorry :/) and I’m
 guessing that
 since the Rewheeling is going to pull in the system versions that it’s going
 to pull in a
 copy of pip with those things unbundled. If that’s the case you’re going to
 need to install
 those things into the virtualenv itself.

Just yesterday, I took ownership of python-pip in Fedora and I'm quite 
surprised that we don't unbundle anything. I'll have to investigate this. It 
actually makes sense now that I think of it, since the rewheeled pip has worked 
for us in virtualenv - had we unbundled the bundled code, it would have failed.

 However I think that the copy of pip inside of a venv should keep stuff
 bundled if at all
 possible. One of the reasons we did this was so that when using pip inside of
 a venv
 we don’t make any assertions about what other things you can have installed.
 So for
 example we depend on requests, we don’t want someone who is using an older
 (or newer!)
 requests inside of their venv to be unable to install it because pip itself
 uses it. Also
 another reason we did that is because if you uninstall one of those things
 and it breaks
 pip you don’t really have a good way to unbreak it except destroy the venv or
 install it
 manually. This is less of a concern for the system installed pip because you
 have yum
 or whatever that can be used to fix it and y’all integrate things already to
 ensure compat :)
 

Maybe the reasons for you to bundle are also the reasons why Fedora's pip 
doesn't have these libraries unbundled. As I've said, I need to investigate 
this.

Regards,
Slavek

 
 -
 Donald Stufft
 PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Python 3.4.0 final has been released

[Bohuslav Kabrda]

- Original Message -
 On 03/17/2014 05:53 PM, Nick Coghlan wrote:
  Direct link to the What's New guide:
  http://docs.python.org/3/whatsnew/3.4.html

Thanks, Nick!

 Rereading that, I remembered there's more to it for Fedora than just
 hey, here's a shiny new version of Python 3 to be packaged, and I
 don't mean the stuff Slavek is working on to let ensurepip use the
 system pip installation as a base.
 
 Specifically, there may need to be a security-related change to the
 Python packaging guidelines, covering the appropriate use of isolated
 mode: http://docs.python.org/3/whatsnew/3.4.html#whatsnew-isolated-mode

What do you have in mind regarding packaging guidelines?

 There's also a simpler workaround for the issues with the standard
 streams when running things in the POSIX locale: setting
 PYTHONIOENCODING=:surrogateescape will deal with it for user mode scripts.
 
 Cheers,
 Nick.

Just BTW me and Matej Stuchlik are working on builds of Python 3.4 in Copr [1]. 
Everything got a bit more complex due to ensurepip:
- python3 should have Requires: python3-setuptools python3-pip (this has 
already been discussed previously on this list, just mentioning)
- I've created the rewheel library [2] that has a simple purpose of being able 
to repack a wheel from system-installed wheels
- this means that we need system setuptools and pip packaged as wheels 
(packaging as wheels has not been standardized yet, so I'm just approaching it 
from the best angle I could come up with, see patches [3] and [4])
- to package system setuptools and pip as wheels, we first need to package them 
as normal packages, because we need these packages to be able to create wheels 
:)
- which creates a nice dependency/boostraping cycle:

1) build python3 (no requires on setuptools or pip)
2) build python3-setuptools and python3-pip as normal python packages (not 
wheels)
3) build python3-wheel (we don't need this to be wheel-in-RPM ATM)
4) build python3-setuptools and python-pip (as wheel-in-RPM)
5) build python3 (add Requires: python3-setuptools, python3-pip)

I've got example patches of building setuptools and pip as wheel-in-RPM at [3] 
and [4] (note that the pip patch also contains some downstream only patches 
that I've created to achieve what we need; upstream won't probably accept them 
in this precise format, but the functionality should get upstream in some form).

Right now, we're working on integrating rewheel into ensurepip (a patch for 
that is at [5] - it's for beta4 IIRC).

We'll keep this list posted on the progress. When we manage to make this whole 
process work satisfiably, we'll:
1) formally document the whole process described above
2) start discussing options of accepting rewheel in Python upstream
3) start rebuilding more python3-* packages in the Copr repo to make sure that 
nothing (or nearly nothing) breaks and we can actually go on with the proposed 
Fedora Change

And then we'd like to concentrate on the Python3-as-a-default switch for a 
while.

Hope this all makes sense, all comments/suggestions are appreciated.

Slavek.

[1] http://copr.fedoraproject.org/coprs/bkabrda/python-3.4/builds/
[2] https://github.com/bkabrda/rewheel
[3] https://github.com/bkabrda/rewheel/blob/master/python-setuptools-spec.patch
[4] https://github.com/bkabrda/rewheel/blob/master/python-pip-spec.patch
[5] https://github.com/bkabrda/rewheel/blob/master/ensurepip-rewheel.patch
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Python 3.4, ensurepip and wheels

[Bohuslav Kabrda]

- Original Message -
 On 12/12/2013 01:18 AM, Bohuslav Kabrda wrote:
  Well yeah, my point is that there is no upstream-acceptable way other than
  checking the file hashes by ensurepip, is there? If I wouldn't want to
  check file hashes, I'd have to query RPM for release - or is there some
  other way you're thinking of?
 
 I think doing it initially as a downstream only change where you query
 RPM will work for now (perhaps by patching the way pip handles the case
 where ENSUREPIP_OPTIONS is set?).
 
 By the time this approach is posted upstream, then PEP 426/440 will
 hopefully by Final and we can just use the metadata version field
 directly rather than needing to grab the release increment from the RPM
 repo. (I think this situation provides a good practical use case for why
 it's important to standardise this feature upstream, too).

So, getting back to Toshio's concern about sysadmins who just update'n'upload 
files, the workflow for them would be update files, bump build tag and then 
upload, right?

What I mean is, this still has two solutions:
- checking the build tag (seems to be very simple to do)
- check the file hashes
Both solutions are IMO acceptable upstream (when we can actually do build 
tags), but my question is: Which one is more likely to be accepted? I'm for 
checking the build tag, even if it means the extra step for sysadmins who 
will need to bump the build tag when doing changes. (We may need to tell them 
to not bump the build tag major number, but add something to it like 1 = 
1.1, since we want distro package with 2 win over sysadmin's change.)

Does that make sense? What I'd love to hear is which of the two approaches is 
more likely to get accepted upstream, so that I can concentrate on that one 
approach.
Thanks,
Slavek.

 Cheers,
 Nick.
 
 --
 Nick Coghlan
 Red Hat Hosted  Shared Services
 Software Engineering  Development, Brisbane
 
 Testing Solutions Team Lead
 Beaker Development Lead (http://beaker-project.org/)

-- 
Regards,
Bohuslav Slavek Kabrda.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Python 3.4, ensurepip and wheels

[Bohuslav Kabrda]

- Original Message -
 On 11/28/2013 12:42 AM, Bohuslav Kabrda wrote:
  I hope I covered all the important points. Basically, we can make this work
  in a way acceptable for upstream, if we package setupttols and pip as
  wheels. It'll require some extra effort, but I think it's worth it.
  Thoughts? Anyone has better/simpler ideas?
 
 From an upstream point of view, so long as test.test_ensurepip and
 test.test_venv still work, things should generally be OK.
 
 I quite like the idea of checking for the consistency of the RECORD
 files between the system pip and the one in the virtualenv (as well as
 using RECORD as a guide to what to copy into a fresh venv). If you get
 that working, I'd be interested in a Python 3.5 venv and/or ensurepip
 patch to do that by default, and only bootstrap from the embedded wheel
 if there was no system pip available.
 
 Cheers,
 Nick.

Actually, there seems to be a much simpler way of doing this in Fedora (and any 
distro more generally):
- setuptools and pip RPMs will carry the wheel inside them and drop it into 
ensurepip/_bundled
- the wheels will be rebuilt during every RPM build everytime *after patching*, 
so they will carry security patches etc.
- we will use the RPM release as the build tag mentioned in PEP 427 [1], so 
that when we e.g. fix a security bug but don't bump the version, ensurepip 
--upgrade will still see that the wheel has to be reinstalled (otherwise it'd 
say think the version is already there and wouldn't reinstall)
So the only thing we will need to implement will be autodiscovery of the 
wheels, since they will change names independently on python3 package, but I 
think we can do that :) From upstream point of view this shouldn't break 
anything, but it'd also probably not have any benefit. Would you still accept 
such patch?

Regards,
Slavek.

[1] http://www.python.org/dev/peps/pep-0427/#id11
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: [Fedora-packaging] Proposal for Python guidelines change (in connection to Python 3 switch)

[Bohuslav Kabrda]

- Original Message -
 On Wed, Dec 04, 2013 at 07:18:31AM -0500, Bohuslav Kabrda wrote:
  - Original Message -
  Oh, I see. Some time ago, FPC has accepted a change that says, that
  packages with py in name should be prefixed with python- anyway [1].
  Since this only applies to newly created packages, we will have to cope
  with this, unfortunately. So my idea of handling this would be:
  - all packages must have Provides: python-*
  - packages that weren't prefixed with python- previously (pyserial,
  PyYAML), should also carry an explicit Provides/Obsoletes for the old
  name.
  Sounds good?
  
 I would remove that first bullet point.  The point of the Provides and
 Obsoletes is to provide backwards compatibility.  If there's no previous
 python-* there's no need to take up that name in the namespace.

Ok, I updated the wiki page with some more talk about the Provides and 
Obsoletes, which should incorporate this change and also the others mentioned. 
You can check out just the diff [1]

   What about apps? Do we want something in the guidelines that would say:
  Toshio already proposed a guidelines solution for this [2], but now that
  I look at it, it seems that it never got proposed to FPC. Toshio, will you
  propose that or should I? I guess we can do this regardless of the change
  I'm proposing now.
  
  [2]
  https://lists.fedoraproject.org/pipermail/python-devel/2013-November/000528.html
 
 Please do.  I haven't got a whole lot of time these days :-(

Done [2].

 -Toshio

Thanks,
Slavek.

[1] 
https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FPy2to3GuidelineChangesdiff=363421oldid=363312
[2] https://fedorahosted.org/fpc/ticket/373
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Packaging Python 3.4.0

[Bohuslav Kabrda]

Update:
- DONE: I've just created a copr repo for Python 3.4 [1] and built beta1
- IN PROGRESS: I'm now working on unbundling of pip and setuptools wheels, as 
mentioned in thread [2]. Progress:
-- DONE: created python-wheels package for Fedora (I'll build it in copr ASAP)
-- DONE: added logic to python-setuptools and python-pip so that they can be 
built as wheels (I'll build in copr ASAP)
-- TODO: Now that I have an idea how to build wheel RPMs, I need to:
--- wait to see if my patches to pip that enable this get accepted [3], [4] 
(and perhaps communicate with upstream to make them better)
--- once the patches are accepted, I'd like to talk to FPC about allowing 
building wheel RPMs (most likely from Fedora 21 on) and how to do that
--- once that is discussed, build setuptools and pip as wheels for F21 (this is 
really necessary, so even if Fedora as a whole distro doesn't accept wheels 
usage yet, I'll try to negotiate exception for these two packages)
-- TODO: in the meanwhile, I'll start working on the actual ensurepip patch and 
I'll propose it upstream
- TODO: also in the meanwhile, I'll be updating Python 3.4 to the newest 
prereleases, as they are released by upstream

If anyone wants to help, you can:
- help push my patches to pip upstream
- help with creating a proposal about building wheel RPMs for FPC (have a look 
at the SRPMs in the copr repo - once I've built them - to see how I'm currently 
doing it)
- help with creating the ensurepip patch
(if you want to work on any of these, please let everyone know, so that we 
don't duplicate our efforts)

Thanks a lot,
Slavek.

-- 
Regards,
Bohuslav Slavek Kabrda.

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/builds/
[2] 
https://lists.fedoraproject.org/pipermail/python-devel/2013-November/000540.html
[3] https://github.com/pypa/pip/issues/991
[4] https://github.com/pypa/pip/issues/1351
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Multirelease effort: Moving to Python 3

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
  3) Making all livecd packages depend on Python 3 by default (and
  eventually getting rid of Python 2 from livecd) - this will also require
  switching from Yum to DNF as a default, that is supposed to support Python
 
 I have a concern about bloating @core and by extension the cloud image.
 Right now, python is about 5% of the total on-disk usage. I'd hate to see
 that go to 10%. Therefore, I'd like to see a goal of making the transition
 for usage in the base cloud image go entirely from python2 to python3 in
 one release cycle.
 
 (Roughly, that's @core + cloud-init, which isn't currently on your list.)
 

Doing everything in one shot sounds reasonable from this POV, I'll try to put 
this into my plan (I'll go through cloud-init the same way I went through 
livecd and post my findings here).

 
 --
 Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org

-- 
Regards,
Bohuslav Slavek Kabrda.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Switching to Python 3

[Bohuslav Kabrda]

- Original Message -
 On Mon, 2012-08-13 at 03:09 -0400, Bohuslav Kabrda wrote:
  - Original Message -
   On 08/06/2012 04:22 AM, Toshio Kuratomi wrote:
The only distribution that has switched is arch.  When they did
there was
a big uproar about how arch was doing something wrong which
eventually
resulted in that PEP.
   
   Yeah, we mainly wrote PEP 394 in order to nudge *everyone else*
   into
   providing a /usr/bin/python2 symlink to help deal with Arch
   making
   their
   bold leap into the unknown (as well as going on record that we
   think
   switching it *right now* is still a bad idea). There's bleeding
   edge
   and then there's tap dancing on razor blades in your bare feet
   :P
   
   To be honest, I expect that the long term outcome will be that
   /usr/bin/python becomes solely the preserve of the OS, with all
   cross-platform scripts and applications using /usr/bin/pythonX,
   software collections, or language level virtual environments.
   
   From an end user perspective, having things mostly compatible
   with
   both
   2 and 3 should come *before* that symlink gets flipped rather
   than
   after.
   
   Cheers,
   Nick.
   
  
  Ok, then I would suggest using Tom Spura's idea about making only
  python2- and python3- packages (maybe with the virtual python-
  provides for python2- packages, as Toshio has mentioned). We could
  target this for F19 and we could also start helping various
  upstreams
  with switching to python 3 and see where this will take us. Does
  that
  sound good?
 If we're looking at this kind of change (python2-foo and
 python3-foo),
 how about some other prefixes:
   * python2-debug-foo (or somesuch) for a build of the package
   against
 the --with-pydebug python2 package
   * python3-debug-foo
   * pypy-foo for the package built against PyPy
 
 FWIW an old idea I had for revamping how we maintain Python packages
 can
 be seen here:
 http://lists.fedoraproject.org/pipermail/python-devel/2010-March/000213.html
 with some further ideas here:
 https://fedoraproject.org/wiki/DaveMalcolm/PythonIdeas
 (you can tell that page is old, it still mentions Unladen Swallow and
 Pynie...)
 
 I still like the basic idea: introduce a tool that captures the info
 on
 python runtimes for a given release in one place, and use it
 programmatically within specfiles to avoid copypaste.  Although the
 proposal isn't complete (how to handle exclusions?), I'm still fond
 of
 it.
 

Personally, I like the idea. As you say, there are still some issues, but I 
guess we could solve those easily.
There is IMHO one downside of this approach - the complexity. I fear that 
rpm-pyconfig can be easily taken to such extremes, that we will end up with 
completely unintelligible specfiles.
As for supporting more runtimes (e.g. Pypy), I would be very careful about 
that, as it might get us overloaded by tons of issues of different packages 
with different runtimes.
Here is a wild idea: Would it be possible to create a common site-packages 
directory for all runtimes? I don't know much about how different runtimes 
handle bytecode generated by another runtime etc, but it may be worth looking 
into, if we want to support more runtimes with our packages.

 Another idea would be to use the Software Collections tool seen here:
   https://fedorahosted.org/SoftwareCollections/
 I known that people within Red Hat have been looking at using that in
 the RHEL context, and some of that is likely to be appropriate for
 EPEL
 too - though AIUI it's a shift in model from one build per src.rpm to
 multiple builds per src.rpm
 

I've already done my bit of SCL packaging, so here are my 50 cents :)
- How exactly would you apply SCLs in our case? I like the SCL concept 
(obviously :) ), but if you package e.g. Python 3 as an SCL, then you're going 
to have a hard time convincing someone to switch their application to it. Maybe 
packaging all the -debug builds for a single runtime in an SCL might be a good 
idea? E.g. have one srpm, that would produce optimized build if built out of 
SCL and debug build if built with SCL.
- SCLs are currently not allowed in Fedora [1] (I'm not sure why, maybe Toshio 
can explain why FPC chose to forbid them).
- If anyone is interested in an example how things could work out, drop me a 
line, I can create a simple example.

 Hope this is helpful
 Dave
 
 ___
 python-devel mailing list
 python-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel

-- 
Regards,
Bohuslav Slavek Kabrda.

[1] 
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Switching to Python 3

[Bohuslav Kabrda]

- Original Message -
 On Fri, Aug 03, 2012 at 04:42:02AM -0400, Bohuslav Kabrda wrote:
  - Original Message -
   On Fri, Aug 3, 2012 at 8:57 AM, Bohuslav Kabrda
   bkab...@redhat.com
   wrote:
Hi,
I'd like to start a discussion about the release where we
should
switch to Python 3. As I have learned recently, Ubuntu 12.10
will
have Python 3 as default [1], which makes me a sad panda :(
We always take pride in being close to upstream and having the
bleeding edge. Python 3 is stable and more and more libraries
support it. So I'd like to propose an idea to switch to Python
3
for Fedora 19.
   
   In which a way do you want to switch to python3?
   For me, that means any mention of python is synonym to
   python3,
   which leads to the question, what is inside a python-foo package?
   The module foo, built for python3?
   
  
  As you say, switching means /usr/bin/python - /usr/bin/python3.
  And yes, that is a very valid point about the naming, I think.
  
 Porting, taking those ports upstream, and even *tiny shudder*
 carrying those
 python3 patches locally for a lng time, I could support.
 
 Switching /usr/bin/python to point to /usr/bin/python3 I'd be very
 much
 against (at least for several years):
   http://www.python.org/dev/peps/pep-0394/
 
 has a section that says it may someday be updated to recommend
 changing
 a /usr/bin/python symlink to point at python3.  I would wait to make
 the
 link change until that PEP is updated (or many other unix
 distributions are
 also ready to make the switch).  Switching the link is a largely
 symbolic
 gesture that creates more work for package maintainers, more work for
 end
 users, and more work for developers (who all have to find uses of
 /usr/bin/python and change them to /usr/bin/python2).
 

Well, my opinion is different on this. The PEP says that bleeding edge 
distributions may have python3 as a default. And I like to think of Fedora as 
bleeding edge.

 Switching /usr/bin/python to /usr/bin/python3 sacrifices practicality
 to
 purity which is unpythonic :-)
 
   It would be best to rename all python-foo packages, to
   python2-foo or
   python3-foo and don't allow subpackaging of modules, which
   provide
   multiple python versions. And when that's consistent, we can
   switch
   /usr/bin/python to python3.
   
  
  I agree about the renaming. Having said that, I don't like that the
  users will need to install python2-foo or python3-foo, not just
  python-foo. On the other hand, the normal users will just get
  stuff and update it. The developers using various versions of
  python might actually appreciate the knowledge of what they are
  installing.
  
 One of the things that tomspur and I talkd about relating to this...
 There's
 a large potntial for confusion (in, for instance, bugzilla) if we
 simply
 rename python-foo to python2-foo if the python-foo package was
 building
 a python3-foo subpackage.  If you find a bug in python3-foo, you'd
 need to
 file it against python2-foo in bugzilla... very non-intuitive.
 
 A way to deal with this would be to stop shipping python3-foo as
 subpackages.  Modules for python3-foo would have to be from separate
 srpms.
 
 Another way would be to have empty python-foo main packages that
 generates
 python2-foo and python3-foo subpackages.  That's kinda ugly though.
 
 Regarding users needing to install python2-foo vs python3-foo: I'd
 propose
 virtual provides *for backwards compatibility*.  For several years,
 yum
 install python-foo would match a
   Provides: python-foo = %{version}-%{release}
 
 in the python2-foo package.  At some point we'd decide these were no
 longer
 worthwhile and get rid of them.  Note that this would only be for
 backwards
 compat.  We'd never change them to install python3-foo.  It's just to
 wean
 users off of python-foo meaning python2-foo.
 

Yep, shipping python2 and python3 packages separately and having the virtual 
provides both sound very good to me, I thought about something similar.
(BTW I'm sorry to interrupt this discussion from my side, as I'm leaving for a 
vacation. I'll be glad to continue when I return :) Have a good time everyone!)

 -Toshio
 
 ___
 python-devel mailing list
 python-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel

-- 
Regards,
Bohuslav Slavek Kabrda.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Switching to Python 3

[Bohuslav Kabrda]

Hi,
I'd like to start a discussion about the release where we should switch to 
Python 3. As I have learned recently, Ubuntu 12.10 will have Python 3 as 
default [1], which makes me a sad panda :(
We always take pride in being close to upstream and having the bleeding edge. 
Python 3 is stable and more and more libraries support it. So I'd like to 
propose an idea to switch to Python 3 for Fedora 19.

Please note, that I don't want to start a flamewar with this, but a serious 
discussion. I want to know what python SIG thinks about taking this step before 
taking it to wider public on fedora-devel.

-- 
Regards,
Bohuslav Slavek Kabrda.

[1] https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3#Python_3.0
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

[Bohuslav Kabrda]

- Original Message -
 On 05/23/2012 04:57 PM, Bohuslav Kabrda wrote:
  Regarding pyp2rpm itself, running pip install pyp2rpm (or
  easy_install pyp2rpm) on my Fedora 16 workstation gives me a
  traceback
  with RuntimeError: That compression method is not supported.
 
  
  Hmm, that is really strange, this works for me on F17. Could it be
  that it depends on Python version or tar version it was created
  with? I created the package on F17.
 
 I'm stumped. I downloaded the tarball and unpacked it with Ark to see
 if
 the unpack step was the source of the problem. I then ran setup.py
 directly and got the output below.
 
 
 $ sudo python setup.py install
 running install
 running bdist_egg
 running egg_info
 writing requirements to pyp2rpm.egg-info/requires.txt
 writing pyp2rpm.egg-info/PKG-INFO
 writing top-level names to pyp2rpm.egg-info/top_level.txt
 writing dependency_links to pyp2rpm.egg-info/dependency_links.txt
 reading manifest file 'pyp2rpm.egg-info/SOURCES.txt'
 reading manifest template 'MANIFEST.in'
 writing manifest file 'pyp2rpm.egg-info/SOURCES.txt'
 installing library code to build/bdist.linux-x86_64/egg
 running install_lib
 running build_py
 creating build/bdist.linux-x86_64/egg
 creating build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/utils.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/package_data.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/version.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/archive.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/settings.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/filters.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/exceptions.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 creating build/bdist.linux-x86_64/egg/pyp2rpmlib/templates
 copying build/lib/pyp2rpmlib/templates/macros.spec -
 build/bdist.linux-x86_64/egg/pyp2rpmlib/templates
 copying build/lib/pyp2rpmlib/templates/fedora.spec -
 build/bdist.linux-x86_64/egg/pyp2rpmlib/templates
 copying build/lib/pyp2rpmlib/dependency_parser.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/package_getters.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/metadata_extractors.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/__init__.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 copying build/lib/pyp2rpmlib/convertor.py -
 build/bdist.linux-x86_64/egg/pyp2rpmlib
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/utils.py to
 utils.pyc
 byte-compiling
 build/bdist.linux-x86_64/egg/pyp2rpmlib/package_data.py
 to package_data.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/version.py to
 version.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/archive.py to
 archive.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/settings.py to
 settings.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/filters.py to
 filters.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/exceptions.py
 to
 exceptions.pyc
 byte-compiling
 build/bdist.linux-x86_64/egg/pyp2rpmlib/dependency_parser.py to
 dependency_parser.pyc
 byte-compiling
 build/bdist.linux-x86_64/egg/pyp2rpmlib/package_getters.py to
 package_getters.pyc
 byte-compiling
 build/bdist.linux-x86_64/egg/pyp2rpmlib/metadata_extractors.py to
 metadata_extractors.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/__init__.py to
 __init__.pyc
 byte-compiling build/bdist.linux-x86_64/egg/pyp2rpmlib/convertor.py
 to
 convertor.pyc
 creating build/bdist.linux-x86_64/egg/EGG-INFO
 installing scripts to build/bdist.linux-x86_64/egg/EGG-INFO/scripts
 running install_scripts
 running build_scripts
 creating build/bdist.linux-x86_64/egg/EGG-INFO/scripts
 copying build/scripts-2.7/pyp2rpm -
 build/bdist.linux-x86_64/egg/EGG-INFO/scripts
 changing mode of
 build/bdist.linux-x86_64/egg/EGG-INFO/scripts/pyp2rpm
 to 755
 copying pyp2rpm.egg-info/PKG-INFO -
 build/bdist.linux-x86_64/egg/EGG-INFO
 copying pyp2rpm.egg-info/SOURCES.txt -
 build/bdist.linux-x86_64/egg/EGG-INFO
 copying pyp2rpm.egg-info/dependency_links.txt -
 build/bdist.linux-x86_64/egg/EGG-INFO
 copying pyp2rpm.egg-info/requires.txt -
 build/bdist.linux-x86_64/egg/EGG-INFO
 copying pyp2rpm.egg-info/top_level.txt -
 build/bdist.linux-x86_64/egg/EGG-INFO
 zip_safe flag not set; analyzing archive contents...
 creating 'dist/pyp2rpm-0.4.0-py2.7.egg' and adding
 'build/bdist.linux-x86_64/egg' to it
 removing 'build/bdist.linux-x86_64/egg' (and everything under it)
 Processing pyp2rpm-0.4.0-py2.7.egg
 creating /usr/lib/python2.7/site-packages/pyp2rpm-0.4.0-py2.7.egg
 Extracting pyp2rpm-0.4.0-py2.7.egg to
 /usr/lib/python2.7/site-packages
 Traceback (most recent call last):
   File setup.py, line 39, in module
 'Topic :: System :: Software Distribution',
   File /usr/lib64

Re: Django packages - proposed name changes

[Bohuslav Kabrda]

- Original Message -
 Am 02.03.2012 10:56, schrieb Bohuslav Kabrda:
 
  Ok, so after having this approved, here is the tracking page that I
  came up with. I'd like you all to go through it and say if it's
  ok/discuss things that may not be clear.
 
  https://fedoraproject.org/wiki/User:Bkabrda/Django_rename
 
  Thanks!
 
 Great, thank you.
 
 What about retiring packages? Will this rename involve older branches
 or
 just f18 and newer?
 
 I'd suggest to do it for all (active) branches. Since we have the
 provides: django-... it won't break anything.
 
 Matthias

Hi Matthias,
I'm not sure about that. I think it's not necessary, but let the other guys 
speak and say what they think.
In my opinion, F17 and F18 should be enough.

-- 
Regards,
Bohuslav Slavek Kabrda.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Django packages - proposed name changes

[Bohuslav Kabrda]

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 02/27/2012 08:28 AM, Bohuslav Kabrda wrote:
   -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
   
   On 18/01/12 14:01, Bohuslav Kabrda wrote:
   It seems actually, that there are pretty straightforward
   guidelines for renaming packages:
   
   http://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required
  
  
  
  
   
  http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
   
   So if renaming, we will _have to_ re-review. Also, the
   guidelines are pretty clear with the Provides and Obsoletes,
   so it shouldn't really be a problem.
   
   Bohuslav.
   
   OK,
   
   if renaming is consence, we should implement it right after
   branching F17 in devel-tree.
   
   Probably one should write an example .spec, especially taking
   care on sane requires, provides.
   
   Maybe we should make a wiki page to coordinate this step
   (overview, which package is required to change, which is
   changed, etc.
   
   Bohuslav, would you start such a page? We could divide up
   reviews. I would volunteer to do some reviews.
   
   Matthias
   
   Hi guys, so it seems that we should get this started now, when we
   have plenty of time for Fedora. I was thinking about this a lot
   and here is what I came up with: 1) We should create a fpc
   ticket,
   that would summarize what we want to do, and more importantly, it
   would ask fpc to add a section about Django and its plugins to
   Python packaging guidelines. 2) Then, after approved by fpc, I
   will
   create a wiki page that will hold the list of Django
   plugins/extensions, that were/were not renamed. 3) Then, we
   should
   first review python-django, which is already in work [1], but I
   believe it might be a good idea to wait for the fpc approval,
   before we actually approve and push it. 4) Finally, we should do
   all the other packages. In case some of the packagers are not
   responsive, we should have a proven packager standing by (I know
   two personally, so that shouldn't be a problem).
   
  Sounds like a good plan. I'll be travelling from Wednesday to the
  end
  of the week, and I need to bring the python-django spec that's
  being
  reviewed in sync with our latest Django package (and make some
  changes
  already mentioned in the review ticket and in Bohuslav's email),
  but
  I'll have time to do that later this week.
  
  It'd be great to have this land (mea culpa: I'm the one who
  originally
  picked 'Django' as the package name).
  
  
  
  - --
  Michel Alexandre Salim
 
 Here is the FPC ticket, feel free to join the discussion :)
 https://fedorahosted.org/fpc/ticket/146
 
 --
 Regards,
 Bohuslav Slavek Kabrda.

Ok, so after having this approved, here is the tracking page that I came up 
with. I'd like you all to go through it and say if it's ok/discuss things that 
may not be clear.

https://fedoraproject.org/wiki/User:Bkabrda/Django_rename

Thanks!

-- 
Regards,
Bohuslav Slavek Kabrda.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Django packages - proposed name changes

[Bohuslav Kabrda]

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 18/01/12 14:01, Bohuslav Kabrda wrote:
  It seems actually, that there are pretty straightforward guidelines
  for renaming packages:
  
  http://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required
 
  
 http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
  
  So if renaming, we will _have to_ re-review. Also, the guidelines
  are pretty clear with the Provides and Obsoletes, so it shouldn't
  really be a problem.
  
  Bohuslav.
  
 OK,
 
 if renaming is consence, we should implement it right after branching
 F17 in devel-tree.
 
 Probably one should write an example .spec, especially taking care on
 sane requires, provides.
 
 Maybe we should make a wiki page to coordinate this step (overview,
 which package is required to change, which is changed, etc.
 
 Bohuslav, would you start such a page? We could divide up reviews. I
 would volunteer to do some reviews.
 
 Matthias
 

So you want to actually get this into F17? I'm not sure that this is a good 
idea, the time is short and only two of us have stated their opinions, so let's 
wait for more people and then make the decision. If we really agree on this, 
then I'll be happy to find a way to get this going (wiki page, etc.).

Bohuslav.

 - --
 Matthias Runge mru...@matthias-runge.de
mru...@fedoraproject.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQEcBAEBAgAGBQJPFsV3AAoJEOnz8qQwcaIWdbMH/Ax4ESj6qnAnC60N+4L8I1Xk
 CUKC9xTPU/S3Pmw2fgqXTs2N89W0FosSfDtX3xy8iBJ8F8QHWpNXlWl/1Lb98Kgo
 qyO4IR3AANTDZAPFc7J3hNqwUnt8NiiyVrolfM4gCKRSqp/bmEEd0xKaO+pynrnq
 bkwdcVEtIgE57QY9MzHcUyA06GobKyF9ICX/TLHqDwyfXCtx+qQYUmiW36xAOBTb
 Qjm09T1x95XvMMCnTpYoLAmUcx/3AfzOsrl2vOzJEMFhsn97dlyVtFC5M1ZwO+7v
 bnzWfQQxWmPffetjp/DN9OLNl+HbmCrltDwKsLdubDl7S6zJFbpiOu7QbtZl1CQ=
 =ejbI
 -END PGP SIGNATURE-
 
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel