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 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
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 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
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
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
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
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
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
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
> > 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
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
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&query=$.results[?(@.name.startsWith( "f"))].name&label=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&query=$.results[?(@.name.startsWith( "e"))].name&label=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
On Mon, Nov 28, 2016 at 3:11 PM, Avram Lubkin 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
Seems like this issue is almost a year old. On Wed, Sep 21, 2016 at 9:31 AM, Ville Skyttä wrote: > On Wed, Sep 21, 2016 at 4:21 PM, Avram Lubkin > 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
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
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 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
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
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?
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 wrote: > 2016-06-30 4:59 GMT+02:00 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? > > > > 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?
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
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
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
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 ( 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
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
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 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