Processing of gcj-4.1_4.1.2-14_m68k.changes

[Archive Administrator]

gcj-4.1_4.1.2-14_m68k.changes uploaded successfully to localhost
along with the files:
  gcj-4.1-base_4.1.2-14_m68k.deb
  gcj-4.1_4.1.2-14_m68k.deb
  gij-4.1_4.1.2-14_m68k.deb
  libgcj7-1_4.1.2-14_m68k.deb
  libgcj7-1-awt_4.1.2-14_m68k.deb
  gappletviewer-4.1_4.1.2-14_m68k.deb
  libgcj7-dev_4.1.2-14_m68k.deb
  libgcj7-dbg_4.1.2-14_m68k.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

gcj-4.1_4.1.2-14_m68k.changes ACCEPTED

[Debian Installer]

Accepted:
gappletviewer-4.1_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/gappletviewer-4.1_4.1.2-14_m68k.deb
gcj-4.1-base_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/gcj-4.1-base_4.1.2-14_m68k.deb
gcj-4.1_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/gcj-4.1_4.1.2-14_m68k.deb
gij-4.1_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/gij-4.1_4.1.2-14_m68k.deb
libgcj7-1-awt_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/libgcj7-1-awt_4.1.2-14_m68k.deb
libgcj7-1_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/libgcj7-1_4.1.2-14_m68k.deb
libgcj7-dbg_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/libgcj7-dbg_4.1.2-14_m68k.deb
libgcj7-dev_4.1.2-14_m68k.deb
  to pool/main/g/gcj-4.1/libgcj7-dev_4.1.2-14_m68k.deb


Override entries for your package:
gappletviewer-4.1_4.1.2-14_m68k.deb - optional utils
gcj-4.1-base_4.1.2-14_m68k.deb - optional libs
gcj-4.1_4.1.2-14_m68k.deb - optional devel
gij-4.1_4.1.2-14_m68k.deb - optional devel
libgcj7-1-awt_4.1.2-14_m68k.deb - optional libs
libgcj7-1_4.1.2-14_m68k.deb - optional libs
libgcj7-dbg_4.1.2-14_m68k.deb - extra libdevel
libgcj7-dev_4.1.2-14_m68k.deb - optional libdevel



Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libffi4, ffi_prep_cif on mips and mipsel

[Matthias Klose]

[CCing debian-mips and debian-gcc]

The gcc-4.2 source uses the libffi backport from the trunk. To
investigate further, please look at libffi's config.log to see why the
test for ffi_prep_cif fails.

  Matthias

Neil Williams writes:
> For once, this isn't cross-build related - not even slightly. :-)
> 
> I'm wondering if you can help me with a package problem that shows up
> only on mips and mipsel and is related to the ffi_prep_cif function in
> libffi4, built from gcc-4.2.
> 
> g-wrap looks for this function during the build and the latest upload
> (which only changed the dependency information regarding libglib1.2 vs
> libglib2.0) breaks gnucash on mips and mipsel because g-wrap is unable
> to find ffi_prep_cif in libffi4 for mips and mipsel. I've checked
> previous logs and this has not been a problem with previous builds of
> g-wrap.
> 
> http://buildd.debian.org/fetch.cgi?pkg=g-wrap;ver=1.9.6-3.1%2Bb1;arch=mips;stamp=1183106948
> checking ffi.h usability... yes
> checking ffi.h presence... yes
> checking for ffi.h... yes
> checking for ffi_prep_cif in -lffi... yes
> 
> http://buildd.debian.org/fetch.cgi?pkg=g-wrap;ver=1.9.6-3.2;arch=mips;stamp=1184676067
> checking ffi.h usability... yes
> checking ffi.h presence... yes
> checking for ffi.h... yes
> checking for ffi_prep_cif in -lffi... no
> 
> This causes g-wrap to try to use an internal libffi that appears to
> work but causes a FTBFS within gnucash (which is about the only
> application now using g-wrap in Debian). Disabling the internal libffi
> support in g-wrap could cause a FTBFS in g-wrap on mips and mipsel.
> 
> This *only* happens on mips and mipsel. All other architectures
> correctly locate ffi_prep_cif within the libffi library. If previous
> builds of g-wrap on mips/mipsel had used the internal ffi support, I
> would work on fixing that but this does appear to be a change in how
> libffi4 has been built on mips and mipsel.
> 
> The 1.9.6-3.2 builds were made using gcc-4.2 4.2-20070712-1. 
> (Tue Jul 17 12:41:07 2007)
> 
> The 1.9.6-3.1 builds were made using gcc-4.2 4.2-20070627-1
> (Fri Jun 29 08:49:08 2007)
> 
> I'm a relatively new DD and I'm not sure how to proceed on this bug -
> it was my NMU that exposed it but I can't see how my changes would have
> caused it.
> 
> Can you help me? Maybe just a few pointers at where the real bug lies?
> Is it a bug in libffi4 on mips and mipsel from the gcc-4.2 source? I
> don't mind reporting it as such but I would like to check that it
> reasonable to assign this to the libffi build from gcc-4.2 as it would
> be RC due to the FTBFS in gnucash.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: forwarded gcj report

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 433391 + upstream
Bug#433391: gij-4.1: Runs out of memory
There were no tags set.
Tags added: upstream

