Re: Request to join DPMT
Hi again, On Wed, Jun 24, 2020 at 11:27 AM Michael Hanke wrote: > I would like to join DPMT, specifically to provide a Debian package for > annexremote (https://bugs.debian.org/963593). The package is ready. Would it be acceptable, if I upload it to NEW with ``` Maintainer: Debian Python Modules Team Uploaders: Michael Hanke ``` even though my request to join the team has not been approved yet? For interested parties: the package is hosted on Github for the moment: https://github.com/mih/debian-annexremote Cheers, Michael
Request to join DPMT
Hi, I would like to join DPMT, specifically to provide a Debian package for annexremote (https://bugs.debian.org/963593). My salsa login is 'mih'. I have read and accept the policy document at https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thanks in advance, Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Re: may be a logo?
On Sep 14, 2011 9:41 PM, Yaroslav Halchenko deb...@onerussian.com wrote: What would be your choice among the following 6: http://www.onerussian.com/tmp/pydebian-red_tuned/ My favorite is 2. Michael
More info and interest
Hi, [cross posting to debian-science and debian-python] I want to draw you attention to an RFP that might deserve more attention: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515319 It is concerned with a Matlab-to-Python converter. The project aims to aid the conversion of Matlab code to Python. While this software seems to be in a rather early stage of development it has nevertheless the potential to become a mighty tool to facilitate the migration of an unestimable amount of Matlab code to a free language/computing environment and hence a global migration toward the use of free software. These guys published a paper about their compiler in the journal 'Frontier in Neuroinformatics' (open-access as it should be ;) http://www.frontiersin.org/neuroinformatics/paper/10.3389/neuro.11/005.2009/ According to the journals access statistics it receives an impressive amount of attention. It would really cool to have that beast in the flagship of free software (which is Debian for those who wonder ;). Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Frozen unstable (was: please test the numpy package)
On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? I'd be also very interested about this information -- which seems to be common sense -- but I cannot see the necessity as well. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Frozen unstable (was: please test the numpy package)
On Fri, Feb 06, 2009 at 07:50:36AM +0100, Steve Langasek wrote: On Fri, Feb 06, 2009 at 07:24:47AM +0100, Michael Hanke wrote: On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? I'd be also very interested about this information -- which seems to be common sense -- but I cannot see the necessity as well. It's not necessary to freeze unstable when preparing to release testing; this is a significant reason why testing exists as a separate suite. So in fact, unstable is *not* frozen. It is recommended to treat unstable as frozen for libraries, because uploads of such central packages to unstable makes it more onerous to get fixes to other packages depending on those libraries into testing via the normal route; but I'm of the opinion that the pendulum has swung too far the other direction for lenny, with maintainers uploading leaf packages to experimental instead of to unstable for freeze reasons, when the probability of an upload to unstable causing more work for the lenny release is infinitesimal. Thanks a lot for your clarifications. (I understand that the current discussion is about a case of a package with a lot of reverse-dependencies; so I don't disagree with the conclusion to avoid an upload to unstable for now.) Wrt to lenny, we are talking about two reverse dependent packages. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Mon, Jan 26, 2009 at 08:15:47AM +0100, Adeodato Simó wrote: * Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django Thanks a lot! This is exactly what I suspected. None of those packages has RC-bugs, hence no reason to allow for a transition to testing. Moreover, I promise that pymvpa will not attempt such thing ;-) On sid there are a few more: jinja2 matplotlib mpmath pymvpa python-django python-django-treebeard python-pysqlite2 python-tempita python-webob rpy2 webtest Even for those there is no RC bug (although none of them will be part of lenny anyway). Given these facts, I'd very much appreciate an upload of latest sphinx to unstable -- making complicated experiments with numpy's (and other docs) obsolete. Thanks in advance. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Mon, Jan 26, 2009 at 10:47:02AM +0100, Piotr Ożarowski wrote: [Michael Hanke, 2009-01-26] On Mon, Jan 26, 2009 at 08:15:47AM +0100, Adeodato Simó wrote: * Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django Thanks a lot! This is exactly what I suspected. None of those packages has RC-bugs, Are you sure? It doesn't have reported RC bugs, yes ;-P ;-) This is of course always implied. hence no reason to allow for a transition to testing. Moreover, I promise that pymvpa will not attempt such thing ;-) What about Sphinx 0.4.3? Does it mean we will not try to unblock it? Sphinx 0.4.3 is the classic example: It causes more trouble than it fixed. For example try building pymvpa's docs with it -- it completely fails since sphinx 0.4.3 is not able to find any figures. It works with lenny's version and 0.5 though... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502397#15 Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Sun, Jan 25, 2009 at 10:47:06PM +0100, Piotr Ożarowski wrote: [Michael Hanke, 2009-01-25] To me the question is: Why is sphinx 0.5 in experimental not unstable? This issue does not only affect numpy, as sphinx 0.4.3 has some problems which prevent successful building of docs (e.g. image/figure handling bug) -- and at least this one is solved in 0.5. if you will help me convince release managers to unblock it, I will upload 0.5 to unstable (if Mikhail will not protest). I cannot think of any argument in favor of sphinx transitioning from unstable/experimental to testing. At the same time, I have a hard time seeing the need for a full blown unstabletesting transition for a package that aims to become part of lenny (i.e. preventing a direct upload to testing-proposed-updates). I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
