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

Orphaned several Python packages

[Bohuslav Kabrda]

Hi all,
since I'm no longer using following Python packages and don't have time to 
maintain them, I'm orphaning them. Feel free to take them:

python-dingus
python-django-keyedcache
python-django-profile
python-django-roa
python-django-sorting
python-remoteobjects

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

Re: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat

[Bohuslav Kabrda]

- Original Message -
> On 09/25/2015 08:36 AM, Matthew Miller wrote:
> > On Fri, Sep 25, 2015 at 10:09:50AM -0400, Paul Wouters wrote:
> >> It's nice to be able to edit the .py for testing without going through
> >> hoops or building/installing rpms.
> >
> > Right, but you know that if you're doing that in /usr/lib, that's
> > *gross*, right? :)
> 
> To heck with gross, it's incredibly efficient.  I've done it numerous
> times to track down problems.  But that said, I'd be happy to install
> -pysource sub-package in order to do it.

Maybe we could utilize weak dependencies here. The python-foo package would 
have only bytecompiled files and would Recommend python-foo-sourcefiles. That 
way python-foo-sourcefiles would be installed in standard setting, but it would 
be possible to opt out of it.

> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Regards,
Slavek Kabrda
-- 
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 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

Re: nothing provides /bin/python needed by mercurial-3.5-1.fc23.x86_64

[Bohuslav Kabrda]

- Original Message -
 I'm stuck on this (again).  According to advice here:
 
 https://lists.fedoraproject.org/pipermail/devel/2015-June/211666.html
 
 I just needed to use
 Requires: /usr/bin/python
 
 But I tried changing
 
 Requires: python
 
 to
 
 Requires: /usr/bin/python
 
 and it doesn't work.  Somehow I still get:
 ...
 Requires: /bin/python /usr/bin/env libc.so.6()(64bit) libc.so.6(GLIBC_2.14)
 (64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit)
 libc.so.6(GLIBC_2.4)(64bit) libpthread.so.0()(64bit)
 libpthread.so.0(GLIBC_2.2.5)(64bit) libpython2.7.so.1.0()(64bit) python(abi)
 = 2.7 rtld(GNU_HASH)
 
 I don't know where this is coming from or how to fix it.

Have you checked hashbangs? RPM will automatically generate file-based requires 
for #!/bin/python, if such a hashbang is in any of the packaged files. I guess 
the proper way to fix this error would be to replace that with 
#!/usr/bin/python2.

-- 
Regards,
Slavek Kabrda
-- 
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: [Guidelines change] Changes to the packaging guidelines

[Bohuslav Kabrda]

- Original Message -
 On Thu, Aug 06, 2015 at 10:03:00AM -0400, Robert Kuska wrote:
  - 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.
 This problem is covered extensively in the guidelines:
 
   If the executables provide the same functionality independent of
   whether they are run on top of Python 2 or Python 3, then only one
   version of the executable should be packaged. On releases up to and
   including F21, this was the python 2 implementation. Python3 should
   be used in F22 and later if supported by upstream. [...]
   Transitioning from python2 to python3 is left to individual package
   maintainers[...]
 
 The switch as default was accepted as
 https://fedoraproject.org/wiki/Changes/Python_3_as_Default.
 
  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.
 Fedora is finally switching to Python 3. E.g. /usr/bin/dnf now uses Python 3,
 and a lot of other things also.

I'm not sure I understand what you're saying 100 %, so let's make this clear:
1. If the package ships a binary that does the same regardless of Python 
version used to invoke it, then /usr/bin/foo should be invoked with Python 3. 
This usually applies to applications, like dnf.
2. If the package ships a binary that does different things on different Python 
versions, then the unversioned binary should point to Python 2 version. This is 
done in order to stay in line with /usr/bin/python pointing to Python 2. This 
usually applies to e.g. test runners, coverage tools, etc.

  This applies for modules binaries such as pytest (nosetests, pip, ...)
  where is
  difference between running python2 and python3 version of the binary.
 For those cases guidelines say that both versions should be packaged.
 
  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.
 Yes.
 
  Therefore I suggest to switch order of pyX_install macros.
 Eeee, no. Let's use Python 3 by default.

Yes. Because the example in the guidelines is an example of packaging a Python 
library (point 2. above), hence the unversioned binary should still use Python 
2. Even the guidelines say that:

 For example, the python3 version of coverage must ship executables 
/usr/bin/coverage-3 and /usr/bin/coverage-3.4 (assuming python3 is currently 
version 3.4), while the python2 version must provide /usr/bin/coverage, 
/usr/bin/coverage-2 and /usr/bin/coverage-2.7 (assuming python2 version 2.7). 

 Zbyszek

-- 
Regards,
Slavek Kabrda
-- 
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

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jun 18, 2015 at 9:54 AM, Bohuslav Kabrda sla...@redhat.com wrote:
  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.
 
  Plus, this is also about Python packaging guidelines suggesting usage of
  #!/usr/bin/python3 hashbang by default [1] (assuming, of course, the
  upstream supports Python 3).
 
 I don't see that listed in the Change, but I don't think it needs to
 be.  The packaging guidelines can be changed to that independently of
 the default claim.  Frankly, I think the packaging guidelines should
 be changed and in place as a prerequisite for this being approved
 anyway.

The guidelines have already been changed to say that. Please see the link that 
I provided in my previous mail.

 josh

-- 
Regards,
Slavek Kabrda
-- 
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

[Bohuslav Kabrda]

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

Plus, this is also about Python packaging guidelines suggesting usage of 
#!/usr/bin/python3 hashbang by default [1] (assuming, of course, the upstream 
supports Python 3).

 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
  
 --
 Robert Kuska
 {rkuska}


-- 
Regards,
Slavek Kabrda

[1] https://fedoraproject.org/wiki/Packaging:Python#Guidelines
-- 
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

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jun 11, 2015, at 04:40 PM, Adam Miller wrote:
 
  I think the point that Colin is trying to make is that while Atomic
  Host does not depend on Ansible being installed, it is a very popular
  utility used to remotely manage (potentially large) sets of Atomic
  Hosts.
 
 Right, see
 https://github.com/eparis/kubernetes-ansible
 as well as
 https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00027.html
 
  Also, while Ansible is agentless it does require the remote
  machine to have python2 installed. Therefore, Fedora Atomic Host is
  likely to continue to ship Python 2.x as a part of it's default
  installation as it's in the best interest of a large population of
  it's user base.
 
 Right.

Ah, ok, that's what I needed to hear :)

  So for the time being, the switch to python3 as default for Atomic
  Host might not be an option or at the very least will be non-trivial
  in terms of what is in the best interest of the users.
 
 This could be read in multiple ways, so to restate this (again for
 the Nth time, not sure why I'm having trouble getting the point across),
 I am just saying that the end result will be *both* versions.
 
 Again: *both* versions.  Python 2 *and* Python 3.
 
 Everything could be ported, except Python 2 would still be installed
 even if no package on the host depended on it explicitly.
 
 (Hmm, I should propose a patch to add it to the manifest,
  right now it's pulled in indirectly)

Yeah, that'd be very good. I'd probably also advise to add a comment explaining 
why it's there. Just to make sure that people who come across are aware of it.

 Which is a space increase, but we'll just live with it.
 
 (I'm not the only person who works on Atomic Host so don't
  take my opinions here as entirely representative or final, but I'm
  stating my opinions based on current resourcing)

Thanks.

 For how long would Python 2 be installed?  I don't know
 but the conservative answer would probably be measured in
 units of major versions.

-- 
Regards,
Slavek Kabrda
-- 
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

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jun 11, 2015, at 09:03 AM, Bohuslav Kabrda wrote:
 
  
  Which means that it isn't *in* the Atomic host itself, but it is only used
  to *control instances* of Atomic host, is that correct? If so, I see no
  conflict with the proposed change.
 
 It's not a conflict.  I'm just making the point that in the end *both*
 versions will be there.

Could you please be more specific with your answers? What does *there* mean? 
Atomic host instance itself or a machine from which you control Atomic host 
instance?
Generally, we expect that not all software will be ported to Python 3, so we do 
expect that on some systems you'll end up having both. We'd just like to 
minimize the number of these as much as possible.

Thanks.

-- 
Regards,
Slavek Kabrda
-- 
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

[Bohuslav Kabrda]

- Original Message -
 
 
 On Thu, Jun 11, 2015, at 04:01 AM, Robert Kuska wrote:
 
  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.
 
 Ansible is agentless, you install it on your client machine, and it uploads
 Python
 code to the server, without requiring anything other than that to be
 installed.

Which means that it isn't *in* the Atomic host itself, but it is only used to 
*control instances* of Atomic host, is that correct? If so, I see no conflict 
with the proposed change.

-- 
Regards,
Slavek Kabrda
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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: [EPEL-devel] EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC

[Bohuslav Kabrda]

- Original Message -

 Sorry for the delay in getting this out. We will be continuing the EPEL
 Python discussion

 We will be in #epel on Freenode for our weekly EPEL Steering
 Committee meeting Friday 06-Mar-2015 at 17:00 UTC.

 Proposed Agenda items:

 1.) Python 3.X Discussion
 - Dual stack support?
 - Macros?
 - How can people help?

Hi, I'm sorry but I won't be able to attend today's meeting for some personal 
reasons that appeared suddenly. I believe the proposal is in a good shape and 
most pressing concerns have been discussed on the ML. If any more are concerns 
are voiced on the meeting, I'll try to handle them during next Monday. 
Also, since I've been in a huge time press lately, I'd like to pass ownership 
of this proposal to someone else during next week or week after that. One of my 
colleagues, Matej Stuchlik (CCed), has expressed an interest and would be 
willing to take this - that's unless someone else who's participated up until 
now wants to take it. 
I'll still be around doing suggestions and trying to help, I just don't have 
the time to really drive this effort and do all the hard work. I'll try to ask 
Matej to come to the meeting, assuming he has the time today. 

Thanks for understanding, 
Slavek 

 2) Keep the meeting at the same UTC time? [I would like to do so.]

 3) Open Floor / Other Items

 --
 Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
 On 03/03/2015 06:31 AM, Bohuslav Kabrda wrote:
  Today, I've made some changes to the proposal to accomodate comments from
  the previous meeting and from discussion on this list. The diff is here:
  
  https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3diff=405180oldid=404782
  
  I'd appreciate comments, I hope I made it clearer and more explanatory.
  
  Thanks for your comments,
  Slavek
  ___
 
 Can we add the proper _sitelib / _sitearch macros to the example spec file?
 Thanks.

Done. I added one more change that's not mentioned in the yesterday's diff, so 
here's are all the changes since the last diff I sent:
https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3diff=405371oldid=405180
(I made the example specfile look like a full example, I added rules for files 
in /usr/bin and I also included a definition of libraries and applications 
- the two package types I think we need to distinguish)


Slavek

 --
 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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
 On 03/03/2015 08:35 AM, Kevin Fenzi wrote:
  On Tue, 3 Mar 2015 07:46:00 -0500 (EST)
  Bohuslav Kabrda bkab...@redhat.com wrote:
  
  ^ Is this step part of a coordinated mass-rebuild, or is this just a
  period of time after we make the announcement: Hey Packagers: be
  sure to rebuild for python35?
 
  That's a good question. I guess we should standardize how this will
  be done. Something like:
  - there's an announcement on epel-devel that python35 is the main
  python3 and packagers should rebuild their packagers (and users
  their apps/scripts/...)
  - wait for a week (two?)
  - open bugs for packages that haven't been rebuilt during the
  previous week and get them fixed ASAP
  
  I'd say just doing the mass rebuild by a provenpackager or the like
  would be easier than filing bugs and waiting.
 
 Yeah, just do the builds and be done with it.  Will need to get built in dep
 order.

My concern is that in some cases we may actually need for upstream to release 
supported version for the new Python release. However much Python upstream is 
cautious about not introducing regressions, from time to time a small backwards 
incompatibility change can crawl in and cause problems to certain packages that 
rely on the changed code.

  Also, we need to coordinate the update with them in it... ideally they
  would all be in the same update?
 
 That's seem sure to crash bodhi :)
 
 As long as deps are pushed out in the right order things would be okay.

Yeah, ideally it should work like that, but in some cases we may want to just 
push everything that has been rebuilt to bodhi and not wait for one or two 
laggards.

Slavek

 --
 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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
 On Mar 02 06:53, Bohuslav Kabrda wrote:
  - Original Message -
 ...SNIP...
  
  I think applications should use /usr/bin/python3.4 (at least packaged
  applications). Otherwise we could theoretically end up in a situation
  where /usr/bin/python3 is owned by python35, but the application RPM still
  has python34- dependencies and thus the app doesn't work.
  
  I think this is actually one of the reasons why I thought it makes sense to
  keep both python34 and python35 living together in the state where
  python35 is the main python3 (having the default macros and owning
  /usr/bin/python3) and python34 is the other. Let's take this example:
  - there's an application foo written in python, which requires six
  - it doesn't make sense to build the application for both python34 and
  python35, since it's an application, not a library
  - this means it doesn't make sense for package maintainer to introduce the
  %python3_{other or next}* macros to the specfile, maintainer just wants to
  build with the python3
  - so this means that we should do this:
  -- python 3.5 is released, we build it in EPEL and turn with_python3_other
  to 1 in python3-pkgversion-macros
  -- then there's a period when python34 and python35 coexist and python34 is
  the main python - in this period, *libraries* are rebuilt to provide
  both python34- and python35- subpackages
  -- python34 and python35 are switched (the default macros now point to 35
  and it also owns /usr/bin/python3 now)
  -- then there's a period when python34 and python35 coexist and python35 is
  the main python - in this period, *applications* are rebuilt for
  python35 (may take some time, there will likely be a period when there are
  some apps on python34 and some already on python35)
 
 ^ Is this step part of a coordinated mass-rebuild, or is this just a
 period of time after we make the announcement: Hey Packagers: be sure
 to rebuild for python35?

That's a good question. I guess we should standardize how this will be done. 
Something like:
- there's an announcement on epel-devel that python35 is the main python3 and 
packagers should rebuild their packagers (and users their apps/scripts/...)
- wait for a week (two?)
- open bugs for packages that haven't been rebuilt during the previous week and 
get them fixed ASAP

 One alternative might be to do python35 in a side tag, after which we
 could release the libraries and applications, and deprecate python34
 together. This might take quite a bit more work though.

+1, I don't want to introduce side tags to the process.

  -- when all applications are rebuilt for 35, with_python3_other is set to 0
  and we now have just python35 and it's the main python3
  
  Does this make sense or am I missing something? I'd need to do some minor
  changes+explanations to my proposal to accomodate this, but I still think
  it makes sense.
  
   What about all of the old python34 packages left on their systems after
   retirement?  Is there some way they can get cleaned up automatically?
  
  I'm not sure about that... and I'm also not sure we want to do that, people
  may still want to keep these around for their own non-system applications
  to migrate.
 
 Great discussion so far!
 
 Brian

Thanks,
Slavek

 --
 Brian Stinson
 bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
snip
   * applications will need to be rebuilt to pick up a change from
 python34-* to python35-*
   which is a bit unfortunate.
   
   Is there any reason why we shouldn't just upgrade applications to the
   python35-* stack straight away, by providing python3-*?
  
  Yeah. First of all, it may happen that there are some minor backwards
  incompatibilities. Lots of packages run tests during buildtime, so
  these will be caught.
  Another reason is that there are applications, which store files in
  /usr/lib/python3.X/site-packages - these need to be rebuilt anyway,
  since they have the Python minor version incorporated in path of
  files.
  I really think that we should rebuild applications with new Python
  3.X.
 
 Well, they should really be using pkg_resources instead of hardcoding
 the path... but yes I take your point. Rebuilding for the newer Python
 stack makes sense.

There is no hardcoded path. The problem is that /usr/bin/python3.4 import 
modules from /usr/lib[64]/python3.4/site-packages. So when /usr/bin/python3 
switches all of a sudden from python3.4 to python3.5, the app will try to 
import the module from /usr/lib[64]/python3.5, but it's not there. That's why I 
think we should use /usr/bin/python3.X rather than /usr/bin/python3.

 We will need to make sure that setuptools-generated entry points have
 a shebang of /usr/bin/python3.4 rather than just /usr/bin/python3
 though, so that the scripts are always invoked with the same Python
 stack they are built for. Currently on Fedora they have
 /usr/bin/python3. This might need a patch to
 setuptools/distutils/whatever it is?

