Re: F29 System Wide Change: Move /usr/bin/python into a separate package

[Petr Viktorin]

On 05/24/18 02:21, Orcan Ogetbil wrote:

On 23 May 2018 at 11:30, Brian C. Lane wrote:

as a user of python what do you expect
/usr/bin/pythong to do? You expect it to run the python2 interpreter.


Careful with the generalization. I expect /usr/bin/python to launch
python3 and I get surprised with each Fedora release why it still
keeps launching python2 after all these years.


Fedora follows [PEP 394], which is a result of much discussion across 
many distros and use cases.


[PEP 394]: https://www.python.org/dev/peps/pep-0394/

I don't blame you for expecting python3 instead, though :)


This change seems to be a move in the right direction (although I
would have preferred a more radical approach, like removing python2
from the distro altogether. It can be reintroduced in a later release
as a compat-python2 package)


I would also prefer what a more radical approach, and I did suggest it 
upstream. what ended up in the current PEP is a compromise.

The discussion/history is at https://github.com/python/peps/pull/630.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZOT7FZGKKM6U3LBQBV3I46UTBY6NMMDJ/

Re: Are 3.6.x release candidates useful to find bugs?

[Petr Viktorin]

On 05/21/18 14:43, Nick Coghlan wrote:
On 21 May 2018 at 22:09, Charalampos Stratakis > wrote:


 > So, please, if you find any bugs in upcoming Python *3.6.x* release
 > candidates, let me know (or write to Łukasz directly)! If there
are no
 > such reports, there will be no 3.7.x RCs.

So I see two potential outcomes here. Either we change our
procedures on updating the point releases and we test the RC ones as
well, or we can just say to upstream that from
Fedora's POV we don't really bother with the rc point releases. I'm
more inclined towards the second option, as the first one is highly
dependent on the workload/free cycles
at that particular time frame, and combined with the short window
between an RC and the actual release, it could strain a lot of
resources for not much of a benefit.


Note also that part of Łukasz's proposal was that if a significant 
regression *was* found in a point release, then the resolution would be 
to spin a new point release with a fix ASAP. It's just that in such 
cases, the version numbers involved would be X.Y.Z and X.Y.Z+1 rather 
than X.Y.Zrc1 and X.Y.Z.


Indeed.
Even if we should do more testing in Fedora than we do now (which of 
course we should!), the RCs aren't really needed -- if the tests fail, 
we'll fix the bug upstream, get the fix as part of X.Y.Z+1 (which under 
Łukasz's rule should be released ASAP), and use that.


(Again, prereleases for *feature* releases, such as the current 3.7.0b4, 
are very useful and should be kept.)



If there is no more discussion on this topic in the next few days, I'll 
summarize it to Łukasz.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/UNEW7ZTTR3MCKQCLSV64VJPHBEO3D4LB/

Are 3.6.x release candidates useful to find bugs?

[Petr Viktorin]

Hello!

At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told 
me that he'd like to collect data about Release Candidates for point 
releases (3.x.y). The idea is that if these aren't being tested and 
aren't revealing bugs, it would make sense to stop releasing them.


So, please, if you find any bugs in upcoming Python *3.6.x* release 
candidates, let me know (or write to Łukasz directly)! If there are no 
such reports, there will be no 3.7.x RCs.


Also, are these useful for Fedora? Do/should we test 3.x.y RCs?
(3.x.0 pre-releases like the current 3.7.0 beta are a different matter; 
those are obviously useful.)

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/HY4DS7PFF525JGKOE2CUXRUE4D3I22FA/

Re: PEP 394 update proposal: Allow changing the `python` command in,some cases

[Petr Viktorin]

On 04/26/18 09:17, Nick Coghlan wrote:

On 26 April 2018 at 05:22, Petr Viktorin <pvikt...@redhat.com> wrote:

If this goes through, in Fedora I would like to:

- Create a "python" package containing *just* the /usr/bin/python symlink.
This would be a subpackage of python2, and python2 would *suggest* it. In
other words, it would be installed by default with Python 2, but mock, koji,
and test tools would omit it (unless something deliberately Requires
`python` or `/usr/bin/python`).

- Put an unofficial "python 3.6" on COPR (and maybe eventually in a Module),
which would be the recommended way to make `python` invoke Python 3.


Cool, thanks for moving this forward!

Did you want to update
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
accordingly, or should that entire site just be scrubbed as an
experimental idea that didn't work out in practice?


The current discussions and documentation is scattered between there, 
the mailing list, Fedora Changes, the Wiki (for things that aren't 
Changes only because they affect multiple releases), the Fedora 
Developer Portal, etherpads and PEPs. It's all confusing, I'm afraid.


But no, I don't think the Sphinx site is working very well for design 
and development notes. Etherpads are easier to edit, the mailing list 
and Fedora changes/guidelines are good for rough and final drafts, and 
the Developer portal is for documentation – it's worse technically, but 
better in that it's not a Python-specific silo.
Pull request driven collaboration is great (after an initial draft 
phase), but when the results then need to be copied to mediawiki or 
markdown, it doesn't make much sense to bother with ReST :(

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

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/08/18 17:49, Kevin Kofler wrote:

Rex Dieter wrote:

And we've circled back to the original post starting this thread.

Note: intent to *orphan*, not intent to *retire*.


If it is not going to be retired, then why would we want to kill python2-*
subpackages throughout the distribution for no reason?


By orphaning, I mean:

1. Work with users and maintainers of dependent packages to either 
remove their dependencies or to share/take over maintainership

2. Drop the package if no one stepped up

This is the first step.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/04/18 18:21, James Hogarth wrote:
[...]

Can we please get some consistency here?

I noted today that firewalld has dropped python2-firewall but of course 
ansible isn't switching to py3 for the controller (and therefore local) 
until F29 and not all python modules are py3 compatible yet... and of 
course we ship firewalld as our firewall in fedora.


