Debian Refuses To Push Timezone Update For NZ DST

Jasper Bryant-Greene writes "Although a tzdata release that includes New Zealand's recent DST changes (2007f) has been out for some time, Debian are refusing to push the update from testing into the current stable distribution, codenamed Etch, on the basis that 'it's not a security bug.' This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually, all systems running Debian Etch in New Zealand currently have the incorrect time, as DST went into effect this morning. As one of the last comments in the bug report says, 'even Microsoft are not this silly.' The final comment (at this writing), from madcoder, says 'The package sits in volatile for months. Please take your troll elsewhere.'"

So there are no time based security attacks?

Assuming there are, or even the possibility that one could be crafted, it seems quite justifiable to call this a security fix. And aside from that, it's just dumb not to include it.

Re:So there are no time based security attacks?

It's in volatile (where it should be), it's just one line in /etc/apt/sources.list, which should probably already be there and an apt-get update && apt-get -u install tzdata

done.

Re:So there are no time based security attacks?

I understand the reasoning behind putting it in volatile, but why not enable volatile by default during installation?

Debian is considered the stable distribution. They move glacially slow, and are, if you use their stable repo, stable as hell. If you want bleeding edge by default, install their bleeding edge version.

Otherwise, if you want Debian, install Debian.

Oh, and in response to the even-Microsoft-would-not-be-so-foolish comment: Of course not. They demonstrated their level-headed thinking when they charged $4000 for a time zone update for Windows 2000. A server OS. When you can do it for free [slyck.com] if you know how. Debian should charge NZers $4000 Canadian (OUCH!), then they would be respected.

Re:So there are no time based security attacks?

The daylight savings patch you posted is more work than is required.Here is a link to one that works on NT-2003 and requires but a single click.Oh,and they have one for 9X that does the same.http://www.intelliadmin.com/Downloads.htm [intelliadmin.com]. Look under freeware downloads

That said,being a fan of Debian based OSs,I'm wondering why they are doing this. Does this patch cause crashes? System instability? If not it seems a disservice to their NZ users not to have it in their standard repository.

Re:So there are no time based security attacks?

This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.

The point is, stable is supposed to be stable, and only changed for very good cause (which this is), and then only after considerable testing...which this hasn't had. An exception is made for security fixes because it's considered *necessary* to patch vulnerabilities. Otherwise, no. Even if you don't see how it could cause a problem, you don't include changes without considerable review and testing. That's what stable means.

OTOH, if you choose to import it from another repository...it's your choice. And simple to do. (I'll grant that I don't understand the "volitile" response. The repositories I'm aware of are stable, testing, unstable, and experimental. Presumably volitile has something to do with the stable branch.)

Given all that...I don't see how the timezone file could cause a problem, and I don't see why it should have set in the volitile repository for weeks. Perhaps nobody would test it before they needed it?

Re:So there are no time based security attacks?

This is the debian *STABLE* branch. In testing I imagine they would do it quickly...well, within a week.

Sure, and if you want to put up with the possibility that, eg, trying to use tab-completion will cause your shell to dump core then, by all means, use testing.

'Stable' cannot, in the real-world really mean 'nothing changes except security updates'. The world does not work like that, as this demonstrates.

Re:volatile explained

BTW, adding 1 line to your /etc/apt/sources.list seems a fairly simple way to get the patch, so what *is* the problem here? Don't want to understand how your OS deals with certain things, then don't use Debian.

There's a lot I don't understand about the things I use in my day to day life but I still use them. Micro-managing one's operating system is a foolish waste of time and loss of productivity. My operating system exists to grant me access to the tools I've installed to perform tasks relevant to my daily life and career. This is something that should be done right the first time without any political nonsense getting in the way. A timezone patch not stable? Now I've heard it all. Next thing you know my /etc/issue file will be unstable.

Re:So there are no time based security attacks?

Debian is considered the stable distribution.

The way it was explained to me, Debian is the stale distribution.

Volatile versus update

It's in volatile (where it should be)

The whole FA is a big mis-understanding of what the various repositories are and what they purpose are.

