Re: [PATCH] Support :any architecture qualifiers for multiarch
On Wed, Sep 18, 2013 at 14:33:00 -0500, Steve Langasek wrote:
> On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote:
> > Following the “if it didn't happen on a mailing list, it didn't
> > happen”, I repeat here what I said on IRC:
>
> > 12:26 < kwilk> So I rebuilt src:python-aalib, and I ended up these Depends:
> > "python3:any (>= 3.3.2-2~), libaa1".
> > 12:27 < kwilk> This is wrong; the package only works if the interpreter
> > architecture is the same as libaa1 architecture.
> > 12:27 < kwilk> Please revert this ":any" mess.
> > 12:30 < kwilk> In general, just because a script or a module is pure-Python
> > doesn't mean it doesn't care about interpreter's architecture.
> > 12:30 < kwilk> And there's no way to determine automatically whether it
> > cares or not.
>
> Nonsense. It's not in the purview of the script/module to care about the
> architecture of the interpreter.
>
> There are cases for which a package that ships a python script / pure python
> module *does* care about the architecture of the interpreter, but this is
> *not* because of the script / module itself - it's only because of
> architecture-specific python extensions included in the same package, which
> is expressed via a separate arch-specific dependency on libpython; or
> because of restrictions on the architecture-availability of the other python
> modules the package depends on, which should be handled by the package
> manager and *not* hard-coded in the dependencies of the package in question.
>
Well, in Jakub's case the module does dlopen("libaa.so.1"), so while it
doesn't care about the interpreter's architecture, it does need the
libaa1 and python3 packages to be of the same architecture. AIUI
"Depends: python3:any, libaa1" doesn't express that?
Cheers,
Julien
--
Julien Cristau
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
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/20130919073926.ga31...@crater1.logilab.fr
Re: PEP 453 affects Debian packaging of Python packages
[Stuart Prescott, 2013-09-19] > > I don't understand the pip hate. Why don't you guys try and, you know, > > figure out *why* these tools were invented. It (for sure) is overly > > simplistic, but it's there for a reason. > > It's pretty obvious why these tools were invented -- I think everyone > appreciates the difficulties of installing and distributing software across > different platforms, particularly legacy ones with no native concept of > package management. I think it's also safe to assume that the python > packaging list is probably acutely aware of API problems in python modules > that would make it useful in virtualenvs too. > > However, we're currently in a situation where users can very easily make an > absolute mess of their set up without realising that's what they are going > to do and it then becomes Debian's user support problem. We see this on a > regular enough basis -- packages stop working and the python stackdumps show > modules with incompatible APIs being loaded from /usr/local/. (#703874 is > just one example of this that I have to hand -- I'm sure the BTS has many > more and we see a few per week like this in #debian) > > Who gets the blame for mess made? The Debian project and its developers. Who > ends up helping users clean up the mess? The Debian project and its > developers. Pip can as useful as it wants in virtualenvs but it already has > a lot of historical baggage attached to it that is mostly associated copious > amounts of time spent trying to fix the mess it makes on Debian machines. > > That's why you have pip hate. > > For better or for worse, proposals to make further use of pip carry all this > historical baggage with them. As suggested elsewhere in this thread changing > pip so that it was difficult to do things system-wide would help with this. my thoughts exactly -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20130919074621.gj12...@p1otr.com
Disabling pip for root? (was: PEP 453 affects Debian packaging of Python packages)
On 2013-09-18 09:36, Paul Tagliamonte wrote: > 1) pip isn't for global package management, for this is stupid. If we > disabled root use of pip, I think we'd all be a bit happier. Very quick and very dirty patch attached. > 4) Python modules from dpkg are borderline useless for developers. We > package modules so that apps can use them, not so that people can > develop with them. That is maybe my problem with pip: Developers tend to use every Python library in every version they like from PyPI. As a project leader I generally have to think about deployment and this means: Use Debian stable and backports! Only for long-term projects the next Debian stable release might be relevant. But if you have a dozen or so libraries installed by pip, there are libraries that will not be packaged for Debian and the deployment is wrecked. --- /usr/bin/pip 2013-08-20 00:37:24.0 +0200 +++ pip 2013-09-19 11:11:04.567271401 +0200 @@ -2,6 +2,13 @@ # EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.4.1','console_scripts','pip' __requires__ = 'pip==1.4.1' import sys + +import os + +if os.getuid() <= 100: +print >> sys.stderr, "a nice insult from the sudo insults list?" +sys.exit(-1) + from pkg_resources import load_entry_point if __name__ == '__main__':
Bug#723736: RFA: lintian4python -- Debian package checker (for Python packages)
Package: wnpp I want someone to take over development of lintian4python, as I no longer use this package. Description === Lintian dissects Debian packages and reports bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. This package provides an experimental flavor of Lintian designed to check packages implemented in Python. Allergy advice == * contains: Perl (2.4 kloc), Python (1.0 kloc) * may contain traces of things that are nuts -- Jakub Wilk -- 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/20130919101440.ga20...@snusmumriken.jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
[Julien Cristau, 2013-09-19]
> Well, in Jakub's case the module does dlopen("libaa.so.1"), so while it
> doesn't care about the interpreter's architecture, it does need the
> libaa1 and python3 packages to be of the same architecture. AIUI
> "Depends: python3:any, libaa1" doesn't express that?
as I mentioned on IRC, I think the solution for that is detecting "lib*"
or "${shlibs:Depends}" in Depends (even in arch:all packages, see
pyenchant) and disable :any dependencies for such packages, at least
until we find a better solution for ctypes packages.
I will make the dependency part of multiarch support optional
but keep it enabled by default in jessie (and disable it in
wheezy-backports) so another option would be to let maintainers
disable it in such packages.
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20130919125517.gk12...@p1otr.com
Re: [PATCH] Support :any architecture qualifiers for multiarch
On Thu, Sep 19, 2013 at 14:55:17 +0200, Piotr Ożarowski wrote:
> [Julien Cristau, 2013-09-19]
> > Well, in Jakub's case the module does dlopen("libaa.so.1"), so while it
> > doesn't care about the interpreter's architecture, it does need the
> > libaa1 and python3 packages to be of the same architecture. AIUI
> > "Depends: python3:any, libaa1" doesn't express that?
>
> as I mentioned on IRC, I think the solution for that is detecting "lib*"
> or "${shlibs:Depends}" in Depends (even in arch:all packages, see
> pyenchant) and disable :any dependencies for such packages, at least
> until we find a better solution for ctypes packages.
>
Oh $DEITY please please no.
Cheers,
Julien
--
Julien Cristau
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
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/20130919130506.gb31...@crater1.logilab.fr
Re: [PATCH] Support :any architecture qualifiers for multiarch
[Julien Cristau, 2013-09-19]
> On Thu, Sep 19, 2013 at 14:55:17 +0200, Piotr Ożarowski wrote:
>
> > [Julien Cristau, 2013-09-19]
> > > Well, in Jakub's case the module does dlopen("libaa.so.1"), so while it
> > > doesn't care about the interpreter's architecture, it does need the
> > > libaa1 and python3 packages to be of the same architecture. AIUI
> > > "Depends: python3:any, libaa1" doesn't express that?
> >
> > as I mentioned on IRC, I think the solution for that is detecting "lib*"
> > or "${shlibs:Depends}" in Depends (even in arch:all packages, see
> > pyenchant) and disable :any dependencies for such packages, at least
> > until we find a better solution for ctypes packages.
> >
> Oh $DEITY please please no.
any proposals on how to detect packages that import ctypes?
(other than parsing sources, please ;)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20130919133354.gl12...@p1otr.com
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte wrote: >On Wed, Sep 18, 2013 at 05:16:22PM +1000, Ben Finney wrote: >> Howdy all, >> >> Over at the ‘python-dev’ forum, PEP 453 is being discussed. This >affects >> Debian packaging of Python, and packages written for Python. >> >> See the discussion thread and take the opportunity to represent >Debian >> >https://mail.python.org/pipermail/python-dev/2013-September/128723.html> >> while this major change to the behaviour of Python packaging is still >> being specified. >> >> Note that we don't need a dog-pile; someone with both knowledge and >time >> to discuss this will find that reasoned arguments work better there. >Who >> can do this? > >I butted in, since I was on python-dev anyway. > >http://hg.python.org/peps/rev/6c1b658bc16c > >is the changeset they made after I mentioned it was highly unlikely >that >it would be included. Basically, this means so long as >command-not-found >is installed, we're fine. > >I think this is a fine middleground and shouldn't be much if a problem. >Donald pung me after, and he's open to working with us. Thanks for that. I think that resolves my concern about the mandatory nature of the PEP. I am still concerned about the security aspects of the design. It should be cryptographically verified and not installed as root. Scott K -- 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/698016e1-13c9-43f8-8d3b-ea44512c3...@email.android.com
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 05:16:22PM +1000, Ben Finney wrote: > Howdy all, > > Over at the ‘python-dev’ forum, PEP 453 is being discussed. This affects > Debian packaging of Python, and packages written for Python. > > See the discussion thread and take the opportunity to represent Debian > https://mail.python.org/pipermail/python-dev/2013-September/128723.html> > while this major change to the behaviour of Python packaging is still > being specified. > > Note that we don't need a dog-pile; someone with both knowledge and time > to discuss this will find that reasoned arguments work better there. Who > can do this? I butted in, since I was on python-dev anyway. http://hg.python.org/peps/rev/6c1b658bc16c is the changeset they made after I mentioned it was highly unlikely that it would be included. Basically, this means so long as command-not-found is installed, we're fine. I think this is a fine middleground and shouldn't be much if a problem. Donald pung me after, and he's open to working with us. Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
Hi, On Wed, Sep 18, 2013 at 06:45:24PM -0400, Scott Kitterman wrote: > It shows my background, but when I need older versions of things I > fire up a chroot and work in that. I often do that even for the > same distro release I'm running to keep things separated. It's quite > possible to deal with multiple versions using Debian tools. I had good results doing the something similar, but with LXC to separate things and salt to automate and reproduce the install. https://wiki.debian.org/LXC http://debian.saltstack.com/ -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- 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/20130919143719.gb6...@volans.logilab.fr
Re: [PATCH] Support :any architecture qualifiers for multiarch
* Piotr Ożarowski , 2013-09-19, 15:33: any proposals on how to detect packages that import ctypes It's not necessarily only ctypes. (other than parsing sources, please ;) Don't detect anything. Add an option (say, --multiarch-me-harder), so that maintainers can opt-in for :any dependencies. -- Jakub Wilk -- 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/20130919150538.ga2...@jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
On Thu, Sep 19, 2013 at 05:05:39PM +0200, Jakub Wilk wrote: > * Piotr Ożarowski , 2013-09-19, 15:33: > >any proposals on how to detect packages that import ctypes > It's not necessarily only ctypes. What are the other cases? > >(other than parsing sources, please ;) > Don't detect anything. Add an option (say, --multiarch-me-harder), > so that maintainers can opt-in for :any dependencies. That doesn't sound to me like it's optimizing for the common case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
Paul Tagliamonte writes: > Donald pung me after, and he's open to working with us. Thank you! It's important to have calm discussion with upstream, when we can make a positive difference to this specification. -- \ “Teach a man to make fire, and he will be warm for a day. Set a | `\ man on fire, and he will be warm for the rest of his life.” | _o__) —John A. Hrastar | Ben Finney -- 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/7wwqmcwd8s@benfinney.id.au
