Re: Generic Python packages which don’t work on all architectures
On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote:
> I am still wondering why we don't have just empty some pseudo-
packages that are available only on specific architectures
> (or groups of them, like linux, or little endian, or 64 bit or so).
To solve which problem?
Packages being installable don't mean that they can do anything useful
as they might, for example, require special hardware. We don't have a
way to express "requires device ${X}" on a package level.
Ansgar
Re: Python module packages that don't bytecompile on installation?
Paul Wise writes: > On Sat, Nov 2, 2019 at 6:04 PM Matthias Klose wrote: >> I'd say, there are currently more pressing issues than that, like the Python2 >> removal, or the introduction of Python 3.8. 3.8 also offers a central >> directory >> for bc files, so that's maybe another thing to look at, but not a priority >> now >> from my point of view. > > Agreed re Python 2 etc. Eventually switching to using a central > directory in /var would be nice, right now the .pyc files are dumped > cruftily into /usr subdirs. But /var is for variable state data, i.e. data that is modified during regular system operation. This isn't the case for *.pyc which follow the same rules as the *.py included directly in the packages. So these files should stay in /usr. (I even think /var/lib/dpkg/info should really be in /usr for similar reasons.) See also http://0pointer.net/blog/projects/stateless.html for some other reasons why not using /var might be an advantage. Ansgar
Re: dropping python2 [was Re: scientific python stack transitions]
Thomas Goirand writes: > On 7/7/19 5:31 PM, Matthias Klose wrote: >> you can start dropping it now, however please don't drop anything yet with >> reverse dependencies. So leaf packages first. > > I'm sorry, but I think I need to contest this. Doing things in order, > first leaf, then go all the way back, will take too long, and this is > IMO unnecessary effort. Older binary packages will anyway stay in the > archive as long as they are needed, and no FTP hint is added (please > correct me if I'm wrong here... but that's what I saw in the past). Packages usually don't migrate to testing if they cause packages to be uninstallable which will happen if you start breaking reverse dependencies. Will that be the case here? > You've done some pretty destructive transitions yourself for other > stuff, so why should we bother on this simple case? Removing an entire language isn't a simple case, even less so when doesn't mean we just remove all packages written in said language (as the source packages all build for a different language as well). Ansgar
Re: overriding default compile flags when building python extensions
On Fri, 2019-05-03 at 19:49 +0800, Drew Parsons wrote: > The first -g is the problem (in "-DNDEBUG -g -fwrapv -O2 -Wall"). The > advice from the internet (stackoverflow) is exceedingly poor on this > question, in most cases addressing how to add flags, not how to change > the existing default flags. Alternatives like >OPT="" python3 ./setup.py > simply do not work. Not sure about setup.py, but `-g0` (after `-g`) should also disable debug information: +--- | Level 0 produces no debug information at all. Thus, -g0 negates -g. +--- Ansgar
Re: [py3porters-devel] Python 2 in the default installation -- progress made!
Daniel Kahn Gillmor writes: > On Thu 2016-12-29 23:41:39 -0500, Stuart Prescott wrote: >> one of the objectives for stretch was to reduce the number of Python 2 >> packages that are installed in common scenarios, instead having the >> Python 3 stack take over. The "standard task" within tasksel is a >> reasonable place to look.¹ > [...] >> python-gpg >> python3-gpg > > fwiw, python-gpg and python3-gpg should not be Priority: standard, and > they are indicated as such in the source packages. > >https://packages.qa.debian.org/g/gpgme1.0.html > > indicates that they're marked that way due to override files, but i > don't think there'd be any objection from myself or any of the other > pkg-gnupg-maint team (cc'ed here) if those overrides were removed. There was an open bug about changing the overrides (#849903) and I just set all packages built from gpgme1.0 to "Priority: optional". I don't think there is any reason for the lib*-dev packages to be at Priority: extra? Ansgar
Re: pybuild and proxies -- could we make prohibition optional?
On 07/21/2015 10:21 PM, Dimitri John Ledkov wrote: In practice however we do allow accessing debian ftp archive and localhost services, thus: no_proxy=localhost,*.debian.org would probably be better imho for the balance of don't allow general network access, yet allow sensible networking test-suites to run. I think no_proxy=localhost would be okay, but *.debian.org should not be allowed. Packages don't have to be built for Debian after all. (And yes, I know there is at least one special case that needs to download data from *.debian.org, but that doesn't imply *.d.o should be allowed by default.) Ansgar -- 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/55af7779.3050...@debian.org
Re: Can't create directory '/svn/python-modules/db/transactions/32752-1.txn': Permission denied
Hi, On 05/21/2015 11:59 AM, Mathieu Malaterre wrote: Has anyone seen this lately: $ svn ci -mprepare package Sendingdebian/changelog Sendingdebian/control Sendingdebian/rules Sendingdebian/watch Transmitting file data svn: E13: Commit failed (details follow): svn: E13: Can't create directory '/svn/python-modules/db/transactions/32752-1.txn': Permission denied Who should I get in touch with ? The permissions for the directory look correct to me, but malat is not a member of the scm_python-modules group, nor of the python-modules group on Alioth. I assume you need join the Alioth project to get commit permissions. Ansgar -- 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/555dae97.5030...@debian.org
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: Fwd: python-eventlet_0.12.1-2_amd64.changes REJECTED
Thomas Goirand z...@debian.org writes: What's happening? Is dak going mad? :) No, dpkg doesn't like the source package you uploaded. Please try dpkg-source -x with dpkg from Squeeze. (Yes, the error message should probably be improved.) Ansgar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761yp3y4s@deep-thought.43-1.org
Re: How does team maintenace of python module works?
On 02/15/2013 01:39, Tristan Seligmann wrote: I don't think forming a separate team would be silly at all. If you have a group of people working on Python packages in Git, and a separate group of people working on Python packages in SVN, what use is there in pretending that they're the same group when they're effectively separate anyway? Of course, there may be some people who are interested in working on both teams, but there's nothing stopping you being a member of both teams if you choose to do so. I think having a separate team just to use another VCS is not good. It will probably split contibutors between the different teams; having to follow different polices (for the two teams) for similar packages would at least annoy me. pkg-perl had to make similar decisions in the past: all packages were maintained in Subversion, but some people wanted to try out Git. This was accepted even though some people said they might not care about the Git packages, but it worked fairly well. (Eventually we switched to only Git.) Maybe a similar policy would work for the Python team as well? At least if some regular contributors would have to be interested in using Git. (I don't care too much as I only maintain a single package in the Python modules team.) When you say I want to maintain my packages in Git, in the team, there are really only two possible implications that I can see: 1) I want everyone in the team to comply with this way of doing things, even though they don't want to do so, and 2) I want to do things my own way separate from the rest of the team, but claim to be working as part of the team. Now, written that way, perhaps you can see why this produces a negative reaction from some existing team members, even if you did not mean it in that way? There's more to maintaining packages in a team than having a common VCS. For me it's fairly important to have people that you can ask questions, one has a common policy for packages, ... Ansgar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511e1d68.10...@debian.org