• stable - litteraly means stable, as in mountain rocks. Once a distribution hits this status, it normally shouldn't change a bit.
• non-US - the USA have some pretty wierd laws concerning patents and cryptography. There are a lot of software that can be made available in the USA (because it infringes patent that can only exist in the USA system, or because it is a cryptographic software whose strengh is declared too high and considered as a weapon), but the same software can safely be used everywhere else in the world. non-US contains software that is as imuable as stable, but that is specifically banned in the USA.
• updates or security - as it names implies, standart updates release for stable version of debian, only provide fixes to bugs that could be abused for exploits. All fixes retain the same exact version, only patching the hole (i.e.: firefox 2.0.0.1 isn't upgraded to firefox 2.0.0.6. Instead it's iceweasel 2.0.0.1-1 that is patched to 2.0.0.1-2 the exact same source code, except for the security fix). In the very unlikely case that after 3 fucking years of development in testing state, there is still a bug that prevents a program to start, the corrected version (same version just patched) will appear here.
• volatile - this are packages that can change version, because their functionnality needs it. Virus scanning engine clamav is there for exemple (because to catch new threats, some times the engine it self needs to be updated, not only the signatures). Timezone goes there too (a computer won't be hacked with a bad timetable. therefore it's not in security)
• volatile-sloppy - for non critical upgrades. Gaim/Pidgin goes there for exemple. It's not critical to the function of the computer, but never the less, IM network companies like microsoft regularily changes their protocoles just to break compatibility with 3rd party clients. Thus clients needs to be upgraded to newer versions from time to time. But because newer version MAY break some compatibility with older distribution, older config files, or old user scripts, it is separated from volatile.
• backports - newer version of software, for those who constantly whine because Debian release are 3 years appart. Usually it's package from testing recompiled in stable environment
• testing - This is much closer to what other distribution call a release. It has more up to date packages, but isn't completly bleeding edge, is somewhat stable. This will become the next stable once everyone in debian is happy and decide to definitely freeze it
• vendors, like samba or 3rd parties maintain their own repositories with software compiled against stable, if you like updating your software to latest version.

More information about voltile, at the corresponding debian site [debian.org].

Debian is quite popular among some admins because of this. You know, once you install debian on a server, that your installation will still get critical security fixes for the next 3-4 years. But nothing else will change a bit. 0% chance that an upgrade may break your configuration file. 0% risks that all the scripts that you manually wrote will suddenly stop functionning because of subtle differences between version 1.8.6.9 and 1.8.6.10 in some obscure software. (which are things that could occasionally happen with other distribution ) NO dependency hell once you start using updated software (like a 3rd party repository targeting a library version 2.0.9, but the distro having updated to 2.0.11. Very rarely it can happen between openSUSE and packman).

But as AC said in this thread, maybe the installation procedure of Debian should give

Re:Volatile versus update

But nothing else will change a bit. 0% chance that an upgrade may break your configuration file. 0% risks that all the scripts that you manually wrote will suddenly stop functionning because of subtle differences between version 1.8.6.9 and 1.8.6.10 in some obscure software.

And a 100% chance that a change in your timezone will cause your servers to suddenly have the wrong time (assuming default configuration).

No thanks, I'll stick to a platform with a more sane balance between platform stability and not breaking things.

Re:Volatile versus update

I solved this problem by changing wholesale to GMT/UTC on all of our servers, Linux and Windows. Now we never have to worry about another stupid DST or TZ change again, including MS charging $4K for a patch that should be free. It also makes life easier for people outside our TZ who use our servers.

I just learned that I go to work at 3pm in the morning and head home at 11pm. It's not hard. I wish the world would switch to GMT, it would make everything so much easier. Businesses can have summer hours if they wish to take advantage of the longer days.

Of course, the desktops are all still on local time. There would be a pitchforks-and-torches uprising if you tried to change that. ;)

Re:Volatile versus update

Maybe he said 'fucking' because he fucking wanted to.

Re:Volatile versus update

I think the participle fucking quite succinctly and accurately described the combination of amazement and frustration the author of the post intended to convey. It really is a useful word that can express complex emotion concisely: truly in the spirit of Strunk & White's rule 13.

Re:Volatile versus update

People who reduce themselves to bitching about curse words contribute nothing to the conversation at hand.

Re:Volatile versus update

Hehe. Yeah, those fuckers. :)

Re:Volatile versus update

In the very unlikely case that after 3 fucking years of development

This was a good post, but it's a pity that your command of English is so limited that this gratuitous vulgarity is the best adjective you could choose.

Well, I fixed it for you:

In the very unlikely case that after 3 sex abstinence years of development

That's what you meant, right.. At least I think you did :P ?

Re:So there are no time based security attacks?

No, see we take fractions of a penny from each transaction and put them all into one account...

Re:So there are no time based security attacks?

the sensationalist /. summary asside lets get some facts.

it is not a security update so it doesn't go in the security repositry
it is already in the volatile repositry
it is already in etch-pryoposed-updates which means it will probablly be in the next point release of etch

pushing a point release of stable is not something that has been taken lighly, lots of CDs to build and push out to mirrors, lots and lots of testing.

Sure the US changes got better treatment, how much of that was luck and how much of it was being one of the largest (in terms of computer using population) countries arround is hard to tell.

If you can't live with the way debian stable releases work choose another distro. If you can't manage your IT infrastructure such that deploying local patches is not unreasonably difficult fire your IT staff.

Re:So there are no time based security attacks?

If you can't live with the way debian stable releases work choose another distro.

Many organizations have and will continue to do so. Thanks for the advice.

If you can't manage your IT infrastructure such that deploying local patches is not unreasonably difficult fire your IT staff.

When backports and patches amass to the point where a smooth upgrade path to the next major release is no longer possible, it's time to start laughing at the militant ignorance of the distribution's maintainers and adherents.

