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/


--