Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: > This has driven > some contributors away in the past, thinking we don't have team spirit. > IMO, that's truth, and this kind of thread is hurting again. Just to back this up: watching threads like this go past makes working on/with Debian look very uninviting. At times it seems like DPMT is more interested in quoting sections of policy at one another than in actually making stuff work. It looks absolutely like there's no team spirit, unless you all keep it carefully hidden from the mailing list. If this is what you're like even to other people with @debian.org email addresses, I don't want to try doing anything within Debian. Thomas K
Re: Dealing with flit -- a simplified packaging of python modules
On Thu, Sep 24, 2015, at 03:30 AM, Paul Wise wrote: > Source tarballs containing generated/bundled files is a bug that > should be fixed. That's my point ;-). From our upstream point of view, it's not a bug that the distributions we put on PyPI contain generated/bundled files - we do it that way deliberately, so that end users can install without needing Javascript developer tools to build those files. If you want a pure source tarball without generated files, that's available from Github. Thomas
Re: Dealing with flit -- a simplified packaging of python modules
On Sat, Sep 19, 2015, at 09:36 AM, Barry Warsaw wrote: > There have been countless attempts at moving the Python packaging > infrastructure to a declarative syntax over the years. I remember > talking to > Tarek at a Pycon *many* years ago about this. Maybe this time it'll > catch > on. :) I think the introduction of wheels makes this goal more practical, as now there's a defined package format that tools can build, rather than relying on executing a script at install time. I'm also making the problem easier using the 80/20 rule: flit doesn't aim to replace all setup.py Python packaging. It's limited to a single module/package of pure Python code, which I think accounts for a large majority of what people do with setup.py. > flit doesn't build sdists, so I guess the current toolchain which starts > with > .orig.tar.gz won't work with flitted packages. The README says: > > "People may also want a traditional sdist for other reasons, such as > Linux > distro packaging. I hope that these problems will diminsh over time." > > I'm not sure which problem you hope will diminish! People wanting > traditional > sdists, the problem of Linux distro packaging or needing sdists > for > downstream consumers like Debian. There are certainly times when I wish distro packaging would focus on maintaining a much smaller set of core infrastructure packages really well. Take Jupyter, for instance: as upstream, we feel no investment in Linux distro packaging of it, and if we're helping people who got it from apt, we're likely to recommend that they uninstall that and use Anaconda or pip to install a recent version. I don't think distro packaging works for user-facing applications, and AFAIK it's not widely used for web app deployment either. However, my hope in that sentence was that other packaging will come not to rely on Python sdists containing a setup.py file. Using sdists for Debian packaging is already somewhat dubious, because they can contain generated and bundled files (we do both for Jupyter Notebook sdists). The way I'd like to see things working is for the canonical source for a release to be the tag in the VCS. Popular code hosting sites like Github make the source tree at this tag readily available as a downloadable tarball, e.g.: https://github.com/jupyter/testpath/archive/0.2.tar.gz The source tree contains metadata about the Python package in the repo. Different tools can use that to build wheels for PyPI, conda packages, Debian packages, or whatever. Of course, only the first of those is implemented yet, and it's no doubt more complex to build a .deb package, but that's where I'd like things to go. Thomas
Re: Dealing with flit -- a simplified packaging of python modules
On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote: > here is a new way to package modules for Python: > https://github.com/takluyver/flit > > It means that something packaged using it doesn't use a setup.py or some > such, but a flit.ini ; see for example: > https://github.com/jupyter/testpath > > I'm not sure how to package something like this (and testpath is a > depends for IPython's tests), so I think asking here is better. By the way, I am also upstream for flit, and I'm prepared to help build some tooling to use it for distro packaging. I know it will cause some inconvenience in the short term because there's infrastructure around setup.py packaging, but ultimately I think that having declarative metadata should be an advantage. Thomas
Re: Dealing with flit -- a simplified packaging of python modules
On Sat, Sep 19, 2015, at 01:05 AM, Julien Puydt wrote: > Yes, you're also upstream for ptyprocess and terminado :-P Guilty as charged ;-) I work for Jupyter/IPython, so there are several dependencies from that that I'm responsible for. > I have nothing against declarative -- it's just that I suspect we will > need something like a --buildsystem=flit or some such, and I have no > clue how to do something like this I don't know how to define a new buildsystem either. For the first package, I hope that we can do without that, at the cost of a longer Debian/rules file that specifies more stuff explicitly, and then work out what bits of that can be abstracted into tooling. Thomas
Re: Removing some python3-* packages
On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote: c) write convoluted tricky code to workaround the bugs and differing behaviour on 3.4 vs 3.5. I use unittest.mock from Python 3.4 on several packages, and it has not required convoluted code. I would be very surprised if that code breaks when run under Python 3.5.
Re: Help needed for broken clean target of python module
On Mon, Jun 22, 2015, at 12:20 PM, Andreas Tille wrote: /home/andreas/debian-maintain/alioth/debian-med_git/build-area/python-dendropy-4.0.2/dendropy/utility/textprocessing.py, line 44, in bytes_to_text s = codecs.decode(s, ENCODING) TypeError: must be string, not None Looks like it's been fixed upstream since the release: https://github.com/jeetsukumaran/DendroPy/pull/20 Hopefully the author will release a new version soon, since it can break installation, but if not, it's a pretty small patch, so you could copy it. Thomas -- 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/1435001911.2473805.304841553.219c2...@webmail.messagingengine.com
Re: /usr/bin/python in Python 2 and 3
On 21 April 2015 at 08:15, Barry Warsaw ba...@debian.org wrote: For third parties who want to distribute scripts that run out-of-the-box everywhere (installers, cross-platform system management or monitoring scripts, build scripts, etc.), Python 3 isn't an option. If we remove Python 2 from the default install in Debian, Python 2 ceases to be an option too. So they'll start using sh or perl or something, or ship compiled code, both of which I think are net negative options. Do you think that will happen even if Python 2 is just an apt-get away? Yes. If I'm distributing a script, I don't want to have to tell users if you're on Debian newer than X or Ubuntu newer than Y, apt-get install python first. If you're on Fedora newer than Z If I couldn't rely on either 'python' or 'python3' being present, I might try to ship Python scripts with a shell wrapper that does something like this pseudocode: if (which python3): python3 my_real_script.py else: python my_real_script.py But that's ugly, and I'd be thinking things like: will the syntax I use work in plain sh, or only in bash? do all distros have bash? how similar are the shells 'sh' points to in different distros? I'm sure I could work it out, but if I need to wrap Python scripts in another language, it's a disincentive to use Python for this kind of thing. Thomas
Re: Bits from the Debian PyCon Hangout - /usr/bin/python
It's worth mentioning that in virtualenvs and conda envs, where there can only be one version of Python installed, 'python' refers to that whether it is Python 3 or 2. So it's already not a safe assumption that 'python' always means Python 2, even if you discount Arch. On 15 April 2015 at 21:04, Scott Kitterman skl...@kitterman.com wrote: On April 15, 2015 8:00:22 PM EDT, Barry Warsaw ba...@debian.org wrote: On Apr 15, 2015, at 04:42 PM, Scott Kitterman wrote: Then I don't understand why the whole s/python/python2// plan in the shebangs helps anything. As long as both exist, it's a no-op. Partly this is to begin to educate users to stop using /usr/bin/python, which has unclear semantics across the wider Python community. If users see distro installed scripts use /usr/bin/python2, and PEP 394 says to use it, they will switch over and in time (e.g. by 2020) the impact of removing /usr/bin/python will be greatly lessened. P.S. It would be nice if there would be a PEP that says to never ever do this. I know it would make Arch have a sad, but they'll get over it. PEP 394 is the vehicle for this, and getting the Debian and Fedora ecosystems aligned will be a powerful force for making sure it says what we want it to say. PEP-394 is very weak in my opinion. All it says is we aren't ready to break existing systems yet, but we probably will in the future. I think it's better not to do that period. Scott K -- 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/403c6d4f-1e52-4e67-aa6a-5914d0be8...@kitterman.com
Re: PyCon BoF: Stretch goals for cPython, PyPy CFFI
On 14 April 2015 at 08:10, Barry Warsaw ba...@python.org wrote: But it fails unhelpfully when you use it in a shebang. $ /tmp/foo.py bash: /tmp/foo.py: /usr/bin/python: bad interpreter: No such file or directory Let's make the latter more helpful. From a script authors point of view, it's currently safe to assume that a shebang like '#!/usr/bin/env python' will work on any Linux machine. In some cases (Arch) it may already refer to Python 3, but with some care it's entirely possible to write a script that can do the right thing on Python 2 or 3. If distros start to remove 'python', there's an interim period before it's safe to assume that 'python3' is available everywhere, and script authors currently don't have any good options to bridge that. I know Debian is all in on treating Python 2 and 3 as two entirely separate worlds, but that's not how everyone sees them. It would be nice to make some kind of affordance to people for whom they are two versions of the same language. Thomas
Re: PyCon BoF: Stretch goals for cPython, PyPy CFFI
On 14 April 2015 at 08:57, Scott Kitterman deb...@kitterman.com wrote: I have scripts I use locally that are untouched in almost a decade that use /usr/bin/python. I'm thinking about scripts that are written and distributed to people running on different, unknown, Linux distros. Obviously if you're only targeting your own machines, there's no problem. But if you want to write a script that will work for arbitrary Linux users, what should you do? I imagine it's not yet a safe assumption that python3 is installed everywhere, but on the other hand, Ubuntu and Fedora are both looking at dropping Python 2, so without some kind of compatibility shim it won't be safe to assume there's a python command. Thomas
Re: dh_python2 extension rename breaking module loading
On 11 February 2015 at 14:22, Scott Kitterman deb...@kitterman.com wrote: Given the filename, shouldn't it be import khmermodule? foomodule.so was a valid filename for a module 'foo' - though I only heard about this when that spelling was removed in Python 3.3: https://docs.python.org/3/whatsnew/3.3.html#building-c-extensions
Re: multiple modules in one source
On 14 December 2014 at 15:34, Brian May br...@microcomaustralia.com.au wrote: Not sure calling it multiple distinct Python packages is correct, currently there is only one setup.py, and hence only one egg file produced. e.g. package contains setup.py module1/__init__.py module1/something.py module2/__init__.py module2/somethingelse.py To be precise with Python terminology, an importable folder (typically with an __init__.py, but there are exceptions since PEP 420) is a package, a single importable file is a module, and the thing that you get from PyPI as a single unit is a distribution, I believe. In practice, distributions are almost always called packages as well. Thomas
Re: Help needed to test packages with Django 1.7
On 4 August 2014 10:29, Thomas Goirand z...@debian.org wrote: Also, fixing version 3 of beautifulsoup doesn't look very easy. It needs sgmllib, which is removed from Python 3, and it doesn't feel right to maintain sgmllib as a Python module for Python 3 (I tried, and with a few hacks, it works though...). IIRC, that's why upstream only added Python 3 support in a new major release with a new PyPI package name. In terms of porting, the main thing to be aware of is that beautifulsoup4 no longer handles parsing HTML itself - now that lxml and html5lib offer decent, tolerant HTML parsers, beautifulsoup is focused on the tree traversal and manipulation APIs. So the APIs should be largely the same, but the parsing may produce slightly different results. Is there anyone who wish to package beautifulsoup4 I think someone already did ;-) https://packages.qa.debian.org/b/beautifulsoup4.html Thomas
Re: favouring Python3 in the Debian policy
On 7 May 2014 14:11, Paul Tagliamonte paul...@ubuntu.com wrote: If I had more time to blow, I'd likely try a run at something SUDS API compatible in Python 3. Won't happen any time soon for me, but it's something I will eternally praise someone over. So many people have tried to forward-port the SUDS codebase, apparently it's *bad*. This fork looks like it's actively maintained, and has a recent release on PyPI (as suds-jurko): https://bitbucket.org/jurko/suds Thomas
Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)
On 26 Jan 2014 16:33, Paul Tagliamonte paul...@debian.org wrote: On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Ditto - I agree with just about everything Nicolas said. I'd love to see this become a cooperative and welcoming team. Thomas
Re: Indeed, python-concurrent.futures is the same
On 25 Jan 2014 07:37, Thomas Goirand z...@debian.org wrote: On 01/25/2014 06:01 PM, Sandro Tosi wrote: Sorry, what? and you didn't think to contact me first to almost rewrite the package? If there's problems, open bugs. Revert your changes or I'll do at the first occasion. and mainly, why don't you go away from DPMT once and for all? you're doing more harm than good here. you're not welcome here. Shortly to the list: This kind of message saddens me. I'm not expecting this kind of interaction, but rather: thanks for fixing that, however there, you shouldn't have done this, plus let me revert and fix that bit better Maybe you could try this style and really do team work if your package is team maintained, no? I agree. Even if we don't have an explicit code of conduct, I think we should expect more civil discourse. It sounds to me like Thomas G was honestly trying to improve something, and disagreeing with how he did it does not warrant a personal attack. Thomas K
Re: CLI recommendations for version-specific /usr/bin scripts
On 11 November 2013 08:45, Barry Warsaw ba...@debian.org wrote: * Expose /usr/bin/foo with a shebang line of #!/usr/bin/python * Expose /usr/bin/foo-3 with a shebang line of #!/usr/bin/python3 In upstream IPython, we now install an ipython2 script on Python 2, paralleling the ipython3 script. The packaging in Debian for pip likewise installs /usr/bin/pip2, and as recently discussed, a python2 symlink is now created. Should this be part of the recommendation? Question: dash or no dash in the script name? I feel like I mostly see the single-digit version number without a dash (nosetests3) and the two part number with a dash (nosetests-2.7). I'm inclined to leave the dash out where it makes sense, in line with the /usr/bin/python* naming, but I don't feel strongly about it. Thomas
Re: Packaging the new upstream release of ipython (i.e. 1.1.0)
Hi Jean-Christophe, On 29 September 2013 13:31, Jean-Christophe Jaskula jean.christophe.jask...@gmail.com wrote: The Ipython team has released a couple of major releases during the last months but I haven't seen any discussions about packaging them in debian. Just for curiosity, I decided to start trying to update the debian package (v0.13.2) to the latest release (v.1.1.0). When doing it, I realized there is a lot of changes to do and I do understand why it is not in sid yet (putting aside you might be also very busy with other things). I didn't plan to propose this work for a NMU but I'm wondering if someone was working on it. So far, my work is still in progress but I don't mind keeping working on it if it helps you or dropping it if a debian package is going to be uploaded soon. I have adapted most of the debian patches to the upstream release. I'm still working on the Mathjax patch to avoid ugly hack. I started from the source that one can get at: https://github.com/ipython/ipython/archive/rel-1.1.0.tar.gz . However, everything isn't shipped in this archive and I had to add static components that I took from: https://github.com/ipython/ipython/releases/download/rel-1.1.0/ipython-1.1.0.tar.gz. I put these files altogether in the same .orig.tar.gz archive and started packaging from it. If you need help on this packaging, I'll be very happy to contribute. I asked Julian about this last month, and this is what he said: I'm not working very fast, due to lack of time and focus on other things :/ There are still a few things missing. highlightjs is done marked almost done still to do: fonts-awesome missing css files (#719360) requirejs bootstrap jquery 2.0 I don't know how to handle bootstrap as it has as version 3 out now ipython uses 2, debian has an even older 2. Probably embedding is best, like codemirror. If you want to help out you could have a look at packaging requirejs, it seems like a useful package as it has a small api (compared to bootstrap, jquery or codemirror). Also much appreciated is writing the debian/copyright for bootstrap if we go for the embed route. (I haven't got round to doing anything on this front yet) Thanks, Thomas
Re: PEP 453 affects Debian packaging of Python packages
On 20 September 2013 01:11, Thomas Goirand z...@debian.org wrote: From a developer point of view: this leaves you dependent on other people to get the latest release of your software to users, which can be very frustrating. For instance, I'm a developer for IPython: we made a 1.0 release over a month ago, and there's already been a 1.1 release since then, but Debian unstable still doesn't have either of these. This is not to criticise our packager, who we have a good relationship with, but simply to point out that this system is beyond our control. If we recommend that people use apt/yum/port/whatever to install IPython, they'll get an old package, with bugs that we've already fixed. By contrast, we update the packages on PyPI at release time, so users installing with pip will always get the current version. Thomas Then get involved in the Debian packaging: problem solved! I try to get involved with Debian packaging. But, to be blunt, it is a slow, frustrating process, and the effort I put in feels utterly disproportionate to the results. We are not going to get many Python programmers involved with the packaging process as it stands. Take the most recent two packages I have worked on: - python3-sympy: The package is sitting in the team SVN, waiting for someone to review or upload it. I last touched it two months ago to package a new upstream release. - python-xlrd: My changes were rejected, although the package was extremely out of date, because the package had an individual 'Maintainer' who hadn't been seen for three years. It took another four months (a long time in developer terms) before the wheels turned and someone actually got an up to date version packaged. I wish I could say this is atypical. But from my limited experience of DPMT, a slow, tricky process is the norm. There are procedural traps (e.g. to make a package you must first file a bug by e-mail, then mark your new package as closing the bug), social traps (annoying a 'maintainer' overprotective of what is ultimately little bit of metadata to turn a Python package into a Debian package), and you may simply fail to catch the interest of a Debian developer--as I seem to have failed with python3-sympy--in which case you're out of luck. I don't wish to criticise without making suggestions as to how this could be improved: - Write a 'how to keep your distro packager happy' guide for developers. E.g. many Python developers don't know that distros will move data files to /usr/share, but when you do know, it's easy to write code so that the patch to achieve this is trivial. - Have a simple way for developers to submit packaging information without having to join Debian teams, file ITP bugs, and all that cruft. Technically, Debian mentors is already something like that, but maintainers mostly ignore it. Which brings me to: - Put the emphasis on keeping packages up to date and simple, not on 'maintainer rights'. Packaging should not be an art form. If someone uploads a newer version to Debian mentors (or another submission system), the maintainer should get an e-mail. If a package is out of date for more than a few days without a clear reason, people should be prodding the maintainer to ask what's up. If a maintainer is regularly unresponsive, drop the package to team maintainership so that other people can work on it. Put another way, focus on what is best for Debian and for the upstream project being packaged, not what the person who has appointed themself 'maintainer' of that package wants. - Make it really, really easy to accept changes to packaging. One of the reasons for the meteoric rise of Github is that when someone submits a change that clearly improves things, the repository owner literally just has to click a big green button to accept that. I don't mean DPMT should use Github, but, for instance, if upstream makes a bugfix release 1.4.3, and Debian has 1.4.2, it should be as near as possible one click/one command to grab the new version, update the changelog, commit the change, upload the package, and whatever else needs doing. I know this won't go down well with everyone here. I contend that if the situation continues as is, Debian packaging will be seen as ever more irrelevant by Python developers. Already, the default assumption is that distro packages will be out of date. The scientific Python community is unhappy with pip PyPI, but is looking to yet more packaging tools, such as conda, to address this (despite Yaroslav Halchenko's excellent work with NeuroDebian). Thomas
Re: PEP 453 affects Debian packaging of Python packages
On 20 September 2013 10:52, Paul Tagliamonte paul...@debian.org wrote:
If a library breaks API because the maintainer wanted another toy
rewrite, we're not going to upload it and break half the archive. That's
silly.
This condescending attitude towards developers ('another toy rewrite')
doesn't help. Work with upstream developers to understand what they're
doing, encourage them to care about API stability and to use conventions
like semantic versioning and deprecation warnings to reduce the impact of
changes. There are plenty of developers who do care about backwards
compatibility.
We could also have topic-specific extra repos, so that a user can add, say,
a Python-science repo to get newer versions of some packages by accepting a
bit of extra risk associated with that. Neurodebian offers something like
that, but in general it's hard to set up. Ubuntu PPAs are much easier to
get set up, but don't build for Debian relases.
Hell, we shouldn't even introduce a module unless it has an app using
it.
- This gives module authors little to no incentive to get involved in
Debian packaging.
- In scientific Python, the expectation is that *users* will import and use
modules directly. Likewise, most code that depends on a package like Django
is not going to be packaged as a Debian app. I don't think Debian has some
special insight into what currently unpackaged things users want.
We care more about users than developers. Python developers can use
virtualenv and pip on Debian like any other Python development env.
Believe it or not, developers care about users as well. That's why we're
writing code and fixing bugs. We want the people using our software to have
the best possible experience. However, we regularly see bug reports for
problems where we have already released a fix, because users are on
outdated versions. So, upstream projects are increasingly inclined to
bypass distros and offer their software to users by a more direct route.
Again, it feels like packagers see developers as the enemy. Yes, developers
will at times do things that you disagree with, but fundamentally we are on
the same team. We both want to deliver great software to users. If you
fight developers, you will lose, by sheer weight of numbers.
Thomas
Re: PEP 453 affects Debian packaging of Python packages
On 20 September 2013 12:08, Paul Tagliamonte paul...@debian.org wrote: Don't take this as me trashing on Python or Pythonistas. If you want to talk about this in person, I'm usually at PyCon. I'm also usually in the packaging BOF. Perhaps we can bring some of this up there this year? Unfortunately, I don't think I'll be going to PyCon next year. I'll probably be at next year's SciPy, but I presume you won't be there? I'm glad to hear that you are a developer as well. However, a lot of the tone in this discussion suggests that all developers are idiots who can't keep an API intact. I think there is a much more productive conversation to be had with upstreams. help. Work with upstream developers to understand what they're doing, encourage them to care about API stability and to use conventions like semantic versioning and deprecation warnings to reduce the impact of changes. There are plenty of developers who do care about backwards compatibility. And just as many (if not more) that don't. As a result, we have to design the system to defend against this breakage. Alright, a proposal: create some kind of 'expedited upload' pathway, so upstream developers sign to say that they will use semantic versioning, never break APIs in a bugfix release, issue deprecation warnings for any code relying on something that they plan to remove, and create strong regression tests. We could add other reasonable conditions to this list. The carrot for developers is that, by agreeing to this, they get semi-automated uploads of minor updates (run the package's own tests, run DEP-8 tests of its dependencies, and a brief manual check). If projects that have signed break the requirements, kick them off the pathway for a couple of subsequent releases. At present, there is no carrot - getting stuff packaged is slow whether upstream cares about API stability or not. (I'm sure someone reading is about to point out a reason why this won't work exactly as I have described. Don't bother telling me - I'm not really expecting this will actually happen. But please try to think of how things might change, instead of why nothing must change.) We could also have topic-specific extra repos, so that a user can add, say, a Python-science repo to get newer versions of some packages by accepting a bit of extra risk associated with that. Neurodebian offers something like that, but in general it's hard to set up. Ubuntu PPAs are much easier to get set up, but don't build for Debian relases. PPAMAIN would be nice for special cases like this, aye! OK, I searched that term. It's nice to see that Debian is finally considering setting up a PPA system. Did anything more happen on that after the mailing list thread got sidetracked into security questions? Elena: there is an UpstreamGuide_ on the wiki: So promote it! I'm pretty sure I've never seen that URL before. ITP bugs aren't cruft, they are a way to prevent duplication of work, which would lead to even more frustration. That seems like an unlikely problem in real world cases - how often will two people decide to package the same, currently unpackaged, piece of software, within the couple of days or so before the first one publishes their work. And if it is necessary: make it simple. A web page listing 'things people have said they're working on packaging in the last week', with a text box to add something, would be easy to implement. Instead, I have to install a command line tool, run through several questions, paste it into an e-mail client, and then remember to close the bug in the package's changelog. It's a double-reciprocating sledgehammer with cruise control to crush an ant. ;-) It takes more than the two weeks for AUR, but afaik it should take less than the 4 months you mentioned: was the MIA team contacted? Yes. They never responded to me, but instead filed a bug which I didn't see. Most of the four months was then just waiting for someone to act on that bug. I didn't realise anything had happened until I checked on the package today. Thomas
Re: PEP 453 affects Debian packaging of Python packages
On 20 September 2013 16:00, Andrey Rahmatullin w...@wrar.name wrote: Packaging often takes much longer than a couple of days, especially if the packager is not experienced. And when the work is published somewhere, but not yet uploaded, there is no general way to know if it's published and where. And how many inexperienced packagers will start by filing an ITP bug? Or indeed by searching for existing ITP bugs? More likely, the bug only gets filed when they've prepared a working package and Lintian is complaining about the lack of a line closing the ITP bug. This is not a problem specific to Debian - people work on all sorts of projects, and post them all over the web. Yes, sometimes work gets duplicated, but the world does not end. For a project like Debian, you can sanely keep a registry of 'stuff people are working on', but if you're going to do that, at least make it easy to use. Thomas
Re: PEP 453 affects Debian packaging of Python packages
On 18 September 2013 08:41, Piotr Ożarowski pi...@debian.org wrote: so instead of reinventing the wheel and trying to make something that works everywhere they should make it easier for others to convert whatever they provide (tarballs?) into .rpm, .deb or .exe. From a developer point of view: this leaves you dependent on other people to get the latest release of your software to users, which can be very frustrating. For instance, I'm a developer for IPython: we made a 1.0 release over a month ago, and there's already been a 1.1 release since then, but Debian unstable still doesn't have either of these. This is not to criticise our packager, who we have a good relationship with, but simply to point out that this system is beyond our control. If we recommend that people use apt/yum/port/whatever to install IPython, they'll get an old package, with bugs that we've already fixed. By contrast, we update the packages on PyPI at release time, so users installing with pip will always get the current version. Thomas
Re: RFS: python3-sympy
I've updated the python3-sympy package in SVN to the new upstream release, 0.7.3. Is anyone interested in reviewing or uploading this? Thank-you, Thomas On 29 June 2013 23:17, Thomas Kluyver tak...@gmail.com wrote: On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote: Please can someone upload the new package python3-sympy Package name : python3-sympy Version : 0.7.2-2 URL : http://sympy.org/ Binary packages: python3-sympy It's already in the team svn: svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/ From a previous discussion, it's OK to have separate source for this, because upstream doesn't support building Python 2 and 3 packages from the same release tarball: http://lists.debian.org/debian-python/2012/10/msg00041.html This now also has an ITP bug, #712924. And I've put it on Debian mentors if that helps anyone to review it. Thanks, Thomas
Re: starting to dive into python package bugs
On 16 July 2013 22:25, Stéphane Blondon stephane.blon...@gmail.com wrote: I checked the string exceptions in the code and they are not catched (see shell commands used at this end of this message). So I plan to wrap the string with an exception (Exception ou TypeError). To me, the errors raised are not TypeError so it's not the appropriate exception but if someone catched TypeError in another software (outside Debian) it will work. It would not work with Exception class. However, I still prefer raising Exception. Does anyone have an opinion about that point? Finally, I used BaseException. I added a patch to the bug report (#585291): I would be inclined *not* to use BaseException for this - the intention is that 'except Exception:' should catch all normal exceptions, and only KeyboardInterrupt and SystemExit are outside that. I don't know the specifics of the string exceptions you're updating, but almost anything that Python code explicitly raises should inherit from Exception. Thomas
Re: starting to dive into python package bugs
On 3 July 2013 19:36, Barry Warsaw ba...@debian.org wrote: The reason is that if some code is trying to: except 'error message' this will fail if the raise site is changed. In fact it will already fail - recent Python 2 versions throw a TypeError if you attempt to raise a bare string (from at least 2.6 - I don't have older versions to check). Changing the exception could still lead to it getting caught by an except: clause which previously missed it, though. Thomas
Re: setuptools 0.7
On 22 May 2013 16:28, Barry Warsaw ba...@python.org wrote: I think we should consider switching back to setuptools once 0.7 is released (defined as available on PyPI), since this will clearly be the future of this component. We may have some fallout to deal with in other packages (e.g. virtualenv) that depend on this, and clearly setuptools/distribute is a central part of our stack. But it seems like now is a good time to shake that out for Jessie. PyPI now has the re-merged setuptools at version 0.7.4 - are we still planning to package this as a new version of python-setuptools? Thanks, Thomas
Re: RFS: python3-sympy
On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote: Please can someone upload the new package python3-sympy Package name : python3-sympy Version : 0.7.2-2 URL : http://sympy.org/ Binary packages: python3-sympy It's already in the team svn: svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/ From a previous discussion, it's OK to have separate source for this, because upstream doesn't support building Python 2 and 3 packages from the same release tarball: http://lists.debian.org/debian-python/2012/10/msg00041.html This now also has an ITP bug, #712924. And I've put it on Debian mentors if that helps anyone to review it. Thanks, Thomas
Re: django-tables package
On 19 June 2013 05:47, Brian May br...@microcomaustralia.com.au wrote: How do I do this? I don't see any references to objects.inv in the upstream source code for django-filter, and I am not really sure what these files are used for. The files are an index of objects described in the Python Django sphinx docs, so you can cross reference a Django function and Sphinx will make a link to the documentation for it. Thomas
RFS: python3-sympy
Please can someone upload the new package python3-sympy Package name : python3-sympy Version : 0.7.2-2 URL : http://sympy.org/ Binary packages: python3-sympy It's already in the team svn: svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/ From a previous discussion, it's OK to have separate source for this, because upstream doesn't support building Python 2 and 3 packages from the same release tarball: http://lists.debian.org/debian-python/2012/10/msg00041.html Thanks, Thomas
Re: Accepted python-defaults 2.7.3-5 (source all)
On 7 May 2013 18:46, Sandro Tosi sandro.t...@gmail.com wrote: debian-python doesn't deserve a similar communication (don't you dare thinking about coordination, it's out of question) because we're just a bunch of puppets waiting for orders by the ultimate master - well done. Selectively quoting the tech committee resolution: These breakdowns appear to be rooted in an unfortunate feedback loop, of which all parties involved share some blame. On multiple occasions, inflammatory comments regarding the employment and/or motives of individuals involved in python have been made. ... The committee expresses its disappointment in the communication problems which have lead to this issue, and strongly suggests that all involved parties be as awesome to each other as possible. Please everyone, make an effort to be polite. I don't know the origin of all the problems in debian-python (and frankly I don't want to), but it's pretty clear that writing snarky messages isn't going to resolve them. If you want to make a point, do so politely and people will be more inclined to listen. Thanks, Thomas
Re: About canonical Vcs fields
On 14 March 2013 14:01, Scott Kitterman deb...@kitterman.com wrote: 3. Don't care to invest any thought or time in the question. That's pretty much my thinking. If someone wants to go through and automatically change svn. - anonscm., that's fine. I'm mildly against having a Lintian rule for it, because it just seems like yet another gotcha to catch out new packagers. Thomas
Re: Removing /usr/bin/nosetests-3.x scripts
On 22 February 2013 06:28, Dmitry Shachnev mity...@gmail.com wrote: After looking at all packages that build-depend on python3-nose, I've identified these packages as needing fix: I happen to recall that python-xdg is also affected, both in debian/rules [1] and autopkgtests [2]. I'm happy to update that, but you might want to double check the script that you were using to scan packages, to make sure that we're not missing other cases. [1] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/rules?revision=22479view=markup [2] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/tests/upstream?revision=23091view=markup Thomas
Re: python3 and /usr/share
On 20 February 2013 14:38, Olе Streicher debian-de...@liska.ath.cx wrote: I am trying to create packages for Python3 for the source package [1]. Following the guide [2], I get some success. However, the packages for Python2 and Python3 differ significantly: in the Python2 package, all machine independent data go into /usr/share/, while the Python3 package contains everything under /usr/lib/python3. The Python code itself goes into /usr/lib/python3 now - as I understand it, /usr/share/pyshared was a workaround that's not needed for Python 3. If the package includes actual data files, they should still go into /usr/share. If it has a lot of data files, it might be worth splitting them into a -data or -common package that the Python 2 3 packages both depend on. IPython matplotlib both use this: ipython3-notebook depends on ipython-notebook-common, and python3-matplotlib depends on python-matplotlib-data. Best wishes, Thomas
Re: How does team maintenace of python module works?
On 20 February 2013 14:53, Thomas Goirand z...@debian.org wrote: In what way the QA is different because it's a tag instead of a tarball ? I don't understand your reasoning. In both cases, you must make sure that what you are packaging is buildable, tested, QA, etc. I think the idea is that, if you prepare a release and find some last-minute critical bug (say, in the build process), you'll definitely upload a fixed release tarball, because that's what people are installing from. But you might have already tagged it, and you might forget to move the tag to the fixed version. Of course, in projects where the git tag is the release, it makes no difference. But lots of projects still do tag a release and upload separate release tarballs (say, to PyPI). Thomas
Re: How does team maintenace of python module works?
On 19 February 2013 17:55, Thomas Goirand z...@debian.org wrote: Thomas Kluyver Seems to be ok with migrating to Git (so, option D) I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for summarising the votes. Including Piotr Andreas, and putting people whose opinion you've described into the nearest possible vote would give us first preference votes: D: 4 (migration to git) C: 3 (allow git) E: 2 (migration to bzr) F: 2 (migration to hg) A: 1 (maintain status quo) - I thought there were some more, but I'm too tired to go back through the thread at present. Using alternative voting, knock out A (and B, which had no first preference votes): D: 4 C: 3 F: 3 E: 2 After that it gets tricky, because we'd knock E out next, but the I'm not sure where the votes counted for E (Scott Barry) should be reallocated. If we plough ahead regardless by dropping them, it ends up with a 4-4 draw between D (migration to git) and C (allowing git and svn). Perhaps we can get more votes, or more fallback preferences from people who've only expressed their first preference. Thomas
Re: How does team maintenace of python module works?
On 18 February 2013 20:46, Ludovic Gasc gml...@gmail.com wrote: I vote D, and I can handle the migration from SVN to Git, I've done this several times for my work and WYMeditor. Are you interested? I'm interested personally, but the votes so far suggest there's no real will for any change - the only option with more than one first preference vote is the status quo. Thomas
Re: How does team maintenace of python module works?
On 18 February 2013 22:23, Ludovic Gasc gml...@gmail.com wrote: I propose to make a poll on the Web (Doodle or other) and ask the question in another thread, I'm not sure that each subscriber has read this long thread. I don't think I'll do that myself - the responses I have seen don't have even the barest hint of consensus, and there's no particular reason to think that a wider sample would produce a more unified opinion. If you think it would be useful, though, I shan't stop you doing it. Thomas
Re: How does team maintenace of python module works?
On 16 February 2013 09:10, Thomas Goirand z...@debian.org wrote: It would be really stupid to only want to claim to be working as part of the team, that's not at all what I want to do. I'd like to be able to help when I can, and receive help when I need, which is the point of a team. I agree there are reasonable reasons to want to maintain something in git, and it's not ideal to exclude those packages from team maintainership just because of the VCS question. Although, if it came to that, the team would be happy to offer advice and assistance for Python packages that aren't maintained by the team. We all want stuff to work smoothly, whether or not it's our stuff. I suggest we take a poll - not as a binding decision, but to get an idea of the level of support for different courses of action. You're free to attach more weight to the votes of highly involved team members. The following four positions have all been advocated in this thread: A - Maintain the status quo, in which DPMT packages may only be maintained in SVN. B - As A, but encourage the creation of a separate team where Python modules can be maintained in git. C - Allow DPMT-maintained packages to live in SVN or git, so new packages can be committed to git if the packager prefers. Optionally, we could make provisions to migrate existing packages. D - Migrate all the DPMT-maintained packages to git. (I suggest we don't consider other VCSs - while we might have our favourites, I sampled the list of Debian teams, and found very few using anything other than svn or git. So tools workflows for other VCSs are likely to be less well developed.) So I would vote CDBA, in order of preference. Thanks, Thomas
Re: How does team maintenace of python module works?
On 14 February 2013 16:41, Sandro Tosi sandro.t...@gmail.com wrote: so please search into the mailing list archive about the several iterations of such discussion and the outcome of them. The most recent discussion I found with a quick search started nearly 2 years ago. Nobody appeared to be arguing strongly against the switch, although there were a few caveats, like having a sane migration path: http://thread.gmane.org/gmane.linux.debian.devel.python/6540/ It looks more like the idea stalled than was rejected. If that is the case, it shouldn't be a problem to discuss it again. Thomas
Re: How does team maintenace of python module works?
On 14 February 2013 20:29, Barry Warsaw ba...@python.org wrote: I look at the switch to dh_python2 as an example. I don't think it's a particularly good example, though. Lots of packages continue to use the older helpers, and not due to a lack of time - attempts to move away from the deprecated helpers still seem to meet considerable resistance. That causes problems when newcomers don't want to learn deprecated packaging methods, and aren't allowed to update packages to use the recommended helper. Back on the VCS question, I fear that the 'all or nothing' road will circle back to 'nothing' for a long time. I think that we should allow some packages to live in git without forcing a complete migration, so individual maintainers can use the VCS they're more comfortable with. Most open source programmers have at least a basic familiarity with both, so it shouldn't be such an obstacle to working on other packages. We wouldn't be the only team doing this - Debian Games Team, for example, use both git and svn for packaging: http://wiki.debian.org/Games/VCS Thomas
Re: How does team maintenace of python module works?
On 14 February 2013 22:54, Matthias Klose d...@debian.org wrote: That causes problems when newcomers don't want to learn deprecated packaging methods, and aren't allowed to update packages to use the recommended helper. Agreed, so why not helping with it? Again, why not helping here? I'm not sure what you're suggesting I do. I consider myself to be a newcomer in more or less the situation I described. I've got better things to do than learn the workings of python-support, but switching a package to dh_python2 is apparently a major change, which only named maintainers can approve. And if the maintainers aren't interested, the old helper can remain indefinitely. Also, between this sort of thing, and the tense atmosphere I sometimes feel this list has, I'm not especially motivated to contribute here. The effort/satisfaction ratio isn't as good as many other projects I can spend time on. Back on the VCS question, I fear that the 'all or nothing' road will circle back to 'nothing' for a long time. I think that we should allow some packages to live in git without forcing a complete migration, so individual maintainers can use the VCS they're more comfortable with. Most open source programmers have at least a basic familiarity with both, so it shouldn't be such an obstacle to working on other packages. We wouldn't be the only team doing this - Debian Games Team, for example, use both git and svn for packaging: http://wiki.debian.org/Games/VCS Now you did point out one discrepancy, which hinders newcomers, and you do want to introduce another one? The distinction I was trying to make is that open source developers often already know the basics of multiple VCSs, because they've contribute to different projects. By contrast, the different packaging helpers are entirely specific to packaging Python modules within Debian, so newcomers have to learn them for this specific task. So there's less penalty to having multiple VCSs coexisting. But I don't feel strongly about this point - it looks like we want to maintain a single team VCS, and that's fine by me. Thomas
python-xlrd
The python-xlrd package is maintained by Thomas Bläsing and the DPMT, but the packaged version is quite old. A PAPT thread from last year suggests that Thomas Bläsing is missing in action [1]. I've prepared a new version of the package, using a patch from the bug tracker, the latest upstream version, and adding a python3- package. Does anyone object to me committing this to the DPMT SVN repository, and seeking sponsorship for the new version? [1] http://lists.alioth.debian.org/pipermail/python-apps-team/2012-April/006028.html Thanks, Thomas
Re: python-xlrd
On 6 February 2013 12:52, Sandro Tosi sandro.t...@gmail.com wrote: Yes I do: Thomas is set as the Maintainer (as opposed to the team being the Maintainer), so your are more forced to ask Thomas first given the huge changes you're planning to do: did you contact him (it doesn't seem so from your email)? have you done that in a public tracable way (pinging a bug, f.e.)? did you give him enough time to reply? I've just done some digging. I see no activity from Thomas B since 2009. Lintian is complaining about his packages [1], apart from two where people have managed non-maintainer/team uploads. Tomorrow, it will be two years since a bug was filed requesting a new version of python-xlrd [2]. I can't find him on the TU Berlin site, so it's likely that the e-mail address we're trying for him has expired. No new e-mail address is apparent. No doubt he should have declared his packages orphaned before he left. But whether he got hit by a bus, or just lost interest in them, I'm not interested in blaming him. I have e-mailed the MIA team to start the 2-month process [3] that will probably end with his packages being orphaned. Of course, it's good to exercise due diligence, but the flip side is that technical changes which I hope would be uncontroversial have now taken a back seat to bureaucracy, because one man a few years ago declared himself 'the maintainer'. It feels like a big enterprise which should have a pretty good bus factor has been artificially split into many small projects, each with a terrible bus factor. There are plenty of people who understand the packaging for something simple like this, and hundreds [4] of Debian developers that we trust to upload packages. But changing a package hinges on an individual maintainer, who could be busy, on holiday, uninterested, or deceased. I suggest that we encourage packagers to make team maintainership the norm, and individual maintainership the exception, to avoid this kind of problem. This is in line with plenty of other open source projects, where people talk about not becoming a bottleneck or a single point of failure. [1] http://lintian.debian.org/maintainer/thoma...@pool.math.tu-berlin.de.html [2] https://bugs.launchpad.net/debian/+source/python-xlrd/+bug/714632 [3] http://wiki.debian.org/qa.debian.org/MIATeam [4] http://www.debian.org/devel/people Best wishes, Thomas
Re: python-xlrd
On 6 February 2013 19:30, Sandro Tosi sandro.t...@gmail.com wrote: please read our unwritten policy about Maintainer field at http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin As a general rule of thumb, just set Maintainer to the team; there might be some exceptions, like in situations where the package is so complex that a check from a knowledgeable person is welcome before an upload but they are very rare. This is pretty much what I mean, but I think we should strengthen it a bit from what I think the current case is. Namely, if someone does an RFS for a package with themselves set as the Maintainer, the reviewer should encourage them to put the team there instead. Maybe reviewers are already doing that, although I don't remember seeing it. Simon: If the request for a new version has been open for 2 years, waiting another couple of months to confirm that the maintainer doesn't object isn't really going to make much difference - particularly if that's 2 months of release-freeze time. It's two months in which someone has to e-mail Thomas B several times, and in which what I've done will fall out of my memory. Maybe I'll forget about it by April, and someone will end up redoing the work. Maybe my laptop will kick the bucket in the meantime, and the changes that I couldn't commit to the centralised VCS will be lost. (Although in this case, they're in my PPA [1]) It's two months of release freeze time for Debian, but my understanding is that submitting to Debian experimental remains the preferred way to get new versions into Ubuntu. Ubuntu is not currently frozen, but in two months time it will be, so it will miss these changes for another 6 months. Finally, it's two months as a minimum. Elena contacted the MIA team at least seven months ago, but Thomas B's packages have not been orphaned. That suggests that either they didn't follow up, or that he made contact but hasn't resumed any maintenance. I haven't seen any way to check on that, or to know the fate of my message to the MIA team. Thomas [1] https://launchpad.net/~takluyver/+archive/python3
Re: Private modules
On 22 December 2012 22:00, Bas Wijnen wij...@debian.org wrote: 6. Make /usr/bin/program a symlink to the actual file in the private directory. It will then search in its real place. (I've seen this used by angrydd.) This (symlinking /usr/bin/program) appears to be the recommended way to deal with it: http://wiki.debian.org/Python/Packaging#Example_2:_Python_application http://permalink.gmane.org/gmane.linux.debian.devel.python/6728 Thomas
Re: GUI tool for packaging
Hi Clint, On 15 November 2012 03:53, Clint Byrum cl...@ubuntu.com wrote: https://launchpad.net/pkgme At one point I was interested in writing a ruby backend for this, but got distracted and moved to other focus, but I think it solves what you are talking about, without need to develop a large project like a GUI. I have been keeping an eye on pkgme, but I'm not sure it solves the problem. My concern with automated tools is that they tend to to work for about 75% of stuff, but there's always a substantial proportion of things that just do something a little bit odd, and the automatic tool can't handle them. So I have to understand what the automation is doing, to deal with the things it can't do for me. To give more concrete examples, we have stdeb for Python packages, and debhelper, which can guess much of the standard process of building a package (such as running 'make' or 'setup.py'). But neither can handle enough real-world cases that new packagers can use it without thinking about what's happening. I tried writing an application with Quickly a couple of months ago, and I was impressed with how well 'quickly package' (which uses pkgme) worked. But a lot of things that I'd like to see packaged aren't developed with Quickly, and I'm not confident that pkgme can do such a good job with them. Thanks, Thomas
Re: GUI tool for packaging
On 15 November 2012 15:18, Andrey Rahmatullin w...@wrar.name wrote: Bottom line: if you want to get a good package, it's not always possible to fully automate that, especially in cases of complex (and proprietary) software like that you mentioned, and so a GUI wizard can't do everything needed. I absolutely agree, but as I see it, I'm not trying to automate the process. I'm trying to make it easier for the user to manually intervene in the packaging. The wizards are just one part of that. Packaging at the moment involves an array of different data files, specialist syntax, and command line tools. There's a lot of detail which is hard to learn and remember. For example: - uscan puts upstream tarballs into ../, but svn-buildpackage expects them in ../tarballs/ - dh_make is something for the user to run, whereas dh_install is something to be run automatically by the build system. - When you make a new patch, you have to 'quilt add' any files you want to modify before you can modify them. It's easy, and annoying, to forget that. (I know about 'quilt edit', but for other reasons my $EDITOR is set to an in-terminal editor, which isn't what I prefer for modifying large code files) - To work on patches, you have the debian/ directory in amongst the upstream codebase. But having the rest of the codebase there clutters up information from the version control system. So I often end up with two copies of the packaging, and copying debian/patches/ between them. - You call pbuilder with a .dsc file, but dput with a .changes file. - In the pkg.install list, a line with a single entry works quite differently from a line with two entries To be clear, I'm not asking for solutions or workarounds to these individual issues. I'm sure there are good reasons things work the way they do - but being relatively new to this, the array of not-quite-connected tools is daunting. I think the advantage of a GUI is that it presents your options, rather than requiring you to already know them. If you realise you need to change some of upstream's code to make the package work... hey, that pane says 'patches', that sounds like the thing. If there are some examples, you can see the binary package target has an entry called 'examples'. Specifically, some of the things I have in mind: - Integration with quilt for patches. If you try to edit a source file from the GUI, you're prompted to create a patch. - A joined-up view of the intended binary packages. At present, the details of a binary package are spread out over part of the control file, and the foo.install, .docs, .examples, etc. files. - Editing copyright info without having to get the file syntax just right, look up license short names, and so on. Just enter a glob and select the license from a dropdown. - Wizards for specific things like watch files or DEP-8 tests. The key to this is that GUI wizards have a much lower barrier of entry than new command line tools - no flags to remember. - A build menu where you can select source package, local build, pbuilder or PPA, and it will take care of any preparation needed for that. Whew, that's more than I meant to write. Thanks to anyone who's read this far - I hope I've managed to give a clearer picture of what my idea involves. Thanks, Thomas
Re: GUI tool for packaging
On 14 November 2012 11:43, Jakub Wilk jw...@debian.org wrote: I don't think so, sorry. Could you expand on this at all? Do you think that packaging should be left to the experts? Or that the existing systems are easy enough for newcomers to learn? Thomas
Re: Python fdb
(Resending to the list) Hi Philippe, On 13 November 2012 12:36, Philippe Makowski pmakow...@espelida.com wrote: I never packaged any thing for Debian yet, I have to learn everything about Debian rules and tools for packaging. I'm trying to start a GUI application to simplify Debian packaging. It probably won't be ready for you to use, but I'd be interested to hear what bumps you hit as someone new to the process. Good luck! Thomas
Re: Sympy 0.7.2
Returning to the original topic: I've now svn-injected python3-sympy [1], and successfully built it in a PPA [2]. [1] http://anonscm.debian.org/viewvc/python-modules/packages/python3-sympy/ [2] https://launchpad.net/~takluyver/+archive/python3 Thanks, Thomas On 8 November 2012 13:32, Jakub Wilk jw...@debian.org wrote: * Dmitry Shachnev mity...@gmail.com, 2012-10-29, 14:47: 2. dh_sphinxdoc should handle URLs starting with a protocol name correctly (so that it won't complain about .../html/file:///usr/share/** javascript/mathjax/MathJax.js?**config=TeX-AMS_HTML-full missing) This is now fixed in svn. 3. It would be also good if dh_sphinxdoc stripped everything after ? character. Ditto. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-REQUEST@lists.**debian.orgdebian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/**20121108133234.GA1777@jwilk.**nethttp://lists.debian.org/20121108133234.ga1...@jwilk.net
GUI tool for packaging
This is an idea I've had knocking around for a while. Packaging is complex - there are lots of different tools and syntaxes you have to understand to do a good job of it - quilt, debhelper, watch files, etc. - along with specialist terminology. I know various CLI tools aim to simplify things, but not everything can be automated, and the tools end up with lots of options to learn about. The upshot is that most open source developers rely on a relatively small number of specialist packagers to do the rather esoteric work of preparing Debian packages. To get this to scale, I think we need to encourage more upstreams to provide packaging - whether it's for inclusion in Debian, or to provide .deb packages themselves, like Google Chrome, MongoDB and Dropbox do. In my opinion, the best way to do that is to build a GUI that holds the user's hand through the process of packaging, showing them the options available. It should be particularly useful for occasional packagers who don't want to remember a load of commands and options. Ultimately, I envisage a kind of packaging IDE. But the bit I picked to implement first is a wizard to create a watch file. The user can select popular sites like Github or PyPI, enter a couple of details, and a (hopefully correct) watchfile is generated. Screenshot: http://i.imgur.com/YM2LT.png Code: https://bitbucket.org/takluyver/packagebench/src I imagine wizards like this could be a large part of this tool, for tasks like Add a documentation package or Make DEP-8 tests. So, I'd like to know: - Do you think this is worth spending time on? Bear in mind it's primarily aimed at new occasional packagers, not experts who already know the tools. - Is there already anything like this? - Would you be interested in helping to develop it? Of course, this should be useful for any packages, not just Python-based ones. But I thought I'd float the idea here first, to get some feedback before I take it any further. Thanks, Thomas
Re: pyxs review
On 9 November 2012 12:44, Maykel Moya mm...@mmoya.org wrote: Even in the case of the more restrictive license applying only to debian/* work? Could you/someone elaborate a little the implications of this (link to fine documentation is welcomed)? I'm not sure if there's a Debian rule about it, but I'd consider it good etiquette, if you're adding something to a much larger work, to follow the author's lead on licensing. For instance: say you patch the code to fix a bug you notice while you're packaging. You don't forward the patch at the time, but the upstream author later sees it and wants to include it. If debian/ is under the same license, he's free to use your code and credit you. If debian/ is more restricted, he has to try to contact you to get an appropriate license. Thanks, Thomas
Re: Advise on packaging a new Python module
On 8 November 2012 14:15, Andreas Tille andr...@an3as.eu wrote: As far as I have followed this thread I have not seen an answer to this part of your mail. I admit I have no idea how to support Python 2 *and* 3 but wild-guessing from my experience with Debian tools I doubt any manual code writing would be needed. Any more detailed advise? Some manual code writing is needed, as debhelper doesn't yet know how to automatically build packages with Python 3. The best description is this wiki page: http://wiki.debian.org/Python/LibraryStyleGuide Thomas
Re: RFS: pyxdg 0.24-1
(Resending to the list - sorry) On 6 November 2012 12:36, Thomas Kluyver tho...@kluyver.me.uk wrote: On 6 November 2012 12:03, Dmitrijs Ledkovs x...@debian.org wrote: Can you add an autopkgtest that runs the upstream testsuite? I've had a go - can you have a glance at the attached patch? If it looks OK, I'll commit it. Thanks, Thomas
Re: RFS: pyxdg 0.24-1
On 6 November 2012 12:54, Dmitrijs Ledkovs x...@debian.org wrote: Looks good. Commit and I will sponsor your package. Done. Thanks, Dmitrijs. Thomas
Re: RFS: pyxdg 0.24-1
On 6 November 2012 13:18, Dmitrijs Ledkovs x...@debian.org wrote: I am thinking to upload to experimental instead of unstable. It's a few upstream releases jump and a python3 package is introduced. This makes this changes unsuitable for unstable considering that we are currently frozen and these changes are not appropriate for wheezy at this time. Is that ok with you? Or did you intend to upload into unstable? That's fine by me. I see myself primarily as the upstream here, offering the package to Debian to use as you will. In that case, I'll submit it separately to Ubuntu, as it won't be synced from experimental. Thanks for letting me know. Best wishes, Thomas
Re: Sympy 0.7.2
On 29 October 2012 04:42, Dmitry Shachnev mity...@gmail.com wrote: What was the MathJax complain about? I maybe can help you with that. dh_sphinxdoc: debian/python-sympy/usr/share/doc/python-sympy/html/ https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-fullis missing Thanks, Thomas
Re: Sympy 0.7.2
On Oct 25, 2012 6:31 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: I assume that building the binary packages from a single source package is preferred? sympy devs reckon we should use the separate release tarballs. Is that acceptable for Debian? Thomas
Re: Sympy 0.7.2
On 28 October 2012 08:47, Jakub Wilk jw...@debian.org wrote: I assume that building the binary packages from a single source package is preferred? sympy devs reckon we should use the separate release tarballs. Is that acceptable for Debian? Yes. OK. I've committed the minor changes (diff attached) to update the Python 2 package to 0.7.2. I tried to add a -docs package with the Sphinx docs, but it complained about Mathjax, so I've left it for now. If that sounds OK, could someone upload it? Also attached is the new packaging for the Python 3 version. This now calls the script isympy3. Is it OK to svn-inject this? And is python3-sympy the right name to use for the SVN directory? Thanks, Thomas sympy-0.7.2.patch Description: Binary data python3-sympy-debianpackaging.tar.gz Description: GNU Zip compressed data
Re: #! /usr/bin/python{,3} -Es
On 26 October 2012 09:19, Floris Bruynooghe f...@devork.be wrote: Several people have said they don't think this is a good idea. But why not? There is a bad effect if you don't rewrite the shebang to /usr/bin/python[3] -ES that we know of, but is there any example of where such a shebang line would cause trouble that warrants not doing this by default? Are there any situations where you might want to run a system script with modified Python environment variables? I can't think of any off the top of my head. Here's the list of environment variables: http://docs.python.org/using/cmdline.html#environment-variables Thomas -- 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/CAOvn4qjiW6VicuZnT-CdQnESXkVMc0kO4pVGCV_3vLwx=nd...@mail.gmail.com
Re: #! /usr/bin/python{,3} -Es
On 26 October 2012 11:53, Chow Loong Jin hyper...@debian.org wrote: What is the definition of system script? Any script installed via dpkg, perhaps? I wouldn't have said so - I install plenty of Python scripts from packages, like /usr/bin/ipython, that I wouldn't call system scripts. I don't think there's a robust distinction on Linux, but there's loosely a difference between system components and user applications. Thomas -- 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/CAOvn4qjjutDhApA1YVBGWY61z9NoLp=r8ctkhggw-jwdnwf...@mail.gmail.com
Re: #! /usr/bin/python{,3} -Es
On 26 October 2012 14:20, Paul Tagliamonte paul...@debian.org wrote: django-admin if I'm using a virtualenv? Perhaps I'm missing the point? Will this just break all virtualenv support? To my mind, django-admin is not a system script. A system script would be something like the unattended-upgrades script, which you wouldn't really want to be affected by virtualenvs. Thomas -- 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/caovn4qimsiet2_lwts2p1c37mjabgmi5tsxsy3ptzqgc-vy...@mail.gmail.com
Sympy 0.7.2
The attached patch is a first stab at packaging SymPy 0.7.2, which supports Python 3. There's some polishing to be done, such as adding an isympy3 script, but it at least builds. I assume that building the binary packages from a single source package is preferred? The upstream releases on Google Code and PyPI have separate py2/py3 tarballs, and they don't include the conversion script. So I've used the tarball from the github tag as the source. I also had to patch the conversion script, which assumes it's working inside a git repository. I've raised an issue upstream about this. I'm still not sure of the protocol, so I thought I'd bring it up here first. Let me know if I should commit the changes to the DPMT SVN. Thanks, Thomas sympy-0.7.2-and-py3.patch Description: Binary data
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On 2 October 2012 09:01, Nicolas Chauvat nicolas.chau...@logilab.fr wrote: PS: by the way, would anyone know of a way to use chroot or something similar to allow any user to have any number of virtual environments that use apt-get to install stuff and fall-back to the system if something is not installed in the virtualenv ? I'd be interested to see something like this, or something that would allow installing Debian packages for a single user. Is something possible with UnionFS/OverlayFS? Thomas -- 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/CAOvn4qgPKgcgwEA+5a_o27ch4go4-sKLpqG9nFv7KzhO=du...@mail.gmail.com
Re: PyCon 2013 -- anyone going? ideas for the talks?
On 21 September 2012 19:32, Paul Boddie p...@boddie.org.uk wrote: From following discussions on python-dev, I imagine that it might be interesting for people to be shown how following the basic best practices around metadata and configuration information can get you most of the way to making a half-decent package. It might also be informative if Natalia Frydrych's PyPI to Debian work were covered somehow, because that would potentially make people aware of packaging portability and that with only a little extra consideration, they could have their work conveniently available to an entire community. Thanks all, good points. Fred: in that case you should have a look to the pythonxy project Yes, that's one of several distributions we're discussing - others include EPD, Anaconda, WinPython and QSnake. Best wishes, Thomas -- 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/caovn4qgdjz3csn3bchnyy8d57cyyblzwkpbjlaqs0gpcgov...@mail.gmail.com
Re: PyCon 2013 -- anyone going? ideas for the talks?
With apologies in advance for straying off topic ;-) On 21 September 2012 14:18, Yaroslav Halchenko deb...@onerussian.com wrote: Previously I have done a similar talk with an accent on a scientific Python stack in Debian [1] which I thought was quite well accepted. We're having a big discussion on scipy-user at the moment about formalising a scientific Python stack under the name Pylab. I hope once it's defined, we'll be able to make a Debian metapackage that depends on all the relevant components. If you want to get involved in defining it, please do join the discussion on scipy-user. 2. tutorial on Debian packaging of Python modules/software That reminds me: I'm doing a talk (~ 1/2 hour) at my local Python user group on this topic, so I'd be interested to see any tutorials anyone has already prepared. I'm not sure I'm really qualified to expound on it, but I hope that I can give people some kind of mental map of what's involved. Thanks, Thomas -- 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/caovn4qigcsn3wpw7qrgbnhsyczkftue9o2-ggwvak57syda...@mail.gmail.com
Re: Xpra to publicly expose its modules
On 18 September 2012 18:00, Dmitry Smirnov only...@member.fsf.org wrote: At the moment I can't recall a good example but there are some exceptions like when package in mainly used as application. IPython is packaged as 'ipython', 'ipython3', etc., and it also includes a public module. Thomas -- 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/CAOvn4qgoh_wUN_jSG8teDoFXe3ykxFdpjTv6mh2BoyrGau_=m...@mail.gmail.com
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
Hi Nigel, On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote: The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Python 3 versions of numpy and scipy are already in wheezy. wx and matplotlib haven't yet released Python 3 compatible versions, and Wheezy is frozen now, so they've missed that boat. If you need to use those packages for a substantial application in the near future, sticking with Python 2 for now is your safest bet. If you use Python 2.6 or 2.7 with modern idioms, it should be relatively easy to port code later when all the libraries are ready. As far as I understand Debian, none of those python3- packages will be added to Squeeze. The idea of a stable release is that the only updates it gets are bugfixes and security. Looking further ahead: matplotlib is aiming to release a Python 3 version in October. wxPython has a development version working on Python 3, but I don't see any indication of how soon a release is planned. Other GUI toolkits (Qt, GTK) already support Python 3, if they are an option for you. Best wishes, Thomas -- 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/caovn4qipxjjqxswn1dwc3rcnzhc15icn8e5dyxwa18yurzo...@mail.gmail.com
Re: Please add me to the team
On 10 August 2012 11:33, Jakub Wilk jw...@debian.org wrote: I'm confused. Why do you ask _us_ if you can inject a package into Debian Med repo? I think he's checking that it's OK to get help here with some packaging that won't live in the DPMT repository. That's presumably fine, but if he's not sure, it's polite to ask. Best wishes, Thomas -- 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/caovn4qjtt_fvjp3jcrm+4bfx0qg2-vo4bb_3tpzryscxjqj...@mail.gmail.com
Re: pyxdg 0.23
Thanks Barry, On 1 August 2012 19:51, Barry Warsaw ba...@python.org wrote: - I bumped d/compat to 9 and BD on debhelper = 9 - In the d/control python-xdg and python3-xdg stanzas, I added the appropriate Python 2 or Python 3 text in the first line of Description: I've applied both of these, along with Jakub's suggestion, and committed to the team SVN repository. - I had to update gettext-support.patch (but maybe that's an Ubuntu-ism) That patch doesn't seem to be in Debian. - I also updated d/watch, but I think I used your p.f.o/~takluyver url. I'm glad you changed it to use the PyPI url instead. Yep - hopefully if the maintainership changes again, releases will still be uploaded to PyPI in the same way. Best wishes, Thomas -- 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/CAOvn4qi6q_nKgN8A2KT=3fzxxav0k8nzobx4kqkdbykytet...@mail.gmail.com
RFS: pyxdg 0.23-1
Hello, I'd like to request a sponsor to upload a new version of pyxdg. Package name: pyxdg Version : 0.23-1 Upstream Author : Sergey Kuleshov svyato...@gentoo.org; Heinrich Wendel h_wen...@cojobo.net; Thomas Kluyver tho...@kluyver.me.uk URL : http://freedesktop.org/wiki/Software/pyxdg License : LGPL-2 Section : python Changelog: pyxdg (0.23-1) unstable; urgency=low * New upstream version + Python 3 support (closes: #591017) + Test suite * Convert packaging to use dh_python2 (closes: #637154) It builds these binary packages: python-xdg - Python 2 library to access freedesktop.org standards python3-xdg - Python 3 library to access freedesktop.org standards In the DPMT SVN repository: http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/ On Debian mentors: http://mentors.debian.net/package/pyxdg Thanks, Thomas -- 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/caovn4qisy+zeasrwb0adaxo1rdxmdnueccsu09x5xlro60g...@mail.gmail.com
Re: pyxdg 0.23
On 31 July 2012 08:02, Jakub Wilk jw...@debian.org wrote: If the team is in the Maintainer field, you are invited to commit and upload stuff yourself. However, in case of big or controversial changes (*cough* #654978 *cough*) it's still a good idea to ask the human maintainer(s) first. Do these changes count as big? By the standards of packaging, it's a fairly substantial set of changes, including adding a new binary package. But it's not changing much that should affect users, just packaging a new upstream release. + rm -rf *.egg-info This looks like a no-op to me. Thanks, I'll remove that line. Are there other cases where it is needed? I got it from http://wiki.debian.org/Python/LibraryStyleGuide Best wishes, Thomas -- 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/caovn4qigrckmdlcbgwjg6bdxua_byn_yyp4a6umecfh4sfz...@mail.gmail.com
pyxdg 0.23
The attached diff updates pyxdg with a new upstream version, which includes Python 3 support (bug #591017). I'm not sure of the etiquette for doing this sort of thing. Should I contact the list (like this), directly contact the individual named as the uploader - in this case, Piotr Lewandowski - or commit the changes to the team SVN repository and then ask for review? Thanks, Thomas pyxdg_0.23-1.diff Description: Binary data
Re: RFR: python-secretstorage
On 22 June 2012 08:47, Dmitry Shachnev mity...@gmail.com wrote: There is a small test script in the tarball (I plan to add real unit-tests in the next releases), but it requires dbus and gnome-keyring daemons running, so I don't think it's possible to run it at the build time. I recently did a wrapper for the dbus desktop notifications API, which is tested with dbus and notification-daemon running. It was suggested that it wasn't necessary to run those tests, but after a bit of fiddling we got it working. You're welcome to crib from that: http://anonscm.debian.org/viewvc/python-modules/packages/python-notify2/trunk/debian/ Best wishes, Thomas -- 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/caovn4qjfzcp1cnyzag5he9v36vdbnkuatfszmsqhcsyt4nf...@mail.gmail.com
Re: RFR: python-secretstorage
On 22 June 2012 12:37, Simon McVittie s...@debian.org wrote: FYI this shouldn't be necessary on Linux if you're either under X or running dbus-daemon manually, but it's still needed on kFreeBSD and probably Hurd, even if you run dbus-daemon manually. The tests failed during an archive rebuild - that line was apparently to fix the issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674351 PYTHONS=$(PYTHON2) $(PYTHON3) xvfb-run -a debian/runtests.sh You don't need X for D-Bus if you run a dbus-daemon yourself. tools/with-session-bus.sh in src:telepathy-glib and other Telepathy packages is a relatively simple way to achieve that: run it like this: Thanks, that's good to know. Good luck getting it in as a general tool. In my case, I think notification-daemon itself requires an X server. Best wishes, Thomas -- 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/caovn4qj3xxpsfeiwayacb4vknkckkqkc2guol69+dmk50yb...@mail.gmail.com
Re: RFR: cairosvg -- SVG converter based on Cairo
On 7 June 2012 17:09, Michael Fladischer mich...@fladi.at wrote: SVG converter based on Cairo This description seems a bit ambiguous - does it convert from or to SVG? What's the format on the other end of the conversion? But perhaps this is obvious to anyone who'd want to install it. Clicking through to the website, I see it's from SVG to pdf/ps/png. Best wishes, Thomas -- 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/caovn4qhz4xacjdsiu6czsams91faggd5e69rt8x18bx90ez...@mail.gmail.com
Re: Future of python2.6 in Debian
On 6 June 2012 11:51, Toni Mueller t...@debian.org wrote: Since some time, it's Plone 4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2 even works with Python 2.7 (but 2.6 is still supported). For my own interest, what does the current version do that prevents it from working on 2.7? I thought just about anything written for 2.6 should run on 2.7. Thomas -- 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/caovn4qhne_waq82k_ut6oncdv+u-bvfu2pukz-wfzbzg6bu...@mail.gmail.com
Re: RFS: python-notify2
On 25 May 2012 15:39, Thomas Kluyver tho...@kluyver.me.uk wrote: Should I try to launch the dbus server for my tests (like I'm already launching the notification daemon), or just disable all the tests which require a running dbus server (which is all of them, at present)? I've disabled the test suite with an explanatory note in debian/rules. Could I ask someone to sponsor 0.3-2 (from SVN)? Alternatively, if there's a good way to get dbus running on the buildd, I'd be happy to re-enable the tests. I can't reproduce the failure with pbuilder or a PPA. Thanks, Thomas -- 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/CAOvn4qgWQ=GC=rssbYtzrR8hTvTDS2yXEfDVCVJr=ltqrvi...@mail.gmail.com
Re: RFS: python-notify2
On 28 May 2012 12:05, Thomas Kluyver tho...@kluyver.me.uk wrote: Alternatively, if there's a good way to get dbus running on the buildd, I'd be happy to re-enable the tests. Thanks to Jakub for a patch which should sort it out. I've applied it in svn. Thomas -- 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/caovn4qgkufo-prjmfef6sfhj4k_xe2s38vqodepzk4njnhy...@mail.gmail.com
Re: RFS: python-notify2
On 19 May 2012 19:00, Thomas Kluyver tho...@kluyver.me.uk wrote: So the most important thing for the tests is to check my interpretation of the notifications spec against an established implementation. That's simple enough for local testing (I just see a series of notifications), but doing it on a headless server was more tricky. In any case, it works now, even if it means 300 lines of code has 50MB of build-dependencies. ;-) Except it didn't work: I've just noticed that I've got a FTBFS bug, as it couldn't connect to the dbus server. It looks like this is the critical part: Setting up dbus (1.5.12-1) ... All runlevel operations denied by policy invoke-rc.d: policy-rc.d denied execution of start. Should I try to launch the dbus server for my tests (like I'm already launching the notification daemon), or just disable all the tests which require a running dbus server (which is all of them, at present)? Thanks, Thomas -- 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/caovn4qjhfhgmeco1zax+vaueeegqx5gtmjs5lq4mnusxq2j...@mail.gmail.com
Re: RFS: python-notify2
On 14 May 2012 23:27, Thomas Kluyver tho...@kluyver.me.uk wrote: - The tests: Running the tests during the build requires dbus and a notification daemon, which in turn requires an X server running. I've come up with a recipe that works in a pbuilder, but is it suitable for the autobuilders, and is there a better way to do it? I've worked out how to use xvfb-run, which makes running the tests quite a bit simpler. I've updated the package in SVN and re-uploaded to mentors. I'm still keen for someone to review or sponsor it. Thanks, Thomas -- 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/CAOvn4qjRrdOT96m0HSouGM+=hbx3nv2hoejut4zfvp0ra0r...@mail.gmail.com
Re: RFS: python-notify2
On 19 May 2012 15:20, Piotr Ożarowski pi...@debian.org wrote:
if you're not sure and package works with all Python{,3} versions
currently supported by Debian, it's OK to skip these fields
As far as I know, that's the case. The tests pass with all supported versions.
uploaded
Thanks, Piotr!
Thomas
--
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/CAOvn4qgooW7ac9DB+CMNCRJBdenUmD=kzhau6jkzal6vibe...@mail.gmail.com
Re: RFS: python-notify2
On 19 May 2012 18:19, Barry Warsaw ba...@python.org wrote: Ideally, upstream would mock these for the majority of, if not all the tests. It would be fine if there were non-unittests (i.e. integration tests) that used the real dbus, but these could be disabled for the builds. (Upstream is also me, in this case) Mocking would be valuable for testing the callback infrastructure, but apart from that, it's just a wrapper around making dbus calls. So the most important thing for the tests is to check my interpretation of the notifications spec against an established implementation. That's simple enough for local testing (I just see a series of notifications), but doing it on a headless server was more tricky. In any case, it works now, even if it means 300 lines of code has 50MB of build-dependencies. ;-) Thanks, Thomas -- 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/caovn4qhu6_ouwytajgkrifd1esr6bqsmxfbfvehjo9vpzeu...@mail.gmail.com
RFS: python-notify2
Hi all, I'd like to request sponsorship of a new package, python-notify2. This is intended as a replacement for pynotify (aka notify-python, python-notify), so it broadly copies the API from that package, although it's not a drop in replacement. Why is a replacement needed? - notify2 is compatible with Gtk 3 and Qt 4. pynotify can't even be imported in the same process as the gobject introspection bindings for Gtk 3, and its callbacks depend on the Gtk 2 event loop. - notify2 is compatible with Python 3; pynotify probably can't easily be made to support Python 3. - notify2 has useful docstrings and function signatures for introspection - Getting things wrong with pynotify can easily segfault your process. notify2 should just raise a Python exception. - notify2 is written in Python, not C, so it's shorter, more readable, and easier to maintain. A few points I'd like to ask about: - The tests: Running the tests during the build requires dbus and a notification daemon, which in turn requires an X server running. I've come up with a recipe that works in a pbuilder, but is it suitable for the autobuilders, and is there a better way to do it? - Examples: There are a handful of examples. At present, these end up in both of the binary packages, under /usr/share/doc/packagename/examples/ . I tried to put them in a separate python-notify2-docs package, but then the folder was in /usr/share/doc/python-notify2-docs, which doesn't seem right. Can I easily make a -docs package but keep the folder name python-notify2? - X-Python[3]-Version: I don't know what the minimum Python version required is. It doesn't use any new language features. Should I leave these fields out, copy them from dbus-python (the key dependency), or put the minimum I'd consider fixing things for (2.6/3.1)? Package name: python-notify2 Version : 0.3-1 Upstream Author : Thomas Kluyver tho...@kluyver.me.uk URL : http://pypi.python.org/pypi/notify2 License : BSD Section : python It builds these binary packages: python-notify2 - Desktop notifications API for Python python3-notify2 - Desktop notifications API for Python 3 In the DPMT SVN repository: http://anonscm.debian.org/viewvc/python-modules/packages/python-notify2/ On Debian mentors: http://mentors.debian.net/package/python-notify2 The ITP is #672799 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672799 Thanks for your time, Thomas -- 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/CAOvn4qhSvvgHiWLVf2toCx8Q_Lh1nbq=-JD=_kr4ew3vkn4...@mail.gmail.com
Re: Double build failures
On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote: ok. what is the relationship between 'distribute' 'packaging'? Let's see if I get all these right: distutils: basic packaging functionality, part of the Python standard library setuptools: third party module to add functionality that distutils lacked distribute: continuation of setuptools after setuptools development stopped packaging, aka distutils2: Improving on distutils but not backwards compatible, will be integrated into the standard library for Python 3.3, and might then make setuptools/distribute obsolete. Please correct me if I've got any of that wrong. Thomas -- 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/CAOvn4qiG6-kqWUh2vsHV03=6hoY9=sqy8ryo-rh2+xrvo3e...@mail.gmail.com
Re: please help with a pbuilder error on local debug.
On 4 May 2012 23:33, Tim Michelsen timmichel...@gmx-topmail.de wrote: how to solve pbuilder-satisfydepends-dummy dependencies? https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073 Looking at which packages it says aren't installable, I would guess that your pbuilder environment isn't set up to get packages from universe. For my pbuilder, I copied the .pbuilderrc file from here: https://wiki.ubuntu.com/PbuilderHowto#Multiple_pbuilders Note this line for Ubuntu (there's an equivalent for Debian): COMPONENTS=main restricted universe multiverse After you've changed the repositories a pbuilder environment sees, I think you need to run with --override-config for it to pick up the change. Or if you're unsure, you can just delete the environment tarball and create a new one. Thomas -- 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/caovn4qic9zj9wri5nfksv4ocnlrvfe6ts6y_pf3dcdcby7b...@mail.gmail.com
Re: RFS: python3-dateutil
On 18 April 2012 18:03, Jakub Wilk jw...@debian.org wrote: But anyway, I bumped timestamp in the changelog, built, signed and uploaded the package. Thanks. Thanks Jakub, and thanks for taking the time to go through all these things with me. Thomas -- 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/caovn4qhxk6ngw-dp+djxwcwysuxcxzycqkanmwdynt73jon...@mail.gmail.com
Re: RFS: python3-dateutil
On 16 April 2012 21:30, Jakub Wilk jw...@debian.org wrote: The extended description is supposed to make sense even when it's displayed alone, without the synposis. So it certainly cannot start with “It features:”. Done. I'd misunderstood the format, I thought that it was simply continuation of the field on the line Description: . Thomas -- 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/caovn4qjbsri7252nxhymqk_ehdsny9bsdgcaavr7scmzzkg...@mail.gmail.com
Re: RFS: python3-dateutil
On 14 April 2012 11:12, Jakub Wilk jw...@debian.org wrote: Could you update the latter item? Yep, done. Thomas -- 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/caovn4qi4hvyeg2dqa9qer10nxay9ennotf254rtwjhp52dm...@mail.gmail.com
Re: RFS: python3-dateutil
On 5 April 2012 11:38, Jakub Wilk jw...@debian.org wrote: Indeed, adding --check-dirname-level=0 fixes the problem for me. I've added that, and checked that it still works for me. Thanks, Thomas -- 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/CAOvn4qiGDkeeNvH_n_z3hm61iC4nvV06smxEaR9Z6U=srcq...@mail.gmail.com
Re: RFS: python3-dateutil
On 4 April 2012 22:14, Jakub Wilk jw...@debian.org wrote: Hmm, didn't help here: No bright ideas. What uscan version do you have? $ uscan --version This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1 I took a closer look at your watch file: I've followed all of your suggestions, and checked that it still works. Previously, I'd just copied the watch file from python-dateutil; evidently it wasn't as good an example as I had hoped. Thanks, Thomas -- 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/caovn4qiv6bw0syaqcgkfwi4e5zd4ajos3x+wcrblhocksyr...@mail.gmail.com
Re: RFS: python3-dateutil
On 2 April 2012 23:23, Jakub Wilk jw...@debian.org wrote: Your get-orig-source target tries to support being invoked from any directory, but this doesn't work: You're right. I've used `pwd` now instead of . and it appears to work. I was following the example here: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball Please merge changelog entries for 2.0+dfsg1-1 and 2.0-1. Done. Thomas -- 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/caovn4qhgem+yzrpgwbym2sneccbdcobdpilv4racmm9qu4x...@mail.gmail.com
Re: RFS: python3-dateutil
On 1 April 2012 10:53, Jakub Wilk jw...@debian.org wrote: Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(), instead of disabling them entirely? Please add get-orig-source target. The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz, which doesn't exist in .orig.tar anymore. All done. I seem to have locked the package out of mentors.debian.net; I'll try uploading it again tomorrow. Thomas -- 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/caovn4qiaxbcclkw832h9-rgb92h2te0tr_vd6sngxnnr2d4...@mail.gmail.com
Re: RFS: python3-dateutil
On 28 March 2012 21:10, Jakub Wilk jw...@debian.org wrote: I see that you disabled tests for zoneinfo, which I interpret as a yes answer to my question. Well, I can't see how such behaviour is useful[0], but at very least it deserves a big red warning in README.Debian. As far as I can see, the zoneinfo subpackage is used as a fallback by dateutil.tz.gettz() if it can't find the equivalent system timezone data files (the binary package has a dependency on tzdata). zoneinfo.gettz() appears to account for the possibility that its local data file doesn't exist, and returns None. I'm inclined to leave this behaviour intact in case code depends on it, although it's not how I'd design it myself. I've added a note in README.Debian pointing people to dateutil.tz.gettz(). Thomas -- 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/CAOvn4qie-yBr-novh71RXNY-_Qd=W3dz24nw2u2+nML+B_4O=g...@mail.gmail.com
Re: Numpy dh_python2
On 17 March 2012 15:00, Sandro Tosi mo...@debian.org wrote: that stuff is done and the package is uploaded: Thanks for your contribution! Great, thanks for putting in the time to finalise it. Thomas -- 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/caovn4qhbq4am5mdmrxh7wt+0zsastmo7ecr30-yghapowda...@mail.gmail.com
Re: Numpy dh_python2
On 16 March 2012 13:35, Sandro Tosi mo...@debian.org wrote: Thanks a lot for your work! I just gave it a quick look (i.e. reading the patch) and it seems that would work (at least for the packaging part). It would be also nice if you could post your patch at 601...@bugs.debian.org, so also the BTS will be notified of the available patch. Great, thanks Sandro, I'll post it to the bug. Let me know if there's anything else I should be doing with it. Best wishes, Thomas -- 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/caovn4qgpt7vg32n0po1sag39li9qgl3td+kmgors8pya_yd...@mail.gmail.com
Re: Numpy dh_python2
After some trial and error, I've got it building python3-numpy (leaving python-support in place for Python 2) - a patch is attached. I've checked that I can install and import the built package. Changes and suggestions are welcome, and I expect there are better ways to do bits of it. I'm away for the weekend, so it'll be a few days before I can work on it again. For now, I've ignored the dh_numpy and ABI/API versions, but I guess we'll want to make Py3 versions of them. Thanks, Thomas py3-numpy.patch Description: Binary data
Re: qscintilla2: package Python 3 bindings
On 14 March 2012 04:13, Scott Kitterman deb...@kitterman.com wrote: I did have to make some additional changes, such as using a policy compliant binary name in python3, as we did for PyQt4 (python3-pyqt4.qsci) and using dh_sip3 for the python3 package. You can see the details in the DPMT SVN if you want. I've been and looked, and it mostly makes sense to me. A couple of questions: Is the policy for binary package names simply to use python3- followed by the lowercased name that you'd import? You changed the packaging to build for all supported Python 3 versions, rather than only the default (although I think only 3.2 is currently supported, anyway). I'd originally had it like that, but when I looked at the PyQt4 packaging, it was only targeting the default version (py3versions -vd), so I followed suit for qscintilla. How do we decide which option to use? Thanks, Thomas
