skimage (was: Re: Bug#729956: Python 3 Statsmodels & Pandas)
On Sat, Sep 16 2017, Yuri D'Elia wrote: > Looking at python3-skimage-lib (which also requires a rebuild), it seems > that the package failed to pass some tests. > > Bug #868582 even includes a patch to update to 0.13 [and disables some > test failures]. Has anyone had a chance to look at skimage btw?
Re: Bug#729956: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote: > I was assuming it's because there's a cyclic dependency between pandas > and statsmodels (needed for pandas unit tests), and statsmodels was > also broken by the fpectl problem. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875805 > > My solution was to use build-profiles to flag the test dependency with > !nocheck Looking at python3-skimage-lib (which also requires a rebuild), it seems that the package failed to pass some tests. Bug #868582 even includes a patch to update to 0.13 [and disables some test failures].
Re: Python 3 Statsmodels & Pandas
On Sat, Sep 16 2017, Diane Trout wrote:
> python3-pandas: Pandas is not installable
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
I would have expected the rebuild of python packages affected by the
fpectl extension with a transition, but it doesn't seem to be the case?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874253
More Breaks where added to {python,python3}-stdlib itself, but there are
still packages which didn't rebuild.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On Thu, Sep 07 2017, Brian May wrote: > In general, however, when something does go badly wrong I think it will be a > lot easier to diagnose, understand, and fix with GPB PQ then with git-dpm. > git-dpm can get very messy very quickly, particularly if you forget to pull > before making changes (personally I make this mistake too frequently) or > update > to a new upstream version without using the correct git-dpm workflow - I have > seen both of these situations happen. I concur. gbp is not without issues, but as you said, gbp is easier to reason about and fix. I don't use gbp daily. In fact, I maintain or edit existing packages not as frequently as I would like, often having to re-read the documentation along the way. The fact that gbp is better documented is a big plus, even if everything else would be equal. Simplicity goes a long way for cooperative maintenance. I'm relieved gbp is now the recommended choice.
git-dpm (was Re: Bug#729956: Forwarded upstream)
On Wed, Sep 06 2017, Andreas Tille wrote: >> But just to confirm, I see that statsmodels is just using >> git-buildpackage? > > Yes. Ok, that's reassuring. I'll have a look at the packaging, since I'm already on alioth. But since DPMT is CC-ed (I normally follow via gmane), I take the occasion to say that I _really_ _REALLY_ wished the recommendation on git-dpm to be reconsidered, or at least relaxed. For a newcomer, git-dpm is overkill and underdocumented. >From an outsider, making a Debian package already looks daunting. git-dpm does not help. On the other hand, git-buildpackage is a relatively smooth progression from quilt, and it does provide some added convenience.
Re: Bug#729956: Forwarded upstream
On Wed, Sep 06 2017, Andreas Tille wrote: > Great. What about sending a patch with your changes to the bug > report? I've added a branch debian-python3 to I always built from source, not with the debian packaging. >https://anonscm.debian.org/git/debian-science/packages/statsmodels.git > > but the build failed (for other reasons). I'd willing to work on this > but I definitely need help since I'm lacking the needed Python > knowledge. Hum, I always assumed the consensus on python packages was to manage them with git-dpm, which is something I cannot digest (and has stopped me from contributing more). But just to confirm, I see that statsmodels is just using git-buildpackage?
The state of jupyter in Debian
Hi everyone, I have a general question about the state of the jupyter packages. I noticed recently that several packages started to pop-up in the experimental archive, which is great. I've been trying jupyter through anaconda a couple of times, and I'm looking forward to it. Although the actual jupyter notebook is still missing. Any particular trouble with packaging?
Bug#810543: RFS: python-bond/1.4-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-bond" * Package name: python-bond Version : 1.4-1 Upstream Author : Yuri D'Elia <wav...@thregr.org> * URL : http://www.thregr.org/~wavexx/software/python-bond/ * License : GPL-2+ Section : python It builds those binary packages: python-bond - transparent remote/recursive evaluation between Python and other languages python3-bond - transparent remote/recursive evaluation between Python and other languages To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-bond Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-bond/python-bond_1.4-1.dsc Changes since the last upload: This is my first package and upload to python-modules.
Re: Joining python-modules
On 01/01/16 15:44, Yuri D'Elia wrote: > I've read the policy from > https://python-modules.alioth.debian.org/policy.html and I accept it (in > fact, I love the idea behind collaborative maintenance, collab-maint, > and I subscribed to LowThresholdNmu as well). > > There are three python packages that I'd like to contribute, all three > from pypi: > > - https://pypi.python.org/pypi/python-bond (I'm the author) Anyone?
Re: Joining python-modules
On 01/01/16 15:44, Yuri D'Elia wrote: > I've read the policy from > https://python-modules.alioth.debian.org/policy.html and I accept it (in > fact, I love the idea behind collaborative maintenance, collab-maint, > and I subscribed to LowThresholdNmu as well). I perhaps should add that my username on alioth is wavexx-guest
Joining python-modules
Hi everyone, I recently wanted to increase my debian contributions as a prospective maintainer. I've read the policy from https://python-modules.alioth.debian.org/policy.html and I accept it (in fact, I love the idea behind collaborative maintenance, collab-maint, and I subscribed to LowThresholdNmu as well). There are three python packages that I'd like to contribute, all three from pypi: - https://pypi.python.org/pypi/python-bond (I'm the author) - https://pypi.python.org/pypi/tabview (contributor) - https://pypi.python.org/pypi/gtabview (author) I filed already an ITP for python-bond, and I was probably too trigger-happy as I created the package into collab-maint already: https://anonscm.debian.org/cgit/collab-maint/python-bond.git/ (ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809542) Only afterwards I realized that python-modules would be a better place. Conversion with p2dsc was pretty straightforward. I only added copyright, tweaked the control file with the correct build-depends, description, installed the documentation correctly. The test suite in the package is rather complex, as it depends on a whole slew of other runtimes (perl, nodejs, ssh, etc). The package is independently tested via travis, so I disabled the tests instead of adding build-depends for all of them. Could somebody review the package? I only need to tweak the changelog and fix uploaders/maintainer at this point. Thanks!