In defense of the Debian team...

... maybe it just isn't time.

Debian keeps getting sillier every day.

They've taken a perfectly good distribution and absolutely destroyed its reputation thanks to their management's ineptitude.

Re:Debian keeps getting sillier every day.

I dont think the correct time is a bleeding edge feature is it?

Re:Debian keeps getting sillier every day.

You're right, it's not bleeding-edge but rather a volatile feature. Hence the fix is in volatile [debian.org], just like TFS says.

It all sounds like a shitstorm in a chamber pot to me.

Is it a security update?

Some systems may rely on the "wrong" timezone for their continued operation, so if it is indeed not a security update, and the policy for automatic updates is "security only", then not pushing the update is correct. If you need the timezone update, get it. It's not like they hide it from you.

Re:Is it a security update?

So pray explain why they pushed a timezone update for the US changes earlier in the year?

It's not that the updates aren't going to be made, it's just that they're made via point releases, not security updates because they aren't a security bug.

If you don't want to wait for a point release, the packages have been made available already via volatile and the backports area. It's trivial to add these to your sources.list and install the updated package.

the reputation of Debian is being ruined by the ineptitude and down right stupidity of the management.

You seem to not understand how Debian actually works. The management of Debian, such as it is, are the actual developers; the people who actually sit down and do the work. If you don't like the decisions that they make, you have two choices: jump in and help out or choose to use something different. The former will enable you to make decisions in the areas you work in, the latter means hoping that someone else is going to make decisions that you agree with. Choose whichever you prefer; presuming to dictate to those who actually are doing the work isn't one of those choices.

Apple are just as bad

They haven't rolled out a patch for OSX either. There are several folks on Apple in NZ who are just as disappointed.
Meanwhile, Microsoft rolled out a patch on Windows Update - Microsoft users on Automatic Updates rolled over without even knowing anything had changed.

Debian actually did release it for Stable. It's in

It's in volatile repository.

Volatile is specificly designed to take into account things like this. It's for updates to packages, like anti-virus software, and similar things that change over time.

Nobody actually reads the fucking articles do they? The guy that posted the article is a troll and selectively took quotes out of context.

What SlashDot says:
"Although a tzdata release that includes New Zealand's recent DST changes (2007f) has been out for some time, Debian are refusing to push the update from testing into the current stable distribution, codenamed Etch, on the basis that 'it's not a security bug.' This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually, all systems running Debian Etch in New Zealand currently have the incorrect time, as DST went into effect this morning. As one of the last comments in the bug report says, 'even Microsoft are not this silly.' The final comment (at this writing), from madcoder, says 'The package sits in volatile for months. Please take your troll elsewhere.'"

What is actually in the Bug Report:
----SNIP----
The fix is already in the volatile archive (see
http://volatile.debian.org/ [debian.org] in the etch-proposed-update archive and it
will also appear in the next release of etch. Alternatively you can also
download the new version by hand and use dpkg -i.
----SNIP----

ALSO:
----SNIP----
>>> I would recommend re-opening this bug and upgrading its severity until the fix has been
>>> applied.
>> That won't change anything as it is now out of control of the glibc team.
>>
>
> And these mission-critical updates aren't put into security, why?
>

Because it's not a security bug.
----SNIP----

NO SHIT. It's _not_ a security bug. Why should the Debian Security team be forced to deal with something that is not security? Think about it for a whole two seconds.

The tzdata was updated a long time ago and is in a Debian repository that is specificly setup to deal with changes like this.
The person who filed the bug report doesn't like this and thinks that the package should be in the security fix repository.

It's fucking stupid. It's not a security bug. The package has been fixed for a long time. It doesn't have to be installed manually. It CAN be installed manually.

Get a grip people.

Re:Debian actually did release it for Stable. It's

This is what usually happens when something Debian-policy-related happens and is touted as silly:

1. I think: How silly of them. Just like Debian to do something stubborn and annoying like that.
2. Then I read the argumentation, the policy that led them to the decision.
3. I find myself agreeing with the policy and thus accepting the decision as the Right Thing.
4. I find someone, usually in the Debian project itself, has come up with a solution for those who don't like the decision.

The more time passes, the more I like Debian. They have policies that are good and they stick to them. When the policy causes them to do something that people don't like, they provide a workaround. With Debian, you can have your cake and eat it. Exclusively free software? Check. Proprietary software when you do want it? Check. Stable system that stays the same for years? Check. Recent versions of packages when you want them? Check. Support in the package manager for mixing and matching? Check. Oh, and they had dependencies figured out and working well long before any other distro I'm aware of. Debian isn't perfect, but it comes frighteningly close sometimes.

Re:Debian actually did release it for Stable. It's

That's why I love it too. I really don't like the distributions where you get a big bunch of packages as a release, which you are then basically stuck with until the next release (at which point you have to upgrade and cross your fingers, or reinstall). Like Ubuntu, you get a whole ton of packages, and there are always a few that have a subtle bug. But since you're on one release, you don't get the fix until six months later (of course, you can install it separately, but it's a pain). With Debian, if an app is broken in some way, I get the fix as soon as that developer releases a new version, without affecting any other package.

And it's really not that complicated to use. Even things like nvidia drivers are just a m-a autoinstall nvidia away. Sometimes it takes a while, but eventually I find Debian makes things like that very simple and integrated.

Re:Debian actually did release it for Stable. It's

The person who filed the bug report doesn't like this and thinks that the package should be in the security fix repository.

FTR, actually that's not the case. Someone else who stumbled onto the problem near the last minute doesn't like the fact that it didn't go into the main repository or security repository. I -- the person who filed the original bug -- am perfectly happy with the fix going into the volatile archive, and patched the servers I manage months ago. (I think it's rather unfortunate it missed the 4.0r1 point release, and unfortunate (but understandable) that there's no patch for Debian Sarge ("oldstable"), but otherwise the situation seems to have been handled fine. For Debian Sarge it works okay to take the NZ or Pacific/Auckland timezone file from a patched Etch system and put it onto the Sarge system.)

Ewen

probably not much of an issue

i would imagine anyone in New Zealand smart enough to install Debian is also smart enough to fix this manually...

Re:probably not much of an issue

Anyone who does business with New Zealand might not be aware of the change and the need to update their systems.

E.g. sites hosting NZ content outside of NZ, or even banks doing business with customers in NZ.

The change impacts the world and should be applied to all systems.

Re:probably not much of an issue

dropped debian for my home machines and work systems a long time ago. Ubuntu rocks me. It's everything good about debian (apt-get) without everything bad (debian policy, debian usability).

Stability-wise:
debian/stable > debian/testing > debian>unstable > ubuntu/released > debian/experimental > ubuntu/unreleased

Thus, for a home desktop which can break most of the time and where you want the bling, you can afford to run Ubuntu.

I do run Beryl at home, even though it breaks a lot. Beryl, not the new versions of Compiz which after all those months after merge are still a regression, both stability and usability wise. Yet, I wouldn't let it anywhere near a system which shouldn't break. Well, many people actually run Windows in places where stability matters, but I digress. And Ubuntu made Compiz the default...

Re:probably not much of an issue

> In this case: bling = my computer knowing what time it is.

If you're running debian then it was apparently updated automatically ages ago. The article seems to be about a bug reported by somebody who chose to turn off updates except for security fixes. Naturally, then, they didn't get this update - they then asked for these things to be considered security bugs in future.

I disagree with the bug reporter. Anywhere time is used in a security mechanism (and there are many) it should be using UTC or be robust against timesaving measures (eg, only be used for approximate deadlines to improve odds). In which case a timesaving change is not needed for security. Security bugs are therefore in the application not the time metadata (except adjustments to UTC which definitely *would* be security issues).

In short - debian users' arses (and clocks) are covered just fine.

Debian did the right thing

In my opinion, Debian did the right thing here.

This update is not security-related, so has no business being in the security update section. That's perfectly OK - Debian's security updates are completely safe to apply 99% of the time, because they do not change functionality. They only fix security bugs. Unlike Microsoft, Debian are not in the practice of shipping automatic updates that change functionality.

The update has been posted to the volatile repository, which is intended for things that change frequently, like timezone data. It can be installed from there right now - any of these people complaining could have simply installed the patch at any time over the past several months. The update has also been pushed to the updates repository, for inclusion in the next point release of Etch.

I don't see the problem here.

Re:Debian did the right thing

"This update is not security-related"

Yes, in fact, it is. Have you ever heard of log timestamps?

If it was a US daylight saving change

..you can bet it would have been pushed through.

Debian are refusing to push the update

And Debian is the plural for what...?

By the way, what are a Debian?

latest is 2007g

Note that even 2007g is out since August this year, including timezone updates for Egypt and Australia.

OB

This means that unless New Zealand sysadmins install the package manually

Imagine the overtime if both of them had to come in on a Saturday morning!

Re:OB

Their sheep will be so lonely.

With my FreeBSD hats...

As the person who did the latest timzeone updates to RELENG_5, RELENG_6 and HEAD (but not to the security-only branches RELENG_5_5 and RELENG_6_2) I say: They're right.
As the person who maintains the misc/zoneinfo port I say: They're right.

Well, kind of right and kind of wrong

Keep in mind that this conversation is from a subset of the Debian developers, the glibc team/group. They are correct in saying that this is not a security fix, and that's not how they planned on releasing the update. Its clear from this statement "It will go through etch/updates when the new point release will be issued, andwe missed the previous window because the bug was open a few days before the last release, and it couldn't make it sorry. So we pushed it in any other place we have access to, namely backports.org and volatile.debian.org (the latter is designed to fulfill updates of volatile packages, _LIKE_ timezone datas)." That the normal method of updating wasn't an option before the change took effect because the team missed the deadline. The wrong part of this that the patch for handling this change was completed at the of July and yet the Debian team was unable to get it into the normal release flow. Strangely enough the folks at Ubuntu seem to have gotten this handled much more rapidly, "2007f-0ubuntu0.6.10 Published in edgy-updates on 2007-08-03, Published in edgy-proposed on 2007-07-27".

This points to a wider problem...

abolish DST! It was silly in the early 1900s when the majority of workers worked in factories, mills, or on farms. It's sillier in 2007. Get rid of that stupidity once and for all.

Re:This points to a wider problem...

There have been studies that showed it doesn't really reduce energy usage. The only thing left is having more daylight for your picnics.

http://www.google.com/search?client=opera&rls=en&q=daylight+savings+time+doesn't+save+energy&sourceid=opera&ie=utf-8&oe=utf-8 [google.com]

Not until New Zealand decides...

... to allow Debian warships back in their ports.

What I find truly dumb....

...is daylight savings time.

Troll

> The final comment (at this writing), from madcoder, says 'The package sits in volatile
> for months. Please take your troll elsewhere.'"

He's right. That is exactly what volatile is for.

WTF

this article is about? It's about a sysadmin who's blaming Debian for not doing her job?
As it's clearly pointed out in the bug report, this package:
1) Has not a security bug, so does not belong to security-updates.
2) Was in volatile for a long time.
3) Is scheduled for the next release of etch.

debian-volatile is a repository for this type of packages (as virus lists, tzdata, et alter) that has information/data changes/updates often. If your time zone has changed or it's about to change, it's your responsability as a sysadmin to upgrade the packages, not Debian's. There were not a bug in tzdata.

Debian is one of the best distros out there, please contribute to make it even better by filling bug reports, but please take a minute to think about what you are doing, and read carefully the developers/mantainers posts or replys, because most of the time they're right.

pffft, linux really is for hackers....

Linux is really for command-line hackers only... setting the time zone manually... pft. what a disgrace for the IT world... :p

Heres how to update yourself

Updating your timezone data for daylight savings changes. [debian-adm...ration.org]...

Well, why dont you just..

.. install it manually, that is the job of the IT admin no?

Get your daily clue: learn what Debian volatile is

From http://volatile.debian.org/ [debian.org]: "debian-volatile will only contain changes to stable programs that are necessary to keep them functional".

Slashdot got trolled once again with a false story. Nothing unusual, and always deserved, but when it harms Debian's reputation in an area where it used to be at fault but now does the proper thing, it's just irritating.

The real culprit here

Can't we put the blame here where it belongs: on the idiots who keep foisting Daylight Saving Time nonsense on us? For god's sake, people, if you think there's some benefit in waking up at a different time of day, then change your freaking alarm time, not the time time.

Re:The real culprit here

All the commercial OSs release the update, yet someone that controls something that is non-profit decides he is right and everyone else is wrong. The reason the commercial OSs release it? Because people use it!

You seem to have failed to read the article. The Debian people *have* released the necessary package ages ago, and it will be rolled into the next release of Etch. The OP's complaint is that they didn't put it in the security updates. Since it isn't a security update it would have been quite wrong to put it in the security updates.

The complaint amounts to "You should have put it in the wrong place because I was looking in the wrong place and didn't find it." People who actually bother to think about what they're doing use Debian precisely *because* you can rely on them sticking to the rules.

Time Zones

When will gov stop messing around with time zones and DST? The WA gov in Australia are doing this too and it's a pain. I try and run all my stuff on UTC, but that's not acceptable for the user facing stuff.

Sysadmins only

Well, since there are no end users that use Debian, i guess their entire userbase are more then capable to just do the patch themselves, right?

No elitism here ..

( Yes this is sarcasm. Rather short sighted of the Debian crew )

Good for Debian

Good for Debian. I can't tell you how much of a pain in the ass timezone alterations are. The US one sucked big time. I wish more companies raised their middle finger to this shit. Talk about a waste of time, because it isn't as if most IT workers/organizations DON'T HAVE ENOUGH TO DO ALREADY. PLUS, if you are an international shop, knowing that some other country has legislated a timezone change could bite you. It's because of crap like this that I advise my customers to just run GMT.

Silly Wabbits: System should be set to GMT anyhow

Simply put, a *Nix system should have the system clock set to GMT and synchronized to a time server. MS rolled the update out as they insist that local time is what the system time should be set to. IDIOTS Now anyone who's upset that Debian/Apple/*bsd has not rolled out a patch/update is creating a tempest in a teapot unless they are foolish enough to use localtime for the system clock as MS insists on. In that case, they deserve all the ridicule and grief they're getting for being idiots instead of doing things the correct way.

Why is it stupid to do things the MS Way? Pretty simple really. Time Zones do change and Laptops change between several of them quite frequently. Now by setting the system clock to GMT, all time stamps are based upon the same TZ and no daylight savings time (remember this is called Internet Time) meaning you avoid all those issues while ensuring a legal timestamp on everything that needs it.

It's this reason that almost every *nix installer asks if your system clock is configured to GMT. If so, then you avoid these damn foolish issues unlike the poor MS admins who had to roll out the TZ patch in order to correctly sync their system clocks to local time instead of Internet Time as is the *nix standard. It's all part of the Extend/Embrace/Extinguish habits of MS and they love to create more work for the lawyers all the time; otherwise they would have followed the RFC on setting computer System Clocks to GMT or as the Military says ZULU TIME.

What did Debian do for the US DST change?

Near as I can tell, the US DST change went into tzdata2007d - so it's not in the one in stable either (unless I got the timeline wrong).

So - what did Debian do for that? If they left it in volatile, then the NZ guys haven't got anything to complain about, really - at least the Debian folks are consistent (in this scenario)

Re:What did Debian do for the US DST change?

Ah... found it (and in a link from the FA, as well... go figure). The US DST changes, according to this bug report [debian.org] went into tzdata2006p - which, sure enough, got the changelog [debian.org] got pushed to stable Nov 28.

So that does beg the question - if it's okay to do it for the US, why not NZ?

Where there's smoke, there's fire

It seems to me that all this brouhaha is evidence that some change to Debian policies should be made.

five years of lead time

The LEAPSECS mailing list has been discussing the issue of implementing leap seconds in UTC for seven years. There is rarely any consensus between those who want to abandon leap seconds and those who want to keep them. There is on occasion something to which there is not strong objection. Last year LEAPSECS fell silent at the suggestion that leap seconds should be announced five years in advance (instead of the current practice of 6 months and requirement of only 8 weeks). The point is that changing civil time in any fashion is extremely disruptive (see Hugo Chavez and Venezuela last week). If the international technical community would agree that five years of advance warning is required, then the local legislative and bureaucratic folks who modify daylight time might get the message. It's a dream.

The real issues

The real issues are:
  Stupid politicians buying the idea that it's easier to reset a billion clocks than to just get up an hour earlier.
  Stupid politicians deciding that the stupid time changes can be improved enough by changing the dates they happen on that it will pay for the cost of changing.

