python-devel March 2017

python-devel@lists.fedoraproject.org

15 participants
10 discussions

Please help test IPython 5 and Jupyter Notebook in F26
by Miro Hrončok 17 Mar '17

17 Mar '17

https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e5cf9525f Note that both are testable from Mock, if you are not running Fedora 26 yet. All you need to do is to create a mock config with updates-testing. cp /etc/mock/fedora-26-x86_64.cfg /etc/mock/fedora-26-x86_64-testing.cfg edit /etc/mock/fedora-26-x86_64-testing.cfg (find [updates-testing], change enabled to 1) run: mock -r fedora-26-x86_64-testing --init mock -r fedora-26-x86_64-testing --install \ notebook ipython2 python2-ipykernel mock -r fedora-26-x86_64-testing --shell # ipython3 # ipython2 # jupyter-notebook (test both kernels (2 and 3) in notebook) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Self Introduction : Dhanesh B. Sabane [dhanesh95, UTC +5:30]
by Dhanesh B. Sabane 16 Mar '17

16 Mar '17

Aloha! I'm Dhanesh from Maharashtra, India[1]. I've been contributing to Fedora since May 2016. I started off with CommOps and now I've come to the point where I feel I can be a part of this group. I have just finished my first package for Fedora [2] which is Python software and I've got a few more in my queue. Packaging was one of my aims and now that I've achieved it, my next aim is to help with porting packages from Python2 to Python3. Looking forward to working with all of you! FAS Username and IRC nick: dhanesh95 [1] https://fedoraproject.org/wiki/User:Dhanesh95 [2] https://admin.fedoraproject.org/pkgdb/package/rpms/python-mlpy/ -- Dhanesh B. Sabane [dhanesh95] dhanesh95.gitlab.io

1 0

openSUSE Python packaging and Fedora
by Neal Gompa 14 Mar '17

14 Mar '17

Hello all, I've been recently somewhat involved in openSUSE stuff, and I caught wind of a recent initiative to update their Python packaging. Some background here: As some of you may know, for whatever unknown reason, openSUSE has historically had separate source packages and projects for Python 2 and Python 3 packages[1][2]. While this approach does make packaging more trivial in some regards, it has had the unfortunate consequence of making it so that the Python 2 and Python 3 packages of the same module often were wildly out of sync. Last month, Jan Matejek (SUSE's Python stack maintainer, who is CC'd to this email) unveiled his "singlespec" project[3][4][5] and began transitioning Factory (their equivalent of Rawhide) to it. Factory has been undergoing the transition for the last month rather successfully. Now, in Fedora (and Mageia), "single spec" is not new to us. We've been doing this for years. However, what is new is that openSUSE's packaging structure allows for dynamically generating "flavors" as subpackages to target Python 2, Python 3, PyPy, or whatever other implementation of Python you wish to support. For people familiar with openSUSE's Ruby packaging, this is not new, as it works the same way there. I've taken a look at how the new openSUSE Python packaging works, and it appears to have shades of how Jason Tibbs' prototype Python packaging works[6]. I've not dug too deeply into Jason's work, but they do appear conceptually similar. A deeper examination of the openSUSE packaging macros[7] reveals that it's designed to be mostly a superset of our macros in Fedora and Mageia. All the macros we currently use are defined in their macros, except for one: %python_provide. For the openSUSE macros, the "flavors" capability supersede the usage of %python_provide. My main critique of the openSUSE packaging is that it enforces the usage of alternatives to select the "unversioned" binary. In my view, openSUSE uses alternatives too much across Python, Ruby, and other languages where they have multiple stacks supported. I'd much rather enforce a particular version of the binaries being unversioned (preferably the Python 3 version, unless there's some compelling reason otherwise) and have that always be used. Another issue is that it depends on Python packages being reformatted to match the new convention. Unlike openSUSE, we have not been very good about pushing to restructure all of our Python packages to match our new preferred convention. That being said, we also have the advantage of having a Python dependency generator (though we are only using it for generating Provides at the moment, Mageia uses an earlier version of it to generate Provides and Requires, and openSUSE doesn't have this at all). If we were to incorporate their work, it could be modified to leverage our dependency generator so that this is less of a problem. We could fall back to the structured Python module package names when we're attempting to use modules that don't have the Provides (which are basically modules not built using setuptools or distutils). However, I think that their work is complementary, and at least we could incorporate their macros into our standard set of Python macros. I would like to see us work with the openSUSE guys to see if we can come together on a unified standard of macros. I believe there's certainly a desire on both sides (especially with the OpenStack packaging teams, who'd like to not have to duplicate each other's work for their respective distributions). What do you guys think? Best regards, Neal [1]: https://build.opensuse.org/project/show/devel:languages:python [2]: https://build.opensuse.org/project/show/devel:languages:python3 [3]: https://lists.opensuse.org/opensuse-packaging/2017-02/msg00105.html [4]: https://lists.opensuse.org/opensuse-packaging/2017-02/msg00107.html [5]: https://build.opensuse.org/project/show/devel:languages:python:singlespec [6]: https://pagure.io/python-macros [7]: https://github.com/openSUSE/python-rpm-macros -- 真実はいつも一つ！/ Always, there's only one truth!

