Bug 199592 - Review Request: icu4j
Review Request: icu4j
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Vivek Lakshmanan
Fedora Extras Quality Assurance
: Reopened
: 227060 (view as bug list)
Depends On:
Blocks: 199504
  Show dependency treegraph
 
Reported: 2006-07-20 13:01 EDT by Ben Konrath
Modified: 2011-12-05 15:49 EST (History)
7 users (show)

See Also:
Fixed In Version: 3.4.5-2jpp.2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-07 02:58:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
viveklak: fedora‑review+


Attachments (Terms of Use)
spec file for review (8.70 KB, application/octet-stream)
2007-01-23 12:02 EST, Fernando Nasser
no flags Details

  None (edit)
Description Ben Konrath 2006-07-20 13:01:03 EDT
Spec URL:

http://people.redhat.com/bkonrath/eclipse/icu4j.spec

SRPM URL:

http://people.redhat.com/bkonrath/eclipse/icu4j-3.4.4-1jpp_1fc.src.rpm

Description: 

The International Component for Unicode for Java (ICU4J) is a library for Unicode support, software internationalization and globalization. Eclipse 3.2 uses this library for its internationalization support.
Comment 1 Jesse Keating 2006-07-20 13:13:17 EDT
The versioning doesn't pass current naming guidelines.  We've got an open
discussion on jpp based packages and need input from more RH Java folks about
the goals of the jpp naming so that we can work our guidelines to allow for an
agreed upon scheme.

Differring until this has been completed.
Comment 2 Ben Konrath 2006-07-20 13:20:11 EDT
The Eclipse packges in Fedora Core currently include a binary version of these
libraries. The purpose of this package is to remove these binary jars. Given
this, and the fact the Eclipse packages all currently use the jpp naming
convention, I respectfully request review at this time instead of waiting for
the jpp naming issue to be sorted out.
Comment 3 Jesse Keating 2006-07-20 13:44:31 EDT
I'm trying very hard to get the naming scheme approved by the freeze.

