2009/12/10 Joseph D. Darcy <joe.da...@sun.com>: > Andrew John Hughes wrote: >> >> 2009/12/9 Joseph D. Darcy <joe.da...@sun.com>: >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/8 Andrew John Hughes <gnu_and...@member.fsf.org>: >>>> >>>> >>>>> >>>>> 2009/12/8 Joseph D. Darcy <joe.da...@sun.com>: >>>>> >>>>> > > [snip] >>>>> >>>>> >>>>> >>>> >>>> No sooner did I write that than it built: >>>> >>>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/ >>>> >>>> >>> >>> Approved. >>> >>> >>>> >>>> The remaining three tz fixes are: >>>> >>>> changeset: 639:67c41d740e6d >>>> user: peytoia >>>> date: Mon Sep 08 15:21:55 2008 +0900 >>>> summary: 6466476: (tz) Introduction of tzdata2005r can introduce >>>> incompatility issues with some JDK1.1 3-letter TZ Ids >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d >>>> >>>> changeset: 1693:92b6482e7719 >>>> user: peytoia >>>> date: Mon Aug 31 14:53:05 2009 +0900 >>>> summary: 6456628: (tz) Default timezone is incorrectly set >>>> occasionally on Linux >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 >>>> >>>> >>>> >>> >>> These other backports approved. >>> >>> >>>> >>>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug >>>> ID. >>>> >>>> >>> >>> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for >>> this >>> change. >>> >>> Thanks, >>> >>> -Joe >>> >>> >> >> Thanks. All of them are now in OpenJDK6. >> >> There is one more backport lurking in IcedTea6: >> >> http://cr.openjdk.java.net/~andrew/tz/webrev.03/ >> >> The actual code fix went in to OpenJDK7 in the black hole between the >> two (b22): >> http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html >> There should be a bug ID as a result -- presumably, you can discover >> that internally? >> > > Donning my fedora and brandishing a bullwhip, the bug id for this change was > 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff: > > ------- TimeZone.java ------- > 606,610c606 > < if (hasPermission()) { > < defaultTimeZone = tz; > < } else { > < defaultZoneTL.set(tz); > < } > --- >> defaultTimeZone = tz; > 640a637 >> defaultZoneTL.set(null); > > There was another file involved in this change, > windows/native/java/util/TimeZone_md.c: > > ------- TimeZone_md.c ------- > 199a200 >> bufSize = sizeof(val); > 347c348 > < valueSize = MAX_ZONE_CHAR; > --- >> valueSize = MAX_MAPID_LENGTH; > > This is also the current difference between the OpenJDK 6 and JDK 7 versions > of this file. > >> The test case included in the webrev is from Mark Wielaard and is >> contributed through Red Hat's SCA. >> > > There appears to be some test coverage of this change in still-closed > regression tests. > >> CCing i18n-dev in case they have any input; it would be nice to have >> the test case in 7 too as well as the fix. >> > > I'll approve this change going back if the change from the JDK 7 version of > TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if the > @bug line in the test includes 6584033. > > Thanks, > > -Joe >
I added the fixes mentioned and tried to push. I was greeted with this: remote: remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh: Executable files not permitted remote: Funny because: $ find test -name '*.sh'|wc -l 305 And no it isn't because of the executable permission bit, I did a chmod -x to be sure and it still didn't push :( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
