2007/10/1, Peter Samuelson [EMAIL PROTECTED]:
What upstream does, and whether the upstream license requires source,
are not valid arguments for whether we're meeting the DFSG. There are
many packages in Debian that have to be altered to comply with the
DFSG.
I don't know any example of
Hi,
On Monday 01 October 2007 11:01, Piotr Roszatycki wrote:
I don't know any example of package which has included some additional
sources because the upstream didn't provide real-sources for its
sources.
typo3-src is an example. Upstream doesn't provide the source for a font it
ships.
2007/10/1, Holger Levsen [EMAIL PROTECTED]:
I don't know any example of package which has included some additional
sources because the upstream didn't provide real-sources for its
sources.
typo3-src is an example. Upstream doesn't provide the source for a font it
ships.
Search for
On Mon, Oct 01, 2007 at 03:11:05PM +0200, Piotr Roszatycki wrote:
I think it is because the nimbus font is released on GPL license, so
the source code is required. The Olson DB is public domain so its
license does not exact the shipping of source form.
The DFSG requires us to ship the source
2007/10/1, Hamish Moffatt [EMAIL PROTECTED]:
I think it is because the nimbus font is released on GPL license, so
the source code is required. The Olson DB is public domain so its
license does not exact the shipping of source form.
The DFSG requires us to ship the source though. Clause 2.
On Mon, 01 Oct 2007, Piotr Roszatycki wrote:
2007/10/1, Hamish Moffatt [EMAIL PROTECTED]:
I think it is because the nimbus font is released on GPL license, so
the source code is required. The Olson DB is public domain so its
license does not exact the shipping of source form.
The
2007/9/29, Peter Samuelson [EMAIL PROTECTED]:
I just downloaded the source package for libdatetime-timezone-perl, and
I don't see the Olson database in there anywhere. Where is it? It
looks to me as though you aren't shipping the real source for your
package, neither directly nor via
[Piotr Roszatycki]
Even upstream don't ship the Olson database. I'm not conviced that we
should ship Olson database.
[...]
The Olson database is public domain and it doesn't require to be
distributed as real source.
What upstream does, and whether the upstream license requires source,
are
On Oct 01, Peter Samuelson [EMAIL PROTECTED] wrote:
If enough packages need to do this same thing, it would make sense for
tzdata to ship a tzdata-source binary package to be build-depended on.
It looks like you may have missed the arm firmware thread of yesterday...
--
ciao,
Marco
[Marco d'Itri]
If enough packages need to do this same thing, it would make sense for
tzdata to ship a tzdata-source binary package to be build-depended on.
It looks like you may have missed the arm firmware thread of yesterday...
No, I caught that thread, but thanks for your concern. It
[Piotr Roszatycki]
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]:
will that cause dfsg problems?
Not at all. The packages was built with pbuilder. It still is not
fully understandable, so I'll try explain:
I just downloaded the source package for libdatetime-timezone-perl, and
I don't
Hi,
On Wed Sep 26, 2007 at 00:20:10 +0200, Piotr Roszatycki wrote:
You made a subtle mistake. You checked the source package for tzdata
and the changes are really small. Then you checked the differences for
libdatetime-timezone-perl package, but this source package is already
compiled. You
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]:
Accepted now.
Thank you very much.
For the future: i would have been much easier, if you would have said:
be warned, the patch is huge, but if you don't look at the compiled
version of it, it is these number of lines...
Both of us would have
Piotr Roszatycki wrote:
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]:
Accepted now.
Thank you very much.
For the future: i would have been much easier, if you would have said:
be warned, the patch is huge, but if you don't look at the compiled
version of it, it is these number of
Hi,
On Wed Sep 26, 2007 at 14:46:16 +0200, Piotr Roszatycki wrote:
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]:
Accepted now.
Thank you very much.
For the future: i would have been much easier, if you would have said:
be warned, the patch is huge, but if you don't look at the
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]:
I think we could communicate better if you read the patch, not just
statistics about it. By the way, the patch itself does not contain the
real source data - the Olson database. I understand that it might be
will that cause dfsg problems?
The Debian volatile archive is the place for packages that expires
before new Debian release. The description perfectly fits for my
package libdatetime-timezone-perl.
I prepared a few weeks ago new releases for sarge and etch. The
release is based on old packages which have refreshed just
Hi Piotr,
On Tue Sep 25, 2007 at 14:10:58 +0200, Piotr Roszatycki wrote:
The Debian volatile archive is the place for packages that expires
before new Debian release. The description perfectly fits for my
package libdatetime-timezone-perl.
I prepared a few weeks ago new releases for sarge
Ah... Do you mean this mail?
am I missing something completely here?
[EMAIL PROTECTED]:~/debian/packages$ diff -rNu
libdatetime-timezone-perl-0.42-before-dv/ libdatetime-timezone-perl-0.42 |
diffstat
changelog|9
control |
Piotr Roszatycki wrote:
After 30th of September the timezone data for New Zealand will be not
correct (Bug#440258). The users who rely on Debian package will notice
that something goes wrong.
Based on the description (and not the patch) it seems to me that this
kind of change should be in the
Hi,
On Tue Sep 25, 2007 at 14:55:47 +0200, Piotr Roszatycki wrote:
Ah... Do you mean this mail?
am I missing something completely here?
[EMAIL PROTECTED]:~/debian/packages$ diff -rNu
libdatetime-timezone-perl-0.42-before-dv/ libdatetime-timezone-perl-0.42
| diffstat
changelog
It's not about one timezone. The new release refresh all available
timezones. The whole package was synced with the latest Olson
database.
It is simple analogy for tzdata package. You should also ask, why the
tzdata package has so many changes and why don't simply update only
one timezone?
On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote:
It's not about one timezone. The new release refresh all available
timezones. The whole package was synced with the latest Olson
database.
It would be good if you fixed #416206, and used tzdata yourself. So
that we only need to
It is almost impossible.
The DateTime::TimeZone is pure Perl library and can't use binary data
from tzdata package. In fact, this library can be used on systems
without libc6 and tzdata at all! You wrongly assume that tzdata
package is more important than libdatetime-timezone-perl package. It
can
On Tue, Sep 25, 2007 at 09:48:19PM +0200, Piotr Roszatycki wrote:
It is almost impossible.
The DateTime::TimeZone is pure Perl library and can't use binary data
from tzdata package. In fact, this library can be used on systems
without libc6 and tzdata at all! You wrongly assume that tzdata
It is already such library called DateTime::TimeZone::Tzfile. It is
not packaged yet, but... It is different story. We still talk about
DateTime::TimeZone. Even if it should be replaced with newer, better
and faster libraray, it is ALREADY in etch and sarge.
The Debian supports the packages which
Hi,
On Tue Sep 25, 2007 at 17:36:03 +0200, Piotr Roszatycki wrote:
It is simple analogy for tzdata package. You should also ask, why the
tzdata package has so many changes and why don't simply update only
one timezone?
[EMAIL PROTECTED]:~% diff -rNu tzdata-2007b tzdata-2007f | diffstat
You made a subtle mistake. You checked the source package for tzdata
and the changes are really small. Then you checked the differences for
libdatetime-timezone-perl package, but this source package is already
compiled. You should check the difference between binary packages for
tzdata.
The real
28 matches
Mail list logo