This means that in F28 you can't just `yum  install ansible 
python-firewall` and do ansible localhost -m firewalld and have it work.


Worse is if you bump into a module not ported yet and then you have a 
split of python versions and playbooks required.


Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about the 
implications of dropping subpackages. Currently we use RPM deps, so the 
needs of Ansible clients are invisible.


Naturally there's no technical reason to drop the library in F28 and 
there's no Change filed for it.


It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible depends 
on the package? Again, a maintainer can't very well notice a "soft 
dependency", unless they use Ansible themselves.


We at least need a "common bugs" with all the python2-* libraries being 
dropped in F28 and really they shouldn't be going without a Change.

> For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to 
that effect).


To be clear I'm 100% comfortable with python2 being dropped in the 
proposed timescale... but let's do it sensibly and not have it surprise 
people.

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

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/24/18 15:28, Kevin Kofler wrote:

Petr Viktorin wrote:

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or


IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4.
It is not an unreasonable amount of work, though to be very clear I will NOT
be the one to do this for Python 2, somebody experienced with and interested
in Python should do it.


And if you read the original mail to the end, you'll find that our 
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – 
but just for developers who need to test backwards compatibility of 
their upstream libraries; we don't want to see them used as a base for 
Fedora packages. Why? To make sure Fedora packages work with modern 
Python, and to have only one time-sensitive place to concentrate on when 
a critical security fix comes. We want to put Python 2.7 in the same 
situation.


Part of the reason to start dropping Python 2 packages now is to figure 
out which packages can do it now and which ones will need additional 
help or coordination in the next few years.


As I wrote in the beginning of the e-mail, we'd rather go out and change 
the packaging guidelines to say "please drop your unneeded python2 
subpackages, or let us drop them for you". (Note the word *unneeded*.) 
That would make a nice a simple message, and in effect it would give you 
the same options you have now.
But it turns out we can't say just that (for good reasons [0]), so we're 
explicitly mentioning your second option – "if you can manage the 
transition better, come and do it instead of us".
I doubt anyone can – Python SIG is, by definition, the people 
experienced with and interested in packaging Python in Fedora. And yes, 
we'll do our best to manage things, with cooperation with interested 
packagers.


There's of course a third option – if you don't want to take over 
*everything* but have ideas about how to do something better – 
respecting that if you're asking someone to do more work, they might (or 
might not) say no – then come over to Python SIG [1] and talk!


And let me mention this one explicitly: expecting us to maintain Python 
2 *is* implicitly asking us to do work. It's not necessarily bad per se, 
but don't complain if we ask you to do some work in return.

We'll be glad to help anyone who respects that.


[0] https://pagure.io/packaging-committee/issue/753
[1] https://fedoraproject.org/wiki/SIGs/Python



Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported until
2024. (That said, RHEL typically only fixes the really critical issues. My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my Fedora
fix, weeks later. But there are also other distros around.)

 Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/23/18 17:57, Randy Barlow wrote:

On 03/23/2018 07:23 AM, Petr Viktorin wrote:

In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at
[1].)


I'm +1 to the idea of dropping Python 2 support in general, but I'm not
sure we should really do it gradually (which is what would effectively
happen if some packagers start dropping now and others later, and others
not at all). It seems to me like it'd be cleaner to have a release note
on Fedora 30 that's just "Python 2 support dropped" and do it all at
once. Thoughts?


I'm afraid we won't be able to handle the massive breakage in random 
build scripts, infrastructure, and (especially) areas we don't yet know 
will break. The likely outcome of such a flag day would be that the 
change would need to be reverted immediately. (You're welcome to try 
this locally. The problems start with the buildroot broken in ways I 
didn't know could exist, and continue from there.)
Even if the base distro would end up usable, we wouldn't be able to help 
all the non-"essential" packages if all problems appear at once.


Instead we want to start with the things we *know* can be dropped, and 
work on getting more things into that state. That should bring a steady 
stream of problems, which can be tackled one by one.

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

Intent to orphan Python 2

[Petr Viktorin]

tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.



Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded 
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2 
alive, we won't be the ones doing it – at least not at the current 
magnitude".

Here are the details.


The current maintainers of python2 would like to "orphan" the python2 
package in 2020 (~ Fedora 30):

- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is 
a security-critical package and will be abandoned upstream), or

- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent 
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support 
from dependent packages *now*, starting with ported libraries on whose 
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested 
packagers, as long as there's an understanding that we won't just 
support python2 forever.


If you are a maintainer of anything at [1] we ask you kindly to consider 
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora > 
29. (On the current schedule, Fedora 30 will be the first release still 
supported after 2020-01-01.)


If no one steps up to maintain python2 after 2020, we're prepared to 
package a "legacy" python27 package, similar to what we do for e.g. 
python33 [2], to:

- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if 
their upstreams don't manage to port to Python 3 in time




[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/20/18 21:47, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 04:11:46PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 03:28:23PM +0100, Miro Hrončok wrote:

On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote:

Indeed, I'm using those python packages like a dinosaur ;)


:D


What about adding conditionals like

%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif

starting now?


I am not against that. However currently that number (31) is
somewhat artificial. it's up to the maintainer to choose if it's 28
or 32 (or anything in between). Should we somehow recommend a
specific Fedora release here? Why 31?

Re 31: my thinking was that python2-eos is at 2010-01-01. If we keep
up current biannual release schedule, we'll have 28 and 29 this year,
30 and 31 in 2019, and 32 in early 2020. But this is of course wrong,
because we need python2 support for the lifetime of the release, not
just at the start. So actually 29 which will be supported until
2018-10-30 + 13 months ≈ 2020-01-01, is the last release overlapped
by python2 support. This right conditional would be:

%if 0%{?rhel} > 7 || 0%{?fedora} > 28

but that round around the corner. So it's not even necessary to add
the conditional, as long as the patch to drop support is only added
in rawhide, not F28.

OK, so I withdraw my objections. Removing python2 support in rawhide
is fine.


Pff, sorry I can't count. The right conditional would be
   %if 0%{?rhel} > 7 || 0%{?fedora} > 29
so dropping support in rawhide right now would be premature. It seems
that adding a conditional like that is the way to go for now.



Compared to just removing the subpackage, it's a difference of just one 
release. It may not be worth the complication of conditionalizing 
everything.


I'd say maintainers can either drop the subpackages now in Rawhide, or 
add a conditional for Fedora > 29 -- up to the maintainer.

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

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/20/18 14:45, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 12:23:06PM +0100, Miro Hrončok wrote:

On 20.3.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote:

to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.


I think there is a fundamental difference of how I see python RPMs
in Fedora and how you do. In my POV, purpose of pythonX-foo packages
that only bring libraries is to provide dependency for an
application that happens to be written in python, runs on pythonX
and need the foo library. If there is no such application packaged
in Fedora, I see no purpose of such package. (Except maybe if such
app is packaged in another repository used by our users. That's a
corner case and if the maintainer of pythonX-foo is aware of that,
it can always be used as argument to keep pythonX-foo.)


Indeed, I'm using those python packages like a dinosaur ;)
But more seriously, I think the distinction between library and app in
the python world is neither clear nor particularly significant. Distro
packaging provides clear benefits in both cases: easy and quick
install, easy and quick uninstall, testing, provenance history,
license checks, general reliability.

So instead of losing packages, I'd like to see more automatic
packaging and updates of packages from pypi and other "forges".
We are making steps in that direction, but not quickly enough.


We live in an era of pip (and rubygems, and cpan, and npm etc.).
Trying to mirror those systems with RPM packages just because it's
possible is tedious, incomplete and mostly pointless IMHO. An era
when upstream projects were eager to get their tool into the distros
has passed. Having pythonX-foo packaged where no other
tool/app/service needs it is not beneficial (if foo is a library
only thing, not a tool itself). I have this opinion even with
python3 packages.

Developers who wants to use python2 for whatever reasons (rational
or emotional ones) can do that on Fedora. We encourage developers to
use virtual environments and pip [1]. Removing leaf python2 packages
does not block them here at all.


Let them have a single moment where python2 support goes away.


Removing all python2 things at one point is impossible. We've tried
to test this with Django [2] on a much smaller scale. (Tens instead
of thousands packages.) It took us too much time and too much
energy. At the end, too much packages were just retired because
their maintainers are "dead". I cannot imagine doing this on current
scale in 2020.
We can just retire python2 then and see what breaks. Honestly,
everything would break.

I don't think this is entirely comparable. Django20 was about updating
packages and switching support from python2 to python3. Just dropping
existing support for python2 is something much easier.


Maybe it's much easier, but it's still not trivial.

I just saw a package that uses epydoc to generate its documentation, 
from its py2 code. Since epydoc is not ported, that package would lose 
its documentation if python2 was just suddenly dropped – and we wouldn't 
know in advance, because the package was in the "dual py2/py3 support" 
bucket.
But I'm not complaining about epydoc in general. I'm afraid there are 
many more cases like that – cases where we won't know about the problem 
until we try to remove the py2 packages. Especially those with 
unresponsive maintainers, which tend to use the most interesting ancient 
technology.


I don't see a good way to uncover such problems other than to start 
removing stuff.




Nevertheless, I agree that this still is a very significant chunk of
work at this scale. So spreading this out makes a lot of sense, but
imho python2 subpackages don't need to go away, they can just be
conditionalized.

What about adding conditionals like

%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif

starting now?


Agreed, we just need to bikeshed the "31" number there.

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

Intent to orphan Python 2

[Petr Viktorin]

Hello,
Here is a message I want to post to devel-announce later. Let me know if 
you see anything wrong (or would like to take over python2 maintainership).


---
Intent to orphan Python 2

tl;dr: Unless someone steps up to Python 2 after 2020, we need to start 
dropping python2 packages now.



Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded 
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2 
alive, we won't be the ones doing it – at least not at the current 
magnitude".

Here are the details.


The current maintainers of python2 would like to "orphan" the python2 
package in 2020 (~ Fedora 32/33):

- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is 
a security-critical package and will be abandoned upstream), or

- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent 
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support 
from dependent packages *now*, starting with ported libraries on whose 
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested 
packagers, as long as there's an understanding that we won't just 
support python2 forever.


If you are a maintainer of anything at [1] we ask you kindly to consider 
removing the python2 subpackages.


If no one steps up to maintain python2 after 2020, we're prepared to 
package a "legacy" python27 package, similar to what we do for e.g. 
python33 [2], to:

- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if 
their upstreams don't manage to port to Python 3 in time




[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/

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

Re: Draft: Macros to tell what Python versions to package for

[Petr Viktorin]

I like to use bconds, i.e. "%if %{with python2}". They're easy to 
override for local builds, allowing easy experimentation with, for 
example, dropping Python 2.
I'd be happy if our official recommendation used bconds. If we want 
people to copy-paste something, let's make it good.


Also, "with_python2" is the current de-facto best practice. It's a good, 
descriptive name, and people are used to it.
The "%if 0%{?py3_may}" is not as descriptive. If that is used throughout 
the specfile, people will need to know/read the docs – or just consider 
it magic.


So, I'd prefer adding macros that set "with_python2" bconds, and using 
that throughout the specfile.



For a more concrete idea, would something like this work? Naming to be 
bikeshedded of course.


# Build for python2 if it MUST be done
%py2_bcond_if required
# Build for python3 if it MAY be done
%py3_bcond_if available

%build

%{?with_python2:py2_build}
%{?with_python3:py3_build}

%install

%if %{with python2}
%py2_install
%endif
%if %{with python3}
%py3_install
%endif


(And some kind of %py_build_all and %py_install_all as the next baby 
step? Or am I reinventing a wheel with that line of thought?)



Also, I'd like to do some wordsmithing on the proposal when the 
technicalities are sorted out, so the following is obvious to people who 
just skim it:
- This new complexity is *only* meant for packagers who share specs 
across distros; others can stop reading now.

- FYI, we would love it if you dropped your py2 subpackage from Fedora.


On 03/02/18 10:36, Miro Hrončok wrote:

Hello Pythonistas,

I've prepared a draft for Python packaging that introduces some new 
macros that should ease packaging for Fedoras, EPELs and even potential 
new RHELs, when it comes to python stacks.


I don't do much ifs in specfiles and prefer to leverage git branches for 
this, so I don't know what bothers you most. The proposal with example 
spec file is at:


https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros 



All you have to do to test it, is add the following block to your spec 
(that won't be needed once this is actually implemented):


     %if 0%{?fedora}
     %global py3_must 1
     %global py3_may 1
     %global py2_may 1
     %endif

     %if 0%{?rhel} &&  0%{?rhel} <= 7
     %global py3_may 1
     %global py2_may 1
     %endif

     %if 0%{?rhel} > 7
     ... (use your best judgment here)
     %endif

Could you please provide feedback? Ask questions?

There is a note at the bottom of the draft about how you could possibly 
start dropping Python 2 subpackages from Fedora.



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

Re: Removal of BuildRoot

[Petr Viktorin]

On 02/15/2018 10:17 AM, Michal Novotny wrote:
I feel PRs are better for this sort of stuff. Mainly because people are 
informed why exactly this change is made,
they can read the guidelines and then merge the change when they are 
sure they understand it. It helps spreading knowledge
and keeping community involved. Python team did it very well in their 
"Fedora's Switch to Python 3 effort 
<https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3>", i think.


Yeah, well, I definitely agree that's how it should be done, but... did 
you see the script that handles the automatic pull requests? (If not, 
the first half is here: https://pagure.io/python-fixrequires, and the 
second half -- merging -- is not yet automated.)


Pagure's API around automatically creating and administering Pull 
Requests is, not yet useful enough. Selenium kinda works as a 
workaround. But I wouldn't recommend it, unless one of your goals is to 
find the issues, so this can eventually become the preferred workflow. 
(See e.g. https://pagure.io/pagure/issue/2803)


(Disclaimer: I'm not the one actually doing the work, I just heard the 
complaints...)



Maybe it would be nice if proven packagers had some tooling for doing 
those changes.


tl;dr: It's possible, people are slowly working on it, but it's not 
generally usable yet.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 strange rpmbuild failure

[Petr Viktorin]

On 02/04/2018 10:08 PM, Alec Leamas wrote:



On 04/02/18 21:36, Steve Grubb wrote:

On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:



Many questions here, and a large package. Still, searching the logs I
cannot see any python files - are there any such at all?


None at all. Its all java, javascript, R, and ELF files.


If not, perhaps  you could disable the byte compulation as described in
[1]?


Bingo! That fixed the build...which leads to the question of why is that
failing?


I think the basic answer is that the byte comoilation script is using
all sorts of strange heuristics. It seems that it determined a that a
non-python file was python.

Efforts are under way to redefine things and make the byte compilation
more explicit. Until this is done, this is probably not the last error
of this sort.

In other words, it's sort of a known bug with fixes under way, slowly...


I'd like to make sure any Python-related automation is limited to Python 
context (/usr/lib*/python*, files with python shebangs, etc.). I'm not 
sure why it's not this way now.


We're preparing a Change to fix this exact issue in Fedora 29. Started 
just last week, actually:

https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation

Up to this point I thought this was just a theoretical issue. Thank you 
for finding a concrete example -- and sorry it had to be you!



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 12:47 PM, Guido Aulisi wrote:

2018-02-05 12:00 GMT+01:00 Petr Viktorin <pvikt...@redhat.com>:

On 02/05/2018 09:32 AM, Guido Aulisi wrote:


Hi,
according to latest python guides, we should avoid calling generic
unversioned python command

(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been
downgraded.

Thanks



Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a
different error: "--freedesktop requires itstool > 2.0.0 to translate
files.".
Could you check if that's not causing the failure?


I found that the check for itstool fails because it gets the
deprecation warning as input, there's a mistake in
output = subprocess.Popen("itstool --version", shell=True,
stderr=subprocess.STDOUT,
stdout=subprocess.PIPE).communicate()[0].splitlines()
stderr is redirected to stdout, so itstool gets DEPRECATION and
version [u'WARNING:']
I will report this upstream, it seems to me that the redirection of
stderr is a mistake.


Ah! I see the problem now: /usr/bin/itstool has a /usr/bin/python 
shebang. I've filed a pull request that should fix this:

https://src.fedoraproject.org/rpms/itstool/pull-request/1


[...]


It looks like waf will be one of the tougher things to figure out. After the
mass rebuild we'll see the effect on the whole distribution, and hopefully
come up with a better strategy for bundled waf.


I will file a bug for waf, if it's the correct thing to do.


If you can wait a bit until itstool maintainers merge the PR, that 
should sort the problem out.

Let me know if you need this soon, I can look for a provenpackager.


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 09:32 AM, Guido Aulisi wrote:

Hi,
according to latest python guides, we should avoid calling generic
unversioned python command
(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been downgraded.

Thanks


Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a 
different error: "--freedesktop requires itstool > 2.0.0 to translate 
files.".

Could you check if that's not causing the failure?

If the python2 message is breaking your build, then please file a bug 
and set an environment variable, as described in the Change. (Do file 
the bug, though – that ensures we'll contact you before we remove the 
workaround.)



Background:

We do want everyone to avoid calling /usr/bin/python, but we realize 
it's not always easy. That's why we added the warning -- it will allow 
us to grep the logs to figure out what is using it (and why). And of 
course, in simple cases it can be fixed right away.
Some tools do fail if there's extra output on stderr; that's the reason 
for the "Quick Opt-Out" workaround.


It looks like waf will be one of the tougher things to figure out. After 
the mass rebuild we'll see the effect on the whole distribution, and 
hopefully come up with a better strategy for bundled waf.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

No more automagic bytecompilation

[Petr Viktorin]

Did you know that if you put a .py file outside /usr/lib/pythonX.Y/, 
rpmbuild will automatically byte-compile .pyc/.pyo for it?

Using Python 2 by default?

I find this (and especially the details of how it's done) too 
surprising, too limited and too hard to configure properly.
Miro and I are drafting a Fedora change to eventually switch to doing 
the byte-compilation explicitly instead. Files in /usr/lib/pythonX.Y/ 
still get compiled automatically, of course.


You can read the draft here:
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation


--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3.7's Deterministic pycs

[Petr Viktorin]

On 02/01/2018 04:21 PM, Nick Coghlan wrote:

On 1 February 2018 at 23:54, Petr Viktorin <pvikt...@redhat.com> wrote:

Honestly, I'm not sure we want to use this in Fedora. Is anyone here into
reproducible builds, to make a better argument for this?


I believe rpmbuild (et al) all set SOURCE_DATE_EPOCH in the
environment, so Fedora's likely to get the new CHECKED_HASH behaviour
by default: 
https://docs.python.org/dev/library/py_compile.html#py_compile.compile


Wait. These docs say "invalidation_mode will be forced to 
PycInvalidationMode.CHECKED_HASH", which sounds quite scary. Is it 
possible to use UNCHECKED_HASH with SOURCE_DATE_EPOCH?


(I don't think we use SOURCE_DATE_EPOCH now, but we might in the future.)


Given that SELinux typically won't allow user applications to rewrite
the bytecode anyway, we may want to specify the use of UNCHECKED_HASH
at build time instead - with that setting, Python will ignore source
file changes entirely, and trust that RPM will keep the source and pyc
files consistent.


And it lets us... avoid a stat call per import? I still fail to see the 
advantage :(




--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Python 3.7's Deterministic pycs

[Petr Viktorin]

Hello!
The first beta for Python 3.7 is out. It will hopefully get into Fedora 
soon as python37.

After it comes out of beta, we'll upgrade python3 to it.

The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html

One thing that's interesting for packagers is PEP 552: Deterministic 
pycs: https://www.python.org/dev/peps/pep-0552/


Let me summarize in my own words.


A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files 
depend only on the contents of the corresponding source file.
If we use this, it will slow down imports, because the whole source file 
would need to be read and hashed in order to verify if a .pyc file is 
valid. (Currently, metadata like the modification time and file size is 
used.)


To speed things up, there's an option, UNCHECKED_HASH, which skips cache 
validation entirely. Using this would mean that if you modify a .py 
source file installed by RPM, the changes wouldn't take  effect (the .py 
contents would only be shown in tracebacks).
Modifying installed files in production is extremely bad practice, of 
course, but it's quite useful for debugging on throw-away systems. If we 
adopt UNCHECKED_HASH, anyone doing it will have to remember to remove 
the corresponding .pyc file.



Honestly, I'm not sure we want to use this in Fedora. Is anyone here 
into reproducible builds, to make a better argument for this?



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

[OT] Octal number syntax (Was: Please stop re-adding gtk-update-icon-cache scriptlets)

[Petr Viktorin]

On 01/20/2018 06:08 AM, Chris Adams wrote:

Once upon a time, Nico Kadel-Garcia <nka...@gmail.com> said:

I don't see any modern scripting language where a leading 0 would lead
to interpreting a number as octal.


I suggest you check again; I don't see any where a leading 0 does NOT
lead to interpreting a number as octal  Here are a few common scripting
languages (just what I have installed):

$ python -c 'print(010 + 1)'
9


Fedora's /usr/bin/python is not a modern scripting language, but a 
7-years-old one with even older historical baggage. We're working on 
fixing that, but there are serious backwards compatibility issues :) 


Generally, the movement is away from leading 0 meaning octal.
Current Python does not allow this. It was removed exactly because it 
was "extremely easy to inadvertently [specify] the wrong value" [0], 
especially for people without a C/Unix background.
Instead, there's the explicit "0o" prefix, which also works in Python 2, 
Ruby, JavaScript (ES6), Perl 6, ... even Rust. An you're likely to see 
style guides and linters warning against leading 0 in languages that 
keep it.


You could say RPM is ahead of its time here!


[0]: https://www.python.org/dev/peps/pep-3127/#motivation


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Petr Viktorin]

On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:

Hello,
Python3 will be in the next major RHEL release.  I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following

   if 0%{?fedora}
%define with_python3 1
   %endif

If you have something like that, please change it to something like this.

   if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
   %endif


I'll say it once again, but why can't we just have
%{python2_available} and %{python3_available} macros defined in the
base system?


Mostly because we can't change RHEL.

So, how about %{python2_missing} and %{python3_available}? Is that too 
ugly and inconsistent?



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Petr Viktorin]

On 01/10/2018 09:33 AM, Miro Hrončok wrote:

On 10.1.2018 03:16, Nick Coghlan wrote:
On 10 January 2018 at 11:30, Jason L Tibbitts III <ti...@math.uh.edu> 
wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look 
something like:


 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually set a 
dedicated env vars for our builds (which is even better).


+1, let's do that!


This would potentially even make it possible to push this patch to 
upstream. >

Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.






--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Django 2.0 released, and what it means to you

[Petr Viktorin]

On 12/12/2017 04:17 PM, Miro Hrončok wrote:

On 7.12.2017 10:56, Matthias Runge wrote:

To follow-up on this, I'm drafting a change[1]. Since my
responsibilities changed, this has a quite low priority for me.
Any help is greatly appreciated!

Best,
Matthias
[1] https://fedoraproject.org/wiki/User:Mrunge/Django20


Today, we proposed https://fedoraproject.org/wiki/Changes/Django20 and 
set it to Ready For Wrangler.


I filed a review request for python2-django1.11: 
https://bugzilla.redhat.com/show_bug.cgi?id=1532541



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Django 2.0 released, and what it means to you

[Petr Viktorin]

On 12/05/2017 09:19 AM, Matthias Runge wrote:

Hello,

tl;dr if you're not maintaining/using a Django related package,
you can safely skip this message.


Django 2.0 was released quite recently. While it is mostly compatible with
earlier versions, the SIGNIFICANT change is, to drop support for Python 2.

I'm intending to update Django in Rawhide to 2.0 in 2 weeks. If you're
maintaining a package depending on Django, please make sure to disable
the python2 subpackage. Please keep in mind, you'll also need proper
obsoletes.

If there is any bug, blocker, whatever connected to this change,
please make also sure to report it in bugzilla and
make your bug a blocker for[1].


Hi,
Another option is to create a new "python2-django" package containing 
the latest Django 1.x code (which is still supported upstream as LTS). 
That would mean dependent packages would have until April 2020 to drop 
Python 2.

If that would help, let me know and I'll package it.


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: pytest byte compiling its own files

[Petr Viktorin]

On 11/10/2017 04:58 AM, Scott Talbert wrote:

Hello all,

I've recently noticed that in some of the python packages I maintain, 
there are now additionally byte-compiled files that appear to be from 
pytest:


[swt2c@rawhide-test ~][PROD]$ rpm -ql python3-pytest-xdist | grep PYTEST
/usr/lib/python3.6/site-packages/xdist/__pycache__/_version.cpython-36-PYTEST.pyc 

/usr/lib/python3.6/site-packages/xdist/__pycache__/dsession.cpython-36-PYTEST.pyc 

[...etc...]



It seems that these files must be generated when running the tests for 
the package.  I have a hunch they might be problematic, though, because 
they contain the buildroot's path in them:


[swt2c@rawhide-test ~][PROD]$ strings 
/usr/lib/python3.6/site-packages/xdist/__pycache__/_version.cpython-36-PYTEST.pyc 
| grep builddir
t/builddir/build/BUILDROOT/python-pytest-xdist-1.20.1-1.fc28.noarch/usr/lib/python3.6/site-packages/xdist/_version.py 



What are these special PYTEST byte compiled files? 
Pytest compiles test files slightly differently than normal Python. 
That's what allows it to do its "assert rewriting", i.e. telling you 
what went wrong assert.
I *assume* this is what's happening here: they started caching the 
results of that compilation. I might be wrong, but that's the direction 
I would look in if I had time to research this issue today :)


I'm adding Thomas, pytest's maintainer, to the thread. Thomas, do you 
know more about what's happening?




Should they be packaged in the first place?


I don't think they should.
They're cache files; nothing should break if they're if not present. 
Pytest will probably try to write them when it runs, but should silently 
do nothing if it can't write into /usr/lib.
So, the only time not packaging them would be a problem is if someone 
runs the tests as root, as that would create unpackaged files in 
/usr/lib. But I don't think that's a use case we need to support.




Anyway, thanks for letting us know! This might turn out to be something 
we'll need to solve at the Python SIG level.

I'll start with a brainstorm.

How to best make sure those files aren't packaged? %ignore? Or rm them 
at end of %check? Or is there some Pytest config option or env variable 
to prevent writing them, which we could enable in the rpm macros?



For the record, here are packages that have the issue now:

$ sudo dnf repoquery --releasever 27 -s -f '*PYTEST.pyc'
pytest-3.2.1-3.fc27.src.rpm
python-astropy-2.0.2-1.fc27.src.rpm
python-camel-0.1.2-2.fc27.src.rpm
python-flask-0.11.1-6.fc27.src.rpm
python-healpy-1.11.0-1.fc27.src.rpm
python-joblib-0.11-1.fc27.src.rpm
python-pyqtgraph-0.10.0-1.fc27.src.rpm
python-pytest-timeout-1.2.0-3.fc27.src.rpm
python-pytest-xdist-1.18.2-1.fc27.src.rpm
python-wcsaxes-0.9-5.fc26.src.rpm

--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Parselmouth Badge

[Petr Viktorin]

On 11/05/2017 08:39 PM, Troy Curtis Jr wrote:

So, do upstream contributions count toward Parselmouth badges? ;)


I'm afraid the way they're set up now, they're just for the Fedora 
packages – mainly because I don't really want to get in the business of 
reviewing how each upstream contribution affected Fedora.


Should that be changed?



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Package submission question

[Petr Viktorin]

On 09/04/2017 03:37 PM, Miro Hrončok wrote:



On 4.9.2017 15:34, Troy Curtis Jr wrote:
On Mon, Sep 4, 2017 at 7:52 AM Miro Hrončok <mhron...@redhat.com 
<mailto:mhron...@redhat.com>> wrote:




On 4.9.2017 14:49, Troy Curtis Jr wrote:
 >
 >
 > On Mon, Sep 4, 2017 at 3:54 AM Petr Viktorin <pvikt...@redhat.com
<mailto:pvikt...@redhat.com>
 > <mailto:pvikt...@redhat.com <mailto:pvikt...@redhat.com>>> wrote:
 >
 > On 09/04/2017 06:21 AM, Troy Curtis Jr wrote:
 >  > I have a version of the gpsd package which I believe
addresses this
 >  > ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1390812.  I've
 > been
 >  > looking around about the right way to submit.  I thought
it would
 > be by
 >  > using a pull request from within the pagure instance at
 >  > src.fedoraproject.org <http://src.fedoraproject.org>
<http://src.fedoraproject.org>
 > <http://src.fedoraproject.org>.  However, I cannot
 >  > authenticate with my ssh key.  There is no where to add it
within
 >  > pagure, and my FAS key doesn't seem to be sufficient.  So
perhaps
 > this
 >  > isn't they way?  Then I was reading through
 >  >
 >

http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request 


 >  > , but it seems a bit geared toward brand new packages, so
I was
 > not sure
 >  > if that was in fact the proper coarse.
 >  >
 >  > I'd appreciate any pointers as to the proper direction to
get this
 >  > updated package updated.  In the meantime, I'll fix the
rpmlint
 > warnings
 >  > I just found!
 >
 > That shouldn't be happening.
 > What's your FAS username?
 >
 > troycurtisjr


Thanks!
I see in FAS that you're not yet a packager. That's probably the reason 
you don't have Pagure write access.


That's a bit unfortunate, and I guess it should be solved with remote 
pull requests, but as you found out those seem broken at the time. (It's 
all a pretty new system, so it's not unreasonable to think no one tried 
remote PRs here yet.)


I've made a PR for you: https://pagure.io/fedora-infrastructure/issue/6332
Could you please comment there? :)


 >
 >
 > If you can push the changes to another public Git repository
(e.g.
 > GitHub), that could be a workaround while we get Pagure access
 > sorted out.
 >
 >
 > Ok so Pagure is the right way to go then.  I tried importing my 
key

 > again, but I'm still getting denied.  I can use the same key on a
 > different linux host as well as with gitlab.com
<http://gitlab.com> <http://gitlab.com>, so
 > I'm fairly confident my local configuration is correct.  I assume
this
 > is unrelated, but I also can't seem to tie my FAS account
correctly to the


... the rest of the sentence seems missing.


 >
 > For the time being then, I've pushed my changes to
 > https://gitlab.com/troycurtisjr/fedora-pkg-gpsd.git under the
 > 'python2-packaging' branch for review. Additionally, I used 
copr to

 > build for several releases, which you can find at
 >

https://copr.fedorainfracloud.org/coprs/troycurtisjr/gpsd/build/597872/



Now you should be able to send a pull request from gitlab in here:
https://src.fedoraproject.org/rpms/gpsd/diff/remote


Remote pull requests, that is a great feature!

Unfortunately I can't seem to get it to work either.

I've tried using the gitlab.com <http://gitlab.com> repo, then I 
pushed to github and tried from there, same error.  Then I wondered if 
it didn't like having a hyphen in the branch name so I changed that.  
I even removed the hash from the ticket reference in the title.  In 
all cases I get: "Fatal Error (500)" in response.  I am using the 
https repo url, and have cloned on another machine to ensure the urls 
are publically available.


I guess that sounds like a thing that needs a report at 
https://pagure.io/fedora-infrastructure/issues


I've reported it:
https://pagure.io/fedora-infrastructure/issue/6332




--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/25/2017 10:23 AM, Nick Coghlan wrote:

On 24 August 2017 at 21:28, Petr Viktorin <pvikt...@redhat.com> wrote:

On 08/24/2017 12:22 PM, Nick Coghlan wrote:

Stream names match the Platform module. We follow its policy here, even
when
it changes.


Oh, interesting, I had that backwards (I thought the planned F27
Python modules were the ones named after upstream Python releases).

That means the current module definitions would be closer to what I'm
calling the "Integrated Python Modules".


My comment was for Platform Python :)


Oops, reading comprehension fail on my part :)


* Python Interoperability Testing Modules
- one module per Python X.Y release
- only one stream per module
- conflict with the corresponding Application Runtime stream
- provide "/usr/bin/pythonXY" and "/usr/bin/pythonX.Y"
- do NOT satisfy "python2-*" and "python3-*" RPM dependencies

And looking at their current implementation in Fedora, one notable
difference between them and the Application Runtime streams is that
these would just use their bundled pip and setuptools, rather than
splitting those out the way the regular packages do.


No, I don't want to support *full* parallel-installable stacks. Let's stick
to what we currently support in Fedora, not more.

"Python Interoperability Testing Modules" get "x.y" streams and provide
"x.y" binaries;


These modules will probably only have one stream each, so I don't have
a strong personal opinion on what that stream is called (although it's
also possible they could each end up with two streams: one that
actually installs the parallel installable version, and one that just
depends on the corresponding application runtime stream).


"Python Application Runtime Modules" get one stream for
python3 and one python2, and provide the python2/python3 binaries.


I think we can do better than that, and the relative timing of the F28
and Python 3.7 releases provides a good illustration of why I think we
should aim to do so:

* F28 code freeze is in March, with the release in May
* 3.7 release candidate is in May, with the release in June

Traditionally, that would have meant that we wouldn't get a Fedora
based Python 3.7 container out the door until the release of Fedora 29
in October, and we'd never ship the F28+3.7 combination at all, even
for folks that mainly just want the Python runtime, and then will use
pip to install everything else they need.


Traditionally, that's very well possible: there'd be a "python37" 
package that provides a /usr/bin/python37. We do the same for old 
versions, and for python36 on f25. It works quite well.


If the intended use for 3.7 in f28 is to make a virtualenv and use pip 
to install things, that virtualenv can very well be made by calling 
/usr/bin/python37. I still see no reason for a stream that makes 
/usr/bin/python3 point to 3.7.



However, I think modularity gives us access to a more flexible
approach: we can set up the F28 System Profile to *default* to the 3.6
Python App Runtime stream, allowing the sequence of updates to be:

1. In Fedora 28, we split the Python 3 runtime module into two pieces:
- the App Runtime, with a 3.6 stream
- the Integrated Runtime, with an f28 stream that depends on AppRuntime:3.6
2. After 3.7 hits beta in January 2018, we add a "3.7" stream to the App Runtime
3. After 3.7 is released, we start building a new F28+3.7 app
development container
- in this configuration, most system packages that need Python 3 can't
be installed


How do you achieve this for package that depend on /usr/bin/python3?


4. In Fedora 29, we add an f29 stream to the integrated runtime that
depends on AppRuntime:3.7
- now it would be the F29+3.6 configuration that prevents use of
system packages that need Py3


I don't think "Integrated Python Modules" are necessary in Fedora.


Whether they're necessary or not depends on whether we enable the
F28+3.7 configuration: if we allow that, then we need a way to make it
clear that in that configuration, the only Python-3-based system
packages you can install are the ones that rely on
/usr/libexec/platform-python instead of /usr/bin/python3 (since the
others ran their integration testing against the default 3.6 stack).


The only thing that relies on /usr/libexec/platform-python is dnf. 
Nothing else.



Also, the names are a mouthful; let's revise naming after we get the
semantics down :)


I'm reasonably happy with App Runtime (since I stole that directly
from "OpenShift Application Runtimes", which is the downstream use
case I'm interested in making easier to maintain), and I think
"Integrated Python" or "Integrated Runtime" accurately conveys the
significance of the proposed stream mapping between Fedora versions
and Python versions ("F28 integration testing uses Python 3.6", "F29
integration testi

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/24/2017 12:22 PM, Nick Coghlan wrote:

On 24 August 2017 at 19:02, Petr Viktorin <pvikt...@redhat.com> wrote:

On 08/24/2017 10:13 AM, Nick Coghlan wrote:

My current thinking based on that discussion is that we're actually
going to need a module set that looks like this for F28+:

* Platform Python (already planned for F27)
- part of the Platform module
- stream names match Fedora releases (f26, f27, etc)


Stream names match the Platform module. We follow its policy here, even when
it changes.


Oh, interesting, I had that backwards (I thought the planned F27
Python modules were the ones named after upstream Python releases).

That means the current module definitions would be closer to what I'm
calling the "Integrated Python Modules".


My comment was for Platform Python :)


* Python Application Runtime Modules (already planned for F27)
- one module for Python 2 and one for Python 3
- stream names match upstream Python releases (2.7, 3.6, etc)
- Application Runtime Modules conflict with the corresponding >
Integrated Python Module
- provide "/usr/bin/python2" and "/usr/bin/python3" respectively
- also satisfy "python2-*" and "python3-*" RPM dependencies
- only the Python 2 module satisfies "python-*" RPM dependencies (for
now) > * Integrated Python Modules
- one module for Python 2 and one for Python 3


These need to be parallel installable, to support tox. So we need separate
modules for each Python release.


Aye, I agree that will be a good way to tackle the parallel
installable versions that *don't* define "/usr/bin/python3". However,
for containers designed to run Python applications (web or otherwise),
we *will* want mutually conflicting streams that define their symlinks
and RPM provides based only on the Python major version.

So lets make those extra modules their own distinct category:

* Python Interoperability Testing Modules
   - one module per Python X.Y release
   - only one stream per module
   - conflict with the corresponding Application Runtime stream
   - provide "/usr/bin/pythonXY" and "/usr/bin/pythonX.Y"
   - do NOT satisfy "python2-*" and "python3-*" RPM dependencies

And looking at their current implementation in Fedora, one notable
difference between them and the Application Runtime streams is that
these would just use their bundled pip and setuptools, rather than
splitting those out the way the regular packages do.


No, I don't want to support *full* parallel-installable stacks. Let's 
stick to what we currently support in Fedora, not more.


"Python Interoperability Testing Modules" get "x.y" streams and provide 
"x.y" binaries; "Python Application Runtime Modules" get one stream for 
python3 and one python2, and provide the python2/python3 binaries.


I don't think "Integrated Python Modules" are necessary in Fedora.

Also, the names are a mouthful; let's revise naming after we get the 
semantics down :)




- stream names match Fedora releases (f26, f27, etc)
- each depends on an *exact* version of the corresponding Python
  Application Runtime module



Huh? You just said Python Application Runtime Modules would conflict with
this.


Sorry about that - when I started writing the email, my plan was to
have them conflict with each other, but as I wrote that initial
version up I went "Hang on, couldn't I use a stream dependency here
and rely on *that* to trigger a conflict if you had an Integrated
Python module installed and then tried to switch to an unsupported
runtime stream, or vice-versa?"


* Default Python Module
- provides /usr/bin/python (and nothing else)
- stream names: no-default, python3-default, python2-default


+1
I guess this would contain a "python" RPM, containing just a /usr/bin/python
symlink, which would added to non-modular Fedora as well.


Pretty much, yeah. The "no-default" stream would be a bit different,
as in that case it would install a shell script that printed out a
custom error message.


A shell script that would satisfy file dependencies on "/usr/bin/python" 
might not be the best idea.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/24/2017 10:13 AM, Nick Coghlan wrote:

On 21 August 2017 at 19:46, Petr Viktorin <pvikt...@redhat.com> wrote:

On 08/18/2017 01:38 PM, Nick Coghlan wrote:

Does that approach sound sufficiently plausible to folks that I can
use it to provide feedback to the folks working on the modularity
tooling as to the capabilities we think we'll need?


That sounds like it would work. But yes, please talk to the Modularity WG to
see if modules can be made to work that way.


Aye, this draft proposal was essentially me figuring out what I think
we're going to want/need for Python before I pitched the related
feature ideas to the Modularity WG :)

The proposal then became something I could point to to say "This is
the problem I'm trying to solve" while we discussed various possible
ways of solving it.

I finally had a discussion with Langdon about it today, and he really
isn't a fan of my idea of trying to enhance the modularity tooling to
natively support parallel installation of streams - he'd strongly
prefer that we stick to the idea of "one active stream per module per
system" (at least for now), and then rely on separate SRPMs and/or the
Software Collections parallel installation layout to handle use cases
like tox.

(Note: I'll get the properly formatted proposal updated by tomorrow,
so feel free to wait for that if the email version below is a bit hard
to read)

My current thinking based on that discussion is that we're actually
going to need a module set that looks like this for F28+:

* Platform Python (already planned for F27)
   - part of the Platform module
   - stream names match Fedora releases (f26, f27, etc)


Stream names match the Platform module. We follow its policy here, even 
when it changes.



* Python Application Runtime Modules (already planned for F27)
   - one module for Python 2 and one for Python 3
   - stream names match upstream Python releases (2.7, 3.6, etc)
   - Application Runtime Modules conflict with the corresponding >  
Integrated Python Module
   - provide "/usr/bin/python2" and "/usr/bin/python3" respectively
   - also satisfy "python2-*" and "python3-*" RPM dependencies
   - only the Python 2 module satisfies "python-*" RPM dependencies (for now) > 
* Integrated Python Modules
   - one module for Python 2 and one for Python 3


These need to be parallel installable, to support tox. So we need 
separate modules for each Python release.



   - stream names match Fedora releases (f26, f27, etc)
   - each depends on an *exact* version of the corresponding Python
 Application Runtime module


Huh? You just said Python Application Runtime Modules would conflict 
with this.



* Default Python Module
   - provides /usr/bin/python (and nothing else)
   - stream names: no-default, python3-default, python2-default


+1
I guess this would contain a "python" RPM, containing just a 
/usr/bin/python symlink, which would added to non-modular Fedora as well.




The scope for F27 would specifically be Platform Python and the Python
Application Runtime Modules, with the separate Integrated Python
Modules being defined for F28+

At least for now, the Python XY stacks for Fedora and EPEL, as well as
the Python SCLs, would be treated as something generated downstream
from the app runtime modules, rather than as something that the
modularity tooling would necessarily handle natively.

The general idea is that it would then be up to other modules to
decide whether they specifically needed the Integrated Python Module
with all the related system bindings (in which case they'd either
depend on that module, or depend on another RPM that depended on it),
or were prepared to cope with any installed version of Python 3 (in
which case they'd just use normal RPM level "python3*" dependencies).

Right now, the difference between the Integrated Python Modules and
the Python Application Runtime Modules isn't particularly obvious, but
it hopefully becomes clearer once we consider questions like "Who will
decide when to rebase to Python 3.7?" and "When will a particular
stream stop being updated?".

For the Integrated Python Modules, those are Fedora level design
decisions, as reflected in the stream names being based on Fedora
versions. This means that for a system container, or a traditional
mutable installation, you'd be able to continue to rely on a shared
Python installation with all the operating system level bindings for
things like the RPM database, without Fedora package maintainers
having to provide prebuilt bindings for arbitrary Python versions.
You'd only change streams when you changed base Fedora versions, and
the update cycle for these streams would match the Fedora release
cycle (i.e. each stream would receive updates for 13 months from the
date of the corresponding Fedora release).

By contrast, for the Python App Runtime Modules, when to rebase is an

Python 3.5.4 in Fedora 25

[Petr Viktorin]

Hello,
Python 3.5.4 for Fedora 25 is now waiting in Bodhi; see more info here:
https://bodhi.fedoraproject.org/updates/python3-3.5.4-1.fc25

Please test and provide karma :)


--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/18/2017 01:38 PM, Nick Coghlan wrote:

Hi folks,

[Note: this may not make much sense to folks that haven't been closely
following the Modular Server work for F27. If that's you, sorry -
hopefully this will be more comprehensible by the time I officially
propose it for F28, as the relevant terminology becomes more widely
understood. In the meantime, check out
https://docs.pagure.org/modularity/ to learn more]

I'm working on a draft proposal for a "Default Python" module (see
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
for details), and hit an interesting challenge when it comes to
defining the containing images that we want to be able to build from
our module definitions.

A quick summary of what I'm expecting we'll have by F28:

- a separate platform-python binary in the Platform module
- python2 modules with a full 2.7 stream and a partial
interpreter-only 2.6 stream
- python3 modules with a full 3.6 stream and a TBD set of other streams
- a default-python module to switch between no-default,
python2-default and python3-default

With those modules defined, a minimal Fedora container image will only
include platform-python, but we'd at least also have Python3-F28, and
Python2-F28 images that included the respective user Python stack in
addition to the platform Python runtime.

The part I'm struggling with is this: Python 3.7.0 is expected to be
released in June 2018, while Fedora 28 is due out in May 2018. It
would be *really nice* to be able to define a Fedora 28 based Python
3.7 container where "/usr/bin/python" and "/usr/bin/python3" were both
references to "/usr/bin/python3.7".

The challenge with actually doing that lies in the "/usr/bin/python3"
symlink: integrated userspace Python applications in F28 are going to
expect that to still refer to the Python 3.6 stream.

One way I could potentially see this working:

* the normal non-conflicting setup is as follows:

   * the python3 3.6 stream includes a "/usr/bin/python3" symlink
   * the other python3 3.x streams do *not* include such a symlink &
hence don't conflict
   * the default-python python3-default stream does *not* include such
a symlink & hence doesn't conflict

We then add some more streams to the default-python module that *do*
include a "/usr/bin/python3" symlink: python3.5-default,
python3.7-default, etc

The trick with these streams is that they would *conflict* with the
regular python3 3.6 stream, due to the disagreement over what
"/usr/bin/python" means. That dependency resolution conflict would
then mean that have a non-default version of Python 3.x configured as
the default when defining your container would *prevent* you from
including any regular userspace Python components - you'd only be able
to include the ones built specifically for that stream.

Does that approach sound sufficiently plausible to folks that I can
use it to provide feedback to the folks working on the modularity
tooling as to the capabilities we think we'll need?


That sounds like it would work. But yes, please talk to the Modularity 
WG to see if modules can be made to work that way.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: ENOTIME

[Petr Viktorin]

On 07/20/2017 05:04 PM, Orion Poplawski wrote:

My workload at $dayjob$ has increased significantly so I'm afraid I have much
less time to devote to packaging work.  Now more than ever I could use help
maintaining my packages (listed below).  If you are interested, please add
yourself as co-maintainers in pkgdb.  Thanks!


Hello Orion!
Sorry for the late reply; I'm behind in my e-mails.

First of all, thank you very much for all your work! I knew you 
maintained a lot of Python packages, but seeing the whole list is very 
impressive.


Would you like to hand over (some of) your Python packages to the Python 
SIG?
Pagure doesn't allow groups as package owners, but I hope I can 
represent Python SIG here, at least for administrative tasks. (Among 
other things, I lead Red Hat's python-maint team, which includes many 
active Python SIGgers.)
If you add me as admin, I'll add Python SIG to the committers list, try 
to search for contributors, and handle any emergencies. (I can't promise 
we'll handle day-to-day packaging for all the packages, but some of them 
are interesting to me presonally.)


Unfortunately, in Pagure I can't request access for myself. But if you 
agree, I can file ticket with a Fedora infra for some kind of mass update.


Python packages where you're an admin seem to be:

netcdf4-python
oct2spec
pyhoca-cli
pyhoca-gui
pymongo
python-AppTools
python-Traits
python-backports_abc
python-clyent
python-cytoolz
python-ecdsa
python-envisage
python-gflags
python-google-apputils
python-iptools
python-ipython_genutils
python-jupyter_core
python-locket
python-nbformat
python-numpydoc
python-optcomplete
python-pamela
python-pkgconfig
python-process-tests
python-pycosat
python-pyface
python-pytest-cache
python-pytest-cov
python-pytest-flakes
python-pytest-pep8
python-rpm-macros
python-scp
python-setuptools_scm
python-sphinx-gallery
python-sphinxcontrib-issuetracker
python-spur
python-terminado
python-toolz
python-traitlets
python-traitsui
python-workerpool
python-x2go
python3-Cython
python3-PyYAML
python3-coverage
python3-dbus
python3-decorator
python3-docutils
python3-idna
python3-jinja2
python3-markupsafe
python3-netaddr
python3-netifaces
python3-nose
python3-numpy
python3-ply
python3-py
python3-pycparser
python3-pycurl
python3-pygments
python3-pytest
python3-pytz
python3-requests
python3-scipy
python3-setuptools
python3-six
python3-sqlalchemy
python3-suds
python3-tornado
python3-urllib3

--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: ENOTIME

[Petr Viktorin]

On 07/20/2017 05:04 PM, Orion Poplawski wrote:

My workload at $dayjob$ has increased significantly so I'm afraid I have much
less time to devote to packaging work.  Now more than ever I could use help
maintaining my packages (listed below).  If you are interested, please add
yourself as co-maintainers in pkgdb.  Thanks!


Hello Orion!
Sorry for the late reply; I'm behind in my e-mails.

First of all, thank you very much for all your work! I knew you 
maintained a lot of Python packages, but seeing the whole list is very 
impressive.


Would you like to hand over (some of) your Python packages to the Python 
SIG?
Pagure doesn't allow groups as package owners, but I hope I can 
represent Python SIG here, at least for administrative tasks. (Among 
other things, I lead Red Hat's python-maint team, which includes many 
active Python SIGgers.)
If you add me as admin, I'll add Python SIG to the committers list, try 
to search for contributors, and handle any emergencies. (I can't promise 
we'll handle day-to-day packaging for all the packages, but some of them 
are interesting to me presonally.)


Unfortunately, in Pagure I can't request access for myself. But if you 
agree, I can file ticket with a Fedora infra for some kind of mass update.


Python packages where you're an admin seem to be:

netcdf4-python
oct2spec
pyhoca-cli
pyhoca-gui
pymongo
python-AppTools
python-Traits
python-backports_abc
python-clyent
python-cytoolz
python-ecdsa
python-envisage
python-gflags
python-google-apputils
python-iptools
python-ipython_genutils
python-jupyter_core
python-locket
python-nbformat
python-numpydoc
python-optcomplete
python-pamela
python-pkgconfig
python-process-tests
python-pycosat
python-pyface
python-pytest-cache
python-pytest-cov
python-pytest-flakes
python-pytest-pep8
python-rpm-macros
python-scp
python-setuptools_scm
python-sphinx-gallery
python-sphinxcontrib-issuetracker
python-spur
python-terminado
python-toolz
python-traitlets
python-traitsui
python-workerpool
python-x2go
python3-Cython
python3-PyYAML
python3-coverage
python3-dbus
python3-decorator
python3-docutils
python3-idna
python3-jinja2
python3-markupsafe
python3-netaddr
python3-netifaces
python3-nose
python3-numpy
python3-ply
python3-py
python3-pycparser
python3-pycurl
python3-pygments
python3-pytest
python3-pytz
python3-requests
python3-scipy
python3-setuptools
python3-six
python3-sqlalchemy
python3-suds
python3-tornado
python3-urllib3

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass package change (python2- binary package renaming)

[Petr Viktorin]

On 08/10/2017 04:52 AM, Scott Talbert wrote:

On Tue, 8 Aug 2017, Zbigniew Jędrzejewski-Szmek wrote:


Hello Fedora Python package maintainers!

This is an announcement of a mass package renaming:
Python 2 binary packages will be renamed to python2-*.

This will happen soon after the F27 branching on August 15th.


Currently ~1330 source packages already generate a binary package with
the python2- prefix, and 835 remain to be updated. The spec files for
approximately 740 packages will be renamed, and 95 will be left for
fixing by maintainers or proven packagers.

[...]
Where did your list of 'all python packages' come from?  I fear that 
there are some missing because wxPython should be in there.


I'll plan on fixing wxPython myself, but you may want to look into why 
it wasn't on the list as there may be others.


Thanks for noticing!

Unfortunately, I don't know of a good way to automatically tell if a 
package contains a Python module, or if it's an application that just 
happens to use Python.
So, if a package doesn't have an unqalified "python-" prefix (or 
postfix), it doesn't end up on the autogenerated list, and needs to be 
added manually.

Ideas for better heuristics are welcome :)

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Naming policy for application vs library packages in Python

[Petr Viktorin]

On 08/10/2017 02:49 AM, Ben Rosser wrote:

Hi,

This is following up on a brief conversation I was part of in IRC
(#fedora-devel) earlier:

I've never been quite sure how to name packages written in Python when
they are just applications. Many "applications" written in Python
still install themselves using distutils or setuptools, and so install
a "module" into the site_packages directory. By a strict
interpretation of our Python packaging guidelines [1] [2], python 3
"modules" MUST be packaged as "python3-name".

Since technically any nontrivial Python application that can be
installed via distutils or setuptools likely installs a module, this
strict interpretation of the guidelines would mean that software that
happens to be written in Python but does not intend to provide a
library must be named with the python3-* prefix.

I am not sure that this is intended (since there's definitely software
in the distribution written in Python not named with a python prefix).
If this is not intended, then it would be nice if we could reword the
guideline to be more clear.

If it is intended, I'm prepared to argue that the current guideline is
too strict and should be revisited, both from a practical position
(users looking for software called "foobar" who many not care whether
or not it's written in Python will be confused if it is packaged under
the name "python-foobar" in Fedora), and from a philosophical one (we
don't put the "lib" prefix on every library package if upstream
doesn't use that as their name because we generally try to respect the
way upstream names their software).



Hello,

You're right that this is currently missing from the guidelines. Would 
you be interested in writing up a draft change?



Python modules are a special case of "Addon Packages" [0]:

> If a new package is considered an "addon" package that
> enhances or adds a new functionality to an existing Fedora
> package without being useful on its own, its name should >
> reflect this fact.

So, if you're not extending Python, but providing a standalone app, you 
don't need to use the python3- prefix.



Specifically, the de-facto policy (which we should write down) is that 
if nothing else is expected to import the module, then don't use the 
python3- prefix. So, by not using the prefix, you're signaling that the 
Python module is an implementation detail and can be removed (or moved, 
for example to a different Python implementation) at any time.


If others *are* expected to import the module, some people make a 
"python3-foobar" sub-package, and make the main "foobar" package require it.



[0] 
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Addon_Packages




As a counter-proposal I would suggest that, as we currently do, we
require the python3-prefix to be provided by the package, but
explicitly leave it to the packager+reviewer's discretion whether or
not the prefix must be part of the real name, too. Some other
languages do already do this: nodejs [3] and ocaml [4] both explicitly
have "if this primarily provides a tool or application" clauses in
their naming guidelines. I think it makes sense to have something
similar for Python, to help avoid confusion.


That's a nice idea.

I'll note that modules installed using Python's mechanisms (setuptools, 
flit, pip, etc.) automatically provide "python3dist(name)". If we write 
new guidelines, I think we should promote that rather than the 
"python3-" prefix.


--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/29/2017 11:12 AM, Peter Robinson wrote:

On Thu, Jun 29, 2017 at 2:39 AM, Adam Williamson
<adamw...@fedoraproject.org> wrote:

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:

2) Using `python-` instead of `python2-` in the dependencies for the
Python 2 binary RPM [2].


I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.


I completely agree with Adam's sentiment here and think this is a
giant waste of time for a little bit of vanity. It's prone to errors.
I've seen and fixed numerous issues where maintainers just blanket
change/build/push without doing proper provides/obsoletes and break
things on stable releases and EL.

Most packagers have enough problems with workload without piling on a
bunch of extra unnecessary vanity bollocks that provides absolutely
ZERO value.


Sorry that all this looks useless to you!

Let me try to explain the situation:
Python 2.7 has 10-year upstream support. That's as much as enterprise 
Linux distributions, but coming from a community of volunteers, who are 
getting tired and want to move on.
That support will end in 2020. That's when the current Fedora 
maintainers of Python 2.7 plan to orphan it.
Since lots of packages Fedora depend on Python, we want to make sure 
these packages have:

- fair warning that py2 is going away
- a chance to move over as gracefully as possible.

You're free to not act on these warnings and suggestions -- all that'll 
happen is your package will have a missing dependency in a few years.


If you have a better way to manage this, please let us know!


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/29/2017 04:20 AM, Adam Williamson wrote:

On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:

On 29 June 2017 at 11:39, Adam Williamson <adamw...@fedoraproject.org> wrote:

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:

2) Using `python-` instead of `python2-` in the dependencies for the
Python 2 binary RPM [2].


I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.


This was the key concern I raised in response to the initial email,
and our conclusion at the time was:

1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available

The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:

```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over

# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif


# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```


Erf, well, that seems kinda icky but manageable. Is it really better
than just coming up with some kind of script to at least add the
appropriate "Provides: python2-foo" to all packages (or at least a
large subset of the most commonly-used packages) in EL6/EL7/F24,
though? I mean, that doesn't seem beyond the bounds of possibility, to
just find everything that provides 'python-foo' and make it also
provide 'python2-foo'...


Adding python2-foo is the second half of this proposal.
We don't want to do that by *just* adding "Provides: python2-foo" to all 
packages, because if everyone did that, we'd need to ask them to change 
again in a few years.


Would it be reasonable to do this in phases: first ask everyone to add 
python2- provides, then ask everyone to use them? Yes, and in fact, we 
already did that: the python2- prefix has been recommended in the 
guidelines for a quite a long time. But many packagers won't do the 
change until it starts being necessary.


Rebuilding lots of packages in EL6 is practically impossible, actually.
However, some subset of commonly-used packages do have the python2- 
prefixed provides even in EL6. The very example above is misleading: 
EL6's packages do provide python2-devel.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/29/2017 04:20 AM, Adam Williamson wrote:

On Thu, 2017-06-29 at 12:11 +1000, Nick Coghlan wrote:

On 29 June 2017 at 11:39, Adam Williamson <adamw...@fedoraproject.org> wrote:

