[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

version as /usr/bin/unversioned-python. Tomas On Fri, Jul 23, 2021 at 1:36 PM Tomas Orsava wrote: > If I understand what you're describing correctly, this is not a bug. > In the default state, /usr/bin/python should *not* exist, that's correct > behaviour. If you want it to exist, y

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

r packages and >> managed by >> > > alternatives. >> > >> > I hit "Send" to early, apologies, here is the rest of my email: >> > >> > Could you please share the package spec file with us (Python Maint >> team at Red &g

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

On 4/8/21 10:17 AM, Panu Matilainen wrote: On 4/7/21 4:16 PM, Panu Matilainen wrote: On 4/7/21 2:21 PM, Tomas Orsava wrote: On the other hand, I understand where you're coming from: we have fought battles with unintended use of our tools too (e.g. sudo pip breaking dnf). But given the scope

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

On 4/7/21 12:45 PM, Panu Matilainen wrote: On 4/7/21 1:12 PM, Tomas Orsava wrote: On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

On 4/7/21 11:38 AM, Panu Matilainen wrote: On 4/7/21 12:06 PM, Miro Hrončok wrote: On 07. 04. 21 10:45, Panu Matilainen wrote: I'm starting to think the right thing to do is to move %check to run after %build rather than %install. That would completely eliminate arguments over what is proper 

[EPEL-devel] pybind11 in RHEL 8, but no action needed

ndPolicies#Policy All the best, and let me know if you have any questions, Tomas Orsava ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Condu

Disk space minimization of Python

Hi, I have opened an upstream discussion about disk space minimization of Python, take a look: https://discuss.python.org/t/disk-space-minimization-for-python-distributors/5447 All the best, Tomas ___ python-devel mailing list --

[EPEL-devel] Re: EPEL repos packaged for Fedora (for repoquery)

On 6/30/20 9:10 PM, Miro Hrončok wrote: On 30. 06. 20 21:03, Kevin Fenzi wrote: I don't think a package-review is needed? It would just be unretiring the fedora branches of an existing package? Technically, the package is "retired for 8+ weeks" on Fedora. Hence a new review request. That

New pipenv 2020.6.2 ready for testing in a copr repo

Hi, yet newer upstream version of pipenv, 2020.6.2, was released and is ready for you in copr: https://copr.fedorainfracloud.org/coprs/g/python/pipenv/ All the best, Tomas On 5/28/20 5:11 PM, Tomas Orsava wrote: Hi, upstream released a brand new version of `pipenv` this morning, and we've

Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

On 6/15/20 10:10 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ModularReposSubpackage == Summary == Reintroduce the fedora-repos-modular package. Have the /etc/yum.repos.d/*-modular.repo files in it instead of fedora-repos. We install/keep fedora-repos-modular by default, users

Re: Draft of New Python Packaging Guidelines

On 6/9/20 12:15 PM, Petr Viktorin wrote: On 2020-06-08 12:15, Tomas Orsava wrote: On 6/8/20 11:58 AM, Petr Viktorin wrote: On 2020-06-05 16:12, Tomas Orsava wrote: On 6/5/20 2:26 PM, Petr Viktorin wrote: On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote

Monthly highlights from the Red Hat's Python-maint team, May 2020

Hi, we're the Python-maint team from Red Hat, and we'd like to experiment with sharing with you what we are working on from month to month. There are some things we should not disclose (such as embargoed CVEs), but the majority of what we do is out in public. Please let us know if you find

Re: [Fedora-packaging] Re: Let's standardize the way to disable tests during RPM build?

On 6/9/20 3:01 PM, Nicolas Mailhot via devel wrote: Le mardi 09 juin 2020 à 14:56 +0200, Nicolas Mailhot a écrit : Le mardi 09 juin 2020 à 14:35 +0200, Vít Ondruch a écrit : The proposal was to optionally disable test. When somebody asked why, the answer was bootstrapping. But we know how to

Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

at 16:10 +0200, Tomas Orsava wrote: Hi, I think it would be useful to have a standard way of disabling the running of tests during RPM build (in the %check section of a spec file). I see a lot of packages already having %bcond's or other macro definitions to archieve this, but each package has

Re: Draft of New Python Packaging Guidelines

On 6/8/20 11:58 AM, Petr Viktorin wrote: On 2020-06-05 16:12, Tomas Orsava wrote: On 6/5/20 2:26 PM, Petr Viktorin wrote: On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text

Re: Let's standardize the way to disable tests during RPM build?

On 6/5/20 4:46 PM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 04:38:03PM +0200, Miro Hrončok wrote: On 05. 06. 20 16:26, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote: Hi, I think it would be useful to have a standard way of disabling

Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

On 6/5/20 4:39 PM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 10:28:39AM -0400, Paul Wouters wrote: Or just a new option to rpmbuild that skips %check ? It exists already: rpmbuild --nocheck. It's not wired into the rest of the stack - eg. you cannot start a Koji build with checks

Re: Let's standardize the way to disable tests during RPM build?

On 6/5/20 4:26 PM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote: Hi, I think it would be useful to have a standard way of disabling the running of tests during RPM build (in the %check section of a spec file). I see a lot of packages already having

Re: Draft of New Python Packaging Guidelines

On 6/5/20 2:26 PM, Petr Viktorin wrote: On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text itself as comments in the document. Comments about the subject matter are inlined

Let's standardize the way to disable tests during RPM build?

Hi, I think it would be useful to have a standard way of disabling the running of tests during RPM build (in the %check section of a spec file). I see a lot of packages already having %bcond's or other macro definitions to archieve this, but each package has their own way, there's no real

Re: Draft of New Python Packaging Guidelines

On 6/5/20 2:22 PM, Petr Viktorin wrote: On 2020-06-05 13:58, Tomas Orsava wrote: On 6/5/20 1:43 PM, Miro Hrončok wrote: On 05. 06. 20 11:51, Tomas Orsava wrote: [...] I see what you mean. On the other hand, that's a pretty horrible error message format (posting in it's entirety

Re: Draft of New Python Packaging Guidelines

On 6/5/20 1:43 PM, Miro Hrončok wrote: On 05. 06. 20 11:51, Tomas Orsava wrote: ## PyPI parity Every Python package in Fedora **SHOULD** also be available on [the Python Package Index](https://pypi.org) (PyPI). The command `pip install PROJECTNAME` **MUST** install the same package

Re: Draft of New Python Packaging Guidelines

On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text itself as comments in the document. Comments about the subject matter are inlined below: On 4/30/20 3:41 PM, Petr Viktorin wrote: ### Dist-info metadata Each

Re: Draft of New Python Packaging Guidelines

Hi, I have left a few notes about the text itself as comments in the document. Comments about the subject matter are inlined below: On 4/30/20 3:41 PM, Petr Viktorin wrote: ### Dist-info metadata Each Python package **MUST** include *Package Distribution Metadata* conforming to [PyPA

Brand new pipenv 2020.5.28 ready for testing in a copr repo

version. All the best, Tomas Orsava ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code

Re: Redesigning the %python_provide macro from scratch

On 5/26/20 11:52 AM, Miro Hrončok wrote: On 26. 05. 20 11:29, Tomas Orsava wrote: On 5/25/20 7:42 PM, Miro Hrončok wrote: On 25. 05. 20 18:33, Tomas Orsava wrote: On 4/19/20 4:55 PM, Miro Hrončok wrote: 4) Make it so that for given arguments, the macro will only expand to something once per

Re: Redesigning the %python_provide macro from scratch

On 4/19/20 4:55 PM, Miro Hrončok wrote: Hello Python packagers. After touching the %python_provide topic in: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/SSJLPWSGFGPYRSHXQZDR7JNQXSDGGX3Z/ I have realized several things I don't like about

Monthly highlights from the Red Hat's Python-maint team, April 2020

Hi, we're the Python-maint team from Red Hat, and we'd like to experiment with sharing with you what we are working on from month to month. There are some things we should not disclose (such as embargoed CVEs), but the majority of what we do is out in public. Please let us know if you find

Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

Hello everyone. I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. python39 to python3.9. *Motivation:* When you install an additional Python interpreter, the command that runs it contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. dnf install

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

On 3/30/20 2:33 PM, Petr Pisar wrote: On Mon, Mar 30, 2020 at 01:57:22PM +0200, Miro Hrončok wrote: On 30. 03. 20 13:52, Petr Pisar wrote: If I undeestand the proposal correctly there there will be an ELN branch or a name space. But not by default. Only for those packages that reject the

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

On 3/30/20 12:54 PM, Aleksandra Fedorova wrote: On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch wrote: It is kind of irony, that the ELN branch idea is still rejected. I've made several attempts to explain this decision. You are ignoring them. Therefore there will be PRs coming from Stephen's

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On 3/25/20 4:47 PM, Stephen Gallagher wrote: Starting a new sub-thread. On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova wrote: As Ben is on PTO, I'd like to present the System-Wide Change https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose == Summary == The goal of the ELN

[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?

On 2/13/20 5:18 AM, Orion Poplawski wrote: On 1/30/20 8:39 AM, Miro Hrončok wrote: On 30. 01. 20 16:32, Orion Poplawski wrote: Folks -     Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6.  From the 8.2 beta: Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)

Re: Modularity: The Official Complaint Thread

On 11/14/19 10:52 PM, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 4:49 PM Miro Hrončok > wrote: On 14. 11. 19 22:30, Stephen Gallagher wrote: > On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok mailto:mhron...@redhat.com>> wrote: > >> Easy is

Re: DNF: "There are following alternatives to this package"

On 09/13/2018 06:43 PM, Mathieu Bridon wrote: On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote: We'd like to propose a new functionality for dnf: When a user tries to install a package XYZ and dnf doesn't find it, dnf would recommend them alternative packages. These offered packages would

Re: DNF: "There are following alternatives to this package"

On 09/13/2018 06:43 PM, Mathieu Bridon wrote: On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote: We'd like to propose a new functionality for dnf: When a user tries to install a package XYZ and dnf doesn't find it, dnf would recommend them alternative packages. These offered packages would

DNF: "There are following alternatives to this package"

the best, Tomas Orsava ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https

DNF: "There are following alternatives to this package"

the best, Tomas Orsava ___ 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

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

project.org> Cc: "Kamil Dudka" <kdu...@redhat.com> Sent: Wednesday, May 2, 2018 4:49:18 PM Subject: Re: Prioritizing ~/.local/bin over /usr/bin on the PATH On Wed, May 02, 2018 at 10:35:28AM -0400, Siteshwar Vashisht wrote: - Original Message - From: "Tomas Orsa

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 05/02/2018 11:57 PM, Iain Rae wrote: On 02/05/18 17:50, Kamil Dudka wrote: On Wednesday, May 2, 2018 4:25:58 PM CEST Iain Rae wrote: if they've got sudo privs to install software in the system area as root then any malicious program is going to emulate su/sudo in which case you're rooted

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 05/02/2018 03:23 PM, Tomas Orsava wrote: Hi! I'd like to propose putting the ~/.local/bin in front of the /usr/bin on the PATH. Currently /usr/bin has priority over ~/.local/bin, which causes a [bug] where the old system-installed executable written in Python (from /usr/bin) is launched

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 05/02/2018 03:23 PM, Tomas Orsava wrote: Hi! I'd like to propose putting the ~/.local/bin in front of the /usr/bin on the PATH. Currently /usr/bin has priority over ~/.local/bin, which causes a [bug] where the old system-installed executable written in Python (from /usr/bin) is launched

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 05/02/2018 03:30 PM, Stephen Gallagher wrote: On Wed, May 2, 2018 at 6:24 AM Tomas Orsava <tors...@redhat.com <mailto:tors...@redhat.com>> wrote: Hi! I'd like to propose putting the ~/.local/bin in front of the /usr/bin on the PATH. Currently /usr/bin

Prioritizing ~/.local/bin over /usr/bin on the PATH

Hi! I'd like to propose putting the ~/.local/bin in front of the /usr/bin on the PATH. Currently /usr/bin has priority over ~/.local/bin, which causes a [bug] where the old system-installed executable written in Python (from /usr/bin) is launched, but it finds new Python sources (installed

What happened to Platform-Python?

to python-devel ML soon. All the best, Tomas Orsava ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

What happened to Platform-Python?

to python-devel ML soon. All the best, Tomas Orsava ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Warning before sudo pip'ing?

Hi! The warning when sudo pip installing is deployed in rawhide! Package version: python-pip-9.0.1-6.fc26. Cheers, Tomas On 02/10/2017 06:35 PM, Tomas Orsava wrote: Hi! On the last FESCo meeting while discussing the sudo pip Fedora [Change], maxamillion proposed that it might be useful

Warning before sudo pip'ing?

). What do you think? [Change] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe Regards, Tomas Orsava ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le

portingdb.xyz is back!

We're pleased to announce that the Python 3 PortingDB is back at it's usual location: http://portingdb.xyz/ Happy New Year! Tomas Orsava ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel

Re: Making sudo pip Safe

On 12/12/2016 05:39 AM, Nick Coghlan wrote: On 11 December 2016 at 01:33, Donald Stufft wrote: On Dec 10, 2016, at 8:10 AM, Nick Coghlan wrote: P.S. For folks wondering what the problem with "--user" is on Debian/Ubuntu, as far as I know it's mainly the

Re: Making sudo pip Safe

On 12/07/2016 02:47 PM, Konstantin Zemlyak wrote: Michal Cyprian wrote: there is a long-standing problem that `sudo pip install` cannot be safely used in Fedora. Many users don't know about this and break python packages on theirs systems. Packages installed using this command can conflict

PortingDB is temporarily moved to a new address

for the inconvenience. Tomas Orsava [0] http://portingdb.xyz/ ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: [RFC] RPM's Python dependency generator

On 12/01/2016 02:36 PM, Igor Gnatenko wrote: We'll see how it will go. we have depgen for pkgconfig, libraries, etc. for many years and people don't go and debug it immediately, but for many of packages it will help a lot. Anyhow, we'll see after couple of releases. Yeah, absolutely. When it's

Re: [RFC] RPM's Python dependency generator

On 11/30/2016 02:44 PM, Neal Gompa wrote: On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava <tors...@redhat.com> wrote: I don't think the depgen should be enabled by default, at least not in the foreseeable future. IIRC it's not that well implemented—e.g. I believe it doesn't read requiremen

Re: PEP: Distributing a Subset of the Standard Library

On 09/07/2016 06:13 PM, Nick Coghlan wrote: On 7 September 2016 at 19:30, Tomas Orsava <tors...@redhat.com> wrote: On 09/06/2016 08:25 PM, Nick Coghlan wrote: Very interesting, although I see a pragmatic problem with trying to check for explicitly missing packages only after ch

Re: PEP: Distributing a Subset of the Standard Library

Hi! On 09/06/2016 08:25 PM, Nick Coghlan wrote: On 7 September 2016 at 02:41, Tomas Orsava <tors...@redhat.com> wrote: Hi! I'm currently writing a PEP titled "Distributing a Subset of the Standard Library" to standardize and hopefully improve the behavior of Python with

Re: PEP: Distributing a Subset of the Standard Library

I forgot to include a link to a previous discussion of this topic on the python-dev upstream mailing list: https://mail.python.org/pipermail/python-dev/2016-July/145534.html Tomas On 09/06/2016 06:41 PM, Tomas Orsava wrote: Hi! I'm currently writing a PEP titled "Distributing a S

PEP: Distributing a Subset of the Standard Library

l packages (e.g. python3-tkinter). I have a draft of the first two sections: Motivation and Specification. https://fedora-python.github.io/pep-drafts/pep-A.html The source can be found here: https://github.com/fedora-python/pep-drafts All the best, To

[EPEL-devel] Re: python34 for EPEL6

On 08/24/2016 11:39 PM, Neal Gompa wrote: 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

Re: Update python-django EPEL7

As far as I understand, someone could package it as a new package, e.g. python-django18. On 08/16/2016 07:11 PM, Igor Gnatenko wrote: It's against policies. Currently python-django has version 1.6. And 1.8 is major release. On Tue, Aug 16, 2016 at 6:17 PM, Germano Massullo

Rebasing Python, deleting patches

Hi, I'm currently rebasing Python to version 3.5.2 for Fedora 25. As many of the existing patches are no longer necessary I needed to delete or disable them. I looked through the git history of python and python3 packages, and there isn't a clear consensus on which method is preferred. While

Re: Automatic Provides: Discussion summary and plan

Yeah, I really wish I had actually pushed through the macro work I had done last year. You can see that at https://pagure.io/python-macros A spec would look like this: https://pagure.io/python-macros/blob/master/f/test1.spec And most of that is actually implemented. Note the almost complete

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

On 07/04/2016 02:43 PM, Neal Gompa wrote: On Mon, Jul 4, 2016 at 7:43 AM, Tomas Orsava <tors...@redhat.com> wrote: Hi! We have just removed the dependency generator from the proposal [0], see diff [1]. The implementation of it (backported from RPM upstream) is significantly lacking:

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[1] https://fedoraproject.org/w/index.php?title=Changes%2FAutomatic_Provides_for_Python_RPM_Packages=461233=461232 Tomas Orsava On 06/30/2016 02:20 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Automatic Provides for Python RPM Packages = https://fedoraproject.org/wiki/Changes

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

Also, hasn't this been already discussed on the python-devel Fedora mailing list? https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/3VYLAL22YPA7BSRTMRGAIAXKHXRFRGBF/ On 07/02/2016 12:13 PM, Tomas Orsava wrote: - Original Message - So

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

- Original Message - > So, the "problem" with --majorver-provides occurs when either of the > two conditions are true: > > * There's no dependency on a specific version of the Python ABI > ("python(abi) = X.Y") in the modules > * There's more than one package providing a python

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

lists.fedoraproject.org> Sent: Friday, July 1, 2016 5:43:46 PM Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM Packages On Fri, Jul 1, 2016 at 8:34 AM, Tomas Orsava <tors...@redhat.com> wrote: > I'm sorry, I could have expanded on it. > > The difference is tha

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

occur if there are multiple independent Python stacks per major version available." [1] [1] https://github.com/rpm-software-management/rpm/commit/29abb07fbf6b9ea255bd26e492c104eac8d2370f On 07/01/2016 02:23 PM, Neal Gompa wrote: On Fri, Jul 1, 2016 at 2:48 AM, Tomas Orsava <tors...@redh

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

Hi Jason! Ticket created: https://fedorahosted.org/fpc/ticket/635 Tomas - Original Message - From: "Jason L Tibbitts III" To: devel@lists.fedoraproject.org Sent: Thursday, June 30, 2016 6:33:48 PM Subject: Re: F25 System Wide Change: Automatic Provides for Python RPM

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

= Proposed System Wide Change: Automatic Provides for Python RPM Packages = > https://fedoraproject.org/wiki/Changes/ > Automatic_Provides_for_Python_RPM_Packages > > Change owner(s): > * Tomas Orsava <https://fedoraproject.org/wiki/User:Torsava> > * Miro Hroncok <

Re: Problems with scripts in a common spec file

Hi! On 05/27/2016 07:44 PM, John Dennis wrote: On 05/27/2016 10:10 AM, Tomas Orsava wrote: I think the python2-XXX package in the examples is missing something like this: Requires: %{_bindir}/sample-exec Make sense? I believe there is a misunderstanding. In your first message you said

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

Hi Rajesh! the `binclock` project is a bit problematic. As you can see in the note on the left side on the PortingDB, the upstream for this project is abandoned, emails bounce. If you go look into the Bugzilla link on the same page, you'll also find that someone has made a Python 3 patch, but

Re: Problems with scripts in a common spec file

Hi! On 05/26/2016 07:38 PM, John Dennis wrote: On 05/26/2016 08:24 AM, Tomas Orsava wrote: Hi, those are very good questions to which you should be able to find answers on the Python RPM Porting Guide [0]. You are right that this should be better covered in the packaging guidelines, sadly

New PyPI URL format for tarballs/sources

/rebase-helper Great day to all, Tomas Orsava ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

New PyPI link format for Python packages

Hi! The Python Package Index (PyPI) has decided to change the format of the URLs to download tarballs/sources. The new format is not predictable, because part of the URL is a hash of the contents of the file. [0] This means that for the vast majority of Python packages (those using PyPI to

Self Introduction: Tomas Orsava

Hi, I'm a new Red Hatter working in python-maintenance. I have submitted my first review-request: https://bugzilla.redhat.com/show_bug.cgi?id=1308956 It is the last missing dependency for a keyboard-driven, vim-like browser called qutebrowser, which I hope to package next: