Bug 426867

Updated to fix dangling symlinks in -devel.

SRPM: http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-4.srpm

oops, that should be
http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-4.src.rpm

Another update:

* Thu Dec 27 2007 Geoff Reedy <geoff> - 2.6.1-5
- Add emacs(bin) BR
- Patch out call to subversion in build.xml
- Add pkgconfig to BuildRequires

http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-5.src.rpm

With this update it is building under mock for me.

Seems that the sponsors hesitates to handle java applications in the absence of
guidelines for these apps. And I, being a rookie as you, need to show some
skills to get a sponsor. Make an informal review, that is. 

Licensing: The documentation refers to a "BSD-like" license defined in the file
docs/LICENSE. It seems to be a specific scala license, not one of the "good"
ones in wiki/Licensing.

Missing build dependencies:
   update-mime-database   shared-mime-info (post/postun)
   pkg-config             pkgconfig
   svn                    subversion

mock test fails on missing svn (subversion). After adding subversion it fails
with: /var/tmp/rpm-tmp.96363: line 77: clean: command not found

The placement of the post/postun scriptlets at the very end is unusual. Normal
place is after the %install, why not stick to this?

The package includes not only the upstream source tarball, but also the binary
distribution tarball scala-2.6.1-final. This contains generated stuff (e. g.,
jar files) and raises issues whether all source is included according to
wiki/Packaging/Guidelines. It definitely breaks wiki/PackagingDrafts/Java

Package contains a devel subpackage, makes no sense in a java context and breaks
wiki/PackagingDrafts/Java. devel contains a configuration file, belongs to
another (sub) package?

Discussion: seems that java packages requires a whole lot of copying in
%install. Is this the right place, would it be better to use ant or make to
clean up the spec file, to make it look more like a normal make-based spec-file?
Is there any (other) good example of a packaged java-app out there?

OK Rpmlint is silent
OK Package name
OK Spec file name.
OK Licensing: BSD is OK (but see above).
-  License: tag matches Licensing in code - see above
OK License included in doc - see above
-  Meets Packaging guidelines - see above.
OK Spec file in American English: I'm from Sweden, but to my understanding...
OK Spec file legible
OK Source MD5sum: 34851e6b001955b169529397d499f17f upstream and in src.rpm
OK Builds on i386
OK This is platform-independent java code.
-  Build dependencies - see above
OK Locales management -  n/a, this is java code
OK Libraries - n/a
OK Not relocateble - n/a
OK Owns it's directories.
OK No %file duplicates
OK File permissions
OK %clean target
OK Consistent macro usage
OK Code/permissive content (this is just code).
OK Documentation is in separate package.

Thanks for taking a look at my package, it looks like you might not have tried the latest release (5) 
since I fixed some of the issues you pointed out in that release.  

> skills to get a sponsor. Make an informal review, that is. 

Yeah, I know I've got to do that but my day job has been keeping me too busy lately.

> Licensing: The documentation refers to a "BSD-like" license defined in the file
> docs/LICENSE. It seems to be a specific scala license, not one of the "good"
> ones in wiki/Licensing.

I checked on fedora-legal about this (https://www.redhat.com/archives/fedora-legal-list/2007-
December/msg00012.html) and got confirmation that the license is OK and to use BSD for the license 
tag.

> 
> Missing build dependencies:
>    update-mime-database   shared-mime-info (post/postun)

I took the post/postun directly from http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-
5f93ed83c968bb73b052c06ba0d7139e28f35d93 The script is such that it will not fail if shared-mime-
info is not installed

>    pkg-config             pkgconfig
>    svn                    subversion
> 
> mock test fails on missing svn (subversion). After adding subversion it fails
> with: /var/tmp/rpm-tmp.96363: line 77: clean: command not found

These should be fixed in release 5

> The placement of the post/postun scriptlets at the very end is unusual. Normal
> place is after the %install, why not stick to this?

That's a good idea. I'm not sure how/why they ended up down there

> The package includes not only the upstream source tarball, but also the binary
> distribution tarball scala-2.6.1-final. This contains generated stuff (e. g.,
> jar files) and raises issues whether all source is included according to
> wiki/Packaging/Guidelines. It definitely breaks wiki/PackagingDrafts/Java

It is kind of an akward situation. As far as I can figure that is the only way to get some things 
(documentation, scripts, etc) for a specific release.  Would you recommend to erase the binary 
components of the unpacked binary tarball as part of the prep to make sure that the binary 
components don't end up installed by the RPM?

> Package contains a devel subpackage, makes no sense in a java context and breaks
> wiki/PackagingDrafts/Java. devel contains a configuration file, belongs to
> another (sub) package?