3 3

Re: try to build the python module: PyXPCOM with errors
by Charalampos Stratakis 10 Mar '17

10 Mar '17

I suspect this is due to the configure script from the upstream sources expecting the location of the header.py to be /usr/lib64/xulrunner-devel-44.0/sdk/bin/header.py while the Fedora rpm of xulrunner installs it at a different location, more specifically at /usr/lib64/xulrunner/header.py [0] You could try to modify the respective locations at the configure.in to make it consistent with the Fedora packaging. You could also try to contact the gecko-maint team regarding your issue, they might be able to provide more info [1] [0] http://pkgs.fedoraproject.org/cgit/rpms/xulrunner.git/tree/xulrunner.spec#n… [1] https://admin.fedoraproject.org/pkgdb/packager/gecko-maint/ Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ----- Original Message ----- From: "Cătălin George Feștilă" <catalinfest(a)gmail.com> To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org>, python-devel(a)lists.fedoraproject.org Sent: Friday, March 10, 2017 4:59:25 PM Subject: Re: try to build the python module: PyXPCOM with errors I try to build the pyxpcom nope [root@localhost mythcat]# dnf install xulrunner-devel Last metadata expiration check: 2:50:44 ago on Fri Mar 10 15:05:41 2017. Package xulrunner-devel-44.0-9.fc25.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete! maybe is something else ! I used this page to build : https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Inst… The error I got come from the last part: make See error result [root@localhost build]# ls config config.log dist mozilla-config.h config.cache config.status Makefile xpcom [root@localhost build]# ./config.status creating config/ autoconf.mk creating Makefile creating xpcom/Makefile creating xpcom/src/Makefile creating xpcom/src/loader/Makefile creating xpcom/src/module/Makefile creating xpcom/components/Makefile creating xpcom/test/Makefile creating xpcom/test/test_component/Makefile [root@localhost build]# make make export make[1]: Entering directory '/home/mythcat/pyxpcom/build' make[2]: Entering directory '/home/mythcat/pyxpcom/build/config' if test ! -d system_wrappers; then mkdir system_wrappers; fi /usr/bin/perl ../../src/config/ preprocessor.pl -DOSTYPE=\"Linux4.9.13-200.fc25\" -DOSARCH=Linux -DHAVE_64BIT_OS=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_SIGINFO_T=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UNAME_DOMAINNAME_FIELD=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_ATTRIBUTE=1 -DHAVE_DIRENT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_SYS_BITYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GNU_LIBC_VERSION_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_SYS_QUOTA_H=1 -DHAVE_MMINTRIN_H=1 -DNEW_H=\<new\> -DHAVE_SYS_CDEFS_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_DLADDR=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_STAT64=1 -DHAVE_LSTAT64=1 -DHAVE_TRUNCATE64=1 -DHAVE_STATVFS64=1 -DHAVE_SETBUF=1 -DHAVE_ISATTY=1 -DHAVE_FLOCKFILE=1 -DHAVE_GETPAGESIZE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STRTOK_R=1 -DHAVE_WCRTOMB=1 -DHAVE_MBRTOWC=1 -DHAVE_RES_NINIT=1 -DHAVE_GNU_GET_LIBC_VERSION=1 -DHAVE_ICONV=1 -DVA_COPY=va_copy -DHAVE_VA_COPY=1 -DHAVE_VA_LIST_AS_ARRAY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_TYPENAME=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DHAVE_CPP_CHAR16_T=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 \ ../../src/config/system-headers | /usr/bin/perl ../../src/config/ make-system-wrappers.pl system_wrappers /usr/bin/python ../../src/config/nsinstall.py -R system_wrappers ../dist make[2]: Leaving directory '/home/mythcat/pyxpcom/build/config' make[2]: Entering directory '/home/mythcat/pyxpcom/build/xpcom' make[3]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/src' make[4]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/src/module' make[4]: Nothing to be done for 'export'. make[4]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/src/module' make[4]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/src/loader' make[4]: Nothing to be done for 'export'. make[4]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/src/loader' /usr/bin/python ../../../src/config/nsinstall.py -R -m 644 ../../../src/xpcom/src/PyXPCOM.h ../../dist/include make[3]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/src' make[3]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/components' make[3]: Nothing to be done for 'export'. make[3]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/components' make[3]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/test' make[4]: Entering directory '/home/mythcat/pyxpcom/build/xpcom/test/test_component' py_test_component.idl /usr/bin/python ../../../../src/config/pythonpath.py \ -I/usr/lib64/xulrunner-devel-44.0/sdk/bin/ply \ /usr/lib64/xulrunner-devel-44.0/sdk/bin/header.py --cachedir=/home/mythcat/pyxpcom/build/xpcom/test/test_component/cache -I../../../../src/xpcom/test/test_component -I../../../dist/idl -I/usr/lib64/xulrunner-devel-44.0/idl ../../../../src/xpcom/test/test_component/py_test_component.idl -d .deps/py_test_component.h.pp -o _xpidlgen/py_test_component.h Traceback (most recent call last): File "../../../../src/config/pythonpath.py", line 40, in <module> execfile(script, {'__name__': '__main__', '__file__': script}) IOError: [Errno 2] No such file or directory: '/usr/lib64/xulrunner-devel-44.0/sdk/bin/header.py' ../../../../src/config/ rules.mk:1668 : recipe for target '_xpidlgen/py_test_component.h' failed make[4]: *** [_xpidlgen/py_test_component.h] Error 1 make[4]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/test/test_component' ../../../src/config/ rules.mk:796 : recipe for target 'export' failed make[3]: *** [export] Error 2 make[3]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom/test' ../../src/config/ rules.mk:796 : recipe for target 'export' failed make[2]: *** [export] Error 2 make[2]: Leaving directory '/home/mythcat/pyxpcom/build/xpcom' ../src/config/ rules.mk:796 : recipe for target 'export' failed make[1]: *** [export] Error 2 make[1]: Leaving directory '/home/mythcat/pyxpcom/build' ../src/config/ rules.mk:727 : recipe for target 'default' failed make: *** [default] Error 2 [root@localhost build]# ls _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

