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.
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/