On Wed, 3 Oct 2018 at 11:13, Neil Williams neil.williams@linaro.org wrote:
On Wed, 3 Oct 2018 at 10:50, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Wed, 3 Oct 2018 at 10:44, Neil Williams neil.williams@linaro.org wrote:
On Wed, 3 Oct 2018 at 10:24, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Mon, 1 Oct 2018 at 10:46, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Mon, 1 Oct 2018 at 10:24, Neil Williams neil.williams@linaro.org wrote:
> >> Is there any reason why lava is stuck with debian? Why not package it > >> as pip package and make distro agnostic? > > > > > > This is covered in the docs. LAVA has dependencies which cannot be provided by pip and it has functionality which pip cannot support. >
It turns out debian isn't any better in managing dependencies here.
That's an unhelpful description of the situation - there's been no request to put this change into stretch-backports. Stretch is a stable release, changes don't go in without a reason. Other people using this package in Stretch have obviously not had problems with the version in Stretch.
maybe there is no one using it. It fails as soon as you include it into django settings.
Works fine for me - as long as django settings are set up correctly using only packages from Stretch:
root@lxc-stretch-security:/# lava-server manage shell Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole)
import django_filters
root@lxc-stretch-security:/# dpkg -l python-django-filters python-django lava-server|cut -c -80 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=====================-=================-============-======================= ii lava-server 2016.12-3 all Linaro Automated Valida ii python-django 1:1.10.7-2+deb9u2 all High-level Python web d ii python-django-filters 0.13.0-1 all filter Django QuerySets
If you're using current LAVA or using django from backports, then that would likely be the problem.
It is: https://git.lavasoftware.org/mwasilew/lava/-/jobs/3085 It fails with lava unit tests.
milosz
Anyway, we can see about a rebuild of the version from buster targetted at stretch-backports.
milosz
In order not to implement all filtering again I tried using django-filter package. Unfortunately the version that is currently in stretch (0.13.0-1) has a bug [1] that is fixed in 1.0.2. So buster version (1.1.0) is OK. There is no fix in stretch-backports. Any hints what to do in such case?
We can request an upload to stretch-backports of the fixed version in buster. This is how Debian works - packages in testing (currently buster) can go into stable-backports (currently stretch-backports), once that work is requested.
That gives us a change of limited impact which can be properly staged, validated and implemented and which won't change underneath us later.
[1] https://github.com/carltongibson/django-filter/issues/673
milosz
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/