Is there upstream (jpp) packages of the icr4j stuff, or is this our local split out?
Comment 4 Ben Konrath 2006-07-20 17:34:42 EDT
This is a local split. I had to update the sources from 3.2 to 3.4.4 and add a
patch to work around a bug in the javadoc generation. Other than that the spec
file is the same.
Comment 5 David Walluck 2006-07-20 17:51:58 EDT
As stated in bug #199504, I wasn't able to build eclipse after replacing its
binary jars with icu4j 3.4.4. I did not investigate further.
Comment 6 Fernando Nasser 2006-07-20 17:54:52 EDT
Don't forget to fix the version in you changelog entry
Comment 7 Ben Konrath 2006-07-20 19:01:33 EDT
(In reply to comment #5)
> As stated in bug #199504, I wasn't able to build eclipse after replacing its
> binary jars with icu4j 3.4.4. I did not investigate further.

Right, I'll make a patch on Monday. I'm at OLS right now. 
Comment 8 Ben Konrath 2006-07-20 19:07:50 EDT
(In reply to comment #6)
> Don't forget to fix the version in you changelog entry

Fixed, thanks.
Comment 9 Ben Konrath 2006-07-21 00:13:21 EDT
I looked into this a little bit and it seems that the icu4j included with
eclipse (icu4j 3.4.4.1) is different enough from this version (icu4j 3.4.4) that
I think it is better to build 3.4.4.1. The only place to get the 3.4.4.1 source
is from the Eclipse source and even though it doesn't have build files, I think
it's best to hack the build of icu4j 3.4.4.1 into the Eclipse spec file.  

I consulted Andrew Overholt and he argees with this.
Comment 10 David Walluck 2006-07-21 13:39:38 EDT
Why not patch the upstream source against the source included with eclipse and
keep the external package?
Comment 11 Ben Konrath 2006-07-24 12:36:48 EDT
(In reply to comment #10)
> Why not patch the upstream source against the source included with eclipse and
> keep the external package?

I don't want to patch becuase it seems that 3.4.4.1 is a significant change from
3.4.4.1. They removed a whole bunch of classes and I'm not really sure what
there changes do. I'm going to file a bug upstream and see if I can figure out
what's going on.
Comment 12 Ben Konrath 2006-11-30 09:53:45 EST
We're going move the icu4j plugins build out of the eclipse package and put it
in the icu4j package.
Comment 13 Ben Konrath 2006-11-30 09:58:43 EST
Jeff, once you add the icu4j plugin build to the icu4j package, you'll need to
get it into Fedora Core. But since the Core/Extras distinction is going away, I
guess you can get it approved in either place. You should do this before FC7Test1.
Comment 14 Jesse Keating 2006-12-15 12:02:19 EST
Whats going on here?
Comment 15 Andrew Overholt 2006-12-15 12:04:43 EST
I believe Jeff Johnston is planning on doing this sometime early in the new year.
Comment 16 Fernando Nasser 2007-01-23 12:02:00 EST
Created attachment 146318 [details]
spec file for review

Release tag to be adjusted as per new guidelines
Comment 17 Fernando Nasser 2007-01-23 12:04:49 EST
SRPM can be obtained with 'make srpm' in the 'devel' branch of dist CVS.
Comment 18 Fernando Nasser 2007-01-23 12:29:54 EST
URL: http://people.redhat.com/fnasser/icu4j-3.4.5-2jpp.1.src.rpm
Comment 19 Andrew Overholt 2007-02-10 12:30:05 EST
*** Bug 227060 has been marked as a duplicate of this bug. ***
Comment 20 Vivek Lakshmanan 2007-02-12 16:18:13 EST
X suggests the subsection needs attention
+ is a positive comment
. is a specific comment about a problem

MUST:
X * package is named appropriately
 - match upstream tarball or project name
   + OK
 - try to match previous incarnations in other distributions/packagers for
consistency
   + OK
 - specfile should be %{name}.spec
   + OK
 - non-numeric characters should only be used in Release (ie. cvs or
   something)
   + OK
 - for non-numerics (pre-release, CVS snapshots, etc.), see
   http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
   . 0:3.4.5-2jpp.1 -> 0:3.4.5-2jpp.2%{?dist} to be inline with 
     http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
 - if case sensitivity is requested by upstream or you feel it should be
   not just lowercase, do so; otherwise, use all lower case for the name
   + OK
* is it legal for Fedora to distribute this?
   + OSI-approved
   X licence OSI approved
 - not a kernel module
 - not shareware
 - is it covered by patents?
 - it *probably* shouldn't be an emulator
 - no binary firmware
   + None of these apply

X * license field matches the actual license.
   + The license according
     http://www-306.ibm.com/software/globalization/icu/license.jsp is X License

* license is open source-compatible.
 - use acronyms for licences where common
   + Yes but needs to be confirmed to be the correct license, see above.
* specfile name matches %{name}
  + OK.
* verify source and patches (md5sum matches upstream, know what the patches do)
  + OK. The patches use windows style CRLF, please use sed to fix.
 - if upstream doesn't release source drops, put *clear* instructions on
   how to generate the the source drop; ie. 
  # svn export blah/tag blah
  # tar cjf blah-version-src.tar.bz2 blah
  + N/A
* skim the summary and description for typos, etc.
  + OK.

X correct buildroot
 - should be:
   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
   . Use the buildroot specified above

X * if %{?dist} is used, it should be in that form (note the ? and %
locations)
  . Use the new naming convention mentioned above

* license text included in package and marked with %doc
  + OK.

* keep old changelog entries; use judgement when removing (too old? useless?)
  + N/A

* packages meets FHS (http://www.pathname.com/fhs/)
  + OK
X rpmlint on <this package>.srpm and rpm gives no output
W: icu4j non-standard-group Development/Libraries/Java
The value of the Group tag in the package is not valid.  Valid groups are:
"Amusements/Games", "Amusements/Graphics", "Applications/Archiving",
"Applications/Communications", "Applications/Databases",
"Applications/Editors", "Applications/Emulators", "Applications/Engineering",
"Applications/File", "Applications/Internet", "Applications/Multimedia",
"Applications/Productivity", "Applications/Publishing", "Applications/System",
"Applications/Text", "Development/Debug", "Development/Debuggers",
"Development/Languages", "Development/Libraries", "Development/System",
"Development/Tools", "Documentation", "System Environment/Base", "System
Environment/Daemons", "System Environment/Kernel", "System
Environment/Libraries", "System Environment/Shells", "User
Interface/Desktops", "User Interface/X", "User Interface/X Hardware Support".

W: icu4j wrong-file-end-of-line-encoding
/usr/share/doc/icu4j-3.4.5/license.html
This file has wrong end-of-line encoding, usually caused by creation or
modification on a non-Unix system. It could prevent it from being displayed
correctly in some circumstances.

W: icu4j wrong-file-end-of-line-encoding
/usr/share/doc/icu4j-3.4.5/APIChangeReport.html
This file has wrong end-of-line encoding, usually caused by creation or
modification on a non-Unix system. It could prevent it from being displayed
correctly in some circumstances.

W: icu4j wrong-file-end-of-line-encoding
/usr/share/doc/icu4j-3.4.5/readme.html
This file has wrong end-of-line encoding, usually caused by creation or
modification on a non-Unix system. It could prevent it from being displayed
correctly in some circumstances.

W: icu4j-eclipse non-standard-group Text Editors/Integrated Development
Environments (IDE)
The value of the Group tag in the package is not valid.  Valid groups are:
"Amusements/Games", "Amusements/Graphics", "Applications/Archiving",
"Applications/Communications", "Applications/Databases",
"Applications/Editors", "Applications/Emulators", "Applications/Engineering",
"Applications/File", "Applications/Internet", "Applications/Multimedia",
"Applications/Productivity", "Applications/Publishing", "Applications/System",
"Applications/Text", "Development/Debug", "Development/Debuggers",
"Development/Languages", "Development/Libraries", "Development/System",
"Development/Tools", "Documentation", "System Environment/Base", "System
Environment/Daemons", "System Environment/Kernel", "System
Environment/Libraries", "System Environment/Shells", "User
Interface/Desktops", "User Interface/X", "User Interface/X Hardware Support".

W: icu4j-eclipse no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.
 . There should probably be an EPL file in the eclipse subpackage that needs
   to be added
W: icu4j-javadoc non-standard-group Development/Documentation
The value of the Group tag in the package is not valid.  Valid groups are:
"Amusements/Games", "Amusements/Graphics", "Applications/Archiving",
"Applications/Communications", "Applications/Databases",
"Applications/Editors", "Applications/Emulators", "Applications/Engineering",
"Applications/File", "Applications/Internet", "Applications/Multimedia",
"Applications/Productivity", "Applications/Publishing", "Applications/System",
"Applications/Text", "Development/Debug", "Development/Debuggers",
"Development/Languages", "Development/Libraries", "Development/System",
"Development/Tools", "Documentation", "System Environment/Base", "System
Environment/Daemons", "System Environment/Kernel", "System
Environment/Libraries", "System Environment/Shells", "User
Interface/Desktops", "User Interface/X", "User Interface/X Hardware Support".

W: icu4j-javadoc dangerous-command-in-%post rm
+ If you get rid of the script driven javadoc handling, you wont have to deal
with this, see below

W: icu4j non-standard-group Development/Libraries/Java
The value of the Group tag in the package is not valid.  Valid groups are:
"Amusements/Games", "Amusements/Graphics", "Applications/Archiving",
"Applications/Communications", "Applications/Databases",
"Applications/Editors", "Applications/Emulators", "Applications/Engineering",
"Applications/File", "Applications/Internet", "Applications/Multimedia",
"Applications/Productivity", "Applications/Publishing", "Applications/System",
"Applications/Text", "Development/Debug", "Development/Debuggers",
"Development/Languages", "Development/Libraries", "Development/System",
"Development/Tools", "Documentation", "System Environment/Base", "System
Environment/Daemons", "System Environment/Kernel", "System
Environment/Libraries", "System Environment/Shells", "User
Interface/Desktops", "User Interface/X", "User Interface/X Hardware Support".

W: icu4j mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 55)
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.

 - justify warnings if you think they shouldn't be there
 + Groups can be ignored
 . Fix the end line encoding
 . Add EPL documentation to eclipse package

* changelog should be in one of these formats:
  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
  - 0.6-4
  - And fix the link syntax.
  + OK

* Packager tag should not be used
  + OK

* Vendor/Distribution tag should not be used
  + OK

* use License and not Copyright 
  + OK

* Summary tag should not end in a period
  + OK

* if possible, replace PreReq with Requires(pre) and/or Requires(post)
  + N/A

* specfile is legible
 - this is largely subjective; use your judgement
   + OK

* package successfully compiles and builds on at least x86
   + ?Builds OK locally

* BuildRequires are proper
  + Builds in mock
 - builds in mock will flush out problems here
 - the following packages don't need to be listed in BuildRequires:
   bash
   bzip2
   coreutils
   cpio
   diffutils
   fedora-release (and/or redhat-release)
   gcc
   gcc-c++
   gzip
   make
   patch
   perl
   redhat-rpm-config
   rpm-build
   sed
   tar
   unzip
   which

* summary should be a short and concise description of the package
  + OK

* description expands upon summary (don't include installation
instructions)
  + OK
* make sure lines are <= 80 characters
  + Everything except the gc_support incantation seems OK, if possible
reformat

* specfile written in American English
  + OK

* make a -doc sub-package if necessary
  + OK, the javadoc subpackages are equivalent to this

* - see
  
http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b
* packages including libraries should exclude static libraries if possible
* don't use rpath
* config files should usually be marked with %config(noreplace)
* GUI apps should contain .desktop files
 + None of the above apply

* should the package contain a -devel sub-package?
  + N/A

X use macros appropriately and consistently
 - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS
 - $RPM_BUILD_ROOT and %{buildroot} used interchangably

* don't use %makeinstall
* locale data handling correct (find_lang)
 - if translations included, add BR: gettext and use %find_lang %{name} at the
   end of %install

X consider using cp -p to preserve timestamps
  Some cp commands not using -p option, suggest adding them if possible

* split Requires(pre,post) into two separate lines
  + N/A

* package should probably not be relocatable
  + Not relocatable

* package contains code
 - see http://fedoraproject.org/wiki/Packaging/Guidelines#CodeVsContent
 + OK
 - in general, there should be no offensive content
 + To the best of my knowledge no ofensive content :)

X package should own all directories and files
  . /usr/lib/eclipse should be owned by libswt3-gtk2 in the latest update to it,
add a require for it
  . jpackage-utils is needed for the javadoc and base package since it needs
/usr/share/java{,doc}.
    Please take a look at
https://zarb.org/pipermail/jpackage-discuss/2007-February/011119.html and
    modify the javadoc handling appropriately. If you use the above javadoc
handling then you can 
    limit to Requires: jpackage-utils in both javadoc and main packages, o/w you
need Requires(post)
    and Requires on jpackage-utils as well as Requires(post) on rm and ln in
javadoc package and a 
    requires on the main package for jpackage-utils
 
* there should be no %files duplicates
  + OK

* file permissions should be okay; %defattrs should be present
  + OK

* %clean should be present
  + OK

* %doc files should not affect runtime
  + OK

* if it is a web apps, it should be in /usr/share/%{name} and *not* /var/www
  + Not a web app

X verify the final provides and requires of the binary RPMs
  + Builds in mock fine
  . Requires need to be fixed, check "package should own all directories and files"

SHOULD:
* package should include license text in the package and mark it with %doc
  + OK
* package should build on i386
  + Builds in mock
* package should build in mock
  + OK

Comment 21 Matt Wringe 2007-02-14 00:55:05 EST
(In reply to comment #20)
> ...
>  - for non-numerics (pre-release, CVS snapshots, etc.), see
>    http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
>    . 0:3.4.5-2jpp.1 -> 0:3.4.5-2jpp.2%{?dist} to be inline with 
>      http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
Done

>  ...
> X * license field matches the actual license.
>    + The license according
>      http://www-306.ibm.com/software/globalization/icu/license.jsp is X License
Yeah, the X License = X.net License = X11 License = MIT License
Only the MIT license and the X.net License appear in the offical rpmlint
license list. Should this be called what the project calls it "X license"
or should the MIT license be used instead since rpmlint likes it better?

> ...
> X correct buildroot
>  - should be:
>    %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>    . Use the buildroot specified above
Fixed
 
> X * if %{?dist} is used, it should be in that form (note the ? and %
> locations)
>   . Use the new naming convention mentioned above
Fixed

> ...
> X rpmlint on <this package>.srpm and rpm gives no output
> W: icu4j non-standard-group Development/Libraries/Java
- group warnings can be ignored
> W: icu4j wrong-file-end-of-line-encoding
- fixed
> W: icu4j wrong-file-end-of-line-encoding
- fixed
> W: icu4j wrong-file-end-of-line-encoding
- fixed
> W: icu4j-eclipse non-standard-group Text Editors/Integrated Development
> Environments (IDE)
- group warnings can be ignored
> W: icu4j-eclipse no-documentation
>  . There should probably be an EPL file in the eclipse subpackage that needs
>    to be added
The plugin should be under the X license since this is the license of the
project. This has now been added

> W: icu4j-javadoc non-standard-group Development/Documentation
- can ignore group warnings
> W: icu4j-javadoc dangerous-command-in-%post rm
- fixed
> W: icu4j non-standard-group Development/Libraries/Java
- can ignore group warnings
> W: icu4j mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 55)
- fixed

> ...
> X use macros appropriately and consistently
>  - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS
>  - $RPM_BUILD_ROOT and %{buildroot} used interchangably
fixed
 
> ...
> X consider using cp -p to preserve timestamps
>   Some cp commands not using -p option, suggest adding them if possible
fixed

>...
> X package should own all directories and files
>   . /usr/lib/eclipse should be owned by libswt3-gtk2 in the latest update to it,
> add a require for it
>   . jpackage-utils is needed for the javadoc and base package since it needs
> /usr/share/java{,doc}.
>     Please take a look at
> https://zarb.org/pipermail/jpackage-discuss/2007-February/011119.html and
>     modify the javadoc handling appropriately. If you use the above javadoc
> handling then you can 
>     limit to Requires: jpackage-utils in both javadoc and main packages, o/w you
> need Requires(post)
>     and Requires on jpackage-utils as well as Requires(post) on rm and ln in
> javadoc package and a 
>     requires on the main package for jpackage-utils
added requires on jpackage-utils and the libecj3-gtk to proper packages

> ...
> X verify the final provides and requires of the binary RPMs
>   + Builds in mock fine
>   . Requires need to be fixed, check "package should own all directories and
files"
> 
> SHOULD:
> * package should include license text in the package and mark it with %doc
>   + OK
> * package should build on i386
>   + Builds in mock
> * package should build in mock
>   + OK
> 
> 

RPMLINT on new packages:

srpm:
rpmlint icu4j-3.4.5-2jpp.1.fc7.src.rpm
W: icu4j non-standard-group Development/Libraries/Java

rpms:
E: icu4j explicit-lib-dependency libswt3-gtk2
- I believe this error is only occuring because it has 'lib' in the name.
This package is needed to build the eclipse plugin subpackage.

W: icu4j non-standard-group Development/Libraries/Java
W: icu4j-eclipse non-standard-group Text Editors/Integrated Development
Environments (IDE)
W: icu4j-javadoc non-standard-group Development/Documentation

The updated packages can be found here:
https://mwringe.108.redhat.com/files/documents/175/215/icu4j-3.4.5-2jpp.1.fc7.src.rpm
https://mwringe.108.redhat.com/files/documents/175/216/icu4j-3.4.5-2jpp.1.fc7.i386.rpm
https://mwringe.108.redhat.com/files/documents/175/217/icu4j-debuginfo-3.4.5-2jpp.1.fc7.i386.rpm
https://mwringe.108.redhat.com/files/documents/175/218/icu4j-eclipse-3.4.5-2jpp.1.fc7.i386.rpm
https://mwringe.108.redhat.com/files/documents/175/219/icu4j-javadoc-3.4.5-2jpp.1.fc7.i386.rpm
Comment 22 Andrew Overholt 2007-02-14 08:45:59 EST
(In reply to comment #21)
> > X package should own all directories and files
> >   . /usr/lib/eclipse should be owned by libswt3-gtk2 in the latest update to it,
> > add a require for it

No, it should require eclipse-platform.  While SWT does indeed own that
directory, the plugin should probably require eclipse-platform.  Ben, can you
give us your opinion?
Comment 23 Ben Konrath 2007-02-14 10:07:08 EST
Technically the icu4j OSGi jars shouldn't require any eclipse subpackage. It is
possible that someone would want to use the OSGi jar instead of the regular jar
outside of eclipse. Here's what I think we should do: remove the 'Requires:
libswt3-gtk2' and put the OSGi jar in /usr/share/java/. That will allow it to be
installed independently of eclispe and we can just symlink to it in the eclipse
build. If the OSGi jar can be used in place of the regular jar, I think we
should only include the OSGi jar and add a symlink for the regular jar in
/usr/share/java/.

Also, I noticed a small error with the src.zip creation; '--date=1/1/1970'
should be changed to '--date=1/1/1980' because the zip file format starts at
1980. Really it's my mistake from when I first updated this spec file, sorry.
Comment 24 Vivek Lakshmanan 2007-02-14 10:36:02 EST
(In reply to comment #21)
> (In reply to comment #20)
> > ...
> >  - for non-numerics (pre-release, CVS snapshots, etc.), see
> >    http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
> >    . 0:3.4.5-2jpp.1 -> 0:3.4.5-2jpp.2%{?dist} to be inline with 
> >      http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
Looks good, 0:3.4.5-2jpp.1.fc7 is rpm newer 
> >  ...
> > X * license field matches the actual license.
> >    + The license according
> >      http://www-306.ibm.com/software/globalization/icu/license.jsp is X License
> Yeah, the X License = X.net License = X11 License = MIT License
> Only the MIT license and the X.net License appear in the offical rpmlint
> license list. Should this be called what the project calls it "X license"
> or should the MIT license be used instead since rpmlint likes it better?
> 
MIT style seems correct to me for this package


> > W: icu4j-eclipse no-documentation
> >  . There should probably be an EPL file in the eclipse subpackage that needs
> >    to be added
> The plugin should be under the X license since this is the license of the
> project. This has now been added
OK

> > X package should own all directories and files
> >   . /usr/lib/eclipse should be owned by libswt3-gtk2 in the latest update to it,
Please apply bkonrath's suggestion above

> > add a require for it
> >   . jpackage-utils is needed for the javadoc and base package since it needs
> > /usr/share/java{,doc}.

Also please apply the fix to the src.zip that bkonrath mentioned
Everything else looks good.
Comment 25 Matt Wringe 2007-02-14 16:26:56 EST
Updated (in same locations as posted before)
Comment 26 Vivek Lakshmanan 2007-02-14 17:11:43 EST
(In reply to comment #25)
> Updated (in same locations as posted before)
The requires has been switched to eclipse-rcp and the eclipse jars are under
%{_datadir}/eclipse/{features/plugins}. I think this is OK.
APPROVED
Assigning to owner to build into rawhide.

Please let me know when the package is built and once verified in Rawhide I will
close the bug.
Comment 27 Fernando Nasser 2007-03-12 17:02:53 EDT
New Package CVS Request
=======================
Package Name: icu4j
Short Description: International Components for Unicode for Java
Owners: fnasser@redhat.com
Branches:
InitialCC: dbhole@redhat.com,nsantos@redhat.com
Comment 28 Anthony Green 2007-03-16 17:43:00 EDT
I can't build this thing...

RPM build errors:
    File not found by glob:
/var/tmp/icu4j-3.4.5-2jpp.1-root-root/usr/lib/gcj/icu4j/com.ibm.icu*
Comment 29 Jeff Johnston 2007-03-16 18:27:41 EDT
This error is known.  The package has problems with recent eclipse-rcp changes.
 For now, the eclipse plugin subpackage has been disabled.  The latest changes
can be found at:

  http://www.vermillionskye.com/downloads/icu4j.spec
  http://www.vermillionskye.com/downloads/icu4j-3.4.5-2jpp.2.src.rpm

Vivek, please give this a quick look and comment here if there are any issues.
Comment 30 Vivek Lakshmanan 2007-03-19 10:48:12 EDT
Changing the review flag.
Comment 31 Vivek Lakshmanan 2007-03-19 10:51:04 EDT
- Builds on mock (doesnt produce the -eclipse subpackage as expected)
- Seems to pass the criterias for review
Provides of the rpms:
$ rpm -qp --provides icu4j-3.4.5-2jpp.2/icu4j*.i386.rpm
icu4j-3.4.5.jar.so  
icu4j = 0:3.4.5-2jpp.2.fc7
icu4j-3.4.5.jar.so.debug  
icu4j-debuginfo = 0:3.4.5-2jpp.2.fc7
icu4j-javadoc = 0:3.4.5-2jpp.2.fc7

Requires of the rpms:
$ rpm -qp --requires icu4j-3.4.5-2jpp.2/icu4j*.i386.rpm
/bin/sh  
/bin/sh  
java-gcj-compat  
java-gcj-compat  
jpackage-utils  
libc.so.6  
libc.so.6(GLIBC_2.1.3)  
libdl.so.2  
libgcc_s.so.1  
libgcc_s.so.1(GCC_3.0)  
libgcc_s.so.1(GLIBC_2.0)  
libgcj_bc.so.1  
libm.so.6  
libm.so.6(GLIBC_2.0)  
libpthread.so.0  
librt.so.1  
libz.so.1  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
jpackage-utils  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Everything seems to be in order IMO. 

APPROVED.

Please build in plague and comment here, once verified as visible on rawhide the
bug can be closed.
Comment 32 Ben Konrath 2007-04-27 01:54:02 EDT
Can this bug be closed?
Comment 33 Ben Konrath 2007-06-07 02:58:58 EDT
Closing bug since icu4j has been imported into cvs already.
Comment 34 Deepak Bhole 2011-12-05 14:24:38 EST
Package Change Request
======================
Package Name: icu4j
New Branches: el6
Owners: Jochen Schmitt <Jochen@herr-schmitt.de>
InitialCC:
Comment 35 Jon Ciesla 2011-12-05 14:34:27 EST
Use FAS account, not name and email.
Comment 36 Deepak Bhole 2011-12-05 14:40:14 EST
Oops, sorry. I copied and pasted from comment 27 and used same format
Comment 37 Deepak Bhole 2011-12-05 14:40:48 EST
Package Change Request
======================
Package Name: icu4j
New Branches: el6
Owners: S4504kr
InitialCC:
Comment 38 Jon Ciesla 2011-12-05 14:45:27 EST
Still not working.  Might it be case-sensitive?
Comment 39 Deepak Bhole 2011-12-05 14:54:20 EST
Ah sorry, his Fedora Wiki name has a different case. Last try, hopefully:

Package Change Request
======================
Package Name: icu4j
New Branches: el6
Owners: s4504kr
InitialCC:
Comment 40 Jon Ciesla 2011-12-05 14:55:21 EST
Git done (by process-git-requests).
Comment 41 Fernando Nasser 2011-12-05 15:43:09 EST
Package Change Request
======================
Package Name: icu4j
New Branches: el6
Owners: fnasser

Jochen Schmitt wants to build pdftk for EPEL-6 and that has icu4j as a dependency.
Comment 42 Jon Ciesla 2011-12-05 15:49:26 EST
Branch already exists, user should request access in pkgdb.

Note You need to log in before you can comment on or make changes to this bug.