Bug#805149: ITP: mediaconch -- implementation and policy checker, reporter and fixer for media files
Package: wnpp Severity: wishlist Owner: Chow Loong Jin * Package name: mediaconch Version : 15.10 Upstream Author : MediaArea.net SARL * URL : https://mediaarea.net/MediaConch/ * License : GPLv3+ Programming Lang: C++ Description : implementation and policy checker, reporter and fixer for media files MediaConch is an extensible, open source software project consisting of an implementation checker, policy checker, reporter, and fixer that targets preservation-level audiovisual files (specifically Matroska, Linear Pulse Code Modulation (LPCM) and FF Video Codec 1 (FFV1)) for use in memory institutions, providing detailed and batch-level conformance checking via an adaptable and flexible application program interface accessible by the command line, a graphical user interface, or a web-based shell. I plan to maintain this in pkg-multimedia with the other bunch of things done by MediaArea.net (libzen, libmediainfo, and mediainfo), some of which are dependencies of mediaconch. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: django-ajax-selects lintian errors/warnings
On Sun, 15 Nov 2015 11:42:31 +1100
Brian May wrote:
> Neil Williams writes:
>
> >> 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.
>
> Replace what file with a symlink? bootstrap.js isn't the problem
> itself, the problem is bootstrap.js referencing jquery.min.js from an
> external source. The library itself doesn't currently come with a
> copy of jquery.
So the reference to bootstrap.js needs to be patched out to refer to a
static location which can be put in place using a Depends in
debian/rules.
To get this upstream, yes, upstream should include jquery because that
way everyone knows which version of jquery upstream is actually using.
See below, there is a script which could help here, using node-uglify.
> In this case the python*-ajax-select packages are not intended to be
> used by users, rather they are libraries intended to be used by other
> applications (Django apps) which are used by users. There simply
> isn't a single standard way I know of providing and using one and
> only one jquery in Django libraries. (no - Django Media objects don't
> help)
So the upstream tests against random jquery versions across a wide
range? Isn't it more likely that upstream have a particular version of
jquery that gets used and tested.
> Maybe I should raise this issue with the Django developers? Even if I
> did, came up with a proposal (I don't have one), and we agreed to a
> solution, we still need a solution for now, with the current release
> of Django.
Upstream changes will take time, yes. That's unavoidable.
> If I tell upstream to include a copy of jquery.min.js and/or jquery.js
> in the static directory (this is another issue[1]), it will get
> exported in all Django apps that use this library, including those
> that don't need or want it.
Isn't bootstrap.js doing that already? If bootstrap.js is part of
upstream, using bootstrap.js brings in an external jquery.
> Maybe this is considered a reasonable
> tradeoff - it is unlikely to cause conflicts due to the directory
> name used, however I come from the school of thought that you
> shouldn't be publishing files unless there actually is a need to
> publish the files.
There is a need. If there is a security fix in jquery, how is your
package going to fix that CVE? You can't rely on some external content.
It needs to be fixable within the archive.
> Apologies if I seem argumentative, however I really don't see a good
> solution to this. The best decision really depends on the Django app
> that uses this library, and upstream have tried to make it easier to
> get started using the library in such a way it has minimal downsides
> for Django apps that want to include their own version of jquery.
Then maybe upstream should state the value of using a tested version of
jquery which can have security fixes applied. It sounds like upstream
have decided to support something which is actually counter-productive
and ill-advised on a security basis.
The best way is for upstream to adopt something like the script I
linked to last time. It allows upstream to use one JS set, provides a
way for packagers or others to replace bits of that JS set with
symlinks to preferred versions of that JS. What JS upstream do provide,
has all internal references resolved internally and is provided as
editable JS with all references to JS as .min.js, using a script which
does simple uglification in a configurable way.
We've only just merged that script upstream and it works for us - it
will likely need changes to work for others but we're open to patches
if people are interested.
> >> 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('
Bug#805153: ITP: libqes -- a next-gen sequencing format parsing and utility library for C
Package: wnpp Severity: wishlist Owner: Kevin Murray * Package name: libqes Version : 0.1.20 Upstream Author : Kevin Murray * URL : https://github.com/kdmurray91/libqes * License : GPL-3+ Programming Lang: C Description : Next-gen sequencing format parsing and utility library for C This is packaged as a build-dep of the Axe demultiplexer (src pkg axe-demultiplexer). It will be co-maintained with Debian Med.
Re: Copyright file granularity
Quoting Osamu Aoki (2015-11-15 04:07:10) > Please note one type of de-facto exception which is not documented but > widely accepted. FTP master has accepted such packages with the GNU > permissive type license on autotools generated files. I see almost no > one follow the rule literary on these files. Right - 72 packages register GAP licensing terms (plus maybe some not using machine-readable files with that common license shortname): https://codesearch.debian.net/results/License%3A%20GAP%20path%3A%2Fdebian%2Fcopyright/page_0 > They are slightly different files to files and are nothing but noise > for then purpose we use debian/copyright if we pedantically list them. Registering such files is not simply noise: It is a way of signalling "this file has been checked and is believed to be DFSG-compliant", which is is quite different from "this file was added in a later upstream release, was not checked by the package maintainer nor by the ftpteam". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#805188: ITP: selektor -- Java based Tor exit node selector and traffic router
Package: wnpp Severity: wishlist Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" * Package name: selektor Version : 3.13.49 Upstream Author : Alistair Neil * URL : http://www.dazzleships.net * License : GPL2+ Programming Lang: Java Description : Java based Tor exit node selector and traffic router A java based GUI frontend for the Tor client. Simplifies the process of selecting Tor exit nodes and manages selective URL Pattern based routing via system proxying.
git, debian/ tags, dgit - namespace proposal
Currently, the debian/ git tag namespace is used by a number of different tools, and can mean different things in different packages and sometimes even different things for the same package in different repos or trees. dgit produces, and the dgit git server requires, tags of this form, which refer to the dgit branch, which is roughly what some people call a `patches-applied packaging branch'. So far, dgit has been using debian/ for this. But this is a problem because this tag namespace is used for other purposes and has no clear meaning. I'm currently working on dgit native push support for users of 3.0-quilt+git-buildpackage, where this is particularly bad because it would involve dgit making two tags with the same name (!) Having considered things, I think it would be best for dgit to concede this area of namespace for all the existing uses. Declaring those existing uses wrong, just because they're varied and and mutually inconsistent, is not very helpful. Consequently I need a new namespace. I don't want to put `dgit' in the name because the format is not specific to dgit. It is simply the result of `dpkg-source -x' (only without the .pc directory which dpkg-source sometimes produces). I am currently thinking that dgit would start to use the tag namespace Debian/ instead. These tags would always refer to a Patches-applied packaging branch (where applicable containing a patch to add or update .gitignore). For other distros, I would likewise capitalise just the first character of the distro name (with `ucfirst' in Perl). So `Ubuntu/'. is translated as specified in DEP-14. So this message is: * A request for anyone to say if they know of a reason I shouldn't do this. * A declaration (currently, tentative) of intent to claim this part of the git tag namespace. * A proposal to update DEP-14 to declare that "vendor" in DEP-14 should start with a lowercase letter, and ideally, to reserve the corresponding starts-with-uppercase tags for dgit. Thanks, Ian.
Re: git, debian/ tags, dgit - namespace proposal
On Sun, 2015-11-15 at 21:10 +, Ian Jackson wrote: [...] > So this message is: > > * A request for anyone to say if they know of a reason I shouldn't do > this. [...] Deliberately creating identifiers that differ only by case seems gratuitously confusing. Further, it may cause difficulties for someone who is packaging for some other operating system and tries to clone a dgit repository onto a case-insensitive filesystem (which git generally does support). Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#805230: ITP: python-pymummer -- Python interface to MUMmer
Package: wnpp Severity: wishlist Owner: Debian Med Packaging Team * Package name: python-pymummer Version : 0.6.1 Upstream Author : 2015 Martin Hunt and Nishadi De Silva * URL : https://github.com/sanger-pathogens/pymummer * License : GPL Programming Lang: Python Description : Python interface to MUMmer pymummer is a Python wrapper for running the program of the MUMmer sequence alignment suite and parsing its output. This package will be maintained by the Debian Med team.
Re: git, debian/ tags, dgit - namespace proposal
On 2015-11-15 21:26:52, Ben Hutchings wrote: > On Sun, 2015-11-15 at 21:10 +, Ian Jackson wrote: > [...] > > So this message is: > > > > * A request for anyone to say if they know of a reason I shouldn't do > > this. > [...] > > Deliberately creating identifiers that differ only by case seems > gratuitously confusing. Further, it may cause difficulties for someone > who is packaging for some other operating system and tries to clone a > dgit repository onto a case-insensitive filesystem (which git generally > does support). +1, differing only by case is indeed very confusing. regards, iustin signature.asc Description: PGP signature
Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]
On Fri, Nov 13, 2015 at 05:47:41PM +0100, Marc Haber wrote: > Regarding dpkg, its conffile handling is IMO beyond repair, it should > be deprecated and later removed. Could you explain why? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: Bug#802595: ITP: node-defined -- return the first argument that is `!== undefined`
On Wed, Oct 28, 2015 at 09:44:33AM +0900, Josh Triplett wrote: > However, whether we fix (1) or not, (2) needs to stop. It's completely > ridiculous to go to an upstream and say "your package is tiny, could you > combine it with other unrelated tiny packages to make a less tiny > package?". Yes, that's correct, but that doesn't (in my book) imply that (2) does indeed need to stop. It's perfectly possible and reasonable for _Debian_ to make that aggregation; we can create a package "node-small-libraries" or some such which would "Provides: node-undefined" and other similarly small libraries. Given the fact that they are indeed all very small, there's little to no downside to doing so. If the sheer number of these small libraries ever starts actually becoming a problem, we can then still split it up -- and the "Provides:" header should then make sure (if Debian maintainers have done their job correctly) that dependencies don't suddenly start breaking. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Bug#805255: ITP: golang-github-smartystreets-goconvey -- Go testing in browser
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Control: block 797702 by -1 Package name: golang-github-smartystreets-goconvey Version: 1.5.0 Upstream Author: SmartyStreets, LLC License: Expat URL: https://github.com/smartystreets/goconvey Vcs-Browser: https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-smartystreets-goconvey.git Description: Go testing in browser Write behavioral tests in your editor. Get live results in your browser. signature.asc Description: This is a digitally signed message part.
Bug#805256: ITP: r-cran-jsonlite -- A Robust, High Performance JSON Parser and Generator for R
Package: wnpp Severity: wishlist Owner: Chris Lawrence * Package name: r-cran-jsonlite Version : 0.9.17 Upstream Author : Jeroen Ooms * URL : http://arxiv.org/abs/1403.2805 * License : MIT Programming Lang: R Description : A Robust, High Performance JSON Parser and Generator for R A fast JSON parser and generator optimized for statistical data and the web. Started out as a fork of 'RJSONIO', but has been completely rewritten in recent versions. The package offers flexible, robust, high performance tools for working with JSON in R and is particularly powerful for building pipelines and interacting with a web API. The implementation is based on the mapping described in the vignette (Ooms, 2014). In addition to converting JSON data from/to R objects, 'jsonlite' contains functions to stream, validate, and prettify JSON data. The unit tests included with the package verify that all edge cases are encoded and decoded consistently for use with dynamic data in systems and applications. -- This package is a dependency for r-cran-zelig 5.0 and later.
Bug#805257: ITP: r-cran-aer -- Applied Econometrics with R
Package: wnpp Severity: wishlist Owner: Chris Lawrence * Package name: r-cran-aer Version : 1.2-4 Upstream Author : Achim Zeileis * URL : https://cran.r-project.org/web/packages/AER/index.html * License : GPL 2/3 Programming Lang: R Description : Applied Econometrics with R Functions, data sets, examples, demos, and vignettes for the book Christian Kleiber and Achim Zeileis (2008), Applied Econometrics with R, Springer-Verlag, New York. ISBN 978-0-387-77316-2. This package is required by r-cran-zelig 5.0+
Bug#805258: ITP: r-cran-geepack -- Generalized Estimating Equation Package for R
Package: wnpp Severity: wishlist Owner: Chris Lawrence * Package name: r-cran-geepack Version : 1.2-0 Upstream Author : Søren Højsgaard * URL : https://cran.r-project.org/web/packages/geepack/index.html * License : GPL v3+ Programming Lang: R Description : Generalized Estimating Equation Package for R Generalized estimating equations solver for parameters in mean, scale, and correlation structures, through mean link, scale link, and correlation link. Can also handle clustered categorical responses. Required by r-cran-zelig 5.0 and later.
Re: copyright files can be generated by cme (was Re: Copyright file granularity)
On Saturday 14 November 2015 16:02:18 Neil Williams wrote: > scan-copyrights must get much better handling of non-text formats. > I tried it with a package containing a lot of png files, the example at > the top of the manpage failed because the output of scan-copyrights was > a binary file. (It's a text-like file which contains binary snippets > pretending to be copyright information.) scan-copyright uses licensecheck which has some trouble recently to handle files with binary. This issue is tracked by #803724. > So no, detailed copyright files for non-trivial packages cannot be > generated and the tools produce nothing close to the required result. > Trivial packages don't need generation. > > It's not that neither tool is perfect, neither tool seems to have been > tried with actual packages that may need the tool. I tried 'cme update dpkg' on moarvm, libtommath, pan and sdl2. Here's a result: http://anonscm.debian.org/cgit/pkg-rakudo/pkg-moarvm.git/tree/debian/copyright Unfortunately, the latest changes in licensecheck indeed broke scan- copyrights. > Even with a trivial package, scan-copyrights produces output which > if used as debian/copyright would get rejected by lintian and ftpmaster. What trivial package ? I can't fix bugs without details. > Much more work needs to be done, You're right. Especially with licensecheck. I've tried to improve licensecheck to better cope with encoding using `file` to detect mime type. But your mail show that this approach fails. Looks like `file` does not cope with with ascii file embeding binary or with several encodings. I need to rework licensecheck. I'll probably revert my changes and let user deal with inconsistent encodings in owners names. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
