Re: Copenhagen timezone bug
Troels Vognsen <[EMAIL PROTECTED]> writes: > The /usr/share/zoneinfo/Europe/Copenhagen is incorrect. > It currently equals GMT-2, when it should in fact be GMT-1. As far as I know, Denmark uses Central European Time (1 hour ahead of UTC) and observes daylight-saving time in the summer, which means that it's currently 2 hours ahead of UTC. Or at least, that has been true for many years. Has it changed recently? Anyway, this issue isn't really specific to coreutils; it's more of a time zone database issue, so please report any bugs to the time zone folks at <[EMAIL PROTECTED]>. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Unable to build current CVS: coreutils.pot not built
On Mon, 10 May 2004, Paul Eggert wrote: >>shouldn't the configure script have a 'checking for gettext' stage? > >When you check source out directly from CVS, you're assumed to be an >expert, and to have the correct build tools even if they're not on >the standard list of tools all users are assumed to have. (The set >of "expert" tools includes CVS itself. :-) The "checking for" stuff >is designed more for non-experts, who are assumed to have tarballs >instead of checking things out directly from CVS. That makes perfect sense. So when I check out of CVS, am I getting a slightly different code base from what goes into the tarballs? -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: cp by blocks, with errors
>The first one looks like it's solely a performance optimization for the >case (common?) in which there are short reads. Can you provide some >data to justify adding this code? Do you have a feel for how often >cp gets short reads when block alignment would make a significant >difference in performance? I don't think the performance gains would justify the change. The main purpose of the change to block structured reads instead of arbitrary byte stream reads (for me, that is) is to structure the reads in a way more conducive to error recovery. I.e. this was the easiest way to write the error recovery code. >Can you give an example showing why it'd be better to have this >functionality in cp than in dd? Dd is a low level copy tool. It can't do things such as preserve timestamps and permissions and copy a whole directory tree. Also, I think the idea of recovering a bad block by reading the good parts in smaller chunks is a little too high level for dd. I think the dd user means to prescribe an actual sequence of read and write system calls and doesn't want the program exercising any intelligence. >Isn't it necessary sometimes to use lseek to get past an unreadable bit >of media? Yes. That's what my cp patch does. -- Bryan HendersonPhone 408-621-2000 San Jose, California ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Copenhagen timezone bug
Hi ! The /usr/share/zoneinfo/Europe/Copenhagen is incorrect. It currently equals GMT-2, when it should in fact be GMT-1. Best regards, - Troels Vognsen ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