> forwarded 433391 http://gcc.gnu.org/PR32853
Bug#433391: gij-4.1: Runs out of memory
Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR32853.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2007-07-22 16:31 ---
Subject: Bug 31639

Author: dfranke
Date: Sun Jul 22 16:31:11 2007
New Revision: 126826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126826
Log:
gcc/fortran:
2007-07-22  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/29962
PR fortran/31253
PR fortran/31265
PR fortran/31639
* gfortran.h (gfc_intrinsic_sym): Changed members elemental, pure,
generic, specific, actual_ok, noreturn into bits of a bitfield, 
added bits for inquiry, transformational, conversion.
* check.c (non_init_transformational): Removed, removed all callers.
* intrinsic.c (enum class): New.
(add_sym*): Replaced argument elemetal by enum class. Changed all
callers.
(add_functions): Assign appropriate classes to intrinsic functions.
(add_subroutines): Assign appropriate classes to intrinsic subroutines.
(add_conv): Set conversion attribute.
(gfc_init_expr_extensions): Removed, removed all callers.
(gfc_intrinsic_func_interface): Reimplemented check for non-standard
initializatione expressions.
* expr.c (check_specification_function): New.
(gfc_is_constant_expr): Added check for specification functions.
(check_init_expr_arguments): New.
(check_inquiry): Changed return value to MATCH, added checks for
inquiry functions defined by F2003.
(check_transformational): New.
(check_null): New.
(check_elemental): New.
(check_conversion): New.
(check_init_expr): Call new check functions, add more specific error
messages.

gcc/testsuite:
2007-07-22  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/29962
* gfortran.dg/array_initializer_1.f90: Removed warning.
* gfortran.dg/initialization_1.f90: Adjusted messages.
* gfortran.dg/nested_modules_6.f90: Removed warning.

PR fortran/31253
* gfortran.dg/initialization_7.f90: New test.

PR fortran/31639
* gfortran.dg/initialization_8.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/initialization_7.f90
trunk/gcc/testsuite/gfortran.dg/initialization_8.f90
Modified:
trunk/gcc/fortran/check.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/gfortran.dg/array_initializer_1.f90
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
trunk/gcc/testsuite/gfortran.dg/nested_modules_6.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2007-07-22 16:39 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.1.2 4.2.0 4.3.0   |4.1.2 4.2.0
  Known to work||4.3.0
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2007-07-22 16:41 ---
As said, closing as fixed.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[kargl at gcc dot gnu dot org]

--- Comment #10 from kargl at gcc dot gnu dot org  2007-07-22 19:14 ---
(In reply to comment #9)
> I don't know the fortran policy on closing bug reports with regressions; is
> there no chance to backport the fix to the active branches?

It isn't a gfortran policy.  The general GCC policy is that only regression
fixes can/should be backported.  You would need to show that the code in
comment #1 could be compiled with a version of gfortran that is older than
4.1.2 20061115; otherwise, this is simply a bug that finally got fixed.

Additionally, there simply are too few gfortran developers to maintain 3
active branches.  So, we have chosen to concentrate our effort on trunk.
If a patch fixes a regression in 4.2, it may be backported but there is
no guarantee.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug target/32853] [4.3 regression] failing libjava testcases

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|java|target
Summary|[4.3 regression] failing|[4.3 regression] failing
   |libjava testcases   |libjava testcases
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32853

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[dfranke at gcc dot gnu dot org]

--- Comment #11 from dfranke at gcc dot gnu dot org  2007-07-22 19:42 
---
Reopening, the original testcase still fails for std=gnu. Sigh.

For the record: an error is generated for -std=f95, std=f2003 and a warning for
-std=gnu -pedantic. Currently testing ...

