Re: R package CI test failures

[Andreas Tille]

Hi Gordon,

thanks for your investigation.

On Tue, May 03, 2016 at 04:05:22PM +0200, Gordon Ball wrote:
> Having had a better look at some of the less obvious failings:
> 
> r-bioc-biocparallel
> ---
> 
> Non-deterministic? Seems to fail about 80% of the time in
> test_bpaggregate.R when calling
> 
> bpworkers(param) <- 2
> 
> This is the only call to bpworkers() in the test suite, but I can't
> obviously see why it fails. I'm guessing it is some sort of
> parallel-related race condition.
> 
> Unsure how to solve this except removing the affected test.

If we do not receive any hint from upstream removing this test seems to
be the only solution I can imagine (with my admittedly poor background
knowledge in this field).

> r-bioc-biomart
> --
> 
> The test suite never succeeds, but fails at apparently random points
> with malformed XML errors. Since it relies on internet access, I'm
> guessing the connections don't work reliably from the autopkgtest
> testbed. It consistently works locally, so it isn't the remote resource
> failing.
> 
> The tests may need removing (or at least, installing only for local use)
> since they aren't very useful as CI.

A suggested patch (commited to SVN + team upload) would be great.
 
> r-bioc-cummerbund
> -
> 
> Both vignettes are patched (suppress_test_writing_to_usr.patch) removing
> attempts to write to a readonly dir, but leaving subsequent code which
> consequently fails (data hasn't been loaded).
> 
> Possibly changing the patch to copy extdata from the installed package
> and replace the `system.file` call with a local dir would let these run.

A suggested patch (commited to SVN + team upload) would be great.

> r-bioc-genefilter
> -
> 
> Two vignettes (independent_filtering{,_plots}.Rnw) require knitr
> (unpackaged), not Stangle for compilation.

knitr is ITPed (#808155) but needs some dependencies itself.
 
> The test script can probably be changed to ignore them.

I'm temped to leave this open to come back to the needed package
r-cran-knitr (which also rings a bell for other packages somehow).  To
support this I committed to the packaging of r-cran-highr (#808808) as
well as r-cran-markdown[1].  I pinged Joost van Baal-Ili to get this
finished.

> r-bioc-genomicalignments
> 
> 
> I think this is a bug with the test from upstream.
> test_readGAlignments.R :: test_read_GAlignments_BamViews creates a
> temporary file, doesn't hold onto the file handle and then tries to read
> it. Hence a race condition depending on whether R has yet
> garbage-collected the reference and the file has consequently been
> deleted first.

Hoping for upstream to respond to my first mail.  I might ping at
end of the week with these more detailed information.
 
> r-bioc-limma
> 
> 
> Compared stdout of the test script to a saved copy. It's probably
> sufficient to just run the script and test the exit code, since this
> seems to fail on trivial differences.

I might have a look.  Needs to be updated anyway.

> r-bioc-rsamtools
> 
> 
> test_utilities.R::test_catch_samtools expects both a warning and an
> error, but only gets an error (and hence fails). Maybe a behaviour
> change in r base?

I have no idea. :-(

> r-bioc-shortread
> 
> 
> A bug somehow related to the package's class system, but I haven't
> managed to identify a cause.

I might ping upstream.
 
> r-bioc-summarizedexperiment
> ---
> 
> Missing dependency on R database package hgu95av2.db (from
> test_makeSummarizedExperimentFromExpressionSet.R:176 - can probably just
> remove that subtest)

Fixed in recent upload. 
 
> r-cran-afex
> ---
> 
> In run-unit-test, should run `gunzip -r *`, not `*.gz` (all the gz files
> are in a subdir). This hides a couple of errors resulting from trying to
> load the dataset mlmRev::Contraception (mlmRev isn't packaged). The
> individual tests are small enough they can probably be patched out for now.

Fixed in team upload.
 
> r-cran-contfrac
> ---
> 
> Should be `gunzip -r *` like r-cran-afex

Fixed in team upload.   

 

> r-cran-doparallel
> -
> 
> Uses R CMD BATCH instead of R --no-save < filename to run tests, so all
> the output is hidden in the CI output. Doesn't copy the test files to a
> temporary dir so when they try and create output it fails due to read-only.

(Hopefully) fixed in upload of new upstream version.
 
> r-cran-dplyr
> 
> 
> Missing dependency r-cran-rsqlite. Hopefully the last one.

Hopefully.  Seems I really need to setup debci here ...
 
> r-cran-r6
> -
> 
> Fixed a couple of extra errors - gzipped tests not uncompressed, added a
> patch to remove a one-line use of pryr (unpackaged) in the testsuite.
> 

Request for sponsoring r-cran-tgp and r-cran-maptree

[Pablo Oliveira]

Hi,

I have updated r-cran-tgp [1] to the latest upstream version (2.4-14),
which fixes #820866.

The new upstream version requires a new dependency, r-cran-maptree [2],
which I just packaged (ITP #823320).

Could somebody please upload these packages ?

Thanks,

Pablo

[1] 
[2]

Re: SuperLU

[Mattia Rizzolo]

On Tue, May 03, 2016 at 02:17:42PM +, Nico Schlömer wrote:
> I've imported the repo into [1] where I'll do some work,

it's missing the pristine-tar branch.
Please also import the pristine-tar details into the repository.  Given
that apparently your gbp config doesn't have 'pristine-tar = True', and
you already imported everything, in means you have to run pristine-tar
manually now.

> later this week we can move it to alioth.

why this?
please put in on alioth straigh away (create the repository with the
'setup-repository' command that's in
/git/debian-science/setup-repository)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: SuperLU

[Nico Schlömer]

I've imported the repo into [1] where I'll do some work, later this week we
can move it to alioth.

Cheers,
Nico

[1] https://github.com/nschloe/debian-superlu

On Tue, May 3, 2016 at 3:34 PM Mattia Rizzolo  wrote:

> On Tue, May 03, 2016 at 01:14:38PM +, Mattia Rizzolo wrote:
> > On Tue, May 03, 2016 at 10:48:24AM +, Nico Schlömer wrote:
> > > @Mattia would you mind moving SuperLU over to /git?
> >
> > Conversion ongoing.
> > Will notify once done.
>
> Well, it has been super quick, probably because there is basically
> nothing (for some reasons that are escaping me git-svn didn't notice (or
> couldn't import) the last 3 commits leadin to other 2 uploads...)
>
> mattia@chase ~/devel/TEAM/helper-scripts/superlu
> (git-svn)-[remotes/svn-import/trunk] % git lg
> * 60b07cc (HEAD, svn-import/trunk) Fix the build rule: the static library
> shipped in the package was built with -fPIC (2 years, 5 months ago)
> Sébastien Villemot 
> * 25bf07c Release to experimental (2 years, 5 months ago) Sébastien
> Villemot 
> * 7d447d5   * Repackage the upstream tarball to remove non-free code
> (mc64{a,i}d functions)   * As a consequence, provide stubs for these
> functions in no-mc64ad.patch: if the removed functionality is used, the
> library will simply abort.   * Document the removed functionality in
> README.Debian.   * debian/copyright: rewrite using machine-readable format
> 1.0.   * Use new scheme for BLAS dependencies.   * Remove the broken
> infrastructure for running tests from /usr/share/doc.   * Add new
> libsuperlu-doc package. (2 years, 5 months ago) Sébastien Villemot <
> sebast...@debian.org>
> * 5b015d5 finalize upgrade to 4.3 (2 years, 8 months ago) Christophe
> Trophime 
> * 7976504 some cleanup and update to 4.3 (3 years, 10 months ago)
> Christophe Trophime 
> * 01558ff [svn-inject] Applying Debian modifications (4.0-1) to trunk (6
> years ago) Christophe Prudhomme 
> * bd5050f [svn-inject] Forking superlu source to Trunk (6 years ago)
> Christophe Prudhomme 
> * 6478afe (svn-import/trunk@36809) [svn-inject] Installing original
> source of superlu (4.0) (6 years ago) Christophe Prudhomme <
> prudh...@debian.org>
> mattia@chase ~/devel/TEAM/helper-scripts/superlu
> (git-svn)-[remotes/svn-import/trunk] % git branch -a
> * (HEAD detached at svn-import/trunk)
>   remotes/svn-import/tags/4.3+dfsg-1
>   remotes/svn-import/trunk
>   remotes/svn-import/trunk@36809
> mattia@chase ~/devel/TEAM/helper-scripts/superlu
> (git-svn)-[remotes/svn-import/trunk] %
>
> (the branches would have to be renamed, that's something done post
> conversion)
>
> I'm not sure there is any gain in converting that svn repo.  I think you
> could be better served by an import of all the past uploads to the
> archive into a git repo.
> To do that you can just run:
> gbp import-dscs --debsnap superlu
> It'll download all past uploads of superlu from snapshot.d.o, and import
> then in a git repo.  I'm fairly confident that it'll better made than
> this conversion, consider try running the command and inspecting the
> resulting repository, compared with the history above here (also you
> would have useful tags for all the uploads, etc...).
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Re: SuperLU

[Mattia Rizzolo]

On Tue, May 03, 2016 at 01:14:38PM +, Mattia Rizzolo wrote:
> On Tue, May 03, 2016 at 10:48:24AM +, Nico Schlömer wrote:
> > @Mattia would you mind moving SuperLU over to /git?
> 
> Conversion ongoing.
> Will notify once done.

Well, it has been super quick, probably because there is basically
nothing (for some reasons that are escaping me git-svn didn't notice (or
couldn't import) the last 3 commits leadin to other 2 uploads...)

mattia@chase ~/devel/TEAM/helper-scripts/superlu 
(git-svn)-[remotes/svn-import/trunk] % git lg
* 60b07cc (HEAD, svn-import/trunk) Fix the build rule: the static library 
shipped in the package was built with -fPIC (2 years, 5 months ago) Sébastien 
Villemot 
* 25bf07c Release to experimental (2 years, 5 months ago) Sébastien Villemot 

* 7d447d5   * Repackage the upstream tarball to remove non-free code 
(mc64{a,i}d functions)   * As a consequence, provide stubs for these 
functions in no-mc64ad.patch: if the removed functionality is used, the 
library will simply abort.   * Document the removed functionality in 
README.Debian.   * debian/copyright: rewrite using machine-readable format 1.0. 
  * Use new scheme for BLAS dependencies.   * Remove the broken infrastructure 
for running tests from /usr/share/doc.   * Add new libsuperlu-doc package. (2 
years, 5 months ago) Sébastien Villemot 
* 5b015d5 finalize upgrade to 4.3 (2 years, 8 months ago) Christophe Trophime 

* 7976504 some cleanup and update to 4.3 (3 years, 10 months ago) Christophe 
Trophime 
* 01558ff [svn-inject] Applying Debian modifications (4.0-1) to trunk (6 years 
ago) Christophe Prudhomme 
* bd5050f [svn-inject] Forking superlu source to Trunk (6 years ago) Christophe 
Prudhomme 
* 6478afe (svn-import/trunk@36809) [svn-inject] Installing original source of 
superlu (4.0) (6 years ago) Christophe Prudhomme 
mattia@chase ~/devel/TEAM/helper-scripts/superlu 
(git-svn)-[remotes/svn-import/trunk] % git branch -a
* (HEAD detached at svn-import/trunk)
  remotes/svn-import/tags/4.3+dfsg-1
  remotes/svn-import/trunk
  remotes/svn-import/trunk@36809
mattia@chase ~/devel/TEAM/helper-scripts/superlu 
(git-svn)-[remotes/svn-import/trunk] %

(the branches would have to be renamed, that's something done post
conversion)

I'm not sure there is any gain in converting that svn repo.  I think you
could be better served by an import of all the past uploads to the
archive into a git repo.
To do that you can just run:
gbp import-dscs --debsnap superlu
It'll download all past uploads of superlu from snapshot.d.o, and import
then in a git repo.  I'm fairly confident that it'll better made than
this conversion, consider try running the command and inspecting the
resulting repository, compared with the history above here (also you
would have useful tags for all the uploads, etc...).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: SuperLU

[Mattia Rizzolo]

[ keeping only the list in the recipients.  But you did good at mailing
me explicitly, otherwise I'd have ignored this email ]

On Tue, May 03, 2016 at 10:48:24AM +, Nico Schlömer wrote:
> @Mattia would you mind moving SuperLU over to /git?

Conversion ongoing.
Will notify once done.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Re: SuperLU

[Nico Schlömer]

Thanks!

> That's worth a bug report "New version available" via reportbug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823213

> The best way to tackle this is IMHO becoming a member of Debian Science
team,

I already am. :)

> fix it in VCS (may be by moving packaging to Git) a

Very good. If this gets moved over to Git, I'll be happy to create a
branch, get it to work, and have it reviewed by anyone.

@Mattia would you mind moving SuperLU over to /git?

Cheers,
Nico



On Tue, May 3, 2016 at 12:39 PM Andreas Tille  wrote:

> Hi Nico,
>
> On Tue, May 03, 2016 at 09:30:03AM +, Nico Schlömer wrote:
> > > So if you have a real question rather than this meta-question you
> should
> > ask it here.
> >
> > Yup, well, SuperLU in Debian is pretty outdated and the new version
> allows
> > for a much simpler build process.
>
> That's worth a bug report "New version available" via reportbug.
>
> > The debian config can probably be
> > improved. I was going to ask how this could best be tackled.
>
> The best way to tackle this is IMHO becoming a member of Debian Science
> team, fix it in VCS (may be by moving packaging to Git) and ask for a
> sponsor to upload.  I need to admit that I'm personally not interested
> in this package and have no further free time slots than I used to give
> these hints.
>
> Hope this helps
>
>  Andreas.
>
> --
> http://fam-tille.de
>

Re: SuperLU

[Andreas Tille]

Hi Nico,

On Tue, May 03, 2016 at 09:30:03AM +, Nico Schlömer wrote:
> > So if you have a real question rather than this meta-question you should
> ask it here.
> 
> Yup, well, SuperLU in Debian is pretty outdated and the new version allows
> for a much simpler build process.

That's worth a bug report "New version available" via reportbug.

> The debian config can probably be
> improved. I was going to ask how this could best be tackled.

The best way to tackle this is IMHO becoming a member of Debian Science
team, fix it in VCS (may be by moving packaging to Git) and ask for a
sponsor to upload.  I need to admit that I'm personally not interested
in this package and have no further free time slots than I used to give
these hints.
 
Hope this helps

 Andreas.

-- 
http://fam-tille.de

Re: SuperLU

[Nico Schlömer]

Thanks for the info!

> So if you have a real question rather than this meta-question you should
ask it here.

Yup, well, SuperLU in Debian is pretty outdated and the new version allows
for a much simpler build process. The debian config can probably be
improved. I was going to ask how this could best be tackled.

Cheers,
Nico

On Tue, May 3, 2016 at 11:12 AM Andreas Tille  wrote:

> On Tue, May 03, 2016 at 10:18:23AM +0200, Johannes Ring wrote:
> > On Tue, May 3, 2016 at 10:07 AM, Nico Schlömer 
> wrote:
> > > Does anyone know who is the current maintainer for SuperLU [1] and
> where to
> > > find the debian repo?
> >
> > The maintainer is Debian Science Maintainers and the debian repo is
> > available in debian-science svn repo:
> >
> >
> http://anonscm.debian.org/viewvc/debian-science/packages/superlu/trunk/debian/
>
> ... and you can find out this via
>
>apt-cache showsrc superlu
>
> or using http://tracker.debian.org.
>
> BTW, te Uploader of the package Christophe Prud'homme was not seen
> frequently in the last time here.  So if you have a real question rather
> than this meta-question you should ask it here.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>

Re: SuperLU

[Andreas Tille]

On Tue, May 03, 2016 at 10:18:23AM +0200, Johannes Ring wrote:
> On Tue, May 3, 2016 at 10:07 AM, Nico Schlömer  
> wrote:
> > Does anyone know who is the current maintainer for SuperLU [1] and where to
> > find the debian repo?
> 
> The maintainer is Debian Science Maintainers and the debian repo is
> available in debian-science svn repo:
> 
> http://anonscm.debian.org/viewvc/debian-science/packages/superlu/trunk/debian/

... and you can find out this via

   apt-cache showsrc superlu

or using http://tracker.debian.org.

BTW, te Uploader of the package Christophe Prud'homme was not seen
frequently in the last time here.  So if you have a real question rather
than this meta-question you should ask it here.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#823308: ITP: caffe-contrib -- a deep learning framework, compiled with CUDA

[lumin]

Package: wnpp
Severity: wishlist
Owner: lumin 
X-Debbugs-CC: costamagnagianfra...@yahoo.it, ghisv...@gmail.com, 
debian-science@lists.debian.org

Hi,

#788539 is cpu version of caffe, this is CUDA version.
CPU version goes into main section while this CUDA version
goes into contrib section.

* Package name: caffe-contrib
  Version : 1.0.0~rc3
  Upstream Author : Berkeley Vision and Learning Center
* URL : https://github.com/BVLC/caffe
* License : BSD 2-Clause license
  Programming Lang: C++, Python
  Description : a deep learning framework
 .
 Caffe is a deep learning framework made with expression,
 speed, and modularity in mind. It is developed by the Berkeley
 Vision and Learning Center (BVLC) and community contributors.

Caffe is a well-known software to many (computer vision) researchers,
and it helps them doing related researches. 

Its project home page is:

http://caffe.berkeleyvision.org/

Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Gianfranco Costamagna]

Hi,

>set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)
>
>An upstream classic unfortunately.


as upstream I did this once, and the side effect was something weird.

when you run multiple times cmake .. the cflags gets appended multiple times, 
so you might
end up in a really weird CMakeCache.txt and with really long build lines.

I'm not sure which way is the best one, but cmake should provide something 
different from CFLAGS.

e.g.
CMAKE_C_FLAGS
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS

and so on.
that way they will be appended to current CFLAGS without having to override 
them manually.

(thanks again for your nice reviews!)

g.

Re: SuperLU

[Johannes Ring]

On Tue, May 3, 2016 at 10:07 AM, Nico Schlömer  wrote:
> Does anyone know who is the current maintainer for SuperLU [1] and where to
> find the debian repo?

The maintainer is Debian Science Maintainers and the debian repo is
available in debian-science svn repo:

http://anonscm.debian.org/viewvc/debian-science/packages/superlu/trunk/debian/

Johannes

SuperLU

[Nico Schlömer]

Hi everyone,

Does anyone know who is the current maintainer for SuperLU [1] and where to
find the debian repo?

Cheers,
Nico

[1] https://packages.debian.org/source/sid/superlu

Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Ghislain Vaillant]

On 03/05/16 03:08, lumin wrote:

- d/*.install.in: no multi-arch install paths? why?


I have no plan to make multiarch support for this package,
because that makes no sense. In production environment
Caffe is a computational intensive and memory-consuming
application, and I believe no user will need multi-arch
support for this package.

Made no change related to multi-arch.


What about cross-building?


- d/libcaffe-dev.install.in: what is the purpose of the additional
libproto.a binary?


There is a protobuf definition file under Caffe's source,
   src/caffe/proto/caffe.proto
which is a very essential file as it defined
caffe's "protocol". And libproto.a is the compiled
binary version of that protocol.

Besides, the Official "install" target installs
that static lib, so it is recommended by upstream
to have such a lib. Hence it goes into the -dev packages.


What upstream does is not always aligned with what Debian recommends
though. I was just wondering how the caffe and proto binaries were
related. Plus, it makes lintian ouput comments about unstripped static
libs.


- d/rules + d/*.in: IMO, sounds like a very convoluted way of running 2
separate builds (one for CPU one for CUDA) and moving the files in the
right places. Another possibility could have been to have caffe-cpu and
caffe-cuda as separate source packages, one in main and one in contrib.
For each of them, the packaging would have been much more simple to
maintain I suppose.


I've ever considered split them up into 2 source packages,
but building 2 set of binary from 1 source is my initial intent.
I may split them in the future.


Here is why I would consider splitting them **now**. A significant 
portion of your d/rules consist in detecting whether CUDA is available

and optionally enable compilation of the CUDA version. This could be
avoided by having a caffe or caffe-cpu source package, which potentially
builds on all arch, and a caffe-cuda source package with the CUDA 
Build-Depends, for which you would not need to manually specify the target

architectures.

Benefits from this include:
1) The caffe[-cpu] source package and related binaries can live in main,
instead of contrib at the moment.
2) The caffe-cuda source package does not need the manual architecture
restriction stuff.
3) Last but not least, the resulting source packages become much
simpler to maintain in the long term, which is good from a
**team-maintenance perspective**.

As an FYI, the version of CUDA you are asking is available for ppc64el
and no longer for i386. With your solution, you (now) have to modify
this manually in d/{control,rules}. With separate source packages, you 
would not have to.



I've tried to inject these flags according to wiki:Hardening
```
# Hardening Caffe according to https://wiki.debian.org/Hardening
DPKG_EXPORT_BUILDFLAGS=1
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
include /usr/share/dpkg/buildflags.mk
CFLAGS+=$(CPPFLAGS)
CXXFLAGS+=$(CPPFLAGS)
```


You should only require
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_CPPFLAGS_MAINT_APPEND = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

I have added DEB_CPPFLAGS_MAINT_APPEND, since CMake does not always
automatically transfer the CFLAGS to CPPFLAGS. Unless, the caffe
build system is set-up for doing so.


But hardening-fortify-source-function is still unfixed.
```
$ hardening-check /usr/bin/caffe
/usr/bin/caffe:
  Position Independent Executable: yes
  Stack protected: yes
  Fortify Source functions: no, only unprotected functions found!
  Read-only relocations: yes
  Immediate binding: yes
```

I have no idea about it...


You would have to look for override lines of the form:

set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)

An upstream classic unfortunately.

Ghis

Re: packaging of flatbuffers

[Jonathon Love]

no nibbles? i would appreciate a sponsor.

with thanks


On 30/04/2016 19:30, Jonathon Love wrote:

hi folks,

i've been packaging the flatbuffers project, and i think it might be 
ready to go (although, perhaps it should be submitted independent of 
debian-science).


i've pushed the work to:

/git/debian-science/packages/flatbuffers.git

the flatbuffers project contains many subprojects which should form 
separate binary packages. my packaging so far produces:


 - libflatbuffers-dev

 - flatbuffers-compiler

 - libjs-flatbuffers

 - libflatbuffers-java

but there's also subprojects for go, C#, python, PHP, etc. which i 
haven't packaged and didn't really want to. hopefully that's ok.


i'm not completely sure i've done the right thing with the maven java 
builds. the pom.xml has sections requiring the plugins:


 - maven-source-plugin (version 2.3)

 - maven-javadoc-plugin (version 2.9.1)

so i've added these to the dependencies in d/control

however, these (older) versions don't exist in debian, and only newer 
ones (2.4, and 2.10.3). so i've patched pom.xml to use these newer 
versions, which works. but of course, this will *only* build with 
these versions, so i've fixed the dependency to require these versions.


from what i've read, maven requires you to specify a specific version, 
and doesn't allow wildcards or >= $version ... so i can't see a way 
around this.


could someone review the package for me?

with thanks

jonathon