On Wed, 2017-06-28 at 16:21 +0200, Iryna Shcherbina wrote:

2) Using `python-` instead of `python2-` in the dependencies for the
Python 2 binary RPM [2].


I'm not sure this list is terribly useful, because of the above. There
are thousands of packages that do this, because the 'python2-' provide
is not available on some older Fedora release, or on EPEL (and the
package is maintained for EPEL as well as Fedora). Sprinkling "if (some
release number condition) then Requires: python2-foo else Requires:
python-foo" all over your spec is a giant PITA and I for one am not
very interested in doing it.

IMHO, if there is going to be some kind of requirement that all Python
requires be explicitly versioned, there needs to be a co-ordinated
effort to make sure the versioned Provides are available across at
least EL6, EL7, and all supported Fedora releases *first*.


This was the key concern I raised in response to the initial email,
and our conclusion at the time was:

1. This case does need to be addressed
2. Adding an opaque dependency on buildroot configuration settings
wouldn't be a particularly nice way to handle it, since it forces
every package to switch concurrently, rather than each maintainer
getting to decide when to move from the Python 2 stack to the Python 3
stack for themselves (and that unilateral shift is already going to
happen for unqualified dependency declarations when the virtual
%python_provides macro moves from the Python 2 stack to the Python 3
stack)
3. Ideally, the recommended approach would work for arbitrary RHEL &
CentOS based buildroots, not just those with the EPEL RPM macros
available

The most straightforward solution we came up with was for affected
packages to define their own "%py_prefix" macro that selects the stack
they want to use based on the Python version:

```
# The block below would become the conventional
# "Python stack compatibility" dance for
# EL6, EL7, and Fedora
# Each package can decide for itself which version of
# Fedora had a sufficiently complete Py3 stack for
# them to be able to switch over

# Current EL releases & older Fedora use "python-*"
%if 0%{?el6} || 0%{?el7} || 0%{?fedora} < 25
%define py_prefix python
%if 0%{?el6} || 0%{?el7}
BuildRequires: python-devel
%else
BuildRequires: python2-devel
%endif
%else
# Newer Fedora releases use "pythonX-*"
# A Py2-only project would use "python2" here
%define py_prefix python3
BuildRequires: python3-devel
%endif


# Dependency declarations use stack selected above
BuildRequires: %{py_prefix}-builddep1
BuildRequires: %{py_prefix}-builddep2
Requires: %{py_prefix}-runtimedep1
Requires: %{py_prefix}-runtimedep2
```


Erf, well, that seems kinda icky but manageable. Is it really better
than just coming up with some kind of script to at least add the
appropriate "Provides: python2-foo" to all packages (or at least a
large subset of the most commonly-used packages) in EL6/EL7/F24,
though? I mean, that doesn't seem beyond the bounds of possibility, to
just find everything that provides 'python-foo' and make it also
provide 'python2-foo'...


Adding python2-foo is the second half of this proposal.
We don't want to do that by *just* adding "Provides: python2-foo" to all 
packages, because if everyone did that, we'd need to ask them to change 
again in a few years.


Would it be reasonable to do this in phases: first ask everyone to add 
python2- provides, then ask everyone to use them? Yes, and in fact, we 
already did that: the python2- prefix has been recommended in the 
guidelines for a quite a long time. But many packagers won't do the 
change until it starts being necessary.


Rebuilding lots of packages in EL6 is practically impossible, actually.
However, some subset of commonly-used packages do have the python2- 
prefixed provides even in EL6. The very example above is misleading: 
EL6's packages do provide python2-devel.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/20/2017 05:54 PM, Jason L Tibbitts III wrote:

"IS" == Iryna Shcherbina <ishch...@redhat.com> writes:


IS> The packages that violate the above-mentioned policies are being
IS> tracked in portingdb [3] and we plan to start filling bugs soon.

Before doing that, please post a list of packages and their maintainers
to the devel list.  Preferably you would post two lists: one in the
form:

packageowner1 owner2 owner2

And another in the form

owner  package1 package2 package3

This makes it easy for packagers to trivially see if they have any work
to do without having to wrestle with what could potentially be a large
number of bugzilla tickets which are more annoying than useful.

The message with these lists should also include reasonably complete
information about what they need to do.  Not just a pile of links,
though you should of course include links in case someone wants to read
further.

IS> Since that's a lot of bugs to file (more than 1000) , we
IS> encourage all maintainers to fix the packages they maintain.

That will go faster if you don't waste people's time filing a load bugs
and instead give people at least a couple of weeks to see their name on
a list and get things fixed up.

A few extra minutes spent generating a useful and complete report can
save a lot of time for busy packagers and potentially save some ill will
as well.


Noted.
I think this advice should be added to the wiki [0], as it really 
applies to all mass bug filings.

Iryna, could you draft a change?

Another strategy we'll be using is not filing all the bugs at once: the 
plan is to file a few at first and learn from the reactions before doing 
the next wave.



[0] https://fedoraproject.org/wiki/Mass_bug_filing

--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Petr Viktorin]

On 06/20/2017 05:54 PM, Jason L Tibbitts III wrote:

"IS" == Iryna Shcherbina <ishch...@redhat.com> writes:


IS> The packages that violate the above-mentioned policies are being
IS> tracked in portingdb [3] and we plan to start filling bugs soon.

Before doing that, please post a list of packages and their maintainers
to the devel list.  Preferably you would post two lists: one in the
form:

packageowner1 owner2 owner2

And another in the form

owner  package1 package2 package3

This makes it easy for packagers to trivially see if they have any work
to do without having to wrestle with what could potentially be a large
number of bugzilla tickets which are more annoying than useful.

The message with these lists should also include reasonably complete
information about what they need to do.  Not just a pile of links,
though you should of course include links in case someone wants to read
further.

IS> Since that's a lot of bugs to file (more than 1000) , we
IS> encourage all maintainers to fix the packages they maintain.

That will go faster if you don't waste people's time filing a load bugs
and instead give people at least a couple of weeks to see their name on
a list and get things fixed up.

A few extra minutes spent generating a useful and complete report can
save a lot of time for busy packagers and potentially save some ill will
as well.


Noted.
I think this advice should be added to the wiki [0], as it really 
applies to all mass bug filings.

Iryna, could you draft a change?

Another strategy we'll be using is not filing all the bugs at once: the 
plan is to file a few at first and learn from the reactions before doing 
the next wave.



[0] https://fedoraproject.org/wiki/Mass_bug_filing

--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self-introduction

[Petr Viktorin]

On 03/01/2017 12:39 PM, Artem Goncharov wrote:

Hello everyone,

My name is Artem and I would like to join the python-devel group.

I am a Software/Solution architect with experience in Telecom and
databases. Due to the work I never had a change to participate actively
in OS development activities, but since FC4 I am with Fedora and always
do try to test Betas on all of my workstations. So in this or other way
I am a long running contributor to Fedora community. Now the time came,
when I would participate more actively to get a different experience.

Python is just another language on my skills list. But since I have
started with it relatively recently I would like to deepen my knowledge
while doing something useful for the community.

I have started supporting Python3 port activities (reviews are still
pending ;-), but that is definitely not the only thing I will be able to
bring. I would be glad if someone will be able to review my specs and
point on problems to start bringing use sooner.


Welcome!

Could you add a link to the specs here, if you've filed bugs already? 
There's quite a large backlog of Python packages that reviewers need to 
go through, but writing here could maybe make things faster :)