Index: expr.c
===
--- expr.c  (revision 126826)
+++ expr.c  (working copy)
@@ -1966,9 +1966,8 @@
&& ap->expr->symtree->n.sym->ts.type == BT_CHARACTER
&& ap->expr->symtree->n.sym->ts.cl->length == NULL)
  {
-   if (gfc_notify_std (GFC_STD_GNU, "assumed character length "
-   "variable '%s' in constant expression at %L",
-   e->symtree->n.sym->name, &e->where) == FAILURE)
+   gfc_error ("assumed character length variable '%s' in constant "
+  "expression at %L", e->symtree->n.sym->name, &e->where);
  return MATCH_ERROR;
  }
else if (not_restricted && check_init_expr (ap->expr) == FAILURE)


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug target/32857] libjava fails to build on hppa-linux-gnu (ICE in simplify_subreg)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|java|target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#434274: gcc-snapshot 20070720-1 fails to compile trivial code

[Christophe Prud'homme]

Package: gcc-snapshot
Severity: serious

Martin, Matthias,

it seems that the 20070720-1 snapshot has some issues with limits.h

here is a snippet that cannot be compiled by gcc-snapshot

---
#include 

int main()
{
  return 0;
}
--

/usr/lib/gcc-snapshot/bin/g++ -o t 
t.cpp   
   /tmp
In file included from t.cpp:1:
/usr/include/limits.h:125:26: error: no include path in which to search for 
limits.h

I got these errors in the codes I develop and use on Debian while testing the 
new snapshot

Best regards
C.
-- 
Debian Developer - http://people.debian.org/~prudhomm/
Scientific computing packages maintainer
Fingerprint = 3703 50DE 7A9F 024E 0F26  0D07 A18F B40B D4BE 1450

[Bug target/32857] libjava fails to build on hppa-linux-gnu (ICE in simplify_subreg)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-22 20:16 ---
ICE is just an artifact I think:
java/util/AbstractMap.java:819: error: cannot find file for class
java.util.AbstractMap$SimpleEntry

is the real error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug target/32857] libjava fails to build on hppa-linux-gnu (ICE in simplify_subreg)

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2007-07-22 21:02 ---
Do you have Kyle's use-compat_sys_getdents patch installed?  It fixes
a scandir bug.  Without it, building libjava fails.  See
.
It was also posted to parisc list.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: tag gcj report

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 398129 + upstream
Bug#398129: gij-4.1: keytool fails where keytool from sun java 1.5 works
There were no tags set.
Tags added: upstream

> tag 398129 + fixed-upstream
Bug#398129: gij-4.1: keytool fails where keytool from sun java 1.5 works
Tags were: upstream
Tags added: fixed-upstream

> retitle 398129 [fixed in 4.2] keytool fails where keytool from sun java 1.5 
> works
Bug#398129: gij-4.1: keytool fails where keytool from sun java 1.5 works
Changed Bug title to `[fixed in 4.2] keytool fails where keytool from sun java 
1.5 works' from `gij-4.1: keytool fails where keytool from sun java 1.5 works'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#397905: marked as done (libgcj7-0: Throws NullPointerException in javax.xml.parsers.SAXParser.parse)

[Debian Bug Tracking System]

Your message dated Mon, 23 Jul 2007 08:47:38 +0200
with message-id <[EMAIL PROTECTED]>
and subject line libgcj has no problem, ant is responsible for the failure
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: libgcj7-0
Version: 4.1.1-17
Severity: important

*** Please type your report below this line ***

The method in parse() ind javax.xml.parsers.SAXParser throws a
NullPointerException. The problem only occurs when I compile a binary
of my application.

Exception in thread "main" java.lang.NullPointerException
   at gnu.java.nio.channels.FileChannelImpl.open(libgcj.so.70)
   at gnu.java.nio.channels.FileChannelImpl.(libgcj.so.70)
   at gnu.java.nio.channels.FileChannelImpl.create(libgcj.so.70)
   at java.io.FileInputStream.(libgcj.so.70)
   at javax.xml.parsers.SAXParser.parse(libgcj.so.70)
   at lemming.rule.RuleReader.(Lemming)
   at Lemming.main(Lemming)

If I build a jar of the application, I have no problems with
gcj/gij. Sun's SDK has no problems, too.

A few days ago I even had no problems with the application compiled as a
binary. There have been a few updates of gcj and libgcj the last
days. Perhaps this is the problem.

===

I have an older version of my application as binary. The binary still
works without problems. If I compile a new binary of the same code,
the same fault as above occurs.
Perhaps not libgcj is the problem, it could be gcj, too.

