Bug#1083083: ITP: esphome -- system to create firmwares for ESP32/ESP8266 super easy
Package: wnpp Severity: wishlist Owner: Piotr Ożarowski X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: esphome Version : 2024.9.2 Upstream Contact: ESPHome * URL : https://esphome.io * License : MIT Programming Lang: C, C++, Python Description : system to create firmwares for ESP32/ESP8266 super easy ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems
Re: Python3 modules not built for all supported Python versions
> I don't know if I'm missing an argument to dh_python3 so that it knows the > python version, or even if there's a better workaround. But perhaps pybuild better workaround is to force cmake to install into versioned dist-packages (that's what I do in distutils) as I didn't find a reliable way to read Python version/architecture/tag/etc. from .so file > should be doing this automatically between the dh_auto_install calls so that > this kind of workarounds aren't necessary. it's actually a nice idea - pybuild can check if /usr/lib/python3.X/dist-packages/ is empty and there are .so files in /usr/lib/python3/dist-packages/ and move them temporarily to /usr/lib/python3.X/dist-packages/ (it knows which interpreter is used at this point) and let dh_python3 rename them later > Piotr, is this a bug in pybuild, or am I doing something wrong? well, cmake is not really easy to work with, they provide -DPYTHON_LIBRARY:FILEPATH… but they don't use it or use completely different name… it basically is different for each library I checked (and in different official documentation versions I read, sic!)
Re: MBF proposal: python modules that fail to import
[Helmut Grohne, 2018-04-15]
> Piotr Ożarowski
>python-changelog (U)
>python-sphinx-paramlinks (U)
>python3-changelog (U)
>python3-sphinx-paramlinks (U)
These packages provide sphinx plugins and have Enhances: python{,3}-sphinx
Missing module is available after installing python{,3}-sphinx
same situation most probably also in: python3-sphinxcontrib.autoprogram,
python3-sphinxcontrib.plantuml, python3-sphinxcontrib.rubydomain,
python3-sphinxcontrib.youtube
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Bug#843325: ITP: waf -- Tool for configuring, building, and installing projects
[Walter Landry, 2016-11-08] > Doing a quick search > > curl -s > https://codesearch.debian.net/results/22044ee2fe5c4350/packages.json | jq -r > '.Packages[]' | wc -l this result is no longer available > > shows 39 packages might also benefit from a central installation of > waf. IMHO there are 39 packages out there that should be patched to use something else (or at least strongly suggest upstream to use something else and watch waf changes very carefully in each new upstream release) > Waf has had a somewhat contentious history in Debian. It was packaged > and then removed upon request by upstream. it's your time, but please feel warned > I have had a conversation with upstream (Thomas Nagy). Nagy still > opposes a generic 'waf' package, but is fine with giving it a specific > version number (e.g. waf-1.9.5). what's the benefit of having ~39 waf-version packages (with hostile upstream) over 39 packages that bundle waf? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Bug#832987: ITP: api-hour -- lightweight daemon framework to write AsyncIO based applications
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: api-hour Version : 0.8.1 Upstream Author : Eyepea Dev Team * URL : http://www.api-hour.io * License : Apache2 Programming Lang: Python Description : lightweight daemon framework to write AsyncIO based applications API Hour was created to answer the need for a simple, robust, and super-fast server-side environment to build very efficient Daemons with ease. . By default, API-Hour Starter Kit (Cookiecutter) creates for you a HTTP daemon to develop WebServices. . With API-Hour, you can quickly convert any AsyncIO server library to multi-processing daemon, ready for production. Binary package name: python3-api-hour signature.asc Description: PGP signature
Bug#832981: ITP: aiohttp-debugtoolbar -- debugtoolbar for aiohttp.web
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiohttp-debugtoolbar Version : 0.1.1 Upstream Author : Nikolay Novik * URL : https://github.com/aio-libs/aiohttp_debugtoolbar * License : Apache2 Programming Lang: Python Description : debugtoolbar for aiohttp.web aiohttp_debugtoolbar provides a debug toolbar for aiohttp.web application. Library is port of pyramid_debugtoolbar and still in early development stages. Basic functionality that has been ported: . * basic panels * intercept redirects * intercept and pretty print exception * interactive python console * show source code Binary package name: python3-aiohttp-debugtoolbar signature.asc Description: PGP signature
Bug#832978: ITP: aiohttp-mako -- mako template renderer for aiohttp.web
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiohttp-mako Version : 0.0.1 Upstream Author : Nikolay Novik * URL : https://github.com/aio-libs/aiohttp_mako/ * License : Apache2 Programming Lang: Python Description : mako template renderer for aiohttp.web Mako template renderer for aiohttp.web (asyncio HTTP server) based on aiohttp_jinja2. Library supports almost same API. signature.asc Description: PGP signature
Bug#832977: ITP: aiohttp-jinja2 -- jinja2 template renderer for aiohttp.web
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiohttp-jinja2 Version : 0.8.0 Upstream Author : Andrew Svetlov * URL : https://github.com/aio-libs/aiohttp_jinja2/ * License : Apache2 Programming Lang: Python Description : jinja2 template renderer for aiohttp.web aiohttp_jinja2 library makes it easier to integrate Jinja2 (template engine for Python) templates in aiohttp.web (asyncio HTTP server) Binary package name: python3-aiohttp-jinja2 signature.asc Description: PGP signature
Bug#832279: ITP: python-multidict -- multidict implementation (Python library)
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: python-multidict Version : 1.2.1 Upstream Author : Andrew Svetlov * URL : https://github.com/aio-libs/multidict * License : Apache 2 Programming Lang: Python Description : multidict implementation (Python library) Multidicts are useful for working with HTTP headers, URL query args etc. . HTTP Headers and URL query string require specific data structure: multidict. It behaves mostly like a dict but it can have several values for the same key. The code was extracted from aiohttp library an it's python3-aiohttp's new dependency. Binary package name: python3-multidict signature.asc Description: PGP signature
Bug#801334: ITP: pypi2deb -- PyPI to Debian converter
Package: wnpp Severity: wishlist Owner: Piotr Ożarowski * Package name: pypi2deb Version : 1.20151008 Upstream Author : Piotr Ożarowski * URL : https://github.com/p1otr/pypi2deb * License : Expat Programming Lang: Python Description : PyPI to Debian converter This package provides: * py2dsp - converts PyPI package to Debian source package * pypi2debian - converts PyPI repository to Debian repository . Features: * uses PyPI metadata * supports Python 2.X, 3.X and PyPy * guesses build dependencies * reuses existing Debian package names if already packaged in Debian * creates -doc package with Sphinx regenerated documentation * generates ITP email template * easy to customise (profiles, overrides, templates) * uses Debian tools to generate files if possible * integrates with dh-python's tools * asynchronous signature.asc Description: PGP signature
Bug#795415: ITP: aiozmq -- ZeroMQ integration with asyncio
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiozmq Version : 0.7.0 Upstream Author : Andrew Svetlov * URL : https://aiozmq.readthedocs.org/ * License : BSD Programming Lang: Python Description : ZeroMQ integration with asyncio ZeroMQ integration with asyncio (PEP 3156) . Features: * Implements create_zmq_connection() coroutine for making 0MQ connections. * Provides ZmqTransport and ZmqProtocol * Provides RPC Request-Reply, Push-Pull and Publish-Subscribe patterns for remote calls.
Bug#795414: ITP: aioredis -- asyncio (PEP 3156) Redis support
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aioredis Version : 0.2.2 Upstream Author : Alexey Popravka * URL : https://aioredis.readthedocs.org/ * License : Expat Programming Lang: Python Description : asyncio (PEP 3156) Redis support The library is intended to provide simple and clear interface to Redis based on asyncio. . Features: * Connections pool * Low-level & high-level API * hiredis parser
Bug#795413: ITP: aiopg -- PostgreSQL integration with asyncio
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiopg Version : 0.7.0 Upstream Author : Andrew Svetlov * URL : https://aiopg.readthedocs.org/ * License : BSD Programming Lang: Python Description : PostgreSQL integration with asyncio aiopg is a library for accessing a PostgreSQL_ database from the asyncio (PEP-3156/tulip) framework. It wraps asynchronous features of the Psycopg database driver.
Re: Q: why binary-log by systemd-journald is not enabled by default?
[Hideki Yamane, 2015-05-10] > On Sun, 10 May 2015 00:56:43 -0300 > Henrique de Moraes Holschuh wrote: > > And I wish it would keep /var/log/dmesg (and its rotation). That thing is > > really useful for user support when dealing with kernel and boot issues. > > Is it enough to ask users to exec "sudo journalctl"? IMO a better idea is to add them to systemd-journal group -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512111008.go2...@sar0.p1otr.com
Bug#752994: ITP: vim-ctrlp -- fuzzy file, buffer, mru, tag, etc. finder for Vim
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: vim-ctrlp Version : 1.79 Upstream Author : Kien Nguyen * URL : http://kien.github.io/ctrlp.vim/ * License : https://github.com/kien/ctrlp.vim/issues/582 Programming Lang: Vimscript Description : fuzzy file, buffer, mru, tag, etc. finder for Vim * Written in pure Vimscript for MacVim, gVim and Vim 7.0+. * Full support for Vim's regexp as search patterns. * Built-in Most Recently Used (MRU) files monitoring and search. * Built-in project's root finder. * Open multiple files at once. * Create new files and directories. * Execute Ex commands on an opening file (jump to a line, to a string or do anything). * Optional cross-sessions caching and history allow for fast initialization. * Mappings and usage conform to Vim's conventions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140628085625.29994.47529.report...@sts0.p1otr.com
Bug#735508: ITP: sphinx-paramlinks -- allows param links in Sphinx function/method descriptions to be linkable
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: sphinx-paramlinks Version : 0.2.0 Upstream Author : Michael Bayer * URL : https://bitbucket.org/zzzeek/sphinx-paramlinks * License : Expat Programming Lang: Python Description : allows param links in Sphinx function/method descriptions to be linkable Sphinx extension which allows :param: directives within Python documentation to be linkable. . Features: . * :param: directives within Sphinx function/method descriptions will be given a paragraph link so that they can be linked to externally. * a new text role :paramref: is added, which works like :meth:, :func:, etc. This package is a build dependency of sqlalchemy >= 0.9 Binary package names: python-sphinx-paramlinks, python3-sphinx-paramlinks signature.asc Description: Digital signature
Bug#735209: ITP: python-changelog -- Sphinx extension to generate changelog files
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: python-changelog Version : 0.3.4 Upstream Author : Michael Bayer * URL : https://bitbucket.org/zzzeek/changelog * License : Expat Programming Lang: Python Description : Sphinx extension to generate changelog files This package provides simple Sphinx markup to render changelog displays Example: Changelog for 1.5.6 .. changelog:: :version: 1.5.6 :released: Sun Oct 12 2008 .. change:: :tags: general :tickets: 27 Improved the frobnozzle. .. change:: :tags: rendering, tests :pullreq: 8 :changeset: a9d7cc0b56c2 Rendering tests now correctly render. signature.asc Description: Digital signature
Re: Bug#733634: ITP: gevent-socketio -- Socket.IO server based on the Gevent pywsgi server
[Benjamin Drung, 2013-12-30] > * Package name: gevent-socketio (binary: python-gevent-socketio) please follow Debian Python Policy's recommendation and use "python-socketio" as binary package name (module name is "socketio") -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140101212541.gi4...@sts0.p1otr.com
Re: wheezy postmortem re rc bugfixing
[Charles Plessy, 2013-05-09] > For a large number of packages if not all, we should allow the > package maintainers to manually migrate their packages to Testing during the > Freeze, within boundaries set on debian-devel-announce by the release team. +1 or a soft freeze (as described above) a month (or two) before hard freeze -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510125746.ga24...@p1otr.com
Re: Bug#700630: ITP: gitorious -- Git based tool for collaborating on distributed open source projects
[Andrew Shadura, 2013-02-18] > Just some info: I'm currently working on packaging Rhodecode and its > dependencies; Rhodecode supports both Git and Mercurial, which is > great. > By the way, I mostly have finished it. great! Please update 689573 accordingly (and let me know if you need sponsored upload) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130219094341.ga31...@piotro.eu
Bug#696195: ITP: python-jedi -- autocompletion tool for Python
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: python-jedi Version : 0.5~b5 Upstream Author : David Halter * URL : https://github.com/davidhalter/jedi * License : LGPL-3+ Programming Lang: Python, Vim script Description : autocompletion tool for Python Jedi is an autocompletion tool for Python. It works. With and without syntax errors. Sometimes it sucks, but that's normal in dynamic languages. But it sucks less than other tools. It understands almost all of the basic Python syntax elements including many builtins. Source package is available in DPMT repo: http://anonscm.debian.org/viewvc/python-modules/packages/python-jedi/trunk/ I will upload it once python3-defaults is uploaded to experimental (with new pybuild build system) Binary packages: python-jedi, python3-jedi, vim-python-jedi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121217220957.11957.76857.report...@vega.piotro.eu
Re: Source package names for R libraries (and Perl, Python, Java, …).
[Paul Wise, 2012-02-17] > On Thu, Feb 16, 2012 at 7:59 PM, Piotr Ożarowski wrote: > > Please don't. There are developers (like me) who prefer source package > > names to be as close as possible to upstream's name. > > As a pedantic/info level warning, you are of course free to ignore it. True. It doesn't mean lintian should suggest something that many (?) developers do not agree with (and what is not backed up by Policy) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120217103751.gl28...@piotro.eu
Re: Source package names for R libraries (and Perl, Python, Java, …).
[Paul Wise, 2012-02-16] > How about a lintian complaint at info/pedantic level called > source-package-name-doesnt-match-binary-package that triggers on > single-binary source packages and where the binary name doesnt look > like a versioned library package? Please don't. There are developers (like me) who prefer source package names to be as close as possible to upstream's name. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120216115934.gk28...@piotro.eu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
[Octavio Alvarez, 2012-01-24] > Just a note, though: the non-automatic subscription behavior of the > BTS could confuse new potential package maintainers, as they might > not subscribe to the corresponding bug (this has happened to me). Is it a bad idea to modify BTS or reportbug to automatically subscribe submitter in this case? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124101020.ga19...@piotro.eu
Re: Alioth status update, take 3
Any news about wsvn and viewvc (viewsvn)?
There are hundreds of packages that have Vcs-Browser pointing to
links like
http://svn.debian.org/{vie,}wsvn/python-modules/packages/mako/trunk/
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110601073511.gv17...@piotro.eu
Re: Sponsorship in Debian (Re: Ubuntu-originated packages in Debian (Re: ubuntu keyring?))
[Arno Töll, 2011-05-20] > I know and I provided everyone willing to sponsor me a comprehensive > change log where I explain what I did and why, altogether with a diff > outlining all changes when compared to the previous version. good, let me know when you will need an upload of something Python related :-) > All I wanted is > to outline, the current procedure seems not to work that good in > some/many(?) cases. I do not read mentors list that often anymore mostly because a lot of packages there are not even lintian clean (no to mention that most packagers didn't read docs... because they're too long and there are too many of them, "try and error" is just easier...) so when I sponsor a NEW package now, it usually comes from someone I sponsored already (see question #4 from my FAQ) or from PAPT/DPMT team member. I think debexpo could improve the situation thanks to review system (I'd love to be able to filter requests with at least X positive reviews or with a positive review from someone I trust, but who is not a DD yet or from someone I sponsored before and marked as prospective maintainer) -- http://people.debian.org/~piotr/sponsor -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110520094739.gz17...@piotro.eu
Re: Sponsorship in Debian (Re: Ubuntu-originated packages in Debian (Re: ubuntu keyring?))
[Arno Töll, 2011-05-20] > So from my experience, in reality you need to seek a new sponsor for > every upload you want to get into the archive and this takes a lot of > time and patience. For example I'm currently waiting and seeking since > over a month to get a RC bug fix and upstream update into unstable until > Asheesh signaled interest to help me recently. Did you ask your previous sponsor first? When I see a package I sponsored on mentors again - I ignore it (if sponsoree is not happy with my "service", he/she is free to try someone else after all). When I already sponsored a package, it's easier to sponsor next upload (as I can assume I checked everything previously and just check the debdiff output¹ next time) [¹] not interdif's! -- http://people.debian.org/~piotr/sponsor -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110520091058.gy17...@piotro.eu
Re: A concrete proposal for rolling implementation
[Didier Raboud, 2011-05-04] > While I agree with the demotivation stance, why can't those packages be > uploaded to experimental, fwiw ? because that's not what experimental is for and it's harder to use it (did you notice that python3.2 is in experimental or did someone gave you proper apt-pinning rule when Squeeze was frozen?) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504133210.gn17...@piotro.eu
Re: A concrete proposal for rolling implementation
[Josselin Mouette, 2011-05-04] > This would be a pseudo-suite, like experimental. Except that while > experimental is built on top of unstable and filled manually by > maintainers, rolling would be built on top of testing and filled > semi-automatically. A rolling system would have typically 2 APT lines: > one for testing and one for rolling. +1 [...] > What to do during freezes > - > I’m not sure we really need to do something different in times of > freeze. Our time would be better spent by reducing the freeze time and > making it more predictable; squeeze has been an awesome step in this > direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504132207.gm17...@piotro.eu
Re: time based freezes
[Abou Al Montacir, 2011-05-04] > On Sun, 2011-04-24 at 20:00 +, Sune Vuorela wrote: > > > On 2011-04-24, Stefano Zacchiroli wrote: > > > Dear Release Team ... good luck in proposing a freeze month now :-) > > > > I would propose mid september or mid-march. That's just after 2nd patch > > release of new set of releases by KDE. > > > And why not new gnome release, or maybe new kernel version or even any > other program packaged because I'm too lazy to send 42 mails¹ every 2 years, specially when some of recipients might start ignoring them after receiving two with different dates and most other upstreams will not get such mails at all. You can pick the release date of your favourite $foo package with popcon=0, I really don't care as long as we can put "Debian freezes on $month every $parity year" on http://www.debian.org/ and not change it for next decade or so. Upstream authors that care about Debian, will try to release new stable version on time, the ones that don't will just do what they do now and we'll deal with it the same way we handle it now. [¹] even if created as 1 mail with 41 addresses in CC ;-P -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504131453.gl17...@piotro.eu
/usr/bin/python2 again
[Barry Warsaw, 2011-04-13] > On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote: > > >I think it makes more sense to have a release or two where users can > >fall back on python2. Well there needs to be at least one > >where /usr/bin/python becomes python3 alerting users to the change and > >giving them the python2 fallback, just so they have time to be prepared > >for the permanent change. > > I do agree that we could add the python2 symlink now so that folks who want to > prepare can start changing their #! lines to use /usr/bin/python2. what's the point? /usr/bin/python2 will not work either when we'll drop support for Python 2.X. How about providing python3-foo packages as soon as possible (to make it easier to migrate) instead of wasting time on /usr/bin/python2 mess? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413171959.gj19...@piotro.eu
Re: "Python2.6 as default"
[Michael Gilbert, 2011-04-13] > Can't that be solved in the release notes when that happens? Something > like: > > python3 is now the default /usr/bin/python, so if you have existing > python2 scripts you will need to make sure to use /usr/bin/python2 > instead (or convert them to python3). IMO we can change /usr/bin/python to point to python3 once Python 2.X will no longer be supported by Debian, not sooner (as local scripts with #!/usr/bin/python shebang would stop working anyway) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413135136.gi19...@piotro.eu
Re: Python 3 as default? (Re: "Python2.6 as default")
[Adrian von Bidder, 2011-04-13] > Agreed. However, it would be interesting to track which of the bg/major > python packages/frameworks are not available on Python3 yet, if only as a > reference for the next time somebody proposes to have /usr/bin/python be a > Python 3. > > http://wiki.debian.org/Python/Python3Packages please use http://wiki.python.org/moin/PortingToPy3k/Modules instead -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110413072800.ge19...@piotro.eu
Re: time based freezes
[Stefano Zacchiroli, 2011-04-03]
> Road maps
+1
no, I cannot fix & upload (without waiting for sponsoree who has a list
of things to learn/fix) 10+ RFS packages (postponed mostly due to
packaging bugs), deal with increased number of "normal" RFS mails ("I
was working on improving the package for last few weeks, please upload
it now because the freeze will happen this week"), scan thru 500+ team
packages (to check if every transition is done or to upload new upstream
version that fixes annoying bugs or simply to clear team's RFS list /
upload UNRELEASED fixes), complete transitions (which can take some time,
even for small packages like sqlalchemy¹, not even mentioning PITA
python-defaults transitions²)... in one day/week/month (even with "soft"
freeze for the next month)
[¹] which never were announced to release managers (and never will most
probably)
[²] hint: python2.5 in Squeeze
> Strict date
+1
most of the work is done by our upstreams, and by simply telling
them "we'll freeze PICK_YOUR_MONTH every even/odd year" will (in the long
term) improve quality of Debian *a lot* more than choosing a random^Wperfect
(and different) date for every release cycle (and not announcing it to
upstream authors *at all*), IMHO
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404111533.gc28...@piotro.eu
Re: python packaging example with debhelper, dh_pysupport and dh_python2
[Thomas Bechtold, 2011-03-11]
> i tried to understand the correct way to package a python module with
> debhelper, dh_pysupport and dh_python2.
you can use either dh_pysupport or dh_python2, passing --with python2 to
dh sequencer (which you use) will disable (default) dh_pysupport
> I created a python-helloworld example package ( get it from
> https://code.launchpad.net/~toabctl/+junk/python-helloworld ) and want
> to know if i used the correct way to package a simple python module.
please also take a look at py2dsc script (from python-stdeb package)
> questions are:
> - are the package dependencies correct or do i need some more substvars?
${python:Depends} is enough
> - what exactly should do dh_python2 and do i need both, dh_pysupport
> _and_ dh_python2? i just found the manpage and [1] as dh_python2
> documentation and don't exactly understand why i need dh_python2.
dh_python2 does the same thing dh_pysupport does, but in a differen't
way, see NOTES in dh_python2 manpage¹
> - How should i install the python module if i don't have a setup.py . i
> use the debian/install file and just copy all files
> to /usr/share/pyshared/helloworld . is this correct?
both helpers will pick these files up, with dh_python2 you can also use
debian/python-helloworld.pyinstall file (I will document it in the
manpage this weekend, for now, see debian-python thread²)
PS please ask on debian-python@l.d.o next time
[¹] http://deb.li/dhp2
[²] http://lists.debian.org/debian-python/2010/11/msg00063.html
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110311095029.gj30...@piotro.eu
${python:Breaks}
[Raphael Hertzog, 2011-03-09]
> On Wed, 09 Mar 2011, Piotr Ożarowski wrote:
> > [Josselin Mouette, 2011-03-06]
> > > You might “like” Breaks, but this:
> > > Depends: python
> > > Breaks: python (>= 2.8), python (<< 2.5)
> > > has the same semantics as:
> > > Depends: python (>= 2.5), python (<< 2.8)
> >
> > Yes it does; if you will not add ${python:Breaks} in debian/control,
> > that's what dh_python2 will generate actually.
>
> Having a different behaviour depending on whether a variable is listed in
> a dependency or not does not look like good design to me.
>
> > Packages with public modules do not really care about default Python
> > version usually so why should they depend on python package¹?
> >
> > [¹] if package ships .py files, there's a dependency on python package
> > due to pycompile/pyclean scripts, but if package is providing .so files
> > only, there's no need for "python" in Depends
>
> This might be true but it smells like a useless optimization at the cost
> of abusing the Breaks field. First of because you use it like "IsBrokenBy"
> and then because Breaks is usually used to force the upgrade of the broken
> package to a non-broken version. But you're not using it that way and I'm
> not sure how well APT will cope with this.
>
> > > What is the point of doing that?
> >
> > Breaks will warn user if an upgrade of python can break some scripts with
> > /usr/bin/python in shebang, but python-foo packages can still be usable so
> > I prefer Breaks (because it's easier to override).
>
> I really don't understand your point. If the default python is not
> supported by python-foo, then it won't be coinstallable whether you're
> using Depends or Breaks...
seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
we don't have to worry about 2.X transitions when 2.7 will become the
only supported one. If you don't like Breaks, I will remove it, it
really doesn't matter - that's why at the beginning I wasn't generating
either of these dependencies (in Depends and in Breaks).
What do you want me to do? Can I drop both of them or do you want me to
drop Breaks only?
[¹] I guess I have to repeat it in my every mail, people still see
problems that will not exist in few months
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310091056.gg30...@piotro.eu
Re: Ruby changes for Wheezy
[Josselin Mouette, 2011-03-06]
> Le samedi 05 mars 2011 à 00:22 +0100, Piotr Ożarowski a écrit :
> > > Breaks: python (>= 2.8), python (<< 2.5)
> >
> > yeah, that's to avoid bug reports when someone will try to use this
> > package with (default) python 2.4 or python 2.8 (which will NEVER be
> > released, BTW). dh_python2 will create similar dependencies to those
> > generated by dh_py{central,support} if Breaks: ${python:Breaks} is
> > missing in debian/control (I like Breaks because... that's what
> > Breaks is for)
>
> You might “like” Breaks, but this:
> Depends: python
> Breaks: python (>= 2.8), python (<< 2.5)
> has the same semantics as:
> Depends: python (>= 2.5), python (<< 2.8)
Yes it does; if you will not add ${python:Breaks} in debian/control,
that's what dh_python2 will generate actually.
Packages with public modules do not really care about default Python
version usually so why should they depend on python package¹?
> except that APT deals *much* better with Depends than it does with
> Breaks.
>
> What is the point of doing that?
Breaks will warn user if an upgrade of python can break some scripts with
/usr/bin/python in shebang, but python-foo packages can still be usable so
I prefer Breaks (because it's easier to override). If APT doesn't deal
well with Breaks, please report bugs against APT (with patches if
possible :)
[¹] if package ships .py files, there's a dependency on python package
due to pycompile/pyclean scripts, but if package is providing .so files
only, there's no need for "python" in Depends
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309150221.gf30...@piotro.eu
Re: Ruby changes for Wheezy
[Adrian von Bidder, 2011-03-04]
> The way it's done is that the packages declare what versions of python they
> support:
>
> python-pygments, for example:
python-pygments uses dh_python2 which takes a little bit different
approach than dh_pycentral or dh_pysupport.
dh_python2 ships all symlinks in the .deb package, in contrast to other
two tools which create them at install time (package's or interpreter's
install time). That means if package doesn't provide extensions,
dh_pysupport and dh_pycentral packages do not need another upload if new
Python version is added to the list of supported Python versions.
All tools byte-compile these files at install time (.pyc or .pyo files
are not shipped in .debs) for all installed Python versions that are
supported by the package.
> Depends: python2.6 | python2.7 | python2.5, python (>= 2.6.6-7~)
python2.6 is first because it's the default Python version, after the
default Python version (if package supports it) all other supported
(by the .deb) Python versions are listed (from newest to oldest)
python (>= 2.6.6-7~) is here due to pycompile/pyclean scripts used in
maintainer scripts
> Breaks: python (>= 2.8), python (<< 2.5)
yeah, that's to avoid bug reports when someone will try to use this
package with (default) python 2.4 or python 2.8 (which will NEVER be
released, BTW). dh_python2 will create similar dependencies to those
generated by dh_py{central,support} if Breaks: ${python:Breaks} is
missing in debian/control (I like Breaks because... that's what
Breaks is for)
> Then, via triggers, the module is compiled to bytecode for all supported
dh_pysupport byte-compiles them via triggers, dh_pycentral and
dh_python2 byte-compile them in postinst (and remove .pyc files in
prerm)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110304232230.gv30...@piotro.eu
Re: binNMU for Arch: all packages.
[Joachim Breitner, 2011-01-26] > (I know that I’m not actually helping to solve the problem, but I want > to give a better picture of the work involved and how much the buildd > infrastructure is relied upon by the Haskell team – thanks for that!) FWIW: dh_python2 based packages would benefit from arch:all binNMUs as well (dh_python2 generates symlinks for all supported Python versions at build time instead of in preinst). That's not that big problem, though: Wheezy will most probably support Python 2.7 only which is the last Python 2.X version. Python 3.X do not have this problem anymore (thanks to Barry Warsaw's changes¹, some backported to python3.1 in Squeeze, to make Squeeze→Wheezy upgrade easy) [¹] PEP3147 and PEP3149 -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127093515.gq8...@piotro.eu
Re: Debian bugs #700000 and #1000000 contest
[Christian PERRIER, 2010-10-18] > Quoting Piotr Ożarowski (pi...@debian.org): > > Subject: Debian bugs #70 and #100 contest > > To: debian-devel-annou...@lists.debian.org > > > > seriously? Isn't debian-priv...@l.d.o for all the off-topic mails? > > > Who told this is off-topic? I already only scan -private and -devel mailing lists once a week or so (due to spam), I was expecting important information on -devel-announce so I stopped doing what I was doing (see below), opened announce mailbox and was annoyed by the fact that 2nd class DDs like me (and their upstreams!) do not deserve information about freeze date in advance but they're feed with bug contest messages instead. I can't/don't want to work on Debian 24h a day. Yesterday, I found few hours in the evening to work on Debian so I worked simultaneously on few issues related¹ to Squeeze release or not². After replying to your mail to -devel I had to fix RC bug³ (I wish all spammers would fix one RC bug after sending off-topic mail to Debian mailing list) and thus didn't finish checking python-easygui and galleryremote so if I don't want to break "24h rule"[4] again, I will have to speed up this evening as I also have to fix another RC bug due to sending yet another off-topic mail to -devel (feel free to take over[5], but please remember that NEW packages almost never[6] are ready after initial RFS mail, so if you will not find something serious, just don't try to help, unless you will work with sponsoree with further uploads as well). [¹] * jinja2 2.5.4-1 (uploaded to unstable, no unblock request yet) * cython3 (later I noticed my work is useless as Cython public module is used only by cython script which generates Python 2.X and Python 3.X compatible code, changes are in DPMT repo) * pype RFS (replied, one version uploaded later, another one on it's way) * pyopencl RFS (replied to wait for RMs for few more days) * pycompile RC bug [²] * python-easygui RFS (NEW package) * galleryremote RFS (NEW package, blocks new upstream version of another package) [³] python-defaults upload to experimental, I will backport it in 2.6.6-3squeeze1 today [4] http://people.debian.org/~piotr/sponsor [5] * svn://svn.debian.org/python-modules/packages/python-easygui/trunk * http://mentors.debian.net/debian/pool/main/g/galleryremote/galleryremote_0.4-1.dsc [6] happened like 2 times for me for now (and both sponsorees were close to get their DD account back then) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101018082931.gt3...@piotro.eu
Re: Debian bugs #700000 and #1000000 contest
Subject: Debian bugs #70 and #100 contest To: debian-devel-annou...@lists.debian.org seriously? Isn't debian-priv...@l.d.o for all the off-topic mails? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101017193113.gp3...@piotro.eu
Bug#596042: ITP: logbook -- logging replacement for Python
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: logbook Version : 0.2 Upstream Author : Armin Ronacher * URL : http://logbook.pocoo.org/ * License : BSD Programming Lang: Python Description : logging replacement for Python Simple logging library that aims to support desktop, command line and web applications alike. It can send your logs directly to database (all supported by SQLAlchemy, MongoDB), Twitter, Libnotify, syslog, file, mail, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908075119.3008.93517.report...@vega.piotro.eu
Re: call for python/pylons hackers
[Jan Dittberner, 2010-06-23] > A short update: > > I started work on debexpo yesterday and I'm almost finished porting it to > Pylons 1.0, SQLAlchemy 0.6 and the latests python-debian. I will put my work > in > a publicly accessible git repository and will improve the unit test coverage > before I start working on the open issues/new ideas. FYI: Squeeze will most probably be released with python-pylons 0.10 (1.0 is still in experimental as TurboGears2 doesn't work with 1.0). Code written for Pylons 1.0 should work with 0.10, though (1.0 is 0.10 without deprecated code). SQLAlchemy 0.6 is already in unstable (and Squeeze will be released with 0.6.x) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623083253.go18...@piotro.eu
Re: A lot of pending packages
[Jakub Wilk, 2010-06-15] > I consider QA/adoption uploads without DD assistance unacceptable. +1 -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100616071552.gw31...@piotro.eu
Bug#578093: ITP: flask -- microframework based on Werkzeug, Jinja2 and good intentios
Package: wnpp
Severity: wishlist
Owner: "Piotr Ożarowski"
* Package name: flask
Version : 0.1
Upstream Author : Armin Ronacher
* URL : http://flask.pocoo.org/
* License : BSD
Programming Lang: Python
Description : micro framework based on Werkzeug, Jinja2 and good
intentions
Flask is a micro framework for Python based on Werkzeug, Jinja 2 and
good intentions.
.
A minimal Flask application looks like that:
.
from flask import Flask
app = Flask(__name__)
.
@app.route("/")
def hello():
return "Hello World!"
.
if __name__ == '__main__':
app.run()
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100416195750.13840.51986.report...@localhost
Re: Has Debian abandoned Python?
Right now we're working on updating the Debian Python Policy. Once we'll be happy with the first set of patches, we'll send them to debian-python mailing list. I don't see a reason to make it public right now as it's simply not ready. Does it really matter that I'm not preparing it alone? If I would work on it alone would I still be obligated to make everything public? /me wonders if other Debian cabals do not realize they're a cabal as well ;-) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: Has Debian abandoned Python?
I agree that the current situation sucks. However, I've been involved in discussion with various developers on both sides (Debian and Ubuntu) that are interested in finding solutions. I'm still confident that we can reach a solution. But clearly, attacking each other like that is counter-productive. Please give us some time, and stop throwing fuel on the fire. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Bug#550353: ITP: stdeb -- Python to Debian source package conversion utility
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: stdeb Version : 0.4.1 Upstream Author : Andrew Straw * URL : http://github.com/astraw/stdeb * License : MIT Programming Lang: Python Description : Python to Debian source package conversion utility stdeb produces Debian source packages from Python packages via a new distutils command, sdist_dsc. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. An additional command, bdist_deb, creates a Debian binary package, a .deb file. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Quick analysis of the Python dist-packages transition
[Steve Langasek, 2009-09-20] > On Fri, Sep 18, 2009 at 09:18:16PM +0200, Josselin Mouette wrote: > > * 505 of these packages do not use distutils and should not be > > affected, still shipping files to site-packages/. However, > > according to Scott Kimmermann (who handled parts of this > > transition in Ubuntu), python-central does not look for modules > > in /usr/lib/python2.6/site-packages, so most modules using it > > are broken. > > What do you mean, "look for" modules there? Are you proposing that these > packages ship files under /usr/lib/python2.6/site-packages, or that > python-central find modules under this directory at build-time and move them > to /usr/lib/python2.6/dist-packages? no, move them to /usr/share/pyshared, just like it does with dist-packages > There is no bug filed against python-central for this. I will file a bug in a minute (not that it will change much) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Piotrek's new preferred helper tool - (unfair) decision
[Piotr Ożarowski, 2009-02-18] > [...] it's time however to decide which one will be my > winner - I'll decide that in next weeks (maybe months, but it > will happen sooner than later Since nobody is interested in having the tools binary compatible[1] (and, to be honest, I cared about opinion of two guys only: Matthias voted "no" by not agreeing to use /usr/lib/pyshared and Joss expressed his disapproval on #debian-python) - I choose python-support to be my preferred tool (no, not the "winner", I only wanted to provoke you both to make a consensus and thus not let me decide about anything). I'm not saying one of them is better than the other (although I was more a pycentral guy, Ana knows something about it[2]) - I'm saying I have more influence on how the tool looks like (f.e. via reporting bugs) and changes are more predictable in pysupport. You can now prove me how wrong decision I made but... I don't care ;-P I propose to file bugs against python-support instead (Joss will talk you to death if it's not really a bug ;-) Anyway, as promised: I will convert all my python-central based packages to python-support soon, will *not* sponsor python-central based package anymore (except packages for Lenny) - my FAQ is already updated, and will try to convince other DDs to do the same. PS while converting, remember to add to preinst something like these 3 lines: | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2.3-4; then | pycentral pkgremove python-foo | fi [1] http://lists.debian.org/debian-python/2009/02/msg00099.html [2] ups, I did it again, sorry Ana -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpZ8lkLIH5pV.pgp Description: PGP signature
Re: Python related changes for unstable/squeeze
[Piotr Ożarowski, 2009-02-18]
> that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
> /usr/share/py{,3}shared but for Python extensions, sorry if I sounded
> differently
and by that I mean /usr/lib/py{3,}shared/python2.5,
/usr/lib/py{3,}shared/python2.6 and so on (including .py files that are
not suitable for /usr/share/py{3,}shared)
/me really goes to bed
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp6J6MzkDwaR.pgp
Description: PGP signature
Re: Python related changes for unstable/squeeze
[Josselin Mouette, 2009-02-18]
> Le mercredi 18 février 2009 à 01:20 +0100, Piotr Ożarowski a écrit :
> > > where is the advantage of having a /usr/lib/pyshared?
> >
> > it's one of the "sacrifices" you'll have to make if you want
> > /usr/share/py{,3}shared to be used by other tool(s). I see no way to use
> > Python's official path in pysupport in its current design.
> > Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
> > probably the worst of it's bugs, but maintainer is aware of this and
> > will most probably fix it during the move to
> > /usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
> > he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
> > convince him, leave it to me ;)
>
> It seems that there is one thing you got wrong here. /usr/lib/pyshared
> will be for C extensions and data that varies from a Python version to
> another (like /usr/lib/python-support/$package currently). It is not the
> place where the symlinks and byte-compiled files will land after running
> the script.
that's exactly what I meant, /usr/lib/py{3,}shared will be equivalent of
/usr/share/py{,3}shared but for Python extensions, sorry if I sounded
differently
> Actually, it’s just that the supported list in python-support is
> maintained separately from that of python-defaults. The reason is that
> the pyversions script cannot be reliably used from maintainer scripts.
> See #396840 for part of the explanation.
oh, w wishlist bug then maybe (to be able to add local version, like
python2.6)
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpkTVUJuUZa3.pgp
Description: PGP signature
Re: Python related changes for unstable/squeeze
[Matthias Klose, 2009-02-16]
> Piotr Ożarowski schrieb:
> >> - 2.5 is superseded by 2.6; currently there doesn't seem to be
> >>a reason to ship 2.5 and modules for 2.5 with the next stable
> >>release. The upstream 2.5 maintainance branch doesn't see bug
> >>fixes anymore, only security releases will be made from this
> >>branch.
> >
> > What about a smooth upgrade path for those who use Python2.5 for their (3rd
> > party) applications? I think Python 2.6 should be default in Squeeze and
> > Python
> > 2.4&2.5 in supported.
FTR: I meant "2.5" in supported and "2.4" in "semi-supported" (as in only
Zope related modules should be supported for this version)
> always having the default version of the stable release included in the next
> release would mean that Debian releases keep up with Python release, or we
> would
> end up shipping more than two 2.x versions. Same if 2.7 gets released in time.
what if administrators will install some local applications that will
have python2.5 hardcoded in shebang? Do you want to provide
python2.5->python2.6 symlink? I'm not sure it's a good idea. Are you
sure Python 2.6 (and all modules/extensions) are 2.5-compatible? Or do
you simply want to add an instruction in release notes what to do in
such situation (but then again: are you sure 2.6 and 2.5 are compatible?)
> /usr/local/lib/pythonX.Y/site-packages will only be used if you install your
> own python, and use this interpreter to call setup.py install. When using the
> python (>= 2.6) provided by Debian without to call setup.oy install
> --install-layout=deb, the installation will go to
> /usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to
> /usr/lib/pythonX.Y/dist-packages.
/usr/local/lib/pythonX.Y/site-packages should definitely *not* be
symlinked to /usr/local/lib/pythonX.Y/dist-packages then (and vice versa)
> > I really like the idea of using the same location for both tools, please
> > note
> > that you'll have to change pycentral to use something like /usr/lib/pyshared
> > (for Python extensions)
>
> where is the advantage of having a /usr/lib/pyshared?
it's one of the "sacrifices" you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.
Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me ;)
Once we'll agree on the paths, I will rise another problem I want to
discuss before we'll start converting packages but lets leave it for
later (note that I don't want to merge both tools, it's not possible, I
want a situation where one helper can Conflict&Provide the other one -
yeah, you'll say "it's not possible! You're crazy!" - we'll see about
that :-)
Oh, one more thing: for now, I'm using both helper tools (to be aware of
their advantages/disadvantages and to be able to help my sponsorees -
please note that I never forced my sponsoree to use one of the helpers -
see FAQ#2 [1]), it's time however to decide which one will be my
winner - I'll decide that in next weeks (maybe months, but it
will happen sooner than later - my packages in Squeeze will use one
helper only!) and once I decide that, I will force all my sponsorees to
choose the same one (by refusing to upload package that uses the other
one)
IMNSHO
[placeholder for all those who want to make jokes about what I wrote in
next few lines - feel free to also make fun of me on #debian-python - at
least I will feel a little bit better after writing so many immodest
stuff ;]
If you care how many packages are using your tool, my preference should
matter to you as I'm the one who sponsored more Python related Debian
packages than anyone else in Debian - right now no one else has more
sponsored packages on QA page than I do (Anibal listed first on this[2]
page has less sponsored packages) and besides Sandro and Bernd, I'm the
only one who does regular sponsoring in PAPT and DPMT (which are
becoming more popular every day, there are rumors about magic way to get
a Python related package very well reviewed and really fast sponsored in
Debian even on #ubuntu-motu and people are prefering to do this via
Debian, really!) - I will also try to convince Bernd, Sandro and few
other DDs (Ana: that includes you! :) to use the same helper.
anyway, my army[3] and I can make a difference when it com
Re: Python related changes for unstable/squeeze
t; on upstream software. To avoid these problems in the future, exactly > one location for public python modules shold be used. yes, that's a problem, but I think we should do it step by step, first: all packages should ship .py and .so files in the same directories (so that dpkg can handle conflicts again), then we'll think about using common entry in sys.path (and/or merging helper tools or making it possible to choose one of them to do all the stuff) > Avoid runtime dependencies on python packaging helpers > -- > > During upgrades or distribution upgrades, public python modules are > not available for use, or they may be in an inconsistent state. This > is the time between removal of old version / unpacking new version and > the postinst configuration, when the python packaging helpers are run > and the public modules made available in sys.path. There are > currently work arounds implemented to shorten the window of > unavailability: > > - Not removing symlinked files and not removing byte-compiled files >during upgrades. This only works reliable if the new version >does neither remove nor add files, or else an inconsistent set of >files in a package may be imported during an upgrade. > > - Already create the symlinked files in the preinst step, because >the time between running the preinst and unpacking the new version >is much shorter. > > Ideally I would like to see public python modules available after > unpack without the help of any helper application. This is possible > by creating the symlinks while creating the package and including > these in the package instead of creating these at installation time. > The only configuration needed at installation time would be > byte-compilation. > > The advantage would be a more robust upgrade path. > > The disadvantage of this approach is the limitation to a specific set > of python versions (the package will have a dependency of the form > "python (<< X.Y)", which we already have for architecture dependent > packages containing extensions. This would add this kind of > dependency to all architecture independent python-* modules and then > requires an upload of these packages for each python transition as > well. Afaics this would not affect a transition or a set of > transitions to testing, because no new dependencies on new versions of > shared libraries are introduced during these uploads. This approach > certainly has an impact on the ftp archive and its mirrors, but I > can't say if this would be an issue or not. I don't like python (<< X.Y) dependencies, it's so... old-policy like. Not a good idea, IMHO > > If this cannot be done for all packages, this should be done for a > subset of "core" modules and extensions. > > There is still the issue of handling name space packages based on > setuptools. Ideally existing techniques like diversions should be used > for this, even if it looks loke overkill to divert the same empty > __init__.py file. > > > Various > --- > > There are other things which may be worth a look. > > - The current policy advises packages to byte-compile only the >files which a package owns itself. This is not done by several >packages, with the result that an upgrade caused by a byte- >compilation error may be attributed to the wrong package (makes >the upgrade of an otherwise fine package fail). > > - The removal of a python version will cause the need for massive >rebuilds. because many python extensions currently have >dependencies of the form pythonX.Y-foo. There is nothing what > can be done now for the upcoming removal, but those dependencies >should not be there by default. This is 2.4 of the python policy, >but many packages tend to ignore that. python-support supports namespace packages and it does it good. I didn't want it to be enabled by default but since Joss provided a way to disable it (see #459468) I think it's OK. python-central should implement the same behaviour, IMHO > > > I will start uploading python2.6 and related packages, then proceed > with python3.x in the next weeks. > > Matthias Just one more issue: what about "current" issue? Although I protested when others wanted to remove it, now I agree it's useless. All packages that depend on it (Python applications mostly) should use private directories and thus not pollute the global namespace (we should add this to the Python policy, IMO) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpNXB1YPoP6L.pgp Description: PGP signature
Bug#509751: ITP: zine -- Python powered blog engine
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: zine Version : 0.1.1 Upstream Author : Armin Ronacher * URL : http://zine.pocoo.org/ * License : BSD Programming Lang: Python Description : Python powered blog engine Zine is an Open Source personal publishing platform written in Python. It's written with security and extensibility in mind and inherits many ideas of WordPress and other existing blogging systems. . Zine's features: * basic blog functionality: posting, comments, categories, tags, and ATOM feeds * user, group and permission management * theming support * importers for WordPress and blogger.com blogs as well as Atom feeds. * an advanced plugin system * a translatable interface * pingback support -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506947: ITP: python-webtest -- wraps any WSGI application and makes it easy to test
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" <[EMAIL PROTECTED]> * Package name: python-webtest Version : 1.1 Upstream Author : Ian Bicking <[EMAIL PROTECTED]> * URL : http://pypi.python.org/pypi/WebTest * License : MIT Programming Lang: Python Description : wraps any WSGI application and makes it easy to test WebTest helps you test your WSGI-based web applications. This can be any application that has a WSGI (Web Server Gateway Interface) interface, including an application written in a framework that supports WSGI (which includes most actively developed Python web frameworks – almost anything that even nominally supports WSGI should be testable). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459320: ITP: buildutils -- Distutils extensions for developing Python libraries and applications
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" <[EMAIL PROTECTED]> * Package name: buildutils Version : 0.3 Upstream Author : Ian Bicking, Ryan Tomayko <[EMAIL PROTECTED]> * URL : http://buildutils.lesscode.org/ * License : MIT Programming Lang: Python Description : Distutils extensions for developing Python libraries and applications. Python Build Utilities (buildutils) is a set of extension commands to Python's standard distutils that are often useful during development and deployment of python projects. buildutils was created with the desire of removing make and other external build tools from the python development process. . Because buildutils is integrated with distutils, information about a project can be obtained from the project's setup.py and setup.cfg files. This allows commands to provide smart defaults when invoking external tools and utilities. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging python modules with .so files?
[martin f krafft, 14.03.2007]
> As you can see, it installs compiled .so files, making the package
> dependent on the python ABI, 2.4 in this case.
>
> How am I to deal with packages like this?
Make sure that you build .so for all supported python versions
(`pyversions -s`) and let py{support,central} handle the rest
if you choose pycentral, read this:
http://python-modules.alioth.debian.org/python-central_howto.txt
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpYIoR7TG2SW.pgp
Description: PGP signature
