Re: New release of Mock (fixes and subscription-manager support)

[Avram Lubkin]

On Tue, Aug 27, 2019 at 10:20 AM Miroslav Suchý  wrote:

> 2) Mock now supports subscription-manager, which allows you to build
> packages for RHEL with cost-free developer license.
> No need to wait for CentOS 8.
>

Does this work when using Fedora as the base system? subscription-manager
is available in the Fedora repos and a Fedora system can be registered to
RHN, but that doesn't seem sufficient to access the repos through mock.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: New release of Mock (fixes and subscription-manager support)

[Avram Lubkin]

On Tue, Aug 27, 2019 at 10:20 AM Miroslav Suchý  wrote:

> 2) Mock now supports subscription-manager, which allows you to build
> packages for RHEL with cost-free developer license.
> No need to wait for CentOS 8.
>

Does this work when using Fedora as the base system? subscription-manager
is available in the Fedora repos and a Fedora system can be registered to
RHN, but that doesn't seem sufficient to access the repos through mock.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

[Avram Lubkin]

On Sat, Dec 29, 2018 at 2:04 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Duplicated dependencies is a problem because rpm-md becomes larger. If
> we would use Requires: python%{python3_version}dist() dependencies,
> then RPM would merge them and it would be fine. But since we use
> python3-foo and python3dist(foo), it makes duplicated dependencies.
>

An article giving instructions and creating bug reports might be a better
approach. Then if there is no movement create a PR. Should save you some
work and lets people do things in their own style. This is similar to what
Miro has been doing with the python2 deprecation.
___
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

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

[Avram Lubkin]

On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> You can't make it work in EPEL easily because python modules do not
> have pythonX.Ydist() provides.
>

Didn't realize that and not sure why that wasn't backported. Honestly, if
we aren't going to be consistent across EPEL and Fedora when we can, then
why are they even under the same umbrella?

Anyway, looks like enabling it for EPEL is a bigger task. I still don't see
the point of enabling it by default in Fedora at this point. It can easily
be enabled for those who want it and doesn't add work for those who it
won't work for. Especially since there is no test code!
___
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

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

[Avram Lubkin]

On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Well, now that this has been enabled, it is likely that there already
> are packages which make use of this functionality, and disabling the
> generator again would break them. So reverting the changes doesn't seem
> like a good idea. It'd also create even more chaos.
>

It's just been a week so I doubt the impact is very large and the fix is
simply to explicitly turn on dependency generation. Igor and Neal are
championing this change, so I think if they can go back and work on the
missed steps, no reason to revert in rawhide, but if no one is signs up to
fix it, then it's clearly not ready.


> Maintaining single-spec compatibility with EPEL is the responsibility
> of individual package maintainers that desire that. The changes to use
> the generators are only done in "master", so before merging those
> changes into the epel branches, the maintainers have the chance to add
> the necessary conditionals or some other solution. (Alternatively,
> disabling the generators in that specific package and continuing to
> use the manual deps is also a valid option.)
>

You seen to misunderstand how a common spec works. There are no changes
made between the branch merges. The purpose of this is to make it easier to
maintain packages across branches so packages don't languish unnecessarily.
Yes, it can be disabled per package, but isn't the point of this to save
effort. Seems like it just creates more work for other people.

Avram


On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
> > Looks like the dependency generator was turned on in rawhide. Igor has
> been
> > making pull releases against packages because this is now creating
> > duplicate requires for some packages. That would seem reasonable, but he
> > never pushed the dependency generator to EPEL so packages which maintain
> a
> > common spec file across branches require additional logic and it's
> creating
> > more work instead of less work. The python-rpm-generators package doesn't
> > even exist in EPEL. I started looking at what it would take to make it
> > available, but the script that's used has no documentation and no tests.
>
> Well, now that this has been enabled, it is likely that there already
> are packages which make use of this functionality, and disabling the
> generator again would break them. So reverting the changes doesn't seem
> like a good idea. It'd also create even more chaos.
>
> > I recommend we revert this to opt-in until a couple loose ends are tied
> up:
> >  - Tests and a readme file are created for python-rpm-generators
> >  - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
> > (Requires python-rpm-generators RPM)
>
> Maintaining single-spec compatibility with EPEL is the responsibility
> of individual package maintainers that desire that. The changes to use
> the generators are only done in "master", so before merging those
> changes into the epel branches, the maintainers have the chance to add
> the necessary conditionals or some other solution. (Alternatively,
> disabling the generators in that specific package and continuing to
> use the manual deps is also a valid option.)
>
> Zbyszek
> ___
> 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
>
___
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

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

[Avram Lubkin]

On Fri, Dec 28, 2018 at 11:48 AM Neal Gompa  wrote:

> python-rpm-generators is not the real upstream for that code (rpm is).
> And testability would be a bit difficult because all the script does
> is pull stuff from python module metadata using setuptools and print it
> out.
>

So you provide test data either as external files or using the the mock
Python module. This is pretty standard.


> It's not going to exist in EPEL because in RHEL, the Python dependency
> generator doesn't exist at all. If we enabled it for EPEL, we'd have broken
> dependencies everywhere, since no RHEL Python modules would have the
> necessary generated dependencies. If you'd like to ask Red Hat to add it to
> RHEL 7, be my guest. However, I suspect they'll say no.
>

It doesn't need to be in the base, there just needs to be el6 and epel7
branches for python-rpm-generators and make it a dependency of
python-rpm-macros which is also an EPEL package. This is relatively
straightforward. The only difference from Fedora is maybe it should
probably be opt-in instead of enabled by default.

>
> A simple way to check if you should specify manually is to check if
> %__pythondist_requires is undefined, like so:
>
> %if ! %{defined __pythondist_requires}
> Requires: python3-modA
> Requires: python3-modB
> ...
> %endif
>

What is the point of this then if it requires additional logic and still
requires listing dependencies for EPEL? I'm happy to help with the changes
for EPEL, but I think if we're going to rely on this then it should at
least have tests.

Avram
___
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

Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default

[Avram Lubkin]

Looks like the dependency generator was turned on in rawhide. Igor has been
making pull releases against packages because this is now creating
duplicate requires for some packages. That would seem reasonable, but he
never pushed the dependency generator to EPEL so packages which maintain a
common spec file across branches require additional logic and it's creating
more work instead of less work. The python-rpm-generators package doesn't
even exist in EPEL. I started looking at what it would take to make it
available, but the script that's used has no documentation and no tests.

I recommend we revert this to opt-in until a couple loose ends are tied up:
 - Tests and a readme file are created for python-rpm-generators
 - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
(Requires python-rpm-generators RPM)

Avram


On Sat, Dec 8, 2018 at 10:15 AM Ben Cotton  wrote:

> On Sat, Dec 8, 2018 at 4:08 AM Igor Gnatenko
>  wrote:
> >
> > This is system-wide change, at least that's what wiki says ;)
>
> That is correct. I should not send email after being in meetings all day.
> :-D
>
>
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> ___
> 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
>
___
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

Re: Unresponsive Maintainer: python-ldap3

[Avram Lubkin]

Michal gave me commit privileges and I was able to push out the changes.
Happy to maintain it.
In the future, even if you don't have an interest, please respond and
communicate that.


On Sun, Dec 16, 2018 at 1:01 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Sorry, I have no interest in EPEL packages, so I didn't respond.
>
> If you would like to maintain it, I will happily add you as comaintainer.
>
>
> On Fri, Dec 14, 2018, 16:11 Avram Lubkin 
>> I've been trying to reach the maintainers for python-ldap3
>> (ignatenkobrain, mcyprian) for the last month. I've sent multiple emails,
>> submitted pull requests[1] [2], and a bug [3]. fedora_active_user.py shows
>> occasional activity for ignatenkobrain. Does anyone know how to contact
>> either maintainer?
>>
>> Thanks,
>>
>> Avram
>>
>> [1] https://src.fedoraproject.org/rpms/python-ldap3/pull-request/1
>> [2] https://src.fedoraproject.org/rpms/python-ldap3/pull-request/2
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1653732
>>
>
___
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

Unresponsive Maintainer: python-ldap3

[Avram Lubkin]

I've been trying to reach the maintainers for python-ldap3 (ignatenkobrain,
mcyprian) for the last month. I've sent multiple emails, submitted pull
requests[1] [2], and a bug [3]. fedora_active_user.py shows occasional
activity for ignatenkobrain. Does anyone know how to contact either
maintainer?

Thanks,

Avram

[1] https://src.fedoraproject.org/rpms/python-ldap3/pull-request/1
[2] https://src.fedoraproject.org/rpms/python-ldap3/pull-request/2
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1653732
___
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

Re: Fedora 29 Mass Rebuild

[Avram Lubkin]

>
> Currently you should run this:
>   fedpkg retire "This is an EPEL only package"
> in both the master and f28 branches.
>

Makes sense, but is this documented anywhere?

On Sat, Jul 14, 2018 at 1:46 PM, Jason L Tibbitts III 
wrote:

> >>>>> "AL" == Avram Lubkin  writes:
>
> AL> We had issues, Bug 1600418, because python3-dns, which is intended
> AL> only for EPEL7, was included in the mass rebuild for 28 and had an
> AL> f28 branch created. Now it's been included in the f29 mass
> AL> rebuild. How do we keep this from happening?
>
> Well, it's not retired in rawhide, so it's going to keep getting built
> and branched.  If it's an EPEL-only package, you need to immediately
> retire the master branch when the repository is created.
>
> Currently you should run this:
>   fedpkg retire "This is an EPEL only package"
> in both the master and f28 branches.
>
> The buildsystem should then automatically block that package from future
> composes so it will disappear from the repositories, and it should not
> acquire an f29 branch when the branching happens.
>
>  - J<
>
___
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/7G5JJOMF7GE6FOQN55D5NLW7RUJTPVNQ/

Re: Fedora 29 Mass Rebuild

[Avram Lubkin]

We had issues, Bug 1600418, because python3-dns, which is intended only for
EPEL7, was included in the mass rebuild for 28 and had an f28 branch
created. Now it's been included in the f29 mass rebuild. How do we keep
this from happening?

Avram
___
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/NLUXR2TSZ2HERJZUWNHG5PWAWPMUJ6JE/

Fedora/EPEL GitHub Badges

[Avram Lubkin]

Badges are pretty popular in GitHub though there don't seem to be many that
provide information on distros that have packages for a project. This would
be very useful because, at least for me, the first thing I do when I want
to try a new project is see if a package is available for the distro I'm
working with, usually Fedora or CentOS.

I searched around, but couldn't find anything that existed already (please
let me know if I missed it), so I made static badges for one of my
projects, python-enlighten[1], but this requires remembering to update them
when a new version of Fedora comes out.

I tried to create a dynamic one, but it isn't exactly what I want. It's
based on if a branch exists and starts with 'f' or 'e', not if there is a
stable package for that branch. Also, the branch names are not consistent
between EPEL 6 and EPEL 7, so it would be better to just get the number.
Might as well just use the number for Fedora too for consistency.

Static Fedora:
https://img.shields.io/badge/Fedora-26,_27-lightgrey.svg

Static EPEL:
https://img.shields.io/badge/EPEL-6,_7-lightgrey.svg


Dynamic Fedora:
https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
"f"))].name=Fedora

Dynamic EPEL:
https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
"e"))].name=EPEL

I'm also not sure the best place to point them to. shields.io does let you
set a target for both the left and the right sides, but I just set the
target within readme.rst and pointed both badges to the Bodhi updates page
for the package.

Anyone have a better way to generate dynamic badges? Should badge
generation be a part of the Fedora infrastructure?

For an alternative approach, would it be better to show the latest stable
version in the latest Fedora. Something like this, but dynamic:

https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg


[1] https://github.com/Rockhopper-Technologies/enlighten
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: State of LuaTeX in F25/rawhide

[Avram Lubkin]

On Mon, Nov 28, 2016 at 3:11 PM, Avram Lubkin <av...@rockhopper.net> wrote:

> Forcing the pdftex driver gives an error about missing pdf primitives,
> so this is most probably related to the removed pdf primitives in LuaTeX
> 0.85 and later.
>


texlive-luatex85 provides luatex85.sty which might solve your issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upstream Release Monitoring builds for EL7 instead of Rawhide