Packaging/reviews is probably the best way to get into Fedora 
contributions. If you watch this list, you should see what people are 
working on, and hopefully find other opportunities to get involved.


If you need any help, be sure to let us know!


--
Petr Viktorin
___
python-devel mailing list -- python-de...@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Petr Viktorin]

On 02/07/2017 01:22 PM, Mathieu Bridon wrote:

On Tue, 2017-02-07 at 13:08 +0100, Vít Ondruch wrote:

Dne 7.2.2017 v 11:32 Michal Cyprian napsal(a):

Ruby on Fedora uses /usr/local/share/gems/ for packages installed
as a root via gem tool for many years.


Since you refer to Ruby, I just want to highlight that
/usr/local/share/gems/ is for packages installed by *root* via gem
too (as you correctly said) [1]. We assume that root manages the
entire system and wants installed packages to be available system
wide. I don't expect this is widely used practice. Typical user
installed packages goes into $HOME/.gem. Is there any location
similar to this?


Yes, under ~/.local/lib/

It's what you get with `pip install --user $module`.


As far as I know, our users very appreciate the possibility to do
"gem install" without administrator privileges.


So do Python developers. It's very commonly used.

But even more common is to use virtual environments, one per
application.

---

I strongly feel this feature is a move in the wrong direction. I've
never met a Python developer (and I'm one myself) installing modules
system-wide with Pip. It seems to me the only people doing that are
people who follow bad documentations.


Well, I've met some that are writing the bad documentation. Their 
rationale was that pip's --user option doesn't work on Ubuntu, so they 
don't have many options. (This might have been fixed since, but old 
versions are still around.)


And, not just Python developers are installing software distributed over 
PyPI.



IMHO a much better (and simpler) way to fix the (very real) issue of
unsuspecting users damaging their systems would be for pip to refuse to
run with root permissions.


I wouldn't say it's simpler, unless you also want to disable `sudo pip 
--user`.


I believe that a proper fix, which includes making --user the default, 
is planned upstream.



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: To use or not to use: packaged flask

[Petr Viktorin]

On 01/12/2017 10:44 AM, Alec Leamas wrote:

Hi out there!

I'm dipping my toes in flask, completely newbie. Doing so, I see a lot
of fedora flask packages, but no-one anywhere recommends using these -
it's all about pypi.

I "think" I prefer the packaged version, partly because I'm using
another package with native code (which, as I understand it, isn't that
easy to make a linux pypi package of). However, I'm stuck at the very
beginning:

   $  ./run_flask
   ...
   ImportError: No module named 'flask.cli'

So, my question: is it possible to run a flask application using the
packaged components similar to run_flask above, in any way? If so, how?


What is ./run_flask? Is this a script you wrote yourself?

On my Fedora 25, I can import flask.cli from the system packages just 
fine. But note that Fedora 24 has an older version of Flask packaged – 
one that doesn't include flask.cli yet.


Generally, you're better off using a virtual environment and PyPI, 
unless you're making some software specifically for Fedora.
Packages with native code aren't as much of a problem nowadays as they 
used to be, but if you still run into trouble, we'll be happy to help :)



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Making sudo pip Safe

[Petr Viktorin]

ng?


Yes, it would make a lot of sense for system-python to always behave as 
if -I was specified.



Debian deals with this by having dist-packages
(https://wiki.debian.org/Python).  Is this not worth adopting?


This diverges from upstream even more, and AFAICS the benefit it brings 
is a that if you compile Python from source with the default settings, 
it is isolated. With Python 3's built-in isolation between different 
*versions* of Python, I think there's no problem with separating 
packages installed with `sudo pip` from the system Python and from a 
Python compiled from source.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3.6, Fedora, and the "C" locale

[Petr Viktorin]

On 12/10/2016 02:56 PM, Nick Coghlan wrote:

Hi folks,

One of the minor irritations with running Python 3 applications in
Fedora containers is that those containers still default to the "C"
local by default - you have to force "C.UTF-8" or "en_US.UTF-8" in
order to tell Python that it should use UTF-8 for communicating with
system interfaces.

However, since 3.5, the CPython start-up sequence has treated claims
from the OS that it should use ASCII more skeptically, and enabled the
"surrogateescape" error handling by default on the standard streams.

Along similar lines, what do folks think of the idea of patching
Python 3.6 in Fedora to assume UTF-8 if it's told that it should use
ASCII to communicate with the OS? That changes the failure mode from
"interface problems happen any time you fail to configure your locale
correctly" to "interface problems happen any time you fail to
configure your locale correctly *and* your default locale uses an
encoding other than UTF-8".

That latter case then further breaks down into the following two situations:

- you use an ASCII-incompatible encoding like Shift-JIS or GB-18030,
in which case the old POSIX default of ASCII was already broken, and
the surrogateescape workaround in 3.5 probably didn't help much

- you use an ASCII-compatible encoding like koi8-r, which means the
surrogateescape workaround in 3.5 probably helped a bit, but libraries
like `click` would still have complained and refused to run

So I think doing this would be a nice usability improvement for users
of the system Python 3 installation on Fedora.

I also have an upstream motive for suggesting this, though: if we do
this in the more constrained environment of "Fedora users" and it
doesn't break the world, then that will help build a case for making
it the default upstream behaviour in Python 3.7.

Regards,
Nick.



+1
Handling this is on my (and thus python-maint's) TODO list, but python 
3.6, "sudo pip", and PEP 354 have higher priority for us currently.
If anyone wants to go ahead, make a patch and put it on Bugzilla, or 
draft a Fedora Change page, please go ahead!



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: [RFC] RPM's Python dependency generator

[Petr Viktorin]

On 12/01/2016 02:42 PM, Neal Gompa wrote:

On Thu, Dec 1, 2016 at 8:36 AM, Igor Gnatenko <ignate...@redhat.com> wrote:

On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava <tors...@redhat.com> wrote:

On 11/30/2016 02:44 PM, Neal Gompa wrote:


On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava <tors...@redhat.com> wrote:


I don't think the depgen should be enabled by default, at least not in
the
foreseeable future. IIRC it's not that well implemented—e.g. I believe it
doesn't read requirements.txt for example (but I might be wrong).
There will be a lot of cases where the generated requirements are
incomplete, or contain unnecessary entries, etc. I think it should remain
an
opt-in.


According to various Python people, we're not actually supposed to
read requirements.txt. That file is explicitly designed for people to
individualized deployments. The proper place to get this information
is from the egg-info/dist-info data, which is what we read. The fact
that some people abuse requirements.txt and have it read in by their
setup.py is beside the point. Whatever the setup.py (thus
pip/easy_install/etc.) says it needs, the generator will dutifully
report.



The fact remains in too many cases it will need to be manually adjusted, it
won't be foolproof.
Therefore I argue it would be better for it to be an opt-in so that new
packagers don't immediately have to jump in into debugging a depgen they
have no clue how really works.

We'll see how it will go. we have depgen for pkgconfig, libraries,
etc. for many years and people don't go and debug it immediately, but
for many of packages it will help a lot. Anyhow, we'll see after
couple of releases.

Neal suggested to have:
%__python_requires
%{_rpmconfigdir}/%{?pythondistdeps_enable:pythondistdeps.py}%{!?pythondistdeps_enable:pythondeps.sh}
--requires
in python.attr inside RPM.

I tested it and it just works once I specify `%global
pythondistdeps_enable 1` in spec. Can you help me to get this
included? With RPM part it's clear how to get this, but updating
guidelines and other stuff...


This will also drastically simplify the work of tools like pyp2rpm,
since instead of having to do crazy processing of module names, it can
just use the appropriate pypi provides/requires. If the macro template
enables the requires generator, it won't even need to specify requires
at all, as they'll be generated from the wheel data anyway.


+1, ideally that'll leave us with only one automatic dependency generator.


Problems with upstreams getting setup.py wrong should be treated as 
upstream bugs and treated accordingly: reported as pull requests, or, as 
the last resort, by a Fedora-specific patch to setup.py.



CCing Michal from the pyp2rpm project, so that everyone knows he's aware 
of the discussion here.


--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

On 10/10/2016 06:18 PM, Kevin Kofler wrote:

Charalampos Stratakis wrote:

tox is THE main reason for multiple interpreters in Fedora.

So no the comments are not contradictory but it seems there is a lack of
(technical) understanding of the actual situation here, but I may be wrong
here, so please correct me if you think so.

tox is not just any package, so maybe it is not stressed out I guess from
the original descriptions.


If no package is allowed to require the old Pythons (and IMHO, "Recommends:"
is "require"),


This is the source of the apparent contradiction. For me, "Recommends" 
and "Requires" are two different things. "Requires" means that the 
dependency is required for proper operation. In this case, that would 
usually mean the library is built for a particular version of Python.
"Recommends" means that people usually want to install the packages 
together. Specifically, "tox" is a tool for testing Python code across 
multiple Python versions. Without a few different interpreters, it would 
be useless, but no single interpreter is required for it. And since many 
people use it to test across various versions, it makes sense to install 
those by default.




that also applies to tox. If tox is allowed to recommend the
old Pythons, that invalidates the claim that they will never be dragged in
as dependencies.


Sorry for the brevity in that claim. The old Pythons should not being 
dragged in as deps, *except* for development tools specifically meant 
for testing on alternate Pythons, where "alternate" almost always means 
"old".



In an earlier mail:
On 10/10/2016 04:14 PM, Kevin Kofler wrote:

Petr Viktorin wrote:

I would also like to point out that if you have these suffixed Python
versions installed, some build scripts may be accidentally picking up
those instead of the recommended default versions of Python.


Do you mean Fedora build scripts here?


I mean build scripts in upstream tarballs, which can also end up in our
packages (and cause problems when building outside of mock), but which can
also be used directly by people.



Okay, let's go back to the use case here: a developer wants to test on 
various versions of Python. If that's not the case, they wouldn't 
install tox, since tox is a tool that only tests code on various 
versions of Python.


The alternative to packaging those Pythons in Fedora is putting them in 
some COPR. I believe this would send a bad message. If we want to make 
Fedora friendly for Python developers, we should make cross-version 
testing officially supported, and as easy as possible. "Bring your own 
Python from somewhere" does not give Fedora any advantage over any other OS.
But either way, main repos or COPR, if a developer wants to test against 
multiple Pythons and follows the recommended steps, the old Pythons 
might get picked up by build scripts. I don't see an alternative that 
would prevent this.



The alternative to Recommending lots of Python versions from Tox is 
letting people install them manually. This, again, makes the experience 
worse – people just want to start testing, and we want them to be able 
to do that by just installing the testing tool and running it.




--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

I'd like to apologize for the wording "No security fixes will be 
applied". It was meant as a warning to users who might install the 
package without knowing what it is for, not as a declaration that we 
won't maintain the package properly.


The "python26" package is meant to provide just that -- Python 2.6, as 
it was released and as it is present in various old environments. People 
that develop backwards-compatible libraries need to test against this 
version, and to make Fedora compelling for those developers, we want to 
make it as easy as possible to test the backwards compatibility.


This version is no longer supported upstream, so there aren't many eyes 
on it. It shouldn't be held to the same standards as the current Python 
versions, but since it is still in use, bugs still sometimes get found 
and security fixes will get applied. We do intend to maintain the 
package according to Fedora standards -- as far as there are standards 
for packages with inactive upstreams.


This conversation builds on discussions all the way back to Flock, and 
some details were elided or worded inappropriately in the recent 
messages. I'd like to invite everyone to take a deep breath, try to 
understand the intent, and ask for clarifications rather than forming 
assumptions.




--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Petr Viktorin]

On 10/09/2016 05:39 PM, Kevin Kofler wrote:

Nick Coghlan wrote:

They're not unnecessary for Python developers, as if you want to make
sure you're not accidentally using any features from later versions of
Python, the only way to reliably check that is to actually test your
code on those older versions. Tools like "tox" make that relatively
easy to do, but you still need a straightforward way to get hold of
the old runtimes for tox to use. The addition of these packages to
Fedora means that as soon as you do "dnf install tox", those runtimes
are all brought in automatically via Recommends, rather than having to
jump through multiple hoops to reconfigure your local package
management.


That contradicts churchyard's claim in the FESCo tracker:
| These packages are not intended to be used as dependencies for other
| packages (such as we have some "compat" packages when another package
| needs an older version of a library), hence we want to stop people from
| requiring them, see ​https://fedorahosted.org/fpc/ticket/650 - as a result
| no software in Fedora will ever run on those.


Indeed, there's a disconnect here. The old Pythons are intended for 
*upstream* development/testing.


If you're developing for Fedora, the old Pythons are not for you.
They're for people who are developing cross-platform libraries, which 
for some reason need backwards compatibility: usually for deployment 
elsewhere (old RHEL, old Debian – I've even seen people that need an old 
Python for Symbian phones, though that's older than we can support in 
Fedora).
And if you're developing a cross-platform library, you don't *want* your 
dependencies to come form RPMs. They need to be installable from PyPI 
(the Python-specific package repository) so you can use them on any distro.
So, the older Pythons should come with virtualenv & Pip, but a RPM 
ecosystem around them would be useless.


The people this is for want to develop compatible libraries for Python. 
They don't really care for the OS underneath. But having the old Pythons 
easily installable provides an incentive for them to choose Fedora.


The resulting upstream libraries can then be packaged as RPMs with 
Fedora's normal Python.




I would also like to point out that if you have these suffixed Python
versions installed, some build scripts may be accidentally picking up those
instead of the recommended default versions of Python.


Do you mean Fedora build scripts here?


--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python (3) packaging for EPEL 7: hddfancontrol

[Petr Viktorin]

On 09/23/2016 02:12 AM, Ben Rosser wrote:

Hello,

I just packaged and built hddfancontrol
(https://github.com/desbma/hddfancontrol) for Fedora, which is written
in Python 3.

I'd like to get this built for EPEL-- the machine that I want to run it
on is actually a CentOS 7 box. However, there's a problem: it depends on
python-daemon, which only gained python3 support in version 2.0 The EPEL
package provides version 1.6.

So, obviously I can build this in a Copr if I really want, alongside an
updated python-daemon package. However, there is a fork of python-daemon
1.x, python-daemon-3K
(https://pypi.python.org/pypi/python-daemon-3K/1.5.8), that supports
Python 3. Upstream hddfancontrol actually depends on this version of
python-daemon, so for Fedora I had to patch it to use python-daemon 2.0
instead.

So perhaps it would make sense to package python-daemon-3K just for EPEL
and have it provide python3*-daemon? Is that a reasonable course of
action here? Any other suggestions besides just using Copr?


Hello,
Have you contacted the EPEL maintainers of python-daemon? I think those 
are the people that will give you the best advice around python-daemon 
in EPEL.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

fedoralovespython.org

[Petr Viktorin]

Hello!

Some time ago, at Flock, a couple of us had the idea to better promote 
Fedora's Python story. Currently we have the "Python Features" section 
on the Wiki [0][1], but the target audience there is the Python SIG 
itself – people who work on the integration, not those who "just" use 
Python. There's also the Python Brochure [2], which looks quite nice but 
the content is ... well, not very useful for developers.


In my experience (with portingdb), a bit of HTML and CSS can go a long 
way towards getting people interested. So we started writing down some 
developer-focused Python talking points:


https://fedoralovespython.org/

And here's a preview with points that aren't ready for prime time yet:

https://fedoralovespython.org/__future__/

The points there are just headlines with links to more information – 
mostly to the Fedora Developer Portal. A lot of the effort in the 
"fedoralovespython.org project" should go into improving the Developer 
Portal content [3][4][5]. The guides there can help people get started, 
but should also help *us* check that getting started is as easy as it 
can be :)


If you want to help out, the repo is public: 
https://github.com/fedora-python/fedoralovespython.org


The page isn't publicly announced yet. Until it has some more content, 
please don't market it to people who wouldn't interested in it as a 
Python SIG project.



[0] https://fedoraproject.org/wiki/SIGs/Python#Python_Features
[1] 
https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python#Python_Features

[2] https://fedoraproject.org/wiki/Marketing/Python_brochure

[3] https://github.com/developer-portal/content/pull/159
[4] https://github.com/developer-portal/content/pull/156
[5] https://github.com/developer-portal/content/pull/158

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

Re: PEP: Distributing a Subset of the Standard Library

[Petr Viktorin]

On 09/06/2016 08:25 PM, Nick Coghlan wrote:

On 7 September 2016 at 02:41, Tomas Orsava <tors...@redhat.com> wrote:

Hi!

I'm currently writing a PEP titled "Distributing a Subset of the Standard
Library" to standardize and hopefully improve the behavior of Python without
the its full standard library. This is relevant to Fedora, as we exclude
several standard library modules into separate optional packages (e.g.
python3-tkinter).

I have a draft of the first two sections: Motivation and Specification.
https://fedora-python.github.io/pep-drafts/pep-A.html


Very interesting, although I see a pragmatic problem with trying to
check for explicitly missing packages only after checking for the
standard library ones: the default import system doesn't make a clear
distinction as to which sys.path entries refer to the standard library
and which refer to other directories (like site-packages), so you
can't readily intercept processing after the standard library is
checked but before the rest of sys.path is processed.


Distinstion between stdlib and not-stdlib is not what's being solved here.

Within each sys.path entry, these suffixes are checked, in order:
>>> importlib.machinery.all_suffixes()
['.py', '.pyc', '.cpython-35m-x86_64-linux-gnu.so', '.abi3.so', '.so']

The proposal is to put '.missing.py' at the end, so if neither '.py' nor 
'.so' is found in that particular directory (or before it on sys.path), 
'.missing.py' raises ImportError.


The idea is to use it for stdlib directories. These come before 
site-packages, so overrides in site-packages would be blocked (as they 
should be, since they wouldn't be compatible with a "complete" install 
of Python).


If someone finds a use case for putting '.missing.py' markers elsewhere, 
all the power to them :)



However, sys.meta_path *does* let you explicitly block imports before
the default machinery is tried by raising ImportError from find_spec:
https://docs.python.org/3/reference/import.html#the-meta-path

Now, I'm making the assumption that what we need is a model whereby
the base install includes files that tells Python "these stdlib pieces
might be missing", and then the other packages can install files that
mean those "these pieces are missing" markers don't get processed.


The goal is mainly to provide good error messages when a piece of stdlib 
is missing, i.e. ImportError("run dnf install python3-tkinter to get the 
missing piece"). And to standardize how it's done, since CPython and 
Debian need this too.


I hope we can answer the "what should be in stdlib?" question with 
something more like dist info, complete with dependency information and 
environment markers for things like Unix-only modules, and separate from 
runtime.



One possible way to do that as a pre-import check injected into the
start of sys.meta_path would be to maintain a set of static
"module_name.optional" files in the standard library directory that
included:

- a relative file path to stat to indicate that the optional module is installed
- an import error message to raise if its not found


The proposal evolved from a similar idea; after that I realized an extra 
"fallback file" in the stdlib directory is enough.



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

Re: PEP: Distributing a Subset of the Standard Library

[Petr Viktorin]

On 09/06/2016 06:46 PM, Neal Gompa wrote:

On Tue, Sep 6, 2016 at 12:41 PM, Tomas Orsava <tors...@redhat.com> wrote:

Hi!

I'm currently writing a PEP titled "Distributing a Subset of the Standard
Library" to standardize and hopefully improve the behavior of Python without
the its full standard library. This is relevant to Fedora, as we exclude
several standard library modules into separate optional packages (e.g.
python3-tkinter).

I have a draft of the first two sections: Motivation and Specification.
https://fedora-python.github.io/pep-drafts/pep-A.html

The source can be found here: https://github.com/fedora-python/pep-drafts


Why doesn't Python offer dist data indicating the modules that are
included in the standard library? That way there doesn't need to be
much special handling to support whether it's an external package or a
standard library module. Things like dependency generators can pick
this up properly.


Python does not have dependency generators. Dependendency information is 
added to "setup.py" files, manually.
Even if you got Python to start providing dist data for stdlib packages, 
you would still need to convince the developers of all Python modules to 
use that info in their packages.


The discussion linked in the PEP draft contains lots of info about the 
status quo and opinions of Python core developers.



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

Re: Renaming python to python2

[Petr Viktorin]

On 09/01/2016 01:44 PM, Nick Coghlan wrote:

For /usr/bin/python, we had an upstream discussion about that at the
2015 language summit: https://lwn.net/Articles/640296/


Whatever we do, I'd like it to be coordinated across multiple 
distrubutions, and blesed by a PEP like [PEP 394]. We don't want a 
solution specific to Fedora.
Unless you don't agree with that, a good place to discuss these issues 
it Python's [linux-sig].



Now, the names of Fedora's packages are a different thing – I agree that 
"python" should be renamed to "python2".



[PEP 394]: https://www.python.org/dev/peps/pep-0394/
[linux-sig]: https://mail.python.org/mailman/listinfo/linux-sig

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

Re: Automatic Provides: Discussion summary and plan

[Petr Viktorin]

On 08/17/2016 06:52 PM, Nick Coghlan wrote:

On 15 August 2016 at 19:42, Igor Gnatenko <ignate...@redhat.com> wrote:

It can't track/change BR/R's as RPM is Turing complete and impossible to parse.
Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
Fedora we still need to add some more BR for that, so we add it. When
new release comes (still without added BR in upstream) rebase-helper
will not be helpful. It can change only version of spec.


This is a self-inflicted problem arising from our current tooling
design, though, since "generate-and-edit" isn't the only way to
supplement upstream metadata: we can also design spec file generators
to accept a supplemental config file in addition to the upstream
metadata.

If we're using that alternate model, then rebase-helper can have a
much easier time of things, since it isn't trying to edit a previously
generated spec file, it's just generating a new one based on the new
upstream metadata and the old supplemental metadata, and seeing if the
result still passes CI.


The more I think about it, the more it seems to me that our plan should be:
- Make it possible for pyp2rpm to use extra data to augment/override 
what's in the upstream package.
- Make it standard practice in Fedora to use this data and treat the 
spec file as an immutable generated artifact.
- Treat metadata errors/omissions as upstream bugs, provided the desired 
state can be expressed in setup.py
- For kinds of metadata that setup.py can't express, strive to add them 
to future versions of the upstream packaging format.
- For the far future, perhaps start getting rid of spec files: teach 
Koji to generate them, and stop storing them in dist-git.



Helper macros stay orthogonal -- pyp2rpm would just need to learn to use 
them.



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

Re: Python 3.4 for Fedora 24+

[Petr Viktorin]

On 08/18/2016 09:04 AM, Miro Hrončok wrote:

On 17.8.2016 19:04, Nick Coghlan wrote:

[...]


Nice! Would it make sense for us to have a "tox" section in the
sidebar at
https://developer.fedoraproject.org/tech/languages/python/python-installation.html

that covers using these COPR builds with tox for cross-version
testing?


It would. My long term plan here actually is to put this in Fedora
proper and make tox Recommend all the Pythons, so you could just dnf
install tox and it would bring all the runtimes (and you could prevent
it if you didn't want (actually I have no idea if we ahve some
--without-recommends flag for dnf, but anyway...)).


As a note to anyone interested in alternate versions: The Guidelines 
were recently changed, so the Fedora review should be easier than expected.


I find the new wording ambiguous, so I'd like to follow as much of the 
process as practical, but it should prevent an eager reviewer from 
nitpicking 10-year-old specfile warts in python-2.6. I'd rather focus 
spec cleanup efforts on python3 ;)



 Forwarded Message 