1 0

Python 3.6.1 release candidate in Fedora Rawhide
by Iryna Shcherbina 08 Mar '17

08 Mar '17

Hi all, Python 3.6.1rc1 was released on the 4th of Match, 2017. This is the first release produced using the new GitHub-based development workflow. Ned Deily, the release manager of Python 3.6, encourages [0] the community to try it out and help detect potential problems. Therefore we are planning to rebase Python in Fedora Rawhide to 3.6.1rc1. Python 3.6.1 release is planned for 2017-03-20, which gives us around two weeks to test and make sure that the upstream's new Github workflow works with Fedora. [0] https://mail.python.org/pipermail/python-dev/2017-March/147564.html Regards, Iryna Shcherbina

1 0

Self introduction, GSoC 2017
by Vasantha Ganesh K 07 Mar '17

07 Mar '17

Hello all, I'm new to this mailing list. My name is Vasantha Ganesh Kanniappan. I am a free software enthusiast. I am doing my Bachelors in Computer Science Engineering from Amrita School of Engineering, Coimbatore, India. I've been using Fedora since Fedora 22 but I've been using Linux distros for around four years now. This is my second attempt for GSoC. Recently I worked on creating an AI-Challenge called Bitjitsu. Other than that I've been working on languages and interpreters. I know a couple of languages and Python is one of them. I have a FAS account. My blog is here (https://vasanthaganeshk.wordpress.com) and all my repos on GitHub are here(https://github.com/vasanthaganeshk). I am looking forward to contributing to Fedora after using it for so long. I think GSoC might be the start. Regards, Vasantha Ganesh K.

1 0

Missing executables in Python 3 subpackages
by Iryna Shcherbina 06 Mar '17

06 Mar '17

Hi all, According to the Fedora Packaging guidelines for Python [0], if a Python packagethat supports Python 3installs executables into //usr/bin/, then either both Python versions of the executables should be packaged, or only the Python 3 version, depending on the functionality they provide. However, after going through all Python 3-compatiblepackages for Fedora, we have identified up to ~30 packages which provide both python2- and python3- subpackages with executables available only in the Python 2 version. For more information about obtaining the list refer to the GitHub issue [1]. The list of the affected packages is available here [3]. Before doing mass bug filing, I would like to post the list of packages here, to get feedback or ideas on how this can be fixed in a better way and encourage packagers to do the changes. If you are in Cc, then you are owing at least one of the affected packages. The guide for porting Python-based RPMs is available here [2] and you may refer to it for more instructions. [0] https://fedoraproject.org/wiki/Packaging:Python#Avoiding_collisions_between… [1] https://github.com/fedora-python/portingdb/issues/132 [2] http://python-rpm-porting.readthedocs.io/ [3] PyXB ahkab gdal lcgdm netcdf4-python pystache python-acme python-aexpect python-bugzilla python-docutils python-doit python-fiat python-gearbox python-igor python-igraph python-jsonschema python-ly python-ndg_httpsclient python-ngram python-oslo-policy python-oslo-privsep python-oslo-rootwrap python-pbr python-py2neo python-pygments python-rosdep python-rosinstall python-whisper Regards, Iryna Shcherbina

4 3

[GSOC 2017] Integration between package managers: dnf pip plugin
by govinda Malavipathirana 02 Mar '17

02 Mar '17

Hi All' I'm Govinda Malavipathirana, 3rd year undergraduate student form Faculty of information technology, University of Moratuwa in Sri Lanka. I would love to contribute to the "Integration between package managers: dnf pip plugini" project. I'm a linux lover and I have some experience with python 3 and git. This is my first time experience with the summer of code. So could you give me a good explanation about the problem and instructions about what should I do first? Sincerely, Govinda

2 1

Self introduction/GSoC '17
by vinayakagarwal6996＠gmail.com 02 Mar '17

02 Mar '17

Hello everyone! My name is Vinayak Agarwal. I am a Computer Science student currently pursuing Bachelors. I would like to be participate in this group. I have experience in python. Last year I did a python development internship also. I've used various distributions of Linux over the years. I have experience in developing web, mobile, desktop, writing scripts, I recently started learning kernel development with the help of eudyptula-challenge. Last year, I made a few contributions to Gnome and Firefox. I also know C, C++, Java, R and C#. I would some assistance in getting started in contributing to Fedora. I was looking at the project idea 'Integration between package managers: dnf pip plugin' and was quite interested in the same. I wrote a basic script to emulate the functionality. Could someone please guide me on how to go ahead? Thanks Vinayak Agarwal

2 1

Self-introduction
by Artem Goncharov 01 Mar '17

01 Mar '17

Hello everyone, My name is Artem and I would like to join the python-devel group. I am a Software/Solution architect with experience in Telecom and databases. Due to the work I never had a change to participate actively in OS development activities, but since FC4 I am with Fedora and always do try to test Betas on all of my workstations. So in this or other way I am a long running contributor to Fedora community. Now the time came, when I would participate more actively to get a different experience. Python is just another language on my skills list. But since I have started with it relatively recently I would like to deepen my knowledge while doing something useful for the community. I have started supporting Python3 port activities (reviews are still pending ;-), but that is definitely not the only thing I will be able to bring. I would be glad if someone will be able to review my specs and point on problems to start bringing use sooner. With the hope of a close and useful partnership and the best regards, Artem

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel March 2017