Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 14:54, Scott Kitterman wrote: > It's a wiki. The resolution of your annoyance is within your grasp. I had already fixed it. Sorry if I didn't make this clear.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On Thursday, September 07, 2017 09:28:11 AM Brian May wrote: > On 2017-09-07 08:42, Scott Kitterman wrote: > > Conveniently, we already decided to switch: > > > > https://wiki.debian.org/Python/GitPackagingPQ > > It was annoying me that these instructions were missing the last steps > on how to switch the default branch to debian/master and delete the old > branch. > > These steps are very important to: > > (a) prevent confusion on which branch to use. > (b) prevent confusion on qa.debian.org, which uses the default branch to > check that the git version. > > === cut === > > ssh git.debian.org > cd "/git/python-modules/packages/$1.git" > git symbolic-ref HEAD refs/heads/debian/master > exit > > cd "$TMP" > git push origin :master > > === cut === > > I also have a script to automate the entire conversion, and assuming the > git repository is up-to-date and nobody is withholding pushes, it seems > to work well. > > /srv/home/users/bam/convert on git.debian.org I know this is excessively snarky, but it's the best I can manage late at night: It's a wiki. The resolution of your annoyance is within your grasp. Scott K
Re: Bug#729956: Forwarded upstream
On Thu, 2017-09-07 at 06:20 +0200, Andreas Tille wrote:
> Hi Diane,
>
> On Wed, Sep 06, 2017 at 02:45:14PM -0700, Diane Trout wrote:
> >
> > > 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.
> >
> > Hi,
> >
> > I saw your debian-python3 branch for statsmodels.
> >
> > The dependencies added in the package should probably be added as
> > build-dependencies. and not package dependencies.
> >
> > I believe python-zmq should be a binary dependency.
>
> Thanks for the hints.
>
> > I was trying to build it right now but I'm getting a dependency
> > error.
> >
> > libpython2.7-stdlib : Breaks: python-pandas-lib (<= 0.20.3-1) but
> > 0.20.3-1 is to be installed
>
> I also get an error in the Python 2.7 test suite so I have no idea
> where to continue with the Python3 stuff.
Was the test failures you were see 4 instances like whats shown below?
I found a match upstream at:
https://github.com/statsmodels/statsmodels/issues/3401
I've gotten failures with 2.7 and 3.6.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
runTest
self.test(*self.arg)
File
"/home/diane/src/debian/statsmodels/.pybuild/pythonX.Y_2.7/build/statsm
odels/tsa/statespace/tests/test_save.py", line 65, in test_varmax
res.save('test_save_varmax.p')
File
"/home/diane/src/debian/statsmodels/.pybuild/pythonX.Y_2.7/build/statsm
odels/base/wrapper.py", line 72, in save
save_pickle(self, fname)
File
"/home/diane/src/debian/statsmodels/.pybuild/pythonX.Y_2.7/build/statsm
odels/iolib/smpickle.py", line 15, in save_pickle
cPickle.dump(obj, fout, protocol=-1)
File "stringsource", line 2, in
statsmodels.tsa.statespace._statespace.zStatespace.__reduce_cython__
TypeError:
self._design,self._initial_state,self._initial_state_cov,self._obs,self
._obs_cov,self._obs_intercept,self._selected_state_cov,self._selection,
self._state_cov,self._state_intercept,self._transition cannot be
converted to a Python object for pickling
Request to join DPMT
Hello, I would like to join the Debian Python Modules Team. I am working on a package for django-axes and would like it to maintain it within the team. My Alioth login is jvalleroy-guest. I have read https://python-modules.alioth.debian.org/policy.html and accept it. -- James signature.asc Description: OpenPGP digital signature
Re: Bug#729956: Forwarded upstream
Hi Diane, On Wed, Sep 06, 2017 at 02:45:14PM -0700, Diane Trout wrote: > > > 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. > > Hi, > > I saw your debian-python3 branch for statsmodels. > > The dependencies added in the package should probably be added as > build-dependencies. and not package dependencies. > > I believe python-zmq should be a binary dependency. Thanks for the hints. > I was trying to build it right now but I'm getting a dependency error. > > libpython2.7-stdlib : Breaks: python-pandas-lib (<= 0.20.3-1) but > 0.20.3-1 is to be installed I also get an error in the Python 2.7 test suite so I have no idea where to continue with the Python3 stuff. > Should I see if I can get a python3 build working? and who should I > send any progress too? Keep on commiting on the debian-python3 branch (or fix everything inside the debian branch - I simply did not want to crash this ...) Please just consider me a poor uneducated guy who only intended to inspire the more skilled ones to pick up an urgent topic. :-P Kind regards Andreas. -- http://fam-tille.de
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 08:42, Scott Kitterman wrote: > Conveniently, we already decided to switch: > > https://wiki.debian.org/Python/GitPackagingPQ It was annoying me that these instructions were missing the last steps on how to switch the default branch to debian/master and delete the old branch. These steps are very important to: (a) prevent confusion on which branch to use. (b) prevent confusion on qa.debian.org, which uses the default branch to check that the git version. === cut === ssh git.debian.org cd "/git/python-modules/packages/$1.git" git symbolic-ref HEAD refs/heads/debian/master exit cd "$TMP" git push origin :master === cut === I also have a script to automate the entire conversion, and assuming the git repository is up-to-date and nobody is withholding pushes, it seems to work well. /srv/home/users/bam/convert on git.debian.org
Re: Bug#729956: Forwarded upstream
> 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. Hi, I saw your debian-python3 branch for statsmodels. The dependencies added in the package should probably be added as build-dependencies. and not package dependencies. I believe python-zmq should be a binary dependency. I was trying to build it right now but I'm getting a dependency error. libpython2.7-stdlib : Breaks: python-pandas-lib (<= 0.20.3-1) but 0.20.3-1 is to be installed Should I see if I can get a python3 build working? and who should I send any progress too? Diane
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?
Re: Bug#729956: Forwarded upstream
Hi Yuri, On Wed, Sep 06, 2017 at 10:35:57PM +0200, Yuri D'Elia wrote: > 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? Yes. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#729956: Forwarded upstream
Hi, On Wed, Sep 06, 2017 at 05:26:13PM +0200, Yuri D'Elia wrote: > On Wed, Sep 06 2017, Andreas Tille wrote: > > I opened an issue on Github > > > > https://github.com/statsmodels/statsmodels/issues/3909 > > > > requesting Python3 support. > > I concur with what was said in the issue. > This is only an issue with debian's packaging. > > I've been using a custom build of statsmodels on python3 since years > as well without problems. Great. What about sending a patch with your changes to the bug report? I've added a branch debian-python3 to 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. Kind regards Andreas. -- http://fam-tille.de
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep 2017 18:45:31 +0200): > Mathias Behrle wrote... > > > So finally I am still quite undetermined what to do to get the actual > > release of relatorio packaged[5] (it will be needed for the next release of > > Tryton). For now there is only one usage of python-magic[6], so probably > > best to patch relatorio for now to use file-magic... > > Since I doubt it's super-urgent, just wait a few weeks to see what's > going to happen. You are right. I tend to work as proactively as possible towards new Tryton releases, the next one being scheduled for 2017-10-30. So there is some time left. > In the best outcome, this issue will resolve itself within the next > weeks. Another idea was to add a compability layer in Debian, probably > by switching to PyPi and providing glue code for the users of the > file(1) version. Since to me it seems PyPi is the saner implementation, > CMIIW. Sounds interesting just in case the above proposed solution will not work. I agree that the PyPi impementation seems to be more complete. > Worst approach: Ship a code copy. Appearently kopanocore, peframe and > sqlmap already do that. You'll have to clean up afterwards, though. We will see. Thanks for your input! > Chri- "The delivery of good medica^W packaging is to do as much nothing > as possible" stoph :) Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpb1hWVXCmkW.pgp Description: Digitale Signatur von OpenPGP
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep 2017 18:24:25 +0200): > Mathias Behrle wrote... > > > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep > > 2017 19:38:56 +0200): > > > > The cleanest solution indeed was to bring both upstreams together and > > > ask them to reconcile the APIs and eventually make one of the both > > > implementations obsolete. As things happen such an attempt was started > > > two years ago but appearently never came to a result.[1] > > > > Agreed, that this would be the cleanest solution, but as you say there is > > little probability, that the two upstreams will work together to merge their > > implementations. > > Still this should be tried first. Also, I'm not that pessimistic, see > below. So let's bring the parties involved into the loop: [...] Thanks for your additional information and initiative to re-launch the merge of the two packages. This reads much better and more optimistic than what I could find until now! Crossing fingers now in the hope for the best outcome for everybody. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpKUPcfZz_lw.pgp Description: Digitale Signatur von OpenPGP
