Spec URL: http://www.bde.espci.fr/~george27/ImageJ.spec SRPM URL: http://www.bde.espci.fr/~george27/ImageJ-1.43-0.1.fc12.src.rpm Description: Image Processing and Analysis in Java It can display, edit, analyze, process, save and print many image formats. It supports "stacks", a series of images that share a single window. It can calculate area and pixel value statistics of user-defined selections. It can measure distances and angles. It can create density histograms and line profile plots. It supports standard image processing functions such as contrast manipulation, sharpening, smoothing, edge detection and median filtering. ImageJ was designed with an open architecture that provides extensibility via Java plugins.
Quick comments: *Group is not really that great. I would recommend Applications/Engineering over Amusements/Graphics, but I am open to debate. Neither fit, but amusements is more for games and "toy" applications. ImageJ is targeted towards scientific applciations *Why do you include a build for x86-64 as Source2? It would be better to provide a repack script if you only need a few files. remember that ij142-linux64 includes its own vm -- which is really unneccesary as it is massive and we already have one. It might possibly even be against fedora guidelines, depending on what gets bundled in the VM (not all of the sun code is free), don't quote me on that though. *Description is a bit short, the one you have included above is better. Or maybe something like below or something else. Just try to distinguish it from say, gimp or inkscape, which are targeted towards artistic, rather than scientific analysis: ImageJ is a public domain Java image processing program. It can display, edit, analyze a wide variety of image data, including image sequences. Imagej can be used for quantitative analysis of engineering and scientific image data. *Patch names are not descriptive. Please include a comment above the patches to say what they do. You may wish to send the script patch upstream. If you do, please make a note in the spec. *Version tag is a bit wrong, as it does not say which exactly upstream version of ImageJ you are using (a, b,c,d, ...) . You may need to follow the guidelines at http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release
Spec URL: http://www.bde.espci.fr/~george27/ImageJ.spec SRPM URL: http://www.bde.espci.fr/~george27/ImageJ-1.43-0.2.j.fc12.src.rpm Thanks for these comments 1) I agree, I wasn't very happy with "Amusement/Graphics". (This is not a funny tool ^^) But I didn't know the best group. Your choice seems correct. 2) This source is only for the launch script and some macros not included in the source package but quite useful. I don't use anything else (not the jre nor the .jar file) in the final package. But yes, I don't think about this, maybe include them in the src.rpm is against fedora guidelines I will try to get them from an other way. 3) Yes I forgot to change the description for the one above. But your description looks better (more concise) 4) I added some comments 5) Changed.
new package about comment #2 : Spec URL: http://www.bde.espci.fr/~george27/ImageJ.spec SRPM URL: http://www.bde.espci.fr/~george27/ImageJ-1.43-0.3.j.fc12.src.rpm I searched in the website and found : Source2: http://rsbweb.nih.gov/ij/macros/macros.zip Source3: http://rsb.info.nih.gov/ij/download/linux/unix-script.txt The files packages need. It's better to get them directly. All seems to work except the "Compile and Run" in the menu "Plugins". I don't know how to fix it.
>All seems to work except the "Compile and Run" in the menu "Plugins". I don't know how to fix it. This is important and needs to work "out of the box". ImageJ is on debians package tracker, and I believe they get around this by setting JAVA_HOME appropriately in their imagej script. you may want to check the contents of http://ftp.de.debian.org/debian/pool/main/i/imagej/imagej_1.43g-1.diff.gz for the script. Actually their changes to the script are extensive, and probably worth a quick diff. More comments: * Currently the build is dumping files into ~/rpmbuild/BUILD/ for me which is causing problems. Please fix the uncompress. I think upstream are a bit odd with how they make their release archives.
Spec URL: http://www.bde.espci.fr/~george27/imagej.spec SRPM URL: http://www.bde.espci.fr/~george27/imagej-1.43-0.4.j.fc12.src.rpm thanks for the links, it works now :) I correct the problem of files in ~/rpmbuild/BUILD/ and of some permissions too. The output on rpmlint is now : imagej-javadoc.noarch: W: non-standard-group Development Documentation 3 packages and 0 specfiles checked; 0 errors, 1 warnings. The group for javadoc was found in an example in the packaging guidelines for java : https://fedoraproject.org/wiki/Packaging/Java so it is correct or no ? I change the name from ImageJ to imagej, because upstream use both, and the program create a ${HOME}/.imagej directory, so I think it is more coherent .
Argh. I wrote all of this, then firefox crashed as I was about to submit it. Anyway here is the condensed version * Please modify setup to use the -c parameter, creating a folder %{name}-%{version}. creating a dir called "source" in BUILD is not desirable. See http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html * I concur that plugins work, isntalled in user dir and in imagej/plugins which is great. * I don't think you need all the rm -fs at the start # erase binary and useless files rm -rf .FBC* rm -rf macros/.FBC* rm macros/build.xml rm -f .gdb_history rm -rf __MACOSX * To make maintenance a bit easier, this can (at your option) be changed from: chmod 755 macros chmod 644 macros/About\ Startup\ Macros chmod 644 macros/*.txt chmod 644 macros/data/*.txt chmod 644 macros/tools/*.txt chmod 755 macros/data chmod 755 macros/tools to: find ./macros -name \*.txt -type f -exec chmod 644 {} \; find ./macros -type d -exec chmod 755 {} \; I'll do a full review on the next version.
Spec URL: http://www.bde.espci.fr/~george27/imagej.spec SRPM URL: http://www.bde.espci.fr/~george27/imagej-1.43-0.5.j.fc12.src.rpm ---- 1) is modified 2) yes, but in the previous version the wrapper script was not correct, dependencies too ... For compiling plugins, you need java-devel. But rpmlint raises an error [builder@cafeline result]$ rpmlint *.rpm imagej.noarch: E: devel-dependency java-devel imagej-javadoc.noarch: W: non-standard-group Development Documentation 3 packages and 0 specfiles checked; 1 errors, 1 warnings. 3) I kept removing files in macros directory for not copy them 4) You are right, it is better (and shorter) than my solution I don't change the version to 1.43-1 because the rpmlint error.
> For compiling plugins, you need java-devel. But rpmlint > raises an error I think we can ignore RPMlint on this one. This is required for application functionality. > I kept removing files in macros directory for not copy them OK ==== Review: x - OK ! - Needs attention ? - Query N - Not applicable [x] MUST: rpmlint must be run on every package. The output should be posted in the review. $ rpmlint imagej-1.43-0.5.j.fc12.src.rpm ../RPMS/noarch/imagej-1.43-0.5.j.fc12.noarch.rpm ../RPMS/noarch/imagej-1.43-0.5.j.fc12.noarch.rpm imagej imagej-javadoc imagej.noarch: E: devel-dependency java-devel imagej.noarch: E: devel-dependency java-devel imagej.noarch: E: devel-dependency java-devel imagej-javadoc.noarch: W: non-standard-group Development Documentation 5 packages and 0 specfiles checked; 3 errors, 1 warnings. I am not concerned about the E, and the W I believe to be behind the times. [x] MUST: The package must be named according to the Package Naming Guidelines . [x] MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [x] MUST: The package must meet the Packaging Guidelines . [x] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . [x] MUST: The License field in the package spec file must match the actual license. [x] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. [x] MUST: The spec file must be written in American English. [x] MUST: The spec file for the package MUST be legible. [x] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. $ for i in `cat imagej.spec | grep Source | grep http | awk '{ print $2} '` ; do wget $i; done; .... $ md5sum unix-script.txt ij143j-src.zip macros.zip 71d3aea1cbadf88cef04948411881b6c unix-script.txt 66fec8e25e46de0dce86ffea0e738b1f ij143j-src.zip 8161ec95aa84e9fa3e46e68a00fada4d macros.zip $ md5sum ../SOURCES/unix-script.txt ../SOURCES/ij143j-src.zip ../SOURCES/macros.zip 71d3aea1cbadf88cef04948411881b6c ../SOURCES/unix-script.txt 66fec8e25e46de0dce86ffea0e738b1f ../SOURCES/ij143j-src.zip 8161ec95aa84e9fa3e46e68a00fada4d ../SOURCES/macros.zip OK [x] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. I was able to build it locally, and builds in Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1822281 [N] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [x] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. [N] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. [N] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [x] MUST: Packages must NOT bundle copies of system libraries. [N] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [x] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [x] MUST: A Fedora package must not list a file more than once in the spec file's %files listings. [x] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [x] MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [x] MUST: Each package must consistently use macros. [x] MUST: The package must contain code, or permissable content. [x] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [x] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [N] MUST: Header files must be in a -devel package. [N] MUST: Static libraries must be in a -static package. [N] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [N] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [N] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [x] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. [x] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [x] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [x] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [x] MUST: All filenames in rpm packages must be valid UTF-8. [!] SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. Please contact upstream to include a file somewhere about this. [N] SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. [x] SHOULD: The reviewer should test that the package builds in mock. [x] SHOULD: The package should compile and build into binary rpms on all supported architectures. F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1822281 F12: http://koji.fedoraproject.org/koji/taskinfo?taskID=1822296 [x] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. [N] SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. [x] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. [N] SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. [N] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. So in summary, please contact upstream and tell them to include a LICENCE.txt or similar in the zip file. This package is APPROVED
Thanks for the review, I contacted upstream, he did not answer yet.
Hello, Just to be clear, this package is approved and you can place a CVS request.
New Package CVS Request ======================= Package Name: imagej Short Description: Image Processing and Analysis in Java Owners: manawy Branches: F-11 F-12 InitialCC: sorry for the waiting time, some problems, I prefer wait before starting the cvs process. Anyway, I have updated version to imagej-1.43-1.m. The bug we had when we tried to close an image not saved is corrected. But I have still no answer from upstream. I will try again.
just to be clear, I meant "I preferRED wait before starting the cvs process". Now it is OK. I apologize for all my grammatical errors.
cvs done.
Did this ever get uploaded??
This package has been upload one year ago (It seems I forget to tell bodhi the id of review request so the message "... has been submitted" doesn't appear here :/) Sorry for delay, the first time I read "update", so I start to build new version. They are available for f14 (https://admin.fedoraproject.org/updates/imagej-1.44-1.i.fc14?_csrf_token=ea7ebf493b551beeaaa0eb03223eb14cb6da213d) and f15.
Hello Fabien, thanks for your effort in making ImageJ available in Fedora! I mostly use Fiji (http://pacific.mpi-cbg.de/wiki/index.php/Fiji) because it is a clone of ImageJ with a lot of plugins preinstalled. Is it possible to package Imagej with some of the plugins that Fiji has? Of course, directly packaging Fiji, would be a real plus! :) Thanks and regards, Mario
Hello I didn't know this but it looks great. I don't think it's a good idea to package fiji's plugins with Imagej. Better is to create a fiji-plugins package which install all plugins in the imagej directories For packaging Fiji, ...I don't think so. It seem's more relevant working with the original software, more consistent with fedora's policy, especially if it's just plugins. But maybe I'am wrong. Another big problem is licenses : https://github.com/dscho/fiji/blob/master/LICENSES some of plugins can't be freely redistributed ( Another reason, is that I don't have enough time to take care of this new package. And, above all, I don't use ImageJ anymore. So if someone want to maintain or co-maintain it, he will be welcome )
I like the idea of a separate "imagej-plugins" package which installs them. I use imagej/fiji on a daily basis, I can help comantaining, if you wish.