7:47 a.m.
New package cryptix
Java crypto package
New package cryptix-asn1
Cryptix ASN1 implementation
New package gnu.getopt
Java getopt implementation
New package jakarta-commons-beanutils
Jakarta Commons BeanUtils Package
New package jakarta-commons-collections
Jakarta Commons Collections Package
New package jakarta-commons-daemon
Jakarta Commons Daemon Package
New package jakarta-commons-dbcp
Jakarta Commons DataBase Pooling Package
New package jakarta-commons-digester
Jakarta Commons Digester Package
New package jakarta-commons-el
The Jakarta Commons Extension Language
New package jakarta-commons-fileupload
Jakarta Commons Fileupload Package
New package jakarta-commons-lang
Jakarta Commons Lang Package
New package jakarta-commons-launcher
The Launcher Component is designed to be a cross platform Java application launcher.
New package jakarta-commons-pool
Jakarta Commons Pool Package
New package jakarta-commons-validator
Jakarta Commons Validator
New package jakarta-taglibs-standard
An open-source implementation of the JSP Standard Tag Library
New package ldapjdk
The Mozilla LDAP Java SDK
New package puretls
Java implementation of SSLv3 and TLSv1
New package struts11
Web application framework
Updated Packages:
NetworkManager-0.3.3-1.cvs20050125.3.1
--------------------------------------
* Tue Jan 25 2005 Dan Williams <dcbw(a)redhat.com> 0.3.3-1.cvs20050125
- Play nice with dbus 0.23
- Update our list of Allowed Wireless Networks more quickly
anaconda-10.2.0.13-1
--------------------
* Tue Jan 25 2005 Peter Jones <pjones(a)redhat.com> - 10.2.0.13-1
- Hopefully fix LVM size bug (#145183)
- Support multiple iso sets in the same directory (#146053)
at-3.1.8-64
-----------
* Tue Jan 25 2005 Jason Vas Dias <jvdias(a)redhat.com> 3.1.8-64
- bugs 5160/146132: add PAM authentication control to atd
* Tue Oct 05 2004 Jason Vas Dias <jvdias(a)redhat.com> 3.1.8-60
- fix bug 131510: no_export env. var. blacklisting should not
- remove 'SHELL' when only 'SHELLOPTS' is blacklisted.
- at(1) man-page should not say 'commands are run with /bin/sh'
- and should explain usage of SHELL environement variable and
- details of blacklisted variables.
* Tue Sep 28 2004 Rik van Riel <riel(a)redhat.com> 3.1.8-58
- fix typo in man page, bug 112303
- (regenerated at-3.1.8-man-timespec-path.patch with fix)
desktop-printing-0.18-2
-----------------------
* Tue Jan 25 2005 Dan Williams <dcbw(a)redhat.com> 0.18-2
- Rebuild for dbus 0.23
dictd-1.9.7-5
-------------
* Tue Jan 25 2005 Karsten Hopp <karsten(a)redhat.de> 1.9.7-5
- don't install config file, leave it to the dictionary packages to
populate it. (#135920)
dmraid-1.0.0.rc5f-3
-------------------
* Fri Jan 21 2005 Alasdair Kergon <agk(a)redhat.com> 1.0.0.rc5f-2
- Rebuild to pick up new libdevmapper.
* Fri Nov 26 2004 Heinz Mauelshagen <heinzm(a)redhat.com> 1.0.0.rc5f
- specfile cleanup
eclipse-1:3.0.1_fc-8
--------------------
* Tue Jan 25 2005 Andrew Overholt <overholt(a)redhat.com> 1:3.0.1_fc-8
- add eclipse.db to libswt3-gtk2 files list
* Tue Jan 25 2005 Andrew Overholt <overholt(a)redhat.com> 1:3.0.1_fc-7
- add missing jar-so combinations to lists
- add libswt3-gtk2 jar-so combinations
- use native ecj instead of interpreted
gcc-3.4.3-17
------------
* Tue Jan 25 2005 Jakub Jelinek <jakub(a)redhat.com> 3.4.3-17
- update from gcc-3_4-branch
- PRs c++/19258, c++/19375, libstdc++/19510, other/16403,
rtl-optimization/19296, target/16304, target/19548
- fix PR rtl-optimization/19579
- remove Java *.a libraries, issue error for gcj -static (#145829)
gcc4-4.0.0-0.22
---------------
* Tue Jan 25 2005 Jakub Jelinek <jakub(a)redhat.com> 4.0.0-0.22
- update from trunk
- fix PR rtl-optimization/19579
- remove Java *.a libraries, issue error for gcj -static (#145829)
gdm-1:2.6.0.5-11
----------------
* Tue Jan 25 2005 Ray Strode <rstrode(a)redhat.com> 1:2.6.0.5-11
- Fix bug in greeter sort-session-list patch where selecting
a session did nothing (bug 145626)
isdn4k-utils-3.2-22
-------------------
* Tue Jan 25 2005 Than Ngo <than(a)redhat.com> 3.2-22
- fix the bug in isdn startup script, #146057
kernel-2.6.10-1.1110_FC4
------------------------
* Tue Jan 25 2005 Dave Jones <davej(a)redhat.com>
- 2.6.11-rc2-bk3
pciutils-2.1.99.test8-6
-----------------------
* Tue Jan 25 2005 Bill Nottingham <notting(a)redhat.com> - 2.1.99.test8-6
- remove explicit kernel dep (#146153)
pygtk2-2.5.3-1
--------------
* Tue Jan 25 2005 Jeremy Katz <katzj(a)redhat.com> - 2.5.3-1
- 2.5.3
rhpl-0.153-1
------------
* Tue Jan 25 2005 Peter Jones <pjones(a)redhat.com> - 0.153-1
- add Russian unicode keyboard (#146009)
- revert glibc-kernheaders fix.
rpmdb-fedora-1:4-0.20050126
---------------------------
ruby-1.8.2-4
------------
* Tue Jan 25 2005 Akira TAGOH <tagoh(a)redhat.com> - 1.8.2-4
- fixed the wrong generation of file manifest. (#146055)
- spec file clean up.
selinux-policy-strict-1.21.3-3
------------------------------
* Tue Jan 25 2005 Dan Walsh <dwalsh(a)redhat.com> 1.21.3-3
- Fix crond to run in unconfined_domain on targeted policy
- Eliminate execmod from gpg
selinux-policy-targeted-1.21.3-3
--------------------------------
* Tue Jan 25 2005 Dan Walsh <dwalsh(a)redhat.com> 1.21.3-3
- Fix crond to run in unconfined_domain on targeted policy
- Eliminate execmod from gpg
squid-7:2.5.STABLE7-3
---------------------
* Tue Jan 25 2005 Jay Fenlason <fenlason(a)redhat.com> 7:2.5.STABLE7-3
- Include more upstream patches, including two for security holes.
tn5250-0.16.5-3
---------------
* Tue Jan 25 2005 Karsten Hopp <karsten(a)redhat.de> 0.16.5-3
- add BuildRequires ncurses-devel (#137558)
vixie-cron-1:4.1-22
-------------------
* Tue Jan 25 2005 Jason Vas Dias <jvdias(a)redhat.com> - 4.1-22
- Fix bug 146073 - allow the 'pam_access' module to be used with
- cron - set 'PAM_TTY' item to 'cron' .
xfce-mcs-plugins-4.2.0-1
------------------------
* Mon Jan 24 2005 Than Ngo <than(a)redhat.com> 4.2.0-1
- 4.2.0
xfce4-panel-4.2.0-1
-------------------
* Tue Jan 25 2005 Than Ngo <than(a)redhat.com> 4.2.0-1
- 4.2.0
* Wed Dec 08 2004 Than Ngo <than(a)redhat.com> 4.0.6-2
- add patch to use lauchmail/htmlview #142160
yum-2.1.13-1
------------
* Tue Jan 25 2005 Jeremy Katz <katzj(a)redhat.com> - 2.1.13-1
- update to 2.1.13
8:24 a.m.
On Wed, 2005-01-26 at 14:47, Build System wrote:
New package jakarta-commons-beanutils
Jakarta Commons BeanUtils Package
<snip more Jakarta and Struts packages>
Hmm, I thought you were striving to reduce the amount of packages going
into Core? Just asking really, but is Jakarta and Struts something that
should be in Core? If so, why? What makes them important "base
distribution" packages?
(Sorry if I missed something and this is something that'll be moved to
Pre-Extras)
--
Tarjei
8:38 a.m.
Le mercredi 26 janvier 2005 à 15:24 +0100, Tarjei Knapstad a écrit :
On Wed, 2005-01-26 at 14:47, Build System wrote:
>
> New package jakarta-commons-beanutils
> Jakarta Commons BeanUtils Package
>
<snip more Jakarta and Struts packages>
Hmm, I thought you were striving to reduce the amount of packages going
into Core? Just asking really, but is Jakarta and Struts something that
should be in Core? If so, why? What makes them important "base
distribution" packages?
(Sorry if I missed something and this is something that'll be moved to
Pre-Extras)
Obviously that's a lot of stuff that will be used in RHEL.
It's nice to see that FC users will have access to the same java
infrastructure (unlike before when the stuff Red Hat did for paying
customers and the one dumped on FC people had nothing in common). Plus
given the spread of java in academic circles we might expect some nice
student projects to come out of it once there is a good gcj base in FC.
--
Nicolas Mailhot
1:17 p.m.
Le mercredi 26 janvier 2005 à 15:38 +0100, Nicolas Mailhot a écrit :
Le mercredi 26 janvier 2005 à 15:24 +0100, Tarjei Knapstad a écrit :
> On Wed, 2005-01-26 at 14:47, Build System wrote:
>
> >
> > New package jakarta-commons-beanutils
> > Jakarta Commons BeanUtils Package
> >
>
> <snip more Jakarta and Struts packages>
>
> Hmm, I thought you were striving to reduce the amount of packages going
> into Core? Just asking really, but is Jakarta and Struts something that
> should be in Core? If so, why? What makes them important "base
> distribution" packages?
>
> (Sorry if I missed something and this is something that'll be moved to
> Pre-Extras)
Obviously that's a lot of stuff that will be used in RHEL.
I don't remember Red Hat stating that Fedora *Core* have a direct
relationship this RHEL.
For me, RHEL can be :
FC + FE + other things
It's nice to see that FC users will have access to the same java
infrastructure (unlike before when the stuff Red Hat did for paying
customers and the one dumped on FC people had nothing in common). Plus
given the spread of java in academic circles we might expect some nice
student projects to come out of it once there is a good gcj base in FC.
2:27 p.m.
Le mercredi 26 janvier 2005 à 20:17 +0100, Féliciano Matias a écrit :
Le mercredi 26 janvier 2005 à 15:38 +0100, Nicolas Mailhot a écrit :
> Le mercredi 26 janvier 2005 à 15:24 +0100, Tarjei Knapstad a écrit :
> > On Wed, 2005-01-26 at 14:47, Build System wrote:
> >
> > >
> > > New package jakarta-commons-beanutils
> > > Jakarta Commons BeanUtils Package
> > >
> >
> > <snip more Jakarta and Struts packages>
> >
> > Hmm, I thought you were striving to reduce the amount of packages going
> > into Core? Just asking really, but is Jakarta and Struts something that
> > should be in Core? If so, why? What makes them important "base
> > distribution" packages?
> >
> > (Sorry if I missed something and this is something that'll be moved to
> > Pre-Extras)
>
> Obviously that's a lot of stuff that will be used in RHEL.
I don't remember Red Hat stating that Fedora *Core* have a direct
relationship this RHEL.
For me, RHEL can be :
FC + FE + other things
One big reason RH is in Fedora is for the RHEL it makes out of it
One big reason a lot of people use Fedora is the RedHat touch they get
for free. So it's a symbiotic relationship.
I for one would be the last to complain I have access in FC to large
parts of RHEL. We're not talking about resources Red Hat is taking from
parts of Fedora to reallocate elsewhere (which is IMHO a large part of
what's extra is about). We're talking about ressources Red Hat already
allocated for its *paying* customers and is sharing for free with FC
users (If you just take a peek at who's maintaining the java packages
you'll see they're not people already contributing heavily to other
parts of FC. So don't worry your packages are safe).
Complaining about a free gift is not overly polite.
--
Nicolas Mailhot
3:22 a.m.
--- seth vidal <skvidal(a)phy.duke.edu> wrote:
> Complaining about a free gift is not overly
polite.
That's funny - from what I can tell it is the mantra
of most open source
software development.
or to put it another way:
"Look a gift horse in the mouth"
true. otherwise we wouldnt be able to direct any sort
of criticism, constructive or otherwise at the fedora
project or even Linux
=====
Regards
Rahul Sundaram
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
3:10 p.m.
Le mercredi 26 janvier 2005 à 21:27 +0100, Nicolas Mailhot a écrit :
Le mercredi 26 janvier 2005 à 20:17 +0100, Féliciano Matias a écrit
:
> For me, RHEL can be :
> FC + FE + other things
One big reason RH is in Fedora is for the RHEL it makes out of it
One big reason a lot of people use Fedora is the RedHat touch they get
for free. So it's a symbiotic relationship.
I for one would be the last to complain I have access in FC to large
parts of RHEL. We're not talking about resources Red Hat is taking from
parts of Fedora to reallocate elsewhere (which is IMHO a large part of
what's extra is about). We're talking about ressources Red Hat already
allocated for its *paying* customers and is sharing for free with FC
users (If you just take a peek at who's maintaining the java packages
you'll see they're not people already contributing heavily to other
parts of FC. So don't worry your packages are safe).
Nice speech.
Complaining about a free gift is not overly polite.
What are you talking about ?
I just try to figure out why java stuff should be in Fedora Core.
I think some java stuff can be push in Fedora Extra. In don't think
jakarta is a "core component" for an OS. I do not use java a lot and
perhaps I am wrong.
If you don't agree with my point, just explain why I am wrong.
PS : I use Fedora and I use/buy RHEL. I am really happy with the Red
Hat's work and how Red Hat manage business and free software.
3:40 p.m.
Le mercredi 26 janvier 2005 à 22:10 +0100, Féliciano Matias a écrit :
I just try to figure out why java stuff should be in Fedora Core.
I think some java stuff can be push in Fedora Extra. In don't think
jakarta is a "core component" for an OS. I do not use java a lot and
perhaps I am wrong.
All the jakarta (and particularly the commons bits) are infrastructure
libraries that are used in an awful lot of java projects (including big
apache projects like ant, tomcat, geronimo... but also your run-of-the-
mill in-house java development, other big apps like eclipse, etc). The
java world is huge, but a large part of its OSS elements united under
the apache/jakarta umbrella several years ago. There is no big app named
jakarta just like there is no big app named GNU but if you remove the
jakarta bits very few large OSS java projects will run (I'm writing
large because obviously small student projects care much less about
component reuse)
Now jakarta is big enough there are probably some bits in it that do not
belong in core, but trust me the Red hat people are starting from the
ground up and we're far from the point were java games are proposed for
inclusion. Right now its strictly core library pool seeding. It will
probably reach perl size before apps start trickling in (the difference
being free java is split in small interdependent projects instead of a
big centralised blob - the (stupid) jpackage counter is showing 1381
packages right now and a big part of the repository is infrastructure
stuff not leaf apps)
--
Nicolas Mailhot
5:56 a.m.
On Thu, Jan 27, 2005 at 11:34:28AM +0000, David Woodhouse wrote:
On Wed, 2005-01-26 at 09:46 -0500, Andrew Overholt wrote:
> We were having some stability issues with 3.1M4 natively compiled.
> I'm hoping to go back to a 3.1 milestone build before FC4.
Hmm. Now there's no PPC package. Is it possible to build 3.0 for PPC?
If you have a jre, you can use the standard
eclipse-SDK-3.0.1-linux-gtk.zip with
http://gsd.di.uminho.pt/old/luciano/eclipse-SDK-3.0.1-linux-gtk-x86_ppc.t...
on top.
Regards,
Luciano Rocha
--
2/16
7:03 a.m.
* David Woodhouse <dwmw2(a)infradead.org> [2005-01-27 06:38]:
On Wed, 2005-01-26 at 09:46 -0500, Andrew Overholt wrote:
> We were having some stability issues with 3.1M4 natively compiled.
> I'm hoping to go back to a 3.1 milestone build before FC4.
Hmm. Now there's no PPC package. Is it possible to build 3.0 for PPC?
Of course. I was planning on doing this today (I have a Fedora iBook
myself).
Andrew
7:17 a.m.
On Thu, 2005-01-27 at 08:03 -0500, Andrew Overholt wrote:
Of course. I was planning on doing this today (I have a Fedora
iBook
myself).
Cool, thanks.
Btw, I did eventually get your flash demo working, by using the package at
ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/RPMS/flash-0.4.10-1.ppc.rpm
instead of the swfdec one.
--
dwmw2
10:51 a.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
* Andrew Overholt <overholt(a)redhat.com> [2005-01-26 09:47]:
I'm hoping to go back to a 3.1 milestone build before FC4.
Looking at the schedules for Eclipse 3.1 [1] and FC4 [2], I see the
following:
Eclipse 3.1 M6 (stable build, API freeze): 2005-04-01
FC4 Absolute devel freeze: 2005-05-02
Eclipse 3.1 M7 (stable build, development freeze, etc.): 2005-05-13
FC4 Release open, announced: 2005-06-16
I'd like to ship a 3.1 M6 (or some stable incremental build between then
and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come
out.
Choices:
a) ship as above
b) ship 3.0.x
3.1 Pros:
- between now and then we get to spend lots of time testing and getting
things pushed upstream
- this is where all development is happening
- awesome new plugins like Jeff Pound's ongoing work on the Bugzilla
plug-in are dependent upon 3.1 (without a tonne of back-porting)
- making RPMs will be much simpler than how we're doing the 3.0.1 now
- upstream supports many more architectures than they did with 3.0.1
3.1 Cons:
- lots of stuff that may not work with libgcj4/gij4
- a lot less tested than 3.0.x
3.0.x Pros:
- well-tested, established, stable code
- already have RPMs and know they build okay with gcj4
- will be the latest upstream _released_ version
3.0.x Cons:
- old code where new features are not being added
- will need back-porting if we want new things
- build is a bit of a mess (especially for arches that were unsupported
upstream)
I'd like to go with 3.1, but we'll need to do lots of testing and
bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't
that high and even getting things down to test cases is not an easy task.
I'd like to hear people's opinions.
Thanks,
Andrew
[1]
http://fedora.redhat.com/participate/schedule/
[2]
http://eclipse.org/eclipse/development/eclipse_project_plan_3_1.html
10:59 a.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
I'd like to ship a 3.1 M6 (or some stable incremental build
between then
and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come
out.
Me too. Because of ...
- awesome new plug-ins like Jeff Pound's ongoing work on the
Bugzilla
plug-in are dependent upon 3.1 (without a tonne of back-porting)
Thing like that, which would make the development life-cycle process in
eclipse more complete .. and ..
- making RPMs will be much simpler than how we're doing the
3.0.1 now
Organization of above.
I'd like to go with 3.1, but we'll need to do lots of testing
and
bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't
that high and even getting things down to test cases is not an easy task.
I'd like to hear people's opinions.
I'll help where I can. In porting the plug-ins (CDT, ChangeLog, RPM
import/export, etc) I expect some cross experience to apply.
Regards
Phil
11:48 a.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
On Thu, 27 Jan 2005 10:59:10 -0600, Phil Muldoon <pmuldoon(a)redhat.com> wrote:
> I'd like to ship a 3.1 M6 (or some stable incremental build
between then
> and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come
> out.
Me too. Because of ...
> - awesome new plug-ins like Jeff Pound's ongoing work on the Bugzilla
> plug-in are dependent upon 3.1 (without a tonne of back-porting)
Thing like that, which would make the development life-cycle process in
eclipse more complete .. and ..
> - making RPMs will be much simpler than how we're doing the 3.0.1 now
Organization of above.
> I'd like to go with 3.1, but we'll need to do lots of testing and
> bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't
> that high and even getting things down to test cases is not an easy task.
> I'd like to hear people's opinions.
I'll help where I can. In porting the plug-ins (CDT, ChangeLog, RPM
import/export, etc) I expect some cross experience to apply.
Love to help with testing. I use Eclipse 3.1M4 daily.
Regards
Phil
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Nick Bargnesi
http://www.den-4.com
Den 4 Software
pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi(a)gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0
sub 2048g/56C5D45B 2004-12-02
dd if=/dev/zero of=/dev/hda
11:53 a.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
* Nick Bargnesi <nbargnesi(a)gmail.com> [2005-01-27 12:49]:
Love to help with testing. I use Eclipse 3.1M4 daily.
Awesome! I'll probably get some 3.1 RPMs in there early next week.
Testing the 3.0.1 RPMs that are there now would also help.
If you have rawhide in your yum sources somewhere (as in [1]), you should
just have to:
yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel
Bugs should be filed under Fedora -> devel -> eclipse.
Thanks,
Andrew
[1]
[development]
name=rawhide
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/developme...
enabled=0
1:13 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
tor 2005-01-27 klockan 12:53 -0500 skrev Andrew Overholt:
* Nick Bargnesi <nbargnesi(a)gmail.com> [2005-01-27 12:49]:
>
> Love to help with testing. I use Eclipse 3.1M4 daily.
Awesome! I'll probably get some 3.1 RPMs in there early next week.
Testing the 3.0.1 RPMs that are there now would also help.
I installed 3.1M4 from rawhide when it was in there. It launched, but
performance was so-so and stability less than perfect. It's now been
replced with 3.0.1_fc-8, which does not start anymore. This is printed
on stdout:
-bash-3.00$ eclipse
libgcj failure: Duplicate class registration:
java.awt.image.RenderedImage
Warning: -Xms64M not understood. Ignoring.
Warning: -Xmx256M not understood. Ignoring.
libgcj failure: Duplicate class registration:
java.awt.image.RenderedImage
and after ~5-10 seconds of using 100% cpu, a window pops up with the
following error:
JVM terminated. Exit code=1
/usr/bin/java
-Xms64M
-Xmx256M
-Dorg.eclipse.core.runtime.ignoreLockFile=true
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db
-cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main
-os linux
-ws gtk
-arch x86
-showsplash /usr/share/eclipse/eclipse -showsplash 600
-exitdata /usr/share/eclipse/eclipse -exitdata 2130026
-data /home/builder/workspace
-vm /usr/bin/java
-vmargs
-Xms64M
-Xmx256M
-Dorg.eclipse.core.runtime.ignoreLockFile=true
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db
-cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main
Here's what's installed:
-bash-3.00$ rpm -qa | grep "gcj4\|eclipse"
eclipse-ecj-3.0.1_fc-8
eclipse-platform-3.0.1_fc-8
eclipse-jdt-3.0.1_fc-8
eclipse-source-3.0.1_fc-8
libgcj4-4.0.0-0.21
eclipse-gtk2-3.0.1_fc-8
eclipse-pde-3.0.1_fc-8
libgcj4-devel-4.0.0-0.21
/Peter
1:13 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
Hi,
* Peter Backlund <peter.backlund(a)home.se> [2005-01-27 14:11]:
libgcj failure: Duplicate class registration:
java.awt.image.RenderedImage
You'll need to make sure your java and javac alternatives are set to
java-1.4.2-gcj4-compat{,-devel}.
-bash-3.00$ rpm -qa | grep "gcj4\|eclipse"
eclipse-ecj-3.0.1_fc-8
eclipse-platform-3.0.1_fc-8
eclipse-jdt-3.0.1_fc-8
eclipse-source-3.0.1_fc-8
libgcj4-4.0.0-0.21
eclipse-gtk2-3.0.1_fc-8
eclipse-pde-3.0.1_fc-8
libgcj4-devel-4.0.0-0.21
Install the -0.22 gcc4 RPMs and the -9 eclipse RPMs.
Andrew
1:21 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
Well,
If you need feedback...
My 3.0.1-9 is not working (3.1 was despite the fact the CVS access was not).
!SESSION Jan 27, 2005 14:53:32.46 ----------------------------------------------
eclipse.buildId=200409161125
java.version=1.4.2_06
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=pt_BR
!ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.48
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError:
/usr/lib/eclipse/libswt-pi-gtk-3116.so:
/usr/lib/eclipse/libswt-pi-gtk-3116.so: undefined symbol:
XTestFakeButtonEvent
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:100)
at org.eclipse.swt.internal.gtk.OS.<clinit>(OS.java:19)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
at org.eclipse.swt.widgets.Display.<clinit>(Display.java:121)
at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:268)
at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:153)
at
org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:122)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:72)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
at org.eclipse.core.launcher.Main.run(Main.java:704)
at org.eclipse.core.launcher.Main.main(Main.java:688)
!ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.60
!MESSAGE Bundle
update(a)/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.0.1/ [43] was
not resolved.
!SUBENTRY 1 org.eclipse.osgi Jan 27, 2005 14:53:32.60
!MESSAGE Bundle
update(a)/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0/ was
picked instead.
!ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.62
!MESSAGE Bundle
update(a)/usr/share/eclipse/plugins/org.eclipse.platform.source.linux.gtk.x86_3.0.1/
[75] was not resolved.
!SUBENTRY 1 org.eclipse.osgi Jan 27, 2005 14:53:32.62
!MESSAGE Missing host org.eclipse.platform.source_[3.0.1,4.0.0).
On Thu, 27 Jan 2005 12:53:14 -0500, Andrew Overholt <overholt(a)redhat.com> wrote:
* Nick Bargnesi <nbargnesi(a)gmail.com> [2005-01-27 12:49]:
>
> Love to help with testing. I use Eclipse 3.1M4 daily.
Awesome! I'll probably get some 3.1 RPMs in there early next week.
Testing the 3.0.1 RPMs that are there now would also help.
If you have rawhide in your yum sources somewhere (as in [1]), you should
just have to:
yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel
Bugs should be filed under Fedora -> devel -> eclipse.
Thanks,
Andrew
[1]
[development]
name=rawhide
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/developme...
enabled=0
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
4:09 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
* mbneto <mbneto(a)gmail.com> [2005-01-27 14:22]:
/usr/lib/eclipse/libswt-pi-gtk-3116.so: undefined symbol:
XTestFakeButtonEvent
I can't duplicate this. I guess I should make sure to point out that we're
compiling these with gcj4 so your java and javac alternatives have to be
set to java-1.4.2-gcj4-compat. You do this like this:
su - -c "update-alternatives --set java \
/usr/lib/jvm/jre-1.4.2-gcj4/bin/java"
su - -c "update-alternatives --set javac \
/usr/lib/jvm/java-1.4.2-gcj4/bin/javac"
If you're still having problems after doing this, please file a bug.
Thanks,
Andrew
3:55 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
On Thu, 27 Jan 2005 12:53:14 -0500, Andrew Overholt <overholt(a)redhat.com> wrote:
* Nick Bargnesi <nbargnesi(a)gmail.com> [2005-01-27 12:49]:
>
> Love to help with testing. I use Eclipse 3.1M4 daily.
Awesome! I'll probably get some 3.1 RPMs in there early next week.
Testing the 3.0.1 RPMs that are there now would also help.
Tried the 3.0.1fc9 RPMs, resulted in:
libgcj failure: Duplicate class registration: java.awt.image.RenderedImage
Warning: -Xms64M not understood. Ignoring.
Warning: -Xmx256M not understood. Ignoring.
libgcj failure: Duplicate class registration: java.awt.image.RenderedImage
JVM terminated. Exit code=1
/usr/bin/java
-Xms64M
-Xmx256M
-Dorg.eclipse.core.runtime.ignoreLockFile=true
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db
-cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main
-os linux
-ws gtk
-arch x86
-showsplash /usr/share/eclipse/eclipse -showsplash 600
-exitdata /usr/share/eclipse/eclipse -exitdata 308005
-data /root/workspace
-vm /usr/bin/java
-vmargs
-Xms64M
-Xmx256M
-Dorg.eclipse.core.runtime.ignoreLockFile=true
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db
-cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main
This was executing the /usr/bin/eclipse shell script the
eclipse-platform rpm installed. Looking at the script, the reason for
the crash was the vm switch, i.e.,
ECLIPSE_OPTS="$ECLIPSE_OPTS -vm /usr/bin/java"
Unfortunately, that's no good because using the gcj vm is the point
correct? I wouldn't know where to look for issues with the gcj vm.
If you have rawhide in your yum sources somewhere (as in [1]), you should
just have to:
yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel
Bugs should be filed under Fedora -> devel -> eclipse.
Thanks,
Andrew
[1]
[development]
name=rawhide
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/developme...
enabled=0
--
Nick Bargnesi
http://www.den-4.com
Den 4 Software
pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi(a)gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0
sub 2048g/56C5D45B 2004-12-02
dd if=/dev/zero of=/dev/hda
7:37 p.m.
New subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes)
On Thu, 2005-01-27 at 11:51 -0500, Andrew Overholt wrote:
* Andrew Overholt <overholt(a)redhat.com> [2005-01-26 09:47]:
>
> I'm hoping to go back to a 3.1 milestone build before FC4.
Looking at the schedules for Eclipse 3.1 [1] and FC4 [2], I see the
following:
Eclipse 3.1 M6 (stable build, API freeze): 2005-04-01
FC4 Absolute devel freeze: 2005-05-02
Eclipse 3.1 M7 (stable build, development freeze, etc.): 2005-05-13
FC4 Release open, announced: 2005-06-16
I'd like to ship a 3.1 M6 (or some stable incremental build between then
and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come
out.
Agreed, I've been using M4 and the integration builds and they're
working quite well for me, I don't really see any big issues with
eclipse itself coming up that late in the game though libgcj4/gij4 is
still a bit of a wild card, hopefully nothing big will pop up in
testing.
In functionality for Linux particularly I think 3.1 is a big step
forward with the permission bits and file permissions issues sorted out
along with GTK file chooser now being used. As well I personally find
developing upstream eclipse plugins is definitely easier with 3.1 given
the number of changes that occur in the code between releases. If we
have to go with 3.0 it's not a disaster by any means but given the
choice I definitely would prefer 3.1.
btw. I ran the rpms quickly and they worked great, awesome work!
Aaron
9:23 a.m.
ons 2005-01-26 klockan 08:48 -0600 skrev Rex Dieter:
Peter Backlund wrote:
>>New package jakarta-commons-*
>> Jakarta Commons Package
>
>
> Are these packages built with gcj into native .so libraries?
How else would they get built on/for Fedora Core? (-:
With gcj into bytecode, or with ecj into bytecode :-)
/Peter
9:19 a.m.
Peter Backlund wrote:
ons 2005-01-26 klockan 08:48 -0600 skrev Rex Dieter:
>Peter Backlund wrote:
>
>>>New package jakarta-commons-*
>>> Jakarta Commons Package
>>
>>
>>Are these packages built with gcj into native .so libraries?
>
>How else would they get built on/for Fedora Core? (-:
With gcj into bytecode, or with ecj into bytecode :-)
I wasn't aware one could run/use bytecode with gcj.
-- Rex
7035
days inactive
7037
days old
28 comments
16 participants
participants (16)
-
Aaron Luchko -
Andrew Overholt -
Build System -
Dan Williams -
David Woodhouse -
Féliciano Matias -
Luciano Miguel Ferreira Rocha -
mbneto -
Nick Bargnesi -
Nicolas Mailhot -
Peter Backlund -
Phil Muldoon -
Rahul Sundaram -
Rex Dieter -
seth vidal -
Tarjei Knapstad