I think that this package is a little different since it is actually a language compiler and runtime not just 
a library.  The devel package contains the configuration to allow using scala from ant and the runtime 
source code (which I'm not sure about packaging, but it is included in a standard scala distribution)

> Discussion: seems that java packages requires a whole lot of copying in
> %install. Is this the right place, would it be better to use ant or make to
> clean up the spec file, to make it look more like a normal make-based spec-file?
> Is there any (other) good example of a packaged java-app out there?

I think the big problem here is that most java applications/libraries do not concern themselves with 
installation and even if they do don't match up with the jpackage conventions.

OK. Some responses

- Yes, I used the "old" version :-(. The new one is OK for svn and pkg-config
- Even though the post/postun scriptlets does not fail if update-mime-database
  is missing, I don't see any reason not to add a dependency for them to ensure
  that installation works as intended.
- I don't really have the competence to give advice on this. But it feels
  strange, is there really stuff in the binaries which is not generated from
  the source? If so, I think the way to go is to strip down this binary to
  a very minimun before it's shipped. This should also clarify the situation
  upstream, where it ought to be handled.
- If this subpackage with a configuration file is needed, maybe it should
  be renamed?
- Good point on installation issues!

Cheers!

--ALec

PS: Perhaps it would be an idea to include a short comment about your license
check w fedora-legal in the spec file? After all, someone else might start to
wonder about this.. DS

(In reply to comment #5)

> > The package includes not only the upstream source tarball, but also the binary
> > distribution tarball scala-2.6.1-final. This contains generated stuff (e. g.,
> > jar files) and raises issues whether all source is included according to
> > wiki/Packaging/Guidelines. It definitely breaks wiki/PackagingDrafts/Java
> 
> It is kind of an akward situation. As far as I can figure that is the only way
to get some things 
> (documentation, scripts, etc) for a specific release.  Would you recommend to
erase the binary 
> components of the unpacked binary tarball as part of the prep to make sure
that the binary 
> components don't end up installed by the RPM?

We surely request to do so.
For example:
http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/xml-commons-which/xml-commons-which.spec

Also, would you explain in detail why SOURCE3 is needed?

> - Even though the post/postun scriptlets does not fail if update-mime-database
>   is missing, I don't see any reason not to add a dependency for them to ensure
>   that installation works as intended.

The section in ScriptletSnippets regarding mimeinfo specifically instruct to not add a requires for 
shared-mime-info because when shared-mime-info is installed it will update the mime database 
itself.

I've also got another update that I hope addresses the concern about the SRPM including the upstream 
binary release.  I included further information about what I am using from the binary distribution and 
modified %prep to only extract those files from the archive.

http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-6.src.rpm

* Sun Jan 13 2008 Geoff Reedy <geoff> - 2.6.1-6
- Include further information about inclusion of binary distribution
- Unpack only those files needed from the binary distribution
- Include note about license approval

>The section in ScriptletSnippets regarding mimeinfo specifically instruct to
not >add a requires [snip]

Indeed. At least I learn a lot in this bug... :-)

For 2.6.1-6:

A. General packaging issues on spec file.

A-1: Description stage:
* Disttag
  - Please consider to use %?_dist tag.
    http://fedoraproject.org/wiki/Packaging/DistTag

? Some questions for Requires
  - For vim-scala, is it sufficient to require only vim-common?
  - For XXX-scala subpackages (like emacs-scala), don' they need
    scala package?

A-2: %prep, %build, %install stage
* Timestamps
  http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps
  - When using "cp" or "install" commands, please add "-p" option
    to keep timestamps.

A-3: %files
* Directory ownership issue
  - There are many directories which are not owned by any
    packages.
--------------------------------------------------------------------
[tasaka1@localhost ~]$ LANG=C rpm -qf /usr/share/scala/lib/scala-compiler.jar 
scala-2.6.1-6
[tasaka1@localhost ~]$ LANG=C rpm -qf /usr/share/scala/lib/
file /usr/share/scala/lib is not owned by any package
--------------------------------------------------------------------
    Please make it sure that all directories which are created
    when installing scala related packages are correctly owned by
    scala related packages.

    Note: When you write
--------------------------------------------------------------------
%files
%{_datadir}/scala/lib/
--------------------------------------------------------------------
    This contains the directory %_datadir/scala/lib itself and all
    files/directories/etc under %_datadir/scala/lib.

* gtksourceview2-scala
  - For what purpose does this subpackage exist? This subpackage
    contains no files.

B. rpmlint
--------------------------------------------------------------------
emacs-scala-el.noarch: W: no-documentation
enscript-scala.noarch: W: wrong-file-end-of-line-encoding
/usr/share/doc/enscript-scala-2.6.1/README
gtksourceview2-scala.noarch: W: no-documentation
scala.noarch: W: symlink-should-be-relative
/usr/share/scala/lib/scala-compiler.jar /usr/share/java/scala/scala-compiler.jar
scala.noarch: W: symlink-should-be-relative
/usr/share/scala/lib/scala-partest.jar /usr/share/java/scala/scala-partest.jar
scala.noarch: W: symlink-should-be-relative /usr/share/scala/lib/scala-dbc.jar
/usr/share/java/scala/scala-dbc.jar
scala.noarch: W: symlink-should-be-relative
/usr/share/scala/lib/scala-library.jar /usr/share/java/scala/scala-library.jar
scala.noarch: W: class-path-in-manifest
/usr/share/java/scala/scala-partest-2.6.1.jar
scala.noarch: W: class-path-in-manifest /usr/share/java/scala/scala-dbc-2.6.1.jar
scala.noarch: W: class-path-in-manifest
/usr/share/java/scala/scala-compiler-2.6.1.jar
scala-devel.noarch: W: no-documentation
scala-devel.noarch: W: conffile-without-noreplace-flag /etc/ant.d/scala
scala-examples.noarch: W: no-documentation
--------------------------------------------------------------------
Summary:
  * wrong-file-end-of-line-encoding
    /usr/share/doc/enscript-scala-2.6.1/README contains Window-type
    end-of-line encoding. Please fix this by "sed -i 's|\r||'" or
    dos2unix.

  * symlink-should-be-relative
    Due to chroot issue and so, we request all symlinks should be relative,
    not absolute.

  * class-path-in-manifest
---------------------------------------------------------------------
[tasaka1@localhost ~]$ rpmlint -I class-path-in-manifest
class-path-in-manifest :
The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path.
These entries do not work with older Java versions and even if they do work,
they are inflexible and usually cause nasty surprises.
---------------------------------------------------------------------
    Well, I am not familiar with Java and I am not sure if you should
    fix this warning....

(In reply to comment #12)
> A-1: Description stage:
> * Disttag
>   - Please consider to use %?_dist tag.
>     http://fedoraproject.org/wiki/Packaging/DistTag

I had not read that page before. Now I understand why the dist tag is useful.  I
will post a new revision with the dist tag.

> ? Some questions for Requires
>   - For vim-scala, is it sufficient to require only vim-common?

I am guessing that you wonder this because vim-common does not provide
/usr/share/vim/vimfiles/{ftdetect,indent,syntax}. I will file a bug against the
vim package because I think vim-common should own these directories. Another
package (vim-vimoutliner) also installs to
/usr/share/vim/vimfiles/{colors,ftdetect,ftplugin,syntax} so until vim-common
provides these directories I request a variance for installing files into these
un-owned directories. 

>   - For XXX-scala subpackages (like emacs-scala), don' they need
>     scala package?

Those packages are mainly addons to various editors to provide syntax
highlighting for scala files. They do not actually call to scala in any way
(with the exception of the emacs mode, but this is an optional feature).  It
seems useful to allow syntax highlighting without having scala installed.

> A-2: %prep, %build, %install stage
> * Timestamps
>   http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps
>   - When using "cp" or "install" commands, please add "-p" option
>     to keep timestamps.

Will address in new revision

> A-3: %files
> * Directory ownership issue
>   - There are many directories which are not owned by any
>     packages.

I think the new revision should fix these

> * gtksourceview2-scala
>   - For what purpose does this subpackage exist? This subpackage
>     contains no files.

I made a silly mistake.  I will fix this in the new revision.

> B. rpmlint

My new package should fix most of these, if not all.

I have also decided not to package the source codes in scala-devel so I will
rename it to ant-scala since all it will be is the classpath file to allow the
use of scala from ant.

I have also read in the packaging guidelines that for this package I need
approval from the Fedora Packaging Committee since scala requires bootstrapping
from a previous tool chain. I will ask about this on fedora-packaging.

http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-7.fc8.src.rpm
http://programmer-monk.net/fedora/packages/scala/scala.spec

* Wed Jan 16 2008 Geoff Reedy <geoff> - 2.6.1-7
- Add dist tag to release
- Fix directory ownership issues in %_datadir/scala
- Remove source code from -devel package
- Rename -devel package to ant-scala
- Fix packaging of gtksourceview2 language spec
- Preserve timestamps when installing and cping
- Add patch to remove Class-Path entries from jar manifests
- Fix line endings in enscript/README

(In reply to comment #14)
> I have also read in the packaging guidelines that for this package I need
> approval from the Fedora Packaging Committee since scala requires bootstrapping
> from a previous tool chain. I will ask about this on fedora-packaging.

Would you write in detail how you want to make bootstrap?

Isn't it possible to make bootstrap by installing first scala
to somewhere (under %builddir, for example) and using the temporarily
installed first scala, for example?

(In reply to comment #16)
> Would you write in detail how you want to make bootstrap?

Bootstrapping is already part of the normal build for scala.  Here is what I
posted on fedora-packaging:

On Wed, Jan 16, 2008 at 07:33:56AM -0500, Tom spot Callaway
<tcallawa> said
> Does the scala package cleanly rebuild from source after it is
> bootstrapped?

Yes. The build procedure for scala uses multiple phases to ensure that
the code cleanly bootstraps.  The sequence is like this:

bootstrap (starr) -> locker -> quick -> strap

The results of the quick phase are packaged.  The results of the strap
phase are compared byte-for-byte with the resuts of the quick phase to
ensure that the compiler is stable.

For more details, see http://tinyurl.com/3e3l55 which is the README of
the source distribution.  It describes in detail the process used to
build scala.  I use this process unaltered when building the RPM.

Then would you try as I wrote as comment 16?

(In reply to comment #18)
> Then would you try as I wrote as comment 16?

I guess I am confused about what you are asking. Do you mean that I should put
it into the spec file as a comment?

The upstream build.xml already builds scala first with the provided bootstrap
compiler. Then that build of scala is used to compile the source code again. 
These are the files that are packaged by the RPM. I believe this meets the
requirement that "all binaries or libraries [...] must have been built from
sourcecode included in the source package"

Sorry there is some confusion as of what I am saying as
"bootstrapping".

(In reply to comment #17)
> Yes. The build procedure for scala uses multiple phases to ensure that
> the code cleanly bootstraps.  The sequence is like this:
> 
> bootstrap (starr) -> locker -> quick -> strap
> 
> The results of the quick phase are packaged.  The results of the strap
> phase are compared byte-for-byte with the resuts of the quick phase to
> ensure that the compiler is stable.

From this comment it seems that finally you have to build
though "strap" stage but you mentioned that you did only by
"quick" stage.
What I am asking is that if you want to build through "quick" stage you
can consider my comment 16.

For the emacs add on components please check against the guidelines here:
http://fedoraproject.org/wiki/Packaging/Emacs

One thing I noticed is that you have hardcoded the required Emacs version, which
is wrong.

Please see:

http://fedoraproject.org/wiki/Packaging/Emacs#head-68d9f611fe0917622dfdfae394c546d81cdf2f22

and the suggested macros here:
http://fedoraproject.org/wiki/Packaging/Emacs#head-71c97638631f2dde59ce69357febb07419dc4673

ping?

(In reply to comment #20)
> From this comment it seems that finally you have to build
> though "strap" stage but you mentioned that you did only by
> "quick" stage.

I actually build all the way through to "strap" since this is what the dist
target of the ant build file does.  "Strap" is built just to be sure that
"quick" can bootstrap itself.  In other words it guarantees that you can replace
the bootstrap environment with "quick" and be able to build scala from scratch.

I will be uploading a new srpm and spec fixing the emacs issues pointed out by
Jonathan in the next couple days.

Took me a bit longer than I was hoping, but here's a new revision:

http://programmer-monk.net/fedora/packages/scala/scala-2.6.1-8.fc8.src.rpm
http://programmer-monk.net/fedora/packages/scala/scala.spec

* Mon Feb 11 2008 Geoff Reedy <geoff> - 2.6.1-8
- Adhere more strongly to the emacs package guidelines
- Include some comments regarding the boot-strapping process

For 2.6.1-8:

* Pre-rebuilt binaries
  - To make it sure that all files to be installed are
    built from free and legally compatible sources,
    remove _all_ pre-rebuilt binaries first at %prep like
-----------------------------------------------------------
%setup -q -a 2 -n %{name}-%{fullversion}
%patch0 -p1 
%patch1 -p1 
%patch2 -p1 
find . -name \*.jar -exec rm {} . \;
find . -name \*.dll -exec rm {} . \;
......
-----------------------------------------------------------

* Legal issue
  - Would you explain how the following files are used to
    build scala rpm?
-----------------------------------------------------------
src/library/scala/collection/immutable/Tree.scala in Source0
-----------------------------------------------------------

* Directory ownership issue
------------------------------------------------------------
/usr/share/vim/vimfiles/ftdetect/scala.vim   vim-scala-2.6.1-8.fc9  file
/usr/share/vim/vimfiles/ftdetect is not owned by any package
/usr/share/vim/vimfiles/indent/scala.vim     vim-scala-2.6.1-8.fc9  file
/usr/share/vim/vimfiles/indent is not owned by any package
/usr/share/vim/vimfiles/syntax/scala.vim     vim-scala-2.6.1-8.fc9  file
/usr/share/vim/vimfiles/syntax is not owned by any package
------------------------------------------------------------
  - IMO for now the 3 directories above should be owned by vim-scala
    (however you may file a bug against vim if you want).

* rpmlint
------------------------------------------------------------
ant-scala.noarch: W: no-documentation
ant-scala.noarch: W: conffile-without-noreplace-flag /etc/ant.d/scala
emacs-scala.noarch: E: percent-in-dependency emacs(bin) %{emacs_version}
emacs-scala-el.noarch: W: no-documentation
emacs-scala-el.noarch: E: percent-in-dependency emacs(bin) %{emacs_version}
scala-examples.noarch: W: no-documentation
------------------------------------------------------------
  Summary:
  * Please check where %emacs_version is defined
------------------------------------------------------------
[tasaka1@localhost scala]$ rpm -q emacs-scala
emacs-scala-2.6.1-8.fc9.noarch
[tasaka1@localhost scala]$ rpm -q --requires emacs-scala
emacs(bin) >= %{emacs_version}
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
------------------------------------------------------------

* Timestamps
  - Please recheck that "-p" option is correctly used when using "cp"
    or "install" commands to install files. For example,
-------------------------------------------------------------
for prog in scaladoc fsc scala scalac; do
        install -m 755 dists/scala-%{version}/bin/$prog $RPM_BUILD_ROOT%{_bindir}
        install -m 644 dists/scala-%{version}/man/man1/$prog.1
$RPM_BUILD_ROOT%{_mandir}/man1
done
-------------------------------------------------------------

* man file
  - Files under %_mandir are automatically marked as %doc.

* License document
  - For example, emacs-scala can be installed without scala itself.
    In this case, no license text of scala is installed, which is
    undesirable.
    i.e. All subpackages which don't require ant either directly or
         indirectly should also have license text as %doc.

ping?

Scala 2.7.0 was just released in the last few days.  I'll be working on packaging up the new version, 
hopefully it won't take too long.

ping again?

ping again?

For the 2.7.0 the scala distribution has been changed such that the
documentation and tool support files are distributed separately, but still
released together. Does it make more sense to split them into separate packages
or to still have that all built from the main scala package? If I were to split
them into multiple packages, would I open new bugs for those packages with a
dependency on this one?

(In reply to comment #30)
> For the 2.7.0 the scala distribution has been changed such that the
> documentation and tool support files are distributed separately, but still
> released together.

> Does it make more sense to split them into separate packages
> or to still have that all built from the main scala package? 

Spliting them into seperate srpms is preferred.

> If I were to split
> them into multiple packages, would I open new bugs for those packages with a
> dependency on this one?

Yes, please.

Okay, a new SRPM for scala 2.7.0. It no longer contains the reference documentation and tool support 
as those are being split into new source packages.

http://programmer-monk.net/fedora/packages/scala/scala.spec
http://programmer-monk.net/fedora/packages/scala/scala-2.7.0-1.fc8.src.rpm

Regarding issues raised above

(In reply to comment #25)
> For 2.6.1-8:
> 
> * Pre-rebuilt binaries
>   - To make it sure that all files to be installed are
>     built from free and legally compatible sources,
>     remove _all_ pre-rebuilt binaries first at %prep like

I cannot do this because I need the bootstrap environment

> * Legal issue
>   - Would you explain how the following files are used to
>     build scala rpm?
> -----------------------------------------------------------
> src/library/scala/collection/immutable/Tree.scala in Source0
> -----------------------------------------------------------

I have changed the license tag to BSD and LGPLv2+, is that okay? I will also ask upstream about what 
the intent is there.

> * Timestamps
>   - Please recheck that "-p" option is correctly used when using "cp"
>     or "install" commands to install files. For example,

fixed

> * man file
>   - Files under %_mandir are automatically marked as %doc.

fixed

> * License document
>   - For example, emacs-scala can be installed without scala itself.
>     In this case, no license text of scala is installed, which is
>     undesirable.
>     i.e. All subpackages which don't require ant either directly or
>          indirectly should also have license text as %doc.

fixed

(In reply to comment #32)
> (In reply to comment #25)
> > For 2.6.1-8:
> > 
> > * Pre-rebuilt binaries
> >   - To make it sure that all files to be installed are
> >     built from free and legally compatible sources,
> >     remove _all_ pre-rebuilt binaries first at %prep like
> 
> I cannot do this because I need the bootstrap environment

Sorry but this is a blocker: the section
"Pre-built JAR files / Other bundled software" of
http://fedoraproject.org/wiki/Packaging/Java .

If you really need pre-built binaries, please ask fedora-packaging
mailing list:
http://www.redhat.com/mailman/listinfo/fedora-packaging

For now we cannot approve this situation.

I have already asked on fedora-packaging about approval for the bootstrap environment. Here is the thread root: https://www.redhat.com/archives/fedora-packaging/2008-January/msg00074.html

It didn't really go anywhere though, maybe I just need to ask again. I did get the feeling that it'd be easier if the review were completed except for the pre-built binary issue.

I will ask spot. Spot, would you look at this srpm?

Before spot comments on this:

Build itself failed (check root.log)
http://koji.fedoraproject.org/koji/taskinfo?taskID=586180

* Fri May 02 2008 Geoff Reedy <geoff> - 2.7.0-2
- Use java-sdk-openjdk for non-fc8 builds

http://programmer-monk.net/fedora/packages/scala/scala.spec
http://programmer-monk.net/fedora/packages/scala/scala-2.7.0-2.fc8.src.rpm

This builds in mock now for devel-i386

Also, see
http://www.nabble.com/-scala--licensing-of-scala-collection-immutable-Tree.scala-td16932952.html
for the discussion of the licensing issue. Upstream has contacted the original
author and got the code relicensed under the Scala license. 

Does this mean I can revert the license tag immediately or do I have to wait for
the next release with the LGPL notice removed?

Bootstrapping using prebuilt binaries is ok for the first pass, but only the
first pass.

Go ahead and change the license tag, the intent is clear from upstream. You may
want to leave a comment in there explaining the issue and linking to that URL
until they do a new release.

Lifting FE-Legal.

Well, for 2.7.0-2:

* Java packaging guidelines
  - First of all, would you modify your spec file accoring to
    (recently approved) Java guidelines?
    http://fedoraproject.org/wiki/Packaging/Java

    * Fix Requires, BuildRequires
      - java-sdk-{icedtea,openjdk} has virtual Provides: java
      - jpackage-utils must be in BuildRequires
      - Also you may want to specify version

* JAVA_HOME
----------------------------------------------------
export JAVA_HOME=%{_jvmdir}/java-%{java_sdk}
----------------------------------------------------
  - My system does not have %{_jvmdir}/java-%{java_sdk}.
    Also the following %ant sets JAVA_HOME to %java_home
    (/usr/lib/jvm/java). So perhaps this line is not
    needed.

Then as this is NEEDSPONSOR ticket:
-------------------------------------------------------------
NOTE: Before being sponsored:

This package will be accepted with another few work. 
But before I accept this package, someone (I am a candidate) 
must sponsor you.

Once you are sponsored, you have the right to review other 
submitters' review requests and approve the packages formally. 
For this reason, the person who want to be sponsored (like you) 
are required to "show that you have an understanding 
of the process and of the packaging guidelines" as is described
on :
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

Usually there are two ways to show this.
A. submit other review requests with enough quality.
B. Do a "pre-review" of other person's review request
   (at the time you are not sponsored, you cannot do
   a formal review)

When you have submitted a new review request or have pre-reviewed other 
person's review request, please write the bug number on this bug report 
so that I can check your comments or review request.

Fedora package collection review requests which are waiting for someone to
review can be checked on:
http://fedoraproject.org/PackageReviewStatus/NEW.html
(NOTE: please don't choose "Merge Review")


Review guidelines are described mainly on:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
------------------------------------------------------------

ping?

I'm working on updating the package to version 2.7.1 and going through the java packaging guidelines. 
I'm also backporting a patch that re-implements the .NET code generator in scala so I don't have to patch 
out the support for it to keep everything closer to upstream.

ping again?

ping again?

ping again?

Between vacation, my day job and some strange problems where the jar files, when
extracted in brp-repack-jars have no permission bits set; I haven't gotten the
2.7.1 package completed yet. I'm hoping to get back on it this week.

ping?

2.7.2 will be coming very soon. Geoff if you're too tied up to continue this perhaps I could pick it up?

For confirmation:

What I am waiting from Geoff is what I wrote on the comment 40.
i.e. you must submit another review request or do a pre-review of other person's
     review request as well as updating scala srpm.

(In reply to comment #49)
> For confirmation:
> 
> What I am waiting from Geoff is what I wrote on the comment 40.
> i.e. you must submit another review request or do a pre-review of other
> person's
>      review request as well as updating scala srpm.

Understood ... if Geoff is tied up I could update the spec file to 2.7.2 and incorporate your comments from #40.

I've finally found why files extracted from the jars in brp-repack-jars had no permission bits set so I now have a package that actually builds. I hope to get the new revision up tonight once I get home from work.

Miles, perhaps we could become co-maintainers for the scala package? It'd be really good to have a couple people on it since this package turns out to be very complicated.

I'll probably also pull down off the 2.7.2 branch and start building a package for that. If you want to give it a shot too, start with removing the patches backporting the scala implementation of the msil library. Hopefully it will just work (TM) from there.

(In reply to comment #51)
> Miles, perhaps we could become co-maintainers for the scala package? It'd be
> really good to have a couple people on it since this package turns out to be
> very complicated.

Yes, I think that would be a good plan.

Ok, here we go:

http://www.programmer-monk.net/fedora/packages/scala/scala.spec
http://www.programmer-monk.net/fedora/packages/scala/scala-2.7.1-2.srpm

I just also noticed that I forgot to set the release back down to -1 so there's no entry in the changelog for -2.

Again I leave a note that as written in comment 40 I am still waiting
for _another_ review request or a _pre-review_ of a review request by other person
from Geoff.

(In reply to comment #54)
> Again I leave a note that as written in comment 40 I am still waiting
> for _another_ review request or a _pre-review_ of a review request by other
> person from Geoff.

Does it help if I "officially" become a prospective co-maintainer of this package? I'm upstream for Scala (I work full-time on the Scala Eclipse plugin, and I have commit rights for the Scala compiler, libraries and tools source trees, write access to the web-site, wiki etc.). At some point I expect to sumbit a review request of a packaging of the Scala Eclipse plugin.

In the very near future I will be submitting review requests for a number of Haskell packages.

(In reply to comment #55)
> (In reply to comment #54)
> > Again I leave a note that as written in comment 40 I am still waiting
> > for _another_ review request or a _pre-review_ of a review request by other
> > person from Geoff.
> 
> Does it help if I "officially" become a prospective co-maintainer of this
> package? 

No. I am waiting from Geoff as this is requested for a new contributor
to be sponsored. Of course co-maintaining is always welcome :) (however
if you want to co-maintain this package you also have to get sponsored beforehand)

By the way:

Rebuild failed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=777548

Note:
Now on rawhide patches are applied with --fuzz=0 by default and build.log says
applying a patch fails with this option. So:
- Please re-generate the patch in issue so that it can be applied with --fuzz=0
- or add "%define _default_patch_fuzz 2" if you want to use the default fuzz by
  patch.

Ref:
https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00477.html

I have made some pre-reviews on #446097 and #428549

I'll re-generate the patch and re-upload tonight.

Well:

* bug 428549 is already closed, so I cannot verify if your pre-review is
  proper

* bug 446097 is open, however based on my criterion your pre-review is not
  satisfactory. Would you re-prereview bug 446097 ?
  General packaging guidelines are written on:
  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
  http://fedoraproject.org/wiki/Packaging/Guidelines
  http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

  Some points for pre-review of bug 446097:
  - Please check the item "MUST: In the vast majority of cases...." of ReviewGuidelines
    wiki. This is usually also applied to any subpackages.
  - Please check the %files list. Are there any duplicate files (between subpackages)?
  - Also check the "ScriptletSnippets" wiki. Some files are under %_datadir/icons/hicolor/.

As koji is up again I will wait for your new srpm.

2.7.2 RC1 is now out, here's the stuff:

http://www.programmer-monk.net/fedora/packages/scala/scala.spec
http://www.programmer-monk.net/fedora/packages/scala/scala-2.7.2-0.1.RC1.fc10.src.rpm

Well, for 2.7.2-0.1.RC1:

* License
------------------------------------------
# Except src/scala/collection/immutable/Tree.scala which is LGPLv2+
------------------------------------------
  - This file is moved to src/library/scala/collection/immutable/Tree.scala,
    which says:
------------------------------------------
** NOTE: This code was until 2007-04-01 under a GPL license. The author has
** given permission to remove that license, so that now this code is under
** the general license for the Scala libraries. 
------------------------------------------
    So now the whole codes are under BSD.

* Binaries
  - In Source0:
------------------------------------------
./docs/examples/plugintemplate/lib/scalatest.jar: Zip archive data, at least v1.0 to extract
./lib/ant/ant-contrib.jar:                        Zip archive data, at least v1.0 to extract
./lib/ant/ant-dotnet-1.0.jar:                     Zip archive data, at least v1.0 to extract
./lib/ant/vizant.jar:                             Zip archive data, at least v1.0 to extract
./lib/cldcapi10.jar:                              Zip archive data, at least v2.0 to extract
./lib/fjbg.jar:                                   Zip archive data, at least v1.0 to extract
./lib/jline.jar:                                  Zip archive data, at least v1.0 to extract
./lib/midpapi10.jar:                              Zip archive data, at least v1.0 to extract
./lib/mscorlib.dll:                               PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assem
bly
./lib/msil.jar:                                   Zip archive data, at least v2.0 to extract
./lib/scala-compiler.jar:                         Zip archive data, at least v1.0 to extract
./lib/scala-library-src.jar:                      Zip archive data, at least v1.0 to extract
./lib/scala-library.jar:                          Zip archive data, at least v1.0 to extract
./lib/scalaruntime.dll:                           PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assem
bly
./test/diff/diff.exe:                             PE32 executable for MS Windows (console) Intel 80386
./test/diff/libiconv2.dll:                        PE32 executable for MS Windows (DLL) (console) Intel 80386
./test/diff/libintl3.dll:                         PE32 executable for MS Windows (DLL) (console) Intel 80386
./test/files/jvm/libnatives-32.so:                ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, 
not stripped
./test/files/jvm/libnatives-64.so:                ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not s
tripped
./test/files/jvm/libnatives.jnilib:               Mach-O dynamically linked shared library i386
./test/files/jvm/natives-32.dll:                  PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
./test/files/lib/annotations.jar:                 Zip archive data, at least v1.0 to extract
./test/files/lib/methvsfield.jar:                 Zip archive data, at least v1.0 to extract
./test/files/lib/nest.jar:                        Zip archive data, at least v2.0 to extract
------------------------------------------
    Among above, jar files are now correctly treated. Would you remove the else
    at %prep?

! BuildRequires
  - Current Java packaging guidelines says that all Java package must have
    "BuildRequires: java-devel, jpackage-utils".
    Although this is redundant as ant Requires both, would you add these
    BuildRequires?

* -apidoc subpackage
  - Current Java packaging guidelines
    https://fedoraproject.org/wiki/Packaging/Java
    says that 
    * apidocs subpackage must be named as "-javadoc".
    * All apidocs must be placed under %{_javadocdir}.

* %defattr
  - %defattr is not set on ant-scala subpackage.

(In reply to comment #62)
> * -apidoc subpackage
>   - Current Java packaging guidelines
>     https://fedoraproject.org/wiki/Packaging/Java
>     says that 
>     * apidocs subpackage must be named as "-javadoc".
>     * All apidocs must be placed under %{_javadocdir}.

Scala isn't Java, and even thought scaladoc has some similarities with javadoc they aren't the same, so naming the subpackage -javadoc wouldn't be appropriate.

(In reply to comment #63)
> Scala isn't Java, and even thought scaladoc has some similarities with javadoc
> they aren't the same, so naming the subpackage -javadoc wouldn't be
> appropriate.

Okay, then I wait for the rest issues to be fixed.

* Sat Sep 06 2008 Geoff Reedy <geoff> - 2.7.2-0.2.RC1
- All code is now under BSD license
- Remove dll so and exe binaries in prep
- Add BuildRequires required by Java packaging guidelines
- Add missing defattr for examples and ant-scala

http://www.programmer-monk.net/fedora/packages/scala/scala.spec
http://www.programmer-monk.net/fedora/packages/scala/scala-2.7.2-0.2.RC1.fc10.src.rpm

Okay.

- This package itself is now okay
- Your pre-review is now much better
-------------------------------------------------------------------------
      This package (scala) is APPROVED by mtasaka
-------------------------------------------------------------------------

Please follow the procedure written on:
http://fedoraproject.org/wiki/PackageMaintainers/Join

Now I can see that you have already requested for sponsorship on
FAS (Fedora Account System), however the mail address on FAS does not
coincide with your bugzilla mail address. Please fix 
your FAS email address. Then I will sponsor you.


If you want to import this package into Fedora 8/9, you also have
to look at
http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT
(after once you rebuilt this package on koji Fedora rebuilding system).

If you have questions, please ask me.

I've updated my bugzilla email address to be the same as the one in FAS. The next step will be to make the CVS request, correct?

Okay, now I am sponsoring you. Please follow "Join" wiki again.

(In reply to comment #67)
> The
> next step will be to make the CVS request, correct?
Yes, however please make it sure that you did the previous procedure (like setting
up koji client tools)

ping?

Too much house-work keeping me busy. Now I finally have some time.

New Package CVS Request
=======================
Package Name: scala
Short Description:Hybrid functional/object-oriented language
Owners: geoff
Branches: F-9
InitialCC:

cvs done

To Huzaifa:

Thank you for CVS procedure.
By the way it seems that every time you write in each review request "cvs done",
you add yourself to the CC members of the review request.
Perhaps you want to see bug 457664?

Mamoru

ping?

ping again?

ping again??

scala-2.7.2-0.2.RC1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/scala-2.7.2-0.2.RC1.fc9

Thank you.

When you think the packages submitted on bodhi can be moved
from testing to stable repository, please modify the submitted
request on bodhi.

Now closing.

Hoorray! I am very pleased to see this finally come through.

I am still unable to actually see it my package list. Do you think a mirror would take this long to pick up the update?

This was the command I used:
yum --enablerepo=updates-testing-newkey list scala*

PS. I tried posting on the admin.fedoraproject.org page, but it gives me an internal error of some kind, hence posting here.

(In reply to comment #78)
> I am still unable to actually see it my package list. Do you think a mirror
> would take this long to pick up the update?

This package has not been pushed to testing repository, now waiting
for signing by rel-eng team. You can check the current status on:
https://admin.fedoraproject.org/updates/scala-2.7.2-0.2.RC1.fc9

scala-2.7.2-0.3.RC6.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/scala-2.7.2-0.3.RC6.fc9

One small complaint about the 2.7.2-0.2.RC1 package:
The jline package isn't added to the classpath defacto.

But when I download and install scala distribution from scala-lang.org, jline is bundled alongwith it, and is available in the class path.

If this has been fixed in the RC6 package, please ignore this.

scala-2.7.2-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/scala-2.7.2-1.fc9

scala-2.7.2-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Package Change Request
======================
Package Name: scala
New Branches: epel7
Owners: mcpierce

Any comments from the Fedora maintainers?

(In reply to Jon Ciesla from comment #85)
> Any comments from the Fedora maintainers?

Will Benton is restarting the non-responsive maintainer process to take over package maintenance. From what I understand, they've been MIA for a few years now.

Package Change Request
======================
Package Name: scala
New Branches: epel7
Owners: willb mcpierce

Here's the FESCo ticket related to this:  https://fedorahosted.org/fesco/ticket/1343

Git done (by process-git-requests).

Package Change Request
======================
Package Name: scala
New Branches: master f20 f21 f19 epel7
Owners: willb mcpierce

Sorry, Jon, I meant for this to be an ownership change of the package as well as creating the EPEL branch for Darryl, but it looks like I didn't get the request syntax right.  Here's the FESCo ticket related to this:  https://fedorahosted.org/fesco/ticket/1343

Got it.  Changed as requested.