Ole Streicher writes:
> We need it to put correct time on astronomical registrations, so it is
> most important to have them once they are effective. Having them in
> advance would be an additional plus, however, since f.e. a computer may
> be disconnected during/after the observation, if that ha
On 10/31/2016 10:30 AM, Ole Streicher wrote:
> debian/triggers --
> interest /usr/share/zoneinfo/leap-seconds.list
> ---8<--
>
> However, I now get the following error when I try to update tzdata:
>
> dpkg: cycle
Paul Wise writes:
> 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
>>
Christian Seiler writes:
> On 10/31/2016 09:07 AM, Ole Streicher wrote:
[leap seconds]
>> We need it to put correct time on astronomical registrations, so it is
>> most important to have them once they are effective. Having them in
>> advance would be an additional plus, however, since f.e. a comp
On 10/31/2016 09:07 AM, Ole Streicher wrote:
> Russ Allbery writes:
>> The required timeliness depends a lot on what you're using leap seconds
>> for, and in particular if you need to know about them far in advance, or
>> if it's only necessary to have an updated table before the leap second
>> it
Russ Allbery writes:
> The required timeliness depends a lot on what you're using leap seconds
> for, and in particular if you need to know about them far in advance, or
> if it's only necessary to have an updated table before the leap second
> itself arrives.
We need it to put correct time on as
Christian Seiler writes:
> On 10/30/2016 10:20 AM, Ole Streicher wrote:
>> IETF is responsible for internet standards, not for leap seconds. They
>> will take the leap seconds from IERS. I would assume that this
>> connection is well-established to rely on it. I was not so much
>> questioning ups
On 30.10.2016 04:38, Paul Wise wrote:
> On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote:
>> 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
>> packag
On 10/30/2016 10:20 AM, Ole Streicher wrote:
> IETF is responsible for internet standards, not for leap seconds. They
> will take the leap seconds from IERS. I would assume that this
> connection is well-established to rely on it. I was not so much
> questioning upstream here, but I worry a bit abo
On 30.10.2016 04:42, Paul Wise wrote:
> On Sun, Oct 30, 2016 at 4:36 AM, Ole Streicher wrote:
>
>> The canonical source for leap seconds is the IERS. Our current plan was
>> to take the leap second list from there and build our package from this
>> (as it is done in the casacore-data upstream). Th
On Sun, Oct 30, 2016 at 4:36 AM, Ole Streicher wrote:
> The canonical source for leap seconds is the IERS. Our current plan was
> to take the leap second list from there and build our package from this
> (as it is done in the casacore-data upstream). This guaranteed that we
> always have the actua
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 a
Ben Finney writes:
> Ole Streicher writes:
>> 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 a
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
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
On Fri, Oct 28, 2016 at 8:09 PM, Alec Leamas wrote:
> I wonder i the very idea to package this data is the correct one. What if
> you instead package an update service which is able to download all required
> data and make it available somewhere under /var/lib i. e., not in any
> package at all? A
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, o
On 28/10/16 12:38, Ole Streicher wrote:
Hi,
My question is now how to provide a good and consistent packaging:
Usually, one would just put the data into a package. This works nicely
for the immutable data, and reasonably for the slowly changing data. The
fast changing data shall be available
Hi,
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 o
19 matches
Mail list logo