Re: Bug#936604: getmail: Python2 removal in sid/bullseye
On 2019-11-14 00:24:15, Osamu Aoki wrote: > On Wed, Nov 13, 2019 at 03:31:04PM +0100, Iustin Pop wrote: > > On 2019-11-13 15:06:54, Thomas Goirand wrote: > > > On 11/12/19 4:37 PM, Osamu Aoki wrote: > > > > The related binary packages are available in 2 binary names (depending > > > > on release) > > > > getmail4 (version=4,5) popcon installed ~2000 > > > > getmail (version=3,5) popcon installed ~1000 > > > > > > > > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1 > > > > > > > > I think this qualifies for "py2keep". > > > > > > IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail, > > > which is still available in Debian (and with 4 times the number of > > > installed package in popcon...). So I see no reason to keep getmail > > > then. Maybe tell this to upstream, and they may think another time. > > > > Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK) > > the only tool that works for gmail with ASPs disabled (i.e. with OAUTH). > > > > Heck, I'd be very willing to maintain Py3 patches myself, because I need > > this tool. > > Please take over packaging from me then. You are welcome. I would gladly help with co-maintenance, but taking over packaging would be my least preferred option. Thanksfully, it seems the upstream is willing to move to Python 3, so I think situation is pretty good, actually. thank you!
Re: getmail: Python2 removal in sid/bullseye
On 2019-11-13 15:06:54, Thomas Goirand wrote: > On 11/12/19 4:37 PM, Osamu Aoki wrote: > > The related binary packages are available in 2 binary names (depending on > > release) > > getmail4 (version=4,5) popcon installed ~2000 > > getmail (version=3,5) popcon installed ~1000 > > > > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1 > > > > I think this qualifies for "py2keep". > > IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail, > which is still available in Debian (and with 4 times the number of > installed package in popcon...). So I see no reason to keep getmail > then. Maybe tell this to upstream, and they may think another time. Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK) the only tool that works for gmail with ASPs disabled (i.e. with OAUTH). Heck, I'd be very willing to maintain Py3 patches myself, because I need this tool. regards, iustin
Re: python debug packages
On 2016-04-22 19:36:12, Matthias Klose wrote: > On 22.04.2016 16:58, Jean-Michel Vourgère wrote: > > Hi > > > > Now that debug symbols are automatically generated in -dbgsym packages, > > how do you handle the debug > > /usr/lib/python2.7/dist-packages/.x86_64-linux-gnu_d.so files? > > > > They used to go in a generic -dbg package. […] > > - Do not migrate to new style -dbgsym packages and keep everything in > > rrtool-dbg, like it is now. > > that would be my preferred solution. Reading https://wiki.debian.org/Python/LibraryStyleGuide#Building_python_-dbg_packages, there is some hints to this, but it's not clear that only automatic debug packages work for Python packages. Would it make sense to update the wiki page and say "don't migrate to dbgsym packages as Python needs debug extensions and not only debug symbols"? thanks, iustin
Re: guidelines for sphinx based documentation?
On Wed, May 23, 2012 at 11:02:30PM +0200, Tim Michelsen wrote: > Hello, > is there any recipe/snippet for how to install or treat a sphinx > based python package documentation in debian/rules? Hi, Have you looked at dh_sphinxdoc? regards, iustin -- 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/20120523213424.gd14...@teal.hq.k1024.org
Re: Documenting Python Debuntuisms
On Wed, Jul 14, 2010 at 10:56:02AM +0100, Suno Ano wrote: > > Barry> We had a report in upstream Python from a user who was trying to > Barry> find information about dist-packages. He did a Google search and > Barry> didn't find any definitive official explanation of this > Barry> Debuntuism. His suggestion was to add a note to the official > Barry> Python documentation, but that doesn't seem quite right to me. > > Yes, that is a common question people have when they want to know how > exactly things are handled in Debian. It was the same for me so I > created > > http://www.markus-gattol.name/ws/python.html#why_has_debian_dist-packages_directories ... which says: "Summary, if using python ≥ 2.6: apt-installed packages go in dist-packages, and manually installed modules go in dist-packages". So it's the same situation as in 2.5, but just s/site/dist/? I mean, nothing changed? I don't know if that page is wrong, or the python is wrong, but the situation seems just a name change, and not actually a split of apt- and manually-installed packages in two different dirs... regards, iustin -- 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/20100714113153.ga15...@teal.hq.k1024.org
Re: How do I know if my package is 'arch-all' or 'arch-any'?
On Tue, Dec 29, 2009 at 11:38:11PM +0200, anatoly techtonik wrote: > On Tue, Dec 29, 2009 at 11:01 PM, W. Martin Borgert > wrote: > > Quoting "anatoly techtonik" : > >> > >> python-support README [1] contains different instructions for > >> 'arch-all' and 'arch-any' packaged. How do I know which one is mine? > > > > all: Package works on all architectures without (re-) compilation, > > e.g. a program written in Python > > > > any: Package needs e.g. compilation, but will work on any > > architecture, e.g. a library for Python, but written in C > > Thanks! How about updating python-support README with these comments? > Something makes me think that most Python people who are the primary > readers of this text don't really know what is "arch-all" or > "arch-any". People who are creating/maintaining packages should start by reading the general packaging documentation, which explains these. > > HTH! > > > > PS: debian-mentors is probably the best list for questions, that > > are not directly related to Python. > > You can't say it is not related to Python! And subscribing to yet > another mailing list is painful unless it is a Google Group. With all due respect, these are basic packaging terms that are not Python specific at all. regards, iustin -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Request for help to convert the lyx package
On Wed, Aug 02, 2006 at 08:02:05PM +0200, Pierre Habouzit wrote: > Le mer 2 août 2006 19:51, Iustin Pop a écrit : > > On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > > > and the pyo and pyc files are generated by your build process. you > > > have to remove them manually, e.g. using some find -name '*.pyo' > > > mantra. > > > > The (old) dh_python did remove the .pyc and .pyo files at package > > build time, so one did not have to bother with their removal. Are the > > new fancy tools not doing this (asks a developer still not up-to-date > > with the new python policy)? > > looking at dh_python source, bumping PYCOMPAT to 2 does not changes that > part of its behaviour. > > though, even for the lyx-common in the archive there is .pyo/.pyc > in /usr/share/lyx/lyx2lyx/ (wich in itself is quite bad). Ah, then that must be it - it must be invoked as: dh_python /usr/share/lyx/lyx2lyx in order for it to scan other dirs and generate the correct postinstall/prerm. Iustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for help to convert the lyx package
On Wed, Aug 02, 2006 at 07:42:40PM +0200, Pierre Habouzit wrote: > and the pyo and pyc files are generated by your build process. you have > to remove them manually, e.g. using some find -name '*.pyo' mantra. The (old) dh_python did remove the .pyc and .pyo files at package build time, so one did not have to bother with their removal. Are the new fancy tools not doing this (asks a developer still not up-to-date with the new python policy)? Thanks, Iustin Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
On Sun, Apr 09, 2006 at 08:16:07PM +0200, Pierre Habouzit wrote: > ok, done. > > I'd also like to alert debian-python about #351149 and #351150. Those > were fixed in a quite short period, but Lustin did not found any > sponsor. I don't know how hard he searched, but at least his packages > looked clean and well followed. He deserves better ;) It could be true that I didn't look very hard - I moved to a different country in the last month and I didn't really settle down, so to speak, as to be able to pursue this as it should have been. > maybe someone from debian-python can step up as a sponsor ? I offered > him to do so, but I'm not *that* python interested, and someone more > involved with python would surely be better. That would be great, indeed. Thanks, Iustin Pop signature.asc Description: Digital signature
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote: > I've already re-built these two packages, removing 2.1 and 2.2 support > and adding 2.4. However, I've been unable to find a sponsor. Thanks everyone for the suggestions. Will update the bug reports later today with the relevant information. Thanks, Iustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.1/2.2 removal; Python 2.4 as default
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote: > python-pylibacl has an unsatisfied build-dependency: python2.2-dev > python-pyxattr has an unsatisfied build-dependency: python2.2-dev I've already re-built these two packages, removing 2.1 and 2.2 support and adding 2.4. However, I've been unable to find a sponsor. Regards, Iustin Pop signature.asc Description: Digital signature