Subject: [Guidelines change] Changes to the packaging guidelines
Date: Thu, 18 Aug 2016 13:25:15 -0500
From: Jason L Tibbitts III <ti...@math.uh.edu>
Reply-To: de...@lists.fedoraproject.org
To: devel-annou...@lists.fedoraproject.org

Here are the recent changes to the packaging guidelines.

[...]

The review process document has been amended to note possible
exceptions, and to indicate that review is not needed in certain
situations where a different version of an existing package is being
added.

* 
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process

* https://fedorahosted.org/fpc/ticket/637

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

Re: [Python-SIG] Self-Introduction: Tim Orling

[Petr Viktorin]

On 08/13/2016 05:26 AM, Tim Orling wrote:

Hi all.

Somehow, between a week of vacation with my Dad and reading Miro's email
for the third or fourth time I have come to an epiphany...

Let us clean the slate and start over. Light some cedar and sandalwood
incense. Assume the lotus pose and clang your finger symbols. Breathe
deep. Think good thoughts. Life is good.

---

Hi. I'm Tim, although I prefer to be known as "Timo (Teem-OH)".


Hi Timo! Welcome!

Could you put your preferred name in your e-mail signature? At least 
that's where I look for proper spelling of people's names :)



I've
been using Fedora since before it was called Fedora Core. I care a lot
about __quality__ python packaging in Fedora, in part because my job
depends on it working flawlessly, but also because I just think python
is an awesome language. I evangelize about it to anybody that will
listen. I am responsible for Fedora working flawlessly for my global
team and our larger community (in which many many people prefer to use
Fedora). This can be "fun" when new Fedora releases come out. gcc-6 by
default for example. It usually takes a week or two of somebody's time
(now mine) to get it all working ok again. All of our build tools are
based on python. We recently finished our migration to python3 which
makes me very happy.


Congratulations!


I have a couple python projects I'd like to contribute to Fedora. The
two that come to mind are rethinkdb and robotframework (which will be
many sub-packages as well). Maybe I'll come up with more.


What's the status of rethinkdb and robotframework? Can we help getting 
these in?



I am an active
member of the IronPython community and perhaps that means I can help
with mono support in Fedora.


That sounds interesting! I admit I don't know much about IronPython. 
Would you care elaborating a bit on your plans regarding IronPython in 
Fedora?



In particular, I want to drive IronPython
to be python3 ready. I need to learn how to become an __expert__ python
packager for Fedora.  I also want to help with the inevitable fires that
come up. I read the mailing list daily (hourly?) and get all the
notifications about python packages in Fedora. I guess I don't know
where to start helping effectively.


Helping effectively depends a lot on your area of interest. How do *you* 
want to make Fedora better?

Packaging rethinkdb/robotframework seems like it would be a good start.

Then there are always things others would like help with in their quest 
to make Fedora better. For example, in the Python 3 effort, there's a 
tracking bug for cases where the packager doesn't have time to do the 
Python3 port. Some of the bugs there need expert skills, for some it's 
just that the packager doesn't have time:

https://bugzilla.redhat.com/show_bug.cgi?id=1333765
If you'd just like to help others but don't know where to start, this 
list is a good place to ask.


As for the inevitable fires, unless it's an embargoed security issues 
there should be a public bug on Bugzilla, and usually a flurry of 
activity on this list or IRC. See the recent majorver-provides 
discussion for example.



I'm hoping to work with the members of python-sig to learn the ropes and
join the team. I am not just curious, I am determined. Driven even. I
would like to take that energy and apply it to python-sig. I look
forward to getting to know you all and working for a long time with you.


Welcome to the Python SIG!



Cheers.

--Tim

P.S. I'm not sure who this email will actually reach, so please forward
to the right list if you have permissions. I'm not going to clutter
python-dev with it anymore. No more negative energy. Life is good.


Well, python-devel is the right list for this post. Sorry for the 
misunderstandings earlier.




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

Re: Automatic Provides: Discussion summary and plan

[Petr Viktorin]

On 08/12/2016 03:17 PM, Jason L Tibbitts III wrote:

"PV" == Petr Viktorin <pvikt...@redhat.com> writes:


PV> The magic worries me. It seems like if these macros were finished,
PV> you'd be about the only person capable of maintaining them.

I don't think so.  There are other committers, and the core of it didn't
even come from me so there's certainly at least two other people around
who can handle this stuff.  It's true that not a whole lot of people
understand the deeper interactions between the RPM Lua interpreter and
the rest of RPM, but it took me only about two days to figure out most
of it _without_ having any documented examples.  And I have a real job
that isn't Fedora.


Thanks for clearing that up, I'm less worried now.


The macros are very well commented; the magic is described in detail.
They also include a debugging framework.  Which is more than, well, any
other current macro magic.  Ever tried to debug debuginfo package
generation?  Or even looked at the SCL macros?  (Which are about on par
with magic-ness, but which are completely unreadable and have no
debugging.)


The macros are definitely of exceptional quality. But, still they're RPM 
macros.
(Yes, I have looked SCL macros – that's something I'd not encourage 
people to study...)



PV> And if something goes wrong (magic tends to imply fragility), I'm
PV> not looking forward to the debugging sessions. So, while I am blown
PV> away by this project, I'm inclined to place my bets on pyp2rpm
PV> instead.

Well, there's no reason not to have more than one solution.  However,
pyp2rpm just gets you a spec.  You still have to maintain said spec, and
wiping it out with a fresh run of the generator is not really
acceptable.  I'd generally argue that pyp2rpm would actually generate a
spec using this stuff, once it's actually proven that it works.


The idea with pyp2rpm is to work with the Python Packaging Authority so 
that the upstream metadata *can* be converted automatically. Ideally 
Fedora packagers would fix packaging problems upstream, rather than 
maintaining spec files.

Ideas for a tool for *updating* spec files are also floating around.

The idea of pyp2rpm generating spec files using the macros sounds good. 
Indeed the projects are more orthogonal than I realized.



I would still like to have the spec file be simply an intermediary
between some metadata and the build system.  Or, if you can write
pyp2rpm in lua, I could actually build it directly into rpm.  Have the
regular RPM header, then a %prep section that unpacks the source and
calls a macro.  The rest of the spec (except the %changelog section) is
simply generated from the metadata.


Agreed; it would be nice to get to that kind of situation in the future. 
Not sure about the lua part, at least while pyp2rpm needs heavy 
development :)


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

Re: Automatic Provides: Discussion summary and plan

[Petr Viktorin]

On 08/11/2016 07:37 PM, Jason L Tibbitts III wrote:

"TO" == Tomas Orsava <tors...@redhat.com> writes:


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

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

TO> Maybe it could be revived?

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

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

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


The magic worries me. It seems like if these macros were finished, you'd 
be about the only person capable of maintaining them. And if something 
goes wrong (magic tends to imply fragility), I'm not looking forward to 
the debugging sessions. So, while I am blown away by this project, I'm 
inclined to place my bets on pyp2rpm instead.


I don't think the end goals – not having to write a spec at all, or 
write an ideal spec – are as important as the debugging experience.


But, that's all just my view; I have no intentions of hindering the 
project, and I encourage anyone involved with RPM macros to study it and 
see what's possible.



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

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

[Petr Viktorin]

On 08/11/2016 04:03 PM, Justin W. Flory wrote:

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

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



[...]


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

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


Yes, that would be amazing! Thanks for offering to do that!


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

Python 3 porting: 50% done in Rawhide 

[Petr Viktorin]

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



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


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


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



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


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


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



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

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

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

Automatic Provides: Discussion summary and plan

[Petr Viktorin]

To help automatic building RPMs from native Python packages, we need an
automatic way to record the software's upstream name (dist name, name
on PyPI) in Fedora packages.

