Re: django-pipeline / slimit

[Brian May]

Brian May  writes:

> Ok, so now I think I understand, time to test the lastest version of
> pipeline I think. See if that helps.

It fixes the problem. However we get a new problem:


I: pybuild base:184: PYTHONPATH=. python3.5 /usr/bin/django-admin test 
--settings=tests.settings
..sssss.Es..s
==
ERROR: test_slimit (tests.tests.test_compressor.CompressorImplementationTest)
--
Traceback (most recent call last):
  File "/«PKGBUILDDIR»/tests/tests/test_compressor.py", line 230, in test_slimit
'js', 'pipeline/compressors/slimit.js')
  File "/«PKGBUILDDIR»/tests/tests/test_compressor.py", line 215, in 
_test_compressor
[_('pipeline/js/first.js'), _('pipeline/js/second.js')])
  File "/«PKGBUILDDIR»/pipeline/compressors/__init__.py", line 69, in 
compress_js
js = getattr(compressor(verbose=self.verbose), 'compress_js')(js)
  File "/«PKGBUILDDIR»/pipeline/compressors/slimit.py", line 12, in compress_js
from slimit import minify
ImportError: No module named 'slimit'

--
Ran 89 tests in 0.839s

FAILED (errors=1, skipped=15)


Does this mean we need to change the slimit package into python-slimit
and python3-slimit packages?
-- 
Brian May 

Re: django-pipeline

[Brian May]

Steve Langasek  writes:

> Ok, that was certainly another possibility.  "Clean" chroots certainly vary,
> and some ways of building them may include more stuff than others, and some
> of that "more" stuff may be triggering this problem.

Think we were on the wrong track entirely.

If problem occurs or not, depends on the order the tests are run
in. Which probably depends on the filesystem being used plus a lot of
other random stuff.

It appears that the Django override_settings is not correctly restoring
settings after the test completes - or at least not the JS_COMPRESSOR
and CSS_COMPRESSOR settings - hence currupting future tests.

This seems to be because the settings do not appear in
django.conf.settings._wrapped

Which is probably expected, as when pipeline sets the default values in
pipeline/conf.py it doesn't change the Django setting. So Django
restores the settings to what it thinks were the previous values, which
due to the way pipeline keeps its own copy of the settings isn't
correct.

Ok, so now I think I understand, time to test the lastest version of
pipeline I think. See if that helps.
-- 
Brian May 

Re: django-pipeline

[Steve Langasek]

On Wed, Mar 23, 2016 at 09:21:19AM +1100, Brian May wrote:
> Steve Langasek  writes:

> > No.  I first noticed this bug because the package failed to build in
> > Ubuntu[1], which uses sbuild, not pbuilder.  I reproduced the failure in a
> > clean sid schroot.  I think either your sbuild environment is not clean, or
> > it is not up-to-date.

> Definitely a clean chroot. I just recently deleted and rebuilt it from
> scratch. With sbuild-createchroot.

> In a bizarre twist, I have found I can reproduce the problem on a dirty
> testing Debian installation. So I will attempt to fix the problem here,
> and see if this offers any clues as to what on earth is going on with my
> clean chroot.

Ok, that was certainly another possibility.  "Clean" chroots certainly vary,
and some ways of building them may include more stuff than others, and some
of that "more" stuff may be triggering this problem.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: django-pipeline

[Steve Langasek]

On Tue, Mar 22, 2016 at 09:13:42PM +1100, Brian May wrote:
> Mattia Rizzolo  writes:

> > FTR this is also visible in the reproducible CI:
> > https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/django-pipeline.html

> > That's a standard pbuilder instance in a clean chroot.

> > I tried to reproduce it locally and I had the very same failure.
> > Though I can't help fix it, just saying I can reproduce the failure.

> I was using a clean sbuild environment. Wonder if this is pbuilder
> specific. Not that this really makes sense.

No.  I first noticed this bug because the package failed to build in
Ubuntu[1], which uses sbuild, not pbuilder.  I reproduced the failure in a
clean sid schroot.  I think either your sbuild environment is not clean, or
it is not up-to-date.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] https://launchpad.net/ubuntu/+source/django-pipeline/1.6.4-1/+build/8796465