[Avram Lubkin]

Seems like this issue is almost a year old.


On Wed, Sep 21, 2016 at 9:31 AM, Ville Skyttä <ville.sky...@iki.fi> wrote:

> On Wed, Sep 21, 2016 at 4:21 PM, Avram Lubkin <av...@rockhopper.net>
> wrote:
> >
> > I've noticed this a lot lately. I get a bugzilla for a new release in
> > upstream, but it lists the current version in rawhide as the el7
> > distribution. [...] I this something I can fix or is there a problem
> > with rebase helper?
>
> https://github.com/fedora-infra/the-new-hotness/issues/98
> https://github.com/fedora-infra/the-new-hotness/issues/84
> ___
> 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

Upstream Release Monitoring builds for EL7 instead of Rawhide

[Avram Lubkin]

I've noticed this a lot lately. I get a bugzilla for a new release in
upstream, but it lists the current version in rawhide as the el7
distribution. The rebase helper build fails because of something not
supported in 7, like a Recommends tag. This is exactly what I'm seeing with
the latest python-sphinx version [1]. There isn't even an EPEL 7 branch for
it in git.

Anyone else seeing similar? I this something I can fix or is there a
problem with rebase helper?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1378071
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Avram Lubkin]

On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen 
wrote:

>
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
>

You seem to be talking about RPM names and not SRPM names. By convention,
any Python 3 package for EPEL7 would actually be python34-package. The
point of this thread is to discuss SRPM names and if python34-package can
be built from a SPRM package named python-package like in Fedora. Since
python2 and python3 packages are generally built from the same source and
spec, the SRPM and Fedora Git repo are usually not versioned. The problem
is when a python2 package exists in RHEL, but we want to supply a python34
package. The draft guidelines (which are the only ones we have) say this is
a conflict, but it seems that is not stated anywhere in the EPEL
guidelines. The main problem this creates is very few python34 packages get
created because people don't want to maintain multiple repos for the same
thing.

As far as the limited arch packages, I bring that up because it seems from
the guidelines their SRPM name would be the same as the one in RHEL. If
that is acceptable there, it likely should be for python packages.

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

[EPEL-devel] Requirements for SRPM names

[Avram Lubkin]

I'm looking for some clarification on the naming requirements for SRPMs.

In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
can't conflict with RHEL SRPM names, but in the Limited Arch Packages
[2]section of EPEL: Packaging, it seems to imply the SRPM name would be the
same, but the release number would be pretended with "0.".

Could someone please clarify?

If, in fact, the name can be the same, it will make it much easier to
provide Python 3 packages for EPEL since a separate package would not be
required in the Fedora Package DB.

Avram