Debian Release: 4.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.2-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libgcj7-0 depends on:
ii  gcj-4.1-base 4.1.1-17The GNU Compiler Collection
(gcj b
ii  libasound2   1.0.13-1ALSA library
ii  libc62.3.6.ds1-7 GNU C Library: Shared libraries
ii  libgcc1  1:4.1.1-19  GCC support library
ii  libgcj-common1:4.1.1-19  Java runtime library
(common files
ii  zlib1g   1:1.2.3-13  compression library - runtime

Versions of packages libgcj7-0 recommends:
ii  libgcj7-jar   4.1.1-17   Java runtime library for
use with

- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFVNCjAdmUVGnNrfMRAmwgAJ92GXfcRrlk5Z+eW/+bPLO13pnIngCffEco
9j5WUGw65I3bJP4TkOKX9lA=
=VUYd
-END PGP SIGNATURE-

--- End Message ---
--- Begin Message ---
Marcus:
> I think you can close the bug.

doing so. If you see it again, please recheck with gij-4.1/gij-4.2 from
unstable.
--- End Message ---

Bug#416443: marked as done (libgcj7-0: Incorrect DST calculation)

[Debian Bug Tracking System]

Your message dated Mon, 23 Jul 2007 08:53:01 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#416443: libgcj7-0: Incorrect DST calculation
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---

Package: libgcj7-0
Version: 4.1.1-20
Severity: important

*** Please type your report below this line ***
I am sorry if this is a known problem - it seems like it should be
with all the noise
around the DST - but I wasn't able to find it. In short on my Etch
systems libgcj does
n't seem to contain the latest DST changes, so it currently is showing
incorrect time.

$cat /etc/timezone
US/Pacific

$date
Tue Mar 27 15:35:27 PDT 2007

I have written a very small Java app to demonstrate the issue:
public class tm {
 public static void main ( String[] args ) {
   System.out.println( java.util.TimeZone.getDefault().toString()
+":"+ new java.util
.Date() );
 }
}

The output is:
$gij tm
java.util.SimpleTimeZone[id=PST,offset=-2880,dstSavings=360,useDaylight=true,s
tartYear=0,startMode=2,startMonth=3,startDay=1,startDayOfWeek=1,startTime=720,star
tTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=720,endTimeMode=
0]:Tue Mar 27 14:35:45 PST 2007

As you can see the time is incorrect.

Some more info, which does not directly apply to this bug, but is
relevant to Java on
Etch in general. The Sun Java packages (from non-free or built with
java-package) also
have a time-zone related problem, for which I will be submitting a
separate bug (I am
not sure for which package yet). They have the correct DST settings,
but they are det
ermining the default timezone incorrectly - instead of "US/Pacific"
(which is OK), the
y default to ""SystemV/PST8PDT" (which is not). This doesn't happen on Sarge.

Bottom line, Java (free or not) seems to be almost unusable, as far as
displaying time
, on Etch right now. I have thess problem on two separate systems. Of
course there are
possible manual workarounds by modifying the applications.

-- System Information:
Debian Release: 4.0
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libgcj7-0 depends on:
ii  gcj-4.1-base 4.1.1-20The GNU Compiler Collection (gcj b
ii  libasound2   1.0.13-1ALSA library
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libgcc1  1:4.1.1-19  GCC support library
ii  libgcj-common1:4.1.1-21  Java runtime library (common files
ii  zlib1g   1:1.2.3-13  compression library - runtime

Versions of packages libgcj7-0 recommends:
pn  libgcj7-jar(no description available)

-- no debconf information

--- End Message ---
--- Begin Message ---
Version: 4.1.2-6

should be fixed in unstable (gij-4.1 and gij-4.2).

Tzvetan Mikov writes:
> Package: libgcj7-0
> Version: 4.1.1-20
> Severity: important
> 
> *** Please type your report below this line ***
> I am sorry if this is a known problem - it seems like it should be
> with all the noise
> around the DST - but I wasn't able to find it. In short on my Etch
> systems libgcj does
> n't seem to contain the latest DST changes, so it currently is showing
> incorrect time.
> 
> $cat /etc/timezone
> US/Pacific
> 
> $date
> Tue Mar 27 15:35:27 PDT 2007
> 
> I have written a very small Java app to demonstrate the issue:
> public class tm {
>   public static void main ( String[] args ) {
> System.out.println( java.util.TimeZone.getDefault().toString()
> +":"+ new java.util
> .Date() );
>   }
> }
> 
> The output is:
> $gij tm
> java.util.SimpleTimeZone[id=PST,offset=-2880,dstSavings=360,useDaylight=true,s
> tartYear=0,startMode=2,startMonth=3,startDay=1,startDayOfWeek=1,startTime=720,star
> tTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=720,endTimeMode=
> 0]:Tue Mar 27 14:35:45 PST 2007
> 
> As you can see the time is incorrect.
--- End Message ---