signature.asc
Description: Digital signature

Re: Handling python modules collision

[Scott Kitterman]

On Tuesday, March 22, 2016 04:55:36 PM Frederic Bonnard wrote:
> Hi,
> I'd like your advises concerning the following situation : I'm packaging
> this python library :
> https://github.com/miguelgrinberg/python-socketio
> 
> and I see that debian already provides a library with the same name :
> 
> https://github.com/abourget/gevent-socketio
> 
> The name can be changed of course but I'm not sure on how to deal with the
> fact that the first one wants to install in the same path i.e. :
> /usr/lib/python2.7/dist-packages/socketio
> 
> Is that a proper case where to use "Conflicts" field ?

Only if they provide the same interface.  Here are the relevant bit from 
Debian policy:

10. Files
-


10.1. Binaries
--

 Two different packages must not install programs with different
 functionality but with the same filenames.  (The case of two programs
 having the same functionality but different implementations is handled
 via "alternatives" or the "Conflicts" mechanism.  See Section 3.9,
 `Maintainer Scripts' and Section 7.4, `Conflicting binary packages -
 `Conflicts'' respectively.) If this case happens, one of the programs
 must be renamed.  The maintainers should report this to the
 `debian-devel' mailing list and try to find a consensus about which
 program will have to be renamed.  If a consensus cannot be reached,
 _both_ programs must be renamed.

I would recommend discussing this collision with both upstreams and see what 
they say.  It would be nice if one of them would rename.

Scott K

Re: Handling python modules collision

[Dmitry Shachnev]

Hi Frederic,

On Tue, Mar 22, 2016 at 04:55:36PM +0100, Frederic Bonnard wrote:
> Hi,
> I'd like your advises concerning the following situation : I'm packaging this
> python library :
> https://github.com/miguelgrinberg/python-socketio
>
> and I see that debian already provides a library with the same name :
>
> https://github.com/abourget/gevent-socketio
>
> The name can be changed of course but I'm not sure on how to deal with the 
> fact
> that the first one wants to install in the same path i.e. :
> /usr/lib/python2.7/dist-packages/socketio
>
> Is that a proper case where to use "Conflicts" field ?

No, that's not a proper case for Conflicts.

You should change the Python package name to be different from socketio,
better work with upstream on that. After that you'll be able to name the
package according to our naming policy.

According to GitHub metrics (stars/forks), gevent-socketio is ~10 times more
popular than python-socketio, so it's better to change the latter, not the
former.

If the upstream refuses to do the renaming, you can do it as a distro-patch,
but then you'll need to patch all the packages using it too. So better to
do the work upstream…

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Handling python modules collision

[Frederic Bonnard]

Hi,
I'd like your advises concerning the following situation : I'm packaging this
python library :
https://github.com/miguelgrinberg/python-socketio

and I see that debian already provides a library with the same name :

https://github.com/abourget/gevent-socketio

The name can be changed of course but I'm not sure on how to deal with the fact
that the first one wants to install in the same path i.e. :
/usr/lib/python2.7/dist-packages/socketio

Is that a proper case where to use "Conflicts" field ?

Thanks,
Fred

Re: django-pipeline

[Brian May]

Mattia Rizzolo  writes:

> FTR this is also visible in the reproducible CI:
> https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/django-pipeline.html
>
> That's a standard pbuilder instance in a clean chroot.
>
> I tried to reproduce it locally and I had the very same failure.
> Though I can't help fix it, just saying I can reproduce the failure.

Thanks.

I was using a clean sbuild environment. Wonder if this is pbuilder
specific. Not that this really makes sense.
-- 
Brian May 

Re: django-pipeline

[Mattia Rizzolo]

On Tue, Mar 22, 2016 at 05:42:48PM +1100, Brian May wrote:
> I would appreciate help with #818730 for django-pipeline.
> 
> The reporter claims the package won't build however I can't reproduce
> any problems myself. Which makes it hard to fix.

FTR this is also visible in the reproducible CI:
https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/django-pipeline.html

That's a standard pbuilder instance in a clean chroot.

I tried to reproduce it locally and I had the very same failure.
Though I can't help fix it, just saying I can reproduce the failure.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature