Re: shiny-server in debian

[Eric Brown]

Hi Nilesh et al.,

(Sorry Nilesh for the duplicate emails, I sent some to you alone accidentally).

Good news, I finally figured it out. It's an issue with the updated
version of node-sockjs-client (1.6.0). The 1.5.2 version that upstream
uses seems to work.

So to summarize, after installing these are the changes made to get
shiny-server working:

sudo apt install node-sockjs-client
sudo mkdir /usr/lib/shiny-server/node_modules
sudo ln -s /usr/share/nodejs/sockjs-client/ /usr/lib/shiny-server/node_modules/
sudo ln -s /usr/share/nodejs/shiny-server-client/
/usr/lib/shiny-server/node_modules/
sudo cp /usr/lib/shiny-server/node_modules/sockjs-client/dist/sockjs.min.js
/usr/lib/shiny-server/node_modules/sockjs-client/dist/sockjs.min.js.backup
sudo curl 
https://raw.githubusercontent.com/jcheng5/sockjs-client/main/dist/sockjs.min.js
-o /usr/lib/shiny-server/node_modules/sockjs-client/dist/sockjs.min.js

However, note that one of my apps did not work properly until I
updated the R package shiny in R (to 1.7.1) which is newer than the
current debian package (1.5), so we should likely update r-cran-shiny
when shiny-server gets uploaded.

And to use the examples:

sudo mkdir /srv/shiny-server
sudo ln -s -r /usr/lib/shiny-server/samples/* /srv/shiny-server

And to enable logging:

The shiny-server.service file is missing the instruction to log.
Compare the line [1] in our version vs. [2] in version included in the
upstream repo. When [1] is replaced with [3] and the file
/var/log/shiny-server.log is created, logging works properly. Probably
we can replace shiny-server.service with the upstream version
(https://github.com/rstudio/shiny-server/blob/master/config/systemd/shiny-server.service).

[1] ExecStart=/usr/bin/shiny-server
[2] ExecStart=/usr/bin/env bash -c 'exec
/opt/shiny-server/bin/shiny-server >> /var/log/shiny-server.log 2>&1'

[3] ExecStart=/usr/bin/env bash -c 'exec
/usr/lib/shiny-server/bin/shiny-server >> /var/log/shiny-server.log
2>&1'

Then, as far as I can see, it's all working!


A number of node-sockjs-client's dependencies were updated between
1.5.2 and current 1.6.0 so the underlying issue may be an out of date
dependency, or some other change that upstream shiny-server has not
yet adjusted to. Is there a workaround for this, e.g. to ship the
1.5.2 sockjs.js and sockjs.min.js files along with shiny-server as a
patch, until upstream adopts 1.6.0?

Best,
Eric

On Wed, Mar 30, 2022 at 5:14 AM Nilesh Patra  wrote:
>
> Hi Eric,
>
> On Sun, Mar 27, 2022 at 06:18:49PM +0530, Nilesh Patra wrote:
> > > > 3. update outdated node-shiny-server-client to latest upstream
> > >
> > > Seems a wise thing to do.
> >
> > I have done so.
> >
> > @Eric, if you can try with the newer versions of these packages to check if 
> > your
> > second app looks better, that'd be much appreciated.
> > If it is, then rest stuff should be relatively easy to fix.
>
> Did you get a chance to test it with updated versions of the packages?
> I was planning to proceed to finalise this package according to the feedback.
>
> Let me know.
>
> Regards,
> Nilesh



-- 
Eric Brown MD MSc FRCPC
For encryption, OpenPGP public key available on request.

Re: scikit-learn bug 1008369

[Christian Kastner]

Hi Chiara,

On 2022-04-01 05:47, Chiara Marmo wrote:
> I have investigated the scikit-learn bug #1008369 [1].
> I thought it could be fixed by an update of numpydoc [2], but I was
> wrong (sorry Christian... I believe you are in this list too so I'm not
> cross-posting on debian-python).

Thanks for trying, anyway!

> Indeed, the failures are related to docstring issues in scikit-learn
> that have been fixed in the current main version on github.
> I have created a number of patches already but new failures pop out... :(
> I am quite confident that 1.1 will soon be out (~end of April).
> 
> Could it be acceptable to wait for 1.1 rather than create a number of
> patches on the current version?

If the offending tests all contain the string "docstring" (as is the
case in #1008369), I'd just skip those for now.

This could be as simple as adding "not doctest" to "EXCLUDE_TESTS" in
debian/rules and to "exclude_tests" in debian/tests/python3.

I think in the past, even larger parts of the test suite have been
omitted temporarily to easily deal with transient stuff.

Otherwise, I think waiting until 1.1 wouldn't be too bad.

I don't think the effort of anything more than pulling a patch or two
from 1.1 are worth it, if the issue will indeed be resolved shortly with
the new upstream release.

> Thanks for your understanding.
> 
> Best regards,
> 
> Chiara
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008369
> 
> [2] https://lists.debian.org/debian-python/2022/03/msg00048.html
> 

Best,
Christian

Re: Google Summer of Code, Debian Science

[Anton Gladky]

Dear Debian Science team,

as discussed, I have submitted a proposal to GSoC 2022 [1].
I have a feedback that a second ("backup") person is needed as
a mentor.

If somebody wants to join this initiative, please drop me an email.

[1]
https://wiki.debian.org/SummerOfCode2022/PendingProjects/QualityAssuranceDebianScience

Thanks

Anton


Am Mo., 21. Feb. 2022 um 17:42 Uhr schrieb Anton Gladky :

> Dear all,
>
> Google Summer of Code call for Debian is announced [1].
> I am going to apply Debian Science Team as one of the projects.
>
> Main topic is QA-Work: Autopkgtests for high-popcon packages,
> gitlab-CI for most of packages, bringing not-in-testing packages
> into the proper shape to let them migrate to testing.
>
> If somebody wants to be a co-mentor or if you have better ideas
> for the project, please let me know.
>
> [1] https://lists.debian.org/debian-devel-announce/2022/02/msg2.html
>
> Best regards
>
> Anton
>