Arizona has it right in refusing to do DST. (they have another good reason: who the hell wants more daylight when it's 110F out in the shade?)

The package sits in volatile for months

...please take your troll elsewhere.

Just out of curiosity...

How does Debian handle time-based logins, VPNS, etc that are restricted by security policy? Correlation: How does it handle the same when they rely on Local Time and not GMT?

For example: User A can only login to Server B between 8am and 8:15am, but can maintain the open link until 5pm. This was set up to restrict login access by User A for whatever reason to Server B, which is offshore. If the time zone data is not applied, won't this screw with the restricted login policy? I would think that would be a security issue as well as a use issue.

Another example: Remote backups, etc that rely on accurate local time settings to perform their operations on a tight time schedule. How would the timezone patch not being applied affect this?

I really don't know these things, as I don't use Debian (or Linux in general), which is why I am asking. Excuse my ignorance please.

My final question: Was the fact that this patch was released to the Volatile repo mentioned on the Debian website, or pushed via subscribed newsletter/RSS feed and not just some "obscure" newsgroup posting? If yes, then the Debian team has done all it needs to have done, and it was the end-user's problem for not paying attention to announcements. If nothing but a short newsgroup post was issued, then the Debian team is at fault for not doing a proper announcement (I know as a systems admin, I rarely have the time while on duty to go scouring newsgroups for update announcements).

Thanks for any insight you might provide.

I think you mean GMT *plus* 13.

This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually

I hope no one actually follows the summary's suggestion of manually setting GMT-13 as the timezone. Given that NZ is now GMT+13, you'd be 26 hours behind.

It sure is a security bug

Several security protocols mandate close time synchronization to minimize the risk of replay attacks, so failure to deploy this time zone change causes a denial of service. In particular Kerberos is impacted, and increasing the permissible time skew by a few orders of magnitude on every box in the domain, which not all implementations support, creates a substantial risk unless you're set up for ticket pre-authentication, which puts a greater load on the server, is not well supported by all clients, and is thus often not enabled. Admittedly, if you're using a network of Debian stable machines, you should be okay, but god forbid someone should use a Debian stable box in an Active Directory deployment.

Similar problems may exist for SSL (https, ldaps, imaps anyone?) but I'm not sure if a one hour difference would exceed the tolerance in many applications.

Disclaimer: I work for a commercial distributor.

Re:It sure is a security bug

Protocols mandate close synch of UTC. If they required clock-on-the-wall time to be synchronized then they wouldn't work across time zone boundaries. I manage a network with staff in six timezones, between UTC-8 and UTC+9, some of them with non-integer offsets, with (from memory) four different sets of DST rules, including one (Japan) that doesn't do daylight saving. I know about the timezones because I'm a clock geek sad enough to know the difference between UTC and GMT. But I don't need my systems to understand it (aside from shouting at bloody Apple for thinking BST, UTC+1, is called BDT). That's because everything that cares about timing (Clearcase, WebDAV, SVN, NFS, Make...) works in UTC.

a non-issue

I think the patch is in Debian volatile repository [debian.org], which is Debian's policy to put there any software updates that aren't security bugs but are needed to keep the system working properly. A Debian GNU/Linux user/sysadmin (I am one incidentally) should know about volatile (if not it means that either there is insufficient documentation or the user/sysadmin didn't RTFM). Comparing Debian with Microsoft is wrong, because Microsoft Windows Update is used to update a variety of issues with Windows, not just security bugs. But Debian is usually only focusing on security updates after a stable release is made, it is their policy (whether it's good or bad is another story). The volatile repository was made for non-security important updates, which I think fits nicely with a timezone update. It is important to realise that new Debian users/sysadmins must learn the apt system pretty well, as it is fundamental in managing a Debian system. Debian just follows its own policies here, while still allowing users/sysadmins to get the patch through volatile (and I think also backports), and why this hit Slashdot I really don't know. Of course, this update should be included in the next point release (ie 4.0r2), and perhaps a higher number of volunteers would be helpful here. Are any of you willing to actually help Debian include important bugfixes and updates in next point releases rather than losing your time discussing about non-issues?

Funniest thing about this unresearched story

The tzdata package needs to be at least version 2007f. So, if you think about it, this has already happened at least 6 times this year, somewhere in the world.

Personally I prefer to blame it on stupid politicians who want to push things like this through in under 6 months to give the voters the impression that they are capable of getting stuff done.

Egg on my face

My wife told me that her Windows PC hadn't updated for daylight savings time. With great smugness and confidence I told her that my Linux box would have done it because it was community based software and was therefore superior in every way. I sure felt like a dork when my linux box still had the wrong time on it. And she pinched and punched me for the first of the month again. Damn Debian politics. Red tape is there to be cut through.

Volatile != Unstable

When I first heard about it, I mistakenly assumed volatile == unstable...

No, the volatile repository is exactly what this is for -
packages that need constant adjustment and update to work as advertised.

I just learned about the volatile repository and it's the perfect solution, but
sadly I, and I'm sure others, were unaware that this existed until now.

I wish some of this stuff was advertised a little more rather than buried
in the documentation, but I'm glad I know now.

"even Microsoft are not this silly"

... maybe not, but Apple is:

New Zealand Mac users missing DST patch
Apple has yet to issue a patch adjusting to a change in New Zealand's seasonal times, Mac users from the country complain.

http://www.macnn.com/articles/07/09/28/new.zealand.dst.problems/ [macnn.com]

Not the only one

Tzdata isn't the only affected package.

PHP keeps its time zone information internally, and of course there isn't a debian update for it so you may need to recompile with a new [zend.com] timezonedb.h

So if you have a web server, get cracking!

Debian, a bunch of stubborn engineers

Correct me if I am wrong, but the only way to update packages in default Debian install is through http://security.debian.org/ [debian.org] (or when the distro itself is updated). Therefore, the mentioned fix should have come into http://security.debian.org./ [security.debian.org] And Debian should make sure that its next release includes 'volatile' repository by default as well. Thinking that every user and admin will have to edit /etc/apt/sources.list themselves is pure nonsense! This stubborness of Debian team will cost them. With such attitude, it is not going to be long until Debian is completely abandoned and forgotten, and will only be used by a small bunch of engineers that pretend to be politicians.

Wake up, Debian! You lost your voice when your weekly news letter started to come out once a month, when your users turned to Ubuntu for new software, fun & ease of use, and you yourself got into the fingerpointing blame game. Lose your arrogance and start responding to your users and you will still have a chance!

Debian's canonical problem

This is a good example of why Ubuntu was necessary.

I agree with userid 701 - This is a security fix

Incorrect time is a security problem. And by default Debian logs are in localtime not UTC. Incorrect log timestamps are a security issue.

Just make an exception

It seems like an exception can or should be made for this even if it is not how the Debian people define a "security bug." Having guidelines and rules are fine and necessary for maintaining order, but I have to wonder if they need to be followed in such a slavish way, as if they're part of some kind of religious canon.

This doesn't affect me at all, but it seems like something called "stable" in any sense of the word ought to be able to tell time properly out of the box. That the Debian guidelines or rules or whatever don't allow for the direct incorporation of this bug into the stable repository seems secondary to the fact that it ought to be. That this patch is available in volatile is kind of beside the point. Someone downloading and installing this anew in that NZ timezone is going to have problems.

I suppose someone could make some kind of case about regression testing and so on, but I have a hard time believing a simple time zone update will bring Debian's reputation for curmudgeonly stability crashing down.

Just install it and move on

In an ideal world would Tux go chimney-to-chimney world round in a single clockcycle and force all linux users to update tzdata at gunpoint?

Sure. This is not an ideal world.

In this non-ideal world the updated version of tzdata was added to etch-volatile at the end of July. That's a full two months anyone who needed it could've done extensive research about how to get it. http://packages.qa.debian.org/t/tzdata/news/20070731T155541Z.html [debian.org]

If you're a single debian etch user in NZ then simply install the update manually. Takes what, half a minute at best?

If you're admin of a lot of etch systems you should either put volatile in your repository list [wlug.org.nz] or (I like this better) set up a local repository [debian.org] on your own network so that you can roll out exactly the packages and versions you want.

And for the sake of anyone who does need this package and is patiently waiting. Stop waiting.

http://packages.debian.org/etch-volatile/tzdata/all/download [debian.org]

It's right there.

Either you don't get it or you're a troll.

Debian have promised their users that only security updates will be rolled out and that they will not release any updates that change the normal behavior of programs. They do this because Debian gets run on lots of mission-critical servers where they don't want a program changing its behavior via an "update".

Rolling clocks forward by two hours is a pretty huge change in behavior for some servers, and there isn't much of a security risk in not rolling out the update automatically, so they're not going to.

They're doing the right thing.

Re:Dropped debian back in '01.

It's Debian policy to update stable in point-releases, to have security updates through security.debian.org and packages that _need_ regular code updates (like the clamav virus scanner) in volatile. This timezone change is in volatile.

Nothing to see here, move along.

Re:This illustrates one of Linux' challenges to wi

but it's not a flaw. If you have a 1/16th of a brain you can and probably installed it from the Volatile already. Linux users are WAY WAY more savvy than a windows user. they tend to understand how to install software, patches, and how their system runs. If any sysadmins in NZ did not start testing the patch months or even weeks ago, then it's their fault waiting for the magical debian faires to install it for them.

Everyone keeps trying to compare Linux to windows. It's not. Compare Solaris to Linux.

Re:My god!

Or configure NTP.

1 command, really. Not sure why they're being so stubborn.

Re:My god!

Or configure NTP.

That won't address the issue at all. NTP makes sure the system clock is synchronized with UTC. The issue here is how much offset from UTC should be used for times that are displayed to users.

Re:My god!

What rubbish. New Zealand's technology industry is more significant to its citizens than the US technology industry is to Americans. As a small country, New Zealand's economy relies more on technological innovation than big countries do, with their natural resources and primary production. I'm not just talking about the famous examples (the electric fence, Rakon) either, but a constant push for more efficient and more valuable secondary production.

Or by significant did you mean significant to you and you alone? Who made you Captain of Industry?

Your guess about the few dozen people is also wrong. I, personally, just me, know a few dozen Kiwi Debian users, and I wouldn't say that's even close to the number that live in my suburb. Free software adoption is alive and well down under - it goes well with the 'number 8 wire' tinkering mentality that is a well-established part of New Zealand culture (Burt Munro and all that).

None of that is to say Debian should break policy - I agree that volatile is where these updates belong. But the arguments you give in favour of the status quo are bullshit.

Re:Iceweasel

I do wish, however, that Debian picked a less geeky name than "IceWeasel" for their FireFox build.

I have the feeling it was a not-so-subtle dig at the Mozilla people.

Re:Google Groups in Konqueror

This isn't an isolated incident either. You cannot browse Google Groups in Konqueror. In the bug report they legitimately argue that it's Google's fault for not adhering to standards, but they still lost me as a user, and undoubtedly others also. http://bugs.kde.org/show_bug.cgi?id=140531 [kde.org] [kde.org]

Firstly, this is offtopic and has nothing to do with Debian. Secondly either Google or the KHTML team must have fixed it because I couldn't reproduce the bug in Konqueror.

When you say they've lost you as a user, do you just mean Konqueror? If so, is there anything we can do to lose you as a Linux user as well?

Re:Google Groups in Konqueror

WORKSFORME, though I'm not using Debian and I have the latest released version. The Konqueror devs generally do try to work around this sort of thing, at least for major sites.

Re:My god!

It doesn't "effect a few dozen people"; it "affects a few dozen people."

Learn the difference, please.

Misuse of "effect/affect" is one of my biggest semantic pet peeves.

To "effect" something is to bring it about or into being; to "affect" something is to have an influence on it.

Re:not the only timezone problem

Is there a bug filed about that?

Re:Perfect snapshot of Debian's developers' arroga

You are free to ignore the people who tell you to RTFM and instead listen to those who will help you out.

Re:not the only timezone problem

Another problem: in etch, /etc/localtime is not a symlink to the appropriate timezone file in /usr/share/zoneinfo, but a copy - a regular file. You would think this wouldn't matter, but for tomcat apps it does. Whether that's a bug in tomcat, java, or debian doesn't really matter, the only fix is to replace the file with a symlink.

It is not possible to use a symlink, the system needs to be able to read /etc/localhost without mounting /usr.

What kind of problems does this give Tomcat apps?

Re:not the only timezone problem

it should be the other way around
/usr/share/zoneinfo/localtime should be a symlink to /etc/localtime