[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#
Packaging_Parallel_python3X_stacks
[2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Renaming python to python2

[Avram Lubkin]

On Sat, Sep 3, 2016 at 2:32 PM, Nick Coghlan  wrote:

>
> * Tier 0: "the default Python" is determined at the distribution
> level. For the majority of current distributions, that means Python 2,
> but on a select few it means Python 3.
>
> * Tier 1: "the default Python" is configurable on a per-system level.
> Distros pursuing this option (e.g. by moving /usr/bin/python under
> 'alternatives') are still advised to keep the out-of-the-box default
> as Python 2. This will be sufficient for at least some environments to
> start managed migrations from Python-2-as-default to
> Python-3-as-default, and further establishes the precedent that
> "/usr/bin/python will always be Python 2" is an incorrect assumption.
>
> * Tier 2: "the default Python" is configurable on a per-user level.
> Sufficiently determined sysadmins can actually configure this today,
> so it would mainly be a matter of looking at what's involved in doing
> that, and making it simpler for people to set up.
>
> * Tier 3 (highly experimental): "the default Python" is configurable
> on a per-script level, using something like pythonmux.
>

 I think that is a great approach!

For Teir 2:

Today, a user can alias python for direct execution. For scripts that use
/use/bin/env, they can manipulate their $PATH (and create symlinks). Some
of that could be automated.

For Teir 3:

Ideally this would be something that evaluated a list of preferred
interpreters given on the shebang, but defaulted to the user/system
default. It should also work across multiple python interpreters like pypy
or jython and not just versions of Cpython.

This could be a non-Python-specific solution. What if there was a utility,
like env, that searched python in $PATH, but could take multiple commands?
Then you might have a shebang like:

#! /usr/bin/envmux pypy3 pypy python3.5 python3 python2.7 python

It would probably also need a way to pass options to specific interpreters,
so maybe syntax like this?

#! /usr/bin/envmux python3 "[-b]" python2 python

It could even handle user and system defaults by allowing a keypair file in
the user's home directory and in etc. Something like:

~/.envmux
---
python : /usr/bin/python3.5

/etc/envmux
--
python : /usr/bin/python2.7

In this example the system default would be Python2.7, but the user default
would be Python 3.5. To handle the python command, python could be aliased
to "/usr/bin/envmux python".

I think a solution like this is more flexible than pythonmux and would also
be valuable to non-Python implementations.

The downside is you can't directly say a script required Python 2.6+ or
3.3+, you would have to list out all the versions, but the solutions today
don't handle that either, and that is probably better handled within the
script to give more information to the user.

Avram
___
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

[Avram Lubkin]

On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin  wrote:

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

Completely agree. Based on the suggestions offered in PEP 394, we would
need to add idle2 and pydoc2 symlinks in the python spec.

The PEP also reiterates that the focus is on the end-user and not on the
distribution packages. It's very clear that the shebang should be set
upstream to the level of specificity required.

I think the best way to serve the end-user is to manage /usr.bin/python
with alternatives, with slave entries for idle, pydoc, python-config, and
the python man page. This is compliant with the suggestions of the PEP and
gives control to the user. The symlinks should point to the major version
links/files as minor versions may introduce too many issues to address at
the moment.
___
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

[Avram Lubkin]

On Thu, Sep 1, 2016 at 8:40 AM, Neal Gompa  wrote:

> Sure, but those scripts may not actually work because modules that are
> supposed to be there, aren't. For example, if you depend on a
> non-standard lib module, then that means it needs to be installed for
> each python version supported. How do you expect to guarantee that?
>
> Again, alternatives is only for things that operate functionally
> identically. That's not even true between Python 2.6 and Python 2.7 if
> they are installed in parallel because they can't use the same module
> path. Likewise for Python 3.5 and 3.6.
>
> You're essentially asking for unpredictable breakage.
>


I would argue what "/usr/bin/python" points to should be a user option and
what is in the shebang line is a packager issues. As a user, I should be
able to select whatever version of Python I want. As a packager, I should
make sure my package will run with the correct version. This is easier when
we're only talking about major versions, but we could add an rpm macro that
would point to the minor version executable if there was a need.

Something like pythonmux might be useful in the shebang for this purpose,
but "/usr/bin/python" shouldn't be linked to it.
___
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

[Avram Lubkin]

On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa  wrote:

> Alternatives doesn't work in this case because Python 2.x and Python
> 3.x versions don't share resources, even with minor versions of the
> same series. Enabling alternatives for it is a recipe for disaster.
>

Could you elaborate? The use case we are talking about is what gets
executed when you run /usr/bin/python. i.e. symlink management, which is
what alternatives is intended for.
___
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

[Avram Lubkin]

On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan  wrote:

>
> The ideal point we'd like to get to is one where all distro provided
> scripts actually have the appropriate major version in their shebang
> lines, and the unqualifed "python" is something along the lines of a
> user-configurable launcher, akin to the "py" launcher for Windows:
> https://docs.python.org/3/using/windows.html#python-launcher-for-windows
> (see https://www.python.org/dev/peps/pep-0397/ for more details on
> that)
>

While I see some benefit to something like this and could see use cases for
including it in the shebang, it would be overkill for "/usr/bin/python".
Windows needs something like that because it doesn't support symlinks.

Let's stop trying to reinvent the wheel. There is already a system for
handling this, alternatives, which is used by other languages and included
in a minimal Fedora install. It would only require adding to the %post and
%postun scripts in the spec file and allows very easy testing to see what
breaks when changing the default. When we are ready to change the default,
only one value needs to be changed. And most importantly, it gives the
end-user an easy way to change their system-wide default either from python
2 to 3 or when running a pre-release version of 3.x in parallel.

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

[EPEL-devel] Re: python34 for EPEL6

[Avram Lubkin]

On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III 
wrote:

>
> To be completely fair, I don't actually know EPEL policy here.  The rule
> is that you can't conflict with RHEL packages, but SRPMs aren't really
> installed the same way as other packages and whether or not they would
> install to the same location depends somewhat on your personal .rpmrc.
>
>
As far as I know, this is the adopted policy [1]. Though, I'm not sure if
that was ever made official since it's still on a user page. I couldn't
find anything that specifically says SRPM names can't be the same and it
seems like that is not the process for additional architecture packages.
[2] They just use a leading 0 in the release, ex: foobar-1.0-0.1.

I'm curious if anyone else has any insight. Maybe it is worth bringing up
at a FPC meeting.

[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_
Python3#Packaging_Parallel_python3X_stacks
[2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: python34 for EPEL6

[Avram Lubkin]

>
> Which is an annoying bit of process, but it would be quite possible to
> exempt those packages from needing package reviews.  It needn't take
> that long.
>
>
Not needing reviews would help, but I wonder how hard it would be to make
them children of python-PACKAGE. The main issue is the SRPM needs to have a
different name so there is no conflict with the RHEL SRPM. That's easy to
set in the spec file, but the build system requires the SRPM name to match
the Fedora pkgdb and git names. Is it possible to define children, so
python34-PACKAGE could use the same git repo as python-PACKAGE? This would
be cleaner and more accurate than the current convention of creating a
python3-PACKAGE git repo and pkgdb package.

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

[EPEL-devel] Re: python34 for EPEL6

[Avram Lubkin]

Definitely, but it runs into the same problem as 3.4 on EL7, the fact that
there are few packages available and adding them when the package already
exists in RHEL requires creating a separate parent package in Fedora pkgdb.

On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski 
wrote:

> I have no idea if there is any interest in this or not.  I managed to get
> the
> EPEL7 python34 package to build on EL6 with a few modifications.  Is there
> any
> interest in supporting this?
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
>
> ___
> python-devel mailing list
> python-de...@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@
> lists.fedoraproject.org
>
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: python34 for EPEL6

[Avram Lubkin]

>
> Which is an annoying bit of process, but it would be quite possible to
> exempt those packages from needing package reviews.  It needn't take
> that long.
>
>
Not needing reviews would help, but I wonder how hard it would be to make
them children of python-PACKAGE. The main issue is the SRPM needs to have a
different name so there is no conflict with the RHEL SRPM. That's easy to
set in the spec file, but the build system requires the SRPM name to match
the Fedora pkgdb and git names. Is it possible to define children, so
python34-PACKAGE could use the same git repo as python-PACKAGE? This would
be cleaner and more accurate than the current convention of creating a
python3-PACKAGE git repo and pkgdb package.

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

Re: python34 for EPEL6

[Avram Lubkin]

Definitely, but it runs into the same problem as 3.4 on EL7, the fact that
there are few packages available and adding them when the package already
exists in RHEL requires creating a separate parent package in Fedora pkgdb.

On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski 
wrote:

> I have no idea if there is any interest in this or not.  I managed to get
> the
> EPEL7 python34 package to build on EL6 with a few modifications.  Is there
> any
> interest in supporting this?
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
>
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@
> lists.fedoraproject.org
>
>
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Naming a sphinx-doc theme: python-sphinx_py3doc_enhanced_theme or python-sphinx-theme-py3doc-enhanced

[Avram Lubkin]

Frankly I think upstream should have called it py3doc_enhanced and left out
sphinx and theme, but that's beside the point.

Based on the package naming conventions [1], you name is mainly correct
(more on this later). In the Python modules section [2], it says:

The package name should reflect the upstream name of the Python module, and
should generally take into account the name of the module used when
importing it in Python scripts. This name will be prefixed depending on the
type of the package.

Based on that, the name should really be
python-sphinx-theme-sphinx_py3doc_enhanced_theme,
but that is overly confusing. I think there are two legitimate names:

python-sphinx-theme-py3doc_enhanced
python-sphinx_py3doc_enhanced_theme

Some might argue you could replace the underscore in the first one with a
dash, and I wouldn't see a huge problem with that, but I think it's not
necessary. It is justified though because the name is already changed from
the import name and the tarball for the package uses dashes instead of
underscores.

As far those underscores, that's covered in the separator section [3]:

There are a few exceptions to the no underscore '_' rule.
...
- packages where the upstream name naturally contains an underscore are
excluded from this.

Based on this rule and the Python module rule, I would say python-
sphinx-py3doc-enhanced-theme would not be an appropriate name.

So go with one of these:

python-sphinx-theme-py3doc_enhanced
python-sphinx-theme-py3doc-enhanced
python-sphinx_py3doc_enhanced_theme


[1] https://fedoraproject.org/wiki/Packaging:Naming
[2] https://fedoraproject.org/wiki/Packaging:Naming?rd=
Packaging:NamingGuidelines#Python_modules
[3] https://fedoraproject.org/wiki/Packaging:Naming?rd=
Packaging:NamingGuidelines#Separators

On Wed, Aug 24, 2016 at 3:16 AM, Garrett Holmstrom  wrote:

> On 2016-08-23 10:19, Julien Enselme wrote:
>
>> Hi,
>>
>> Recently I opened a review [1] for a new sphinx theme:
>> py3doc_enhanced_theme [2]
>>
>> The upstream name is sphinx_py3doc_enhanced_theme, so in my opinion,
>> the the package should be named python-sphinx_py3doc_enhanced_theme.
>> Furthermore, there's another sphinx theme with underscores in its
>> name: python3-sphinx_rtd_theme. So I find it logical that the package
>> is named this way.
>>
>> However, the reviewer (Zbigniew Jędrzejewski-Szmek) pointed out that:
>>
>> - Dashes are preferred (See the guidelines [3])
>> - Most themes are named with this pattern: python-sphinx-theme-
>> Therefore, it would be consistent to name the package: python-sphinx-
>> theme-py3doc-enhanced and I think that's a good point.
>>
>> A middle ground would be to use provides so the package can be
>> installed with both names, but that leaves the question about the
>> "main" name unresolved.
>>
>> Any thoughts?
>>
>
> Using hyphens in the package name keeps the package collection more
> consistent, and adding a Provides entry that uses underscores will more or
> less seamlessly take care of the case where people installing it assume it
> uses those instead.  It's a win-win to do it that way, IMO.
>
> --
> Garrett Holmstrom
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How best to handle tools which support multiple Python runtimes

[Avram Lubkin]

On Sun, Jul 17, 2016 at 6:09 AM, Björn Persson  wrote:

> It sounds like I should start trying to get sphinxcontrib-adadomain
> ported to Python 3.
>

Definitely!

> I have two possible fixes:
> >
> > The first would be to decouple the commands from the libraries. Since
> > the package name sphinx is already taken by the search engine,
> > something like python-sphinx-bin may be appropriate. Once separated,
> > the command would default to python3 since the packaging guidelines
> > say it Python 3 versions should be preferred when equivalent.
>
> If this approach is chosen, will the commands still invoke the Python 2
> version if only that one is installed?
>

No, the command would require the python3 version, the second option would
allow the python commands to be the default if it's the only one installed.


>
> > The second option would be to retain the multiple versions, but to
> > manage the links with alternatives so the unversioned commands will
> > default to whatever version is installed and again, Python 3 would be
> > preferred if both were installed.
>
> This approach seems like it would work for my use case.
>
> Ahven uses Sphinx to generate its documentation, using Sphinx's
> generated makefile that invokes sphinx-build. I have ahven.spec
> regenerate the documentation, but the makefile is generated upstream.
> Until the Ada domain gets ported, the Ahven build will have to use the
> Python 2 Sphinx, but I'd rather not encode that in ahven.spec. I want
> to keep that dependency contained in python-sphinxcontrib-adadomain.
> Ahven shouldn't need to even know that Sphinx is written in Python.
>
> If I can have python-sphinxcontrib-adadomain depend on the Python 2
> Sphinx specifically, and then have the ahven package require
> python-sphinxcontrib-adadomain, plus python-sphinx or python-sphinx-bin
> or whatever but not python2-sphinx, and invoke sphinx-build and know
> that it will run on Python 2, then I'm satisfied.
>

It sounds like the first option wouldn't work for your use case, since you
have a hard Python 2 dependency until sphinxcontrib-adadomain gets a Python
3 package. The only way it could work would be to modify the make file
during the build. The second option would work as long as you don't have
python3-sphinx installed during the package build. That should be fine in a
mock build, but if someone wanted to do a rebuild on their regular system
and had python3-sphinx installed, they'd have to set the sphinx version
with the alternatives command.


It seems like the second option, using alternatives, would be the preferred
method so as to not break things. My current thinking is to implement this
in the next package update, but to keep Python 2 as the default (if both
are installed) for Fedora 24, then make Python 3 the default in Rawhide and
Fedora 25.

Avram
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How best to handle tools which support multiple Python runtimes

[Avram Lubkin]

I'm a co-maintainer for the python-sphinx package. There's a bug [1] I'd
like to address, but I'd like some input on what I was thinking. There was
some discussion about this on FPC ticket [2], but nothing workable really
came out of that. I also attempted to get input [3] from the Sphinx
community, but didn't receive a response.

For background, python-sphinx is available for both Python2 and Python3. It
is primarily a library, but provides four commands for convenience:
sphinx-build, sphinx-quickstart, sphinx-apidoc, sphinx-autogen. Here's an
example of how these commands are currently made available to the user:

/usr/bin/sphinx-build -> sphinx-build-2
/usr/bin/sphinx-build-2 -> sphinx-build-2.7
/usr/bin/sphinx-build-2.7 (#!/usr/bin/python2)
/usr/bin/sphinx-build-3 -> sphinx-build-3.4
/usr/bin/sphinx-build-3.4 (#!/usr/bin/python3)

It should be noted, all of these commands are just used to call entry
points and don't have any of their own logic. Here are their equivalents:

sphinx-buildpython -m sphinx
sphinx-quickstartpython -m sphinx.quickstart
sphinx-apidoc python -m sphinx.apidoc
sphinx-autogen   python -m sphinx.ext.autosummary.generate

Sphinx itself isn't Python version specific and maintains compatibility
regardless of what Python version you are using or if you switch back and
forth. Potentially there are some Sphinx extensions that are Python version
dependent, but I am not aware of any.

Use cases for Sphinx are all over the place. For example, I rarely use the
commands and call sphinx through setuptools 99% of the time. Other people
use the commands exclusively, and still others use the makefile created by
sphinx-quickstart as their primary way to call it.

It's this last one is where we are seeing the biggest problem and is
described in the bug. Essentially, sphinx-quickstart-3 is used to create a
makefile which lists sphinx-build as the build command. But sphinx-build is
currently linked to the python2 version, which may not be expected, and
won't necessarily be installed.

It was suggested the makefile should be changed so the Python version that
was used for sphinx-quickstart should be used for sphinx-build.
Unfortunately, that would make the file less portable.

I have two possible fixes:

The first would be to decouple the commands from the libraries. Since the
package name sphinx is already taken by the search engine, something like
python-sphinx-bin may be appropriate. Once separated, the command would
default to python3 since the packaging guidelines say it Python 3 versions
should be preferred when equivalent.

The second option would be to retain the multiple versions, but to manage
the links with alternatives so the unversioned commands will default to
whatever version is installed and again, Python 3 would be preferred if
both were installed.

Does anyone have any preferences, thoughts or alternative approaches?

Avram

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1321413
[2] https://fedorahosted.org/fpc/ticket/612
[3] https://groups.google.com/forum/#!topic/sphinx-dev/vdFeOEj4EKg
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Anyone know how to contact maintainer Salimma?

[Avram Lubkin]

Thanks Haïkel. I'll take you up on that if needed, but assuming I don't
hear from him soon, I'll put in a request to take over the package. Sphinx
sees a lot of development, so we need to make sure we keep the latest
maintained in rawhide. The current version is from March 2015.


On Thu, Jun 30, 2016 at 5:20 AM, Haïkel <hgue...@fedoraproject.org> wrote:

> 2016-06-30 4:59 GMT+02:00 Avram Lubkin <av...@rockhopper.net>:
> >
> > I've been trying to contact Salimma, Michel Alexandre Salim, for the last
> > month. I've been trying to update python-sphinx which hasn't had an
> update
> > since last fall. Worked through all of the issues, but maintainer hasn't
> > responded to commit request, email, or bug reports.
> >
> > Bug report for newest version of Sphinx with needinfo flag.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1323202
> >
> > Anyone have any info?
> >
>
> I see builds from him june, 8 in Koji so he shouldn't be far away.
> Meanwhile, you can send me your patch or add it in the bugzilla and
> I'll apply it in rawhide as provenpackager.
>
>
> >
> > Thanks
> >
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> >
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> >
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Anyone know how to contact maintainer Salimma?

[Avram Lubkin]

I've been trying to contact Salimma, Michel Alexandre Salim, for the last
month. I've been trying to update python-sphinx which hasn't had an update
since last fall. Worked through all of the issues, but maintainer hasn't
responded to commit request, email, or bug reports.

Bug report for newest version of Sphinx with needinfo flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1323202

Anyone have any info?


Thanks
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Review Swap: Python Packages

[Avram Lubkin]

I have a couple of simple Python packages that need to be reviewed. Will
review yours in return.

https://bugzilla.redhat.com/show_bug.cgi?id=1347006:
python-sphinxcontrib-spelling
https://bugzilla.redhat.com/show_bug.cgi?id=1340619: python-imagesize

Thanks,

Avram
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Avram Lubkin]

As many others have expressed, third-party RPMs tend to be done very
poorly, Oracle Java is a good bad example. That said, if it's something a
user wants to install on their system, that's their prerogative, but it's
not part of Fedora and shouldn't be. What we could do is make it easier to
install and enable third-party repos, then you actively have to enable them
and supposedly you know what you're doing (or are blindly following
something you found on Google). For me, I use repos from two providers,
Google and RPM Fusion. I think that's pretty common I add the repos in a
script I use for new desktop builds. For Google I cat out a repo file and
for RPM Fusion I pull down their repo RPM. Being able to dnf install a
third party repo would be a cleaner and I wouldn't mind this approach. I
would guess there's no legality concern because it's just adding a repo
file, but that's for the lawyers to decide.

As far as GUI tools for installing and managing software. I never use them
and I think that's common for "power users". That said, I could care less
what they do, but expect I can have the same capabilities on the command
line, and would expect those capibilities to be available through DNF.

On containerization/sandboxing, I see this as useful from a security
perspective, but not for software installation. What I see in the
commercial world with SCL is developers don't even try to make their
software run natively. Instead they pull a ton of libraries/modules into an
SCL environment, package it all in a huge RPM, and then never update the
included libraries. I think it would be more useful to work towards some
sort of automatic sandboxing and decouple that from software installation.

Avram

On Wed, Jun 15, 2016 at 8:55 AM, Michael Catanzaro 
wrote:

> On Wed, 2016-06-15 at 08:57 +0100, Tom Hughes wrote:
> > I have far more worries about third party rpms which can put files
> > anyway, run any scriptlets they like at install time, and generally
> > interfere with the system as a whole.
>
> Yeah, I'm not sure I like this part of the plan either. The goal is to
> make it as easy as possible to package software for Fedora, but I'm
> thinking that anyone who wants to distribute an RPM repo with metadata
> enabled in Fedora ought to be required to follow our packaging
> guidelines. That Chrome RPM seems like a weird case... but if Google's
> RPM sucks, just imagine what other vendors will do. You can horribly
> break the user's system with a bad RPM; there was a recent "dnf
> uninstalls sqlite" bug caused by some third-party RPM that bundles
> sqlite and also Provides it
>
> With Flatpak, it's indeed less of an issue. Your Flatpak might suck,
> but it can't hurt the system.
>
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Alternatives for python versions

[Avram Lubkin]

I wasn't able to find much recent discussion on this, but I'm a bit
frustrated that there is so much manual work being done creating symlinks
when a system already exists for that.

It seem many projects which support both python2 and python3 are depending
on a hardcoded shebang, install order, or symlink creation in the spec file
to set which version of python to use. It also seems the py*_build macros
are hardcoded to use a versioned python interpreter for shebang lines.

Frankly I feel like I should be able to use /usr/bin/python or /usr/bin/env
python and that should point to a non version-specifc python interpreter.
If I have definite dependencies on a specific interpreter, then it is my
responsibility to set my shebang appropriately. Otherwise, if my project
has an unversioned executable, I have to change it based on my will and the
Fedora version, rather than the will of the end user. Maybe they prefer
python2, python3, or some other distribution of python becomes popular
later (pypy?). If I don't have hard dependencies, why should I force a
version? And why should I need to have conditionals on the Fedora version
or maintain two spec files?

Assuming an end user never touches the default configuration, dependencies
should already be taken care of with python_provides since unversioned
dependencies should default to the release default.

Whether /usr/bin/python is symlinked using alternatives or another method,
the py*_build macros should have a mechanism to overwrite the executable
value.

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

Re: 15 thousands python3-* packages for Fedora

[Avram Lubkin]

I'd suggest running pylint against the packages and skipping anything below
a certain threshold. There are currently over 80,000 packages on PyPi and
the vast majority are poorly written.

I think a more worthwhile effort would be to use the PyPi package rankings (
http://pypi-ranking.info/alltime) and identify any packages in say the top
500 that don't currently have Fedora packages or aren't included in the
standard library.


On Thu, May 19, 2016 at 2:51 AM, Miroslav Suchy  wrote:

> Hi,
> I just finished packaging of 15 634 python3-* packages for Fedora.
>   https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/
>   You can click on Builds and Monitoring tab. But be aware that those
> pages are HUGE (40MB) and they are loading and rendering several
> minutes. Tab "Packages" is timeouting and this will be fixed in next
> release.
>
> I am now building python2-* packages too:
>   https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/
>
> This is only for rawhide and for statistic purposes, but there will be
> more. Read on.
>
> Once the build of python2-* packages will finish, I gather the data and
> build those packages once again in other project. Packages which
> succeeded in both PyPI2 and PyPI3 projects will be build with both
> python2-* and python3-* subpackages. Everything else will be build with
> only one subpackage.
>
> Why I am doing this?
> Because I can. :) While I can imagine several obvious scenarios how this
> can help Fedora users, I anticipate there are some use cases which I can
> not imagine now, and which will surprise me for sure.
>
> Why I'm writing this?
> This projects is not yet finished. But this is first result, which can
> be used/tested/remixed. Once this rebuilds for all Fedoras and Epels
> will be finished I will announce it to Fedora users. But right now I'm
> focused on you - developers.
> These packages were automatically generated by pyp2rpm. They may work
> (or not). So you can create some (automated) tests which can test
> functionality of all those packages. You can look why your favorite
> module failed (there is still 50k packages which are failing to build
> now) and suggest improvements to pyp2rpm:
>   https://github.com/fedora-python/pyp2rpm
> Or come with something else which can raise the quality of those
> packages. The future is open and waiting for your ideas.
>
> If you have any question or idea (anything missing in our API of CLI
> tools?), do not hesitate to contact me.
>
> Mirek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Avram Lubkin]

On Thu, May 12, 2016 at 8:47 AM, Jóhann B. Guðmundsson 
wrote:

>
>
> On 05/12/2016 08:07 AM, Tomasz Torcz wrote:
>
>> On Thu, May 12, 2016 at 09:36:32AM +0200, Jan Kurik wrote:
>>
>>> = Proposed System Wide Change: Use /etc/distro.repos.d as default
>>> reposdir =
>>> https://fedoraproject.org/wiki/Changes/ReposInEtcDistroReposD
>>>
>>> Change owner(s):
>>> * Neal Gompa 
>>> * Jan Silhan 
>>>
>>>
>>> == Detailed Description ==
>>> For DNF 2.0 in Fedora 25, the DNF team would like to make the default
>>> repository configuration directory /etc/distro.repos.d. In contrast to
>>> /etc/yum.repos.d (current default path), /etc/distro.repos.d path is a
>>> package manager agnostic name and less misleading. The configuration
>>> files are currently used by DNF, PackageKit, and Yum. The proposed
>>> location more accurately reflects the nature of the repositories, and
>>> also implies that other tools can look there for repository
>>> information. Note: current default repository configuration directory
>>> /etc/yum.repos.d will still be supported by package managers but
>>> /etc/distro.repos.d would be preferred default path.
>>>
>>Shouldn't that be /usr/lib/distro.repos.d (for distribution-provided
>> data) with usual rules for overriding/masking in /etc/distro.repos.d (for
>> local administrator)?
>>
>>
> More like /usr/lib/rpm.repos.d to be generic, distro and 3rd party
> agnostic but yeah this should reside there these days . . .
>
> JBG
>


I like rpm.repos.d since that is accurate to what type of repo it is and
leaves the door open for other types of repos to follow the convention. I
would argue the correct place is /etc/rpm.repos.d since it is not data but
rather config information. If the enable argument was specified outside of
the repo information, then I could see the repo information being
considered data, but as it is, the appropriate place seems, /etc/rpm.repos.d

As far as anything more generic, like packages.repos.d or disto.repos.d, I
think that would only be appropriate if the file suffix was changed from
.repo to .rpm so any other potential repo types could be stored there. But
that opens the door to which package owns the directory and that directory
already gets cluttered, so it's best to keep them separate.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: krop and python3

[Avram Lubkin]

>From the looks of things the source is a mess, It got a -3.26/10 with
pylint and -9.29/10 with python3-pylint. While some of those are style
issues, many are functional. I think you're going to find one problem after
another. It looks like you moved it to use python3 last month. If it's
working with python2, then I would revert to use python2 for Fedora 23 and
work with upstream to get it cleaned up for Fedora 24.


On Sun, Apr 24, 2016 at 1:28 PM, Avram Lubkin <av...@rockhopper.net> wrote:

> Looks like the version argument was deprecated and later removed. The
> version of argparse 2.7 is using includes it with a deprecation warning and
> the version for 3.4 has it removed.
>
>
> On Sun, Apr 24, 2016 at 1:21 PM, Avram Lubkin <av...@rockhopper.net>
> wrote:
>
>> Based on the error and looking at the source, you should just need to fix
>> the line in /usr/lib/python3.4/site-packages/krop/krop.py:
>>
>> parser = ArgumentParser(description=__doc__, version=__version__,
>>
>> with
>>
>> parser = ArgumentParser(description=__doc__,
>>
>> ArgumentParser does not accept a version keyword
>> It doesn't in 2.7 either, but it may handle it in in a way that wouldn't
>> cause an errror.
>>
>> On Sun, Apr 24, 2016 at 12:38 PM, Raphael Groner <
>> raph...@fedoraproject.org> wrote:
>>
>>> Hi,
>>>
>>> I need some help to fix a bug ¹ with python3 and site-packages.
>>>
>>> > cd /usr/lib/python3.4/site-packages/krop/
>>>
>>> > python2 -c 'import krop ; krop.main()'
>>> → dialog
>>>
>>> > python3 -c 'import krop ; krop.main()'
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "/usr/lib/python3.4/site-packages/krop/krop.py", line 25, in main
>>> formatter_class=RawTextHelpFormatter)
>>> TypeError: __init__() got an unexpected keyword argument 'version'
>>>
>>> Besides that error, the start script in %{_bindir}/krop is b0rken and
>>> should just work for users clicking on the desktop icon.
>>>
>>> ¹ https://bugzilla.redhat.com/show_bug.cgi?id=1321376
>>> ___
>>> python-devel mailing list
>>> python-devel@lists.fedoraproject.org
>>>
>>> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
>>>
>>
>>
>
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: krop and python3

[Avram Lubkin]

Looks like the version argument was deprecated and later removed. The
version of argparse 2.7 is using includes it with a deprecation warning and
the version for 3.4 has it removed.


On Sun, Apr 24, 2016 at 1:21 PM, Avram Lubkin <av...@rockhopper.net> wrote:

> Based on the error and looking at the source, you should just need to fix
> the line in /usr/lib/python3.4/site-packages/krop/krop.py:
>
> parser = ArgumentParser(description=__doc__, version=__version__,
>
> with
>
> parser = ArgumentParser(description=__doc__,
>
> ArgumentParser does not accept a version keyword
> It doesn't in 2.7 either, but it may handle it in in a way that wouldn't
> cause an errror.
>
> On Sun, Apr 24, 2016 at 12:38 PM, Raphael Groner <
> raph...@fedoraproject.org> wrote:
>
>> Hi,
>>
>> I need some help to fix a bug ¹ with python3 and site-packages.
>>
>> > cd /usr/lib/python3.4/site-packages/krop/
>>
>> > python2 -c 'import krop ; krop.main()'
>> → dialog
>>
>> > python3 -c 'import krop ; krop.main()'
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/lib/python3.4/site-packages/krop/krop.py", line 25, in main
>> formatter_class=RawTextHelpFormatter)
>> TypeError: __init__() got an unexpected keyword argument 'version'
>>
>> Besides that error, the start script in %{_bindir}/krop is b0rken and
>> should just work for users clicking on the desktop icon.
>>
>> ¹ https://bugzilla.redhat.com/show_bug.cgi?id=1321376
>> ___
>> python-devel mailing list
>> python-devel@lists.fedoraproject.org
>>
>> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
>>
>
>
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Additional python34 components for epel7

[Avram Lubkin]

So what should package maintainers do? I modified a package to use
python3_pkgversion and it builds fine if with_python3 is set, but it
doesn't seem to be set in the EPEL 7 build environment. I noticed a couple
packages enable it by default. Is that what we should be doing? Or should
we just build it into python/python3_epel7 in copr for now, and it so how?

Avram


On Mon, Jan 4, 2016 at 2:08 PM, Jason L Tibbitts III 
wrote:

> > "DF" == Denis Fateyev  writes:
>
> DF> If we just could work "the same SRPMS name" problem around ;-)
> DF> Healthy repos with the master branch orphaned [1] may look a little
> DF> weird to users...
>
> That is not abnormal for EPEL-only packages, though.  The dead.package
> file in master should simply indicate that the package is EPEL-only.
>
>  - J<
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
>
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

[EPEL-devel] Re: Additional python34 components for epel7

[Avram Lubkin]

So what should package maintainers do? I modified a package to use
python3_pkgversion and it builds fine if with_python3 is set, but it
doesn't seem to be set in the EPEL 7 build environment. I noticed a couple
packages enable it by default. Is that what we should be doing? Or should
we just build it into python/python3_epel7 in copr for now, and it so how?

Avram


On Mon, Jan 4, 2016 at 2:08 PM, Jason L Tibbitts III 
wrote:

> > "DF" == Denis Fateyev  writes:
>
> DF> If we just could work "the same SRPMS name" problem around ;-)
> DF> Healthy repos with the master branch orphaned [1] may look a little
> DF> weird to users...
>
> That is not abnormal for EPEL-only packages, though.  The dead.package
> file in master should simply indicate that the package is EPEL-only.
>
>  - J<
> ___
> python-devel mailing list
> python-de...@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/python-de...@lists.fedoraproject.org
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

New Package: python-scandir

[Avram Lubkin]

Just thought I'd let this list know python-scandir is now in the stable
repos. The code itself has been accepted as an enhancement to the os module
in Python 3.5, but the original independent module is great for older
versions. I tend to use as an optional speedup when I am heavily using
os.walk() or os.listdir(). The maintainer has been very responsive.

https://github.com/benhoyt/scandir
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Self Introduction: Avram Lubkin

[Avram Lubkin]

Hello, I'm Avram. I just submitted my first package, python-scandir. I've
been a system engineer working with Linux for the last 10 years. Several
years ago, in what seems like another life, I worked for Red Hat. Now I'm
an independent consultant while I work on a project I'll be releasing as
open source in the not too distant future. I cut my teeth in large
enterprises so I focus heavily on security and scalability.

In the non-computer world, I like to rock climb, hike, cook vegan food, and
do ultralight traveling.

https://bugzilla.redhat.com/show_bug.cgi?id=1245845
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct