Bug#880245: statsmodels

2019-02-13 Thread Yaroslav Halchenko
Sorry for being allow to respond... Please do what you need to do

On February 13, 2019 5:47:41 PM EST, "Rebecca N. Palmer" 
 wrote:
>On 13/02/2019 09:10, Andreas Tille wrote:
>> Any volunteer to backport the relevant changes I pushed to Git right
>now
>> to 0.8.0?
>
>I intend to try tomorrow, if the uploaders don't say anything first.
>
>> I'm actually wondering why the package did not got any removal
>> from testing warning (or did I missed something)?
>
>statsmodels is considered a key package (i.e. can't be autoremoved) 
>because of the statsmodels -> seaborn -> sphinx-gallery -> matplotlib 
>build-dependency chain.
>
>The autoremoval list (sorted by maintainer/team) is
>https://udd.debian.org/cgi-bin/autoremovals.cgi
>
>> PS: As a general note: We probably need more people dedicated to
>Debian
>> Science QA work.
>
>I guess that's sort of what I do (and if statsmodels and/or pandas were
>
>to become available, they are at least things I use).



Bug#880245: statsmodels

2019-02-13 Thread Rebecca N. Palmer

On 13/02/2019 09:10, Andreas Tille wrote:

Any volunteer to backport the relevant changes I pushed to Git right now
to 0.8.0?


I intend to try tomorrow, if the uploaders don't say anything first.


I'm actually wondering why the package did not got any removal
from testing warning (or did I missed something)?


statsmodels is considered a key package (i.e. can't be autoremoved) 
because of the statsmodels -> seaborn -> sphinx-gallery -> matplotlib 
build-dependency chain.


The autoremoval list (sorted by maintainer/team) is
https://udd.debian.org/cgi-bin/autoremovals.cgi


PS: As a general note: We probably need more people dedicated to Debian
Science QA work.


I guess that's sort of what I do (and if statsmodels and/or pandas were 
to become available, they are at least things I use).




Bug#880245: statsmodels

2019-02-13 Thread Andreas Tille
Hi Rebecca,

On Wed, Feb 13, 2019 at 08:01:27AM +, Rebecca N. Palmer wrote:
> Is the subject line a leftover, or are you actually proposing to move 0.9.0
> from experimental to unstable (which is not generally allowed in soft
> freeze)?

Yes, that's a leftover.  I just uploaded to experimental.  Its a bit sad
that official Uploaders never answered my mail from October which would
have left us a plenty of time for testing. :-(

Any volunteer to backport the relevant changes I pushed to Git right now
to 0.8.0?  I'm actually wondering why the package did not got any removal
from testing warning (or did I missed something)?
 
> The upstream fix for #880245 (the original reason given for wanting the new
> version) is supposedly
> 
> https://github.com/statsmodels/statsmodels/commit/f81cde31421288e669e859d0e798d843ca2ecabe
> 
> but I haven't tried it by itself.

I think you can not really test by yourself since the issue seemed to
occure only on the specific hardware setup the bug reporter was using.
As far as the bug log goes version 0.9.0 fixes the issue.

Kind regards

   Andreas.

PS: As a general note: We probably need more people dedicated to Debian
Science QA work.  I will definitely not do this since doing this for
Debian Med consumes all my resources.  We have to many open bugs in
Debian Science for non-leaf packages and we should find ways to address
this.  We could start with people adding themselves to Uploaders and
really care for those packages that have lots of rdepends.  Uploaders
who realised that they are not able to contribute to the package and do
relevant maintenance (like answering RC bugs in at least one month)
should drop themselves from the Uploaders field to avoid
"fake-Uploaders" (this is not only true for statsmodels- when I migrated
packages from SVN to Git I found *lots* of packages that are not
maintained by their respective Uploaders any more).

-- 
http://fam-tille.de



Bug#880245: statsmodels

2019-02-13 Thread Rebecca N. Palmer
Is the subject line a leftover, or are you actually proposing to move 
0.9.0 from experimental to unstable (which is not generally allowed in 
soft freeze)?


The upstream fix for #880245 (the original reason given for wanting the 
new version) is supposedly


https://github.com/statsmodels/statsmodels/commit/f81cde31421288e669e859d0e798d843ca2ecabe

but I haven't tried it by itself.



Bug#880245: statsmodels: FTBFS: RuntimeError: Kernel died before replying to kernel_info

2017-10-30 Thread Lucas Nussbaum
Source: statsmodels
Version: 0.8.0-6
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20171030 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/docs'
> Make static directory for images
> mkdir -p build/html/_static
> # generate the examples rst files
> Generating reST from examples folder
> #../tools/examples_rst.py
> Generating datasets from installed statsmodels.datasets
> python3 ../tools/dataset_rst.py
> /<>/.pybuild/pythonX.Y_3.6/build/statsmodels/compat/pandas.py:56:
>  FutureWarning: The pandas.core.datetools module is deprecated and will be 
> removed in a future version. Please use the pandas.tseries module instead.
>   from pandas.core import datetools
> Generating notebooks from examples/notebooks folder
> python3 ../tools/nbgenerate.py --execute=True --allow_errors=True
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
> "__main__", mod_spec)
>   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
> exec(code, run_globals)
>   File "/usr/lib/python3/dist-packages/ipykernel_launcher.py", line 16, in 
> 
> app.launch_new_instance()
>   File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
> 657, in launch_instance
> app.initialize(argv)
>   File "", line 2, in initialize
>   File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
> 87, in catch_config_error
> return method(app, *args, **kwargs)
>   File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 448, in 
> initialize
> self.init_sockets()
>   File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 251, in 
> init_sockets
> self.init_iopub(context)
>   File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 256, in 
> init_iopub
> self.iopub_port = self._bind_socket(self.iopub_socket, self.iopub_port)
>   File "/usr/lib/python3/dist-packages/ipykernel/kernelapp.py", line 180, in 
> _bind_socket
> s.bind("tcp://%s:%i" % (self.ip, port))
>   File "zmq/backend/cython/socket.pyx", line 495, in 
> zmq.backend.cython.socket.Socket.bind (zmq/backend/cython/socket.c:5662)
>   File "zmq/backend/cython/checkrc.pxd", line 25, in 
> zmq.backend.cython.checkrc._check_rc (zmq/backend/cython/socket.c:8400)
> zmq.error.ZMQError: Address already in use
> RUNNING THE L-BFGS-B CODE
> 
>* * *
> 
> Machine precision = 2.220D-16
>  N =3 M =   12
>  This problem is unconstrained.
> 
> At X0 0 variables are exactly at the bounds
> 
> At iterate0f=  4.23082D+00|proj g|=  8.41904D-04
> 
> At iterate5f=  4.23082D+00|proj g|=  2.53753D-04
> 
> At iterate   10f=  4.23080D+00|proj g|=  3.50830D-04
> 
> At iterate   15f=  4.23080D+00|proj g|=  0.0D+00
> 
>* * *
> 
> Tit   = total number of iterations
> Tnf   = total number of function evaluations
> Tnint = total number of segments explored during Cauchy searches
> Skip  = number of BFGS updates skipped
> Nact  = number of active bounds at final generalized Cauchy point
> Projg = norm of the final projected gradient
> F = final function value
> 
>* * *
> 
>NTit Tnf  Tnint  Skip  Nact ProjgF
> 3 15 18  1 0 0   0.000D+00   4.231D+00
>   F =   4.2308031360255534 
> 
> CONVERGENCE: NORM_OF_PROJECTED_GRADIENT_<=_PGTOL
> 
>  Cauchytime 0.000E+00 seconds.
>  Subspace minimization time 0.000E+00 seconds.
>  Line search   time 0.000E+00 seconds.
> 
>  Total User time 0.000E+00 seconds.
> 
> RUNNING THE L-BFGS-B CODE
> 
>* * *
> 
> Machine precision = 2.220D-16
>  N =4 M =   10
>  This problem is unconstrained.
> 
> At X0 0 variables are exactly at the bounds
> 
> At iterate0f=  4.23082D+00|proj g|=  4.24640D-03
> 
> At iterate5f=  4.23081D+00|proj g|=  4.05725D-04
> RUNNING THE L-BFGS-B CODE
> 
>* * *
> 
> Machine precision = 2.220D-16
>  N =4 M =   12
>  This problem is unconstrained.
> 
> At X0 0 variables are exactly at the bounds
> 
> At iterate0f=  4.22237D+00|proj g|=  1.77733D-03
> 
> At iterate   10f=  4.23081D+00|proj g|=  1.30108D-04
> 
> At iterate5f=  4.22236D+00|proj g|=  1.28697D-04
> 
> At iterate   15f=  4.23080D+00|proj g|=  1.31690D-03
> 
> At iterate   10f=  4.22234D+00|proj g|=  9.63318D-04
> 
>* * *
> 
> Tit   = total number of iterations
> Tnf   = total number of function evaluations
> Tnint = total number of segments explored during Cauchy searches
> Skip  = number of BFGS updates skipped
> Nact  = number of active bounds at final generalized Cauchy point
> Projg = norm of the final