pybuild (Re: image-file-in-usr-lib)
Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Generally: pybuild seem to install all files into /usr/lib/? As far as I understand the FHS [1], architecture independent files should go to /usr/share. But, almost all python files (except maybe compiled .so extensions) are architecture independent? * .py sources * .pyc bytecode * .egg-info * helper files in png, xml, txt, ... What is the rationale between having all this in /usr/lib? And what should I do with lintian-warnings like the one above? Just silence them? I am asking a bit rigide here since I wanted to write a small newcomers tutorial to package astropy affiliated packages [2]. These packages are quite standard and therefore a good start for newcomers -- but then the final package should be lintian-clean with not too much efforts. The package I am using as example is wcsaxes [3], and it ends up in quite a couple of /usr/lib/.png lintian warnings. I don't want to explain to a newcomer just ignore these, or make them silent. The Debian Policy [4] states (9.1.1): | 1. The FHS requirement that architecture-independent application- | specific static files be located in /usr/share is relaxed to a | suggestion. In particular, a subdirectory of /usr/lib may be used by a | package (or a collection of packages) to hold a mixture of | architecture-independent and architecture-dependent files. However, | when a directory is entirely composed of architecture-independent | files, it should be located in /usr/share. which is a bit contradicting to the current practice: If it is just a suggestion, then maybe the lintian warning has not right severity warning and should be lowered? And are pure python packages (Architecure: all) not covered by the last sentence and should *not* be in /usr/lib/ by policy? What is the best way here, also to explain this in a tutorial to an absolute newcomer? Best regards Ole [1] http://www.pathname.com/fhs/ [2] http://www.astropy.org/affiliated/index.html [3] https://pypi.python.org/pypi/wcsaxes/0.3 [4] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv738ujq.fsf...@debian.org
Re: pybuild (Re: image-file-in-usr-lib)
Ole Streicher oleb...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Short answer: Because the upstream source does not distinguish which files should be installed where. The help that would be needed is for the upstream source (i.e. the Distutils metadata) to distinguish between executable program files versus non-executable files. Generally: pybuild seem to install all files into /usr/lib/? Yes, because that's what will allow the program to work. We're fighting against an essentially incompatible installation philosophy (“install everything in one dump”) which needs to be untangled in order to meet Debian policy. That can't be done reliably by an automated tool, unless there is some help from metadata set in the upstream source. What is the best way here, also to explain this in a tutorial to an absolute newcomer? I don't have a good answer. The incompatible approaches to installing files, by the disparate packaging systems (Python Distutils versus operating system package managers) needs to be reconciled. -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oalra78b@benfinney.id.au
Re: pybuild (Re: image-file-in-usr-lib)
Le Mon, May 11, 2015 at 09:03:53AM +0200, Ole Streicher a écrit : The Debian Policy [4] states (9.1.1): | 1. The FHS requirement that architecture-independent application- | specific static files be located in /usr/share is relaxed to a | suggestion. In particular, a subdirectory of /usr/lib may be used by a | package (or a collection of packages) to hold a mixture of | architecture-independent and architecture-dependent files. However, | when a directory is entirely composed of architecture-independent | files, it should be located in /usr/share. which is a bit contradicting to the current practice: If it is just a suggestion, then maybe the lintian warning has not right severity warning and should be lowered? And are pure python packages (Architecure: all) not covered by the last sentence and should *not* be in /usr/lib/ by policy? Hi Ole, indeed, this is a recent change in the Policy (see bugs.debian.org/741304). Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015051108.ge1...@falafel.plessy.net
Re: pybuild (Re: image-file-in-usr-lib)
On 05/11/2015 09:03 AM, Ole Streicher wrote: Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Generally: pybuild seem to install all files into /usr/lib/? As far as I understand the FHS [1], architecture independent files should go to /usr/share. But, almost all python files (except maybe compiled .so extensions) are architecture independent? * .py sources * .pyc bytecode * .egg-info The FHS never talks about putting *code* into /usr/share. So pybuild is right from my point of view to put it in /usr/lib. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55507195.9010...@debian.org
Re: pybuild (Re: image-file-in-usr-lib)
Matthias Klose d...@debian.org writes: The FHS never talks about putting *code* into /usr/share. So pybuild is right from my point of view to put it in /usr/lib. I think the Debian Policy is quite clear here: | [...] However, when a directory is entirely composed of | architecture-independent files, it should be located in /usr/share. The policy talks about when to put *files* into /usr/share. code files are also files, so they should (from the policy point of view) make no exception. And, in fact there is no difference between emacs .el(c) files, perl .pl files, and python .py(c) files, right? Do you think perl is wrong putting their files to /usr/share? Even if the FHS speaks about data files, they (in my opinion) suggest that this includes code: | It is recommended that application-specific, architecture-independent | directories be placed here. Such directories include groff, perl, | ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may, | however, be placed in /usr/lib for backwards compatibility, at the | distributor's discretion. (the last sentence is clarified by the Debian Policy). I don't want to argue that python should move to /usr/share; however it would be nice (especially for beginners) if policy, lintian, and reality would match here. And I am just trying to find out whom to ask for a change. So, do you think it is just Lintian? Shall I put the recommendation make lintian silent here in my tutorial? Best regards Ole -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbfza17r@news.ole.ath.cx
Re: pybuild (Re: image-file-in-usr-lib)
Charles Plessy ple...@debian.org writes: indeed, this is a recent change in the Policy (see bugs.debian.org/741304). Putting pure python packages (Architecture: all) into /usr/lib is IMO still not coved by the Debian Policy. Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? I'll do that. Cheers Ole -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3qna0yt@news.ole.ath.cx
Re: Filesystem layout choices in Distutils
On 05/11/2015 04:27 AM, Ben Finney wrote: Matthias Klose d...@debian.org writes: there are some discussions on the distutils SIG where to move certain types of files. Can you please show a URL to a specific discussion you think would benefit from a Debian contribution? https://mail.python.org/pipermail/distutils-sig/2015-April/026114.html https://mail.python.org/pipermail/distutils-sig/2015-April/026136.html https://mail.python.org/pipermail/distutils-sig/2015-April/026244.html -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55507257.4060...@debian.org
Re: Membership in PAPT alioth group
On 2015-05-09 02:44, Ben Finney wrote: Balasankar C balasank...@autistici.org writes: I am packaging GNUKhata (http://gnukhata.org), a free accounting software which can be used as an alternative to Tally. Did you check the Work Needing and Prospective Packages list URL:https://bugs.debian.org/wnpp? According to URL:https://bugs.debian.org/751674 ‘gnukhata’ is already being packaged by someone else. Please respond on that bug report and co-ordinate your work with theirs. Yeah. Actually, GNUKhata is split to two - gnukhata and gnukhata-core-engine. The other guy (Praveen) himself asked me to help him with GNUKhata packaging and hence I took ownership of gnukhata-core-engine ITP bug. So, right now, I am packaging gnukhata-core-engine and I would like to do it as a part of PAPT. Hope that is fine. -- Regards Balasankar C http://balasankarc.in -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dcf15cbb7413e282ce48ba6bace6e...@autistici.org
Bug#785015: ITP: wcsaxes -- Framework for plotting astronomical and geospatial data
Package: wnpp Owner: Ole Streicher oleb...@debian.org Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: WCSAxes Version : 0.3 Upstream Author : Thomas Robitaille thomas.robitai...@gmail.com * URL : https://github.com/astrofrog/wcsaxes * License : BSD-3-Clause Programming Lang: Python Description : Framework for plotting astronomical and geospatial data WCSAxes is a framework for making plots of Astronomical data in Matplotlib. It is affiliated with the Astropy project and is intended for inclusion in the Astropy package once stable. I am packaging this mainly as an example for a small Debian packaging tutorial/workshop for astropy affiliated packages [1]. It will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth [2]. Best regards Ole [1] http://www.astropy.org/affiliated/index.html [2] https://anonscm.debian.org/cgit/debian-astro/packages/wcsaxes.git -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5550c934.40...@debian.org
[DPMT] I would like to join the team
Hi, I would like to join the Debian Python Modules Team. I already have an account on alioth (jpuydt-guest) and I already maintain a few packages under the debian-science team umbrella. I have made a package for mistune (a new dep in ipython 3) (bug #779472), and contributed the necessary patches to update tornado to latest upstream (bug #779035). Thanks, Snark on #debian-python and #debian-science -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5550da92.60...@laposte.net
Re: Filesystem layout choices in Distutils
Matthias Klose d...@debian.org writes: On 05/11/2015 04:27 AM, Ben Finney wrote: Can you please show a URL to a specific discussion you think would benefit from a Debian contribution? https://mail.python.org/pipermail/distutils-sig/2015-April/026114.html https://mail.python.org/pipermail/distutils-sig/2015-April/026136.html https://mail.python.org/pipermail/distutils-sig/2015-April/026244.html Thanks, I will find time to participate. -- \“None can love freedom heartily, but good men; the rest love | `\ not freedom, but license.” —John Milton | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85k2wf9cqt@benfinney.id.au
Bug#785048: ITP: python-pyramid-chameleon -- Chameleon templating addon for the Pyramid web application framework
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt ans...@debian.org * Package name: python-pyramid-chameleon Version : 0.3 Upstream Author : Pylons Project and Contributors, http://www.pylonsproject.org/ * URL : http://docs.pylonsproject.org/projects/pyramid-chameleon/en/latest/ * License : BSD-4-clause, with non-free docs (will be removed) Programming Lang: Python Description : Chameleon templating addon for the Pyramid web application framework Pyramid is a small, fast, down-to-earth, open source Python web development framework. It makes real-world web application development and deployment more fun, more predictable, and more productive. . pyramid_chameleon provides bindings for the Chameleon templating system, This addon was previously part of python-pyramid, but split off upstream. It's used by PET (https://pet.alioth.debian.org). -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511185343.2207.66408.report...@deep-thought.43-1.org
Re: pybuild (Re: image-file-in-usr-lib)
On 11/05/15 08:03, Ole Streicher wrote: What is the rationale between having all this in /usr/lib? Conversely, it might be informative to consider the rationale for /usr/lib and /usr/share being separate: This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS. ... but does anyone actually do this? It's not as if dpkg really supports it. If I was trying to provide NFS-mounted root filesystems or /usr for multiple architectures, my process would go more like this: * stop doing that, it's 2015; * failing that, have a chroot per architecture; * if necessary, deduplicate with btrfs reflinks; * if not on btrfs and disk space is short, deduplicate with hardlinks S -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555128c2.5090...@debian.org
pybuild --pytest: empty directory?
Hi, I am trying to automatically run pytest from pybuild (by specifying dh_auto_test -- --test-pytest in override_dh_auto_test). However, the tests do not run. When I look into the log, I see: I: pybuild base:170: cd builddir/.pybuild/pythonX.Y_2.7/build; python2. = test session starts == platform linux2 -- Python 2.7.9 -- py-1.4.25 -- pytest-2.6.3 collected 0 items === in 0.00 seconds === (repeated similarly for python3). Looking into these directories, they are empty (the build tree is in builddirbuild/lib.linux-x86_64-2.7/wcsaxes and they are created by pybuild and setup.py: dh_auto_build -O--buildsystem=pybuild I: pybuild base:170: /usr/bin/python setup.py build running build running build_py creating build creating build/lib.linux-x86_64-2.7 creating build/lib.linux-x86_64-2.7/wcsaxes [...] What am I doing wrong here? Best regards Ole -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw1aamfz@news.ole.ath.cx
