Strange build error for classpathx-mail
by Orion Poplawski
Starting looking into updating classpathx-mail to version 1.1.2 (anyone
know of a reason not to?).
Got a really weird internal compiler error on the ppc64 build:
[javac] 1. ERROR in
/builddir/build/BUILD/mail-1.1.2/inetlib-1.1.1/source/org/jpackage/mail/inet/imap/IMAPConnection.java
(at line 0)
[javac] /*
[javac] ^
[javac] Internal compiler error
[javac] java.lang.NullPointerException
[javac] at org.eclipse.jdt.internal.compiler.looku
[javac] p.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:262)
[javac] at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719)
[javac] at org.eclipse.jdt.i
[javac]
nternal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699)
[javac] at
org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294)
[javac] at org.eclipse.jdt.internal.com
[javac]
piler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128)
[javac] at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:179)
[javac] at org.eclipse.jdt.inte
[javac]
rnal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456)
[javac] at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510)
[javac] at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359)
[javac] at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Compi
[javac] lationUnitScope.java:435)
[javac] at
org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:736)
[javac] at
org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
[javac] at java.lang.Thread.run(libgcj.so.9)
Other arches seemed okay but got cancelled. See:
http://koji.fedoraproject.org/koji/taskinfo?taskID=809142
This was on ppc7.
Resubmitted and it built okay (or at least got past this point). This
time on ppc2
http://koji.fedoraproject.org/koji/taskinfo?taskID=809169
Fully successful build (if anyone wants to take a look at the package):
http://koji.fedoraproject.org/koji/taskinfo?taskID=809200
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 7 months
iText status?
by Orcan Ogetbil
Hi, I saw that the iText software caused some licensing trouble in the past:
https://bugzilla.redhat.com/show_bug.cgi?id=176981
and especially
https://bugzilla.redhat.com/show_bug.cgi?id=236309
According to the second link it was removed from F-7 because of the fact that it contained some Sun-licensed files.
I downloaded the software from its current website:
http://www.lowagie.com/iText/download.html
The website claims a dual MPLv1.1 / LGPL license. Inside the package there is a text file (core/com/lowagie/text/misc_licenses.txt), which I will paste to the bottom of this email.
What is the current status of iText on Fedora? Was there a discussion? Can we consider releasing it again?
-----misc_licenses.txt-----
(1)
ExceptionConverter:
The original version of this class was published in an article by Heinz Kabutz.
Read http://www.javaspecialists.co.za/archive/newsletter.do?issue=033&print=ye...
"This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information.
(2)
SimpleXMLParser:
The original version of this class was published in a JavaWorld article by Steven Brandt:
http://www.javaworld.com/javaworld/javatips/jw-javatip128.html
Jennifer Orr (JavaWorld) wrote: "You have permission to use the code appearing in Steven Brandt's JavaWorld article, 'Java Tip 128: Create a quick-and-dirty XML parser.'
We ask that you reference the author as the creator and JavaWorld as the original publisher of the code." Steven Brandt also agreed with the use of this class.
(3)
The following files contain material that was copyrighted by SUN:
com/lowagie/text/pdf/LZWDecoder.java (first appearance in iText: 2002-02-08)
com/lowagie/text/pdf/codec/BmpImage.java (first appearance in iText: 2003-06-20)
com/lowagie/text/pdf/codec/PngImage.java (first appearance in iText: 2003-04-25)
com/lowagie/text/pdf/codec/TIFFDirectory.java (first appearance in iText: 2003-04-09)
com/lowagie/text/pdf/codec/TIFFFaxDecoder.java (first appearance in iText: 2003-04-09)
com/lowagie/text/pdf/codec/TIFFField.java (first appearance in iText: 2003-04-09)
com/lowagie/text/pdf/codec/TIFFLZWDecoder.java (first appearance in iText: 2003-04-09)
The original code was released under the BSD license, and contained the following extra restriction: "You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility."
In a mail sent to Bruno Lowagie on January 23, 2008, Brian Burkhalter (@sun.com) writes: "This code is under a BSD license and supersedes the older codec packages on which your code is based. It also includes numerous fixes among them being the ability to handle a lot of 'broken' TIFFs."
Note that numerous fixes were applied to the code used in iText by Paulo Soares, but apart from the fixes there were no essential changes between the code that was originally adapted and the code that is now available under the following license:
Copyright (c) 2005 Sun Microsystems, Inc. All Rights Reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistribution of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistribution in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
Neither the name of Sun Microsystems, Inc. or the names of
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
This software is provided "AS IS," without a warranty of any
kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY
EXCLUDED. SUN MIDROSYSTEMS, INC. ("SUN") AND ITS LICENSORS SHALL
NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF
USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS
DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR
ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL,
CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND
REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR
INABILITY TO USE THIS SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
You acknowledge that this software is not designed or intended for
use in the design, construction, operation or maintenance of any
nuclear facility.
The main difference can be found in the final paragraph: the restriction
that the source code is not "licensed" in this particular situation has
been removed.
FYI: Brian also added: "A bit of history might be in order.
The codec classes that you used originally were based on some
classes included with JAI but not strictly part of JAI.
As of Java SE 1.4 an official Image I/O framework was
added in javax.imageio.... This frameork supports these formats:
Java 1.4: GIF (read only), JPEG, PNG
Java 1.5: Added support for BMP and WBMP
Java 1.6: Added support for writing GIF
The JAI Image I/O Tools packages (jai-imageio-core) were created
to support formats handled by JAI but not included in Java SE
as well as some new things like JPEG2000."
(4) the file com/lowagie/text/pdf/codec/TIFFConstants
and some other TIFF related code is derived from LIBTIFF:
Copyright (c) 1988-1997 Sam Leffler
Copyright (c) 1991-1997 Silicon Graphics, Inc.
Permission to use, copy, modify, distribute, and sell this software and
its documentation for any purpose is hereby granted without fee, provided
that (i) the above copyright notices and this permission notice appear in
all copies of the software and related documentation, and (ii) the names of Sam Leffler and Silicon Graphics may not be used in any advertising or
publicity relating to the software without the specific, prior written
permission of Sam Leffler and Silicon Graphics.
THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,
EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR
ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND,
OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF
LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
OF THIS SOFTWARE.
(5)
BidiOrder:
As stated in the Javadoc comments, materials from Unicode.org are used in the class com/lowagie/text/pdf/BidiOrder.java
The following license applies to these materials:
http://www.unicode.org/copyright.html#Exhibit1
EXHIBIT 1
UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
Unicode Data Files include all data files under the directories
http://www.unicode.org/Public/, http://www.unicode.org/reports/,
and http://www.unicode.org/cldr/data/ . Unicode Software includes any source code published in the Unicode Standard or under the directories http://www.unicode.org/Public/, http://www.unicode.org/reports/, and http://www.unicode.org/cldr/data/.
NOTICE TO USER: Carefully read the following legal agreement. BY DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S DATA FILES ("DATA FILES"), AND/OR SOFTWARE ("SOFTWARE"), YOU UNEQUIVOCALLY ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE TERMS AND CNDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COP, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.
ALL OF THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT DOWNLOAD, INSTALL, COPY, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.
COPYRIGHT AND PERMISSION NOTICE
Copyright (C) 1991-2007 Unicode, Inc. All rights reserved. Distributed under the Terms of Use in http://www.unicode.org/copyright.html.
Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files and any associated documentation (the "Data Files") or Unicode software and any associated documentation (the "Software") to deal in the Data Files or Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software, and to permit persons to whom the Data Files or Software are furnished to do so, provided that (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software, (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with the Data File(s) or Software that the data or software has been modified.
THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTAILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in these Data Files or Software without prior written authorization of the
copyright holder.
14 years, 8 months
Cross-compiling under CDT autotools
by Matt Hoosier
Hi,
My company is interested in using Eclipse and CDT for embedded Linux
development. In the past, we've used some other IDE's that have built-in
knowledge of autoconf/automake, and by adding plugins to modify the shell
environment just prior to executing the 'configure' and 'make' steps, been
able to fairly easily divert the normal Autotools workflow to instead
consult a cross-compiled sysroot directory for libraries and headers.
I'm not clear on what the best way to do this is in CDT autotools. The code
which spawns 'autoconf', for example, doesn't really consult any extension
points to allow outside plug-ins the ability to customize the environment
variables (say, CFLAGS, CPPFLAGS, LDFLAGS, ...) or the path at which the
autoconf binary will be found. Do you have any ideas on a good way to do
this?
Regards,
Matt Hoosier
14 years, 8 months
Packaging guidelines - do we need to repack jars for noarch Java packages?
by Sean Flanigan
G'day!
I've been creating a package for eclipse-nls
<https://bugzilla.redhat.com/show_bug.cgi?id=456972>, and I added this
to my spec file:
# Disable repacking of jars, since it takes forever for all the little
jars,
# and we don't need multilib anyway:
%define __jar_repack %{nil}
I haven't found a good explanation of the reasons behind jar repacking,
but I gather it's something to do with multilib. What happens if you
don't repack when you should?
Jar repacking is incredibly slow when you have lots of little plugins
(hello Eclipse!), so avoiding it is nice.
I'm pretty sure it's safe to skip repacking in my case, because my
package contains nothing except .properties files inside Eclipse plugins
which are in jars when I download them, but is it safe to do in more
general cases, such as noarch packages?
Is there anything useful we could add to the guidelines?
Regards
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
14 years, 8 months
Trying to build tomcat app
by Orion Poplawski
I'm trying to build a tomcat application but getting:
+ ant -lib /usr/share/java/tomcat6
Buildfile: build.xml
BUILD FAILED
/builddir/build/BUILD/openmailarchiva-1.7.5e/build.xml:35: taskdef class
org.apache.catalina.ant.InstallTask cannot be found
I've installed tomcat6-lib and there is
/usr/share/java/tomcat6/catalina-ant.jar which is where the InstallTask
class is. How do I point the build to it?
Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 9 months
How to get Ruby installed on Eclipse 3.4?
by Dan Thurman
I'm a bit perplexed..
How do I install Ruby on Eclipse 3.4? Seems that it wants
Equinox - but I don't seem to have this listed in my installed
list - Just straight Eclipse so far.
Here is the barf I get:
Cannot complete the request. See the details.
Cannot find a solution where both Match[requiredCapability:
org.eclipse.equinox.p2.iu/org.epic.regexp/[0.5.1,0.5.1]] and
Match[requiredCapability:
org.eclipse.equinox.p2.iu/org.epic.regexp/[0.1.4,0.1.4]] can be satisfied.
I am using straight Eclipse 3.4 (Not the Fedora 9 version)
I do have EPIC installed also and thought it would work but the
difference seems to be that there must also be EPIC under Equinox
or so I assume? The RubyPeople claims it is compatable with
Eclipse v3.4.
Sorry, I am somewhat a n00b in this case.
Thanks!
Dan
14 years, 9 months
which compiler to use for java packages
by Farkas Levente
hi,
what is the current preferred compiler to use in java packages in
fedora? for me it seems mot of the java package still use gcj while
openjdk is incuded in the distro. gcj has has the advantage to be able
to use on rhel/epel too, while openjdk can compile 1.6 code. but suppose
we've got an 1.5 code what compiler should have to use in rawhide packages?
thanks.
--
Levente "Si vis pacem para bellum!"
14 years, 9 months
Eclipse pdebuild trouble
by Orion Poplawski
BUILD FAILED
/usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/build.xml:24:
The following error occurred while executing this line:
/usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/build.xml:64:
The following error occurred while executing this line:
/usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/templates/package-build/customTargets.xml:17:
The following error occurred while executing this line:
java.io.FileNotFoundException:
/usr/lib/eclipse/dropins/sdk/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts/${eclipse.pdebuild.scripts}/genericTargets.xml
(No such file or directory)
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 9 months
