Re: unresponsive maintainer for python-installer
On Mon, Nov 27, 2023 at 2:15 PM Kaleb Keithley wrote: > > Is someone in contact with cstratak? > > I started the non-responsive maintainer process [1], because I asked that > python-installer be branched and built for epel, or to add the EPEL > packagers SIG to the maintainers [2] on 14 Nov 2023 and added a NEEDINFO on > 16 Nov. > > Even after allowing for holidays, PTOs, and etc., there is still no > response. > > Thanks > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2251761 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2249631 > > > -- > > Kaleb > -- > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > Hey Kaleb, Apologies for not responding, I've been extremely busy and I didn't have much time to look at Fedora. I've added the epel-packagers-sig as a collaborator to the python-installer package. However you could contact me directly on email before initiating the formal process, that would have been easier. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism
> I spent most of yesterday repairing a rawhide VM that had a bad upgrade, > resulting in dnf segfaulting and making the machine difficult to fix. > Had to build a second rawhide VM as a baseline to guide a manual > download and install of affected RPMs. Very not happy, and I would > advise more testing before making it official. Managed to destroy one of my own rawhide VM's that had automatic updates enabled till I figured out how to workaround, so for anyone interested. Hadn't rebooted for some time and when I tried to do a distro-sync I was getting: > Problem 1: problem with installed package python3-slip-dbus-0.6.4-29.fc38.noarch > - package python3-slip-dbus-0.6.4-29.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed > - package python3-slip-dbus-0.6.4-29.fc38.noarch from rawhide requires python(abi) = 3.11, but none of the providers can be installed > - python3-3.11.3-1.fc39.ppc64le from @System does not belong to a distupgrade repository > Problem 2: problem with installed package python3-slip-0.6.4-29.fc38.noarch > - package python3-slip-0.6.4-29.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed > - package python3-slip-0.6.4-29.fc38.noarch from rawhide requires python(abi) = 3.11, but none of the providers can be installed > - package python3-3.11.3-1.fc39.ppc64le from @System requires python3-libs(ppc-64) = 3.11.3-1.fc39, but none of the providers can be installed > - python3-libs-3.11.3-1.fc39.ppc64le from @System does not belong to a distupgrade repository > (try to add '--skip-broken' to skip uninstallable packages) Hence removed python3-slip and python3-slip-dbus. After that I got a segfault when trying to distro-sync. Consistent with 2 other rawhide VM's, the same thing happened. My system had sqlite-3.42.0-7.fc39 and rpm-4.18.1-3.fc39 so I grabbed from koji the sqlite-3.41.2-3.fc39 <https://koji.fedoraproject.org/koji/buildinfo?buildID=2219084> version (which was also dependent on the python3.11 abi) and installed it with: $ sudo rpm -Uvh --oldpackage sqlite-3.41.2-3.fc39.ppc64le.rpm sqlite-libs-3.41.2-3.fc39.ppc64le.rpm sqlite-devel-3.41.2-3.fc39.ppc64le.rpm Then dnf didn't segfault anymore and I could distro-sync, getting the latest python3.12, latest dnf etc. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-packaging] RPM 4.19: Dynamic subpackages with Python extras
uildrequires >%pyproject_buildrequires -X 'nonfree*' > >... > >%pyproject_install >... >%pyproject_generate_extras_subpkgs -X test > > That would mean: > > - extra1 is BRed and packaged > - extra2 is BRed and packaged > - test is BRed but not packaged > - nonfree1 is neither > - nonfree2 is neither > > Your thoughts on the implementation are quite sound and consistent, I don't really have any comments on that as you have taken all the possibilities into account and provided examples. If those thoughts move forward with an implementation I'll provide more comprehensive feedback on that. Also %pyproject_generate_extras_subpkgs somehow inheriting the excluded extras from %pyproject_buildrequires is reasonable, I dislike the archaic %global approach as well. > > Alternatively the information could be supplied by %globals: > >%global _python_ignored_extras nonfree* >%global _python_unpackaged_extras test > > However, I somehow dislike this approach. > > > > I'd appreciate your thoughts on the matter. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > packaging mailing list -- packag...@lists.fedoraproject.org > To unsubscribe send an email to packaging-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/packag...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
python-cryptography license fix
The license of python-cryptography was changed to SPDX and also fixed after clarification from upstream from "ASL 2.0 or BSD" to "(Apache-2.0 OR BSD-3-Clause) AND PSF-2.0" -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Python 3.11 final release might be delayed to December
On Tue, Jul 5, 2022 at 4:33 PM Miro Hrončok wrote: > On 05. 07. 22 16:22, Kaleb Keithley wrote: > > On Tue, Jul 5, 2022 at 9:45 AM Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > On 05. 07. 22 15:20, Kaleb Keithley wrote: > > > > > > > > > On Tue, Jul 5, 2022 at 9:07 AM Richard W.M. Jones < > rjo...@redhat.com > > <mailto:rjo...@redhat.com> > > > <mailto:rjo...@redhat.com <mailto:rjo...@redhat.com>>> wrote: > > > > > > On Tue, Jul 05, 2022 at 01:17:39PM +0200, Miro Hrončok wrote: > > > > Hello, > > > > forwarding this message to Fedora. > > > > > > > > Will know more by the end of this week -- we might need to > consider > > > > reverting back to Python 3.10 if we don't want to ship > Fedora 37 GA > > > > with a beta version of Python :( > > > > > > Is there a reason why shipping a beta version of Python would > be bad? > > > I've been using it on my main development machine for a few > weeks and > > > for the (fairly limited) Python stuff I do it seems to be > fine. > > > > > > It'd be a problem if it was causing bugs. > > > > > > > > > It broke the cephfs-shell subpackage. (Currently disabled as a > temporary > > > work-around.) > > > > Could you please share some link? > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=88847352 > > <https://koji.fedoraproject.org/koji/taskinfo?taskID=88847352> > > """ > error: Multiple top-level packages discovered in a flat-layout: ['top', > 'CMakeFiles']. > To avoid accidental inclusion of unwanted files or directories, > setuptools will not proceed with this build. > If you are trying to create a single distribution with multiple packages > on purpose, you should not rely on automatic discovery. > Instead, consider the following options: > 1. set up custom discovery (`find` directive with `include` or `exclude`) > 2. use a `src-layout` > 3. explicitly set `py_modules` or `packages` with a list of names > To find more information, look for "package discovery" on setuptools docs. > """ > > This is a setuptools 61+ thing, not Python 3.11. > > You might find some context in > > https://setuptools.pypa.io/en/latest/history.html#id105 > https://github.com/pypa/setuptools/issues/3197 > > https://bugzilla.redhat.com/showdependencytree.cgi?id=2064842_resolved=0 > > No idea why ceph was not reported as impacted, the folks have reported > *many* > other failures. > > I am afraid we have not yet seen the end of breaking changes in setuptools > :/ > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > This is due to an oversight by me during the impact check of the latest setuptools, as COPR default timeout is 5 hours and ceph requires more than that, hence I skipped it, apologies for that. You can add a py_modules = [] in setup.py to fix it usually. The issue and the possible fix is described here: https://github.com/pypa/setuptools/issues/3197#issuecomment-1078770109 -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On Fri, Jul 1, 2022 at 5:12 PM Charalampos Stratakis wrote: > > > On Fri, Jul 1, 2022 at 4:54 PM Christian Heimes > wrote: > >> Here you are, have fun! >> >> >> https://github.com/python/cpython/compare/2.7...tiran:cpython:2.7.18-openssl3?expand=1 >> >> $ ./python -c "import sys; print sys.version" >> 2.7.18 (heads/2.7.18-openssl3:a2e3d7995ce, Jul 1 2022, 16:51:37) >> [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] >> >> $ ./python Lib/test/ssltests.py >> OpenSSL 3.0.3 3 May 2022 >> Using random seed 4979488 >> Run tests sequentially >> 0:00:00 load avg: 1.64 [ 1/13] test_ensurepip >> 0:00:00 load avg: 1.64 [ 2/13] test_ssl >> 0:00:07 load avg: 2.33 [ 3/13] test_hmac >> 0:00:07 load avg: 2.33 [ 4/13] test_ftplib >> 0:00:08 load avg: 2.33 [ 5/13] test_urllib2_localnet >> 0:00:09 load avg: 2.33 [ 6/13] test_smtplib >> 0:00:09 load avg: 2.33 [ 7/13] test_smtpnet >> 0:00:10 load avg: 2.33 [ 8/13] test_hashlib >> 0:00:10 load avg: 2.33 [ 9/13] test_httplib >> 0:00:12 load avg: 2.14 [10/13] test_xmlrpc >> 0:00:15 load avg: 2.14 [11/13] test_imaplib >> Resource 'cyrus.andrew.cmu.edu' is not available >> Resource 'cyrus.andrew.cmu.edu' is not available >> Resource 'cyrus.andrew.cmu.edu' is not available >> Resource 'cyrus.andrew.cmu.edu' is not available >> Resource 'cyrus.andrew.cmu.edu' is not available >> Resource 'cyrus.andrew.cmu.edu' is not available >> 0:00:16 load avg: 2.13 [12/13] test_poplib >> 0:00:18 load avg: 2.13 [13/13] test_nntplib >> >> == Tests result: SUCCESS == >> >> All 13 tests OK. >> >> Total duration: 18 sec 495 ms >> Tests result: SUCCESS >> ___ >> 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 >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > > Will try it and do an impact check for the packages depending on python2.7. > > -- > Regards, > > Charalampos Stratakis > Senior Software Engineer > Python Maintenance Team, Red Hat > Draft PR: https://src.fedoraproject.org/rpms/python2.7/pull-request/36 Copr impact check: https://copr.fedorainfracloud.org/coprs/cstratak/python2.7-openssl3/builds/ I won't have time to get back to it till late next week, however there are instructions in copr for getting the mock config for anyone who wants to experiment. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On Fri, Jul 1, 2022 at 4:54 PM Christian Heimes wrote: > Here you are, have fun! > > > https://github.com/python/cpython/compare/2.7...tiran:cpython:2.7.18-openssl3?expand=1 > > $ ./python -c "import sys; print sys.version" > 2.7.18 (heads/2.7.18-openssl3:a2e3d7995ce, Jul 1 2022, 16:51:37) > [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] > > $ ./python Lib/test/ssltests.py > OpenSSL 3.0.3 3 May 2022 > Using random seed 4979488 > Run tests sequentially > 0:00:00 load avg: 1.64 [ 1/13] test_ensurepip > 0:00:00 load avg: 1.64 [ 2/13] test_ssl > 0:00:07 load avg: 2.33 [ 3/13] test_hmac > 0:00:07 load avg: 2.33 [ 4/13] test_ftplib > 0:00:08 load avg: 2.33 [ 5/13] test_urllib2_localnet > 0:00:09 load avg: 2.33 [ 6/13] test_smtplib > 0:00:09 load avg: 2.33 [ 7/13] test_smtpnet > 0:00:10 load avg: 2.33 [ 8/13] test_hashlib > 0:00:10 load avg: 2.33 [ 9/13] test_httplib > 0:00:12 load avg: 2.14 [10/13] test_xmlrpc > 0:00:15 load avg: 2.14 [11/13] test_imaplib > Resource 'cyrus.andrew.cmu.edu' is not available > Resource 'cyrus.andrew.cmu.edu' is not available > Resource 'cyrus.andrew.cmu.edu' is not available > Resource 'cyrus.andrew.cmu.edu' is not available > Resource 'cyrus.andrew.cmu.edu' is not available > Resource 'cyrus.andrew.cmu.edu' is not available > 0:00:16 load avg: 2.13 [12/13] test_poplib > 0:00:18 load avg: 2.13 [13/13] test_nntplib > > == Tests result: SUCCESS == > > All 13 tests OK. > > Total duration: 18 sec 495 ms > Tests result: SUCCESS > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > Will try it and do an impact check for the packages depending on python2.7. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
So I presume then that python2.7 in Debian works flawlessly with OpenSSL 3.0.0, no regressions, no security issues and no ABI problems right? On Thu, Jun 30, 2022 at 5:13 PM Robbie Harwood wrote: > Charalampos Stratakis writes: > > > Unfortunately that effort is moot, it's really not possible to make > > python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python > > versions are not 100% compatible for various reasons. > > > > In trying to make it compatible there are also ABI changes introduced, > > it's not only about having the tests pass. The ssl module is already > > complex enough in backporting changes from the master Python branch to > > previous 3.x versions, doing that for 2.7 without a full fledged > > effort from SSL and the Python C API experts guarantee there's gonna > > be regressions. And that's not even taking into account the security > > implications of randomly cherry-picking commits just to have the > > package compile. > > I'm having trouble understanding this because Debian seems to have > carried out what you're saying is impossible: in testing, they ship a > python2.7 that appears to be using openssl 3, and do not ship openssl > 1.1 at all. There are also a handful of clearly openssl 3-related > patches in their tree > https://salsa.debian.org/cpython-team/python2/-/tree/master/debian/patches > > Have folks looked at how they do this, and whether we could adapt it to > Fedora? > > Be well, > --Robbie > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
And I would very much prefer to remedy the issue of having packages still
relying on python2 rather than thinking about removing OpenSSL 1.1.1 that's
still supported upstream and many packages depend on it.
On Thu, Jun 30, 2022 at 3:29 PM Charalampos Stratakis
wrote:
> Unfortunately that effort is moot, it's really not possible to make
> python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
> versions are not 100% compatible for various reasons.
>
> In trying to make it compatible there are also ABI changes introduced,
> it's not only about having the tests pass. The ssl module is already
> complex enough in backporting changes from the master Python branch to
> previous 3.x versions, doing that for 2.7 without a full fledged effort
> from SSL and the Python C API experts guarantee there's gonna be
> regressions. And that's not even taking into account the security
> implications of randomly cherry-picking commits just to have the package
> compile.
>
> On Wed, Jun 29, 2022 at 5:12 PM Dmitry Belyavskiy
> wrote:
>
>> Dear colleagues,
>>
>> If I correctly follow the discussion, the biggest show-stopper is Python
>> 2.*, which has some incomplete patches to deal with OpenSSL 3.0.
>> If we assist you in moving these patches forward, can we get rid of the
>> devel package and leave the compat package only for 3rd-party packages?
>>
>> I don't think that the community really requires support for this package
>> for 7 years after its upstream sunset.
>>
>> Many thanks!
>>
>> On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok wrote:
>>
>>> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
>>> > ==
>>> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
>>> > --
>>> > Traceback (most recent call last):
>>> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382,
>>> in test_openssl_version
>>> > (s, t))
>>> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>>>
>>> Might be https://github.com/python/cpython/issues/90272
>>>
>>> --
>>> Miro Hrončok
>>> --
>>> Phone: +420777974800
>>> IRC: mhroncok
>>> ___
>>> 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
>>> Do not reply to spam on the list, report it:
>>> https://pagure.io/fedora-infrastructure
>>>
>>
>>
>> --
>> Dmitry Belyavskiy
>> ___
>> 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
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Regards,
>
> Charalampos Stratakis
> Senior Software Engineer
> Python Maintenance Team, Red Hat
>
--
Regards,
Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Unfortunately that effort is moot, it's really not possible to make
python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
versions are not 100% compatible for various reasons.
In trying to make it compatible there are also ABI changes introduced, it's
not only about having the tests pass. The ssl module is already complex
enough in backporting changes from the master Python branch to previous 3.x
versions, doing that for 2.7 without a full fledged effort from SSL and the
Python C API experts guarantee there's gonna be regressions. And that's not
even taking into account the security implications of randomly
cherry-picking commits just to have the package compile.
On Wed, Jun 29, 2022 at 5:12 PM Dmitry Belyavskiy
wrote:
> Dear colleagues,
>
> If I correctly follow the discussion, the biggest show-stopper is Python
> 2.*, which has some incomplete patches to deal with OpenSSL 3.0.
> If we assist you in moving these patches forward, can we get rid of the
> devel package and leave the compat package only for 3rd-party packages?
>
> I don't think that the community really requires support for this package
> for 7 years after its upstream sunset.
>
> Many thanks!
>
> On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok wrote:
>
>> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
>> > ==
>> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
>> > --
>> > Traceback (most recent call last):
>> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382, in
>> test_openssl_version
>> > (s, t))
>> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>>
>> Might be https://github.com/python/cpython/issues/90272
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
> Dmitry Belyavskiy
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
--
Regards,
Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Retiring python-bitcoinlib
I'm planning to retire the python-bitcoinlib package: https://src.fedoraproject.org/rpms/python-bitcoinlib It currently FTBFS on F36 and I have no use for it anymore. If anyone is interested in fixing it and taking over, feel free to reach out. Upstream: https://github.com/petertodd/python-bitcoinlib -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Should python3dist(...) provides generator fail when the version is = 0?
On Sat, Jan 29, 2022 at 10:12 PM Miro Hrončok wrote: > Hello Pythonistas, > > today, I've looked up packages in rawhide providing python3dist(...) = 0 > and I > opened bugzillas for them: > > https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 > > While version 0 (or equal versions like 0.0 or 0.0.0) is probably > technically > valid, it most certainly indicates a packaging error (most likely but not > necessarily a downstream packaging error). > > Should we prevent this error from happening by explicitly erroring (and > failing > the build) when it happens? I think it would make the dependency > generators > more robust. > > In an unlikely scenario when packagers actually want to package version 0, > they > can reach out and we can allow it via some configuration (but [YAGNI], so > I > don't want to clutter the generator with yet another option right away). > > [YAGNI] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > Makes a lot of sense to error out the build in this case. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:26 PM Michel Alexandre Salim < sali...@fedoraproject.org> wrote: > On Wed, Dec 15, 2021 at 10:20:27PM +0100, Charalampos Stratakis wrote: > > On Wed, Dec 15, 2021 at 10:03 PM Miro Hrončok > wrote: > > > > > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > > > (I haven't built python-mock in EPEL9 yet, and am not going to > unless we > > > > really need it for something - but I'll hold off on retiring the > branch) > > > > > > Please, retire it for EPEL9. It should never be needed. > > > > > > > > Unfortunately it's quite possible something might need it as there are > > still a lot of packages relying on the external mock. > > > True, but we probably should patch these going forward? I'm happy to > help. I wonder how many of those will turn out to be obsolete BRs too. > > > I would keep the branch but defer building it for now. > > > Argh, too late, but unretiring is easy anyway. > > No worries, I agree patching the imports out is a better solution IMHO. > Regards, > > -- > Michel Alexandre Salim > profile: https://keyoxide.org/mic...@michel-slm.name > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:26 PM Michel Alexandre Salim < sali...@fedoraproject.org> wrote: > On Wed, Dec 15, 2021 at 10:20:27PM +0100, Charalampos Stratakis wrote: > > On Wed, Dec 15, 2021 at 10:03 PM Miro Hrončok > wrote: > > > > > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > > > (I haven't built python-mock in EPEL9 yet, and am not going to > unless we > > > > really need it for something - but I'll hold off on retiring the > branch) > > > > > > Please, retire it for EPEL9. It should never be needed. > > > > > > > > Unfortunately it's quite possible something might need it as there are > > still a lot of packages relying on the external mock. > > > True, but we probably should patch these going forward? I'm happy to > help. I wonder how many of those will turn out to be obsolete BRs too. > > > I would keep the branch but defer building it for now. > > > Argh, too late, but unretiring is easy anyway. > > No worries, I agree patching the imports out is a better solution IMHO. > Regards, > > -- > Michel Alexandre Salim > profile: https://keyoxide.org/mic...@michel-slm.name > ___ > devel mailing list -- de...@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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:03 PM Miro Hrončok wrote: > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > (I haven't built python-mock in EPEL9 yet, and am not going to unless we > > really need it for something - but I'll hold off on retiring the branch) > > Please, retire it for EPEL9. It should never be needed. > > Unfortunately it's quite possible something might need it as there are still a lot of packages relying on the external mock. I would keep the branch but defer building it for now. > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:03 PM Miro Hrončok wrote: > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > (I haven't built python-mock in EPEL9 yet, and am not going to unless we > > really need it for something - but I'll hold off on retiring the branch) > > Please, retire it for EPEL9. It should never be needed. > > Unfortunately it's quite possible something might need it as there are still a lot of packages relying on the external mock. I would keep the branch but defer building it for now. > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- de...@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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Mon, Jun 21, 2021 at 5:49 PM Charalampos Stratakis wrote: > > > On Thu, Jun 17, 2021 at 5:46 PM Michael Catanzaro > wrote: > >> >> Hi, the script is failing the glib2 build due to an invalid rpath, but >> unless I'm missing something obvious, I think it's valid. Reported: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1973304 >> >> >> > I've sent an upstream PR for that case as well: > https://github.com/rpm-software-management/rpm/pull/1721 > > -- > Regards, > > Charalampos Stratakis > Senior Software Engineer > Python Maintenance Team, Red Hat > Both the optimization fixes and the libexec issue have been addressed upstream. The release of RPM 4.17 beta should land in rawhide very soon and it will include the changes. -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Thu, Jun 17, 2021 at 5:46 PM Michael Catanzaro wrote: > > Hi, the script is failing the glib2 build due to an invalid rpath, but > unless I'm missing something obvious, I think it's valid. Reported: > > https://bugzilla.redhat.com/show_bug.cgi?id=1973304 > > > I've sent an upstream PR for that case as well: https://github.com/rpm-software-management/rpm/pull/1721 -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Thu, Jun 17, 2021 at 5:17 PM Tom Stellard wrote:
> On 6/16/21 10:58 PM, Tom Stellard wrote:
> > On 6/16/21 2:11 PM, Charalampos Stratakis wrote:
> >> On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard <mailto:tstel...@redhat.com>> wrote:
> >>
> >> On 5/7/21 10:48 AM, Ben Cotton wrote:
> >> >
> https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild <
> https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild>
> >> >
> >> > == Summary ==
> >> > Enable broken RPATH detection
> >> > [
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> <
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> >
> >> > buildroot policy] script by default. This will make the RPM
> build fail
> >> > once a broken RPATH was detected within a binary or a shared
> library
> >> > file. An opt-out mechanism will be provided as well.
> >> >
> >> > == Owner ==
> >> > * Name: [[User:cstratak| Charalampos Stratakis]]
> >> > * Email: cstratak AT redhat.com <http://redhat.com>
> >> >
> >> >
> >>
> >> Hi,
> >>
> >> Was there any testing done to determine how much this script would
> increase
> >> build times? I've noticed it takes quite a while on the kernel
> builds, and
> >> I'm curious what factors influence how long the script takes. Is it
> >> number of binaries, binary sizes, etc?
> >>
> >> -Tom
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org devel@lists.fedoraproject.org>
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> >> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines <
> https://fedoraproject.org/wiki/Mailing_list_guidelines>
> >> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> >> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure <
> https://pagure.io/fedora-infrastructure>
> >>
> >>
> >> Hey Tom,
> >>
> >> Unfortunately no, a potential increase in build time was not taken into
> account at the time of the implementation of this change, as it never came
> up when considering other buildroot policy scripts as well.
> >>
> >> Here is the actual script that runs:
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
> <
> https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
> >
> >>
> >> Could you try and compare two scratch builds? One as is and one by
> adding |%global __brp_check_rpaths %{nil} |at the SPEC?|
> >> |
> >>
> >
> > Instead of doing two scratch builds, I just added:
> > %global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec
> file
> > and did a scratch build[1].
> >
> > The results on x86_64 were:
> >
> > real13m51.517s
> > user8m53.216s
> > sys7m34.105s
> >
> > Overall build time for the scratch build was 88m37s, so that means
> check-rpaths
> > accounted for 15% of the build time. I'm going to do some more tests on
> some
> > of the larger packages I maintain (llvm and clang) and see what the
> impact is.
> >
>
> LLVM was ~2 minutes and clang ~30 seconds, so not that big of an impact.
> The
> kernel build might just be an outlier.
>
> -Tom
>
> > I do think it would be worth trying to profile the script and see if
> there is
> > room for optimization.
> >
> > - Tom
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=70270039
> >
> >
> >
> >> Also adding here for completion that the script will also check for
> RUNPATH as of rpm 4.17:
> https://github.com/rpm-software-management/rpm/pull/1487/files <
> https://github.com/rpm-software-management/rpm/pull/1487/files>
> >>
> >> --
> &g
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard wrote:
> On 5/7/21 10:48 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild
> >
> > == Summary ==
> > Enable broken RPATH detection
> > [
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> > buildroot policy] script by default. This will make the RPM build fail
> > once a broken RPATH was detected within a binary or a shared library
> > file. An opt-out mechanism will be provided as well.
> >
> > == Owner ==
> > * Name: [[User:cstratak| Charalampos Stratakis]]
> > * Email: cstratak AT redhat.com
> >
> >
>
> Hi,
>
> Was there any testing done to determine how much this script would increase
> build times? I've noticed it takes quite a while on the kernel builds, and
> I'm curious what factors influence how long the script takes. Is it
> number of binaries, binary sizes, etc?
>
> -Tom
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
Hey Tom,
Unfortunately no, a potential increase in build time was not taken into
account at the time of the implementation of this change, as it never came
up when considering other buildroot policy scripts as well.
Here is the actual script that runs:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
Could you try and compare two scratch builds? One as is and one by
adding %global
__brp_check_rpaths %{nil} at the SPEC?
Also adding here for completion that the script will also check for RUNPATH
as of rpm 4.17:
https://github.com/rpm-software-management/rpm/pull/1487/files
--
Regards,
Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Mon, May 10, 2021 at 5:18 PM Florian Weimer wrote: > * Charalampos Stratakis: > > > On Mon, May 10, 2021 at 5:08 PM Florian Weimer > wrote: > > > > * Charalampos Stratakis: > > > > > I think these rules make sense for RUNPATH, and we should outright > ban > > > RPATH. > > > > > > I'd agree here as well, however this could be a future fedora change > > > as I would deem it too disruptive to outright ban RPATH for now. > > > > I don't agree because of this: > > > > > I think we also should binutils with --enable-new-tags at configure > > > time. > > > > We wouldn't have RPATH after that anymore. > > > > So to understand it better, do you mean globally enabling the > > --enable-new-dtags? > > Correct, we have infrastructure for that already. > > That is an interesting proposition. --enable-new-dtags would in essence move the RPATH entries to DT_RUNPATH instead of DT_RPATH and then a new BRP policy script could be written applying the aforementioned rules for RUNPATH. Could be simpler, but I'll have to approach this from a different POV. I'll ponder on it for a bit. So to summarize, you're proposing: Banning RPATH through using --enable-new-dtags (with hopefully no intervention required from packagers). Apply the check-rpath rules (excluding the $ORIGIN one) for RUNPATH instead. > Thanks, > Florian > > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Mon, May 10, 2021 at 5:08 PM Florian Weimer wrote: > * Charalampos Stratakis: > > > I think these rules make sense for RUNPATH, and we should outright ban > > RPATH. > > > > I'd agree here as well, however this could be a future fedora change > > as I would deem it too disruptive to outright ban RPATH for now. > > I don't agree because of this: > > > I think we also should binutils with --enable-new-tags at configure > > time. > > We wouldn't have RPATH after that anymore. > > So to understand it better, do you mean globally enabling the --enable-new-dtags? > Thanks, > Florian > > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Mon, May 10, 2021 at 3:09 PM David Cantrell wrote: > On Sat, May 08, 2021 at 12:44:32PM +0100, Richard W.M. Jones wrote: > >Some random questions about this: > > > >- How many existing packages are affected? Can this be analyzed and > > the maintainers notified? > > > >- If I want to analyze my own packages to see if they contain > > rpaths, is it sufficient to run this? > > > > chrpath --list --keepgoing | grep RUNPATH > > > >I ran that on /usr/lib64 and found samba seems to use > >RUNPATH=/usr/lib64/samba > > It's possible to use rpminspect to check RPATH and RUNPATH values. A > run I did on a number of packages a few months ago showed we have (or > had) lots of things with /builddir RPATH values. > > Added how to test with rpminspect at the change, thanks for pointing it out. > In the case of Samba, /usr/lib64/samba can be allowed by adding that > to the allowed list in an rpminspect.yaml file locally. > > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Sat, May 8, 2021 at 4:46 PM Florian Weimer wrote: > * Ben Cotton: > > > Another problem of a hardcoded RPATH is security. When an ELF object > > contains an RPATH pointed to a directory not managed by the system, > > where some malicious actor has write permissions to, it's relatively > > easy to execute arbitrary code. > > > > Performance can be also affected, since probing explicitly e.g. > > /usr/lib64 through RPATH adds extra open/openat system calls to the > > process startup. > > Both issues also apply to RUNPATH, not just RPATH. It particularly > impacts s390x due to its many legacy hwcaps subdirectories. > > > === Definition of a broken RPATH === > > This change will use the > > [ > https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths-worker > > rpm script] for checking the broken RPATH's. > > > > The categories are: > > > > * standard RPATHs (e.g. `/usr/lib` or `/usr/lib64`); such RPATHs are a > > minor issue but are introducing redundant searchpaths without > > providing a benefit. They can also cause errors in multilib > > environments. > > * invalid RPATHs; these are RPATHs which are neither absolute nor > > relative filenames and can therefore be a SECURITY risk > > * insecure RPATHs; these are relative RPATHs which are a SECURITY risk > > * the special `$ORIGIN` RPATHs are appearing after other RPATHs; this > > is just a minor issue but usually unwanted > > * the RPATH is empty; there is no reason for such RPATHs and they > > cause unneeded work while loading libraries > > * an RPATH references `..` of an absolute path; this will break the > > functionality when the path before `..` is a symlink > > $ORIGIN needs to exempted from the absolute and .. checks as well. > > I would agree here but if that's the case packagers could opt-out. The other alternative would be to change the rpm script for that specific case. > I think these rules make sense for RUNPATH, and we should outright ban > RPATH. > I'd agree here as well, however this could be a future fedora change as I would deem it too disruptive to outright ban RPATH for now. > > I think we also should binutils with --enable-new-tags at configure > time. > > Thanks, > Florian > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
On Sat, May 8, 2021 at 1:52 PM Richard W.M. Jones wrote: > Some random questions about this: > > - How many existing packages are affected? Can this be analyzed and > the maintainers notified? > There is a list of packages at the change and also at the initial email thread before this change was created, I mention all the failing packages with their respective maintainers: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7ZKGVM4XJ7QFRFZXTSGUT4K2MPDVV2XY/#W7LXPX4SIB57DDXXI4PQNKCFSOQMOL4S I plan to notify every affected packager if the change gets accepted. Noting though, that during my testing of 9k+ packages from rawhide, many failed to build due to different reasons, so more failures might appear later on if their initial FTBFS issue is resolved. > > - If I want to analyze my own packages to see if they contain > rpaths, is it sufficient to run this? > > chrpath --list --keepgoing | grep RUNPATH > > I ran that on /usr/lib64 and found samba seems to use > RUNPATH=/usr/lib64/samba > > On the "how to test" section there is an rpmlint command on how to test your packages locally. Samba's use-case is fine as RUNPATH points to a directory with private libraries. > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.org > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal to fail builds if RPATH is found in Fedora 35
- Original Message - > From: "Alexander Bokovoy" > To: "Development discussions related to Fedora" > > Sent: Friday, March 26, 2021 10:06:28 PM > Subject: Re: Proposal to fail builds if RPATH is found in Fedora 35 > > On pe, 26 maalis 2021, Charalampos Stratakis wrote: > >Hi all. > > > >Some time ago there was a discussion from the Fedora Packaging > >Committee [0] about automatically disallowing the usage of RPATH in > >Fedora to bring it in-line with the packaging guidelines[1]. > >Essentially a package MUST remove the RPATH entry from its binaries > >and/or .so files if it is detected by the check-rpaths script [2] > >coming from the rpm-build package. > > > >However, the script was never run during rpmbuild so it was on the > >discretion of the packager if they'd check for it or not. The intention > >is to enable the check through redhat-rpm-config during the the > >invocation of %__os_install_post. An opt-out mechanism will be > >provided for cases where it's absolutely necessary. > > > >After an analysis of all the x86_64 packages, 92 fail to build due to > >an RPATH issue detected by the check-rpaths script [3]. Full list is > >provided bellow. > > > >Everything will be implemented through a Fedora change and all the > >packagers that their package has been affected by the preliminary > >analysis will be contacted first. > > The logic for banning RPATH in the packaging guidelines operates terms like > "usually smarter than" and "usually do not permit" but has very little > to describe why this should be done. Indeed and the guidelines will need to be updated to clarify that (and a motivation section at the change proposal). Security is the main thing, as directories arbitrary set by various upstreams won't be included in the search path, a minor speed bump could be noticed as well for the same reason. The main idea though is to make the rpath usage opt-in and have packagers clarify why rpath should be used for their packages. I believe using an opt-in (yet to be defined) macro in the SPEC with a comment explaining should be enough justification. > > It also lacks clarity for the most common valid use of Rpath, namely, a > plugin support for an application. > > For example, Samba has a number of internal libraries in > /usr/lib64/samba which have to be linked to by any plugin built for > Samba, even when it is provided by a different package. This situation > is not described in the packaging guidelines and practically ignored. Thanks for this example, I'll investigate that specific usecase. > "Alternatives to Rpath" in this cases do not exist because adding custom > configuration file into a system-wide dynamic linker configuration is > the last thing you should do for this use case at all. > > It is interesting that the behavior of check-rpaths script also isn't > really outlawing any plugin's Rpath use either so you don't see Samba or > similar plugin-based applications in the list of affected packages. > > To me it looks like the packaging guidelines are incomplete and > misleading and better be clarified with regards to Rpath use. > > > > > >Thoughts and feedback are welcome. > > > >[0] https://pagure.io/packaging-committee/issue/886 > >[1] > >https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath > >[2] > >https://github.com/rpm-software-management/rpm/blob/6b21e736a3e47071b33ff7c34e5cfb5447997e18/scripts/check-rpaths-worker > >[3] https://copr.fedorainfracloud.org/coprs/cstratak/rpath/builds/ > > > >List of packages affected so far: > > > >Maintainers by package: > >Io-language limb > >NLoptbesser82 > >SDL_imagejwrdegoede limb moezroy > >WindowMaker sham1 > >abc brouhaha jjames somlo > >audiofileajax alexl caillon caolanm limb rhughes rstrode ssp > >binutils aoliva jakub jankratochvil law mcermak nickc > >cfitsio orion sergiopr > >community-mysql hhorak ljavorsk mmuzila mschorm > >compat-guile18 jskarvad limb mlichvar tkorbar > >condor bbockelm bcotton eerlands matt matyas stevetraylen > >tstclair ttheisen valtri > >conky-managermoceap > >czmq denisarnaud jpo > >eb moceap petersen > >esc jmagne > >ettercap limb > >fcl rmattes thofmann > >fortune-mod sheltren shlomif > >freeradius cipherboy nkondras rharwood > >glib2ale
Re: Proposal to fail builds if RPATH is found in Fedora 35
- Original Message -
> From: "Miro Hrončok"
> To: devel@lists.fedoraproject.org
> Sent: Friday, March 26, 2021 6:51:56 PM
> Subject: Re: Proposal to fail builds if RPATH is found in Fedora 35
>
> On 26. 03. 21 18:24, Charalampos Stratakis wrote:
> > python2.7churchyard cstratak torsava vstinner
>
> I was curious. The error is:
>
>0001: file '/usr/lib64/python2.7/lib-dynload/pyexpat.so' contains a
>standard
>rpath '/usr/lib64' in [/usr/lib64]
>
> And the cause is... our own patch
>
> https://src.fedoraproject.org/rpms/python2.7/blob/rawhide/f/00187-add-RPATH-to-pyexpat.patch
>
> For reasons I don't understand, the bugzilla referenced from the patch is
> private. It is a RHEL 6.2 bugzilla from 2012 that could be summarized as:
>
> "If the user sets $LD_LIBRARY_PATH to a directory with broken/incompatible
> libraries, Python breaks."
>
> And as solution to this problem, RPATH was set to '%{_libdir}' for pyexpat
> (because the reporter happened to have incompatible libexpat in there and not
> different libraries).
>
> If I cared about python2.7 in Fedora, I'd say we should get rid of this
> patch.
>
> (OTOH if this patch is actually desired, we certainly need a lot more of
> them.)
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
I would certainly drop this patch from python2.7 (or maybe drop python2.7
entirely but that's a different topic).
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Proposal to fail builds if RPATH is found in Fedora 35
spot xdotool ohaessler orion slankes xeus qulogic xmms spot yaz cicku guidograzioli zinnia liangsuilong pwu zvbi buc jwrdegoede mchehab Packages by maintainer: aalvarez levmar aarem sylfilter ajax audiofile alexl audiofile glib2 amdunn stp amigadave tracker aoliva binutils atim libcommuni avigne kicad qucs bbockelm condor bcottoncondor besser82 NLopt branto pinentry brouhaha abc levmar buczvbi caillonaudiofile glib2 caolanmaudiofile glib2 churchyard python2.7 cicku libXcm verbiste yaz cipherboy freeradius coremodule kicad cstratak python2.7 scipy cwickert libburn deji ncview suitesparse tracker denisarnaud czmq devrim laszip dfateyev libdkimpp dtimms k3guitune eerlands condor epienbro mingw-qt5-qt3d mingw-qt5-qtbase mingw-qt5-qtdeclarative mingw-qt5-qttools erack woff2 evgenyzopenscap scap-workbench fabliboping libprelude fale rb_libtorrent fkluknav gpgme libburn libisoburn garnacho tracker tracker-miners guidograzioli yaz hguemarjq hhorak community-mysql libburn libisoburn hobbes1069 libdxfrw honli usnic-tools hubbitus vanessa_logger icon verbiste ignatenkobrain gpgme libminc tracker isimlukgpgme openscap jakub binutils jankratochvil binutils jcerny openscap scap-workbench jdornakmod_wsgi jjames abc stp jjelen pinentry jkaluzamod_wsgi jkastner suitesparse jmagne esc jmmv lutok jorton mod_wsgi jpoczmq jreznikkdebase3 kdepim3 jskarvad compat-guile18 qucs rrdtool jspaleta scipy jwrdegoede SDL_image perl-SDL zvbi kalev gupnp-dlna tracker-miners kkoflerkdebase3 kdegames3 koffice-kivio kmatsuimcpp kushal librfid kwizartlibXcm lawbinutils liangsuilong zinnia limb Io-language SDL_image audiofile compat-guile18 ettercap gnokii ljavorsk community-mysql lkundrak kicad liboping nightview lmackenmod_wsgi lonjq lupinixpam_mount luya gpick matt condor matyas condor matyc openscap scap-workbench mbarabas scap-workbench mbarnesglib2 mcermakbinutils mchehabzvbi mclasenglib2 mcrha tracker mefmcpp mjakubicek suitesparse mlichvar compat-guile18 mlysonek scap-workbench mmarhefk openscap scap-workbench mmuzilacommunity-mysql moceap conky-manager eb moezroySDL_image mooninite rb_libtorrent mrunge mod_wsgi mschormcommunity-mysql nb pam_yubico nbeckerkomparator netelerlaszip nforro scipy nickc binutils nkondras freeradius nonamedotc rarian nphilipp suitesparse nucleo libeXosip2 libosip2 ohaessler pam_yubico xdotool orion cfitsio hdf ncview scipy suitesparse xdotool orphan plotmm sofia-sip ovasik kdepim3 openjade pcahynalibburn petersen eb pvrabecopenscap scap-workbench pwuzinnia qulogicxeus rdietergpgme kdebase3 kdegames3 kdepim3 koffice-kivio pinentry remi mongo-c-driver rharwood freeradius rhughesaudiofile glib2 rishi tracker tracker-miners rmattesfcl robert gnokii libburn libisoburn rstrodeaudiofile glib2 rtcm glib2 sagitter hdf sergiopr cfitsio sham1 WindowMaker sheltren fortune-mod shlomiffortune-mod slankesxdotool smani laszip mingw-qt5-qt3d mingw-qt5-qtbase mingw-qt5-qtdeclarative mingw-qt5-qttools snirkelgnokii somlo abc spot libdxfrw sqlite2 texlive-base xbsql xmms sspaudiofile glib2 steve pam_mount stevenfalco kicad stevetraylen condor tartareverbiste than kdebase3 kdegames3 kdepim3 thofmann fcl till pam_mount tkorbarcompat-guile18 tnorth kicad tomspurscipy torsavapython2.7 totol libprelude tpopelawoff2 tstclair condor ttheisen condor ttomecek scipy ueno libkkc valtri condor volter qwtpolar vpolasek openscap vstinner python2.7 wsato openscap scap-workbench wzzrd pam_yubico zeenix gupnp-dlna -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
- Original Message - > From: "Robbie Harwood" > To: "Charalampos Stratakis" , "Development discussions > related to Fedora" > > Cc: "Miro Hrončok" > Sent: Tuesday, February 9, 2021 5:30:45 PM > Subject: Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change > proposal) > > Charalampos Stratakis writes: > > > Well it seems so. I mean I would get it to an extend if this wasn't a > > *PR*. But anyway yes a two-line diff apparently should be a patch and > > not a sed. > > > > Also according to the PR comments I'm "unwilling" to do that upstream. > > That is not how that word is used - the full comment reads: > > > > Fixed the correct way in d269b84 > > This is a review of your code. You have submitted code, and I, the > reviewer, have indicated how it could have been improved, and shown how > I would have preferred it by example. This is normal open source stuff. > >> - You have not made these changes in a way that is helpful to the >> ecosystem as a whole That comment is neither a code review nor an indication of your preferences. Telling me that this PR doesn't help the ecosystem somehow is not helpful in addressing your point. I suggest to used a better tone in your wording. Written communication can be misinterpreted many times, but that's not an excuse for accusing others of ignorance of your words. > Are you unwilling to submit upstream? I can't say, hence the > conditional. What I can say (since upstream is me) is that you didn't. > >> - Once you had to figure out what files needed changed, you could >> simply have submitted a patch - as is done normally. This would >> have enabled me to apply it upstream if you were unwilling to >> submit it yourself. You can't say, yet you suggested it. You could always ask me to send a PR upstream which is the *normal* way of asking things. Also submitting a patch is normal and a sed is not? If you'd like to keep this technical please refrain from using non-technical wording then. I've changed PR's to adhere to maintainer's wishes but I always prefer to have a civilized and not an accusatory discussion over it. > > I don't see how that behavior helps the ecosystem. > > So I see it like this: > > Our goal is to land changes upstream. This helps for two reasons: not > only is our maintenance burden lowered by not carrying things downstream > in Fedora unnecessarily, but also other users (including other distros!) > get to benefit from our work. > > Broadly speaking, upstreams either want PRs on a github/pagure/gitlab > frontend, or patches on a mailing list. In either case, the format > requirements are the same: something they can directly feed into git-am > or git-pull. The more work a downstream maintainer has to do to > upstream something, the less likely they are to do it. > > So, if you want a change to help the ecosystem as a whole, upstream > first. Barring that, lowest barrier to upstreaming. I wholeheartedly agree to that. I still don't think that a 2-3 line change requires a patch but that's up for debate. If you'd like you can make a case for the Fedora packaging committee to ban the use of sed in the SPECs. Or you could ask in the PR. Instead you provide comments like: >> it's just Fedora deviating further from the rest of the >> world, not leading the charge. I'm sorry but while I can see your point, your way of trying to frame it is really not an optimal one. > > Thanks, > --Robbie > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 34 Change: Deprecate python-mock (Self-Contained change proposal)
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Development discussions related to Fedora" > > Cc: "Miro Hrončok" > Sent: Tuesday, February 9, 2021 8:58:36 AM > Subject: Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change > proposal) > > On Mon, Feb 08, 2021 at 07:54:00PM -0500, Robbie Harwood wrote: > > Miro Hrončok writes: > > > > > On 08. 02. 21 20:38, Robbie Harwood wrote: > > >> Robbie Harwood writes: > > >> > > >>> Ben Cotton writes: > > >>> > > >>>> A simple `sed` can be applied in `%prep` as a temporary (or even > > >>>> permanent) downstream solution. > > >>>> > > >>>> In most cases, performing the following replacement should be enough: > > >>>> > > >>>> s/^(\s*)import mock/\1from unittest import mock/ > > >>>> s/^(\s*)from mock import /\1from unittest.mock import / > > >>> > > >>> a couple lines of sed to all (affected) specfiles. I hope I have > > >>> misunderstood, because that has no mechanism to get the changes back > > >>> into upstreams. Could you clarify what you intend to do? > > >> > > >> Turns out this is indeed what they meant. I would like to reiterate > > >> my concern that this has no mechanism to get the changes back into > > >> upstreams: it's just Fedora deviating further from the rest of the > > >> world, not leading the charge. > > > > > > Not sure who you mean by "them" in this case, > > > > Change authors. So, you. > > > > > but doing this downstream only was never my intention. I am the change > > > owner. > > > > You have already replied to one of the PRs > > https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1 > > to comment that it couldn't be merged. It follows the downstream-only > > sed approach, you'll note. > > So... let me get this straight: the Change Owners found outdated code in your > package, created a page to describe the issue in detail, and opened a pull > request > to tell you exactly how you can update the code. And now you are pissed that > they didn't provide the two line diff in the the format that you like. > That's really a way to show appreciation of other people helping with your > packages. > > Zbyszek > ___ > 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 > Well it seems so. I mean I would get it to an extend if this wasn't a *PR*. But anyway yes a two-line diff apparently should be a patch and not a sed. Also according to the PR comments I'm "unwilling" to do that upstream. I don't see how that behavior helps the ecosystem. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Self Introduction: Isaac True
- Original Message - > From: "Isaac True" > To: devel@lists.fedoraproject.org > Sent: Sunday, November 1, 2020 10:55:29 AM > Subject: Self Introduction: Isaac True > > Hello everyone, > > My name is Isaac. I've been a long-time user of Linux and FOSS, and I work in > Germany as a software engineer for embedded devices, mostly programming in C > and Python. As a lot of my development work is currently based around SDR > platforms, I would like to help out with a few of the less cared-for SDR > packages, for example those for use with Analog Devices products, which would > help a lot with my work. > > I look forward to finally being able to give back to the Fedora community, > after many years of using it both at work and at home. > > Regards, > Isaac True > > GPG: F1AB63F9141BE32DB389816510560DD036DC52B3 > > ___ > 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 > Hello Isaac and welcome to Fedora! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide
d builds from it. > > > > > > Fedora features can be planned and discussed anywhere. In the mailing > > > list, bugzilla, github, IRC, Telegram, university hallway or Delirium > > > Cafe. > > > Change Process is an important and necessary step in landing the > > > feature in Fedora. But it is never the first step. > > > > Right, sorry about that. I can discuss a Fedora feature with let's say Neal > > on > > Telegram. But when we decide to actually do it, we'll use a public channel > > to > > discuss the change with the rest of the community before we execute our > > plan. > > > > >> There was no community involvement here, whatsoever. > > > > > > Please just stop excluding me from the community. > > > > I am not excluding you. When members of our community decide something > > privately, I don't consider it as community involvement. > > > > > We were supposed to have this discussion right now. Unfortunately you > > > choose to discuss the motivations of people doing ELN rather than the > > > work they do. > > > > You've announced this. There was no discussion. When I read an > > announcement, it > > is natural that I feel excluded from the decision process. > > Sorry, but you just need to accept the fact that some _early > development_ work in Fedora can happen without your decision on it. > You don't control the content of the copr repositories of the KDE SIG > for example. > > We need a centralized decision-making process to coordinate multiple > Fedora groups, to land changes in the release and to inform users > about them. > > Development work done in smaller groups has a risk of a wasted or > overlapping effort. But it has a benefit of moving faster. > There is always a trade-off, and it is up to the development team to > weigh them and decide, when is the right time to start the integration > effort. > > Ideally FESCo and Council should help dev teams with the process to > encourage the early exposure, so that benefits brought by the open > conversation outweigh the associated overhead. > But demanding the dev teams to report their every move to FESCo is not > how this help should look like. So basically you are saying that ELN can bypass the Fedora change process privately without the community involvement, right? Sorry but I don't think the decision making process of 1-2 people which will impact hundreds or thousands, consists as a "community involvement". This is a great violation of expectations the ELN SIG set, a violation of promises and honestly trying to insult the people who are opposed to that (political game? seriously?) just shows that this dishonesty is not something that makes the Fedora community a welcome place. I would urge you to reconsider not also this specific decision, but also how you respond to your fellow contributors, if you indeed consider yourself part of the community. > > I don't care thta > > much about my feelings wrt. this (I'm used to that), but I see that others > > felt > > the same. As a FESCo member, I feel like I need to represent all the > > packagers > > who will be impacted by this decision and who were left out from the > > decison > > process. > > > > I don't discuss the motivations, I discuss the process and the way this has > > been > > handled so far. I don't agree with that way. > > > > If ELN is part of Fedora, I strongly believe it should follow the > > established > > processes. The amount of energy we spend arguing about this could have been > > spend by proposing a Fedora change proposal about GCC 11. If it explains > > why to > > do this in ELN first, I am sure that it would help to clear the confusion. > > I > > would support such change. (See, my "political agenda" is not to stop the > > GCC > > update at all. Nor it is to tell you not to do it in ELN first.) > > > > > Look, I do agree that communication of the ELN SIG could be done better. > > > Maintaining a SIG is hard. The update of the docs I promised yesterday > > > is still pending. And we discussed with Stephen the bi-weekly meetings > > > but neither him nor me found the time to actually schedule them yet. > > > We will. > > > > > > And I opened this thread exactly for the reason to provide more > > > visibility into what SIG is planning to do. > > > > I appreciate that. However, now you received some feedback (not only from > > me). > > I see the feedback that ELN SIG should be more open. Agreed, noted. > > > You can choose to tre
Re: Giving away two of my package
- Original Message - > From: "Andy Mender" > To: "Development discussions related to Fedora" > > Sent: Tuesday, September 15, 2020 10:38:20 PM > Subject: Re: Giving away two of my package > > On Tue, 15 Sep 2020 at 12:04, Charalampos Stratakis < cstra...@redhat.com > > wrote: > > > Hello, > > I've got some packages that I do not have any use for anymore and I'd like to > give them away. If noone wants them I'll retire and orphan them in ~ a week. > > python-bna: https://src.fedoraproject.org/rpms/python-bna > > This is a Python library of Battle.net Authenticator routines, which contains > a command-line Battle.net authentication. > > Upstream https://github.com/jleclanche/python-bna seems somewhat active with > last commit on the 23rd of May. Latest version on rawhide is 4.1.0 and > upstream latest version is 5.0.0 > > Nothing depends on the package on rawhide. > > Could I take that package? > > Cheers, > Andy Added you as an admin. > > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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
Giving away two of my package
Hello, I've got some packages that I do not have any use for anymore and I'd like to give them away. If noone wants them I'll retire and orphan them in ~ a week. python-bna: https://src.fedoraproject.org/rpms/python-bna This is a Python library of Battle.net Authenticator routines, which contains a command-line Battle.net authentication. Upstream https://github.com/jleclanche/python-bna seems somewhat active with last commit on the 23rd of May. Latest version on rawhide is 4.1.0 and upstream latest version is 5.0.0 Nothing depends on the package on rawhide. pipsi: https://src.fedoraproject.org/rpms/pipsi A wrapper around virtualenv and pip which installs scripts provided by python packages into separate virtualenvs to shield them from your system and each other. The project https://github.com/mitsuhiko/pipsi/ is not maintained anymore upstream and a replacement is developed instead: https://github.com/pipxproject/pipx Nothing depends on it as well -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 33 System-Wide Change proposal: Make nano the default editor
+1 I'm all for making the user experience better, and I think this change contributes to that. - Original Message - > From: "Ben Cotton" > To: devel-annou...@lists.fedoraproject.org, "Development discussions related > to Fedora" > > Sent: Thursday, June 25, 2020 7:18:59 PM > Subject: Fedora 33 System-Wide Change proposal: Make nano the default editor > > https://fedoraproject.org/wiki/Changes/UseNanoByDefault > > == Summary == > > Let's make Fedora more approachable, by having a default editor that > doesn't require specialist knowledge to use. > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: chrismur...@fedoraproject.org > > > == Detailed Description == > > Users are exposed to the default editor when they use commands that > call it. The main example here is something like git > commit. > > Fedora does not currently have a default terminal text editor, because > the $EDITOR environment variable is unset by default. But a common > scenario where users wind up in a terminal text editor is when using > 'git commit'. By default, git picks vi. You need to spend time > learning how to use it, for even basic editing tasks. This increases > the barrier to entry for those who are switching to Fedora and don't > know how to use vi. It also makes things hard for those who don't > particularly want to learn how to use vi. (These arguments would apply > just as well if git picked Vim. vi is like hard mode for Vim, with > fewer features, missing syntax highlighting, and no indication of what > mode you are in. Even Vim users may feel lost and bewildered when > using vi.) > > In contrast, Nano offers the kind of graphical text editing experience > that people are used to, and therefore doesn't require specialist > knowledge to use. It is already installed across most Fedora Editions > and Spins. This proposal will make Nano the default editor, while > continuing to install vim-minimal (which provides vi, but > not Vim). People will still be able to call vi if they > want to edit a file. It will also obviously be possible to change the > default editor to vi or Vim, for those who want it. > > Why make Nano default and vi optional, rather than the other way > round? Because Nano is the option that everyone can use. > > == Feedback == > > Pending ... > > == Benefit to Fedora == > > * Makes the default editor across all of Fedora more approachable. > * Nano is also mostly self-documenting, by displaying common keyboard > shortcuts on-screen. > * More in line with the default editor of other distributions. > > == Scope == > * Proposal owners: > ** Modify comps to include nano Fedora wide. > ** Create a new subpackage of nano, called > nano-editor. > ** nano-editor to include > /usr/lib/environment.d/10-nano.conf, which sets > $EDITOR to nano. > > With this approach, if nano is uninstalled, the > configuration will be removed with it. At the same time, installing > nano on its own won't install the conf. > > * Other developers: N/A > > * Release engineering: [https://pagure.io/releng/issue/9522 #9522] > > * Policies and guidelines: N/A > > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Will not apply to upgrades. > > == How To Test == > > Run export EDITOR="/usr/bin/nano". > > == User Experience == > > Users running git commit will be able to just type their > commit message, rather than having to learn about insert mode, and > they'll be able to cut and paste without having to learn special > shortcuts. > > == Dependencies == > > No additional dependencies are required. > > == Contingency Plan == > The contingency plan is to revert the change by removing the > nano-editor package. > > * Contingency deadline: probably the beta? It's an easy change to revert. > * Blocks release? If the change breaks the redirection to an editor, > it should block the release. However, this is unlikely. > * Blocks product? Potentially all. > > == Documentation == > As part of this change, it would be good to add instructions for > changing the default editor to the > [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs]. > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: ht
Re: Day one of the datacenter service migration
- Original Message - > From: "Clement Verna" > To: "Development discussions related to Fedora" > > Cc: "Kevin Kofler" > Sent: Tuesday, June 9, 2020 9:04:43 PM > Subject: Re: Day one of the datacenter service migration > > > > On Tue, 9 Jun 2020 at 16:29, Charalampos Stratakis < cstra...@redhat.com > > wrote: > ... snip > > > > > > The elections app seems to be broken for me though, so I can't vote at this > point. > > This is now fixed so you should be able to vote :-). > Indeed it's fixed now, thanks! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Day one of the datacenter service migration
- Original Message - > From: "Miro Hrončok" > To: "Development discussions related to Fedora" > , "Kevin Kofler" > > Sent: Tuesday, June 9, 2020 1:22:18 PM > Subject: Re: Day one of the datacenter service migration > > On 09. 06. 20 11:26, Kevin Kofler wrote: > > Kevin Fenzi wrote: > >> The openshift apps move caused a outage for the elections app (both a > >> short one while it was entirely down, and another short time when > >> authentication wasn't yet working) > > > > Doing a migration of the elections app in the middle of a voting period > > sounds like very bad timing to me. > > > > Will the voting period be extended to compensate for the outage? > > The outage of elections app was very short and not near the deadline (so > people > affected had (still have) a chance to come back a bit later). I don't think > it > satisfies an extended voting period. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > The elections app seems to be broken for me though, so I can't vote at this point. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
- Original Message - > From: "Tomasz Kłoczko" > To: "Development discussions related to Fedora" > > Sent: Friday, May 22, 2020 11:51:48 AM > Subject: Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side > tag > On Fri, 22 May 2020 at 10:27, Peter Pentchev < r...@ringlet.net > wrote: > [..] > > > Originally was python package. Than was python python2 and python3. Now > > > it > > > > is python3.9. > > > > Why not is used still and just python and to provide necessary > > > dependencies > > > > during transition python3.8? > > > > That way as well is casing that with each python major version upgrade > > > all > > > > macros needs to be multiplied. > > > Are you asking why python3.8 and python3.9 are separate packages? > > No I'm not. > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > 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 I don't understand your concern though. The Python 3.9 package provides the exact same things that were provided with the unversioned package, other packages don't need to change anything related to macros. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Many packages unnecessarily link to libpython
- Original Message - > From: "Richard W.M. Jones" > To: "Charalampos Stratakis" > Cc: "Development discussions related to Fedora" > , ebl...@redhat.com > Sent: Friday, May 15, 2020 8:50:31 PM > Subject: Re: Many packages unnecessarily link to libpython > > On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote: > > nbdkit rjones > > I guess nbdkit is one of the good ones? We link to libpython because > we want to run Python code from a C main program (nbdkit, an NBD > server written in C). > > http://libguestfs.org/nbdkit-python-plugin.3.html > http://libguestfs.org/nbdkit.1.html > https://en.wikipedia.org/wiki/Network_block_device > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > By having a quick glance at plugins/python/python.c it seems that indeed nbdkit is required to link to libpython. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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
Many packages unnecessarily link to libpython
leigh123linux nemo-extensions limb Io-language link-grammar pitivi lkundrak insight kicad nextpnr trellis lmackenmod_wsgi lslebodn libldb libtalloc lucilanga hamlib libftdi luya YafaRay blender openvdb m4rtinkpyotherside makowski libyui-bindings marcindulak gpaw nwchem martinkg vdr-epg-daemon matt condor mattia calamares matyas condor matyc openscap mblaha createrepo_c libcomps libdnf mcrha pidgin mhlavink collectd minh kdevelop-python mjeanson babeltrace2 mmahut gnuradio monnerat insight python-caja mpreisle openscap mrceresa gdcm vtk mrnuke libsigrokdecode mrunge mod_wsgi syslog-ng mycae mathgl nacho libpeas nb znc ngompa libyui-bindings niveusluna weechat nonamedotc thunarx-python nosnilmot pidgin nottinggnucash nushio calibre obnox samba ohaessler hexchat okeebledmlite oliver mapserver orion gdl paraview plplot vtk pali mapserver panovotn postgresql pavlix unbound pbrobinson csound kernel-tools libcec libplist mraa upm pcpa pynac pemensik ldns unbound pkajabapostgresql pkratoch createrepo_c libcomps libdnf librepo pkubat postgresql pnemadefontforge praiskup postgresql pvrabecopenscap pwalterscribus pwouters ldns unbound raphgropython-jep rathannapbs openbabel raveit65 python-caja rdieterPyQt4 cantor kig krita python-qt5 rebus dionaea rjones nbdkit rmatteshokuyoaist rocha dmlite roma YafaRay blender ruben collectd s4504krblender sagitter COPASI apbs libCombine libnuml libsbml libsedml paraview sbergmann libreoffice sdzcsound sebp gdcm sergesanspaille lldb sergiodj gdb sgallagh libldb libtalloc sharkczgr-rds scribus sigil siddharths lldb simo libldb libtalloc samba slaanesh YafaRay blender openvdb vapoursynth smani getdp libbatch libkml med netgen-mesher somlo nextpnr trellis spot libarcus-lulzbot steve ceph stevenfalco kicad stevetraylen condor stingray ceph weechat tachoknight swift-lang tglpostgresql than PyQt4 cantor python-qt5 thofmann clingo orocos-kdl thozza ldns unbound tingping hexchat tkorbarlibyang tmlcochcreaterepo_c librepo tnorth kicad tomspurpynac tpokorra libkolabxml libyui-bindings tripledes scribus tross qpid-dispatch tstclair condor tstellar lldb ttheisen condor valtri condor volter qgis wsato openscap wtaymans pitivi python-gstreamer1 xaeth collectd zbyszekcalibre libsbml zdohnalvim zultronfreecad -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Python packages up for adoption
- Original Message - > From: "Jeremy Cline" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 21, 2020 11:38:05 PM > Subject: Python packages up for adoption > > Hi folks, > > Over the years I've managed to collect a number of Python packages for > which I am the sole maintainer. Sadly, I'm not really maintaining them, > so unless anyone wants to pick them up I'm going to orphan them. They > are: > > python3-saml > python-args > python-clint > python-flower > python-idna > python-invocations > python-matrix-synapse-ldap3 > python-phonenumbers > python-readme-renderer > python-social-auth-app-flask > python-social-auth-app-flask-sqlalchemy > python-social-auth-core > python-social-auth-storage-sqlalchemy > python-sphinxcontrib-fulltoc > python-sqlalchemy_schemadisplay > python-twine > > Regards, > Jeremy > ___ > 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 > Hey Jeremy, Thanks for your work so far. I would take python-twine. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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
Compiler optimizations and Fedora's default hardening compiler flags
Hello all, Currently on Fedora the -D_FORTIFY_SOURCE=2 compiler flag is enabled by default. However it seems that the minimum acceptable optimization option for it, is -Og and if -O0 is specified, a ton of warnings are generated: warning _FORTIFY_SOURCE requires compiling with optimization (-O) My use case is the python3-debug package, as compiling it with -Og, optimizes out a lot of information that python's gdb integration tests for. Some of the previous discussions on it [0][1]. There has been a proposal to gcc upstream to overhaul the -Og option [2] but it didn't move anywhere. So my solution to that would be to change the default compilation option for the python3-debug package to -O0 and strip out -D_FORTIFY_SOURCE=2 from CFLAGS. This provides us with an obvious solution to the issue, instead of debating about compiler semantics, however that would go against Fedora's default compilation options. Would that be an acceptable solution for this issue? AFAIK the flag cannot be disabled by conventional means, which hints that packages are not supposed to meddle with it, however I can't see any way of moving things forward. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1734327 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1818857 [2] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01394.html -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4
- Original Message - > From: "Stephen Gallagher" > To: devel-annou...@lists.fedoraproject.org > Sent: Monday, April 6, 2020 11:53:47 PM > Subject: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I've just published a fourth version[1] of the ELN proposal. With a > lot of input from Miro Hrončok, I think I've finally been able to > clarify some of the points that we were getting hung up on. > > Changes in this version of the proposal[2]: > > * Improve our explanation of why we are doing ELN in the first place > * Clarify the relationship with Rawhide > * Better describe what happens if packages don't build on ELN > * Explain our plan for when to use conditionals (this was getting a > larger share of the conversation than it warranted because we didn't > do a good job of explaining that they should be the exception and not > the rule) > * Clarify that the time limit on PRs is only for determining if the > maintainer is responsive. If they reply, the timer is cleared. > * Fixed the question about upstream features to make it clear that > what we meant is that new features should go upstream first, not be > implemented as a fork in ELN > * Added a section explaining how we will deal with side-tags > * Make it clear that we don't want to diverge wherever possible and > that any planned divergence should be discussed with the ELN SIG ahead > of time > * Cleaned up the contingency plan section. > > I hope that these changes will make our position more clear. Thank you > to everyone who has contributed to this discussion. I think the > feedback has been very valuable and I sincerely appreciate it. > > > > [1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > [2] > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=570854=570256 > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo > bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp > eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn > EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk > 3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/ > f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq > rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW > IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY > Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI > 8ShPIeos > =+lwN > -END PGP SIGNATURE- > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-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-annou...@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://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 > I've glanced briefly through the changes, and while I didn't have time to properly solicit feedback on the info, I would like to say a big thank you for hearing our feedback and working with that. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
- Original Message - > From: "Michael Catanzaro" > To: "Development discussions related to Fedora" > > Sent: Monday, April 6, 2020 3:37:34 PM > Subject: Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose > V3 > > On Sun, Apr 5, 2020 at 5:08 pm, Charalampos Stratakis > wrote: > > It is reasonable to provide a pull request to fix potential issues > > with ELN. What is not reasonable, is to impose a time limit and also > > expect the maintainers to follow up with that. > > If allowing the ELN maintainers to fix build failures when the > maintainer is unresponsive is "unreasonable," then I guess it will > never build and this is all a pointless exercise. Setting up impossible > requirements doesn't seem fair to the ELN developers. > I don't think I've mentioned the word 'unresponsive' anywhere, please don't move the goalposts here. > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: CPE Weekly: 2020-04-04
- Original Message - > From: "Randy Barlow" > To: devel@lists.fedoraproject.org > Sent: Saturday, April 4, 2020 10:35:21 PM > Subject: Re: CPE Weekly: 2020-04-04 > > On 4/4/20 3:02 PM, Aoife Moloney wrote: > > However we do > > recognize that it was still nonetheless a decision that was not made > > in public, and for that we can only now offer our apologies for this > > mistake and learn a hard lesson from it. > > It's simply not true that this is the only thing that can be done. You > can hold off on making a decision, and follow an open process instead. > > > We do want to let you know that we deeply appreciate the requirements > > you have given us and would like to ask you to continue engaging with > > us while we are moving through our next steps with GitLab. > > What would be the goal if the community were to continue to engage with > CPE management when it has demonstrated that it does not meaningfully > engage with the community? > ___ > 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 > Indeed. I see no reason at all in engaging in any sort of community feedback at this point. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
ntrusive change. I'm obviously biased here, but looking, as an example at the state of the Python, Ruby, Perl ecosystem across Fedora and RHEL, you can see the Fedora work is not only important, but the main drive for a healthy RHEL ecosystem. And I'm happy to say my management understands that. """ ELN artifacts will be made available for testing and development purposes, but we will not be shipping any content produced from ELN directly to the general public (such as on the standard mirror network or via getfedora.org). This does not necessarily mean that they will be shipped directly from Koji, merely that they won't come from the standard locations. """ It would be better to provide artifacts, there is no reason to keep this in a black box, maybe I'd like to spin VM's, maybe containers. Just updating a regular rawhide installation to eln in order to test a simple fix is not something I would do very enthusiastically. Some more thoughts: Since the current Fedora infrastructure is already stretched thin, especially with modularity, koschei rebuilds, the CI and so on, has a possible impact on the load been considered/measured? I know for starters that the tasks will have a lower priority, however has any assessment been made to get a rough idea on what and if any additional resources will be required? I'd also like to point out that all the past system-wide changes, except from maybe rebases of important packages, have always had detailed descriptions on how they were going to be implemented and a well laid-out contingency plan. They weren't mere ideas, and while I understand that not all questions can be answered at this point, starting with a very high level goal and iterating on it, is not something to be done as a fedora system-wide change, not at least since some details need to be cemented on the aforementioned points. A system-wide change and the fedora devel thread of it, is a place to gather feedback from the community, incorporate that and move forward from there, not somewhere where blind trust should be placed on the change owners and accuse people and even elected representatives of ignoring feedback. It really does seem like projection when placing the whole conversation into context. I understand that especially during those trying times, everyone might be a bit on edge while trying to stay productive and within the deadlines, however it really does seem that the change owners and the community are talking entirely past each other at this point. Some time ago, during the discussion of the default modular streams, there was a big pushback on some aspects of it from the community and the feedback was rejected and/or ignored in a similar manner that happens throughout those ELN threads. In the end, the eclipse module did exactly that and it affected a big portion of our userbase: https://bugzilla.redhat.com/show_bug.cgi?id=1780827 So overall, I'm -1 on the proposal and as things currently stand, I won't be adding any of those conditionals at the Python SPEC files or any other smaller library that I maintain. I'll happily reconsider if the feedback is heard and the pain points have been addressed or are at least planned to be addressed. P.S. It took me some days to actually draft this mail, as in general those times, emotions can run wild and I wanted to be objective, if that's even possible. And I understand that some things might have changed as the thread progressed, so apologies if any of my points are not valid anymore. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: CPE Git Forge Decision
- Original Message - > From: "Erich Eickmeyer" > To: devel@lists.fedoraproject.org > Sent: Friday, April 3, 2020 2:02:23 AM > Subject: Re: CPE Git Forge Decision > > On Thursday, April 2, 2020 4:56:33 PM PDT Adam Williamson wrote: > > Correction here: the decision process *was* actually initiated quite > > publicly. It was announced in January, in a thread titled "Git Forge > > Requirements: Please see the Community Blog", which (as you'd guess) > > linked to a Community Blog post announcing that a decision was to be > > made under the Open Decision Framework: > > > > https://communityblog.fedoraproject.org/git-forge-requirements/ > > Ok, I stand corrected then. :) > > > thus far, I'd say that was an example of good process, on the face of > > it. > > Yes, on the face, and with good intentions nonetheless. :) > > > It can be argued that things went wrong later. > > I agree 100% with that. Either way, Jeremy should not have been made to feel > the way he is feeling, and I would guess that applies to many people in this > thread. My point still stands that there was a failure at the leadership > level. > I concur with that. The way this was handled later in the process is a great example on how to not do things and how the decision is being communicated is an utter mess. I don't have a strong preference in respect to Gitlab or Pagure, however the memories are still fresh of when we had to move from pkgdb to pagure because modularity needed it, and now after such a long time that we have a feature parity, compared to our previous workflows, we will have that changed again. But the negative feelings and memories of the previous change do not go away that easily and proposing such a change could very well bring up strong emotions. Adding to it the way this was handled afterwards, included being at odds with the Fedora's project statements only adds fuel to the fire. > Erich > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Help needed to get dependencies in EPEL 8 for pagure
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Cc: "Pierre-Yves Chibon" , "Pete Walter" > , "Fedora Python SIG" > > Sent: Thursday, March 26, 2020 1:50:30 AM > Subject: Re: Help needed to get dependencies in EPEL 8 for pagure > > 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 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. > > > > > > > > > > So, an update: after this most recent push, most of Pagure's > > > dependencies are now in EPEL 8. > > > > > > We're still missing celery... > > > > > > > Celery is now in EPEL 8, so we're good here now! > > > > > > > > And we're still missing pygit2... > > > > > > > * python-pygit2: pwalter > > > ... > > > > A note here: RHEL 8 ships libgit2 0.26.8, so we need pygit2 0.26.x. > > > > And now pygit2 is the only remaining missing dependency! We're nearly > > to the finish line! > > > > And now it's all done, with Pagure 5.9.0 landing in EPEL 8: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a504acc25e > > Thanks to everyone who helped make this happen! > > Thank you Neal for driving this! > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Heads up: OpenSSL-1.1.1e coming to Rawhide
- Original Message - > From: "Tomas Mraz" > To: "Miro Hrončok" , "Development discussions related to > Fedora" > Cc: "python-maint" > Sent: Tuesday, March 24, 2020 1:22:37 PM > Subject: Re: Heads up: OpenSSL-1.1.1e coming to Rawhide > > On Sun, 2020-03-22 at 17:29 +0100, Miro Hrončok wrote: > > On 19. 03. 20 17:31, Tomas Mraz wrote: > > > The new openssl-1.1.1e is coming to Rawhide. > > > > > > It reports premature EOF/improper shutdown on TLS connections more > > > properly. However this might make some dependencies broken in build > > > tests (such as Ruby). > > > > > > As I would like to eventually update the openssl also on stable > > > branches because it brings many bugfixes please consider bringing > > > eventual fixes/workarounds in depending packages also there. > > > > Packages failing to build: > > > > https://koschei.fedoraproject.org/affected-by/openssl?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33 > > > > https://koschei.fedoraproject.org/affected-by/openssl-devel?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33 > > > > That includes Python interpreters. > > > > We have Python tests defined in the CI: > > > > https://src.fedoraproject.org/rpms/openssl/blob/master/f/tests/tests_python.yml > > > > Why have this upgrade never been tested that way? > > I knew there will be actual problems so that is the reason why I sent > the heads up. Next time I'll make sure the CI is run as well, not sure > if it would make any difference in this case apart from maybe I would > open bugs right away? With the PR workflow on pagure, the CI would be run and we can check out the issues that might appear on the python side at least, as we have added the relevant python tests in the openssl pagure repo. So indeed it would help a lot. > > > Please do not push this to older releases until we fix this. > > I will not push it to older releases. Most probably we will revert this > change in upstream 1.1.1 branch and I will update the rawhide build > with the revert patch as well. Anyway this change is going to stay in > the master branch of OpenSSL (for 3.0.0) so it is a good idea to be > able to handle it in the dependencies anyway. > That would be great actually, thanks for considering it. Pushing this change for the 3.0.0 version of OpenSSL should provide us with enough time to iron out everything. On a side note, is there some upstream CI of OpenSSL where we could maybe test its integration with Python, or other projects? From the python upstream CI side, where we use the buildbot software, we noticed that when the fedora servers running the builds got the openssl package updated, the tests started failing. Maybe something similar could be implemented for OpenSSL, depending of course if the infrastructure is in place. > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Code of Conduct issue
- Original Message - > From: "John M. Harris Jr" > To: "Development discussions related to Fedora" > > Sent: Tuesday, March 24, 2020 11:34:50 AM > Subject: Re: Code of Conduct issue > > On Tuesday, March 24, 2020 3:29:58 AM MST Dominik 'Rathann' Mierzejewski > wrote: > > John, > > > > On Tuesday, 24 March 2020 at 06:16, John M. Harris Jr wrote: > > [...] > > > > > Further, attempting to censor *this topic* is not in the spirit of the > > > Friends foundation either. It is important that we, as a community, > > > can discuss the rules we've chosen to govern our actions within this > > > project. If we cannot, they are not our rules, and so we need to get > > > rid of them. Attempting to censor such concerns will only cause > > > cohesion issues within the project. > > > > > > Redirecting an off-topic thread to a venue where it will be on-topic is > > not censorship. > > That's not what is going on here, clearly. They're attempting to sweep this > under the rug, and hide it from the majority of Fedora contributors, likely > because the majority of Fedora contributors either don't care about what has > to be said, and have no objection to it being on Fedora Planet for that > reason, or because they would outright support this individual's blog being > aggregated through Fedora Planet. It should go without saying, but the FLOSS > community strongly supports Freedom. > > -- > John M. Harris, Jr. > Splentity > > ___ > 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 > Why would you care though, care to elaborate? And how would you personally know what is going on? Clearly there are reasons for it to go to a different venue and you just blindly assume that this is censorship and whatnot. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Non-responsive maintainer: pwalter
- Original Message - > From: "Pete Walter" > To: "Neal Gompa" > Cc: "Development discussions related to Fedora" > , "Pete Walter" > > Sent: Saturday, March 21, 2020 4:44:43 PM > Subject: Re: Non-responsive maintainer: pwalter > > 21.03.2020, 10:15, "Neal Gompa" : > > On Sat, Mar 21, 2020 at 6:02 AM Pete Walter wrote: > >> For months!? This is the first email I get from you. Just for the record, > >> I am around, but have 0 interest in EPEL 8 as of the moment. > > > > In that case, I'd be happy to take on co-maintainership (admin) or > > even take over the package entirely from you (main admin), if you > > wish. > > After this kind of treatment there's no way I'm giving you access to any of > my packages. Please learn how to work in a group. > > Pierre is going to help out with the EPEL 8 branch. > > Pete > ___ > 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 > Neal's responses and requests were entirely respectful, even more so than I would expect, after his repeated attempts to remedy the situation and your non-responsiveness, and I'm surprised you accuse him on top. I would advise to refrain from such baseless accusations on community members, there was no 'demand' on anything, the proper procedures were followed. Also: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Self Introduction: Jochen Breuer
- Original Message - > From: "Jochen Breuer" > To: devel@lists.fedoraproject.org > Sent: Friday, February 21, 2020 9:46:46 PM > Subject: Self Introduction: Jochen Breuer > Hello everybody! > As you can read from the subject my name is Jochen Breuer and I'm one of the > lucky people that is being payed for working on open source. I'm a remote > employee of SUSE Germany and I'm working on the SUSE Manager team. My squad > is taking care of Salt for SUSE Manager, Uyuni (the upstream of SUSE > Manager) and openSUSE itself. That's why you will find my name a lot in the > changelog for Salt, but also in the changelog for Cobbler – where I'm also > an upstream maitainer. If you are interested you can find some more > information about me on openSUSE Connect: > https://connect.opensuse.org/pg/profile/brejoc > Some time ago I helped to get the Python3 port of urlgrabber started and this > is the reason why i'm here. You guys are looking for upstream and package > maintainers for urlgrabber and we are using it in Cobbler, SUSE Manager and > Uyuni. Perfect fit! ;) > Neal Gompa already volunteered to guide me and told me that we'll start with > a new (small) package so that I can get familiar with the Fedora specific > tools. Thanks Neal! > I look forward to working with you! > Jochen > ___ > 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 Welcome to Fedora Jochen, glad to have you here! And thank you for your help on porting urlgrabber to Python 3, every piece of software moving away from Python 2 is helping the ecosystem move forward. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Announcement: EPEL Steering Committee Changes
- Original Message - > From: "Stephen John Smoogen" > To: "EPEL Development List" , > "Development discussions related to Fedora" > > Sent: Tuesday, February 18, 2020 6:35:26 PM > Subject: Announcement: EPEL Steering Committee Changes > > Hi, > > It has been a pleasure for me to be a part of and help lead the > EPEL steering committee for the last couple of years. It has not > always been smooth sailing but I have found it an enjoyable experience. > > However, as you may know the Fedora project will be moving to a > different data-center later this spring (from Phoenix to northern > Virginia). Being involved in the planning and implementation of this > project, I do not think that I will be able to give EPEL the time > investment it deserve for the next 6 to 9 months. With EPEL-8 still > ramping up and the various opportunities with modularity, I do > not think it is a fair that EPEL suffers from this lack of time. > > As such, I would like to step down as chair/member of the steering > committee and nominate Troy Dawson as my replacement. Troy formerly > worked on Scientific Linux and has worked on OpenShift and other > projects at Red Hat for the last several years. It is clear he has a > good eye on the concerns and problems enterprise users have. Recently, > Troy helped get the initial RHEL-8 and EPEL-8 out the door with > multiple builds and updates to various macro files. > > Once the move is completed and the close down of the old site is done, > I look forward to getting involved again in EPEL. > ___ > 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 > Thank you for all your work throughout the years. I believe Troy would be an excellent replacement. I've worked with him before on some initiatives and he's always been very supportive and swift in answering questions and figuring out issues from the tiniest detail to the higher level. So Stephen good luck on your next endeavors and Troy welcome :) -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: modular protobuf issue (Dec. 6, 2019) recap
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Development discussions related to Fedora" > > Sent: Saturday, December 7, 2019 2:55:30 PM > Subject: Re: modular protobuf issue (Dec. 6, 2019) recap > > On Fri, Dec 06, 2019 at 08:18:21PM -0500, Langdon White wrote: > > ## How to determine if you have an issue and how to fix it: > > > > run: ```sudo dnf list --installed *protobuf*``` > > if you get a result that looks like > > ```protobuf.x86_64 3.6.1-6.module_f31+6793+1c93c38``` > > > > you have encountered the problem. so please: > > > > run: ```sudo dnf module disable eclipse``` > > run: ```sudo dnf downgrade protobuf``` > > > > Any updates, as of a few hours ago, should be fine. > > > > ## What happened: > > First and foremost, this issue appears to be caused by Modularity but, in > > fact, is just an example of a policy not being followed. > > This is correct, but at the same time imo very short-sighted. > Look at it this way: setting the eclipse module as default was discussed > in the FESCo issue tracker and in IRC meetings for about two months. > I think that this particular stream had undergone scrutiny that is > _way above normal_. The requests for additional information in the > FESCo ticket were overruled. Despite that when it gets enabled things > go south and require manual workarounds. It seems that introspectability > of modules is not good and even the people who designed Modularity > can't do the required checks. > > Now let's imagine that we don't have just a handful of streams, most > of them very trivial, but a few hundred, including some that build > complicated dependency trees, with actual multiple versions of dependencies. > Nobody will have the time or energy to do introspection, so those kinds > of issues will go undiscovered until reported by users. How often would > such issues occur, e.g. a few hundred times per year? > > For this it doesn't really matter if the modules are default or not: > either enabled as a default or explicitly by the user, modules *will* > override other packages they shouldn't, sometimes by mistake, > sometimes on purpose as a result of a disagreement between maintainers. > With modularity, any module owner has effectively *higher* privileges > than owners of packages, because modules override non-modular builds. > > Why do I think this is more of a problem with modules? Right now we > have an elaborate and long-established system with maintainers, > co-maintainers, proven packagers, and mass changes, i.e. some formal > and some customary rules as to what can be done to packages of other > maintainers and who is "at fault" with any given bug. Modularity > throws this system out the window and replaces it with ... nothing. > > Zbyszek > ___ > 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 > Exactly. It might be a policy issue, but I haven't seen any checks in place to ensure that the policy is being followed. The only way to figure out a policy violation is being reported by someone if at all. And if as a module maintainer want to override non-modular rpm's by accident or maliciousness on stable systems, now I get that capability with modularity. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 31: dnf upgrade suddenly enables modular streams for protobuf
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Friday, December 6, 2019 6:12:32 PM > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for > protobuf > > On Fri, Dec 6, 2019 at 12:11 PM Charalampos Stratakis > wrote: > > > > > > > > - Original Message - > > > From: "Stephen Gallagher" > > > To: "Development discussions related to Fedora" > > > > > > Cc: "Mat Booth" , > > > protobuf-mainatin...@fedoraproject.org > > > Sent: Friday, December 6, 2019 5:59:50 PM > > > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for > > > protobuf > > > > > > On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko > > > wrote: > > > > > > > > Thanks for CCing me (maintainer of protobuf here), I am particularly > > > > not happy that some module (which is not even called protobuf, but > > > > some random Java #$%! with ripped out python support overrides my > > > > builds). > > > > > > > > I have put a proposal into a FESCo ticket. > > > > > > > > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok > > > > wrote: > > > > > > > > > > Today I've attempted to run "dnf upgrade". > > > > > > > > > > It has the following in it: > > > > > > > > > > Upgrading: > > > > > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular > > > > > > > > > > Enabling module streams: > > > > > ant > > > > > eclipse > > > > > maven > > > > > > > > > > > > > > > I don't consider this behavior adequate for a released Fedora > > > > > version. > > > > > > > > > > As a maintainer of dependent packages (Cura stack) I have tested and > > > > > built it > > > > > against the nonmodular protobuf. What just happened here and how do I > > > > > track it down? > > > > > > > > > > dnf doesn't even tell me what module is this in. I suppose eclipse. > > > > > > > > > > However, protobuf was not mentioned in > > > > > https://pagure.io/fesco/issue/2285 > > > > > > > > > > > > > > For the record, I've just pushed a temporary removal of the eclipse > > > default stream, so the next compose will not have it. For those of you > > > who are affected, your best bet would be to use `yum history rollback` > > > and wait to update again until tomorrow. > > > > I got affected as well and I guess a big number of people also. > > > > Is it safe to assume that with the next compose the extra modules will be > > disabled/removed when doing a dnf update? Or do we need to rollback the > > update? > > > > No, the extra modules won't be disabled/removed automatically. The > change I made is to ensure no one else gets hit. You will need to roll > back the update if you were affected. I would like to mention here that this is the first time that a modularity issue affected me negatively as a user. I maintain a quite pristine system with fedora 31 on my home computer, knowing full well, exactly what is installed, dependencies, configs etc. And at some point while doing the schedule dnf update I get 3 modules enabled for whatever reason that I had no control over. No information, nothing. I get there might be some quirks here and there, but having that done on a stable fedora due to eclipse moving into a module so late in the release cycle is just unacceptable. I don't know what a good solution would be here, maybe have eclipse as a flatpak only or something, but this is clearly breaking user experience and expectations. > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 31: dnf upgrade suddenly enables modular streams for protobuf
- Original Message - > From: "Miro Hrončok" > To: devel@lists.fedoraproject.org > Sent: Friday, December 6, 2019 6:13:08 PM > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for > protobuf > > On 06. 12. 19 18:10, Charalampos Stratakis wrote:>> For the record, I've just > pushed a temporary removal of the eclipse > >> default stream, so the next compose will not have it. For those of you > >> who are affected, your best bet would be to use `yum history rollback` > >> and wait to update again until tomorrow. > > > > I got affected as well and I guess a big number of people also. > > > > Is it safe to assume that with the next compose the extra modules will be > > disabled/removed when doing a dnf update? > > As of the moment, once a modular stream is enabled implicilty, there is no > way > to disable it implicitly. > > > Or do we need to rollback the update? > > Rollback or disable explicitly. That is more than unfortunate. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 31: dnf upgrade suddenly enables modular streams for protobuf
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Cc: "Mat Booth" , > protobuf-mainatin...@fedoraproject.org > Sent: Friday, December 6, 2019 5:59:50 PM > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for > protobuf > > On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko > wrote: > > > > Thanks for CCing me (maintainer of protobuf here), I am particularly > > not happy that some module (which is not even called protobuf, but > > some random Java #$%! with ripped out python support overrides my > > builds). > > > > I have put a proposal into a FESCo ticket. > > > > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok wrote: > > > > > > Today I've attempted to run "dnf upgrade". > > > > > > It has the following in it: > > > > > > Upgrading: > > > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular > > > > > > Enabling module streams: > > > ant > > > eclipse > > > maven > > > > > > > > > I don't consider this behavior adequate for a released Fedora version. > > > > > > As a maintainer of dependent packages (Cura stack) I have tested and > > > built it > > > against the nonmodular protobuf. What just happened here and how do I > > > track it down? > > > > > > dnf doesn't even tell me what module is this in. I suppose eclipse. > > > > > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285 > > > > > > For the record, I've just pushed a temporary removal of the eclipse > default stream, so the next compose will not have it. For those of you > who are affected, your best bet would be to use `yum history rollback` > and wait to update again until tomorrow. I got affected as well and I guess a big number of people also. Is it safe to assume that with the next compose the extra modules will be disabled/removed when doing a dnf update? Or do we need to rollback the update? > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Announcing new anitya integration and de-orphaning process
- Original Message - > From: "Pierre-Yves Chibon" > To: devel-annou...@lists.fedoraproject.org > Sent: Tuesday, November 26, 2019 1:13:45 PM > Subject: Announcing new anitya integration and de-orphaning process > > Good Morning Everyone, > > Tomorrow we are planning on deploying a new version of pagure and > pagure-dist-git on production. > > These changes come with two changes to the packager workflow: > > * Anitya integration in dist-git > > Something we lost when loosing pkgdb was the easy integration to anitya > (https://release-monitoring.org). With the coming changes we are getting them > back. > > On the left hand-side column, there will be a drop-down button allowing to > change the settings for anitya for the project. > Existing status will be migrated from the fedora-scm-requests repo on pagure > to > use this drop-down. > Using the fedora-scm-requests repo for the anitya integration will no longer > be > supported. > > * Change in the de-orphaning process > > Currently if a package is orphaned, one has to open a ticket against the > releng > project to adopt it. With these changes, anyone will be able to adopt > orphaned > projects (not retired on master) directly from dist-git's UI. > If the project is retired or has been orphaned for too long, a ticket on the > releng project will still be required though. > > > Both of these changes can already be reviewed in staging at: > https://src.stg.fedoraproject.org > > > Looking forward for your feedback! > Pierre > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-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-annou...@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://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 > Thank you, that is awesome work! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Minimization Objective report
- Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Thursday, November 21, 2019 1:08:34 AM > Subject: Re: Minimization Objective report > > Charalampos Stratakis wrote: > > We heard the feedback and did a lot of experimentation and benchmarking > > with a ton of different options so I really can't fathom how you are > > taking credit for something that others invested so much time in. > > The new Feature page: > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup > > explicitly credits 4 people, one of whom is me: > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup#Owner > > Shout-out: Jan Kratochvíl for first suggesting this instead of the > > original proposal, followed by Kevin Kofler. Florian Weimer for providing > > answers to our questions. David Gray for originally suggesting to link > > Python statically to gain performance. > > Kevin Kofler > ___ > 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 > Yes. My point still stands. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Minimization Objective report
- Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Wednesday, November 20, 2019 7:10:32 PM > Subject: Re: Minimization Objective report > > Adam Jackson wrote: > > You're right, you spend two months achieving zero towards this goal, > > Well, just a few days ago, I managed to stop a Change that would have almost > doubled Python 3's size wherever both the python3 executable and the > libpython3 library are needed, and to point out an alternative (though Jan > Kratochvil beat me to it by ~64 minutes) that brings the same performance > gain without the size increase (-fno-semantic-interposition). > > I am constantly trying to fight bloat, but it is usually a political rather > than a technical fight. And the typical outcome (see, e.g., MiniDebugInfo) > is where my "defeatist attitude" comes from. > > Kevin Kofler > ___ > 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 > I'm sorry but how exactly did you manage to 'stop' the change? All you did was started shouting about the size increase and then proposed something already mentioned beforehand in the thread. Your feedback was NOT helpful and it basically pushed people away from wanting to participate to the thread. Luckily sorting through the useful info was possible but still frustrating in between your rants. We heard the feedback and did a lot of experimentation and benchmarking with a ton of different options so I really can't fathom how you are taking credit for something that others invested so much time in. /offtopic rant over -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
- Original Message - > From: "Victor Stinner" > To: devel@lists.fedoraproject.org > Sent: Friday, November 15, 2019 10:21:44 AM > Subject: Re: Fedora 32 System-Wide Change proposal: Build Python 3 to > statically link with libpython3.8.a for better > performance > > Hi Jan, > > With the helper of Florian Weimer and Charalampos Stratakis, we also agreed > to test this flag in priority. I understood that it disables the LD_PRELOAD > feature: it's no longer possible to override symbols in libpython with > LD_PRELOAD. Thanks to that, the compiler can avoid PLT indirection for > function calls and can inline more function functions in libpython. I'm > talking about a function call from libpython to libpython: something which > is very common in python. Basically, almost all function calls are calls > from libpython to libpython. > > I'm impressed. Thanks to -fno-semantic-interposition, I get the same speedup > on a dynamically linked Python (libpython) compared to statically linked > Python! > > Yesterday, I tried on a vanilla Python compiled manually: > > ./configure --enable-optimizations --with-lto --enable-shared > CFLAGS="-fno-semantic-interposition" LDFLAGS="-fno-semantic-interposition" > > I saw the same speed up than avoiding --enable-shared. Today I validated this > result using the RPM generated by Charalampos's PR: > https://src.fedoraproject.org/rpms/python38/pull-request/53 > > In short, https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup is > useless: there is no need to modify Python to statically link it to > libpython. We can keep the dynamically library libpython and keep Python > dynamically linked to it. We only need to pass -fno-semantic-interposition > to compiler and linker flags when building Python! > > I'm not sure if we need a Fedora change just for a compiler flag. Again, the > only drawback is that we will no longer be able to override a symbol using > LD_PRELOAD. Honestly, I never did that. I don't see any use case for that. > But I used LD_PRELOAD on the libc multiple times to mock the system clock > for example. > > If someone really needs LD_PRELOAD, it's quite easy to build a custom Python > without -fno-semantic-interposition. > > Victor > ___ > 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 > Thanks Victor for running the benchmarks. The change will be withdrawn and another self-contained one will be created. I think not being able to override symbols on the system python is a better tradeoff than the size/speed and possible incompatibilities. Side note: the list of packages that still link to libpython without embedding the interpreter will be used to mass file bugs in order to unlink them. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Modularity: The Official Complaint Thread
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Thursday, November 14, 2019 9:32:30 PM > Subject: Re: Modularity: The Official Complaint Thread > > On Thu, Nov 14, 2019 at 3:28 PM Miro Hrončok wrote: > > > > On 14. 11. 19 21:15, Stephen Gallagher wrote: > > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question... > > > > The way Python is designed, 3.7 and 3.8 is parallel installable by default. > > > > The only things that conflict are: > > > > - package names, such as python3 or python3-pytest > > - executable names, such as /usr/bin/python3 or /usr/bin/pytest > > > > By having the python3 modules with 3.7 and 3.8 streams, we would kill this > > feature of Python while gaining a very little benefit (such as that > > users/admins > > might select a stream to determine what version /usr/bin/python3 is). > > > > Not to mention that dnf itself depends on Python, so we would need to have > > dnf > > in those modules, or rewrite dnf in Rust or use mcirodnf or have > > /usr/libexec/platform-python for dnf. > > I was actually thinking more along the lines of: leave the actual > python packages as > non-modular but have a module that acts like the old `alternatives` > tool to set up which binaries should own the main executable names. It > would allow us to do the thing I proposed earlier around the major > upgrade rebuilds (letting us set other modules as `buildrequires:` of > `python: [ ]` for stream expansion) without actually having to build > the complete python stack in the modules. That might be a really > convenient strategy, honestly. > ___ > 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 > While that is an interesting approach I really don't see any benefit on doing that (apart from maybe a staging environment to experiment). -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Modularity: The Official Complaint Thread
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Thursday, November 14, 2019 9:15:38 PM > Subject: Re: Modularity: The Official Complaint Thread > > On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr > wrote: > > > > On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote: > > > You're assuming that parallel-install is a thing that everyone needs > > > from every package on their system. > > > > I'm not. However, if you're going to bring up 'the recommended solution for > > doing "parallel-install" with modules', it makes sense to address this. > > > > > Our research and surveys determined that this was not in fact the case > > > for > > > the overwhelming majority of real-world deployments. Most[1] deployments > > > function with a "one app per VM/container" mentality. > > > > This isn't surprising to me, as that's just an extension of what is done > > with > > physical hosts as well, when serving important services. The physical host > > or > > VM is often dedicated to said service, often at the recommendation of the > > software itself, for example FreeIPA recommends this. > > > > > In such cases, parallel-installability is at best unnecessary and (such > > > as > > > with SCLs) actively annoying to them. > > > > Only if actually implemented as SCLs, in my opinion, but that is definitely > > an > > opinion. > > > > I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)". > > > > Modules offers the availability of multiple streams of software like SCLs > > > does, but it sacrifices the ability to install them in parallel for the > > > ability to install them in the standard locations on disk so that other > > > software doesn't need to adapt to alternate locations (the number-one > > > complaint received about SCLs). > > > > So, are modules are meant to replace SCLs? If so, surely the inability to > > install multiple versions invalidates that? > > > > They aren't incompatible technologies. If there is a case where > parallel-installability is valuable, an SCL can still be made. But for > the common case, we (Red Hat) determined that parallel-availability > was more valuable and common. > > > For example, one of the issues I'm trying to resolve at work is providing > > both > > Python 2.7 and Python 3.5 on RHEL 6. > > Python 2 and 3 are effectively separate tools and (given that they are > built with parallel-installability in mind) should absolutely not be > streams of the same module. > > Now, python3:3.7 vs. python3:3.8 might be a more interesting question... That is actually a non-issue, they are parallel installable if you exclude the main python3 binary. > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
pecific case, which is in line with the packaging guidelines, since statically linking a binary against its own library is permitted. This change intends to speed up Python by a significant margin in the context of the current toolchain, with the outlined effects on compatibility and package changes. We can debate on that, the rest seem irrelevant in the context of accepting it or not. > > Vít > > > > > > Thanks, > > Florian > _______ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Building the python executable statically with libpython*.a for better performance
- Original Message - > From: "Neal Gompa" > To: "Fedora Python SIG" > Cc: "David Gray" > Sent: Saturday, October 26, 2019 5:01:52 PM > Subject: Re: Building the python executable statically with libpython*.a for > better performance > > 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 libpython*.a. That sounds like > > a > > worthy thing to do. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1749479 > > > > Since Python 3.8 Python extension modules are no longer linked to > > libpython.so > > and we can do the following: > > > > * build /usr/bin/python3(.8) statically with libpython*.a > > * build and ship libpython3.8.so.1.0 for packages that "embed" Python > > > > The change in the python3 package is trivial: > > > > https://src.fedoraproject.org/rpms/python3/pull-request/133 > > > > However it can have serious impact on Python extension modules that are > > linked > > to libpython3.8.so.1.0 by various "nonstandard" build mechanisms or by > > compiling > > code for Python extension module and code that embeds Python into one file. > > > > We will likely propose a Fedora 32 Change for this, however I'm opening > > this > > topic for discussion before we do so. > > > > Testing the proposed Pull Request with your code is also helpful. Let me > > know > > how can we make that easier (e.g. if you want a Copr or a Fedora 30/31 > > python38 > > package with this change). > > > > WDYT? > > One major concern: We currently rely on the libpython shared object > linkage for non-standard builds to ensure we get everything for moving > to new Python versions. I've personally experienced quirks with trying > to force linking via the shared object when the Python interpreter > itself is not. For example, perl-Inline-Python determines how to build > itself by asking the interpreter. In Fedora, this works correctly > because the interpreter returns the shared object. In other > distributions where I've built the module, it doesn't and uses the > static link object, which makes it difficult to automatically generate > the link dependency to the system Python we are using. > > In Mageia, we actually reverted Python's change to not link libpython > with extension modules so that we still have the dependency link for > binary objects: > https://svnweb.mageia.org/packages/cauldron/python3/current/SOURCES/link-C-modules-with-libpython.patch?view=markup > > Is there no other way to get better performance? Do we want to > potentially give up the easily trackable dependency web for that? Is > it worth breaking non-standard build mechanisms that interrogate the > interpreter for how to link to it? > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Hello. For the record most of the packages build fine with the change, including perl-Inline-Python [0]. Also still waiting for the change to be sent by the wrangler, but you can read the finalized version here: https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup [0] https://copr.fedorainfracloud.org/coprs/g/python/Python3_statically_linked/builds/ -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Building the python executable statically with libpython*.a for better performance
- Original Message - > From: "Neal Gompa" > To: "Fedora Python SIG" > Cc: "David Gray" > Sent: Saturday, October 26, 2019 5:01:52 PM > Subject: Re: Building the python executable statically with libpython*.a for > better performance > > 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 libpython*.a. That sounds like > > a > > worthy thing to do. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1749479 > > > > Since Python 3.8 Python extension modules are no longer linked to > > libpython.so > > and we can do the following: > > > > * build /usr/bin/python3(.8) statically with libpython*.a > > * build and ship libpython3.8.so.1.0 for packages that "embed" Python > > > > The change in the python3 package is trivial: > > > > https://src.fedoraproject.org/rpms/python3/pull-request/133 > > > > However it can have serious impact on Python extension modules that are > > linked > > to libpython3.8.so.1.0 by various "nonstandard" build mechanisms or by > > compiling > > code for Python extension module and code that embeds Python into one file. > > > > We will likely propose a Fedora 32 Change for this, however I'm opening > > this > > topic for discussion before we do so. > > > > Testing the proposed Pull Request with your code is also helpful. Let me > > know > > how can we make that easier (e.g. if you want a Copr or a Fedora 30/31 > > python38 > > package with this change). > > > > WDYT? > > One major concern: We currently rely on the libpython shared object > linkage for non-standard builds to ensure we get everything for moving > to new Python versions. I've personally experienced quirks with trying > to force linking via the shared object when the Python interpreter > itself is not. For example, perl-Inline-Python determines how to build > itself by asking the interpreter. In Fedora, this works correctly > because the interpreter returns the shared object. In other > distributions where I've built the module, it doesn't and uses the > static link object, which makes it difficult to automatically generate > the link dependency to the system Python we are using. > > In Mageia, we actually reverted Python's change to not link libpython > with extension modules so that we still have the dependency link for > binary objects: > https://svnweb.mageia.org/packages/cauldron/python3/current/SOURCES/link-C-modules-with-libpython.patch?view=markup > > Is there no other way to get better performance? Do we want to > potentially give up the easily trackable dependency web for that? Is > it worth breaking non-standard build mechanisms that interrogate the > interpreter for how to link to it? > Hi Neal and thanks for voicing that concern, 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. Currently on rawhide there are 113 packages requiring libpython. Ubuntu and Debian are doing this for years so I would expect that at least the packages that are also included there, would either be working or require slight modifications. The change will be posted soon for F32 on the devel list, so you can check all the details and we can continue this conversation by then. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
- Original Message - > From: "vvs vvs" > To: devel@lists.fedoraproject.org > Sent: Monday, September 9, 2019 4:52:07 PM > Subject: Re: Fedora 31 System-Wide Change proposal (late): No i686 > Repositories > > May be there are more interested people that we know, but they are not > reading that list. There will just be just every man for himself and Fedora > has failed to recognize that. > > This requires time and effort too. Nobody will appear just by a miracle. I > recognize that there is much less people interested in this architecture but > it's much more than zero. > ___ > 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 > Providing some imaginary numbers and anecdotes as facts doesn't really help the "I am right, you are wrong" style of debating that is on going for some time in this thread. No, Fedora hasn't failed to recognize something, it's a community project. If noone is interested enough to step up and help with the effort, the work will never be done, simple as that. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: python2->python3 mass rebuild and auto tools
- Original Message - > From: "Charalampos Stratakis" > To: "Development discussions related to Fedora" > > Sent: Thursday, August 1, 2019 1:03:51 AM > Subject: Re: python2->python3 mass rebuild and auto tools > > > > - Original Message - > > From: "Steve Grubb" > > To: "Development discussions related to Fedora" > > > > Sent: Thursday, August 1, 2019 12:03:01 AM > > Subject: python2->python3 mass rebuild and auto tools > > > > Hello, > > > > I have a package that fails to build because libraries aren't where they > > are > > suposed to be. I looked at the project page > > > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > > > and there is no mention of the effect on autotools. > > > > I have pyexec_PYTHON. What is supposed to be there? And since this is an > > upstream package consumed by all distributions and old versions of Fedora/ > > RHEL, what is the portable thing to do? > > > > There's other things out there like pybind_dir which are probably messed > > up, > > too. > > > > Should they be hardcoded to mean python2 in autotools and swig? > > > > -Steve > > > > ___ > > 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 > > > > Could you point out in which package the problem manifests? > > I've dealt with numerous autotools issues before in respect to Python 3.8, > and most of them boil down to autotools (or the project using autotools) > invoking python-config --libs to embed python, which in order to achieve it > in 3.8 the additional flag --embed needs to be used. > > -- > Regards, > > Charalampos Stratakis > Software Engineer > Python Maintenance Team, Red Hat > And I've just realized I'm talking about a different problem here, not related to this change, heh. Could you still point out the package you are dealing with? -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: python2->python3 mass rebuild and auto tools
- Original Message - > From: "Steve Grubb" > To: "Development discussions related to Fedora" > > Sent: Thursday, August 1, 2019 12:03:01 AM > Subject: python2->python3 mass rebuild and auto tools > > Hello, > > I have a package that fails to build because libraries aren't where they are > suposed to be. I looked at the project page > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > and there is no mention of the effect on autotools. > > I have pyexec_PYTHON. What is supposed to be there? And since this is an > upstream package consumed by all distributions and old versions of Fedora/ > RHEL, what is the portable thing to do? > > There's other things out there like pybind_dir which are probably messed up, > too. > > Should they be hardcoded to mean python2 in autotools and swig? > > -Steve > > ___ > 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 > Could you point out in which package the problem manifests? I've dealt with numerous autotools issues before in respect to Python 3.8, and most of them boil down to autotools (or the project using autotools) invoking python-config --libs to embed python, which in order to achieve it in 3.8 the additional flag --embed needs to be used. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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 31 System-Wide Change proposal: Python means Python3
- Original Message - > From: "Ben Cotton" > To: "Development discussions related to Fedora" > > Sent: Thursday, June 27, 2019 10:09:58 PM > Subject: Re: Fedora 31 System-Wide Change proposal: Python means Python3 > > On Thu, Jun 27, 2019 at 2:52 PM Dan Book wrote: > > > > As an outsider to the Python community, not having any binary or package > > that responds to the expected name "python" would be a disaster. > > > Can you expand on that? As I understand it, most things that are > calling for "python" now are expecting that to be "python2". So when > it becomes "python3", they'll break anyway. So why perpetuate a > pattern that's not future-proof (for some values of "proof")? Depends on what you mean by calling "python". The biggest portion of python code floating around would be compatible with either both python2 and 3, or only with python3, with a few exceptions. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > 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://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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: [HEADS UP] SOURCE_DATE_EPOCH environment variable set in rpmbuild
- Original Message - > From: "Vít Ondruch" > To: "Development discussions related to Fedora" > > Sent: Thursday, June 27, 2019 12:18:13 PM > Subject: [HEADS UP] SOURCE_DATE_EPOCH environment variable set in rpmbuild > > > > I just want to give heads up that today, my PR [1] allowing to set > SOURCE_DATE_EPOCH environment variable during build of RPM was merged into > redhat-rpm-config. This means that some packages might have a bit more > reproducible builds. Awesome! Thanks for that! > > This was triggered by this ticket [2] and subsequent discussion on Ruby-SIG > ML [3]. Please keep in mind that while your packages might benefit from this > if it respects the environment variable, this is *not* part of any broader > reproducible builds effort. > > > > > > Vít > > > > > > > > > [1] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1719647 > > [3] > https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/FFGZUV5HJTZPJ7JR2K7TAORXBR7TJ4KZ/ > > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot
- Original Message - > From: "Igor Gnatenko" > To: "Development discussions related to Fedora" > > Cc: "Sergio Durigan Junior" > Sent: Friday, May 3, 2019 6:41:21 PM > Subject: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot > Hello, > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot has been > implemented just few minutes ago. > Before: > Install 151 Packages > Total download size: 77 M > Installed size: 339 M > After: > Install 139 Packages > Total download size: 54 M > Installed size: 249 M > It should not affect anything (apart from making buildroot composition faster > and smaller size), but let us know if anything breaks :) > -- > -Igor Gnatenko > ___ > 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 That's a nice reduction, as well as a welcome removal of a bootstraping step for python3. Thanks for that! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Fork a 119MB pagure project to updating monitoring?
- Original Message - > From: "Pierre-Yves Chibon" > To: "Development discussions related to Fedora" > > Sent: Wednesday, April 10, 2019 11:04:11 AM > Subject: Re: Fork a 119MB pagure project to updating monitoring? > > On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote: > >Other than having it as a direct option in [1]src.fp.org I think being > >part of a special file in git would be next best. > > In the recent releases pagure grew the possibility to have 3rd party > extensions > with their own URL endpoints and able to extend the current database model to > store extra information. > > I've spent a little time using this feature to gain back support in pagure's > UI > to toggle the monitoring status. > > Here is a small demo of how it looks like: > http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm > > Basically, there would now be a button on the sidebar which would show the > current monitoring status and would allow project admins and pagure wide > admins > to update this setting. > > Feedback most welcome :) > > I'm going to clean up the code a little bit and open a PR on the > pagure-dist-git > project, reviews and suggestions welcome there as well. > > > Hoping this helps, > > Pierre > ___ > 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 > That is awesome, thanks for that! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Registering Python packages with Anitya and the "no-monitoring" option
- Original Message - > From: "Robert-André Mauchin" > To: "Miro Hrončok" > Cc: devel@lists.fedoraproject.org > Sent: Monday, April 8, 2019 1:32:58 AM > Subject: Registering Python packages with Anitya and the "no-monitoring" > option > > Hello, > > I have worked on my script to register packages with Anitya this week-end: > https://gist.github.com/eclipseo/fbc52aeebccb7f560221bd40ec28b6af > > It now handles all backend that Anitya supports. > > I have ran it on Python 2661 packages and this resulted in 637 new packages > being registered. Michal Konecny still needs to do something for the new > hotness to pick them up. > > However I already noticed that a large number of packages have set "no- > monitoring" in Pagure. A lot of that are old packages ported from pkgdb and > it > seems it defaulted to "no-monitoring" back then. As a results many bugs won't > be filled even if the packages is outdated. > > I wish we forbid the use of "no-monitoring" and force maintainers to track > updates through Bugzilla, so updates are always linked to a bug number. So we > would convert all existing packages from "no-monitoring" to "monitoring". > Any input regarding this proposal? Would many of you be against such a > change? > Right now we have tons of packages left unmaintained as a result. > > Best regards, > > Robert-André > > > ___ > 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 > I'm all for enabling monitoring everywhere, as I have myself lost way too many updates of my packages due to it being disabled after the migration from pkgdb. However I'd also like some simple way to opt out as well. Some packages have really aggressive release schedules (looking at you boto3) generating too much noise, and having to file PR's here [0], skimming through all the fedora rpm's to find my package in order to tweak release monitoring is really not the most intuitive approach. [0] https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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
Orphaning python-Lektor
Not interested anymore in this package, feel free to reach me out if you'd like to take it, I'll orphan it this week. It will probably need a re-review to rename it to 'lektor' as it's mainly an application. It's sort of active on github [0]. More info [1]. [0] https://github.com/lektor/lektor [1] https://www.getlektor.com/ -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Problem with cmake's PythonInterp in F29 and F28
- Original Message -
> From: "Artur Iwicki"
> To: devel@lists.fedoraproject.org
> Sent: Sunday, February 24, 2019 3:27:43 PM
> Subject: Problem with cmake's PythonInterp in F29 and F28
>
> I've got a package (colobot) which has a build-time dependency on Python3.
> The program had a new upstream release today, so I updated the spec file and
> fired up the builds.
>
> Everything went smooth on rawhide and F30, whereas the F29 and F28 builds
> failed with a rather amusing error message:
> >BUILDSTDERR: CMake Error at
> >/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
> >BUILDSTDERR: Could NOT find PythonInterp: Found unsuitable version "1.4",
> >but required
> >BUILDSTDERR: is at least "2.7" (found
> >BUILDSTDERR:
> >/builddir/build/BUILD/colobot-colobot-gold-0.1.12-alpha/build/%{__python3})
> >BUILDSTDERR: Call Stack (most recent call first):
> >BUILDSTDERR:
> >/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376
> >(_FPHSA_FAILURE_MESSAGE)
> >BUILDSTDERR: /usr/share/cmake/Modules/FindPythonInterp.cmake:159
> >(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
> >BUILDSTDERR: data/CMakeLists.txt:6 (find_package)
> >-- Configuring incomplete, errors occurred!
>
> So, uh, is this in issue with cmake, python3, the project's CMakeLists, or
> something totally different?
>
> For anyone interested in the koji builds:
> rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215429
> fc30: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215430
> fc29: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215433
> fc28: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215434
> ___
> 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
>
This is an issue with the build dependencies. python3 should be replaced with
python3-devel.
From the SPEC on the build section: %cmake -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=%{__python3} ..
The %{__python3} macro will be defined when python3-devel is present in the
build environment (to /usr/bin/python3).
In your build logs, it evaluates correctly on F30 but it stays like that in F29
and F28, so my guess would be that
something pulls python3-devel in the buildroot of F30, either one of the other
dependencies or something else,
which is not the case for the other releases.
Nevertheless the rawhide build was basically successful by accident. I've tried
a scratch build on F28 with
python3-devel as BuildRequires and it succeeded:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33010465
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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: Self Introduction: Markku Korkeala
- Original Message - > From: "Markku Korkeala" > To: devel@lists.fedoraproject.org > Sent: Saturday, January 5, 2019 6:58:57 PM > Subject: Self Introduction: Markku Korkeala > > Hi all, > > I'm new to the Fedora-project, here is a short introduction. I am a > Clojure/Java developer > residing in Finland and a long time Fedore user, since Fedore Core 5. I > joined the > Fedora project to package Clojure and Java libraries and programs. > > I would like to become a owner of a retired package, > clojure-maven-plugin, > and then package libraries (clojure-spec-alpha, clojure-core-specs-alpha > and clojure-pom-contrib) required to update Clojure to the latest > version. > > Best regards, > Markku Korkeala > ___ > 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 > Hello and welcome Markku! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Self Introduction: Anthony McInerney
- Original Message - > From: "Anthony F McInerney" > To: devel@lists.fedoraproject.org > Sent: Friday, December 14, 2018 6:00:52 PM > Subject: Self Introduction: Anthony McInerney > > Hi All, as per the packaging guidelines i'm just touching base to say hello. > I'm hoping to get cockpit-composer into fedora, and willing to triage > bugs etc as required. > Need a sponsor. > https://bugzilla.redhat.com/show_bug.cgi?id=1659556 > I have previously packaged for debian, and have been using fedora for > quite some time now. (home and work) > the copr is managed directly by the cockpit/welder-web team. > thanks. > ___ > 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 > Hello Anthony and welcome! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Self Introduction: Patrick Diehl
- Original Message - > From: "Patrick Diehl" > To: devel@lists.fedoraproject.org > Sent: Thursday, November 15, 2018 5:49:06 PM > Subject: Self Introduction: Patrick Diehl > > Hi, > > my name is Patrick Diehl a staff member at the Center for Computation > and Technology (CCT) at Louisiana State University. I am a contributor > to the C++ library for parallelism and concurrency (HPX) [0]. > > Since we released 1.2 of HPX, I like to propose a Fedora > package [1] for HPX. > > My pgp keys are attached to this e-mail. > > Best regards, > > Patrick Diehl > > [0] https://github.com/STEllAR-GROUP/hpx > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1649874 > > -- > Patrick Diehl > www.diehlpk.de > > > > ___ > 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 > Hello Patrick and welcome to Fedora! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Moving EPEL7 to python3.6
-4.el7.src.rpm > python3-greenlet-0.4.12-1.el7.src.rpm > python3-gssapi-1.3.0-1.el7.src.rpm > python3-idna-2.7-1.el7.src.rpm > python3-jinja2-2.8-2.el7.src.rpm > python3-jwt-1.6.4-1.el7.src.rpm > python3-kitchen-1.2.5-1.el7.src.rpm > python3-markupsafe-0.23-1.el7.src.rpm > python3-mysql-1.3.12-1.el7.src.rpm > python3-netaddr-0.7.18-2.el7.src.rpm > python3-nose-1.3.7-3.el7.src.rpm > python3-numpy-1.10.4-6.el7.src.rpm > python3-ply-3.9-1.el7.src.rpm > python3-py-1.4.30-2.el7.src.rpm > python3-pyasn1-0.1.9-1.el7.src.rpm > python3-pycparser-2.14-1.el7.src.rpm > python3-pycurl-7.43.0-5.el7.src.rpm > python3-pygments-2.2.0-1.el7.src.rpm > python3-pytest-2.8.5-2.el7.src.rpm > python3-pytest-cov-2.5.1-1.el7.src.rpm > python3-pytz-2017.2-1.el7.src.rpm > python3-pyusb-1.0.2-2.el7.src.rpm > python3-requests-2.12.5-1.el7.src.rpm > python3-scipy-0.18.1-1.el7.src.rpm > python3-setproctitle-1.1.6-2.el7.src.rpm > python3-setuptools-19.6.2-3.el7.src.rpm > python3-simplepam-0.1.5-6.el7.src.rpm > python3-six-1.11.0-1.el7.src.rpm > python3-sqlalchemy-1.1.3-1.el7.src.rpm > python3-suds-0.6-1.el7.src.rpm > python3-tornado-4.4.2-1.el7.src.rpm > python3-urllib3-1.19.1-3.el7.src.rpm > python3-virtualenv-15.1.0-1.el7.src.rpm > python3-websocket-client-0.47.0-1.el7.src.rpm > python3-zope-event-4.2.0-1.el7.src.rpm > python3-zope-interface-4.3.3-1.el7.src.rpm > python34-3.4.9-1.el7.src.rpm > pyxdg-0.25-6.el7.src.rpm > root-6.14.04-1.el7.src.rpm > scapy-2.4.0-2.el7.src.rpm > spglib-1.10.3-1.el7.src.rpm > uwsgi-2.0.17.1-1.el7.src.rpm > xapps-1.0.4-12.el7.src.rpm > xrootd-4.8.4-1.el7.src.rpm > yubikey-piv-manager-1.4.2-5.el7.src.rpm > -- > Stephen J Smoogen. > ___ > 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://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Hello Stephen and thanks for the proactiveness on the matter. I was planning after introducing python36, after a long but non-specific timeframe to make the main python3 interpreter in EPEL to be python36, thus changing the macros and so on. Unfortunately I've been floored with other things and did not really have time to do that, or follow up on the matter. I'd like to point out though, that after the transition the other_python will be python34 so packages that change that to be built for python36 now, will have to change again in the future. I'll try next month to dig a bit more into it and I'll be happy to provide you with whatever info/help you'd require on that. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: test files in a python flat package
- Original Message - > From: "Jun Aruga" > To: "Fedora Python SIG" > Sent: Wednesday, October 10, 2018 3:24:07 PM > Subject: test files in a python flat package > > I noticed that the test files (/usr/lib64/python3.7/test) for python37 > are occupying more than 50% in the package size, when I was cleaning > the files in my local machine. > If we actually do not use the test files, I do not want to include the > files in the python37 package. > Just want to separate the files as python37-test sub package. > Because of just reducing the file size. > > How do you think? I want to hear your opinions. > Here is the bugzilla ticket. > > Separate the test directory as python37-test > https://bugzilla.redhat.com/show_bug.cgi?id=1637959 > > > -- > Jun Aruga jar...@redhat.com > ___ > 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://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > Hello Jun, That is actually a valid concern and testing with multiple python interpreters is not the most disk-space friendly use case. However those packages were intended to be flat, the whole interpreter in one binary rpm. In my opinion it's the only pragmatic choice when you take into account the maintenance burden of so many interpreters. Also if we split the tests to a subpackage I can imagine having requirements for splitting them up more in the future as well. Thus I would say that I wouldn't like to split them up and just keep them as it is. I'd be open of course to other possible solutions/arguments. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Yet another gargantuan mathematical software update
- Original Message - > From: "Jerry James" > To: "Development discussions related to Fedora" > > Sent: Sunday, October 7, 2018 3:17:04 AM > Subject: Yet another gargantuan mathematical software update > > Hi folks, > > It's about time for another "update the world" moment for some of the > mathematical software we have in Fedora. I'm going to try to clear > away a big chunk of my backlogged package work with this update, so it > will be even bigger than usual. Primary goals are to switch from > atlas or the reference blas to openblas, and to drop python 2 > packages. > > I plan to do all of the necessary rebuilds myself. Package > maintainers, if you would rather that I did not rebuild your package > for you, please let me know. Otherwise, I will do all of these builds > in approximately 1 week from today. I plan to build for Rawhide only. > > As usual with this package set, the rebuilds will take a few days, so > expect broken dependencies in the middle. > > 4ti2: revive this package now that latte-integrale upstream has split > it back out > > arb: update to 2.15.0 > > cddlib: update to 0.94j; epoch bump needed to deal with the new dot in > the version number > > ceres-solver: rebuild for tbb > > cocoalib: switch to openblas > > cryptominisat: update to 5.6.5 > > cxsc: switch to openblas > > DSDP: switch to openblas > > eclib: update to 20180815 > > embree: rebuild for tbb > > fawkes: rebuild for tbb > > fflas-ffpack: switch to openblas > > flint: switch to openblas (needs rebuild anyway due to ntl update) > > gazebo: rebuild for tbb > > gfan: rebuild for cddlib > > giac: rebuild for ntl > > iml: switch to openblas > > latte-integrale: update to 1.7.5. Not really integrale anymore since > 4ti2 was unbundled... > > linbox: switch to openblas, enable OpenCL interface > > Macaulay2: switch to openblas (needs rebuild anyway due to ntl update) > > mathicgb: rebuild for tbb, fix incompatibility with recent gtest versions > > ntl: update to 11.3.0. This involves an soname bump. > > OCE: rebuild for tbb > > opencv: rebuild for tbb > > openvdb: rebuild for tbb > > polymake: rebuild for cddlib > > pynac: switch to openblas, switch from python 2 to python 3 > > python-cvxopt: update to 1.2.1, switch to openblas, drop the python 2 > subpackage > > python-fastcache: update to 1.1.0, drop the python 2 subpackage > > python-networkx: update to 2.1, drop the python 2 subpackages, > consolidate back to a single package again since this cannot appear in > EPEL < 8 anyway > > python-theano: switch to openblas, build with libgpuarray for OpenCL > support, drop the python 2 subpackage > > root: rebuild for tbb > > sagemath: switch to openblas, switch (with great fear and trepidation) > to the experimental python 3 build > > Singular: rebuild for cddlib > > suitesparse: rebuild for tbb > > sympol: rebuild for cddlib > > sympy: update to 1.3, drop the python 2 subpackage > > tbb: update to 2019_U1. This has the same soname, but has a > backwards-incompatible ABI change on 32-bit platforms. Therefore, all > consumers must be rebuilt. > > TOPCOM: rebuild for cddlib > > Regards, > -- > Jerry James > http://www.jamezone.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 > Thank you for all that work! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Python3 will be in next major RHEL release, please adjust %if statements accordingly
- Original Message -
> From: "Pavel Raiskup"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, October 4, 2018 1:05:47 PM
> Subject: Re: Python3 will be in next major RHEL release, please adjust %if
> statements accordingly
>
> > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> > I'll say it once again, but why can't we just have
> > %{python2_available} and %{python3_available} macros defined in the
> > base system?
>
> And once again, what about %py3_build_expected? Proposed in
> https://bugzilla.redhat.com/show_bug.cgi?id=1636020
>
> The most obvious argument against that is that it is not 100% bullet
> proof to cover all Fedora Python packages. But I don't think it is
> a problem in particular; there are _many_ (maybe the most of them)
> python packages that could use this.
>
> Pavel
> ___
> 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
>
This boils down again to having the same SPEC for a bunch of different branches
which I personally
dislike, especially for branches that could be ~10 years apart. My main
argument against it, is
that having a clean SPEC file, which could differ slightly between branches, is
a lot cleaner
than having a huge %if spaghetti.
However, again this is more of a personal preference and I can totally
understand that having
the same SPEC eases the maintainers' burden by a big margin, our time and
resources are not
limitless.
Having said that, providing more macros (and maintaining them and take care of
all the edge cases),
is also a burden for those who implement them. I'd like at least FPC to weigh
in for that
and if the benefits provided by those macros, would benefit a big chunk of our
packagers then
I'm all for it. If it would be only though for enabling fast forward merges for
some cases,
instead of cherry-picking I'd be reluctant to do that.
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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: python2-future on fedora 30+
- Original Message - > From: "Antonio Trande" > To: "Development discussions related to Fedora" > > Sent: Friday, September 21, 2018 2:53:57 PM > Subject: python2-future on fedora 30+ > > Hi all. > > Are we ready for excluding python2-future on fedora 30+ ? > > $ dnf repoquery --release rawhide --enablerepo=*-source > --disablerepo=rpmfusion* --whatrequires python2-future > > Last metadata expiration check: 0:00:00 ago on ven 21 set 2018 14:41:49 > CEST. > > buildbot-0:1.3.0-1.fc29.src > buildbot-master-0:1.3.0-1.fc29.noarch > buildbot-worker-0:1.3.0-1.fc29.noarch > certbot-0:0.27.1-1.fc30.src > crda-0:3.18_2018.05.31-5.fc29.src > httpwatcher-0:0.5.1-3.fc29.src > mozilla-requestpolicy-0:1.0-0.22.20171019git633302.fc29.src > preprocess-0:1.2.3-0.6.20170318git6e868b.fc29.src > python-CommonMark-0:0.7.5-3.fc29.src > python-cloudflare-0:2.1.0-10.fc29.src > python-cookiecutter-0:1.6.0-5.fc29.src > python-dns-lexicon-0:2.7.0-2.fc30.src > python-flask-autoindex-0:0.6-3.fc29.src > python-lz4-0:2.1.0-1.fc29.src > python-mdp-0:3.5-12.fc29.src > python-okaara-0:1.0.37-6.fc29.src > python-parsedatetime-0:2.4-9.fc29.src > python-stestr-0:2.1.0-1.fc29.src > python-stomper-0:0.4.1-7.fc29.src > python-twitter-0:3.3-5.fc29.src > python2-CommonMark-0:0.7.5-3.fc29.noarch > python2-ECPy-0:0.8.2-5.fc29.noarch > python2-certbot-0:0.27.1-1.fc30.noarch > python2-cloudflare-0:2.1.0-10.fc29.noarch > python2-csvkit-0:1.0.3-3.fc29.noarch > python2-dns-lexicon-0:2.7.0-2.fc30.noarch > python2-epdb-0:0.15-7.fc29.noarch > python2-httpwatcher-0:0.5.1-3.fc29.noarch > python2-lz4-0:2.1.0-1.fc29.x86_64 > python2-mdp-0:3.5-12.fc29.noarch > python2-molecule-0:2.16-1.fc29.noarch > python2-okaara-0:1.0.37-6.fc29.noarch > python2-parsedatetime-0:2.4-9.fc29.noarch > python2-pefile-0:2017.11.5-4.fc29.noarch > python2-pyglet-0:1.3.1-3.fc29.noarch > python2-pyqtrailer-0:0.6.2-17.fc29.noarch > python2-pysaml2-0:4.5.0-4.fc29.noarch > python2-rdopkg-0:0.47.2-1.fc30.noarch > python2-stestr-0:2.1.0-1.fc29.noarch > python2-stomper-0:0.4.1-7.fc29.noarch > python2-tracer-0:0.7.0-3.fc29.noarch > python2-twitter-0:3.3-5.fc29.noarch > python2-vertica-0:0.7.4-1.fc30.noarch > rho-0:0.0.34-2.fc29.noarch > sagemath-0:8.2-4.fc29.src > sagemath-0:8.2-4.fc29.x86_64 > tracer-0:0.7.0-3.fc29.src > > -- > --- > Antonio Trande > Fedora Project > mailto 'sagitter at fedoraproject dot org' > GPG key: 0x5E212EE1D35568BE > GPG key server: https://keys.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 > The packages that are being removed right now are leaves, meaning that python2-futures wouldn't be on the removal list for now. At some point though all the dependents will have either been removed or requiring python3 only. Only sagemath worries me in this list since AFAIK there is still some way to go, for full python3 support upstream. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Scons python2 on fedora 30+
- Original Message - > From: "Miro Hrončok" > To: "Development discussions related to Fedora" > , "Jerry James" > Sent: Saturday, August 25, 2018 12:01:38 PM > Subject: Re: Scons python2 on fedora 30+ > > On 24.8.2018 22:54, Jerry James wrote: > > On Fri, Aug 24, 2018 at 2:22 PM Antonio Trande > > wrote: > >> Hello! > >> > >> Regarding Python2 package removal, 'python2-SCons' needs special > >> attention, i guess. > >> It's required for building by many packages on current 'rawhide': > > > > [snip] > > > >> sagemath-0:8.2-4.fc29.src > > > > [snip] > > > >> What's the situation of these packages in a middle-term scenario in > >> respect of Python2 removal proposal? > > > > Not good. Sagemath upstream has been working on converting to python > > 3 for about 5 years now (see https://trac.sagemath.org/ticket/15530), > > and they are not done. For now, sagemath must remain a python 2 > > package. Honestly, given how much work upstream still has to do, I do > > not expect the python 3 version of sagemath to be ready any sooner > > than a year from now, and quite possibly not until 2 years from now. > > > > I've been meaning to post about this. What do we, as a distribution, > > want to do? As I see it, we really only have 2 options. > > > > Option 1. Tell Fedora users that sagemath will not be available for a > > few Fedora releases, until upstream completes the conversion to python > > 3. > > > > Option 2. Keep all of the python 2 packages that sagemath needs in > > the distribution until the python 3 version is ready, which possibly > > means that they have to be kept through Fedora 32. > > As per our Fedora 30 change [1], we go witch option 2 now. We can always > revisit this later. > > [1] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok This. And we can always provide some help to upstream to port their code, which I would encourage to do, especially if you are using sagemath in any way. > ___ > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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: Self Introduction: filbranden
- Original Message - > From: "Filipe Brandenburger" > To: "Fedora Devel" > Cc: "Petr Holášek" > Sent: Monday, August 13, 2018 8:10:33 PM > Subject: Self Introduction: filbranden > > Hi everyone! > > I'm a new packager in Fedora project, so I'd like to introduce myself. > My name is Filipe. I currently live in California, though I'm > originally from Brazil. I have been using Fedora and other distros in > that family for close to 20 years now, for fun and profit, starting > with Red Hat Linux 6 (not RHEL.) I remember installing Fedora Core 2 > on my desktop and I think I attempted to upgrade it to FC4 using yum. > Oh good times! > > I've been an active contributor to the systemd project upstream and > I'm joining as a co-maintainer of systemd package in Fedora. Zbyszek > was very kind to sponsor my membership to Fedora and I really thank > him for showing me the ropes. > > I'm also upstream maintainer of numactl and I already proposed to Petr > that I could help maintain the Fedora package. (I have already sent a > PR to Pagure to bump it up to the latest version.) > > At my $dayjob at Google, I work to improve Kubernetes, for the most > part developing the low-level components to run containers, so that's > an area of interest of mine as well. > > I'm really happy to join the Fedora project and am looking forward to > being an active contributor! > > Cheers! > Filipe > ___ > 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/UYZMY2EFT6W5QZIVA2IDSYCEAVVYXSEV/ > Hello Filipe and welcome to Fedora! Glad to have you here! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/MSD34DLZGLRFKCLLTKZ5RVUN2XQ5AVMP/
Re: self-introduction mythcat
- Original Message - > From: "Cătălin George Feștilă" > To: python-devel@lists.fedoraproject.org > Sent: Wednesday, August 8, 2018 7:25:40 PM > Subject: self-introduction mythcat > > Dear team. > My name is Cătălin George Feștilă known as mythcat into Fedora area. > I want to join to this group because I used python : > https://python-catalin.blogspot.com/ > I'm born 1976 - Romania > Thank you. > Best regards. > > > ___ > 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://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/AQK67H4OEVRZMLLCQRU24AXXLBQ6CMHJ/ > Hello Cătălin and welcome! You can read more information for the Python-SIG here [0]. [0] https://fedoraproject.org/wiki/SIGs/Python -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/3TOS4LGWFYDJFDC6FSPUSRA6TZ25ZCU2/
Re: Why are we shipping debug builds of pythons?
- Original Message - > From: "Troy Curtis Jr" > To: "Development discussions related to Fedora" > > Cc: "Fedora Python SIG" > Sent: Sunday, August 5, 2018 3:44:39 AM > Subject: Re: Why are we shipping debug builds of pythons? > > > > On Sat, Aug 4, 2018 at 5:16 PM Miro Hrončok < mhron...@redhat.com > wrote: > > > Hi, > > an interesting discussion came up in the Python Maint team recently, > about not shipping python3-debug and python2-debug. > > On the Chesterton's fence principle [0], I'd would like to know why are > we building and shipping them before we have a discussion about their > removal to save build time and remove packaging cruft. > > Anyone has an idea? Those packages are meant to debug Python, yet all > people I know who do that, build they own Python for that purpose (often > from the master branch). > > The other main use for the Python debug package is debugging Python C > extensions. I recently made very good use of it while using GDB to debug > some extensions I was working on. This is more than just having debug > symbols, which of course is essential, but the debug build means that when > you are stepping through the code, you can more easily follow what the > interpreter is doing. Also, I think that is the package that has some > niceties that extend GDB to work even better with Python code. > > > I tracked down the introduction of the python-debug package in this > commit [1] by David Malcolm (CCed) @ 8 years ago, added in Fedora 14 > shortly before upgrade to 2.7. Yet the commit message lacks rationale. > > [0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence > [1] > https://src.fedoraproject.org/rpms/python/c/f020abd35954981b383884105dad425ba9c6637a > > Thanks, > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > Troy > > > ___ > python-devel mailing list -- python-de...@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://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/AHOMI7GX6IBXSINVDDTBX6GYZF2Y5QLY/ > Hello. I would suppose you'd be referring to the debuginfo package, which is automatically generated by rpm and holds (via some hacks) the files required by gdb for properly debugging python apps. Here we are referring to the python2-debug or python3-debug builds, which are just extra python builds that are compiled with the --with-pydebug flag [0] [0] http://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/J4KJV5NSD6D6EARF22WD76ZTAYD3CCOX/
Re: Intent to orphan Python 2
- Original Message - > From: "R P Herrold" > To: "Development discussions related to Fedora" > > Sent: Monday, July 16, 2018 8:57:11 PM > Subject: Re: Intent to orphan Python 2 > > On Mon, 16 Jul 2018, Miro Hrončok wrote: > > > On 23.3.2018 12:23, Petr Viktorin wrote: > > > tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need > > > to start dropping python2 packages now. > > tl;dr: --- that statement by itself overlooks the obvious. > Not ALL packages become unsupported that first day of that > year > > > > Python 2.7 will reach end of upstream support on 1st of January, 2020, > > > after almost 10 years (!) of volunteer maintenance. > > Not to be too direct about this, but isn't the RHEL 6 primary > maintenance date (through 2020 11 30) a closer maintenance > depot to look at and to compare against ? > I don't see how that relates to Fedora. Could you elaborate on what you mean? > Packages NOT in RHEL have a closer date, perhaps, but RHEL > (next, assumedly 8, but ...) has not dropped yet. A > subscription customer _should_ be migrating toward 7 at this > point, but as this is not a costless thing, such migrations > tend to be ... with a deliberate pace > Agreed but yet again, this doesn't like something that would impact Fedora. > -- Russ herrold > ___ > 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/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/DAHZTVERHGRCASAXAL5UOBXJQE5SDSLR/
Re: [HEADS UP] Removal of GCC from the buildroot
- Original Message - > From: "Tomasz Kłoczko" > To: "Development discussions related to Fedora" > > Sent: Tuesday, July 10, 2018 2:27:40 PM > Subject: Re: [HEADS UP] Removal of GCC from the buildroot > > On Tue, 10 Jul 2018 at 12:52, Till Maas wrote: > [..] > > > PS. And really I don't care that again above will be taken as kind of > > > personal attack (which is not my intention). > > > > The Fedora Code of Conduct is not optional therefore I expect you to > > care about this. If you believe your e-mail might be offensive, it is > > your job to ensure that it is not. > > Sorry to say this without telling openly some past stories straight > about things which only few people knows it is not possible to > understand why at the moment I'm not able to trust what Igor is doing. > One time it may be accident .. > Truth is that not one but at least few time he miscarried few things. > I would be not surprised if I'll be not only person with such > experience. > IMO even if he has some potential I'm guessing that he is still > relatively young and if it is true he may still need proper mentoring Can you really not see what is wrong and hurtful with that statement of yours? > (however I'm not going or want to be his mentor) > I can honestly promise that if he will be somehow cross the line with > things which sometimes I'm trying to take care next time my reaction > will be as same as before. You may say that from this point of view > I'm 100% predictable. > This is not about how Igor is reacting but how you keep coming up with ridiculous excuses to justify your toxic behaviour. > IMO he needs to learn meaning of some old sentence "Errare humanum est > perseverare autem diabolicum" > If he will not learn few thing I don't want to be around next time. > Everyone needs to learn things, especially when dealing with others. Noone though should justify bad actions or wording due to real or hypothetical actions of other people. Please stop using Igor as a scapegoat. > If you or someone else can give me the lesson how to say above without > hurting someone personal fillings or not act as someone offensive I'm > really ready to pay whatever price someone will ask for. > Noone should feel obliged to give someone a lesson in order to learn to behave properly or in a civilized manner on a public discussions. You inability to do that is not anyone's fault but yours. Please work on that first before deciding to place the blame of your action onto other people. > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > 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/OIMH525NCV6UFWZGCUCSDSQ3FKZHBGC5/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/2DC3EDXGLPA6H4LLGNOF364KWYLXHWSV/
Re: [HEADS UP] Removal of GCC from the buildroot
roposition is *not* to add gcc/g++ explicit to BuildReequires and > use instead glibc-devel and libstdc++-devel modifications and ban use > gcc/gcc-c++ in BuildRequires (in most of the cases all current gcc/g++ > BuildRequires could be replaced by glibc-devel and libstdc++-devel). > All because it is not possible to use C compiler without glibc-devel > and C++ compiler without libstdc++-devel. > I love how instead of a compromise you actually propose banning of that buildrequires. You realize that you arguments are never assertive and it just makes people even more opposed to your (poorly worded) propositions? > Changes in redhat-rpm-config to be able easy switch between gcc and > clang (to other compilers) could be done later. > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > 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/DS3WXH2C7Q6JFQ5X5XOXHRUHN2E3EE3L/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/EEPJP4JMTBDFFL3XRMQWEWKTLKPB5YVO/
Re: Self Introduction: Jani Juhani Sinervo
Welcome to Fedora Jani! - Original Message - > From: "Jani Juhani Sinervo" > To: devel@lists.fedoraproject.org > Sent: Saturday, July 7, 2018 8:23:02 PM > Subject: Self Introduction: Jani Juhani Sinervo > > Hi all! > > I'm a second-year university computer science student (well, the second > year technically starts this September, but details :P) I've been using > Fedora on and off for a few months now, and felt like it'd be only fair > that I give back to the community that has made my own computing a > breeze. > > I just submitted my first contribution to this project, which is a > package for the Vis editor, whose review request is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1598982 > > I hope that the co-operation with myself and the project shall be > fuitful! > > Best regards, > > Jani Sinervo (sham1) > ___ > 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/6YBJLSGP34VEUJADLNICZH7Z75OW77IT/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/H37VEETGGWO7DOUFYDLJ2J2LWKTOA5AJ/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
- Original Message - > From: "Matthew Miller" > To: "Development discussions related to Fedora" > > Sent: Saturday, July 7, 2018 11:21:51 AM > Subject: Re: Compiling binaries with PGO (Profile-Guided Optimization) > > On Fri, Jul 06, 2018 at 01:46:17PM -0400, Charalampos Stratakis wrote: > > Python runs its huge upstream test suite to gather that information. > > Combined with the fact that we also run it once for the debug build > > and another for the actual build, the slow arch's will take way too > > long. ARM was something like 7 hours if I recall correctly, hence the > > reason for enabling it only on specific arch's. > > Hmmm. It seems like the slow architectures is where the _benefit_ will > be most interesting, too. Is there a way to run outside the koji build > and cache the results? > Not sure if that is possible for getting official signed builds for those arch's. But it would be certainly interesting testing the rpm's from a scratch build and benchmarking various workloads on the slow arch's. Python 3 builds, depending on the host, can take from 1h30m up to 3h and extending that to more than double would hinder the speed of pushing fixes fast for a core component of the operating system like python, hence the decision for limiting PGO to only specific architectures. If however the benefits would be considered significant, especially on the "snappiness" of the operating system, I'd be inclined to enable it. > -- > Matthew Miller > > Fedora Project Leader > ___ > 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/UZAVQY5CQUP5QBWFY46IZHTTG2CJV5SW/ > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/MGGIRTGVMJAEV43XQKUENO24EWANHFFK/
Re: Self-Introduction: Dave Dykstra
- Original Message - > From: "Dave Dykstra" > To: devel@lists.fedoraproject.org > Sent: Monday, July 2, 2018 6:58:40 PM > Subject: Self-Introduction: Dave Dykstra > > Hello everyone, > > I work at the Fermi National Accelerator Laboratory and have just joined > this mailing list. I expect to become a co-maintainer of the singularity > package for Fedora and EPEL along with Brian Bockelman. I support > singularity for the Open Science Grid (https://opensciencegrid.org) and > the Worldwide LHC Computing Grid (http://wlcg.web.cern.ch) and have many > years of experience supporting Linux tools. For example, about 20 years > ago during a previous job at Bell Labs, for one year I was the primary > upstream maintainer of rsync. > > Dave > ___ > 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/UV35HCMGHOTPKJCQQ2QK4GY2NYETWDOZ/ > Hello Dave and welcome to Fedora! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/CENVT565K3OTUGYE3X5DU3BR2KPUSS6L/
Re: Compiling binaries with PGO (Profile-Guided Optimization)
- Original Message - > From: "Alexander Zaitsev" > To: devel@lists.fedoraproject.org > Sent: Friday, July 6, 2018 7:35:56 PM > Subject: Re: Compiling binaries with PGO (Profile-Guided Optimization) > > > > 06.07.2018 17:26, Neal Gompa пишет: > > On Fri, Jul 6, 2018 at 10:12 AM Aliaksandr Zaitsau > > wrote: > >> Hello. > >> > >> As far as I know binaries in Fedora repositories are compiled without > >> PGO (profile-guided optimization). Also I don't know any LInux-based OS > >> where binaries are precompiled with PGO. With PGO we can improve > >> performance of binaries for typical use-cases without compiling for some > >> specific architecture (so binaries with PGO will be > >> architecture-independent). > >> > >> Question: why PGO isn't used by maintainers for packages? Lack of > >> profile data for compilation with PGO? Isn't interested for > >> mainatainers? Something else? Will you try to use PGO for your packages, > >> if will be available repository with profile data for different > >> applications, where you can pick profile data for your application, > >> recompile package with this information and, probably, increase > >> performance of your application? > >> > > Some packages in Fedora _are_ compiled with PGO. Off the top of my > > head, both Firefox and Python 3 are, but only for the x86 > > architectures. It takes too long for other architectures. > > > > I don't know if there's significant demonstrative benefit across the > > board for PGO, given the additional time it adds to package builds... > > > > > > > Hmm.. Sounds interesting. If some packages are built with PGO, so which > profiling information is used for compilation with PGO? Maintainers > manually collect it or take this information from some source? > ___ > 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/J2GKMR75ZC5YQ3O3UD5PQAWSLUOYJ46M/ > Python runs its huge upstream test suite to gather that information. Combined with the fact that we also run it once for the debug build and another for the actual build, the slow arch's will take way too long. ARM was something like 7 hours if I recall correctly, hence the reason for enabling it only on specific arch's. You can examine the build logs here if you are interested [0]. [0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1099020 -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/5UOM5KBI3VNPJH47URVB5V6ZTG6GE77N/
Re: Your package doesn't build with Python 3.7
- Original Message - > From: "Sérgio Basto" > To: "Fedora devel" > Sent: Friday, June 29, 2018 1:55:52 AM > Subject: Re: Your package doesn't build with Python 3.7 > > On Thu, 2018-06-28 at 20:41 +0200, Miro Hrončok wrote: > > sergiomb opencv > > /builddir/build/BUILD/opencv-3.4.1/modules/python/src2/cv2.cpp:889:34: > error: invalid conversion from 'const char*' to 'char*' [-fpermissive] > char* str = PyString_AsString(obj); > > This problem is not about new gcc flags ? or about python rebuild ? now > that I'm reading if I just add const to the code [1] will fix this > build error ? > original code here [2] > > [1] > const char* str = PyString_AsString(obj); > > > [2] > https://github.com/opencv/opencv/blob/master/modules/python/src2/cv2.cp > p#L919 > > Thanks, > -- > Sérgio M. B. > ___ > 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/SCRTZW2ERRXTBK7M3LTKRYXRQ5DFSGBS/ > Hmm I was under the impression that PyString_AsString does not exist in Python3 and you'll have to use PyUnicode_AsEncodedString. Was it actually compiling with previous versions of Python3? -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/NZOU55TUCY7QIB7WCRQLKLQ7BFL2NIS6/
Re: Multi-arch support in Mock
- Original Message - > From: "Miroslav Suchý" > To: "Development discussions related to Fedora" > > Sent: Wednesday, June 13, 2018 9:07:18 AM > Subject: Multi-arch support in Mock > > Hi, > I just pushed into updates-testing new release of Mock (1.4.11). It has nice > new feature: > > $ sudo dnf install qemu-user-static # weak dependency > $ mock -r fedora-28-ppc64le --forcearch ppc64le shell > > This will give you Fedora shell on different architecture. Emulated by QEMU. > And of course you can build packages for > the different architectures this way. > You can do this for any architecture: aarch64, armhfp, ppc64, ppc64le, s390x. > > People are asking me how much slower it is. Here are some data: > > $ time mock -r fedora-28-x86_64 /tmp/tito/mock-1.4.11-1.fc28.src.rpm > real0m56,341s > user0m46,238s > sys 0m6,027s > > $ time mock -r fedora-28-ppc64le --forcearch=ppc64le > /tmp/tito/mock-1.4.11-1.fc28.src.rpm > real11m9,576s > user10m40,182s > sys 0m29,916s > > > > $ time mock -r fedora-28-x86_64 --shell 'echo Ahoy' > real0m1,199s > user0m0,759s > sys 0m0,253s > > $ time mock -r fedora-28-ppc64le --forcearch=ppc64le --shell 'echo Ahoy' > real0m1,726s > user0m1,228s > sys 0m0,319s > > > > For full release notes see: > https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.11 > > > Miroslav > ___ > 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/CFJOJP7B5RPSSRSY7B5DITO4N2FBNB55/ > This is really awesome! Finally an easy way to test issues on alternative arch's. Thanks for that! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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/4CADSKBIYDL63D6J3RRLXE34VR2FJ2W4/
Re: Are 3.6.x release candidates useful to find bugs?
- Original Message - > From: "Petr Viktorin" <pvikt...@redhat.com> > To: "Fedora Python SIG" <python-devel@lists.fedoraproject.org> > Sent: Monday, May 21, 2018 1:39:41 PM > Subject: Are 3.6.x release candidates useful to find bugs? > > Hello! > > At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told > me that he'd like to collect data about Release Candidates for point > releases (3.x.y). The idea is that if these aren't being tested and > aren't revealing bugs, it would make sense to stop releasing them. > > So, please, if you find any bugs in upcoming Python *3.6.x* release > candidates, let me know (or write to Łukasz directly)! If there are no > such reports, there will be no 3.7.x RCs. > > Also, are these useful for Fedora? Do/should we test 3.x.y RCs? > (3.x.0 pre-releases like the current 3.7.0 beta are a different matter; > those are obviously useful.) > ___ > 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://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/HY4DS7PFF525JGKOE2CUXRUE4D3I22FA/ > Haven't thought that angle before thanks for bringing it up. Indeed we test the RC releases of a new major release (e.g. 3.7) as it helps catching bugs early on, but we've never done that for point releases, as those updates do not usually pose any major issues. Of course there have been bugs for which in most cases we backport the fix from the next point release. So I see two potential outcomes here. Either we change our procedures on updating the point releases and we test the RC ones as well, or we can just say to upstream that from Fedora's POV we don't really bother with the rc point releases. I'm more inclined towards the second option, as the first one is highly dependent on the workload/free cycles at that particular time frame, and combined with the short window between an RC and the actual release, it could strain a lot of resources for not much of a benefit. I'd like some more opinions on the matter of course. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/UEYEG24HCV63JXG7SP4ZTJAWR7WQ4UCT/
Re: pyp2rpm version in fedora
- Original Message - > From: "Martin Bukatovic" <martin.bukato...@gmail.com> > To: python-devel@lists.fedoraproject.org > Sent: Sunday, April 29, 2018 9:18:16 PM > Subject: pyp2rpm version in fedora > > Dear python devel list, > > I see that version of pyp2rpm packaged in Fedora 27 is older than > one from Fedora 26: > > Fedora 28 3.3.0-3.fc28 > Fedora 27 3.2.2-2.fc27 > Fedora 26 3.2.3-1.fc26 > > Is there any reason for that? > > see: https://apps.fedoraproject.org/packages/pyp2rpm/overview/ > > -- > Martin Bukatovic > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org > That could have been an oversight. cc'ing the maintainer. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Self-introduction: Paweł Stołowski
Hello and welcome back Paweł! - Original Message - > From: "Pawel Stolowski" <stolow...@gmail.com> > To: devel@lists.fedoraproject.org > Sent: Wednesday, April 18, 2018 12:24:12 PM > Subject: Self-introduction: Paweł Stołowski > > Hi all! > > My name is Paweł, I live in Poland and for the last couple of years I've been > working on Ubuntu Linux as a software engineer. For the last ~two years I've > been a member of Ubuntu's snapd team and have been mostly programming in Go. > > I'm joining this community with regard to various cross-distro related topics > related to snapd (and snaps). I'm very excited re-visiting Fedora after a > very long break from it (FC was one of my first distros back at the times > when it was marked with single digits and still name "Core")! > > My first contribution to Fedora ecosystem is the introduction of new go-udev > package for Golang - https://bugzilla.redhat.com/show_bug.cgi?id=1567819 > > Cheers, > Paweł > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