Good point. I *think* setuptools uses the executable with which it was executed 
for hashbangs, so if you use /usr/bin/python3.4 setup.py build, hashbangs 
will have #!/usr/bin/python3.4. I have already modified the __python3 macro 
in my copr to point to /usr/bin/python3.4 instead of /usr/bin/python3, but I 
haven't rebuilt the other packages with it yet. I'm putting it on my TODO list 
to check this.

 --
 Dan Callaghan dcall...@redhat.com
 Software Engineer, Hosted  Shared Services
 Red Hat, Inc.

Thanks a lot,
Slavek
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-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: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
 This is a followup to the EPEL IRC meeting discussion about python 3.  I had
 a
 couple questions which led me to take Slavek's excellent work and try some
 changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3
 
 Main ideas:
 - (bikeshedding) - I didn't like the wording other, so I went with next.

Right, this naming makes more sense due to the way your proposal works - in 
other words, next is always the higher version, assuming there are two 
parallel stacks. This isn't always the case in my proposal, which is why I used 
other.

 - I didn't like having to toggle a macro in the spec files, I'm lazy

+1, this can be done globally in python3-pkgversion-macros regardless which 
proposal we use.

 - What happens on the user's end?
 
 So:
 
 Lifecycle of python3X stacks, rebuilding:
 
 when a new python3X+1 is built in EPEL - let's say that there is python34
 and python35 has just been introduced:
 A new python3-pkgversion-macros is build defining the %python3_next*
 macros.

I think that macro file *in python35-devel* should define this - the main 
python3 defines %python3* macros, the next/other python3 defines 
%python3_next*.

 (scripted) mass rebuild is run to build as much of the new stack
 possible automatically.
 At some point /usr/bin/python3 is switched from python34 to python35.
 at a certain point at time an announcement is made that python34 is
 to
 be retired and python35 is to be *the* one. At this point:
 python3-pkgversion-macros is rebuilt removing the %python3_next*
 macros.

As per my comment above, we wouldn't need to remove the next macros, we would 
rebuild python35 as main python3, thus giving it the normal %python3 macros.

 python35 is rebuilt defining the normal %python3_* macros
 all python34 packages are retired
 
 At this point all packages build just python35-X subpackages
 
 
 
 What I still don't understand is what this looks like on the user end, how do
 they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like
 this
 should be as automatic as possible.  So shouldn't they still use
 /usr/bin/python3 rather than /usr/bin/python3X so they get updated
 automatically?

I think applications should use /usr/bin/python3.4 (at least packaged 
applications). Otherwise we could theoretically end up in a situation where 
/usr/bin/python3 is owned by python35, but the application RPM still has 
python34- dependencies and thus the app doesn't work.

I think this is actually one of the reasons why I thought it makes sense to 
keep both python34 and python35 living together in the state where python35 is 
the main python3 (having the default macros and owning /usr/bin/python3) and 
python34 is the other. Let's take this example:
- there's an application foo written in python, which requires six
- it doesn't make sense to build the application for both python34 and 
python35, since it's an application, not a library
- this means it doesn't make sense for package maintainer to introduce the 
%python3_{other or next}* macros to the specfile, maintainer just wants to 
build with the python3
- so this means that we should do this:
-- python 3.5 is released, we build it in EPEL and turn with_python3_other to 1 
in python3-pkgversion-macros
-- then there's a period when python34 and python35 coexist and python34 is 
the main python - in this period, *libraries* are rebuilt to provide both 
python34- and python35- subpackages
-- python34 and python35 are switched (the default macros now point to 35 and 
it also owns /usr/bin/python3 now)
-- then there's a period when python34 and python35 coexist and python35 is 
the main python - in this period, *applications* are rebuilt for python35 
(may take some time, there will likely be a period when there are some apps on 
python34 and some already on python35)
-- when all applications are rebuilt for 35, with_python3_other is set to 0 and 
we now have just python35 and it's the main python3

Does this make sense or am I missing something? I'd need to do some minor 
changes+explanations to my proposal to accomodate this, but I still think it 
makes sense.

 What about all of the old python34 packages left on their systems after
 retirement?  Is there some way they can get cleaned up automatically?

I'm not sure about that... and I'm also not sure we want to do that, people may 
still want to keep these around for their own non-system applications to 
migrate.

Thanks a lot for this discussion,
Slavek

 --
 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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

- Original Message -
 Excerpts from Bohuslav Kabrda's message of 2015-03-02 21:59 +10:00:
  - Original Message -
   Under the current proposal every package with Python 3 dependencies
   would have to depend on a specific python3x-* package, so then it would
   be up to the maintainers of all those packages to manually bump their
   Requires from python34-* to python35-* at some point. Which, now that
   I think about it, is not that great. Even worse, if any packages form
   a transitive dependency chain then *all* packages in the chain have to
   update their Requires at the same time to avoid having a mix of
   python34-* and python35-* requirements.
  
  Not really. The requires/buildrequires should be in form of
  Requires: python%{python3_pkgversion}-six
  so when we change %python3_pkgversion in the minimal buildroot,
  maintainer just rebuilds and gets updated requires.
 
 Hmm okay. I didn't realise this.
 
 So that means that:
 * Fedora specfiles can't be used unchanged (they will require python3-*,
   needs to have %{python3_pkgversion} macro inserted)

True, but note that we'll make %python3_pkgversion macro available also in 
Fedora (always defined to 3), so once this change is done, it'll be possible 
to have the same specfile both in Fedora and EPEL.

 * applications will need to be rebuilt to pick up a change from
   python34-* to python35-*
 which is a bit unfortunate.
 
 Is there any reason why we shouldn't just upgrade applications to the
 python35-* stack straight away, by providing python3-*?

Yeah. First of all, it may happen that there are some minor backwards 
incompatibilities. Lots of packages run tests during buildtime, so these will 
be caught.
Another reason is that there are applications, which store files in 
/usr/lib/python3.X/site-packages - these need to be rebuilt anyway, since they 
have the Python minor version incorporated in path of files.
I really think that we should rebuild applications with new Python 3.X.

Slavek

 --
 Dan Callaghan dcall...@redhat.com
 Software Engineer, Hosted  Shared Services
 Red Hat, Inc.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Friday EPEL meeting and python3x

[Bohuslav Kabrda]

- Original Message -

 Hello, I will not be able to attend, but Brian Stinson has offered to chair
 the meeting. An agenda will be sent out on Thursday, but I think the main
 focus will be on what is needed to get python3x into EPEL and in that
 discussion what things we are going to want out of short-lifed packages in a
 long term repo. [EG python34 will be EOL sometime after python35 comes out..
 the same with 35 when 36 comes out. Does saying that it would be great to
 have dual stack support actually something we can deliver or should we go
 with you can't have python34 and python35 installed at the same time.]

I believe that having both stacks coexist for some limited amount of time is 
necessary here. Without that, we would be hitting periods with really 
broken/incomplete python3 stack and I think we want to avoid that. 
I already created a copr repo for this [1] where I'll start landing first 
builds today for everyone to test - doing parallel installable python3X stacks 
is actually pretty easy and I pretty much have everything working locally right 
now, so I really recommend to go with parallel installable stacks (while I 
agree that the period when both coexist should be kept to minimum). 

 --
 Stephen J Smoogen.

-- 
Regards, 
Slavek Kabrda 

[1] https://copr.fedoraproject.org/coprs/bkabrda/python34-epel7/ 
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python3x rpms (how do the IUS ones stack up with what we are looking for)

[Bohuslav Kabrda]

- Original Message -

 So I found that I had somehow gotten black holed on IUS emails and cleaned
 that up today. In doing so I found they have an Python34u already in their
 archives

 http://dfw.mirror.rackspace.com/ius/stable/CentOS/7/SRPMS/

 has a list of packages which they contain. I haven't looked too closely to
 see how they match up with the current proposal.. or if they would pass a
 fedora review yet. I wanted to bring them up as a strawman to look at for
 reference to what Bohuslav Kabrda bkab...@redhat.com had been aiming for (in
 case it helps. If it doesn't.. disregard while I go get some more cough
 medicine.)

 --
 Stephen J Smoogen.

Thanks for the link, this actually looks very similar to what I'm planning to 
do with my proposal, although I think it doesn't handle parallel python3X and 
python3X+1 stacks. As you suggested in the other email, I'll try to build a 
proof of concept minimal python34 stack with several packages (in Copr, most 
likely) and post it here for testing and comments. If everything looks good, 
I'll start pushing it to EPEL after that. 

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

Reverting Python 3 Migration Improvements Change

[Bohuslav Kabrda]

Hi,
I have to inform you that I had to revert the Python 3 Migration Improvements 
change for F22 - more precisely, its parts that would've caused both Python 2 
and Python 3 being on atomic host or minimal cloud image. The reason is 
mentioned in [1] - in short, policycoreutils-python3 has only partial 
functionality compared to policycoreutils-python, which I didn't understand 
from my communication with its maintainers previously. It's too late to 
implement and repackage that now, so I'm reverting the change.

I went on and asked maintainers of packages that are either on atomic host or 
minimal cloud image to revert the Python 3 changes in F22 (authconfig and 
firewalld) - I did this myself for packages that didn't seem to have 
maintainers online (pcp and gettext) - these are the packages marked with (*) 
in [2] (some of them were supposed to be rebuilt today, so I put a note in BZ 
to only rebuild for F23).
Since both Python interpreters have already been on livedvd for several 
releases, I think it's still safe to rebuild the rest with Python 3 (== those 
not marked with (*)) for F22, if their maintainers wish to do so. Either way, 
this change is not happening for F22 as submitted.

For F23, I'll do some updates to [3], then discuss the form of bugreport to 
mass file here and then do mass filing. Hopefully I'll get to this during this 
week or next week.

Thanks for understanding. And huge thanks goes to everyone who took part in 
this effort. We really did tons of work and were very close - for F23, we're 
doing this!

Regards,
Slavek

(damn, this was hard to write...)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1194577#c4
[2] https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements#Scope
[3] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
-- 
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] How to formalize and finish the Py3 proposal?

[Bohuslav Kabrda]

- Original Message -
 On Feb 19 04:54, Bohuslav Kabrda wrote:
  Hi all,
  so I think everyone was able to express their opinions about my Python 3
  proposal for EPEL [1] and I think it's time for me to formalize it, get it
  approved and actually do it. I'm however unsure about how this works in
  EPEL and I haven't been able to find a reference to a specific process.
  Can someone please advise (send a link/explain/...) on what is the best way
  to formalize such proposal for EPEL and who to propose it to?
  
  Thanks a lot,
  Slavek
  
  [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
 
 We agreed to move forward with the proposal at our last meeting[1]. I'm
 thinking we should put this on the agenda again to talk about details
 and see how we can help.

Oh, ok :) Well the proposal has several parts where it's not specific or says 
we can do stuff this way or some other way. I'd suggest creating a new document 
(I'm just not sure where), that will serve as the official document about Py3 
in EPEL and I'd like to polish the proposal there. Does that sound good? (I 
really only need to know the proper place where this should live).

Thanks,
Slavek

 Cheers!
 Brian
 
 [1]
 http://meetbot.fedoraproject.org/epel/2015-02-13/epel.2015-02-13-17.00.html
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

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: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Fri, 30 Jan 2015 04:44:19 -0500 (EST)
 Bohuslav Kabrda bkab...@redhat.com wrote:
 
  I just had a quick IRC chat with DNF maintainer and he said we still
  wants to switch to py3 for F22.
 
 Lovely.
 
 Perhaps we could get the dnf folks, anaconda, qa and fesco all together
 in one place to discuss this?

Yeah, I'm not opposed to that, although with DevConf on my back, I'm not likely 
to organize anything like this during this week.

   We will not be replacing python2 entirely, it and packages that
   depend on it will still be available for now.
  
  Doesn't [1] say it?
 
 Fair enough. I looked for that wording and didn't see it. ;(
 
  Yeah, as noted by Stephen Smoogen, I think the problem is
  communication here. Judging from reactions of people who I talked to,
  everyone takes it as FESCo thinks that Python 3 is not ready and not
  the way to go right now. That's also what I thought when I read
  simple defer this to F23. After these conversations here I'm
  starting to understand that this is not a message that FESCo meant to
  send. Python 3 migration improvements sounds about right to me and
  seems to send a better message than just deferring to F23. Can
  someone from FESCo comment on this? If this sounds ok, shall I create
  a change page for it?
 
 I'm personally in favor of that, but I'm also in favor of deferring the
 dnf and anaconda python3 changes. But thats just IMHO.

I created a change and submitted it to change wrangler: 
https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements
I asked Jarda Reznik to process it ASAP, so it should be ready soon.

  As I noted above, DevAssistant devels have been using python3-dnf for
  quite some time now without any issues. I've written couple of
  scripts using python3-dnf and run them regularly without any issue. I
  even replaced #!/usr/bin/python by !#/usr/bin/python3
  in /usr/bin/dnf some time ago and everything still works (how ugly is
  that? :)). I know, that's not extensive testing, but it's certainly
  not zero.
 
 ok. Fair enough. Some small amount of testing. :)
 
 It's not at all the same scale as: Been in fedora for years and we
 have asked people to test it a bunch for the last few years.

I know :)

 I'm using dnf-3 here now and haven't hit any dnf-3 specific bugs, but
 that again is a small sample size.
 
   * anconda switches to python3 (it's almost ready, but no telling
   what issues we will hit, it's not even landed yet).
   
   Should we toss in a UI redesign so we can have Fedora 18 again?
   (sorry, that was rude of me)
  
  Why not :)
 
 You weren't here for Fedora 18 were you? ;)

I've been around since 15... 18 was fun ;)

  I'd say we should leave this up to developers of DNF and Anaconda.
  They're the best ones to say whether they're ready or not.
 
 I suppose so, but I think we should also take into account QA and
 others input.

I'm not saying we shouldn't. AFAIK dnf can be safely switched back and forth, 
so the best way (IMO) would be to switch it ASAP to py3 and see what it breaks. 
We can always switch it back before Beta or so. I think that enough people will 
test it before then.

Slavek

 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

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Thu, 2015-01-29 at 08:56 -0500, Bohuslav Kabrda wrote:
  I'm regularly talking to some of Anaconda devs (mostly Vrata
  Podzimek) and they still think this is doable *without* introducing
  high number of regressions, that would be impossible to fix before
  F22 final.
 
 That doesn't seem to be what other anaconda devs are saying:
 
 bcl 07:58:01 And personally, I'd like to see full python3 support
 go through a rawhide cycle instead of switching right before alpha --
 but that's just me.
 
 ===
 
 bcl 08:09:57 my opinion is that we need a fallback, which is yum,
 and we need time to shake py3 bugs out in rawhide.
 sgallagh 08:10:27 bcl: A fallback to python 2 dnf isn't acceptable?
 bcl 08:10:39 So my suggestion would be to stay with dnf py2 for F22
 with yum as a fallback. And after we branch for f22 next month charge
 ahead with py3 conversion.
 
 (in case it's not clear, the point bcl is making there is that moving
 anaconda to python3 commits it irreversibly to DNF because there is no
 python3 yum, and he'd much rather have yum available as a fallback for
 anaconda for F22 in case we find too many bugs in DNF)
 
 ===
 
 clumens 08:19:36 i want to avoid the two month blocker treadmill
 grind this time
 dlehman 08:21:59 Trying to cram this into f22 alpha is begging for
 abuse IMO
 
 ===
 
 To be completely honest, I think vpodzime is exactly at the point we
 all were at for the 'noloader' change, and newui, and storage rewrite,
 and GPT-by-default; where you've pretty much got what you think of as
 the 'main work' of writing all the code done so you think hey, it
 should be no problem to throw this in, right? We've got a few months
 to fix the bugs and there won't be that many, right?
 
 What bitter experience taught us is there are *always* more bugs than
 you expect, and fixing them is *always* more work than you expect.
 anaconda is a huge hairy mess with 100,000 use cases. When you get
 Step 1 done - in this case, I guess, made it so anaconda runs under
 Python 3 and gets through whatever little ad hoc test you've been
 using - you have not got 90% of the work done, really. You've got
 maybe 50-60% of it done. Maybe we're just a bunch of old cynics, but
 it seems an invariable rule that there will be a ton of stuff that you
 just didn't see coming, and that's not a good combination with a short
 release cycle we really want to stick to (which I believe is the case
 for F22) and a strong desire on both anaconda and QA's part to avoid
 or at least mitigate the stress and burnout-inducing 'blocker
 treadmill' effect.

Ok, I'm not new to software development :) I know that let's do this, what can 
break? are famous last words.
As I've said in one of my other mails, I'm not forcing anyone to do the switch, 
so I'll just leave it up to Anaconda devs. And yeah, I know that some of them 
are optimistic and some others pesimistic about this change.

 I don't agree that pushing the anaconda change to F23 just moves the
 same problems out in time, either. We *have* made improvements to the
 Fedora process in general which mean this just isn't true any more. We
 can commit the Python 3 change to Rawhide the day after F22 branches
 and really go all-in on it there, and those bits *don't* just get
 ignored. anaconda has its own tests now, for one thing, so at least
 those are going to get run, and that coverage is getting bigger. We
 *do* get nightly builds from Rawhide constantly now, even when there's
 a branched, and people do test them - no, not as often as we test
 Branched, but they do get tested. And at least *the day after F22
 ships* we will shift focus to an F23 which is already Python 3-ized
 and we can be testing and finding bugs in it from that date on all the
 way up to release; that's an extra ~2 months of testing vs. making the
 switchover at *this* point in the F22 cycle, even if you imagine we do
 absolutely zero testing on F23 while F22 is in progress.

I've ported *dozens* of upstreams to Python 3 (also, while maintaining Python 
2.6+ compatibility) and I think people overestimate the dangers of doing this. 
It's not like everything is going to blow up and still won't work after 
hundreds of man hours. Anaconda codebase is well written and in a good shape to 
be switched and I still think it can be done (even if I double the number of 
bugs I would realistically expect to occur).
You're saying that Anaconda has its own tests right now and that's great, I 
think that's actually an argument that suggests it should be safer to do the 
switch.
But as I've said, let's leave this up to Anaconda devs.

 As https://www.happyassassin.net/testcase_stats/22/ shows, we have
 already done a decent amount of testing on Fedora 22 and it's still ~2
 weeks before Alpha TC1. Switching anaconda to Python 3 at this point
 substantially reduces the value of a lot of that testing. To me, this
 is a clear demonstration that there's a significant difference

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -

 On 29 January 2015 at 07:39, Bohuslav Kabrda  bkab...@redhat.com  wrote:

  - Original Message -
 
   On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda  bkab...@redhat.com 
   wrote:
 
- Original Message -
 
On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač  m...@redhat.com 
wrote:
 
 (Speaking only for myself, not for all of FESCo; hoping others will
 
 chime
 
 in.)
 
 - What if Anaconda does make it? :)
 
 I don’t know.
 
   
 
I'm skeptical that will happen. Even if it does, that alone is likely
 
not enough to claim python3 by default. You need all the basic
 
functionality to work with pthon3, e.g. yum and dnf would also need to
 
be ported.
 
   
 
DNF works with Python 3, Yum will never work with it (this is why the
 
change page says that this feature depends on DNF becoming the default
 
package manager). I'm regularly talking to some of Anaconda devs
(mostly
 
Vrata Podzimek) and they still think this is doable *without*
introducing
 
high number of regressions, that would be impossible to fix before F22
 
final.
 
  
 
   Good to know DNF is already fine in regards to python3. I must have
 
   misunderstood the references to python3-dnf yesterday. I was under
 
   the impression that it was something that existed, but wasn't widely
 
   used or tested at this point. It certainly didn't seem to be the
 
   default dnf that everyone is using in F20/F21 (and rawhide today)
 
   installs.
 

  Not sure about it being the default, but we've been testing it in
  DevAssistant for dependency installation on Python 3 and never encountered
  any problems. I was also contacted by dnf maintainer with a question on how
  to switch dnf to use python3-dnf (package-wise), so I guess that's what
  will be done for F22 (but that's just my guess, dnf maintainer would have
  to
  comment here).
 

   Even still, that hinges on DNF being the default package manager in
 
   F22. There are some concerns that it won't make it due to rel-eng
 
   tooling used to compose the images, etc. If that's the case, yum will
 
   still be required.
 

  Required, yes, but we'll still have tons of packages built with Python 2. I
  never said that porting rel-eng tooling is the goal for F22.
 

What else is all basic functionality? If this is about making
Workstation
 
LiveCD python2-free, then I'm not sure we can make that even for F23
 
(samba and glusterfs will be hard nuts to crack, although the work on
 
samba has already started).
 
  
 
   That might be a good goal, but it wasn't what I was thinking. I was
 
   thinking more along the lines of a more minimal install only requiring
 
   python3 to be installed. I don't have a concrete package set in mind
 
   at the moment.
 

  So if more minimal is minimal buildroot, then we can achieve that, since it
  only has python-libs because of gdb and gdb can be rebuilt with Python 3
  (upstream source is compatible). If that means minimal cloud image, then we
  can do it (we're waiting for the cloud-init folks to accept the py3
  patches,
  which should happen any time now). If that means content from
  fedora-live-base.ks, then we can do pretty much everything, except of samba
  (I think) - and Petr Viktorin is doing some talking to people to get rid of
  samba from this config, because it seems to be unnecessary there.
 

 - What is enough? It's possible that two or three packages may be
 
 still
 
 unported even in F23 (and as for server livecd in F23, I think
 there
 
 will
 
 be
 
 few more).
 
 2-3 packages should not be an issue, perhaps unless they were very
 
 visible
 
 (e.g. having a public and widely-used Python plugin API).
 

 
 - So is it ok if I file bugs for all components that I know are
 
 upstream-compatible with Python 3 (bugs to get them switched, I
 mean)?
 

 
 If we are shipping both Python versions anyway, and the specific
 
 packages
 
 are known to be compatible (i.e. there little risk), I don’t see any
 
 reason not to switch them already in F22.
 
   
 
I agree with everything Mirek said, as well as his take on the FESCo
 
reasoning.
 
   
 
We'd really like to see this happen, we don't want to slow down the
 
work. We just don't feel F22 is a release that is going to accurately
 
reflect the python3 as default status.
 
   
 
What I'm afraid is that by postponing this change, we will have
achieved
 
nothing else, than half more year of status quo.
 
  
 
   That's understandable, and to be honest a good concern. At the same
 
   time, just declaring something as default when reality doesn't
 
   reflect that really won't achieve the actual goal either. FESCo is
 
   hoping that opening the bugs against rawhide after F22 branching will
 
   help prod things along. We'll be happy to revisit at that point

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Thu, 29 Jan 2015 09:39:28 -0500 (EST)
 Bohuslav Kabrda bkab...@redhat.com wrote:
 
  Not sure about it being the default, but we've been testing it in
  DevAssistant for dependency installation on Python 3 and never
  encountered any problems. I was also contacted by dnf maintainer with
  a question on how to switch dnf to use
  python3-dnf (package-wise), so I guess that's what will be done for
  F22 (but that's just my guess, dnf maintainer would have to comment
  here).
 
 See the thing there that makes my teeth itch is: dnf has been
 massively great about having a long on-ramp. It appeared, it didn't
 replace yum, it let people try it out and report bugs, there was a long
 time of testing. Thats all great. But now, we switch it to dnf-3 and...
 that has not had years of running in rawhide and other releases, it has
 not had people testing it and reporting bugs. While the code overlap
 could be pretty large, I am willing to bet a shiny us dollar that there
 are some python 3 specific bugs lurking in it.
 
 So, we turn on this not very tested path and immediately try and use it
 as default in anaconda and a new release. What happened to our nice
 long ramp? Or any ramp?

I just had a quick IRC chat with DNF maintainer and he said we still wants to 
switch to py3 for F22.

   Even still, that hinges on DNF being the default package manager in
   F22.  There are some concerns that it won't make it due to rel-eng
   tooling used to compose the images, etc.  If that's the case, yum
   will still be required.
  
  Required, yes, but we'll still have tons of packages built with
  Python 2. I never said that porting rel-eng tooling is the goal for
  F22.
 
 Might be good to note that on the change page:
 
 We will not be replacing python2 entirely, it and packages that depend
 on it will still be available for now.

Doesn't [1] say it?

  So if more minimal is minimal buildroot, then we can achieve that,
  since it only has python-libs because of gdb and gdb can be rebuilt
  with Python 3 (upstream source is compatible). If that means minimal
  cloud image, then we can do it (we're waiting for the cloud-init
  folks to accept the py3 patches, which should happen any time now).
  If that means content from fedora-live-base.ks, then we can do pretty
  much everything, except of samba (I think) - and Petr Viktorin is
  doing some talking to people to get rid of samba from this config,
  because it seems to be unnecessary there.
 
 ok. So, perhaps we should have a change around this for f22, but it
 should be: Python 3 migration improvements or something, not
 'default' ?

Yeah, as noted by Stephen Smoogen, I think the problem is communication here. 
Judging from reactions of people who I talked to, everyone takes it as FESCo 
thinks that Python 3 is not ready and not the way to go right now. That's also 
what I thought when I read simple defer this to F23. After these 
conversations here I'm starting to understand that this is not a message that 
FESCo meant to send. Python 3 migration improvements sounds about right to me 
and seems to send a better message than just deferring to F23.
Can someone from FESCo comment on this? If this sounds ok, shall I create a 
change page for it?

  Considering all the information mentioned above and assuming Anaconda
  makes it, I'd say it should be perfectly possible to declare Python 3
  the default. As for the packages that are not in the minimal
  installs, I can always open bugs for them before beta and only those
  maintainers who believe it to be safe can switch.
 
 Yeah, so if anaconda switches we get:
 
 * anaconda switches to dnf (this is already done in rawhide after last
   branch point, so I think it's quite safe/doable).
 * anconda switches to dnf-3 (if we land that change. It's gotten 0
   testing that I know of).

As I noted above, DevAssistant devels have been using python3-dnf for quite 
some time now without any issues. I've written couple of scripts using 
python3-dnf and run them regularly without any issue. I even replaced 
#!/usr/bin/python by !#/usr/bin/python3 in /usr/bin/dnf some time ago and 
everything still works (how ugly is that? :)). I know, that's not extensive 
testing, but it's certainly not zero.

 * anconda switches to python3 (it's almost ready, but no telling what
   issues we will hit, it's not even landed yet).
 
 Should we toss in a UI redesign so we can have Fedora 18 again?
 (sorry, that was rude of me)

Why not :)

 Wouldn't it be safer to defer dnf-3 and anaconda-py3 for next cycle,
 but make those changes in rawhide after the branch point? Then they
 would actually get months of shake out...
 
 kevin

I'd say we should leave this up to developers of DNF and Anaconda. They're the 
best ones to say whether they're ready or not.

Slavek

[1] 
http://fedoraproject.org/wiki/Changes/Python_3_as_Default#Upgrade.2Fcompatibility_impact
-- 
devel mailing list
devel@lists.fedoraproject.org
https

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Wed, 28 Jan 2015 11:09:08 -0500 (EST)
 Bohuslav Kabrda bkab...@redhat.com wrote:
 
  Hi,
  I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I
  realized that I should probably follow the mass bug filing policy. As
  I've said previously, we've already had both Python 2 and Python 3 on
  LiveCDs for few releases, so it makes sense to move as much as
  possible to Python 3. My intention is to mass file bugs only for
  applications (see the second item in second list at [D]) - in
  short, these are packages for which it doesn't make sense to
  introduce python3- subpackage, but it only makes sense to rebuild
  them with Python 3. The mass bug filing policy suggests providing
  text of the bug for review, so here it is:
 
 So, at today's FESCo meeting there was a good deal of discussion about
 python as default:
 http://meetbot.fedoraproject.org/fedora-meeting/2015-01-28/fesco.2015-01-28-18.02.log.html#l-41
 
 in which we agreed defer this to F23, file bugs against rawhide after
 branch (+6,0,0)

I really don't get this. I was over the log and didn't find a compelling 
argument as to why this should be postponed. Can someone sum the arguments up, 
please? (I'm not acting hurt or something like that here. I really don't 
understand why you decided the way you did and what benefit that decision will 
bring.)
I've noted several times on this list, that this is a best effort change. If 
package X isn't ported upstream, then we don't need to switch it (be it 
Anaconda or anything else). Postponing this change won't help anything, or will 
it? OTOH if we do accept the change for F22, we'll give everyone strong signal 
that this is something serious and people might start to get really interested 
and find out why going to Python 3 is better than the current state.

 Not speaking for FESCo, but myself, if you think there is still
 advantage in trumpting the python3 changes that will land in f22,
 please do rescope the change and resubmit. I realize this is a
 process thats going to take a while to complete.
 
 Now, on to the mass bug filing...
 
 Do you have a list of packages you intend to file against?

Not a complete one, no. I do have the list of packages that we need to port to 
have minimal cloud image/workstation LiveCD (these are the ~10 that I mentioned 
in the previous mail):
cloud image: audit cloud-init heat-cfntools
workstation livecd (audit is in both): audit bind caribou environment-modules 
gdb gettext gnome-abrt gupnp nfs-utils pidgin sos telepathy-gabble totem

(ok, so it's 15)

  Since your package requires Python and is considered an application
  as per [1], I'd like to ask you to rebuild it with Python 3. Please
  see recommendations and notes at [2]. Note: this switch should only
  be done assuming you need to do none or very little downstream
  patching of upstream source. If upstream source doesn't work with
  Python 3, it's ok to stay with Python 2.
  
  Some general notes:
  If your package depends on Python because of a Python script that
  has /usr/bin/python in hashbang, you need to change this
  to /usr/bin/python3. All Requires and BuildRequires on Python
  extension modules have to be changed from python-foo to
  python3-foo in order for this change to work. If your package is an
  application (let's call it foo) and it also generates a
  subpackage with Python bindings (i.e. python-foo or foo-python),
  you should provide a python3 subpackage (python3-foo or
  foo-python3) and use that as dependency of other subpackages.
  
  [1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
  [2] https://fedoraproject.org/wiki/Packaging:Python#Guidelines
 
 I'd prefer people make these changes after we branch in rawhide, but as
 always it's going to be up to the maintainer(s) what is best for their
 packages.

I'm not sure I understand. So you're saying that the change is deferred but at 
the same time everyone can move to Python 3 if they wish. Since I've already 
said that this is best effort and I don't mean to *force* anyone to move, I 
don't see how this is different. Does this mean that I can still ask 
maintainers of the packages mentioned above to move to Python 3 (and they can 
move if they wish to do so)?

  If everyone agrees, I'll send a mail to devel-announce, saying that
  we're switching to Python 3 and all maintainers should rebuild with
  it, assuming that upstream sources are Python 3 compatible. After a
  week or so I'll file bugs for the remaining components. I haven't yet
  determined the number of affected packages, since I'm mostly
  interested in packages that are on LiveCD/cloud images - there are
  ~10 of these that don't have bugs filed.
 
 Thats a pretty small number.
  
 kevin

Thanks,
Slavek
-- 
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: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Wed, Jan 28, 2015 at 11:09:08AM -0500, Bohuslav Kabrda wrote:
  Some general notes:
  If your package depends on Python because of a Python script that has
  /usr/bin/python in hashbang, you need to change this to /usr/bin/python3.
  All Requires and BuildRequires on Python extension modules have to be
  changed from python-foo to python3-foo in order for this change to
  work.
 
 Wouldn't it be better to simply say that Dependencies have to be adjusted
 so provide the necessary Python 3 modules. ? How to do it depends on the
 package,
 sometimes a slightly different set might be used, and simply changing all
 python-
 to python3- might not be enough.

As I noted, this bug is not supposed to be created for libraries (i.e. 
packages that have python- or python3- subpackages), but for applications 
(for example bind, that has some Python scripts in it, but no Python bindings 
or importable modules). (Either that answers your question, or I didn't 
understand the question in which case please try to rephrase it :))

  If your package is an application (let's call it foo) and it also
  generates a subpackage with Python bindings (i.e. python-foo or
  foo-python), you should provide a python3 subpackage (python3-foo or
  foo-python3) and use that as dependency of other subpackages.
 
 This part is unclear. What other subpackages and why should the
 depend on the python3 subpackge?

To explain it on an example: there's python-dnf and python3-dnf and dnf - all 
are subpackages generated from a single srpm. Right now, dnf requires 
python-dnf, but should be switched to require python3-dnf (and all other 
subpackages generated from dnf.srpm should be switched to require python3-dnf). 
Does that make it clearer? (I could add this example to the bug description)

Slavek

 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

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
   So, at today's FESCo meeting there was a good deal of discussion about
   python as default:
   http://meetbot.fedoraproject.org/fedora-meeting/2015-01-28/fesco.2015-01-28-18.02.log.html#l-41
   
   in which we agreed defer this to F23, file bugs against rawhide after
   branch (+6,0,0)
  
  I really don't get this. I was over the log and didn't find a compelling
  argument as to why this should be postponed. Can someone sum the arguments
  up, please?
 
 Let me try, based on my understanding of the conversation: whatever the
 technical changes / progress in migration are (and the actual migration can
 of course technically be staged over time), we can only have a public
 announcement (and PR) that “Python 3 is now the default” once.  We do have
 some flexibility in what that announcement means, but it should be enough so
 that we will never need to follow up with a “Python 3 is now really the
 default, trust us this time” Change/announcement.
 
 FESCo felt that not “enough” has been ported yet (in particular that the
 default install will not be ported by F22, and that Anaconda is unlikely to
 make it), hence postponing the Change / announcement aspct.
 Mirek

Thanks, that makes sense. Some questions:
- What if Anaconda does make it? :)
- What is enough? It's possible that two or three packages may be still 
unported even in F23 (and as for server livecd in F23, I think there will be 
few more).
- So is it ok if I file bugs for all components that I know are 
upstream-compatible with Python 3 (bugs to get them switched, I mean)?

Slavek
-- 
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: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
  - Original Message -
  On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač m...@redhat.com wrote:
   (Speaking only for myself, not for all of FESCo; hoping others will
   chime
   in.)
   - What if Anaconda does make it? :)
   I don’t know.
 
  I'm skeptical that will happen.  Even if it does, that alone is likely
  not enough to claim python3 by default.  You need all the basic
  functionality to work with pthon3, e.g. yum and dnf would also need to
  be ported.
 
  DNF works with Python 3, Yum will never work with it (this is why the
  change page says that this feature depends on DNF becoming the default
  package manager). I'm regularly talking to some of Anaconda devs (mostly
  Vrata Podzimek) and they still think this is doable *without* introducing
  high number of regressions, that would be impossible to fix before F22
  final.
 
 Good to know DNF is already fine in regards to python3.  I must have
 misunderstood the references to python3-dnf yesterday.  I was under
 the impression that it was something that existed, but wasn't widely
 used or tested at this point.  It certainly didn't seem to be the
 default dnf that everyone is using in F20/F21 (and rawhide today)
 installs.

Not sure about it being the default, but we've been testing it in DevAssistant 
for dependency installation on Python 3 and never encountered any problems. I 
was also contacted by dnf maintainer with a question on how to switch dnf to 
use python3-dnf (package-wise), so I guess that's what will be done for F22 
(but that's just my guess, dnf maintainer would have to comment here).

 Even still, that hinges on DNF being the default package manager in
 F22.  There are some concerns that it won't make it due to rel-eng
 tooling used to compose the images, etc.  If that's the case, yum will
 still be required.

Required, yes, but we'll still have tons of packages built with Python 2. I 
never said that porting rel-eng tooling is the goal for F22.

  What else is all basic functionality? If this is about making Workstation
  LiveCD python2-free, then I'm not sure we can make that even for F23
  (samba and glusterfs will be hard nuts to crack, although the work on
  samba has already started).
 
 That might be a good goal, but it wasn't what I was thinking.  I was
 thinking more along the lines of a more minimal install only requiring
 python3 to be installed.  I don't have a concrete package set in mind
 at the moment.

So if more minimal is minimal buildroot, then we can achieve that, since it 
only has python-libs because of gdb and gdb can be rebuilt with Python 3 
(upstream source is compatible). If that means minimal cloud image, then we can 
do it (we're waiting for the cloud-init folks to accept the py3 patches, which 
should happen any time now). If that means content from fedora-live-base.ks, 
then we can do pretty much everything, except of samba (I think) - and Petr 
Viktorin is doing some talking to people to get rid of samba from this config, 
because it seems to be unnecessary there.

   - What is enough? It's possible that two or three packages may be
   still
   unported even in F23 (and as for server livecd in F23, I think there
   will
   be
   few more).
   2-3 packages should not be an issue, perhaps unless they were very
   visible
   (e.g. having a public and widely-used Python plugin API).
  
   - So is it ok if I file bugs for all components that I know are
   upstream-compatible with Python 3 (bugs to get them switched, I mean)?
  
   If we are shipping both Python versions anyway, and the specific
   packages
   are known to be compatible (i.e. there little risk), I don’t see any
   reason not to switch them already in F22.
 
  I agree with everything Mirek said, as well as his take on the FESCo
  reasoning.
 
  We'd really like to see this happen, we don't want to slow down the
  work.  We just don't feel F22 is a release that is going to accurately
  reflect the python3 as default status.
 
  What I'm afraid is that by postponing this change, we will have achieved
  nothing else, than half more year of status quo.
 
 That's understandable, and to be honest a good concern.  At the same
 time, just declaring something as default when reality doesn't
 reflect that really won't achieve the actual goal either.  FESCo is
 hoping that opening the bugs against rawhide after F22 branching will
 help prod things along.  We'll be happy to revisit at that point and
 see if there are other efforts we can help with to make this happen in
 F23.

Considering all the information mentioned above and assuming Anaconda makes it, 
I'd say it should be perfectly possible to declare Python 3 the default. As for 
the packages that are not in the minimal installs, I can always open bugs for 
them before beta and only those maintainers who believe it to be safe can 
switch.

 josh
 --

Thanks,
Slavek
-- 
devel

Re: Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač m...@redhat.com wrote:
  (Speaking only for myself, not for all of FESCo; hoping others will chime
  in.)
  - What if Anaconda does make it? :)
  I don’t know.
 
 I'm skeptical that will happen.  Even if it does, that alone is likely
 not enough to claim python3 by default.  You need all the basic
 functionality to work with pthon3, e.g. yum and dnf would also need to
 be ported.

DNF works with Python 3, Yum will never work with it (this is why the change 
page says that this feature depends on DNF becoming the default package 
manager). I'm regularly talking to some of Anaconda devs (mostly Vrata 
Podzimek) and they still think this is doable *without* introducing high number 
of regressions, that would be impossible to fix before F22 final.
What else is all basic functionality? If this is about making Workstation 
LiveCD python2-free, then I'm not sure we can make that even for F23 (samba and 
glusterfs will be hard nuts to crack, although the work on samba has already 
started).

  - What is enough? It's possible that two or three packages may be still
  unported even in F23 (and as for server livecd in F23, I think there will
  be
  few more).
  2-3 packages should not be an issue, perhaps unless they were very visible
  (e.g. having a public and widely-used Python plugin API).
 
  - So is it ok if I file bugs for all components that I know are
  upstream-compatible with Python 3 (bugs to get them switched, I mean)?
 
  If we are shipping both Python versions anyway, and the specific packages
  are known to be compatible (i.e. there little risk), I don’t see any
  reason not to switch them already in F22.
 
 I agree with everything Mirek said, as well as his take on the FESCo
 reasoning.
 
 We'd really like to see this happen, we don't want to slow down the
 work.  We just don't feel F22 is a release that is going to accurately
 reflect the python3 as default status.

What I'm afraid is that by postponing this change, we will have achieved 
nothing else, than half more year of status quo.

 josh
 --

-- 
Regards,
Slavek Kabrda
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Filing Bugs for Python 3 Switch

[Bohuslav Kabrda]

Hi,
I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I realized that I 
should probably follow the mass bug filing policy.
As I've said previously, we've already had both Python 2 and Python 3 on 
LiveCDs for few releases, so it makes sense to move as much as possible to 
Python 3. My intention is to mass file bugs only for applications (see the 
second item in second list at [D]) - in short, these are packages for which it 
doesn't make sense to introduce python3- subpackage, but it only makes sense to 
rebuild them with Python 3.
The mass bug filing policy suggests providing text of the bug for review, so 
here it is:


Since your package requires Python and is considered an application as per [1], 
I'd like to ask you to rebuild it with Python 3. Please see recommendations and 
notes at [2]. Note: this switch should only be done assuming you need to do 
none or very little downstream patching of upstream source. If upstream source 
doesn't work with Python 3, it's ok to stay with Python 2.

Some general notes:
If your package depends on Python because of a Python script that has 
/usr/bin/python in hashbang, you need to change this to /usr/bin/python3. All 
Requires and BuildRequires on Python extension modules have to be changed 
from python-foo to python3-foo in order for this change to work. If your 
package is an application (let's call it foo) and it also generates a 
subpackage with Python bindings (i.e. python-foo or foo-python), you should 
provide a python3 subpackage (python3-foo or foo-python3) and use that as 
dependency of other subpackages.

[1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
[2] https://fedoraproject.org/wiki/Packaging:Python#Guidelines


If everyone agrees, I'll send a mail to devel-announce, saying that we're 
switching to Python 3 and all maintainers should rebuild with it, assuming that 
upstream sources are Python 3 compatible. After a week or so I'll file bugs for 
the remaining components. I haven't yet determined the number of affected 
packages, since I'm mostly interested in packages that are on LiveCD/cloud 
images - there are ~10 of these that don't have bugs filed.

I'll wait a while before sending the mail to devel-announce so that everyone 
has time to comment on this.

Thanks,
Slavek

[A] https://bugzilla.redhat.com/show_bug.cgi?id=1186791
[B] https://bugzilla.redhat.com/show_bug.cgi?id=1186792
[C] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
[D] https://fedoraproject.org/wiki/Changes/Python_3_as_Default#Scope
-- 
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: 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 Thu, Jan 22, 2015, at 12:00 PM, Bohuslav Kabrda wrote:
 
  How exactly is Fedora Atomic generated? It seems that
  fedpra-cloud-atomic.ks has no %packages section...
  I can find out how we're doing with Atomic assuming I know how it's
  constructed :)
 
 It uses rpm-ostree; the input manifest is here:
 https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/fedora-atomic-docker-host.json

Thanks. Based on that, this looks pretty much as good as fedora-cloud-base. The 
list of packages that aren't yet ported based on this manifest:

audit: audit-libs-python (being worked on)
authconfig: authconfig (I sent patch upstream yesterday)
cloud-init: cloud-init (thanks to OpenStack people, it seems that this will get 
moving very soon)
gettext: gettext (code compatible, just needs to be switched)
libxml2: libxml2-python (libxml2-python3 package is being worked on right now, 
upstream code is py3 ready)
nfs-utils: nfs-utils (code compatbile, just needs to be switched)
python (is going away)
python-backports (is going away)
python-backports-ssl_match_hostname (is going away)
sos (code compatible, just needs to be switched)


Slavek
-- 
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 as a Default - Status

[Bohuslav Kabrda]

- Original Message -
 On Tue, Jan 20, 2015, at 08:22 AM, Bohuslav Kabrda wrote:
  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:
 
 There was a sub-thread on this here:
 https://www.redhat.com/archives/anaconda-devel-list/2014-December/msg00030.html
 
 But basically because of Ansible, the only realistic outcome I can see from
 this proposal at least for Server and Cloud is Add Python 3 by default,
 not Switch to Python 3.

Yeah, as I've noted in the sum-up mail, it's clear that we won't be able to 
switch server (and possibly workstation) completely, although I'm quite sure we 
will be able to switch the minimal cloud image to python3 only (again, that's 
based on the assumption that the cloud images are generated from 
fedora-cloud-base.ks, I'm CCing Matthew to make this matter clear :)).

Slavek

-- 
Regards,
Slavek Kabrda
-- 
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 as a Default - Status

[Bohuslav Kabrda]

- Original Message -
 On Thu, Jan 22, 2015 at 11:31:12AM -0500, Bohuslav Kabrda wrote:
  Yeah, as I've noted in the sum-up mail, it's clear that we won't be
  able to switch server (and possibly workstation) completely, although
  I'm quite sure we will be able to switch the minimal cloud image to
  python3 only (again, that's based on the assumption that the cloud
  images are generated from fedora-cloud-base.ks, I'm CCing Matthew to
  make this matter clear :)).
 
 Yes. :) However, I think it would _also_ be valuable to have only
 python3 in Fedora Atomic, and that's currently a much larger surface.

How exactly is Fedora Atomic generated? It seems that fedpra-cloud-atomic.ks 
has no %packages section...
I can find out how we're doing with Atomic assuming I know how it's constructed 
:)

Slavek

 --
 Matthew Miller
 mat...@fedoraproject.org
 Fedora Project Leader

-- 
Regards,
Slavek Kabrda
-- 
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 as a Default - Status

[Bohuslav Kabrda]

- Original Message -
 On Tue, Jan 20, 2015 at 08:22:25AM -0500, Bohuslav Kabrda wrote:
  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
 
  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.
 
  [3] https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240
 
 I forwarded this request to Red Hat's openstack team to see if anyone
 there has contacts with the cloud-init maintainers. I've heard back
 that Ubuntu is in the same boat, also wanting a python3 compatible
 cloud-init in the near future. The author of the patch you mention
 is actually a cloud-init maintainer so could merge stuff himself,
 but he really needs others to review his patches before doing that.
 None the less, it sounds like there might be a bit of interest and
 movement upstream to try to get this porting work finished.

Thanks a lot, I really appreciate that you did that!

 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o- http://virt-manager.org :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Regards,
Slavek Kabrda
-- 
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 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

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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 

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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Bohuslav Kabrda]

- Original Message -

 On 19 January 2015 at 05:08, Bohuslav Kabrda  bkab...@redhat.com  wrote:

  - Original Message -
 
   Bohuslav Kabrda wrote:
 
Please note, that this proposal is absolutely not about imposing some
 
restrictions on who can/should maintain what. It's really just a
 
categorization of packages based on our WG's perception of importance
to
 
Fedora.
 
  
 
   Sure, but there is still a distinction in that proposal between first-
 
   class/Core (ring 1) and second-class/Extras (ring 2) packages. Even
   without
 
   the political/maintainership issues that the old Core/Extras split had,
 
   there were also some technical issues, which this proposal is
   reintroducing.
 
   Those stem from the requirement that ring 1 be self-hosting. It means
   that
 
   not only everything required to build ring 1 packages must be in ring 1,
   but
 
   also everything required to build optional subpackages of ring 1 package
 
   SRPMs! In practice, this means that either, e.g., large portions of
   TeXLive
 
   end up in ring 1, or we end up having to disable features, documentation
 
   etc. for several packages, or build them as separate SRPMs (which is
   always
 
   painful; we try to avoid that for a reason).
 

  I personally don't have a problem with putting large portions of TeXLive
  into
  ring 1. Again, I have to repeat that this is only a categorization of a
  state that currently exists with no intention of changing it (except
  perhaps
  suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron).
 

   For those not familiar with the issue from the Fedora Core past, just
   have
   a
 
   look at EPEL, where the split still exists. We end up with hacks like a
   kde-
 
   plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm
   package
 
   in RHEL (those that depend on VPN libraries not in RHEL and thus cannot
   be
 
   built in the RHEL package). Such an -extras package then typically needs
   to
 
   track the base package exactly, making updates painful (requiring
 
   coordination). (This would be much more of a problem in the fast-moving
 
   Fedora than in RHEL with its extremely conservative update policy.) We
   also
 
   end up with RHEL's KDE applications having many optional features simply
 
   disabled (at compile time), with no way to add them (other than replacing
 
   the entire packages with ones built with the optional features enabled
   from
 
   a third-party repository, in this case Rex Dieter's kde-redhat).
 
  
 
   IMHO, such a self-hosting ring 1 is a step backwards, even if the
 
   implementation keeps it open to all Fedora packagers.
 

  It's not. I don't see why we would need to do such hacks as are done in
  EPEL.
  The way I see it, if kde-plasma-nm builds several binary RPMs, then some of
  them are on LiveCDs, hence in ring 1, while others are not (= ring 2). And
  there's no problem with that. Or is there?
 

 The issues that come up are if ring0 and ring1 has a different update process
 than ring2. If an SRPM has both in them, then you may not be able to fix
 problems in ring2 because ring0, ring1 would supercede ring2. Thus you end
 up splitting out a lot of packages into sub-rpms to deal with what the
 developer sees as needless bureaucracy but the 'product manager' does not.

Yeah, I meant that either 
a) the process shouldn't be different, at least from maintainers point of view 
- in other words, maintainer would work as he now does, but the package would 
be tested (for example in Taskotron) and bugs would be reported 
or 
b) if at least one binary RPM produced by a SRPM would be in 0 or 1, then all 
others should be there as well (making ring 1 defined by SRPMs, not RPMs) 

Since b) has a potential of significantly expanding ring 1, I'd vote for a). 
But again, that's my perception of this all, I'll make sure to bring this topic 
up on next Env  Stacks meeting, so that others express their opinions as well. 

Slavek 

 --
 Stephen J Smoogen.
-- 
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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Bohuslav Kabrda]

- Original Message -
 Bohuslav Kabrda wrote:
  Please note, that this proposal is absolutely not about imposing some
  restrictions on who can/should maintain what. It's really just a
  categorization of packages based on our WG's perception of importance to
  Fedora.
 
 Sure, but there is still a distinction in that proposal between first-
 class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without
 the political/maintainership issues that the old Core/Extras split had,
 there were also some technical issues, which this proposal is reintroducing.
 Those stem from the requirement that ring 1 be self-hosting. It means that
 not only everything required to build ring 1 packages must be in ring 1, but
 also everything required to build optional subpackages of ring 1 package
 SRPMs! In practice, this means that either, e.g., large portions of TeXLive
 end up in ring 1, or we end up having to disable features, documentation
 etc. for several packages, or build them as separate SRPMs (which is always
 painful; we try to avoid that for a reason).

I personally don't have a problem with putting large portions of TeXLive into 
ring 1. Again, I have to repeat that this is only a categorization of a state 
that currently exists with no intention of changing it (except perhaps 
suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron).

 For those not familiar with the issue from the Fedora Core past, just have a
 look at EPEL, where the split still exists. We end up with hacks like a kde-
 plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package
 in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be
 built in the RHEL package). Such an -extras package then typically needs to
 track the base package exactly, making updates painful (requiring
 coordination). (This would be much more of a problem in the fast-moving
 Fedora than in RHEL with its extremely conservative update policy.) We also
 end up with RHEL's KDE applications having many optional features simply
 disabled (at compile time), with no way to add them (other than replacing
 the entire packages with ones built with the optional features enabled from
 a third-party repository, in this case Rex Dieter's kde-redhat).
 
 IMHO, such a self-hosting ring 1 is a step backwards, even if the
 implementation keeps it open to all Fedora packagers.

It's not. I don't see why we would need to do such hacks as are done in EPEL. 
The way I see it, if kde-plasma-nm builds several binary RPMs, then some of 
them are on LiveCDs, hence in ring 1, while others are not (= ring 2). And 
there's no problem with that. Or is there?

 (The ring 0 is likely subject to similar issues and I'm not convinced we
 need that, either, even though a self-hosting minimal system has been
 proposed for a long time.)
 
 Kevin Kofler

-- 
Regards,
Slavek Kabrda
-- 
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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Bohuslav Kabrda]

- Original Message -
 Honza Horak wrote:
  * Fedora Rings  (hhorak, 12:03:21)
 [snip]
 * IDEA: definition of ring 1 is a minimal set of packages that give
   you a functional system, with some sort of approval  (hhorak,
   13:31:21)
 * IDEA: ring 1 should be self-hosted -- because you want to build very
   solid important packages using very solid important packages
   (hhorak, 13:31:21)
 
 In other words, Fedora Core all over again? Been there, done that…
 
 Kevin Kofler

Not all of us were there. So what's the problem with that?

-- 
Regards,
Slavek Kabrda
-- 
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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Bohuslav Kabrda]

- Original Message -

 On 16 January 2015 at 01:31, Bohuslav Kabrda  bkab...@redhat.com  wrote:

  - Original Message -
 
   Honza Horak wrote:
 
* Fedora Rings (hhorak, 12:03:21)
 
   [snip]
 
* IDEA: definition of ring 1 is a minimal set of packages that give
 
you a functional system, with some sort of approval (hhorak,
 
13:31:21)
 
* IDEA: ring 1 should be self-hosted -- because you want to build very
 
solid important packages using very solid important packages
 
(hhorak, 13:31:21)
 
  
 
   In other words, Fedora Core all over again? Been there, done that…
 
  
 
   Kevin Kofler
 

  Not all of us were there. So what's the problem with that?
 

 Fedora Core was seen by many developers as You either work in the small team
 of Red Hatters and get stuff done or You are a volunteer or someone at Red
 Hat who isn't part of the cool group and don't get stuff done.

 If you were an Outsider and worked on a package that all of a sudden was
 core you found your version no longer was the one being worked on.

 Inside of the Core team it was a giant pressure cooker of We have to get
 this out the f'ing door now and don't have time to talk.

 So it took 3 releases (5 if you count RHL 8 and RHL 9) for Extras to be
 actually accepted as being something that could be done, and it took 3-4
 more releases before Core could be unwound and outside developers to be
 considered essential developers.

 Because this proposal is tone deaf to that history it can come across as
 insulting in various ways.

 --
 Stephen J Smoogen.

Ok, I think that there may be some misunderstanding happening here. The 
proposal as we discussed it was, that (as our WG sees it): 

* ring 0, ring 1 and ring 2 are the content built in Fedora's Koji == official 
Fedora repos 
* ring 0 is JeOS as defined by Matthew in the .Next proposal 
* ring 1 contains the packages that are critical in the sense that they are 
used to compose LiveCDs of our products/cloud images 
* ring 2 contains anything that anyone wants to build as an extension to 
rings 0 and 1 (and it's still in Koji as it is right now, e.g. bazillion of 
python/ruby/perl extension packages, applications that aren't on LiveCDs etc) 

We meant to categorize packages that are currently in Fedora (and we also 
wanted to extend the ring proposal to go beyond that with rings 3 and 4 - 
Copr/Playground and other stuff, but this was actually not discussed into 
detail yet). 
Please note, that this proposal is absolutely not about imposing some 
restrictions on who can/should maintain what. It's really just a categorization 
of packages based on our WG's perception of importance to Fedora. 
The only practical change that we suggested is that packages in rings 0 and 1 
should get some more QE/integration tests to better guarantee stability. These 
packages are defined implicitly by their presence on LiveCDs/cloud image, 
there's no intention of creating a cool group. 

I hope this explains the matter. If this still feels wrong, I'd like to 
continue this discussion, as it's not our intention to make someone feel 
excluded or unimportant. 

Slavek 
-- 
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] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -
 Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00:
  On 8 January 2015 at 17:01, Dan Callaghan dcall...@redhat.com wrote:
   Personally I am not looking forward to maintaining more branches
   and/or (sub-)packages for every python3X-*.
  
  I need to understand what you mean here? Even in EPIC and SCL's there would
  have to be some overlap and multiple branches over time due to the fact
  that python, ruby, java, etc all have multiple subpackages which would need
  to be built for multiple releases. They may not be for a long lenght of
  time, but the work is not going away.
 
 Right, even for Fedora there are multiple branches of course, what
 I meant was multiple *divergent* branches.
 
 For all my packages I prefer to keep a single spec for all branches with
 conditionals when necessary. Most of my packages are fairly stable and
 not releasing new incompatible versions too often, so most of the time
 I can just do one update and then all branches are a git fast-forward.
 The only time I have divergent branches is when a stable release needs
 a bug fix but rawhide has already moved to a newer incompatible version.
 That's fairly rare for my packages.
 
 So that approach works fine right now because we just have python-foo
 and python3-foo subpackages and they can just keep rolling through as
 new releases are branched and old releases die off.
 
 What I was picturing for EPEL Python 3 was that I would have to rename
 the subpackage to python34-foo. Then every time Python 3 is bumped
 I would have to rename all the subpackages to python35-foo, and then
 I would have divergent branches for as long as both 3.4 and 3.5 still
 exist. That's the situation I was complaining about.
 
 A much better approach is what Bohuslav has come up with, a single spec
 that builds both python3X and python3X+1 subpackages. And we can script
 the mass version bumping as well. So that addresses my worries.
 
 (The example spec makes me a bit sad with how complex and repetitive it
 is, but I guess there is nothing really we can do about that...)

I was experimenting with dynamic subpackage generation, but you need Lua for 
that. And while it can be done, it's actually much uglier than the way I 
proposed. I guess the only nice way would be to add support for dynamic 
subpackage generation to RPM directly. That is actually something I've wanted 
to propose for some time now, but didn't really get to it... Also, it's 
questionable that it'd get to RHEL 7 rpm, so I think we're stuck with this.

 --
 Dan Callaghan dcall...@redhat.com
 Software Engineer, Hosted  Shared Services
 Red Hat, Inc.

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

Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

  Thank you for circling back on this. I was going to try and contact you
  today
  about python26 which is orphaned in EPEL-5 and was going to see if we could
  use the same logic for making a python27 tree for EL5 and EL6?
 

 Yeah, theoretically we can do that, although I'm not very keen on the idea of
 maintaining yet another build of Python ;) certainly not for EPEL5...
 Note, that one important thing to decide here what the dist-git solution will
 be. The EPEL5 python26 solution basically created new repos for all
 packages, called python26-*. That's viable for python27, since there's no
 python28 coming, but it's not a good solution for python3X. That's why I'd
 probably rather apply the same approach that we'll take for python3X in
 EPEL7 (whichever that will be).
 Also, I'm starting to think about the technical solution (read: RPM macros)
 to multiple Pythons, since I really don't like the python26 solution from
 EPEL5. I'll put my solution in a proposal next week, so that everyone can
 comment on that, too.

 Thanks,
 Slavek

So here's a new part of the proposal that deals with specfiles/macros and how 
that all will work with imports from Fedora etc: 
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macros.2C_Packaging_Process
 
Something similar should be usable in EPEL 6 for python27, but I realized that 
situation is a bit different, since python27 is never going to be replaced by 
python28, so there's no need to consider two 2X stacks. I have to admit that I 
have very little interest (and time!) for python27 in EPEL 6, so I'll leave 
that proposal to someone else. 
As usual, all comments are appreciated! 

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

Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -

 On 9 January 2015 at 07:38, Bohuslav Kabrda  bkab...@redhat.com  wrote:

  Dave, thanks for the input.
 
  Yes, it's technically possible to put both dashes and dots in package name,
  although I'm sort of failing to see what the benefit of doing that would
  be.
  Is this for readability only? For me, python34-something is more readable
  than the two variants you propose (but I understand that it's a matter of
  personal preference and if majority likes one of your variants, we can use
  it).
 

 I can actually see a reason.. when you want python310 to replace python39
 using simple parsing rules. But that is just me comparing colours on the
 bikeshed. [It should point south.. or you'll get the wood rot.]

Guido van Rossum has, several times now, expressed his aversion to having 
3.10. It is most likely that there will be 3.9 and then 4.0, even if that 
doesn't present any huge change (like 2.6-3.0 did). 
[No, no, south is *obviously wrong*; moreover, it'll be metal, not wood...] 

  Regards,
 
  Slavek Kabrda
 

 --
 Stephen J Smoogen.

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

Re: Remove gcc, gcc-c++ and make from minimal build root

[Bohuslav Kabrda]

- Original Message -
 Dear Fedora developers,
 
 I'd like to collect some feedback about the $SUBJECT, i.e. making
 minimal build root really minimal, explicitly specifying build
 dependencies, etc.
 
 The topic originally spring out in this [1] discussion on packaging
 list. Interesting FPC discussion on this topic can be find in this
 ticket [2] and meeting minutes from last FPC meeting [3].
 
 Thanks
 

+1 from Python land. Most Python modules don't need gcc and always installing 
it needlessly wastes bandwith and makes buildroot preparation in {mock,koji} 
slower.

 
 Vít
 
 
 
 [1]
 https://lists.fedoraproject.org/pipermail/packaging/2014-December/010398.html
 [2] https://fedorahosted.org/fpc/ticket/490
 [3]
 https://lists.fedoraproject.org/pipermail/packaging/2015-January/010424.html

-- 
Regards,
Slavek Kabrda
-- 
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] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -
 Is the EPIC proposal totally dead? It seems like that would be a nicer
 and more general solution to this problem (not wanting to ship a Python
 3.x stack for 10 years).

I'm not sure about that, but I think we can align python3 in epel with EPIC 
even if EPIC is introduced later on.

 Personally I am not looking forward to maintaining more branches and/or
 (sub-)packages for every python3X-*.

The way I see it, we will only maintain a single python3X-* subpackage most of 
the time; then, when python3X+1 is released, we will maintain two subpackages 
for a short period of time, until python3X is retired.

 --
 Dan Callaghan dcall...@redhat.com
 Software Engineer, Hosted  Shared Services
 Red Hat, Inc.
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

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

Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

 On 7 January 2015 at 04:05, Bohuslav Kabrda  bkab...@redhat.com  wrote:

  - Original Message -
 
   Hi all,
 
   I know I've been promising this for quite some time to several people, so
   I
 
   finally managed to put together a proposal for packaging Python 3 in EPEL
   7
 
   (it'd also scale to EPEL 6 for that matter).
 
   I've created a wiki page [1] with the proposal and I'd like to hear
   comments
 
   and thoughts on it. There are some TODOs and variants in few places - I'd
 
   like to hear your opinions on these, or perhaps suggestions on better
 
   approaches.
 
   I'll create new documents with the updated proposal at some points during
   the
 
   discussion, so that people can easily see where the proposal is going
 
   without having to compare wiki revisions.
 
  
 
   Is there any other list/interested parties that should be put in CC of
   this
 
   mail? If so, please feel free to respond and do that yourself.
 
  
 
   Thanks!
 
  
 
   --
 
   Regards,
 
   Slavek Kabrda
 
  
 
   [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
 

  Let's reiterate:
 
  - Nick Coghlan posted an interesting proposal to the discussion section in
  my
  proposal (my reaction is in the blue frame) [1]. I'd appreciate more
  comments on this.
 
  - From the feedback gathered on this list:
 
  - We should have /usr/bin/python3 pointing to a python3X build. The
  question
  is which one this will be during transitional periods between 3X and 3X+1.
  My thinking is that we should point /usr/bin/python3 to 3X+1 at the time of
  retiring 3X (IMO there is no ideal time to do that, so it's not really
  important).
 
  - As for dist-git possibilities, Orion would prefer to use current dist-git
  repos with epel-7 branches. It's not my preference (for reasons mentioned
  in
  the proposal), but I'm not against it if that is what others wish.
 
  - Stephen Smoogen mentioned that the transitional period during which
  python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm
  starting to think that we should only specify the minimum time for which 3X
  will be kept. So my proposal would be sth. like 3X is kept for minimum of
  6
  weeks in parallel to 3X+1. After this, it is retired as soon as all
  stakeholders have rebuilt against 3X+1. (keeping it a bit vague is a good
  thing here, I think)
 
  - As I noted in one of my emails, we don't have to worry about conflicts
  with
  RHSCL. New collections from RHSCL will be named with rh- prefix and thus
  won't conflict with python3X stacks.
 

  Since it doesn't seem that there was anything very problematic, let's
  discuss
  the points mentioned above after which I should be able to finalize the
  proposal and make it official (and then we could all get to building :)).
 
  I'm quite sure that we'll still hit some technical issues, e.g. macro
  naming
  for parallel stacks, but I believe we can discuss and solve these on the
  way.
 

 Thank you for circling back on this. I was going to try and contact you today
 about python26 which is orphaned in EPEL-5 and was going to see if we could
 use the same logic for making a python27 tree for EL5 and EL6?

Yeah, theoretically we can do that, although I'm not very keen on the idea of 
maintaining yet another build of Python ;) certainly not for EPEL5... 
Note, that one important thing to decide here what the dist-git solution will 
be. The EPEL5 python26 solution basically created new repos for all packages, 
called python26-*. That's viable for python27, since there's no python28 
coming, but it's not a good solution for python3X. That's why I'd probably 
rather apply the same approach that we'll take for python3X in EPEL7 (whichever 
that will be). 
Also, I'm starting to think about the technical solution (read: RPM macros) to 
multiple Pythons, since I really don't like the python26 solution from EPEL5. 
I'll put my solution in a proposal next week, so that everyone can comment on 
that, too. 

Thanks, 
Slavek 

  Thanks.
 

  --
 
  Regards,
 
  Slavek Kabrda
 

  [1]
  https://fedoraproject.org/wiki/User_talk:Bkabrda/EPEL7_Python3#Sharing_Packages_between_Python_3_installations.3F
 
  ___
 
  epel-devel mailing list
 
  epel-devel@lists.fedoraproject.org
 
  https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

 --
 Stephen J Smoogen.

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

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

Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -
 On Wed, 2015-01-07 at 06:05 -0500, Bohuslav Kabrda wrote:
  - Original Message -
   Hi all,
   I know I've been promising this for quite some time to several people, so
   I
   finally managed to put together a proposal for packaging Python 3 in EPEL
   7
   (it'd also scale to EPEL 6 for that matter).
   I've created a wiki page [1] with the proposal and I'd like to hear
   comments
   and thoughts on it. There are some TODOs and variants in few places - I'd
   like to hear your opinions on these, or perhaps suggestions on better
   approaches.
   I'll create new documents with the updated proposal at some points during
   the
   discussion, so that people can easily see where the proposal is going
   without having to compare wiki revisions.
   
   Is there any other list/interested parties that should be put in CC of
   this
   mail? If so, please feel free to respond and do that yourself.
   
   Thanks!
   
   --
   Regards,
   Slavek Kabrda
   
   [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
  
  Let's reiterate:
  - Nick Coghlan posted an interesting proposal to the discussion section in
  my proposal (my reaction is in the blue frame) [1]. I'd appreciate more
  comments on this.
  - From the feedback gathered on this list:
- We should have /usr/bin/python3 pointing to a python3X build. The
question is which one this will be during transitional periods between
3X and 3X+1. My thinking is that we should point /usr/bin/python3 to
3X+1 at the time of retiring 3X (IMO there is no ideal time to do that,
so it's not really important).
- As for dist-git possibilities, Orion would prefer to use current
dist-git repos with epel-7 branches. It's not my preference (for reasons
mentioned in the proposal), but I'm not against it if that is what
others wish.
- Stephen Smoogen mentioned that the transitional period during which
python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months.
I'm starting to think that we should only specify the minimum time for
which 3X will be kept. So my proposal would be sth. like 3X is kept for
minimum of 6 weeks in parallel to 3X+1. After this, it is retired as
soon as all stakeholders have rebuilt against 3X+1. (keeping it a bit
vague is a good thing here, I think)
- As I noted in one of my emails, we don't have to worry about conflicts
with RHSCL. New collections from RHSCL will be named with rh- prefix
and thus won't conflict with python3X stacks.
  
  Since it doesn't seem that there was anything very problematic, let's
  discuss the points mentioned above after which I should be able to
  finalize the proposal and make it official (and then we could all get to
  building :)).
  I'm quite sure that we'll still hit some technical issues, e.g. macro
  naming for parallel stacks, but I believe we can discuss and solve these
  on the way.
 
 A bikeshedding idea that may be controversial: aren't periods valid
 characters within rpm package names?  If so, can't we have the package
 name be python3.X rather than python3X.  For that matter, dash
 characters are valid in the name, so can't we call it python-3.X?
 
 This might give e.g.
 
  python-3.4-numpy-1.5.0-1.el7
   ^ ^
  NV R
  
 Though, for the core runtime e.g.
   python-3.4-3.4.0-1.el7
 might seem harder to read than:
   python3.4-3.4.0-1.el7
 or:
   python34-3.4.0-1.el7
 
 Apologies for the bikeshedding
 Dave
 

Dave, thanks for the input.
Yes, it's technically possible to put both dashes and dots in package name, 
although I'm sort of failing to see what the benefit of doing that would be. Is 
this for readability only? For me, python34-something is more readable than the 
two variants you propose (but I understand that it's a matter of personal 
preference and if majority likes one of your variants, we can use it).

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

Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -
 Hi all,
 I know I've been promising this for quite some time to several people, so I
 finally managed to put together a proposal for packaging Python 3 in EPEL 7
 (it'd also scale to EPEL 6 for that matter).
 I've created a wiki page [1] with the proposal and I'd like to hear comments
 and thoughts on it. There are some TODOs and variants in few places - I'd
 like to hear your opinions on these, or perhaps suggestions on better
 approaches.
 I'll create new documents with the updated proposal at some points during the
 discussion, so that people can easily see where the proposal is going
 without having to compare wiki revisions.
 
 Is there any other list/interested parties that should be put in CC of this
 mail? If so, please feel free to respond and do that yourself.
 
 Thanks!
 
 --
 Regards,
 Slavek Kabrda
 
 [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

Let's reiterate:
- Nick Coghlan posted an interesting proposal to the discussion section in my 
proposal (my reaction is in the blue frame) [1]. I'd appreciate more comments 
on this.
- From the feedback gathered on this list:
  - We should have /usr/bin/python3 pointing to a python3X build. The question 
is which one this will be during transitional periods between 3X and 3X+1. My 
thinking is that we should point /usr/bin/python3 to 3X+1 at the time of 
retiring 3X (IMO there is no ideal time to do that, so it's not really 
important).
  - As for dist-git possibilities, Orion would prefer to use current dist-git 
repos with epel-7 branches. It's not my preference (for reasons mentioned in 
the proposal), but I'm not against it if that is what others wish.
  - Stephen Smoogen mentioned that the transitional period during which 
python3X and python3X+1 exist can be anywhere from 6 weeks to 2 months. I'm 
starting to think that we should only specify the minimum time for which 3X 
will be kept. So my proposal would be sth. like 3X is kept for minimum of 6 
weeks in parallel to 3X+1. After this, it is retired as soon as all 
stakeholders have rebuilt against 3X+1. (keeping it a bit vague is a good 
thing here, I think)
  - As I noted in one of my emails, we don't have to worry about conflicts with 
RHSCL. New collections from RHSCL will be named with rh- prefix and thus 
won't conflict with python3X stacks.

Since it doesn't seem that there was anything very problematic, let's discuss 
the points mentioned above after which I should be able to finalize the 
proposal and make it official (and then we could all get to building :)).
I'm quite sure that we'll still hit some technical issues, e.g. macro naming 
for parallel stacks, but I believe we can discuss and solve these on the way.

Thanks.

-- 
Regards,
Slavek Kabrda

[1] 
https://fedoraproject.org/wiki/User_talk:Bkabrda/EPEL7_Python3#Sharing_Packages_between_Python_3_installations.3F
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [RFC] Python_Eggs packaging guideline clarification draft

[Bohuslav Kabrda]

- Original Message -
 Changes
 ---
 
 1. Replaced the term 'eggs' with 'egg metadata' in the whole wiki, while
not messing up the URLs to this[1] on both occurances.
 
 2. In section '1.1 Why egg metadata', changed the phrase Allowing end
users to install eggs not made from rpms or install eggs into their
home directories. to Allowing end users to install egg packages not
made from rpms or install egg packages into their home directories.
 
 3. In section '1.2 When to Provide egg metadata' changed the phrase we
need to be sure to include the egg files to we need to be sure to
include the egg metadata
 
 4. Changed the section 1.3 tittle from  Upstream egg metadata to
Upstream egg package
 
 5. In section 1.3, change the phrase: Do not distribute egg metadata
from upstream to Do not distribute egg packages from upstream.

All the changes LGTM, thanks a lot for doing this!

 --
 /kashyap

-- 
Regards,
Slavek Kabrda
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Bohuslav Kabrda]

- Original Message -
 On 02/01/15 11:42, Richard Hughes wrote:
 
  Because as of now, gnome-software just doesn't fit the workstation bill
 
  I think you're misunderstanding what most developers do. We probably
  spend about 10 minutes installing development packages (on the command
  line) when setting up a new OS instance. I then spend a year or so of
  installing or removing the odd application, and a few minutes every
  week applying updates. I don't think GNOME Software is hugely useful
  for installing low-level developer packages, which is fine. It doesn't
  mean it's not a useful application.
 
 I don't know if most developers works with more or less just one
 toolchain and environment as you describe. At least some actually
 works in a lot of projects, with different development packages and
 sometimes also tools.
 
 That said, what about describing  the developer usecase as a project,
 focusing on a user using both GUI and CLI tools?
 
 - Get the sources (if they exist).
 - Install a toolchain, GUI-based or not.
 - Install dependencies: -devel packages, interpreted modules, etc.
 - Install project- or user-specific tools (GUI or not).
 - Keeping the installed sw updated.
 
 Installing the toolchain seems like DevAssistant to me. Besides this, I
 understand your position as if users are supposed to use yum/dnf except
 for GUI development tools and their dependencies (?)

Currently DevAssistant assistants (read: plugins) that we have in Fedora are 
more of kickstart a new project and install deps along rather than install a 
toolchain and perhaps do some other environment setup. This can however be 
easily extended by writing different plugins that will do just that.
E.g. I can imagine us having da prep fedora-dev c (which will BTW 
automatically gain a clickable counterpart in GUI) that will setup development 
environment for C (and similar for other languages). We can even provide some 
choices like --use-eclipse, --use-whatever-other-IDE, ... I'm willing to put my 
work into this, but I'm mostly a Python developer, so I'd need input from 
people working with languages.

Does that sound worth pursuing?

-- 
Regards,
Slavek Kabrda
-- 
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] Proposal for Python 3 packaging in EPEL 7

[Bohuslav Kabrda]

- Original Message -
 Yeah, now that it all comes back to me, naming conflicts with SCLs is
 probably
 the biggest issue.  The fact SCLs weren't given a prefix is a major issue for
 many possible EPEL packages.
 
 On 12/11/2014 09:46 AM, Carl George wrote:
  One thing to look out for would be SCL mod_wsgi.  In the SCL world they
  name
  it python33-mod_wsgi.  Most modules are %{SCL}-python-%{module}, but
  mod_wsgi
  is unique.  To avoid conflicts, the IUS project has committed to using the
  suffix u on our packages going forward (python34u-mod_wsgi).  Are you
  concerned at all about naming conflicts with SCL packages?
  
  I added the IUS coredev mailing list to the CC line.
  
  Carl George
  IUS Community Project

Good points, both.
The thing that I forgot to mention is that it was decided that new RHSCL 
collections will be prefixed with rh-, hence giving rh-python34 and 
similar. Therefore we don't have to be afraid of any naming conflicts - if and 
when Python 3.4 is packaged for RHSCL, it won't conflict with the proposed 
python34 EPEL stack (not now, not in future).

Slavek

  --
  *From:* epel-devel-boun...@lists.fedoraproject.org
  [epel-devel-boun...@lists.fedoraproject.org] on behalf of Stephen John
  Smoogen
  [smo...@gmail.com]
  *Sent:* Wednesday, December 10, 2014 02:24 PM
  *To:* EPEL Development List
  *Subject:* Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
  
  
  
  On 10 December 2014 at 03:48, Bohuslav Kabrda bkab...@redhat.com
  mailto:bkab...@redhat.com wrote:
  
  Hi all,
  I know I've been promising this for quite some time to several people,
  so
  I finally managed to put together a proposal for packaging Python 3 in
  EPEL 7 (it'd also scale to EPEL 6 for that matter).
  I've created a wiki page [1] with the proposal and I'd like to hear
  comments and thoughts on it. There are some TODOs and variants in few
  places - I'd like to hear your opinions on these, or perhaps
  suggestions
  on better approaches.
  I'll create new documents with the updated proposal at some points
  during
  the discussion, so that people can easily see where the proposal is
  going
  without having to compare wiki revisions.
  
  Is there any other list/interested parties that should be put in CC of
  this mail? If so, please feel free to respond and do that yourself.
  
  
  THis proposal looks good at first blush. I think the time for retirement of
  python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that
  isn't too long).
  
   
  
  Thanks!
  
  --
  Regards,
  Slavek Kabrda
  
  [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
  ___
  epel-devel mailing list
  epel-devel@lists.fedoraproject.org
  mailto:epel-devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/epel-devel
  
  
  
  
  --
  Stephen J Smoogen.
  
  
  
  ___
  epel-devel mailing list
  epel-devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/epel-devel
  
 
 
 --
 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
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

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

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: Maybe it is time to move tools to Python 3.x?

[Bohuslav Kabrda]

- Original Message -
 Hi,
 
 On 12/04/2014 02:30 AM, Matthew Miller wrote:
  On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
  When I worked at Canonical there was a goal to move both internal and
  public tools to Python 3.x version. IIRC started somewhere around 12.04
  and today when you look at Ubuntu Touch you will not find Python 2.7
  there. Similar with other tools.
  Can it be done? Maybe not in a month but who knows - f22 cycle?
  
  Take a look at
  http://fedoraproject.org/wiki/Changes/Python_3_as_Default for some
  work in progress.
  
 Since Marcin specifically mentioned tooling -- is there a separate place
 where we can document the coding issues involved? e.g. best practices
 (should we use python-six as a compatibility layer? etc.)

AFAIK there's not a Fedora specific place for best practises around py3 
porting. I myself consider these resources great:

https://docs.python.org/dev/howto/pyporting.html (upstream docs on porting 
Python code)
https://docs.python.org/3/howto/cporting.html (upstream docs on porting Python 
C extension)
http://python3porting.com/ (a great reference for both C and Python porting, 
including tons of examples)
http://www.wefearchange.org/2011/12/lessons-in-porting-to-python-3.html (a 
blogpost on how python-dbus was ported, lots of great gotchas there)
http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ (interesting 
notes on work with unicode)

https://wiki.gnome.org/PyGObject/IntrospectionPorting (porting from PyGTK to 
PyGObject Introspection)
http://overtag.dk/wordpress/2013/01/first-impressions-of-gtk3-migration-in-python/
 (same as above)

From the tools/libraries that can be used:
- https://docs.python.org/3.4/library/2to3.html (package python3-tools) is a 
tool that you run on your code in order to *move* it to Python 3 (e.g. doesn't 
guarantee backwards compat)
- http://python-modernize.readthedocs.org/en/latest/ (package python-modernize) 
- like 2to3, but tries to maintain backwards compat with Python 2.6+
- https://pythonhosted.org/six/ (package python{,3}-six) - importable library 
that helps write code compatible with both Python 2 and 3

And you can also have a look at my presentation from this year's Flock, it 
speaks about basic differences, porting and how people can help with porting:
https://bkabrda.fedorapeople.org/py3-as-default.pdf

Hope this helps!

 Best regards,
 
 --
 Michel Alexandre Salim
 Fedora Project Contributor: http://fedoraproject.org/
 
 Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
 IDs:keybase.io/michel-slm  | IRC: michel_...@irc.freenode.net
 
 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachments

-- 
Regards,
Slavek Kabrda
-- 
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: Maybe it is time to move tools to Python 3.x?

[Bohuslav Kabrda]

- Original Message -
 Hi,
 
 On 12/05/2014 03:08 PM, Bohuslav Kabrda wrote:
  - Original Message -
  Hi,
 
  On 12/04/2014 02:30 AM, Matthew Miller wrote:
  On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
  When I worked at Canonical there was a goal to move both internal and
  public tools to Python 3.x version. IIRC started somewhere around 12.04
  and today when you look at Ubuntu Touch you will not find Python 2.7
  there. Similar with other tools.
  Can it be done? Maybe not in a month but who knows - f22 cycle?
 
  Take a look at
  http://fedoraproject.org/wiki/Changes/Python_3_as_Default for some
  work in progress.
 
  Since Marcin specifically mentioned tooling -- is there a separate place
  where we can document the coding issues involved? e.g. best practices
  (should we use python-six as a compatibility layer? etc.)
  
  AFAIK there's not a Fedora specific place for best practises around py3
  porting. I myself consider these resources great:
  
  https://docs.python.org/dev/howto/pyporting.html (upstream docs on porting
  Python code)
  https://docs.python.org/3/howto/cporting.html (upstream docs on porting
  Python C extension)
  http://python3porting.com/ (a great reference for both C and Python
  porting, including tons of examples)
  http://www.wefearchange.org/2011/12/lessons-in-porting-to-python-3.html (a
  blogpost on how python-dbus was ported, lots of great gotchas there)
  http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ (interesting
  notes on work with unicode)
  
  https://wiki.gnome.org/PyGObject/IntrospectionPorting (porting from PyGTK
  to PyGObject Introspection)
  http://overtag.dk/wordpress/2013/01/first-impressions-of-gtk3-migration-in-python/
  (same as above)
  
  From the tools/libraries that can be used:
  - https://docs.python.org/3.4/library/2to3.html (package python3-tools) is
  a tool that you run on your code in order to *move* it to Python 3 (e.g.
  doesn't guarantee backwards compat)
  - http://python-modernize.readthedocs.org/en/latest/ (package
  python-modernize) - like 2to3, but tries to maintain backwards compat with
  Python 2.6+
  - https://pythonhosted.org/six/ (package python{,3}-six) - importable
  library that helps write code compatible with both Python 2 and 3
  
  And you can also have a look at my presentation from this year's Flock, it
  speaks about basic differences, porting and how people can help with
  porting:
  https://bkabrda.fedorapeople.org/py3-as-default.pdf
  
  Hope this helps!
  
 Thanks, it does. So it's up to each internal tool's maintainers to make
 them Python 3 compatible and then generate Python 3 subpackages (like
 python3-dnf), right?

Generally, yes, but there are two sides to this:
- assuming the package is a tool or application, it should just be switched 
to Python 3 (e.g. fedpkg - users don't care which Python runtime it runs on, 
it's just fedpkg)
- assuming the package is also used as a library (or *is* library), it should 
provide python3-foo subpackage

As for DNF, I think it should provide python3-dnf binding along with 
python-dnf, but dnf command should just switch to python3 without users even 
knowing about it.

 Best regards,
 
 --
 Michel Alexandre Salim
 Fedora Project Contributor: http://fedoraproject.org/
 
 Email:  sali...@fedoraproject.org  | GPG key ID: A36A937A
 IDs:keybase.io/michel-slm  | IRC: michel_...@irc.freenode.net
 
 ()  ascii ribbon campaign - against html e-mail
 /\  www.asciiribbon.org   - against proprietary attachments

-- 
Regards,
Slavek Kabrda
-- 
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: Maybe it is time to move tools to Python 3.x?

[Bohuslav Kabrda]

- Original Message -
 W dniu 03.12.2014 o 20:30, Matthew Miller pisze:
  On Wed, Dec 03, 2014 at 08:13:42PM +0100, Marcin Juszkiewicz wrote:
  When I worked at Canonical there was a goal to move both internal and
  public tools to Python 3.x version. IIRC started somewhere around 12.04
  and today when you look at Ubuntu Touch you will not find Python 2.7
  there. Similar with other tools.
  Can it be done? Maybe not in a month but who knows - f22 cycle?
  
  Take a look at
  http://fedoraproject.org/wiki/Changes/Python_3_as_Default for some
  work in progress.
 
 Thanks.

FWIW, just yesterday I started a discussion on packaging/python-devel lists 
about changes in guidelines connected to the Python 3 as Default change [1]. 
One of the proposed changes is that applications for F22 should be built with 
and use Python 3 as the Python. Feel free to join the discussion (I'll submit 
an FPC ticket once I feel that no more people want to comment on my proposal).
And yeah, this is a sort of heads-up for this list that such discussion is 
happening :)

-- 
Regards,
Slavek Kabrda

[1] 
https://lists.fedoraproject.org/pipermail/packaging/2014-December/010360.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: [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: Meeting minutes from Env-and-Stacks WG meeting (2014-12-03)

[Bohuslav Kabrda]

 Action Items
 
 * bkabrda will ask java guys to create a wiki page summarizing the
approaches we thought of and why we think it's not worth the effort +
post the link to WG ML once it's ready

Here it is: https://fedoraproject.org/wiki/User:Mizdebsk/FedoraMavenRepository

Slavek
-- 
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: 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: Idea: Ability to define dependencies between coprs (correctly)

[Bohuslav Kabrda]

- Original Message -
 Hi all,
 
 I have a proposal that would change how dependencies are defined in copr:
 
 Problem:
 Currently, copr allows to add a link to an arbitrary repo URL that is
 available for installing dependencies during building in copr. Using
 this dependent repo link we are able to build packages in coprA with
 dependencies in another coprB.
 
 However, when enabling only coprA and installing some packages from this
 copr, we can miss some packages from coprB, because those packages are
 not available since coprB is not enabled.
 
 Solution:
 We should be able to define dependency between coprs correctly. When
 creating coprA, we would add one or more depended coprs ('userB/coprB')
 instead of repo link. Then all packages from these coprs would be
 available during build, correct buildroots would be used (no need to
 specify variables $releasever and in addition, we would be able to
 provide correct (all) RPMs also when *installing* coprs.
 
 There are basically two ways how to implement this on the users' side:
 1) Simpler, preferred by Mirek, copr maintainer (CC'd):
 'copr' plugin in dnf would include -r option, which would basically
 installed all related coprs. That means when running `dnf copr enable -r
 userA/coprA`, user would end with two coprs enabled: userA/coprA and
 userB/coprB.
 
 2) More complicated, preferred by me :) :
 copr A repository from example above would not only include RPMs build
 as part of this copr, but would include also packages from copr B. That
 means that when running `dnf copr enable userA/coprA`, user would not
 need to install userB/coprB repository and would have all packages
 available.

3) (And I think that I've already heard this idea from someone) I think it'd be 
better to:
- Put the copr repofiles into RPMs and put all these RPMs in a single repo.
- These repofile RPMs can depend on each other.
- dnf copr enable installs an RPM from this repo.
- When a dependency between repos change, repofile RPMs will be updated. When 
user runs dnf update, he will get the new repofile RPM build, which will have 
dependencies changed properly - so dnf will install these, too. 

 Both ways struggle with refreshing data:
 * in 1) we might need to refresh coprs enabled (on the users' side)
 * in 2) we would need to re-create repodata in depended coprA if coprB

I think that 3) is ok from this POV. The problem here can be, that in 3), dnf 
would on update technically enable other copr repos without explicit user 
approval. I'm not sure whether this is a problem or not, though.

 gets changed (on the server's side).
 
 Let's discuss this a bit, I'm eager to hear your opinions.
 
 Cheers,
 Honza

-- 
Regards,
Slavek Kabrda
-- 
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: 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: request for pygrib packaging debug help

[Bohuslav Kabrda]

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

You have correctly wrapped the Requires: python3-pyproj line in with_python3, 
but you put it in the *main* package. You need to move it to the %package -n 
python3-%{name} section.

 Best regards,
 
 Jos de Kloe

-- 
Regards,
Bohuslav Slavek Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Python 3.4 merged into Rawhide

[Bohuslav Kabrda]

Hi all,
the f21-python side tag, containing Python 3.4, has been merged into Rawhide.
We managed to rebuild 216 packages out of 452 that BR: python3-devel and 7 that 
BR: python3 - these were the packages (or dependencies of packages) that failed 
to build in my local mockchain build for some reason (either problem in the 
upstream source code, problem in specfile or dependency cycle). There are still 
few packages that failed to rebuild and weren't fixed yet:
- dnf and hawkey (I was told by Ales that he'll handle this once Python 3.4 is 
merged to rawhide; we also had rhbz#1098109 blocking us, but that's been fixed 
today)
- iPython and few depending packages (this needed a rebase to work properly 
with Python 3.4 - the new version hit Rawhide just recently, a simple rebuild 
should do)
- python-django15
I'll keep working on these packages with their maintainers to get them building 
and working fine.
All the other packages built fine for me locally, so the mass rebuild should 
get the job done for these.

Big thanks to all who helped with the rebuild.

Regards,
Slavek
-- 
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.4 merged into Rawhide

[Bohuslav Kabrda]

- Original Message -
 
 On 27.05.2014 16:14, Bohuslav Kabrda wrote:
  Hi all,
  the f21-python side tag, containing Python 3.4, has been merged into
  Rawhide.
 I guess this is due to the merge:
 
 DEBUG util.py:282:  Error: Package: python3-sip-4.15.5-1.fc21.x86_64 (build)
 DEBUG util.py:282: Requires: python(abi) = 3.3
 DEBUG util.py:282: Installing: python-2.7.6-7.fc21.x86_64 (build)
 DEBUG util.py:282: python(abi) = 2.7
 DEBUG util.py:282: python(abi) = 2.7
 DEBUG util.py:282: Installing: python3-3.4.1-1.fc21.x86_64
 (build)
 DEBUG util.py:282: python(abi) = 3.4
 DEBUG util.py:282: python(abi) = 3.4
 
 Do I just need to wait a while longer for the package to appear in the koji
 buildroot?

I just pinged Dennis Gilmore about this and he fixed it, the rebuilt sip should 
now be tagged in rawhide (it'll probably take few minutes before repo is 
regenerated).

Slavek

 Thanks,
 Sandro
-- 
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.4 merged into Rawhide

[Bohuslav Kabrda]

- Original Message -
  All the other packages built fine for me locally, so the mass rebuild
  should get the job done for these.
 
 No, you cannot rely on the mass rebuild here. The reason is that the
 mass rebuild goes from a-z, in the alphabetical order and _not_ in the
 dependency order.
 
 Furthermore, even if the alphabetical order would normally work when you
 are doing manual rebuilds (you'd rebuild a; wait for it to appear in the
 buildroots; rebuild b; wait for it to appear in the buildroots; rebuild
 c ...), the mass rebuild doesn't include any newly-rebuilt packages in
 its buildroot, so you really cannot use it to rebuild any dependency chains.

I rebuilt all the packages that didn't rebuild in the alphabetical order, but 
it didn't occur to me that there are no repo rebuilds. Let's wait for mass 
rebuild to do as much work as possible and then just do the rest. (Anyone is 
free to rebuild as many packages as he wishes by hand before that, too :))

 This means that anything that directly or indirectly BuildRequires an
 unrebuilt python3 library is going to fail in the mass rebuild.
 
 Let me give an example.
 
 python3-pytz was one of the packages that didn't get rebuilt. In the
 rawhide tree, this is required by:
 python3-babel-0:1.3-3.fc21.noarch
 python3-celery-0:3.1.9-1.fc21.noarch
 python3-icalendar-0:3.6.2-2.fc21.noarch
 python3-matplotlib-0:1.3.1-4.fc21.x86_64
 python3-nikola-0:6.4.0-1.fc21.noarch
 python3-pandas-0:0.12.0-5.fc21.x86_64
 python3-taskw-0:0.8.1-2.fc21.noarch
 
 ... which are all libraries. If we try to install any of the packages
 from above (either locally or to install in koji for building other
 packages), they'd fail to install because python3-pytz cannot be
 installed. Same goes for any packages that depend on anything from the
 list above; they cannot be installed because they depend on an unrebuilt
 python3-pytz.
 
 In order to rebuild those, first we'd have to rebuild python3-pytz, then
 one of the libraries in the list above, until we reach to the top of the
 iceberg. And this has to be done in the dependency order; rawhide a-z
 mass rebuild does NOT help here.
 
 Or to put it another way, leaving deep dependency trees unrebuilt would
 undermine the the mass rebuild because a huge number of other packages
 that have (indirect) build dependencies on the unrebuilt packages are
 going to fail.

I understand that. As noted above, I'd just wait for the mass rebuild to do as 
much as possible and than do the rest.
(Just BTW I rebuilt pytz, which has python3-pytz subpackage, and it is tagged 
into rawhide already [1])

 --
 Hope this helps,
 Kalev

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=516929
-- 
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 and mod_wsgi

[Bohuslav Kabrda]

- Original Message -

 I naively ported my Django app to Python 3 and didn't realize WSGI was going
 to be an issue. I saw python3-django was available for Fedora 20 and thought
 I was all set until I saw in my httpd logs that python2.7 seems to be the
 assumed default for mod_wsgi. After reading the README and more, I see the
 writing on the wall:

 
 If you have multiple versions of Python installed and you are not using
 that which is the default, you may have to organise that the PATH inherited
 by the Apache application when run will result in Apache finding the
 alternate version. Alternatively, the WSGIPythonHome directive should
 be used to specify the exact location of the Python installation
 corresponding to the version of Python compiled against. If this is not
 done, the version of Python running within Apache may attempt to use the
 Python modules from the wrong version of Python.
 

 I take this to mean that merely fiddling with WSGIPythonHome alone will be
 insufficient and that I would need to recompile the package. Is that
 correct, or did I miss a Python3-specific mod_wsgi package or some other
 neater solution? If I am truly forced to recompile -- as reversing the
 Python 3 is really undesirable at this point -- is there any reason Fedora
 couldn't have two mod_wsgi packages (one for Python2 and another for
 Python3)?

AFAIK you can't have 2 mod_wsgi's, each one compiled against a different Python 
major.minor, loaded by Apache at the same time for various reasons. So the best 
solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), that 
would conflict with mod_wsgi. It should be perfectly doable and it shouldn't 
break anything. 
CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think? 

Regards, 
Slavek 

 --
 John Florian-- 
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: 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 packages versus pydoc -k

[Bohuslav Kabrda]

- Original Message -
 Sorry, I should have tried pdb first, because this one has nothing to do
 with rpm-python.  I can see modname='PyQt4.uic.pyuic', and prior to the
 exception site is a line 'loader = importer.find_module(modname)', which
 is where the None came from.  I can confirm this one in a clean mock
 root with just PyQt4 added (and its dependencies).
 
 This one might be a bug in the way pydoc -k iterates, because I can't
 even target that name directly:
 
 $ pydoc PyQt4.uic.pyuic
 no Python documentation found for 'PyQt4.uic.pyuic'
 
 $ python -c 'import PyQt4.uic.pyuic'
 Traceback (most recent call last):
   File string, line 1, in module
 ImportError: No module named pyuic
 

It seems that PyQt4/uic/pyuic.py is a symlink to /usr/bin/pyuic4, which is in 
PyQt4-devel. This means that the file is not importable when PyQt4-devel is not 
installed.
IMO this is both:
1) packaging problem, since the symlink shouldn't be there if the file it 
points to isn't installed.
2) pydoc problem, because it should try/except broken and unimportable files

I opened a rhbz#1076346 for 1)
And I'll try to figure out a good patch for upstream and send it there to fix 2)

Slavek.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes from today's Env-and-Stacks WG meeting (2014-02-18)

[Bohuslav Kabrda]

=
#fedora-meeting: Env and Stacks  (2014-02-18)
=


Meeting started by bkabrda at 13:02:21 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-18/env-and-stacks.2014-02-18-13.02.log.html
.



Meeting summary
---
* init process  (bkabrda, 13:03:08)

* additional repository - fedora-{incubator,ugly}  (bkabrda, 13:05:15)
  * AGREED: only one repo should be created at the start  (mmaslano,
13:37:55)
  * does malware automatic check exist?  (mmaslano, 13:52:20)
  * ACTION: bkabrda will talk to msuchy about his thoughts on providing
github-like frontend for copr (implement in copr itself vs. do it as
a standalone app) and post discussion result on our mailing list
(bkabrda, 14:30:18)
  * ACTION: all: discuss policies/procedures for accepting copr repo
into fedora-ugly on our ML  (bkabrda, 14:33:41)
  * ACTION: all: propose better names for fedora-ugly on our ML
(bkabrda, 14:35:14)

Meeting ended at 14:42:05 UTC.




Action Items

* bkabrda will talk to msuchy about his thoughts on providing
  github-like frontend for copr (implement in copr itself vs. do it as a
  standalone app) and post discussion result on our mailing list
* all: discuss policies/procedures for accepting copr repo into
  fedora-ugly on our ML
* all: propose better names for fedora-ugly on our ML




Action Items, by person
---
* bkabrda
  * bkabrda will talk to msuchy about his thoughts on providing
github-like frontend for copr (implement in copr itself vs. do it as
a standalone app) and post discussion result on our mailing list
* **UNASSIGNED**
  * all: discuss policies/procedures for accepting copr repo into
fedora-ugly on our ML
  * all: propose better names for fedora-ugly on our ML




People Present (lines said)
---
* juhp (112)
* mmaslano (71)
* tjanez (71)
* bkabrda (49)
* pingou (35)
* samkottler (27)
* hhorak (26)
* jreznik (25)
* zodbot (5)
* handsome_pirate (2)
* abadger1999 (0)
* pkovar (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
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: Packages installing files to /etc/rpm

[Bohuslav Kabrda]

- Original Message -
 bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur

Fixed in python3-3.3.2-9.fc21

 bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej

Fixed in python-2.7.6-2.fc21

-- 
Regards,
Bohuslav Slavek Kabrda.
-- 
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: Meeting minutes Env-and-Stacks WG meeting (2014-01-28)

[Bohuslav Kabrda]

  ACTION: bkabrda will write more about devassistant (mmaslano,
 16:44:20)

I tried to rewrite the DevAssistant part to be more high-level and to also 
include information on what we should do with DevAssistant. Hope it's enough.

Slavek.
-- 
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: Meeting minutes Env-and-Stacks WG meeting (2014-01-28)

[Bohuslav Kabrda]

- Original Message -
 On 4 February 2014 12:02, Bohuslav Kabrda bkab...@redhat.com wrote:
  I tried to rewrite the DevAssistant part to be more high-level and to also
  include information on what we should do with DevAssistant. Hope it's
  enough.
 
 Should DevAssistant and gnome software work together? I think there
 are a lot of overlapping use-cases.

It'd certainly be worth looking into. What particular use-cases do you have in 
mind?
 
 Richard

-- 
Regards,
Bohuslav Slavek Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes from today's Env-and-Stacks WG Meeting (2014-02-04)

[Bohuslav Kabrda]

#fedora-meeting: Env and Stacks (2014-02-04)



Meeting started by bkabrda at 13:03:24 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-04/env_and_stacks.2014-02-04-13.03.log.html
.



Meeting summary
---
* DevAssistant PRD section  (bkabrda, 13:07:16)
  * LINK:

https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document#DevAssistant
(juhp_, 13:09:25)
  * ACTION: DevAssistant section is overally ok, but tjanez and bkabrda
will work on rewording some parts.  (bkabrda, 13:29:43)

* Define Mission Statement of Env and Stacks WG  (bkabrda, 13:30:34)

* Define Vision Statement of Env and Stacks WG  (bkabrda, 13:32:37)
  * ACTION: tjanez to propose vision statement on mailing list for
discussion: Fedora is the preferred platform for software
development and deployment in any language or application stack.
(bkabrda, 13:44:24)
  * ACTION: All woting members of WG should vote on Jens's proposal for
irc channel on mailing list:

https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html
(bkabrda, 13:52:11)

Meeting ended at 13:55:49 UTC.




Action Items

* DevAssistant section is overally ok, but tjanez and bkabrda will work
  on rewording some parts.
* tjanez to propose vision statement on mailing list for discussion:
  Fedora is the preferred platform for software development and
  deployment in any language or application stack.
* All woting members of WG should vote on Jens's proposal for irc
  channel on mailing list:
  
https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html




Action Items, by person
---
* bkabrda
  * DevAssistant section is overally ok, but tjanez and bkabrda will
work on rewording some parts.
* tjanez
  * DevAssistant section is overally ok, but tjanez and bkabrda will
work on rewording some parts.
  * tjanez to propose vision statement on mailing list for discussion:
Fedora is the preferred platform for software development and
deployment in any language or application stack.
* **UNASSIGNED**
  * All woting members of WG should vote on Jens's proposal for irc
channel on mailing list:

https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html




People Present (lines said)
---
* bkabrda (51)
* tjanez (47)
* juhp_ (36)
* hhorak (6)
* zodbot (4)
* mmaslano (3)
* samkottler (1)
* abadger1999 (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
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.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

Meeting minutes - today's Env-and-Stacks WG meeting (2013-12-10)

[Bohuslav Kabrda]

#fedora-meeting: Env and Stacks (2013-12-10)



Meeting started by bkabrda at 13:02:36 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-12-10/env_and_stacks.2013-12-10-13.02.log.html
.



Meeting summary
---
* IDEA: pkovar will send analysis of what we should do with docs/wiki to
  ML before Jan 7.  (bkabrda, 13:23:42)
* ACTION: pkovar will send analysis of what we should do with docs/wiki
  to ML before Jan 7.  (bkabrda, 13:25:23)
* ACTION: hhorak will examine what tutorials/howtos regarding
  webstack/databases are available now and what should we add/improve
  (till jan 7)  (hhorak, 13:32:06)

Meeting ended at 13:40:27 UTC.




Action Items

* pkovar will send analysis of what we should do with docs/wiki to ML
  before Jan 7.
* hhorak will examine what tutorials/howtos regarding webstack/databases
  are available now and what should we add/improve (till jan 7)




Action Items, by person
---
* hhorak
  * hhorak will examine what tutorials/howtos regarding
webstack/databases are available now and what should we add/improve
(till jan 7)
* pkovar
  * pkovar will send analysis of what we should do with docs/wiki to ML
before Jan 7.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* pkovar (40)
* bkabrda (22)
* hhorak (12)
* zodbot (5)
* vpavlin (1)
* samkottler (0)
* abadger1999 (0)
-- 
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.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

Agenda for today's Env-and-Stacks WG meeting (2013-12-10)

[Bohuslav Kabrda]

WG meeting will be today at 13:00 UTC in #fedora-meeting on Freenode.

== Next Steps ==

- PRD - based on discussion on env-and-stacks mailing list
  (some discussion on pad: http://piratepad.net/PwUiH4MEPR)

== Open Floor ==
-- 
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-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

Python 3.4, ensurepip and wheels

[Bohuslav Kabrda]

Hi all,
so I started to work on packaging Python 3.4 beta 1 and I wanted to create 
ensurepip patch also acceptable for upstream - Toshio and Nick talked about 
that at [1]. I tried to analyze the situation and here is what I have. First 
some facts:
- with ensurepip, Python 3.4 bundles setuptools and pip wheel archives
- when ensurepip is run, it installs (or upgrades) currently installed pip from 
the bundled wheels

A way to solve this properly in a distro (as mentioned in [1]) would be:
- throw away bundled setuptools and pip wheels when building Python
- making python3 require python-pip
- patching ensurepip (this is the fun part):
-- if ensurepip is run in venv:
--- we will need to reconstruct the wheels and install them into venv; or just 
grab the RECORD files and use them as a list of files we need to copy into venv
--- to reconstruct the wheels from installed RPMs, it'd be a good idea to 
package python-{setuptools,pip} as wheels (with the .dist-info directory and 
all the wheel goodies inside) so that we have the RECORD files
--- to package setuptools and pip as wheels, they'll have to BR: python3-pip (I 
saw Toshio's notes from flock and I agree with the part about how Fedora should 
use wheels [2])
-- if ensurepip is run systemwide:
--- if --upgrade is used, should this run yum update python3-pip?

Now, when new X.Y version Python is introduced, we will have to:
- bootstrap the new python3 interpreter to not require python3-pip, since 
python3-pip will require python(abi)=X.(Y-1)
- then we will need to build setuptools and pip *not as wheels*, because we 
still won't have pip that would work with our new Python X.Y - that means 
boostrapping them too and building them using the current setup.py install 
approach
- when we will have the new pip, we will be able to reenable python3 requires 
for python3-pip
- and we will also be able to rebuild setuptools and pip *as wheels*

There are also some more minor issues, that are worth mentioning:
- We typically won't update pip after Fedora is released - if there are 
security issues, we will backport patches and bump the release. The problem 
with this is that ensurepip --upgrade is not able to see Fedora releases and 
wouldn't work in venv, leaving it vulnerable. I think we have three options 
here:
-- Either we use some Fedora-specific RPM magic, which won't be acceptable for 
upstream
-- Or we will use a nice feature of wheel RECORD files - they keep file hashes, 
so we can check venv pip against system pip and see if something has changed 
when ensurepip --upgrade is run
-- Or we can just copy whole pip again into venv, regardless of what is 
currently there (doesn't seem very nice..., but it's simple and in the end it 
works as the above method)
- We can't copy the *.pyc and *.pyo files from system to venv, because they 
have file locations hardcoded in them, that are used in tracebacks. We can 
solve this by just copying *.py files and running py_compile in our ensurepip.

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?

Thanks a lot,
Slavek.

[1] 
https://lists.fedoraproject.org/pipermail/python-devel/2013-November/000535.html
[2] 
https://fedoraproject.org/wiki/User:Toshio/Flock2013_Python_Guidelines#Wheel:_the_new_upstream_distribution_format
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-19)

[Bohuslav Kabrda]

 * PRD  (mmaslano, 16:19:29)
* LINK: http://piratepad.net/PwUiH4MEPR   (abadger1999, 17:04:53)
* ACTION: everyone to send one general thing they want the WG to
  enable and one specific thing they'd personally want to work on to
  the mailing list this week  (abadger1999, 17:37:44)

As I've stated previously, I would like to work on few areas:
- Python stack - making Fedora the most appealing distro for Python developers, 
enabling builds of extension packages against alternative interpreters like 
PyPy or Jython
- SCLs - getting SCLs into Fedora (in a pragmatical and usable way)
- Setting up development environments - DevAssistant [1]
- Better tools for packagers/packaging automation - pyp2rpm (I haven't visited 
that for some time, will have to give it some time...), spec2scl, ...

So to get back to your question:
- I'd like the WG to think about how we could support building extension 
packages for multiple interpreters of dynamic languages - e.g. 
Python+PyPy+Jython, Ruby+JRuby+Rubinius (this will probably need to be 
coordinated with FPC).
- Personally, I invest lots of my time in work on DevAssistant, which IMHO is a 
relevant tool for this WG (it's about setting up development environments, 
scaffolding source code etc.) and I'd like to continue working on that.

Slavek.

[1] https://github.com/bkabrda/devassistant
-- 
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: Summary/Minutes from today's FESCo Meeting (2013-10-23)

[Bohuslav Kabrda]

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 10/24/2013 02:45 AM, Bohuslav Kabrda wrote:
  * ticket #1182 F21/F22 System Wide Change: Python 3 as the
  Default Implementation -
  https://fedoraproject.org/wiki/Changes/Python_3_as_Default
  (nirik, 18:10:29) * AGREED: Feature is approved, provided that
  the contingency plan is updated with permitting a mixed
  environment of py2/py3 (+6,-1,0) (nirik, 18:30:22)
  
  This is not very clear to me. Does that mean that we shouldn't use
  side tag at all, but rather just switch as many system tools as
  possible to Python 3 (in F22 rawhide) and leave the rest running
  on Python 2? Just making sure before I update the Change page.
  
 
 Yes, we determined that a reasonable contingency plan is to move
 forward with the parts that did get converted properly and finish up
 the work in the next release.
 

Thanks for the clarification, I'll update the Change page.

 The major caveat was that we would like to request that you focus
 efforts heavily on getting all the pieces that are required for the
 stripped-down cloud image in first, since they're the ones with the
 most to lose if we get stuck carrying two stacks at once.

Ok, I'll try to send some patches in this direction.

Thanks,
Slavek.
-- 
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: Summary/Minutes from today's FESCo Meeting (2013-10-23)

[Bohuslav Kabrda]

 * ticket #1182 F21/F22 System Wide Change: Python 3 as the Default
   Implementation -
   https://fedoraproject.org/wiki/Changes/Python_3_as_Default  (nirik,
   18:10:29)
   * AGREED: Feature is approved, provided that the contingency plan is
 updated with permitting a mixed environment of py2/py3 (+6,-1,0)
 (nirik, 18:30:22)

This is not very clear to me. Does that mean that we shouldn't use side tag at 
all, but rather just switch as many system tools as possible to Python 3 (in 
F22 rawhide) and leave the rest running on Python 2? Just making sure before I 
update the Change page.

Thanks.

-- 
Regards,
Bohuslav Slavek Kabrda.
-- 
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: F21/F22 System Wide Change: Python 3 as the Default Implementation

[Bohuslav Kabrda]

- Original Message -
 On Mon, Oct 14, 2013 at 11:05:52PM -0500, Dennis Gilmore wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  El Mon, 14 Oct 2013 02:19:15 -0400 (EDT)
  Bohuslav Kabrda bkab...@redhat.com escribió:
   - Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El Thu, 10 Oct 2013 05:35:18 -0400 (EDT)
Bohuslav Kabrda bkab...@redhat.com escribió:
 - Original Message -
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On Wed, 09 Oct 2013 14:07:12 +0200
  Jaroslav Reznik jrez...@redhat.com wrote:
  
   ** Request Koji side tag and encourage packagers to rebuilt
   their packages with Python 3 there
  python is not in the minimal build root python-libs is pulled
  in by deps.
  
  So all the koji parts of the change proposal are irrelevant
  
 
 Sorry, I don't see how they're irrelevant. I want the Koji tag so
 that we can push F22 out with Python 2 in case the switch to
 Python 3 isn't ready in time - so it's more of a safety mechanism
 than anything else.

you would still need to go undo everything in git and rebuild to
make sure that the newest builds got out. the builds separate in
koji is the least of the worries. side tags cause many issues,
since python is not part of the minimal buildroot and since undoing
it all would be a massive amount of work. its not going to be
easily undone. there is no reason today that you can build
everything with python3 along with python2. I do not see what it
would give and i see many problems with a side tag especially if it
is long lived.

Dennis

   
   Maintainer can create private branches in dist-git and not touch
   master, can't you? I guess it should be up to every maintainer
   whether he wants to revert dist-git changes in case of no success or
   he wants to merge to master in case of success. Could you be more
   specific about the many problems that side tags cause? I'm not Koji
   expert, so I don't see them. Thanks.
   
  you can, but you are not allowed to do offical builds from private
  branches. you get many issues when you build foo-1.1-3 in the side tag,
  then the maintainer goes and builds foo-2.0-1 in the main tag, when we
  merge thinsg back in you end up with all sorts of broken dependencies
  because you get a mixture of things build against different libraries.
  you then need to clean up by rebuilding a bunch of things again to
  clean up dependency issues.
  
  I am not saying we shouldn't change here, just saying that if we are
  going to do it it is one of those things we should just do and deal
  with the fallout. I for one actually have no plans to port any of my
  code to python3, and many of the things that I look after need to work
  on RHEL 5 up.  some things will just take longer to get done because
  the lowest common denominator doesn't have the new shiny.
  
 
 At today's fesco meeting we decided to defer a vote on this until next week.
 Generally, fesco seemed positively inclined towards the feature but had some
 concerns that needed to be addressed:
 
 * The Change plan should be updated to take into account Dennis's Feedback
   * I suggeested that perhaps a better contingency plan would be to simply
 ship with some applications using python2 and others using python3.
 

Personally I don't have problem with this, but:
- Side tag is a good contingency plan. If we have to revert for whatever 
reason, then without sidetag we will have to rebuild everything with Python 2 
again.
- I recall that someone (I believe it was matthew) pointed out that shipping 
both Python's would significantly grow cloud images (significantly from cloud 
POV, I guess). I can't find the email right now, though.

 * Need to clarify if the DNF bindings will exist for both python2 and
   python3 or just python3.  This could affect releng, mock maintainer, etc.

I'll discuss with Ales.

 
 -Toshio

-- 
Regards,
Bohuslav Slavek Kabrda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct