[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: django-ajax-selects lintian errors/warnings



On Sat, 14 Nov 2015 20:23:38 +1100
Brian May <bam@debian.org> wrote:

> Hello,
> 
> For django-ajax-selects in git[1] I am getting the following errors
> and warnings:

Many of these need work upstream, some can be replaced with symlinks,
some are not packaged in Debian due to problems with the minifier used
in the build process of that upstream.

> E: django-ajax-selects source: source-is-missing
> ajax_select/static/ajax_select/js/bootstrap.js

If this really is your own source code, a filename change would be one
way to do it. In most cases, bootstrap is not written by this upstream
but has been included into the upstream VCS from another location.

> python3-ajax-select: image-file-in-usr-lib
> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif

This matters more when the package list from this source package
contains Architecture: any instead of Architecture: all binaries, which
is uncommon with django apps. With Arch: any, the files in /usr/lib/
would be duplicated for each arch build which is a clear problem to be
avoided.

It would seem sensible that lintian could check the architecture of the
binary providing the files. Yes, it's a wrinkle and arguably ugly to
have images in /usr/lib/ but then what is the point of models.py and
views.py being in /usr/lib/ on that basis? setuptools moved
to /usr/lib/ some time ago, it's not a good idea to backtrack
to /usr/share just for Debian. Having a -common package for Arch:all
doesn't really make sense unless there is more than one Arch:all
package sharing those "common" files. /usr/lib/ makes sense for the
lower end python code which has architecture-specific bindings.

> E: python3-ajax-select: privacy-breach-uses-embedded-file
> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
> You may use libjs-jquery-ui package.

You may indeed - replace the file with a symlink in debian/rules and
add to Depends.

> source-is-missing - this is false, this is the source file, I believe
> it was written by hand. It has some long lines. See below, I pasted
> it into this message.

lintian may just be basing this on the filename.
 
> image-file-in-usr-lib - do we really care about this? For Django apps
> it is common practise to put static files under the Python directory
> like this. That means they go under /usr/lib. It is not really
> possible to change this without a lot of extra complexity using a
> -common package and symlinks. For one small file, not convinced it is
> worth it.

As above, I'm not sure why lintian cannot appreciate the distinction
here for Arch: all packages. It would be nice if I could remove the
override: lava-server: image-file-in-usr-lib *
 
> privacy-breach-uses-embedded-file - this is only correct if used by an
> application that does not import jquery symbols itself. If the
> application already has loaded jqueblry and jquery-ui from, say a
> local source, I believe there is no privacy issue:
> 
> // load jquery and jquery-ui if needed
> // into window.jQuery
> if (typeof window.jQuery === 'undefined') {
>   document.write('<script type="text/javascript"
> src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"><\/script><script

That src can be patched to not look at //googleapis but to look at
{{ STATIC }}/blah/js/jquery.min.js which itself is a symlink. Similarly
with href. Work with upstream about the problems of relying on third
party sites for their code.
 
> I could simply remove the contents of this file if required, that kind
> of seems silly however, and could break compatability with upstream
> for local non-Debian projects. Is it ok if I add an override?

I've overridden /usr/lib and I've worked as upstream to fix the
javascript issues. It's an ongoing process. The harder part is to
ensure that upstream understand the reasoning for the javascript
symlinks and to persuade them to adopt node-uglify in the package so
that all your .min.js files are built from js files in the released
tarball. Explain about the security team needing to patch the .js and
then the package reliably incorporating those changes into the .min.js.

There was talk of dh_uglify but after putting the support we need into
our own package, I'm not yet sure how generic it could actually be.

This is what we're using for uglify & symlink replacement:
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.py
https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.yaml

Not in unstable yet, this is slated for the 2015.12 release.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpsdWfcAiqFj.pgp
Description: OpenPGP digital signature


Reply to: