Re: timezone data packaged separately and in volatile?
Denis Barbier a écrit : On Wed, Mar 01, 2006 at 03:22:50PM +0100, Aurelien Jarno wrote: Lionel Elie Mamane a écrit : - glibc maintainers, would you approve of such an update to a point release of sarge? I am *one* of the glibc maintainer, and I agree in principle with such a change, though I haven't look very deeply at your patch (will do that later). I hope other glibc maintainers will give their opinion there. Ditto, but this should be done for all sarge stable releases, which is a lot of work. IMO splitting timezone data into a seperate package in the next sarge release would help future releases, if this is allowed by our stable RMs. Well I am currently trying to split the glibc to not have libraries and binaries in the same package (that will be a problem for multiarch). While I am doing that, I can also put the timezone data in a separate package. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, 16 Mar 2006, Aurelien Jarno wrote: Well I am currently trying to split the glibc to not have libraries and binaries in the same package (that will be a problem for multiarch). While I am doing that, I can also put the timezone data in a separate package. Please do. That will be a good start. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Mar 16, 2006 at 10:56:36AM +0100, Aurelien Jarno wrote: Denis Barbier a écrit : Ditto, but this should be done for all sarge stable releases, which is a lot of work. IMO splitting timezone data into a seperate package in the next sarge release would help future releases, if this is allowed by our stable RMs. Well I am currently trying to split the glibc to not have libraries and binaries in the same package (that will be a problem for multiarch). While I am doing that, I can also put the timezone data in a separate package. Here is my ballot - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- f249d253-188a-efc8-9428-fdacc5269436 [ 2 ] Choice 1: Ship a new binary package for timezone data [ 3 ] Choice 2: Keep timezone data along with the C library [ 1 ] Choice 3: Ship a seperate source package for timezone data [ 4 ] Choice 4: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Please note that this is a general issue and has nothing to do with #356148. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Wed, Mar 01, 2006 at 03:22:50PM +0100, Aurelien Jarno wrote: Lionel Elie Mamane a écrit : - glibc maintainers, would you approve of such an update to a point release of sarge? I am *one* of the glibc maintainer, and I agree in principle with such a change, though I haven't look very deeply at your patch (will do that later). I hope other glibc maintainers will give their opinion there. Ditto, but this should be done for all sarge stable releases, which is a lot of work. IMO splitting timezone data into a seperate package in the next sarge release would help future releases, if this is allowed by our stable RMs. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Lionel Elie Mamane a écrit : On Thu, Feb 09, 2006 at 07:42:25PM +0900, GOTO Masanori wrote: To get things rolling, I have prepared an updated glibc for sarge with just the timezone data updated to the latest upstream upstream. It is at http://people.debian.org/~lmamane/glibc/ . Technically right now it is correct neither as a NMU (wrong version number, not mentioned in changelog), nor as MU (because I'm not a glibc maintainer). http://people.debian.org/~lmamane/glibc/glibc_22-sarge0.diff is the interdiff (the difference between what's now in sarge and what I've prepared). So: - glibc maintainers, would you approve of such an update to a point release of sarge? I am *one* of the glibc maintainer, and I agree in principle with such a change, though I haven't look very deeply at your patch (will do that later). I hope other glibc maintainers will give their opinion there. If yes, shall I make an NMU of it or shall you prepare a package (replace my -- line in the changelog by one of yours) and submit it to joey? - Martin, would you take such an update if approved or submitted by the glibc maintainers? Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Feb 09, 2006 at 07:42:25PM +0900, GOTO Masanori wrote: At Tue, 7 Feb 2006 14:30:01 +1100, Anand Kumria wrote: On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. Note that I was planning to separate timezone package from glibc package (but I forgot it). It'll be available by the next release, etch. To get things rolling, I have prepared an updated glibc for sarge with just the timezone data updated to the latest upstream upstream. It is at http://people.debian.org/~lmamane/glibc/ . Technically right now it is correct neither as a NMU (wrong version number, not mentioned in changelog), nor as MU (because I'm not a glibc maintainer). http://people.debian.org/~lmamane/glibc/glibc_22-sarge0.diff is the interdiff (the difference between what's now in sarge and what I've prepared). So: - glibc maintainers, would you approve of such an update to a point release of sarge? If yes, shall I make an NMU of it or shall you prepare a package (replace my -- line in the changelog by one of yours) and submit it to joey? - Martin, would you take such an update if approved or submitted by the glibc maintainers? Best Regards, -- Lionel signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
Am 2006-02-07 14:40:52, schrieb Ian Jackson: 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). That seems to be true in this case. I think a system which gets the clock wrong in this way is `overly broken'. And if you have scheduler which take critical operations (erasing of files or or something similar) it would be critical. There doesn't seem to be anything in those rules which allows for an analysis of the risk, so that it can be compared to the benefit. (Perhaps that's implicit, although it's not stated.) A timezone update, carefully built against the right dependencies, could be diffed (that is, the .deb could be diffed) against the old version and carefully tested, which would provide us with confidence that the new package is right to install. I have an international database where I need correct timezones. Currently I have a server side script for Australian $USERS. Ian. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Feb 09, 2006 at 07:42:25PM +0900, GOTO Masanori wrote: At Tue, 7 Feb 2006 14:30:01 +1100, Anand Kumria wrote: On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. Note that I was planning to separate timezone package from glibc package (but I forgot it). It'll be available by the next release, etch. Excellent! Thank you. Do you mean in a separate source package or in a binary package generated by glibc? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
At Tue, 7 Feb 2006 14:30:01 +1100, Anand Kumria wrote: On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: Hi, I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. Note that I was planning to separate timezone package from glibc package (but I forgot it). It'll be available by the next release, etch. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. The underlying technical issue that volatile is working around is that the stable release manager isn't interested in ensuring that a stable release is both functional and secure (btw: has anyone asked him to confirm this?; I'm just working on the 'general assumptions' here). These goals are not inherently opposed to each other. I'd rather work through the existing stable release process first, then resort to a work-around. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
[ debian-volatile dropped ] Hi Daniel, On Mon, Feb 06, 2006 at 11:41:26PM -0500, Daniel Jacobowitz wrote: On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? Once a package is available we can start talking to the stable release manager to see what his position is. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 07:52:15PM +1100, Anand Kumria wrote: On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. You feel yourself at war with volatile because the volatile team didn't accept a fully new upstream version of gtk-gnutella - which was never the idea behind volatile. Volatile is not just one more place for backports. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
2006/2/7, Anand Kumria [EMAIL PROTECTED]: It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ It's quite clear it's not a security bug. Whether it leads to critical data loss or an overly unusable system is debatable. It's just that the clock will be off by an hour for a few weeks. Hardly the end of the world, people run with the clocks on their machines off by months and it doesn't seem to break anything critical. ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Past policy has been that stable updates don't cover things that arn't critical, even if it makes us look out of date compared to other distributions. A change to that policy should be carefully considered before doing it... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: timezone data packaged separately and in volatile?
* Martijn van Oosterhout ([EMAIL PROTECTED]) [060207 14:09]: ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Well, if we *have* files at $location that can be used for this, and that allow updates to etch, these files can directly be put into volatile. The round-trip time for such an update is less than 24 hours, if all relevant people (in this case: the glibc people) agree on how to do it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
* Ian Jackson wrote: Martijn van Oosterhout writes: The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). That's why I'm wondering abount the mutt 1.5.9-2sarge1 reject... it also fixes possible data loss. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Martijn van Oosterhout writes (Re: timezone data packaged separately and in volatile?): The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). That seems to be true in this case. I think a system which gets the clock wrong in this way is `overly broken'. There doesn't seem to be anything in those rules which allows for an analysis of the risk, so that it can be compared to the benefit. (Perhaps that's implicit, although it's not stated.) A timezone update, carefully built against the right dependencies, could be diffed (that is, the .deb could be diffed) against the old version and carefully tested, which would provide us with confidence that the new package is right to install. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Hi Daniel, On Monday, 06 Feb 2006, you wrote: On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. I talked to Joey another day, and he said, we should mail him about, and he will decide if this could go in via a point release. I hearby mail him (CC). Lets see what happens. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:57:54AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? I don't understand your English, perhaps you could rephrase or clarify? As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Again, those statements don't make any sense to me. Either by themselves or in the context my what you've quoted. Could you rephrase or clarify. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: Hi, I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
timezone data packaged separately and in volatile?
Hi,
I just realised that the timezone data in glibc is taken from an
upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data
sometimes changes, more rapidly than our release cycle (and than any
release cycle we can reasonable have).
Examples include the Cuba no stop to daylight saving nearly
last-minute change in November 2005 (affecting changes effective
1 October 2005) or the upcoming Indiana changes (to be effective in
April 2006) that got into the database on 30 January 2006.
Currently, for these changes to propagate to Debian, these delays
occur:
- upstream glibc synchronises with their upstream (this took about
month and a half for the Cuba example).
- glibc release (or Debian packages CVS snapshot or Debian glibc
patched for newer upstream upstream release)
- Debian packages glibc release, with all portability issues and
all.
- Debian release
What I propose, due to the somewhat tight schedule sometimes in play:
- Package the timezone data as a separate (source+binary) package
tzdata, directly from glibc's upstream.
- Put that package in volatile.debian.net .
This would allow updating the timezone data, that is subject to
short-delay political changes, independently from the sensitive
libc6{,.1} package. And thus have it in volatile :)
The tzdata package could be the only source of timezone data (and
libc6{,.1} would depend on it, it would be required, essential) or
libc6{,.1} could still ship its copy, which would be diverted by
tzdata and replaced by its newer copy. In the second scenario, I'd
imagine tzdata to be of priority important or standard and installed
by default on new installs (maybe suggested / recommended by
libc6?). Probably making it simple and taking the first solution would
be best.
libc6 currently Replaces: timezone, timezones, which suggests that
we were doing something like that before but we moved away from this
solution. Why?
The Debian glibc maintainers seem to sometimes go to a newer-than
upstream tzdata release in the Debian patch.
Is there any issue I'm missing? Thoughts?
--
Lionel Elie Mamane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, 02 Feb 2006, Lionel Elie Mamane wrote: I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). See the tz-brasil package for the current solution we have for the problem of widely variable timezones. Brazil's tz gets updated in unpredictable ways, sometimes more than twice a year and with little prior notice. That package is far from perfect (I personally don't agree with a lot of what it does), but it might give you a few ideas. Bottom line: you do not need to package the timezones in volatile. You can also have the timezones available from download, and a normal, stable package that downloads that data, validates it, and applies it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/2006 12:35 AM, Henrique de Moraes Holschuh wrote: On Thu, 02 Feb 2006, Lionel Elie Mamane wrote: I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). See the tz-brasil package for the current solution we have for the problem of widely variable timezones. Brazil's tz gets updated in unpredictable ways, sometimes more than twice a year and with little prior notice. That package is far from perfect (I personally don't agree with a lot of what it does), but it might give you a few ideas. Bottom line: you do not need to package the timezones in volatile. You can also have the timezones available from download, and a normal, stable package that downloads that data, validates it, and applies it. We raise that question in #debian-volatile (OFTC) another day... Brasil and Cuba are countries that are directly affected by this kind of situations, the governments does no use a fixed schedule for DayLight Savings... Brasil has even another problem that is related with the TimeZones names, pzn (Pedro Zorzenon Neto) the maintainer of tz-brasil has sent a RFC to try to define these names, but looks like it has expired. If we split timezones from libc, volatile looks like a very good approach to handle that updates, since we can have to update it a couple of times until the next release. I'm not sure but a timezone update does not fit in security update category (could be possible), but a package update throught a repository looks much more interesting than having a package pulling data files from people.d.o like tz-brasil does. In fact, if you consider offline situations and conditions without access to people.d.o or another site with the data files, having a pre-downloades package (like a CD with updates) is pretty handy and easier to administer. And Volatile Team takes very good care of packages that are in volatile, considering that, you can also have a normal, stable package that updates that data without need extra downloads. Above all, do no harm. :-) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFD4tdUCjAO0JDlykYRAmH9AJ9DHFwtD1p9g4+cEexXP8rNYRPyVgCeM7tx uitvHQhAnnfYcqZHUKoS+LU= =KfJX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Fri, Feb 03, 2006 at 02:08:52AM -0200, Felipe Augusto van de Wiel (faw) wrote: On 02/03/2006 12:35 AM, Henrique de Moraes Holschuh wrote: On Thu, 02 Feb 2006, Lionel Elie Mamane wrote: I just realised that the timezone data in glibc is taken from an upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data sometimes changes, more rapidly than our release cycle (and than any release cycle we can reasonable have). See the tz-brasil package for the current solution we have for the problem of widely variable timezones. Brazil's tz gets updated in unpredictable ways, sometimes more than twice a year and with little prior notice. That package is far from perfect (I personally don't agree with a lot of what it does), but it might give you a few ideas. Bottom line: you do not need to package the timezones in volatile. You can also have the timezones available from download, and a normal, stable package that downloads that data, validates it, and applies it. We raise that question in #debian-volatile (OFTC) another day... Brasil and Cuba are countries that are directly affected by this kind of situations, the governments does no use a fixed schedule for DayLight Savings... Brasil has even another problem that is related with the TimeZones names, pzn (Pedro Zorzenon Neto) the maintainer of tz-brasil has sent a RFC to try to define these names, but looks like it has expired. Australia has this problem this year as the Daylight Saving Time (DST) will be extended for one more week for the 2006 Commonwealth Games. In 2007 it will revert to what it was before. The following links could be useful to people in Australia. http://www.australia.gov.au/335 http://www.info.vic.gov.au/resources/daylight.htm http://www.lawlink.nsw.gov.au/lawlink/Corporate/ll_agdinfo.nsf/pages/community_relations_daylight_saving http://www.workcover.act.gov.au/docs/summer.htm http://www.dpac.tas.gov.au/divisions/policy/daylightsavings/ http://www.safework.sa.gov.au/show_page.jsp?id=2675 If we split timezones from libc, volatile looks like a very good approach to handle that updates, since we can have to update it a couple of times until the next release. I'm not sure but a timezone update does not fit in security update category (could be possible), but a package update throught a repository looks much more interesting than having a package pulling data files from people.d.o like tz-brasil does. In fact, if you consider offline situations and conditions without access to people.d.o or another site with the data files, having a pre-downloades package (like a CD with updates) is pretty handy and easier to administer. And Volatile Team takes very good care of packages that are in volatile, considering that, you can also have a normal, stable package that updates that data without need extra downloads. Above all, do no harm. :-) Kind regards, -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! Aníbal Monsalve Salazar -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- http://v7w.com/anibal signature.asc Description: Digital signature
