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.
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.
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.
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?
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.
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.
Don't forget to fix the version in you changelog entry
(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.
(In reply to comment #6) > Don't forget to fix the version in you changelog entry Fixed, thanks.
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.
Why not patch the upstream source against the source included with eclipse and keep the external package?
(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.
We're going move the icu4j plugins build out of the eclipse package and put it in the icu4j package.
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.
Whats going on here?
I believe Jeff Johnston is planning on doing this sometime early in the new year.
Created attachment 146318 [details] spec file for review Release tag to be adjusted as per new guidelines
SRPM can be obtained with 'make srpm' in the 'devel' branch of dist CVS.
URL: http://people.redhat.com/fnasser/icu4j-3.4.5-2jpp.1.src.rpm
*** Bug 227060 has been marked as a duplicate of this bug. ***
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> - 0.6-4 - And fix the link syntax. * Fri Jun 23 2006 Jesse Keating <jkeating> 0.6-4 - And fix the link syntax. * Fri Jun 23 2006 Jesse Keating <jkeating> - 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
(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
(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?
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.
(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.
Updated (in same locations as posted before)
(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.
New Package CVS Request ======================= Package Name: icu4j Short Description: International Components for Unicode for Java Owners: fnasser Branches: InitialCC: dbhole,nsantos
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*
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.
Changing the review flag.
- 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.
Can this bug be closed?
Closing bug since icu4j has been imported into cvs already.
Package Change Request ====================== Package Name: icu4j New Branches: el6 Owners: Jochen Schmitt <Jochen> InitialCC:
Use FAS account, not name and email.
Oops, sorry. I copied and pasted from comment 27 and used same format
Package Change Request ====================== Package Name: icu4j New Branches: el6 Owners: S4504kr InitialCC:
Still not working. Might it be case-sensitive?
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:
Git done (by process-git-requests).
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.
Branch already exists, user should request access in pkgdb.