Re:

[Jonathon Love]

hi johannes,


On 27/10/16 23:22, Johannes Schauer wrote:

Hi,

I'm not subscribed to debian-science, so please CC me and I hope I didn't break
the thread when I manually set the In-Reply-To header.

Quoting Jonathon Love (30 Apr 2016)

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

Thanks! Your packaging saved me lots of work when I wanted to test flatbuffers
on Debian. :)


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

I was confused that there was no shared library but apparently that is intended
by upstream:

https://github.com/google/flatbuffers/issues/4008


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.

Certainly.


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.

Unfortunately, I cannot help you with java. You should contact the Debian Java
team debian-j...@lists.debian.org about this issue.

Unfortunately, I wasn't able to use your package to successfully compile a
small hello-world demo of flatbuffers. I reported the problem here:

https://github.com/google/flatbuffers/issues/4071

Did you get flatbuffers from your package to work and if yes, how?


does gwvo's response to your issue solve it for you?

i'm not sure the version in the d-science repo is my most recent 
iteration (i did some more work on it), i'd have to look into it. there 
wasn't a lot of interest on d-science (understandably, because it's not 
really science-y) so i tried going through the RFS route. but then there 
was almost no interest there either :/


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

eventually i got a review, but it was about 2 months later, was only 
very general, and didn't instill me with confidence that i would 
actually be able to get a sponsor. so i gave up for the time being.


(so i've adopted ProtoBuf in my projects instead, but even with people 
falling over themselves to provide [trivial] patches to add python3 
support to *that* package, that hasn't received any attention from the dd's)


so this has been a bit of a discouraging road.

but if you'd like to drive flatbuffers in debian forward, i'd be happy 
to help.


jonathon

Re: Data updates in debian packages

[Paul Wise]

On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote:

> The package in question (casacore) wants them in a specific format "CASA
> table" (which is uniformly used within that package), and dependent
> packages access this in that specific format. The only way would be to
> create this table from another leap second table (instead of our current
> source usno.navy.mil), and to update this every time the original table
> is updated (which I would have to learn how to do this).

You can use dpkg triggers to update files in response to packages
updating other files.

> however it worries me a bit that leap seconds are not directly mentioned
> there. How sure can one be that they will be installed in-time?

They are in the tzdata package, you can use Depends to ensure it is installed.

> What would be the default place?
> /var/lib/casacore/data?

Sounds good.

> What I would do here is a separate package "casacore-data-autoupdater"
> that provides that service for all installed casacore-data-XXX packages.
> That package would install itself into /etc/cron.daily and, when called,

Please ensure that all the systems that install this package do not do
the download at the same time, to spread the load out a bit. Check out
these files in the apt package for a good way to do that, which avoids
cron jobs sleeping for ages on systemd-based systems and uses random
sleeps with cron on other systems:

/etc/cron.daily/apt-compat
/lib/systemd/system/apt-daily.service
/lib/systemd/system/apt-daily.timer
/usr/lib/apt/apt.systemd.daily

> The update script itself could even be distributed with the casacore
> package itself. And for simplicity I would make
> casacore-data-autoupdater a binary package within the casacore source
> package (since this is the main dependency anyway).
>
> Comments on that? What would be the best dependency specification then?
> casacore-data-autoupdater "suggests" casacore-data-XXX and/ore vice-versa?

casacore-data-autoupdater Enhances: casacore-data-XXX
casacore-data-XXX Recommends: casacore-data-autoupdater

>> Make sure that any security/privacy consequences of the non-apt update
>> method are dealt with.
>
> If you have comments on my proposal, please comment.

I don't know enough about the formats and the download processes to comment.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Data updates in debian packages

[Ben Finney]

Ole Streicher  writes:

> Probably the canonical source would be:
>
> > tzdata: /usr/share/zoneinfo/leap-seconds.list

I agree, it would be good for a package to build its custom leap-seconds
data starting from that canonical source.

> however it worries me a bit that leap seconds are not directly mentioned
> there.

I don't understand that statement. Reading that file (from ‘tzdata’
version “2016h-1”), I see extensive discussion of leap seconds in the
large header of the file.

What mention are you expecting but not seeing, and how does the header
block in that file not constitute “direct mention of leap seconds”?

> How sure can one be that they will be installed in-time?

This confuses me too. If the file is installed, you have the
leap-seconds data for the installed version of ‘tzdata’.

So I think I don't understand. What specific concern do you have about
the leap seconds data from the ‘tzdata’ package?

-- 
 \ “Nature hath given men one tongue but two ears, that we may |
  `\  hear from others twice as much as we speak.” —Epictetus, |
_o__)  _Fragments_ |
Ben Finney

Bug#842491: ITP: dfcgen-gtk -- Digital Filter Coefficients Generator (DFCGen) GTK+

[Graham Inggs]

Package: wnpp
Severity: wishlist
Owner: Graham Inggs 
X-Debbugs-CC: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: dfcgen-gtk
  Version : 0.4
  Upstream Author : Ralf Hoppe 
* URL : http://www.dfcgen.de
* License : GPL-2.0
  Programming Lang: C
  Description: Digital Filter Coefficients Generator (DFCGen) GTK+
 DFCGen, the Digital Filter Coefficients Generator, assists the engineer
 in the design of digital filters. It supports  the engineer in analysis
 and synthesis of linear time-invariant  time-discrete (LTI) systems
 from the theoretical point of view. It performs  generation of
 system transfer function coefficients in the Z-domain,
 based on the type and specific parameters of a chosen system.

I intend maintaining this package within debian-science.

Re: HDF5 1.10 transition?

[Gilles Filippini]

On 2016-10-25 09:42, Jerome Kieffer wrote:

On Tue, 25 Oct 2016 08:13:43 +0100
Ghislain Vaillant  wrote:



What about h5py ? Have you tried it with hdf5 v1.10 ?



There are many things going around pytables, h5py and hdf5:

* h5py (2.6) supports the new features of hdf5 1.10 (SWMR mainly)

* pytable is useful but no more heavily developed. It has been agreed
  with the dev of h5py to make pytable depend on h5py to have only 1
  wrapper for hdf5 in python and pytables will just offer a different 
API.


This said, I don't know how advanced this migation.


This option was first discussed at SciPy 2015 [1], then officially 
announced after SciPy 2016 [2].


[1] https://groups.google.com/forum/#!topic/pytables-users/GBVkvGexSag
[2] https://groups.google.com/forum/#!topic/h5py/IAaiyHOiJKE

Unfortunaly it is far from achieved and the dedicated 'pt4' branch of 
the pytables repo is stalled since late august. Thus the 'pytables overs 
h5py' option seems dead for Stretch release.


This left us with the 'embed hdf5 1.8.16 into the pytable package' 
option.


Antonio, any thought about this?

Thanks,

Re: Data updates in debian packages

[Ole Streicher]

Hi Paul,

On 29.10.2016 03:37, Paul Wise wrote:
> On Fri, Oct 28, 2016 at 6:38 PM, Ole Streicher wrote:
>> We have the problem (I am not sure whether I posted about this already),
>> that the "casacore" package needs additional "casacore-data-XXX"
>> packages, providing the basic data to work with casacore. Some of the
>> data are almost immutable, others (for example leap seconds) are
>> changing every year or so, and others change quite rapidly (high
>> precision ephemides forecasts). They all can be downloaded from some FTP
>> servers.
> 
> FYI leap seconds are already packaged multiple times in Debian, so
> please do not add another copy of them.

The package in question (casacore) wants them in a specific format "CASA
table" (which is uniformly used within that package), and dependent
packages access this in that specific format. The only way would be to
create this table from another leap second table (instead of our current
source usno.navy.mil), and to update this every time the original table
is updated (which I would have to learn how to do this).

Probably the canonical source would be:

> tzdata: /usr/share/zoneinfo/leap-seconds.list

however it worries me a bit that leap seconds are not directly mentioned
there. How sure can one be that they will be installed in-time?

>> How should the update service work? Can it just overwrite the existing
>> files? How one should handle if an update (with possibly older data) in
>> installed to not downgrade the data?
> 
> Check out pciutils/usbutils and similar.
> 
> Essentially:
> 
> Make the applications look in /var by default.
> 
> Put the packaged data in /usr/share.
> 
> Have the postinst symlink from /var to /usr/share when the /var
> location is missing or older than the /usr/share location.

Looks like a plan ;-) I'll start there. What would be the default place?
/var/lib/casacore/data?

> Have an update script that can be run by the sysadmin or from cron
> that downloads the latest version and atomically replaces the data in
> the /var location.

What I would do here is a separate package "casacore-data-autoupdater"
that provides that service for all installed casacore-data-XXX packages.
That package would install itself into /etc/cron.daily and, when called,
check the age of each installed data table and update if necessary.
Having this service centralized would avoid a debconf script for each
package to ask the user several times for if he wants to auto-update
that table.

The name and the description of the package would make it clear that it
will access the data via net.

The update script itself could even be distributed with the casacore
package itself. And for simplicity I would make
casacore-data-autoupdater a binary package within the casacore source
package (since this is the main dependency anyway).

Comments on that? What would be the best dependency specification then?
casacore-data-autoupdater "suggests" casacore-data-XXX and/ore vice-versa?

> Make sure that any security/privacy consequences of the non-apt update
> method are dealt with.

If you have comments on my proposal, please comment.

Best regards

Ole