Self Introduction: 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

Re: Fedora development of Snap packages

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

Review Swap: Python Packages

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

Re: 15 thousands python3-* packages for Fedora

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 (

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

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

How best to handle tools which support multiple Python runtimes

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

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

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

Anyone know how to contact maintainer Salimma?

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

Re: Anyone know how to contact maintainer Salimma?

, 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

Upstream Release Monitoring builds for EL7 instead of Rawhide

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

Re: Upstream Release Monitoring builds for EL7 instead of Rawhide

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

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

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

Re: State of LuaTeX in F25/rawhide

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 luatex

Fedora/EPEL GitHub Badges

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

Re: Fedora 29 Mass Rebuild

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

Re: Fedora 29 Mass Rebuild

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

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

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

Re: Unresponsive Maintainer: python-ldap3

y, 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) fo

Unresponsive Maintainer: python-ldap3

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?

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

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

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

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

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

'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 genera

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

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

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

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

New Package: python-scandir

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()

Alternatives for python versions

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

Re: Additional python34 components for epel7

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

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

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

Re: krop and python3

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 an

Re: krop and python3

ing 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

Re: python34 for EPEL6

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

Re: python34 for EPEL6

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

[EPEL-devel] Re: python34 for EPEL6

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

[EPEL-devel] Re: python34 for EPEL6

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

[EPEL-devel] Re: python34 for EPEL6

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

Re: Renaming python to python2

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

Re: Renaming python to python2

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 >

Re: Renaming python to python2

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

Re: Renaming python to python2

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

Re: Renaming python to python2

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

[EPEL-devel] Requirements for SRPM names

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,

[EPEL-devel] Re: Requirements for SRPM names

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

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

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