For this, we are using RPM's automatic dependency generator written by
Per Øyvind Karlsen and Neal Gompa, which automatically scans
".dist-info" and similar files and generates virtual Provides,
currently in the form "pythonX.Ydist(name)".
(The generator was originally developed for Mandriva and Mageia; finally
it's coming to Fedora as well!)
The Fedora Change page for this feature is here:
https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages

Unfortunately, while implementing this, we failed to understand how the
virtual provides work with source RPMs. This leads to the situation
that, as currently planned, the automatic provides are only useful in
"Requires" lines, not in "BuildRequires".

The problem is that if a requirement like "python3.5dist(name)" is
present in a SRPM, the SRPM can't be rebuilt on systems with other
Python versions, which would provide, say, "python3.6dist(name)".
For these systems, the SRPM would need to be rebuilt, which not all
tools do.

Igor Gnatenko (ignatenkobrain) explained this on IRC on #fedora-python,
after which we had a long discussion about the problem and possible
solutions. We're sorry for not getting this earlier -- despite several
people mentioning it (including Neal who wrote the generator)!


The fix is to enable "--majorver-provides" in the dependency generator,
so that each package will provide two forms of the virtual provide:
python3.5dist(name)
python3dist(name)
The full version should then be used for runtime Requires, while the
one with major version only should be used for BuildRequires.

We'll wrap this up in easy-to use (and hopefully future-proof) macros:

* One macro for getting the canonical (normalized) dist-name:
%{python_dist_name NAME}

* Four macros for adding Requires and BuildRequires lines (which use the
  python_dist_name macro above):

  %{requires_python3_dist NAME} => Requires: python3.Ydist(name)
  %{buildrequires_python3_dist NAME} => BuildRequires: python3dist(name)
  and similarly for Python 2.

An alternative would be macros that don't include the keyword "Requires:" or
"BuildRequires:". This would result in specfiles with lines like:
BuildRequires: %{python3_dist_br name}
Requires: %{python3_dist name}
This would be susceptible to people copying the Requires line, adding
"Build" to the front, and forgetting to change the macro as well,
leading to a hard-to-catch failure (working binary RPMs but SRPMs that
fail to rebuild on other distro versions).
Macros that include the keyword are more robust to copy-pasting.

Since the %buildrequires_python3_dist and %python_dist_name macros will
be used in the SRPM, they'll need to go in macros.python-srpm to be
present in the default buildroot.
The %requires_python3_dist macro (and %pythonX_version) can live in
macros.pythonX.


Following is the new road plan:


# Plan for Fedora 25:
* The 5 macros will be created and deployed.
* The --majorver-provides swich for the Provides generator in Fedora RPM 
will

  be enabled
* Fedora Packaging Guidelines for Python will be amended:
* The addition of the pythonX.Ydist(..) tags will be explained.
* The %{python_dist_name} macro will be advertised.
* The %{requires_pythonX_dist} macros will be advertised for use in
  generating Requires tags.
* It will be explained that, at this time, it is impossible to
  generate BuildRequires without the providing package being
  rebuilt, so the %{buildrequires_pythonX_dist} macros will be
  discouraged for now.
* See if we can get in another targeted mass rebuild. If yes, continue
  with the f26 plan early.


# Plan for Fedora 26:
* All Provides will be regenerated in the regular Fedora 26 mass rebuild
* Change Python guidelines so the %{buildrequires_pythonX_dist} macros
  are now encouraged.


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

Re: [Python-SIG] Self-Introduction: Tim Orling

[Petr Viktorin]

Hello Tim! Welcome to python-devel, and sorry for us being so quiet.

Is there anything in particular you're pinging about?

If want to access the python-sig FAS group, note that an introduction 
here is just a part of the process [0]. However, that list is mostly 
used to get notifications about bugs in various Python packages (so it 
might not be for you), and it gets security-related information (so not 
everyone who applies is accepted, but I don't know the details there). 
For general discussions there is this list, so you can already participate.



[0] https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group

On 07/11/2016 10:41 PM, Tim Orling wrote:

Ping. Again.

On Thu, May 12, 2016 at 9:32 PM, Tim Orling <ticot...@gmail.com
<mailto:ticot...@gmail.com>> wrote:

Ping.

On Fri, Apr 29, 2016 at 6:56 AM, Tim Orling <ticot...@gmail.com
<mailto:ticot...@gmail.com>> wrote:

Greetings,

I recently became a co-maintainer for pystatgrab [1] and am a
contributor to upstream [2]. I am a co-founder and co-maintainer
of the meta-python [3] and meta-maker [4] layers for
OpenEmbedded. I am also a contributor to IronPython [5] and
RobotFramework [6].

In my professional life, I work for the Intel Open Technology
Center on the Yocto Project, which depends heavily on Python for
its tools and infrastructure.

[1] https://admin.fedoraproject.org/pkgdb/package/rpms/pystatgrab/
[2] https://github.com/i-scream/pystatgrab/graphs/contributors
[3] 
https://layers.openembedded.org/layerindex/branch/master/layer/meta-python/
[4] 
https://layers.openembedded.org/layerindex/branch/master/layer/meta-maker/
[5] https://github.com/orgs/IronLanguages/people
[6] https://github.com/robotframework/robotframework/graphs/contributors




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

Re: Reg- binclock porting from python 2 to python 3

[Petr Viktorin]

On 06/02/2016 10:25 AM, Rajeshkumar Pothiappan wrote:
> Thanks Charalampos Stratakis, 
> I would like to package 
> http://fedora.portingdb.xyz/pkg/python-fsmonitor/
> yograterol is maintaining that package.
> How to contact yograterol ?
> Can i use yograte...@fedoraproject.org or any other way? 

Hi Rajeshkumar,
Since the project has a Bugzilla bug open, it would be best to ask for
status and/or offer help there:
https://bugzilla.redhat.com/show_bug.cgi?id=1312340
You can check "Need additional information" from the maintainer.
The maintainer should get e-mails for all comments there. If he doesn't
respond in a week or so, you can either:
- write the patch anyway, and ask a provenpackager to review and push it
- (more officially) follow the Non-responsive Maintainer Policy [0] and
take over the package


[0]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

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

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/10/2016 07:35 PM, Josh Boyer wrote:
> On Wed, Feb 10, 2016 at 1:26 PM, Bill Nottingham <nott...@splat.cc> wrote:
>> Miro Hrončok (mhron...@redhat.com) said:
>>> I had this in mind as well, but currently, this is not the part of the
>>> change. Once we need this and we have system-python, we can propose a
>>> system wide change that system-python is a different version.
>>
>> ... is the goal that the system-python is outside of $PATH and has a
>> non-standard $PYTHONPATH as well?  That would seem to be where this is
>> heading.

Having it outside $PATH is a good idea, I think. But $PYTHONPATH can be
shared (if the system-python version matches the /usr/bin/python3
version, which it should, at least most of the time).


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/09/2016 08:26 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 08, 2016 at 08:27:53AM +0100, Jan Kurik wrote:
>> = Proposed Self Contained Change: System Python =
>> https://fedoraproject.org/wiki/Changes/System_Python
>>
>> Change owner(s):
>> * Miro Hrončok 
>> * Petr Viktorin
>> * Robert Kuska
>> * Charalampos Stratakis
>>
>> Separate several subpackages form the python3 packages - a
>> system-python(-libs) that can be required by various tools that
>> consider themselves "system tools".
> 
> The part of "Python" that can be usefully split is the standard
> library, and that's where most of the size and dependencies come in.
> In principle the python binary could be trimmed down, but it's small,
> and doesn't bring in any dependencies. The proposal doesn't state it
> clearly, so I assume you only want to split the stdlib
> (system-python-libs), and providing a separate system-python package
> with a separate binary is only a means to differentiate dependencies.

Indeed, the Python binary is very small, since it just calls python-libs.*
The binary needs to be separate to ensure /usr/bin/python? will always
refer to the full installation of Python**, and system-python is there
only for things that opt in.

> My first issue is that system-python{,-libs} is basically a
> subpackage, and should be called python-.

python- is also the naming scheme for Python libraries, which
this is not. So I don't think the naming is that clear-cut.

> And since debian
> calls it -minimal, so should we, to match existing
> expectations and increase cross-distro similarity.

That would also create the expectation that this is following Debian's
set of modules for python-minimal. While it's possible that we'll end up
with the same set, I don't want to lock us in.

> Second, why call it python-*, not python3-*? I think it'll
> be endlessly confusing to have both python*- (v3), python2-* (v2),
> and python3-* (v3) mixed in the same distro.

The assumption is that the basic system tools can agree on a single,
system-wide version of Python, and in case of a "Python 4" they can be
switched at once.
"python-*" is v2, by the way. This change adds "system-python" which is v3.

> My third issue is that packages will have a dependency on either
> system-python or normal python and this will a binary decision.
> Changing the list of things provided by system-python will be hard.
> If you add something to system-python, the only way to ensure that
> dependent packages can make use of it is to add a versioned dependencies
> on system-python. If you remove something from system-python, it will
> be necessary to go over all dependent packages and verify if they need
> the thing being removed or not. And if users' scripts start using
> system-python, it will impossible to remove anything, except maybe
> between Fedora releases.  This is very inflexible.

User scripts should not use system-python.
I now think the binary should be at /usr/libexec/system-python, to drive
that point home.

As for versioned dependencies, and removing things from a published
package -- that's how RPMs enerally work. I don't see a problem.

> As an alternative proposal, what about using an automatic dependency
> generator and having dependent packages require specific modules from
> the standard library. Those modules could then be moved between
> system-python-libs and python-libs, and things would just work™. I
> think that a separate system-python binary also wouldn't be needed.

That's a great idea, and I'm thinking along the same lines. But this
would have to be done upstream, with the wider Python community on board.
Especially with MicroPython gaining popularity, it would be great to
split the stdlib into individual chunks, record their interdependencies,
and say to library authors: "if you want to opt-in to be compatible with
minimal implementations of Python, specify which pieces of stdlib you
need, and make sure your dependencies do the same".

But, that's quite a long-term project. This Change is relatively small,
it should give us the immediate benefits, and if/when the full solution
is done it should be easy to switch to it.

> The scheme with automatic dependency generation could be implemented
> gradually, by introducing the automatic provides and dependencies
> generators, without removing current manual provides. Then when the
> generated dependencies seem to be right, removing manual dependencies.
> 
> Automatic dependency generation would benefit the whole ecosystem of
> Python packages in Fedora.

It would. It's also practically impossible to write such generators
correctly. (Please prove me wrong!)

It's even harder to write such generators for the stdlib than external
libraries, beca

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 02:13 PM, Jonathan Wakely wrote:
> On 08/02/16 08:27 +0100, Jan Kurik wrote:
>> python3 package to be split in several more subpackages:
>> * system-python-libs - a subset of standard Python library considered
>> essential to run "system tools" requiring Python
>> * system-python - /usr/bin/system-python binary (interpreter) for the
>> tools to be able to run, provides system-python(abi)
>> * python3-libs brings in the remaining subset of standard Python
>> library and will require system-python-libs, thus packages requiring
>> it (directly or indirectly) will get the entire standard Python
>> library
>> * python3 still requires python3-libs and provides python(abi)
>>
>> The term "system tool" in this context means any package where a
>> maintainer wishes to require system-python package instead of python3
>> package.
> 
> I'm not opposed to this change (I don't have an opinion) but this
> seems like an almost circular definition.
> 
> system-python-libs is defined as "whatever system tools want to use"
> and "system tools" are defined as "anything that uses system-python".
> 
> So I could create a package that uses system-python, but requires some
> large or obscure piece of the Python standard library, and then insist
> that it is added to system-python-libs. The definitions should prevent
> that.

Right, currently all we have is the circular definition.
The first step (listed under "Scope") is defining what
system-python-libs will contain. Once that's done, it'll be much harder
to add obscure libraries.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 09:21 AM, Neal Gompa wrote:
> On Mon, Feb 8, 2016 at 2:37 AM, Florian Weimer <fwei...@redhat.com> wrote:
>> On 02/08/2016 08:27 AM, Jan Kurik wrote:
>>> = Proposed Self Contained Change: System Python =
>>> https://fedoraproject.org/wiki/Changes/System_Python
>>
>> Is this intended to mirror Debian's python-minimal?

Not necessarily, thought if the subset is similar we might re-use it.

>> What steps have been taken to accommodate Python upstream's wishes
>> against creating subsets of the standard distribution?  If I recall
>> correctly, this was a major point of discussion when Debian introduced
>> python-minimal.

The system-python is not a general-purpose Python interpreter. It should
only be called from programs that explicitly opt in to it.
Perhaps is should be /usr/libexec/system-python rather than
/usr/bin/system-python, to drive the idea home.

> This sounds like a really bad idea. How do we know what to expect is
> provided in a given Python package?

Part of the change is defining the exact subset. The idea is that it
should be small, to keep cloud images small for apps that don't use
Python themselves.

> We don't currently have anything
> that creates package-independent virtual Provides/Requires of Python
> modules that would cover the scope necessary to make this more
> effective.

Right. Every package using system-python would need to explicitly
disable the automatic Python requires, and add the system-python ones.

> Technically, there is one for independent Python module packages
> coming in RPM upstream that is currently disabled by default (in fact,
> I've got a pull request to improve it based on feedback from the
> Python SIG as well as Mageia[1]), but I don't think that is currently
> designed to handle the kind of complexity this is going to introduce.
> 
> How in the world would we handle such a dramatic departure from how we
> currently package Python?

It's a change designed for a few system tools that can accept the
limitations.  we can make Python-less containers and cloud images
smaller. Normal Python packages would be unaffected.
So I don't think it's a dramatic departure.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Proposed Mass Bug Filing: Python 3 Porting

[Petr Viktorin]

Hello!

According to the Python packaging guidelines [*], software must be
packaged for Python 3 if upstream supports it. I would like to start
filing some cookie-cutter bugs [**] where that's not the case, or where
there are some common problems with the Python 3 porting.

Some people have already started doing this, especially during the
Fedora Activity Day (FAD) [***], but some of the bugs filed could be
clearer. Hopefully, going through the mass bug filing procedure will
raise the quality of these bug reports, and provide a single place to
track them.
This also means I don't have a list of packages this mass filing applies
to: usually where the issue is known, a bug was already filed. But many
more are surely left to report. Rumor has it that the next FAD is
already being planned; it would be nice to be ready for mass filing at
least by then.

Several different issues related to this are appearing in the wild. I'd
like to put them all under this umbrella, and I'm including bug report
text for each one below.

[*] https://fedoraproject.org/wiki/Packaging:Python
[**] https://fedoraproject.org/wiki/Mass_bug_filing
[***] https://fedoraproject.org/wiki/FAD_Python_3_Porting_2015


Proposed "Python 3 Porting Tracking bug" description:

"""
Bugs related to the Python 3 porting effort are tracked here. These are:

* No py3 subpackage where upstream supports py3
* No python2-* or python-* Provides
* Requires on both py2 and py3 in one RPM

Mass bug filing was discussed in  and announced in 

Python packaging guidelines: https://fedoraproject.org/wiki/Packaging:Python
"""


Proposed child bug titles and texts:

1. : Provide a Python 3 subpackage

"""
Upstream, this software supports for Python 3. Please provide a Python 3
package for Fedora.


According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
"""


2. : Missing "python2-" provide

"""
This package does not provide "python2-".

As per Python packaging guidelines [0], when there are two versions of
module "foo", the two packages must provide:
"python3-foo" for Python 3
"python2-foo" for Python 2
"python-foo" for the system default Python (currently 2, but this might
change in the future)

Please use the %python_provide macro [1] to specify the correct provides.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance with this
issue, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1]
https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro
"""


3. : Missing "python-" provide

(as for 2., s/python2-/python-/ where necessary)


4. :  requires both Python 2 and Python 3

"""
The  RPM requires both Python 2 and Python 3.

Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Usually, this is a packaging error: for
example, a stray "/usr/bin/python" shebang in a Python 3 package can
introduce a Python 2 dependency.

Please split your package, or remove the stray dependencies.

It's fine to do this in Rawhide only.


If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!
"""


-- 
Petr Viktorin
-- 
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

[Petr Viktorin]

On 01/28/2015 06:08 PM, Dan Williams wrote:

On Wed, 2015-01-28 at 11:09 -0500, Bohuslav Kabrda 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:


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.


How about #!/usr/bin/env python?  I don't recall who suggested this a
long time ago, but I'm 99% sure it was to better handle python3...


That does *not* handle Python 3 for you. In Fedora 22, /usr/bin/python 
will still point to Python 2 [0], so this would (normally) still call 
Python 2.


What /usr/bin/env does is take $PATH into account – for example if you 
have a virtualenv activated, it would use the python from that 
virtualenv. For applications that are installed as part of the system, 
this is almost never what you want.



[0] 
http://fedoraproject.org/wiki/Changes/Python_3_as_Default#User_Experience


--
Petr Viktorin

--
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/19/2014 09:11 AM, Benjamin Kerensa wrote:

Hello Free Software Friends,


I want to encourage the Fedora Community to think carefully about making
a switch
to another browser as the default in Fedora. I would not get hung up on
these tiles
(Ads) too much and remember they are necessary in order for Mozilla to
continue
building Firefox, Thunderbird, Seamonkey, Firefox OS and supporting the
very literally
hundreds of movements and thousands of events it does each year.

But that all aside I hope you will weigh whether the alternatives will
provider your users
any better of an experience in terms of Stability, Performance, Privacy
or Trust.

I think it will be difficult to find an alternative that offers what
Firefox does to your
users and frankly I think you will have a fair amount of users that will
be upset that
you switched the default on them. Sure they can still install Firefox
but the fact is
Fedora users come to expect Firefox to be the default much like they
expect Gnome
to be the default. (Also remember there are very likely thousands of
Mozilla Contributors that use Fedora)


In other words: you have achieved have vendor lock-in.
Congratulations! Good for you. Not so good for me.


Whatever your decision have a good release cycle and keep on building that
awesome free software!


Free software is, and always has been, about users. If something does 
not benefit the users should be able to switch away – where something 
is not whole applications, but individual *features* of applications.


Compare, for example, to the ad-ridden, spy-heavy, vendor-locked-in 
Android ecosystem, where users can't turn off unwanted features. Most 
software there is written to benefit the *developers*, not the *users*. 
Sure, it is more profitable for them that way, and the terms of some of 
those apps are even acceptable. But the fact that this model is finding 
its way into free software is worrying at best.


I think the line we should not cross is: including features that don't 
benefit the user and may be considered harmful. If I opt-in to ads – if 
you politely ask, and I, with mutual respect and understanding, agree to 
help your cause – then it's perfectly fine. (See vim's Help kids in 
Uganda message.) If you just quietly make money off me, or distract and 
annoy me until I have paid, then I can't and will not respect you.


It's not about tracking per se – I'm fine with e.g. opt-in usage reports 
that feed into research for making a better browser – that benefits me 
(in a very indirect and miniscule way, but in the end the purpose is for 
the *user's* benefit).
Ads are a feature that only benefits the upstream and the companies that 
pay for the ads. From my (user's) perspective, there is no reason to 
have them on my system. There is no benefit to me from this feature. 
None at all. This is a major difference from Gnome search providers, 
which I personally don't like either, but I can see how they might be 
good for someone.


If I wanted software that works and is adequately funded, I'd use 
Chrome. If Mozilla slides into forcing ads on people, the difference 
between Chrome and Firefox becomes quantitative, not qualitative – 
Google does the same bad stuff, but worse.


Personally, I sadly no longer trust Mozilla to do what's best for me. 
(Please don't become the next Google. Yes, I'm aware Google makes lots 
of money and can easily fund development and thousands of events each 
year. That does not make them an example I think Mozilla should follow.)


If Fedora starts including, as soldiers in a Trojan horse of default 
software, upstreams' features that don't benefit me and may be 
considered harmful, then Fedora will lose my trust as well.



tl;dr: I think the line we should not cross is: including features that 
don't benefit the user and may be considered harmful.


--
Petr³

--
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/20/2014 04:02 PM, Matthew Miller wrote:

On Thu, Nov 20, 2014 at 03:28:11PM +0100, Petr Viktorin wrote:

tl;dr: I think the line we should not cross is: including features
that don't benefit the user and may be considered harmful.


I don't think this is a very clear line. Should we drop all spreadsheet
applications?

http://www.velocityreviews.com/threads/spreadsheets-considered-harmful.717849/


Spreadsheet applications exist to benefit the user, so they don't cross 
this line.


(With a short-circuiting and¹, you won't even get to the may be 
considered harmful part in this case...)



--
Petr³

¹ http://en.wikipedia.org/wiki/Short-circuit_evaluation

--
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Petr Viktorin]

On 11/20/2014 04:44 PM, Martin Stransky wrote:

On 11/20/2014 03:28 PM, Petr Viktorin wrote:

It's not about tracking per se – I'm fine with e.g. opt-in usage reports
that feed into research for making a better browser – that benefits me
(in a very indirect and miniscule way, but in the end the purpose is for
the *user's* benefit).
Ads are a feature that only benefits the upstream and the companies that
pay for the ads. From my (user's) perspective, there is no reason to
have them on my system. There is no benefit to me from this feature.
None at all. This is a major difference from Gnome search providers,
which I personally don't like either, but I can see how they might be
good for someone.


 From the user perspective Mozilla provides you a high-quality browser
for free (free as a beer). But they have to pay engineers for the work.


Every piece of Fedora is like that, and yet I don't see any other 
software doing useless-for-me opt-out tracking.
(Also, who am I paying? All authors of Firefox, or only the Mozilla 
employees?)



There are some other options there. To have free (basic) and paid
(extended) Firefox versions - Red Hat goes this way. Or direct donation
from users like Wikipedia. Mozilla chose the Ads way and you may or may
not accept it and you exactly know what's the (asked) price.


The question is, will *Fedora* accept it on my behalf?  Will Fedora no 
longer shield me from the ways of the Android developer?



That's still much better than Chrome where the price (user tracking) is
hidden and you can't disable it.


Well, you can – the Chromium source is out there. The only catch is that 
Chromium is not built primarily for users, but for the developers' benefit.



You can remove the Ads from Firefox by one click so no big deal here.
The same case is using Addblock to block Ads on Web. But you're giving
nothing back then.


Is there now an *obligation* to give back? Because there never has been 
such a thing.


I personally give quite a lot back, not to Mozilla specifically but to 
open-source community as a whole – but it's not because I have an 
obligation to do it nor because I'm forced to do it.
The recend trend of open source guiding me to become part of some 
monetization scheme saddens me.



Every user likes the best software for free (as a beer), but there isn't
any magic wand which makes it up for you.


The process which gave us Firefox so far seemed quite fine. I'm sure it 
was no easy wand-waving, but so far it has been for the user first.
Sure, Mozilla did not organize as many events or hire so many employees 
or get to dabble in the phone business. But the result is, so far, great.


I want my software to work for *me*; the free as in beer part is secondary.

--
Petr³

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

[389-devel] Please review: Fix slapi_td_plugin_lock_init prototype

[Petr Viktorin]

Hello,
FreeIPA compilation gives a GCC warning in a 389-ds header:

In file included from ipa_dns.c:54:0:
/usr/include/dirsrv/slapi-plugin.h:5585:1: warning: function declaration 
isn't a prototype [-Wstrict-prototypes]

 int slapi_td_plugin_lock_init();
 ^

The attached patch should fix this.

--
Petr³
From 90bc3f3a34be23e5d10d980641fa9d8deb2a395e Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 15 Sep 2014 13:16:15 +0200
Subject: [PATCH] Fix slapi_td_plugin_lock_init prototype

---
 ldap/servers/slapd/slapi-plugin.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ldap/servers/slapd/slapi-plugin.h b/ldap/servers/slapd/slapi-plugin.h
index f1ecfe8..268e465 100644
--- a/ldap/servers/slapd/slapi-plugin.h
+++ b/ldap/servers/slapd/slapi-plugin.h
@@ -5582,7 +5582,7 @@ void slapi_td_get_val(int indexType, void **value);
 int slapi_td_dn_init(void);
 int slapi_td_set_dn(char *dn);
 void slapi_td_get_dn(char **dn);
-int slapi_td_plugin_lock_init();
+int slapi_td_plugin_lock_init(void);
 int slapi_td_set_plugin_locked(int *value);
 void slapi_td_get_plugin_locked(int **value);
 
-- 
1.9.3

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

Re: [389-devel] Please review: Fix slapi_td_plugin_lock_init prototype

[Petr Viktorin]

On 09/15/2014 09:06 PM, Rich Megginson wrote:

On 09/15/2014 05:20 AM, Petr Viktorin wrote:

diff --git a/ldap/servers/slapd/slapi-plugin.h
b/ldap/servers/slapd/slapi-plugin.h
index f1ecfe8..268e465 100644
--- a/ldap/servers/slapd/slapi-plugin.h
+++ b/ldap/servers/slapd/slapi-plugin.h
@@ -5582,7 +5582,7 @@ void slapi_td_get_val(int indexType, void **value);
  int slapi_td_dn_init(void);
  int slapi_td_set_dn(char *dn);
  void slapi_td_get_dn(char **dn);
-int slapi_td_plugin_lock_init();
+int slapi_td_plugin_lock_init(void);
  int slapi_td_set_plugin_locked(int *value);
  void slapi_td_get_plugin_locked(int **value);
--

Thanks - https://fedorahosted.org/389/ticket/47899


Thanks.

I read the GIT Rules page on the wiki [0], which mentions patches not 
associated with a ticket. If all patches do need a ticket, it would be 
good to update it.


[0] http://www.port389.org/docs/389ds/development/git-rules.html


--
Petr³
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: DNF: why does it refresh metadata all the time

[Petr Viktorin]

On 06/19/2014 07:14 PM, Reindl Harald wrote:

why does DNF refresh metadata in background?


To quote Aleš Kozumplík from [a previous mail]:
| majority of people appreciates having the metadata handy and only a 
minority worries about the traffic.


[a previous mail] 
https://lists.fedoraproject.org/pipermail/devel/2013-March/180401.html




that has no benefit,


False.


increases network traffic


True (in some scenarios).


and finally leads to more likely outdated metadata in case
you type dnf upgrade *when* you want to apply updates


True.



the failed to load plugin copr is also just a bug


In that case please file it here: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora



--
Petr³

--
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 (2014-03-05)

[Petr Viktorin]

On 03/06/2014 06:00 PM, Matthew Miller wrote:

On Thu, Mar 06, 2014 at 03:50:37PM +0100, drago01 wrote:

For instance we named a release beefy miracle and that might have
been offensive for some people (ex. in India)., but
apparently no one cared enough to officially complain.


Additionally, there is a fundamental difference here. The problem isn't that
someone might be offended -- people might be (and are) offended by anything.
The problem is that the logo refers to a marginalized race of people using
stereotyped imagery. While many people do not eat beef and hold cows sacred,
the beefy miracle logo does not make any reference to those people. If it
did, it too would have been a problem.


It seems this tabooization of stereotypes[0] is a North American concept 
(though, as I was surprised to learn, apparently there are entire fields 
of study around this area, which I admit I'm not familiar with).
I don't get how referring to a marginalized people using stereotyped 
imagery should be considered offensive in Fedora while sacrilege 
should not. I really don't see any fundamental difference. (Though -- or 
maybe because -- neither are offensive to me personally.)


Please, consider that there are cultures other than your own. What seems 
inherently right for you may seem confusing or even absurd to others, 
and on the other hand what seems trivial to you might be a huge issue 
for others.


--
Petr³


[0] Pardon me if this simplification is offensive. The whole concept is 
foreign to me.


--
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 (2014-03-05)

[Petr Viktorin]

On 03/07/2014 10:59 AM, H. Guémar wrote:

Hi,

I don't think that worrying about perpetuating offensive stereotypes
is specifc to the US, we have similar controversies in Europe:
http://en.wikipedia.org/wiki/Banania#Controversy
http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies


Well, read the second article. 92% of the Dutch public don't perceive 
Zwarte Piet as racist. I'm not saying it is or is not, or that it 
should or should not be fixed; I'm saying that there is a culture where 
this is not perceived as a big deal, as opposed to USA where political 
correctness is a big deal.



Anyway, the line between what is acceptable and unacceptable in Fedora
should be that no one should be offended by something that directly
refers to him or his origins in a negative or hurtful way.


My point is that the list him/her and his/her origins seems rather 
arbitrary. Why is e.g. his/her religion not on the list?
I'm not saying where the line should be drawn, that is obviously 
something a single person (or a single culture) shouldn't decide.


(By the way, excluding females by saying he when you mean anybody is 
seriously offensive to some. Again, from what I can tell, this is a big 
issue in the American culture.)



I have no opinion about the Cherokee logo, as an European citizen, it
looks to me very innocent (a little child playing) but if it offends
native americans, it should be fixed anyway.


I also don't see how anyone could be offended by it, but I understand 
that there is a culture that I don't understand :)


--
Petr³

--
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: advertisement in packaged software (e.g. Firefox)

[Petr Viktorin]

On 02/12/2014 04:31 PM, Matthias Clasen wrote:


Are we allowed to ship software in Fedora that dynamically loads
advertisements from the web and shows them to users?


I think allowed is probably the wrong term to use here. Fedora
packaging rules on what is allowed to be included have pretty much
focused on legality of packages. ie licensing, trademarks, patents,
etc. The question of whether advertisements are allowed is starting
to venture into the grounds of philosophy. There's probably also a
privacy question to answer here too. To me though, those aren't
criteria for forbidding software from Fedora entirely, but are
relevant when choosing whether a piece of software is set as the
default option installed for users.


Yeah, I agree. This is not about being allowed to, but the question is
whether we want to. And for that, the question probably is: it depends.

I can't imagine having very obnoxious and prominents advertisements in
the flagship applications that we install by default. But an application
that is otherwise useful to our users should probably not be banned from
the package universe just because it downloads an ad.


If that ad enables tracking users, or is obnoxious in any way, the 
software should be modified to not include the ad.


I believe a major advantage of a free distribution like Fedora, over an 
app store like Android's, is that it tries to do what's best for the 
users, not developers and advertisers. Let's not change that, please.


--
Petr³

--
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: adam's grump of the day: icons in fonts (was Re: web-assets-httpd stuck in limbo?)

[Petr Viktorin]

On 01/17/2014 02:25 AM, Samuel Sieb wrote:

On 01/16/2014 01:38 PM, Chris Murphy wrote:


On Jan 16, 2014, at 1:41 PM, Matthew Miller mat...@fedoraproject.org
wrote:



The other thing -- getting unicode to include standard symbols -- is
happening. That's why we have  . Yay standards!


Oh man. Change that to 144pt. Is it chocolate soft serve with a smile?
Or is it Mr. Hanky's cousin?

Right-click on it Show Font  Apple Color Emoji  Character

Character Name? PILE OF POO

Hahaha. Oh so many bad ideas made into a standard here…

 This does not mean OK in many countries!
 This can also be a crude gesture.
 This is just bad graphics.


Well, the graphics can be better in a different font.


Pine decoration, custard, bento box, and wind chime. Standards. Oh boy.



Assuming you're using Fedora to read your emails, what font do you have
installed that has those glyphs?  I can see them on my Android phone,
but not on my Fedora laptop.


You can use Symbola, yum install gdouros-symbola-fonts

--
Petr³

--
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: dnf versus yum

[Petr Viktorin]

On 01/06/2014 03:32 PM, Lars E. Pettersson wrote:

On 01/06/2014 02:06 PM, Vít Ondruch wrote:

Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):

...

What would be the point in removing the running kernel? Is there
actually such a use case?

Lars


Why are you asking? May be you should let your imagination run riot.


Why? Isn't that obvious? If there is no use case for removing the
running kernel, well, then there's no reason to let a application do so,
isn't it?


AFAIU, inside a container you don't need a kernel installed.


Allowing something that has no, or a minuscules use case, while at the
same time might create huge problems for non technically oriented user,
is, in my opinion, really bad.


Also, I'd like to point out that yum/dnf remove by default shows what
it is going to do and you have to explicitly confirm the action, isn't
it enough? How much protection do you need?


Me? For me personally it dose not matter. The reason I debate this is to
help the unsuspecting ordinary non technical users from debunking their
systems. The user perspective is good to have sometimes, you know.

Lars



--
Petr³
--
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: dnf versus yum

[Petr Viktorin]

On 01/02/2014 06:16 PM, Richard W.M. Jones wrote:

On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:

to prevent that the same as with GRUB2 and systemd way too early
made it in a stable release happening again - and after that get
again why are you open your mouth now and not due testing back


I'm sure that Ales will welcome patches from you.

But, have you ever contributed a patch to Fedora?  I'm having
difficulty finding any.  The first match for a Google search reindl
harald fedora is a discussion about banning you from sending mail to
this mailing list.  You don't even have a Fedora account.


I see no reason for ad hominem attacks. Personal history is irrelevant 
here. Let's please keep civil and focus on facts.


Aleš announced DNF ready for user testing, this thread is a legitimate 
reply to that (though this list may be the wrong channel for it).


--
Petr³

--
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: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 10:48 AM, Reindl Harald wrote:

Am 01.11.2013 10:38, schrieb drago01:

On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com wrote:

On 10/30/2013 10:27 AM, Alec Leamas wrote:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your
concerns about this.


Why does it matter?  A hidden directory in everyone's path is obviously
useful to an attacker, and (IMO) more useful to an attacker than to a user.


The attacker needs to be able to write to your home directory to take
advantage of it.
And if he can do that (you lost) he has numerous other ways of doing it


so the people decided not put the current directory in the
PATH on Unix *for security reasons* decades ago must be
fools and if you would have been born as this happened you
would have told them forget it, in that case you are lost


Was that even for security reasons?
Anyway, how this is relevant to this discussion? How does a static, 
well-known (maybe not to you so far) bin directory compare to the danger 
of . PATH and, say, a rootkit in /tmp/cp?



heroic attitude :-)

*yes* you have lost and in doubt in this situation the
interesting thing is how large the impact becomes


Users of a multi-user system get to customize their system without 
having to bother a sysadmin, and without seeing technical details of 
that's accompished mixed with their ~/Photos and ~/Documents.


What impact did *you* have in mind?

--
Petr³

--
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: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 11:14 AM, Reindl Harald wrote:



Am 01.11.2013 11:08, schrieb Petr Viktorin:

On 11/01/2013 10:48 AM, Reindl Harald wrote:

Am 01.11.2013 10:38, schrieb drago01:

On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com wrote:

On 10/30/2013 10:27 AM, Alec Leamas wrote:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your
concerns about this.


Why does it matter?  A hidden directory in everyone's path is obviously
useful to an attacker, and (IMO) more useful to an attacker than to a user.


The attacker needs to be able to write to your home directory to take
advantage of it.
And if he can do that (you lost) he has numerous other ways of doing it


so the people decided not put the current directory in the
PATH on Unix *for security reasons* decades ago must be
fools and if you would have been born as this happened you
would have told them forget it, in that case you are lost


Was that even for security reasons?


yes, Google may help here


Anyway, how this is relevant to this discussion? How does a static, well-known 
(maybe not to you so far) bin
directory compare to the danger of . PATH and, say, a rootkit in /tmp/cp?


the rootkit in /tmp/cp is in your path?


If . would have been in $PATH and I happened to be in /tmp, then yes.
On the other hand if I install something in my home, it does not affect 
other users in any way.


(As an aside: the old Unix security decisions assumed the user trusts 
his or her software. This is of course increasingly less the case, but 
that neither makes anyone a fool, nor does it make . comparable to 
~/.local/bin.)



heroic attitude :-)

*yes* you have lost and in doubt in this situation the
interesting thing is how large the impact becomes


Users of a multi-user system get to customize their system without having to 
bother a sysadmin, and without seeing
technical details of that's accompished mixed with their ~/Photos and 
~/Documents.


on multi-user systems it is *intentional* that the user does *not* install
software at it's own and if this should be the case the admin *one time*
will add a directory to PATH and say there you go


As Alec said, not necessarily. If you want this policy for your systems, 
you have the power to do so.
The users (or software they install) can, of course, edit their 
.bash_profile to change it right back.



What impact did *you* have in mind?


the *security* impact after you have lost happened


In both cases, everything the user had access to is compromised, 
including .bash_profile itself. What other *security* impact did you 
have in mind?


--
Petr³

--
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: $HOME/.local/bin in $PATH

[Petr Viktorin]

On 10/30/2013 01:08 PM, Reindl Harald wrote:



Am 30.10.2013 13:00, schrieb Alec Leamas:

On 2013-10-30 12:25, Reindl Harald wrote:

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide that security is not that important for you
but a distribution as such should not make such wrong decisions for all users

No, it should not.  However,  the right decision is in many cases a trade-off 
between security and usabilty, not
always with a single answer. Allowing users to install sw (i. e., allowing 
random applications to put things in
$PATH) has of course security implications. Dis-allowing has usability aspects. 
 My personal view is that for the
distribution the defaults should allow and support user-installed sw.


the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome,


Do you have any source for that assumption?
For example university students usually simply can't install as root.


if so they should learn
about the implications and have a small barrier


No, they should just install the software and be done with it.


it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to i did not know about the door i never opened by myself


Why should I do that? I expect `pip install --user` to install my 
package without me having to fiddle with .bash_profile.



And, isn't  this still a little off-topic?


no it is not because the topic is in the subject


Current defaults already has ~/bin in $PATH, and user can certainly put
things there. Isn't the issue here if having a hidden, writeable directory
in $PATH is such a bad idea, given that users actually can install sw?


guess how many users are aware of the hidden directory compared with
bin in the userhome and how often someone may take a look


Also guess how many users don't care.
Do you have data to make anything else than a guess?


you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users


I personally like that ~/bin contains what I put there myself by hand, 
and ~/.local/bin has what was installed via pip.



but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero


This is wild speculation.
You can just echo $PATH to see what directories are in $PATH.


Also, if you bother securing .bash_profile so that rogue programs can't 
write into it, you can easily check if $PATH is set the way you want it.
If you don't bother, it doesn't matter if malware installs to 
~/.local/bin/rootkit or ~/.rootkit


--
Petr³

--
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: Source file audit - 2013-09-30

[Petr Viktorin]

On 10/04/2013 11:49 AM, Dridi Boukelmoune wrote:

Hi,

In my case, the makeself source tarball is hosted on github. I've seen
many people saying that github was down recently (even though it
worked fine for me).


It was down for about two hours: https://status.github.com/messages

--
Petr³

--
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: Grepping through all Fedora specfiles?

[Petr Viktorin]

On 07/25/2013 01:45 AM, Toshio Kuratomi wrote:

On Thu, Jul 25, 2013 at 09:02:47AM +1000, Tony Breeds wrote:


As an aside, Any guesses as to how big the ~/fedora-git dir would be
after running the script above?


Upwards of 9GB.  I'm working on a git-seed script right now and that's the
size of a checkout seed in the testing environment (which has an older sync
of the git repos).

-Toshio


If you're worried about the size, shallow clones could work for you in 
this case: git clone --depth 1

Read the man page for the limitations.

It might not save too much space, though -- compressed history tends to 
be small.


(`git fetch --unshallow` will bring in the history if you change your 
mind later.)


--
Petr³

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