Hello all,
I recently upstreamed some fixes to a new RPM dependency generator
that will be available as an option for distributions to enable. The
new generator uses python .egg data to generate Provides and Requires
in the form of pythonXegg(Y), where X is the Python major version and
Y is the mo
On Tue, Nov 17, 2015 at 3:26 AM, Nick Coghlan wrote:
> I'm not clear on what you mean by depending on an egg. Eggs are a
> binary format that isn't compatible with Linux distro packaging
> policies, since they lose too much structural information regarding
> where files should be installed for pol
On Tue, Nov 17, 2015 at 8:05 AM, Donald Stufft wrote:
>
>> On Nov 17, 2015, at 7:54 AM, Nick Coghlan wrote:
>>
>> On 17 November 2015 at 22:05, Neal Gompa wrote:
>>> and
>>> I wanted to give the Python SIG in Fedora the opportunity to try it
>>&
On Tue, Nov 17, 2015 at 8:34 AM, Donald Stufft wrote:
>
>> On Nov 17, 2015, at 8:25 AM, Neal Gompa wrote:
>> Is the format inside of the .dist-info directory the same as the older
>> .egg-info and .egg-link directories? If so, it should be easy to add
>> t
On Tue, Nov 17, 2015 at 9:44 AM, Toshio Kuratomi wrote:
>
> On Nov 17, 2015 6:06 AM, "Nick Coghlan" wrote:
>>
>> On 17 November 2015 at 23:25, Neal Gompa wrote:
>> > As for naming, I'm all ears for a better name, because if the "egg"
>&g
On Tue, Nov 17, 2015 at 9:35 AM, Donald Stufft wrote:
>
>> On Nov 17, 2015, at 9:26 AM, Neal Gompa wrote:
>>
>> The dependency generator uses pkg_resources (specifically
>> Distribution, FileMetadata, PathMetadata) to read data in the
>> .egg-info directory.
On Tue, Nov 17, 2015 at 10:43 AM, Toshio Kuratomi wrote:
>
> On Nov 17, 2015 6:47 AM, "Neal Gompa" wrote:
>>
>> That's already guaranteed by the auto-generated python(abi) requires,
>> and that would also make it hugely problematic to use in spec files
On Wed, Nov 18, 2015 at 2:48 AM, Nick Coghlan wrote:
>
> On 18 November 2015 at 02:29, Jason L Tibbitts III wrote:
> >> "NC" == Nick Coghlan writes:
> >
> > NC> If so, then there's some relevant work currently under way upstream
> > NC> to improve the interaction between Python installation
On Wed, Nov 18, 2015 at 11:32 AM, Toshio Kuratomi wrote:
>
> On Wed, Nov 18, 2015 at 5:27 AM, Neal Gompa wrote:
> > On Wed, Nov 18, 2015 at 2:48 AM, Nick Coghlan wrote:
> >> I'd been thinking using "pip install" instead of "setup.py install" in
&g
On Sun, Nov 22, 2015 at 10:11 PM, Nick Coghlan wrote:
> On 22 November 2015 at 04:18, Neal Gompa wrote:
> > Based on the feedback from you guys, I've made the changes to move to
> > pythonX.Ydist() in the dependency generator. That code has been
> > submitted as a pull
On Sun, Nov 22, 2015 at 10:17 PM, Neal Gompa wrote:
> On Sun, Nov 22, 2015 at 10:11 PM, Nick Coghlan wrote:
>
>> On 22 November 2015 at 04:18, Neal Gompa wrote:
>> > Based on the feedback from you guys, I've made the changes to move to
>> > pythonX.Ydist(
First, I would suggest checking to see if anything even uses
python-pdfminer. I use DNF's repoquery to identify things that use it.
Here's an example command you can use to identify if something depends
on it:
* sudo dnf repoquery --queryformat "%{sourcerpm}: %{reponame}"
--whatrequires "python-pdf
On Wed, Dec 30, 2015 at 3:46 PM, Orion Poplawski wrote:
> I've submitted a review for a separate python-macros package here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1294904
>
> This is what the FPC approved here
> https://fedorahosted.org/fpc/ticket/567#comment:12 to be added to the Fedora
On Mon, Feb 22, 2016 at 9:15 PM, Nick Coghlan wrote:
>
>
> Fedora 24 will be shipping with a C.UTF-8 locale:
> https://bugzilla.redhat.com/show_bug.cgi?id=902094
>
> Perhaps we should file an RFE with rpm and/or mock to run scriptlets under
> the C.UTF-8 locale rather than the C locale?
>
This is
On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok wrote:
> On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> On Mon, Mar 21, 2016 at 06:46:00PM -, Tomas Orsava wrote:
>>>
>>> Since the spec file does package both p2 and p3 versions of the
>>> executable
>>
>>
>> There's a difference bet
On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin wrote:
>
> So, a package I help maintain, python-dns is now provided by Red Hat. So I
> thought, "OK, I'll still build the python34 package to help in that effort".
> But the problem with that is, per the EPEL 7 in Python 3 Plan Draft (1), if
> Red Ha
On Mon, Mar 28, 2016 at 12:31 PM, Stephen John Smoogen wrote:
> On 28 March 2016 at 10:07, Neal Gompa wrote:
>> On Mon, Mar 28, 2016 at 11:00 AM, Avram Lubkin wrote:
>>>
>>> So, a package I help maintain, python-dns is now provided by Red Hat. So I
>>>
Hello all,
It's been a while since I messaged this list about the new dependency
generator being upstreamed into RPM[0]. Since then, I've taken your
valuable feedback and incorporated it into the version that now sits
in RPM git master[1].
A little bit ago, I pushed a package to Copr[2] that incl
On Wed, Apr 13, 2016 at 8:43 AM, Miro Hrončok wrote:
>
> Hi, this looks very good.
>
> I tried to build some arched packages and was wondering, if there shouldn't
> be %{?_isa} included at the end of the provide name?
>
> Something like:
>
> Provided form the 64bit package:
>
> python3
On Sat, Aug 20, 2016 at 6:24 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sat, Aug 20, 2016 at 05:17:59PM +0200, Igor Gnatenko wrote:
>> RPM build errors:
>> Installed (but unpackaged) file(s) found:
>>/usr/lib/python2.7/site-packages/__pycache__/site.cpython-35.pyc
>>
>>
>> This is from bu
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?
>
I think the Koji people would be interested in
On Thu, Sep 1, 2016 at 8:04 AM, Avram Lubkin wrote:
>
> 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" i
On Thu, Sep 1, 2016 at 8:33 AM, Avram Lubkin wrote:
> 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
On Tue, Sep 6, 2016 at 12:41 PM, Tomas Orsava wrote:
> Hi!
>
> I'm currently writing a PEP titled "Distributing a Subset of the Standard
> Library" to standardize and hopefully improve the behavior of Python without
> the its full standard library. This is relevant to Fedora, as we exclude
> sever
On Tue, Sep 6, 2016 at 1:00 PM, Petr Viktorin wrote:
>
> Python does not have dependency generators. Dependendency information is
> added to "setup.py" files, manually.
> Even if you got Python to start providing dist data for stdlib packages, you
> would still need to convince the developers of a
On Thu, Nov 10, 2016 at 7:49 AM, jan matejek wrote:
> Hello,
> in relation to the python single-spec initiative, I have designed a set
> of new macros that allow significant automation in building Python packages.
>
> However, these are constrained by the %python_module macro used in
> BuildRequir
On Thu, Nov 10, 2016 at 8:11 AM, jan matejek wrote:
> On 10.11.2016 14:02, Neal Gompa wrote:
>
>> Why not pull in the dependency generator I upstreamed into RPM[1] into
>> openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and
>> Mageia is using an earli
On Thu, Nov 10, 2016 at 8:16 AM, Neal Gompa wrote:
> On Thu, Nov 10, 2016 at 8:11 AM, jan matejek wrote:
>> On 10.11.2016 14:02, Neal Gompa wrote:
>>
>>> Why not pull in the dependency generator I upstreamed into RPM[1] into
>>> openSUSE? Fedora is using it
On Thu, Nov 10, 2016 at 8:24 AM, jan matejek wrote:
> On 10.11.2016 14:16, Neal Gompa wrote:
>> As far as I know, openSUSE was the *only* distribution *not* doing
>> single spec Python 2/3 packaging. Fedora[1] and Mageia[2] both do.
>
> and as far as I can tell, we're no
On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski wrote:
> Hi,
>
> [Germano Massullo, 2016-11-20]
>> We often deal with upstream developers that bundle libraries in their
>> code, so to make a package we have to debundle them, etc.
>> This time, an upstream dev. asked me what he could do to make ea
On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava wrote:
>
> I don't think the depgen should be enabled by default, at least not in the
> foreseeable future. IIRC it's not that well implemented—e.g. I believe it
> doesn't read requirements.txt for example (but I might be wrong).
> There will be a lot
On Thu, Dec 1, 2016 at 8:36 AM, Igor Gnatenko wrote:
> On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava wrote:
>> On 11/30/2016 02:44 PM, Neal Gompa wrote:
>>>
>>> On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava wrote:
>>>>
>>>> I don't think
On Wed, Dec 7, 2016 at 7:53 AM, Michal Cyprian wrote:
> - system-python (i.e. what all programs installed via DNF will use) is
> limited to site-packages under /usr, so DNF-installed software is unaffected
> by anything installed with pip
system-python is not intended for this use-case. It was
On Sat, Dec 10, 2016 at 8:10 AM, Nick Coghlan wrote:
> On 10 December 2016 at 03:09, Orion Poplawski wrote:
>> Debian deals with this by having dist-packages
>> (https://wiki.debian.org/Python). Is this not worth adopting?
>
> This would be my main question as well, as tinkering with sys.prefix
On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote:
>> Along similar lines, what do folks think of the idea of patching
>> Python 3.6 in Fedora to assume UTF-8 if it's told that it should use
>> ASCII to communicate wi
Hello all,
I've been recently somewhat involved in openSUSE stuff, and I caught
wind of a recent initiative to update their Python packaging.
Some background here: As some of you may know, for whatever unknown
reason, openSUSE has historically had separate source packages and
projects for Python
On Mon, Mar 13, 2017 at 1:14 PM, John Dulaney
wrote:
>
> Hi.
>
> Do you think it would be a good thing to sit down and compare existing macros
> and create a wiki page or similar listing opensuse's and fedora's macros
> with the ones that do the same thing side by side? It would be nice to hash
>
On Sun, Jan 14, 2018 at 7:22 AM, Igor Gnatenko
wrote:
> On Thu, 2018-01-11 at 10:37 -0500, Neal Gompa wrote:
>> Hey,
>>
>> As I was looking at the rpm.spec and fixing up a small bit of the
>> build for the Python bindings, it occurred to me that we have left
>>
On Mon, Jan 15, 2018 at 3:06 AM, Panu Matilainen wrote:
> On 01/14/2018 04:46 PM, Neal Gompa wrote:
>>
>> On Sun, Jan 14, 2018 at 7:22 AM, Igor Gnatenko
>> wrote:
>>>
>>> On Thu, 2018-01-11 at 10:37 -0500, Neal Gompa wrote:
>>>>
>>>>
On Thu, Feb 1, 2018 at 10:21 AM, Nick Coghlan wrote:
> On 1 February 2018 at 23:54, Petr Viktorin wrote:
>> Honestly, I'm not sure we want to use this in Fedora. Is anyone here into
>> reproducible builds, to make a better argument for this?
>
> I believe rpmbuild (et al) all set SOURCE_DATE_EPOC
On Wed, Apr 4, 2018 at 11:37 AM, Eduard Lucena wrote:
> I was reseraching a little bit and I found that this project is made in
> python with Django. Is it possible that we can take this project and do an
> implementation of our own?
>
I don't know if there's a reason _not_ to take over the proje
On Tue, May 29, 2018 at 11:14 AM Miro Hrončok wrote:
> Hi, this is just a summary about what is currently happening with Python
> 3.7 in Fedora [0].
> Upstream has delayed the first RC a bit [1]. So we are not pushing
> anything to rawhide just yet. However I'm working on a "topsort rebuild"
> i
On Sun, Jul 15, 2018 at 3:02 AM Nick Coghlan wrote:
>
> Hi folks,
>
> Facebook just published an interesting bit of tech that uses squashfs
> to create single-file executables that don't require a pre-installed
> container engine to execute, but do place some more significant
> demands on the FUSE
On Mon, Sep 10, 2018 at 7:23 AM Miro Hrončok wrote:
>
> Hi, according to my query, latest build of your package failed the
> Taskotron check that checks if the brp-magle-sehbang script mangled the
> shebangs from python to python2.
>
> See something like this in the build.log:
>
> *** WARNING: man
On Tue, Oct 23, 2018 at 1:28 PM Jason L Tibbitts III wrote:
>
> > "OP" == Orion Poplawski writes:
>
> OP> - Can we make epel7-py36 branches, and somehow have
> OP> %python3_version, et. al. be 3.6 for those builds?
>
> I can't think of any way to do that without extra magic. And if you
> req
Hey all,
I've released urlgrabber 4.0.0, which is notable for being Python 3 compatible!
We're still working out the kinks for getting it updated in all the
right places (urlgrabber.baseurl.org, PyPI, etc.), but for now, the
release source tarball can be downloaded from GitHub:
https://github.com
On Tue, Feb 26, 2019 at 9:12 AM Miro Hrončok wrote:
>
> Long story short:
>
> - we've updated pycodestyle and broke flake8
> - we need to update flake8
> - we cannot update on python2
>
> Hence, I'd like to get rid of python2-flake8.
>
> https://src.fedoraproject.org/rpms/python-flake8/pull-reques
On Thu, Feb 28, 2019 at 8:23 PM Dennis Gregorovic wrote:
>
> I have an update on the koji end. The 1.17 release will not only drop the
> yum dependency, it will also have full python 3 support (except for image
> building that uses oz / imagefactory). Unfortunately, there is only medium
> con
Hey all,
I've proposed a pull request to switch our Koji package to use Python
3 wherever possible:
https://src.fedoraproject.org/rpms/koji/pull-request/4
The PR is a bit complex, but it's based on the upstream spec for Koji,
which accounts for all the variations (Py2 Koji + Py3 client for
Fedora
On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen wrote:
>
> On Sat, 9 Mar 2019 at 22:19, Neal Gompa wrote:
> >
> > Hey all,
> >
> > I've proposed a pull request to switch our Koji package to use Python
> > 3 wherever possible:
> > https:/
On Sun, Mar 10, 2019 at 10:57 AM Stephen John Smoogen wrote:
>
> On Sun, 10 Mar 2019 at 10:55, Neal Gompa wrote:
> >
> > On Sun, Mar 10, 2019 at 10:53 AM Stephen John Smoogen
> > wrote:
> > >
> > > On Sat, 9 Mar 2019 at 22:19, Neal Gompa wrote:
>
On Sun, Mar 10, 2019 at 11:42 AM Peter Robinson wrote:
>
> > > Hey all,
> > >
> > > I've proposed a pull request to switch our Koji package to use Python
> > > 3 wherever possible:
> > > https://src.fedoraproject.org/rpms/koji/pull-request/4
> > >
> > > The PR is a bit complex, but it's based on t
On Sun, Mar 10, 2019 at 7:12 PM Peter Robinson wrote:
>
> > > > > Hey all,
> > > > >
> > > > > I've proposed a pull request to switch our Koji package to use Python
> > > > > 3 wherever possible:
> > > > > https://src.fedoraproject.org/rpms/koji/pull-request/4
> > > > >
> > > > > The PR is a bit c
On Mon, Mar 11, 2019 at 9:44 AM Peter Robinson wrote:
>
> > I disabled autopushing precisely so that there's no accidental pushing
> > to stable updates. The worst thing that can happen is that we have to
> > unpush the update from testing. Seriously, that's really not the end
> > of the world.
>
On Wed, Apr 24, 2019 at 6:23 AM Miro Hrončok wrote:
>
> Hey,
>
> since the plan is to have some python3-... packages in RHEL proper, should we
> adapt the %python_provide macro to provide python3-... when it gets
> python36-...?
>
> %{python_provide python36-foo} currently does nothing.
> I propo
On Wed, May 15, 2019 at 10:59 AM Miro Hrončok wrote:
>
> Hi.
>
> Tornado 6 doesn't support Python 2. Let's update the python-torando package to
> Python 3 only. There are several consumers of python2-torando and if their
> maintainers are interested, they can package it separately.
>
> $ dnf repoq
On Tue, Jun 4, 2019 at 3:26 AM Nico Kadel-Garcia wrote:
>
> On Mon, Jun 3, 2019 at 10:51 AM Sérgio Basto wrote:
> >
> > Hi,
> > These removed python2 packages are breaking upgrade path
> >
> > 1- when you remove python2-foo , you should add to main package
> > Obsoletes: python2-foo
>
> If I may
On Mon, Jun 10, 2019 at 8:28 AM Panu Matilainen wrote:
>
>
>
> A pile of language-specific macros and scripts have been eliminated from
> rpm upstream, notably %__python and %__perl and everything built around
> them, such as %python_sitelib and %perl_sitelib and their relatives.
> Python packages
On Wed, Jun 19, 2019 at 6:05 AM Miro Hrončok wrote:
>
> We have an interesting request for python3-rpm-macros to depend on python3.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1563789
>
> Highlights:
>
> - users who build for Python 3 are told (in the guidelines) to BR
> python3-devel
>
On Wed, Jun 19, 2019 at 8:09 AM Miro Hrončok wrote:
>
> On 19. 06. 19 12:24, Neal Gompa wrote:
> > On Wed, Jun 19, 2019 at 6:05 AM Miro Hrončok wrote:
> >>
> >> We have an interesting request for python3-rpm-macros to depend on python3.
> >>
> >>
On Sat, Sep 21, 2019 at 5:16 PM Miro Hrončok wrote:
>
> Hello,
>
> we've been recently approached by a colleague from Red Hat working on
> performance (CCed).
>
> According to their testing, Fedora Python performance could be improved by
> ~15%
> by building /usr/bin/python* statically with libpy
On Tue, Oct 29, 2019 at 6:58 PM Charalampos Stratakis
wrote:
>
> Through our latest benchmarks the speedup could be up to 27% so I would say
> it's definitely worth it, and we plan to work with the affected packages to
> see how to best resolve the issues, if they arise, on a case by case basis.
Hey all,
In the interest of helping to modernize the infrastructure Fedora runs
on, I'm working on introducing Pagure into EPEL8. This will hopefully
allow us to upgrade our Pagure instances to use RHEL 8 instead of RHEL
7, and notably, make the transition (mostly) complete for moving all
Python s
On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi wrote:
>
> On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > I've done an early build locally to determine what's needed to make
> > this possible. The following report from DNF indicates the missing
> >
On Wed, Nov 20, 2019 at 5:57 AM Miro Hrončok wrote:
>
> Python 3.9.0a1 is out: https://www.python.org/downloads/release/python-390a1/
>
> Here is the package review request for python39:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1774417
I've grabbed the review. Let's see how this goes...
Hey all,
I've been trying to get Pagure into EPEL 8 for a couple of months now
so that we can upgrade our Pagure instances to RHEL 8[1].
Thankfully, most of Pagure's dependencies *are* now present in EPEL 8,
so there's only a few that need to be added.
The list of Pagure dependencies missing are
On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa wrote:
>
> On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi wrote:
> >
> > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > I've done an early build locally to determine what's needed to make
> >
On Sat, Feb 8, 2020 at 9:59 PM Neal Gompa wrote:
>
> Hey all,
>
> I've been trying to get Pagure into EPEL 8 for a couple of months now
> so that we can upgrade our Pagure instances to RHEL 8[1].
>
> Thankfully, most of Pagure's dependencies *are* now present in
On Sat, Feb 22, 2020 at 11:57 PM Neal Gompa wrote:
>
> On Sat, Feb 8, 2020 at 9:59 PM Neal Gompa wrote:
> >
> > Hey all,
> >
> > I've been trying to get Pagure into EPEL 8 for a couple of months now
> > so that we can upgrade our Pagure instances
On Sat, Feb 22, 2020 at 11:50 PM Neal Gompa wrote:
>
> On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa wrote:
> >
> > On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi wrote:
> > >
> > > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > &g
On Sat, Mar 21, 2020 at 3:42 AM Neal Gompa wrote:
>
> On Sat, Feb 22, 2020 at 11:50 PM Neal Gompa wrote:
> >
> > On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa wrote:
> > >
> > > On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi wrote:
> > > >
> &
On Sat, Mar 21, 2020 at 3:41 AM Neal Gompa wrote:
>
> On Sat, Feb 22, 2020 at 11:57 PM Neal Gompa wrote:
> >
> > On Sat, Feb 8, 2020 at 9:59 PM Neal Gompa wrote:
> > >
> > > Hey all,
> > >
> > > I've been trying to get Pagure into EPE
On Tue, Mar 24, 2020 at 8:40 AM Miro Hrončok wrote:
>
> Hello Pythonistas.
>
> (I've CC'ed the devel list for further exposure. But let's discuss this on
> python-devel list please to avoid noise.)
>
>
> We would like ro rename the "python3" component (SRPM) to "python39" to make
> maintaining v
On Tue, Apr 7, 2020 at 8:26 AM Petr Viktorin wrote:
>
> On 2020-04-07 12:40, Miro Hrončok wrote:
> > On 07. 04. 20 11:06, Petr Viktorin wrote:
> >> On 2020-04-03 20:44, Miro Hrončok wrote:
> >>> Hello Python packagers.
> >>>
> >>> I have just updated python-rpm-generators to
> >>> python-rpm-gener
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-r
On Mon, Apr 27, 2020 at 11:58 AM Nicolas Mailhot
wrote:
>
> Le lundi 27 avril 2020 à 11:34 +0200, Miro Hrončok a écrit :
> > Hello Python packagers,
> >
> > Usage:
> >
> >%check
> >%pytest
> >
> > Or with options passed to pyets:
> >
> >%check
> >%pytest -v -m "not network" tests/
On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava wrote:
>
> 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
On Tue, Apr 28, 2020 at 5:00 AM Petr Viktorin wrote:
>
> I finally got around to this mail...
>
> On 2020-04-19 16:55, Miro Hrončok wrote:
> >
> > As always, this leaves us with the name problem, but I'd very much like
> > to use %python_provides (note the s). The only problem I see is that it
> >
-- Forwarded message -
From: Sumana Harihareswara
Date: Thu, Jul 30, 2020 at 11:36 AM
Subject: Re: [pypa/pip] New Resolver: Rollout, Feedback Loops and
Development Flow (#6536)
To: pypa/pip
Cc: Neal Gompa (ニール・ゴンパ) , Comment <
comm...@noreply.github.com>
Per #8511
On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin wrote:
>
> I'll move some discussion here, where it doesn't become part of the
> document:
>
> >
> > On 2020-08-11 14:19, Petr Viktorin wrote:
> >> These Guidelines represent a major rewrite and paradigm shift, and not
> >> all packages are updated to
On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin wrote:
>
> On 2020-08-12 16:53, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin wrote:
> >>
> >> I'll move some discussion here, where it doesn't become part of the
> >> doc
On Wed, Aug 12, 2020 at 12:02 PM Petr Viktorin wrote:
>
> On 2020-08-12 17:22, Neal Gompa wrote:
> > On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin wrote:
> >>
> >> On 2020-08-12 16:53, Neal Gompa wrote:
> >>> On Wed, Aug 12, 2020 at 10:23 AM Petr Vikto
On Wed, Aug 26, 2020 at 6:25 PM Michel Alexandre Salim
wrote:
>
> On Wed, 2020-08-26 at 15:16 -0700, Michel Alexandre Salim wrote:
> > On Wed, 2020-08-26 at 20:23 +0200, Miro Hrončok wrote:
> > >
> > > I don't really know who maintains `rpmdev-newspec python-foo` but
> > > the
> > > output
> > > (
Hey all,
An "interesting" Linux support issue at work with another Linux
distribution opened my eyes to the possibility of how badly things
would break if /usr/bin/python3 was swapped or otherwise altered by an
external force. In such a scenario where it was overridden to point to
another Python 3
On Tue, Dec 29, 2020 at 8:18 AM Miro Hrončok wrote:
>
> Hello,
> I plan to retire Python 3.5 from Fedora 35+:
>
> https://fedoraproject.org/wiki/Changes/RetirePython3.5
>
> Let me know if there is some reason to extend the deadline to a later release.
>
No reason to extend it, but I would also no
On Tue, Dec 29, 2020 at 8:47 AM Miro Hrončok wrote:
>
> On 29. 12. 20 14:27, Neal Gompa wrote:
> > On Tue, Dec 29, 2020 at 8:18 AM Miro Hrončok wrote:
> >>
> >> Hello,
> >> I plan to retire Python 3.5 from Fedora 35+:
> >>
> >> https://fed
On Fri, Feb 19, 2021 at 4:57 PM Matthew Miller wrote:
>
> Hi! I'm using this https://github.com/gyli/PyWaffle for some visualizations
> for Fedora Project stats.
>
> I'm kind of out of the loop on the state of the art of python packaging, and
> wondered if some kind Python SIG person would like
On Tue, Mar 16, 2021 at 5:32 AM Miro Hrončok wrote:
>
> Hello Pythonistas.
>
>
> I find myself cop-pasting this boring snippet each time I create a Python
> package (using the old macros or the new):
>
>
>%package -n python3-foo
>Summary:%{summary}
>
>%description -n python3-fo
Hey all,
Things have changed in Python runtime packaging since we started
introducing alternative Python versions years ago. For one, we now
always have fully versioned source packages, and now we have a flag
for whether the packages are "main runtime" vs "alternate runtime".
Another is that RHEL
On Tue, Jun 15, 2021 at 5:35 AM Miro Hrončok wrote:
>
> On 14. 06. 21 7:31, Zbigniew Jędrzejewski-Szmek wrote:
> >> BuildRequires: %{py3_dist pytest}
> > Does it make sense to recommend py3_dist here? python3dist(pytest) is
> > not more complex but can be fed to 'dnf install' directly, so in the
>
On Thu, Nov 4, 2021 at 7:50 AM Miro Hrončok wrote:
>
> Hello Pythonistas.
>
> After some recent improvements in the Python RPM dependency generators, a
> regression was discovered [0].
>
> Turns out the error happened when the upstream metadata contained a
> requirement
> with a PEP 440 [1] incom
Top posting because replying from my phone, but I think it'd be great to
have in EPEL 9 because it's essential for some packages to build. The same
goes for Poetry, which is now used for software made by Fedora
Infrastructure these days.
On Thu, Dec 23, 2021, 3:10 PM Michel Alexandre Salim <
sali.
On Sat, Mar 5, 2022 at 1:35 PM Orion Poplawski wrote:
>
> I've been poking at some packages that BR python3-docs, like
> python-zope-event. This apparently comes from a sphinx inventory:
>
> # Use local objects.inv for intersphinx
> sed -i "s|\('https://docs\.python\.org/':
> \)None|\1'%{_docdir}
On Fri, Mar 18, 2022 at 4:28 PM Miro Hrončok wrote:
>
> On 16. 03. 22 17:12, Tomáš Orsava wrote:
> > Hi Python-devel,
> > we are considering splitting the alternative Python versions from a
> > single-package format (e.g. python3.11) to multiple subpackages (e.g.
> > python3.11{,-libs,-devel,-tkin
On Thu, May 26, 2022 at 12:10 AM Owen Taylor wrote:
>
> [ At Miro's request, resending this to python-devel so the discussion can be
> public ]
>
> Hi Miro -
>
> When rebuilding a package to include in a Flatpak, we want to install
> *everything* under prefix=/app - that includes Python modules.
On Fri, May 27, 2022 at 6:07 AM Miro Hrončok wrote:
>
> Hey Pythonistas,
>
> let me include you in my dilemma I have wrt different Python versions we
> support in Fedora for testing.
>
> tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for
> RHEL 8, but 3.7 will no longer
On Fri, May 27, 2022 at 11:35 AM Miro Hrončok wrote:
>
> On 27. 05. 22 14:34, Neal Gompa wrote:
> > While unfortunate, I think it makes sense to retire Python 3.7 when
> > Debian 10 goes EOL.
>
> I don't understand why do you consider this unfortunate.
>
The s
On Thu, Oct 13, 2022 at 5:08 AM Miro Hrončok wrote:
>
> Hello Pythonistas,
>
> we are probably going to package python3.12 soon for all Fedora releases.
>
> Unfortunately, building Python for 32bit ARM has been very tedious lately, as
> the Koji build keeps restarting and the build takes 24+ hours
On Tue, Jan 31, 2023 at 1:12 PM Richard Hughes
wrote:
>
> Hey all,
>
> I'm building python-uswid as a rpm as it's going to be needed by the
> fwupd-efi package at build time in the near future. I'm also the upstream
> maintainer, so I'm not against changing upstream and then tagging a new
> rel
On Sat, Feb 4, 2023 at 10:32 AM Richard Hughes
wrote:
>
> Many thanks all; I've fixed up all the issues I think and submitted an actual
> review here: https://bugzilla.redhat.com/show_bug.cgi?id=2167067
>
Reviewed. :)
--
真実はいつも一つ！/ Always, there's only one truth!
1 - 100 of 109 matches
Mail list logo
