Hide Forgot
Spec URL: http://www.programmer-monk.net/fedora/packages/scala/scala.spec SRPM URL: http://www.programmer-monk.net/fedora/packages/scala/scala-2.6.1-3.srpm Description: Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java. This is my first package so I'm looking for a sponsor.
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.
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?
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 ------------------------------------------------------------
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.
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.
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)
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 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.