One file is licensed as GPLv3+. Please ask upstream and also inform them of the wrong address, though that is not a blocker.

"FreeMat is available under the GPL license." -- That part of the description is useless.

Drop all the "-v"s. rpmbuild shows everything by default. Add -f to your last rm.

The description text sounds a lot like in this example: http://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description

Please do as rpmlint says and correct the line ends with something like:

http://fedoraproject.org/wiki/Common_Rpmlint_issues#wrong-file-end-of-line-encoding

rpmlint -I can help, if you don't understand what an error is about.

Also mend that:

freemat.i686: W: devel-file-in-non-devel-package
/usr/share/FreeMat-4.1/toolbox/test/addArrays.c

Either define a Buildroot tag, if you want to put this package to EPEL 5, or drop: rm -rf $RPM_BUILD_ROOT

The defattr line is unneeded.

Can you probably generate the current documentation?

Really delete the bundled libs. Currently there is a pound sign in front of it.

CMake informs about:

-- Could NOT find Boost
Compiler optimization may lead to broken Lapack build. 
If release build produces incorrect results (e.g. svd(rand(4)) is all NaN) 
you should to disable optimization when compiling dlamch.c and slamch.c

Did you make sure that's fine?

(In reply to comment #1)
> One file is licensed as GPLv3+. Please ask upstream and also inform them of the
> wrong address, though that is not a blocker.

Emailed upstream. What file is this please? I can't find it. :/

> 
> "FreeMat is available under the GPL license." -- That part of the description
> is useless.

dropped.

> 
> Drop all the "-v"s. rpmbuild shows everything by default. Add -f to your last
> rm.

mock will show the command, but not verbose execution of rm.

> 
> The description text sounds a lot like in this example:
> http://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description
> 

removed concerned portion

> Please do as rpmlint says and correct the line ends with something like:
> 
> http://fedoraproject.org/wiki/Common_Rpmlint_issues#wrong-file-end-of-line-encoding
> 
> rpmlint -I can help, if you don't understand what an error is about.
> 

corrected. 

> Also mend that:
> 
> freemat.i686: W: devel-file-in-non-devel-package
> /usr/share/FreeMat-4.1/toolbox/test/addArrays.c

It's a test file for users that the package installs. I think we can let it be. 

> 
> Either define a Buildroot tag, if you want to put this package to EPEL 5, or
> drop: rm -rf $RPM_BUILD_ROOT

dropped

> 
> The defattr line is unneeded.

dropped

> 
> Can you probably generate the current documentation?

I've tried, but been unable to. I've informed upstream of this. Whenever they generate the new doc, I'll push a new build.

> 
> Really delete the bundled libs. Currently there is a pound sign in front of it.

deleted

> 
> CMake informs about:
> 
> -- Could NOT find Boost

It isn't causing the build to fail, so I guess it's okay. I will clarify with upstream though.

> Compiler optimization may lead to broken Lapack build. 
> If release build produces incorrect results (e.g. svd(rand(4)) is all NaN) 
> you should to disable optimization when compiling dlamch.c and slamch.c
> 
> Did you make sure that's fine?

I'm using the fedora lapack package so this is irrelevant IMO. 

rpmlint output:
[ankur@ankur SRPMS]$ rpmlint /var/lib/mock/fedora-rawhide-i386/result/*.rpm
freemat.i686: W: devel-file-in-non-devel-package /usr/share/FreeMat-4.1/toolbox/test/addArrays.c
freemat.i686: E: incorrect-fsf-address /usr/share/FreeMat-4.1/toolbox/general/license.m
freemat.i686: E: incorrect-fsf-address /usr/share/doc/freemat-20110620/COPYING
freemat.i686: W: no-manual-page-for-binary FreeMat
freemat.src: W: invalid-url Source0: freemat.tar.gz
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/HandleList.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/DebugStream.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/main.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/application.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/SymbolTable.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libGraphics/HandleFigure.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/FuncTerminal.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/HistoryWidget.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/Terminal.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Token.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libGraphics/RenderEngine.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Exception.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/DataTable.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/NTuple.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/DumbTerminal.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Array.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Stream.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/QTTerm.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/FunctionDef.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/StackTool.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/FuncMode.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/Terminal.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/FileTool.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Scope.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/DebugWin.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/FMFontDialog.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Vector.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/MainApp.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/FuncTerminal.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/MainApp.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/FastList.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/application.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/FuncMode.cpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/ArrayPrivate.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/BasicArray.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libGraphics/HandleWindow.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Context.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Interpreter.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/KeyManager.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/Editor.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libFreeMat/Types.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libGraphics/HandleCommands.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libGraphics/HandleProperty.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/libs/libXP/VariablesTool.hpp
freemat-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/freemat/FreeMat/src/DumbTerminal.hpp
3 packages and 0 specfiles checked; 47 errors, 3 warnings.


The new package is uploading. I'll provide the srpm in a few minutes.

Regards,
Ankur

$ licensecheck -R *|grep v3

freemat/FreeMat/tools/vtkwrap/vtkParse.tab.c: GPL (v3 or later)

But you can forget about it: https://bugzilla.redhat.com/show_bug.cgi?id=668794

http://ankursinha.fedorapeople.org/freemat/freemat-20110620-0.2svn4185.fc15.src.rpm

http://ankursinha.fedorapeople.org/freemat/freemat.spec

You missed a period between your release number and "svn...".

"svn export https://freemat.svn.sourceforge.net/svnroot/freemat/trunk" is not the proper command to prepare for producing exactly the same tarball.

In my opinion, the list of BRs is pretty confusing, as it has no specific order and has multiple BRs per line. That might contibute to having zlib-devel in there twice ;)

You don't have to BR boost, if you specify boost-devel. The devel package always requires the main package.

Maybe one "and" in the description should be removed.

Why are you packaging it as a snapshot anyway? There seemingly was a 4.0 release. Is there a specific reason to ship the latest snapshot? This also leads to questioning the name of the PDF you install, as I couldn't see a 4.1 release on the website, taking a quick look.

I think you should really split the package, as there is loads of documentation and non-binary data.

Better mention the comment number as well, if you use a reference to a ticket in the changelog. But actually, this is not extremly helpful. Rather be explicit there!

Hi!

[ankur@ankur SRPMS]$ rpmlint ../SPECS/freemat.spec freemat-20110620-0.3.svn4185.fc15.src.rpm /var/lib/mock/fedora-rawhide-i386/result/*.rpm | sed '/incorrect-fsf-address/d'
../SPECS/freemat.spec: W: invalid-url Source0: freemat.tar.gz
freemat.src: W: invalid-url Source0: freemat.tar.gz
freemat.i686: W: no-manual-page-for-binary FreeMat
freemat.src: W: invalid-url Source0: freemat.tar.gz
freemat-data.i686: W: no-documentation
freemat-data.i686: W: devel-file-in-non-devel-package /usr/share/FreeMat-4.1/toolbox/test/addArrays.c
6 packages and 1 specfiles checked; 47 errors, 6 warnings.


4.1 has also been released iirc. Googling for the version brings up quite a few packages. 

http://ankursinha.fedorapeople.org/freemat/freemat-20110620-0.3.svn4185.fc15.src.rpm

http://ankursinha.fedorapeople.org/freemat/freemat.spec

* Mon Jul 11 2011 Ankur Sinha <ankursinha AT fedoraproject DOT org> - 20110620-0.3.svn4185
- fix up BRs
- fix up description 
- fix versioning
- split the package


Thanks!
Ankur

I have a few comments as well.

1. The boost build dep isn't doing anything in its current form.  FreeMat is looking for the math_c99 component, and CMake can't find it.  The latest SVN version has a fix in CMakeLists.txt that doesn't specify the math_c99 component on UNIX systems.  This should probably be ported, or else a newer snapshot should be used.

2. This RPM doesn't install.  None of the included shared libraries that are built end up in the final RPM, as they all lack INSTALL sections in CMakeLists.txt (or link everything statically, depending on the choice below)

3. The library names are very generic, especially libGraphics.so.  If you do end up installing them to %{_libdir}, you might want to prefix their names with something unique like freemat.  Or, you can do what Mandriva seems to be doing, and use the flag -DBUILD_SHARED_LIBS=OFF to link all of the libs into the FreeMat executable

4. The package is in violation of the package naming guidelines at http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Since the SVN trunk is a pre-release of version 4.1 (according to the root CMakeLists.txt) the package version should be called freemat-4.1-0.3.20110620svn  Also, according to the guidelines, the package name should match the upstream project and tarball name, both of which are "FreeMat"  The binary being installed is also capitalized.  I think it should be capitalized, even if it seems like the mandriva package uses an all lowercase "freemat"

5. This package would benefit greatly from a .desktop file since it's installing a graphical application.  You can add one and submit it upstream for consideration.

6. It looks like blas.ini is required at runtime to figure out which BLAS implementation should be used (you'll want to use ATLAS).  Mandriva has a patch that installs blas.ini to /usr/share/freemat and changes the source to look there for it.  I believe we should do the same.

7. I don't think it's necessary to separate the .m files in the toolbox into a separate -data package.  The freemat language is interpreted and depends on the functions in the .m files for basic functionality.  I guess it's not hurting anything since the main package requires the -data package, but the .m files are vital for the program's basic functionality.

8. You might want to copy the PDF Source1 instead of moving it.  At least in my case, usually run rpmbuild -ba from ~/rpmbuild/SPECS, and moving the source file generates a file not found error after the first build attempt.

For reference, when I talk about the mandriva package, I'm looking at the SRPM at http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/freemat/current/

There's also a discussion thread at http://groups.google.com/group/freemat-devel/browse_thread/thread/b9f3b48ac200aec5# that might be relevant

Hello,

Fresh spec , srpm

- Corrected versioning/naming
- builds correctly
- Upstream generated a new pdf so no issue there
- Added desktop file 
- Link statically to final binary. Only internal libs, so this seems okay.
- Correct location of blas.ini

http://ankursinha.fedorapeople.org/freemat/FreeMat-4.1-0.1.20110731svn4218.fc15.src.rpm

http://ankursinha.fedorapeople.org/freemat/FreeMat.spec

Thanks :)

llvm has been updated to 2.9 in rawhide. Removing "depends on".

Please note that I've used a workaround for the headers in the wrong locations, so 727301 is *not* a blocker.

Bug filed upstream for incorrect fsf address:

https://sourceforge.net/tracker/?func=detail&aid=3386316&group_id=91526&atid=597446

Ankur,

Looks like you've gotten lots of help on this package but I didn't see an official reviewer. Do you need one?

Richard

Hi Richard,

Yes! I need a reviewer for this one as well! 

Thank you for taking up so many of my review tickets! :D

Regards,
Ankur

I tried building for x86_64 and it failed to find llvm, but I checked root.log and it appeared that llvm{,-libs,-devel} were all installed.

I'll dig a bit deeper tonight perhaps.

Ankur,

It looks like FreeMat requires llvm 2.9 and only 2.8 is available for Fedora. Have you contacted the llvm maintainer to see if there is a plan to go to 2.9?

(In reply to comment #16)
> Ankur,
> 
> It looks like FreeMat requires llvm 2.9 and only 2.8 is available for Fedora.
> Have you contacted the llvm maintainer to see if there is a plan to go to 2.9?

Hi Richard,

There was already a bug filed. llvm 2.9 will not hit f15. It'll only hit f16 onwards. Here's Michael's comment to the bug:

https://bugzilla.redhat.com/show_bug.cgi?id=694785#c6

Therefore, freemat builds for F16+ :)
I won't request an f15 branch. 

Thanks,
Ankur

Ok, that will work. I tried doing some simple searching but didn't find that bug report.

Ok, I got what looks like a good build. 

I've got two questions for now:

1. Shouldn't the desktop file go in the main package and not the data package?

2. Does blas.ini belong in the main package or data package?

Some observations I had while reviewing the spec file:

1. Should the -data sub-package be set as noarch?

2. I cleaned up the %cmake line for readability. Not a must, but... :)

%cmake -DFORCE_SYSTEM_LIBS=ON \
       -DFFI_INCLUDE_DIR:PATH=%{_libdir}/libffi-3.0.9/include/ \
       -DBUILD_SHARED_LIBS=OFF \
       -DUSE_VTK=ON \
       ./

Also, it's a good idea to put two blank lines between major sections (%prep, %build, %install, etc.) I only put one blank line between similar sections (%files, %files doc, %files devel, etc.)

(In reply to comment #20)
> Some observations I had while reviewing the spec file:
> 
> 1. Should the -data sub-package be set as noarch?
> 
> 2. I cleaned up the %cmake line for readability. Not a must, but... :)
> 
> %cmake -DFORCE_SYSTEM_LIBS=ON \
>        -DFFI_INCLUDE_DIR:PATH=%{_libdir}/libffi-3.0.9/include/ \
>        -DBUILD_SHARED_LIBS=OFF \
>        -DUSE_VTK=ON \
>        ./
> 
> Also, it's a good idea to put two blank lines between major sections (%prep,
> %build, %install, etc.) I only put one blank line between similar sections
> (%files, %files doc, %files devel, etc.)

I'm looking into whether the data package should be noarch. The docs is definitely a noarch. 

The desktop and blas.ini files can go in either the main package or the data package. I had broken it down for the sake of organization. What do you suggest?

I'm making the tweaks and trying to build it. Koji is running. I'll submit an updated spec in a bit. 

Thanks :)
Ankur

Duh!

The data package only holds %{_datadir} files. Of course it's a noarch XD

/me goes to brew that coffee

Ankur

Due to the fact that the main package and the data package require each other, there's no practical difference, but it seems more appropriate to have the desktop file in the same package as the binary it references.

For similar reasons, if it's the binary that opens the ini file then it should probably be in the same package.

hello,

I've made some changes:
* Fri Aug 19 2011 Ankur Sinha <ankursinha AT fedoraproject DOT org> - 4.1-0.2.20110731svn4128
- Make doc package noarch
- Make data package noarch
- Modify blas.ini: Upstream says it's better to use cblas


http://koji.fedoraproject.org/koji/taskinfo?taskID=3289856

spec/srpm:

http://ankursinha.fedorapeople.org/freemat/FreeMat.spec

http://ankursinha.fedorapeople.org/freemat/FreeMat-4.1-0.2.20110731svn4218.fc15.src.rpm

Thanks!
Ankur

+: OK
-: must be fixed
=: should be fixed (at your discretion)
?: Question or clairification needed
N: not applicable

MUST:
[+] rpmlint output: shown in comment: OK
[+] follows package naming guidelines
[+] spec file base name matches package name
[+] package meets the packaging guidelines
[+] package uses a Fedora approved license: GPLv2+
[+] license field matches the actual license.
[+] license file is included in %doc: COPYING
[+] spec file is in American English
[+] spec file is legible
[+] sources match upstream: svn checkout matches recursive diff
[+] package builds on at least one primary arch: Tested F16 x86_64
[N] appropriate use of ExcludeArch
[+] all build requirements in BuildRequires
[N] spec file handles locales properly
[N] ldconfig in %post and %postun
[+] no bundled copies of system libraries
[N] no relocatable packages
[+] package owns all directories that it creates
[+] no files listed twice in %files
[+] proper permissions on files
[+] consistent use of macros
[+] code or permissible content
[+] large documentation in -doc
[+] no runtime dependencies in %doc
[N] header files in -devel
[N] static libraries in -static
[N] .so in -devel
[N] -devel requires main package
[+] package contains no libtool archives
[N] package contains a desktop file, uses desktop-file-install/validate
[+] package does not own files/dirs owned by other packages
[+] all filenames in UTF-8

SHOULD:
[+] query upstream for license text
[N] description and summary contains available translations
[+] package builds in mock
[+] package builds on all supported arches
[?] package functions as described: Did not test.
[+] sane scriptlets
[+] subpackages require the main package
[N] placement of pkgconfig files
[N] file dependencies versus package dependencies
[+] package contains man pages for binaries/scripts

*** APPROVED ***

Of course this is based on llvm 2.9 which is not in stable yet, right?

Richard

llvm is stable for F16 now:

https://admin.fedoraproject.org/updates/OpenGTL-0.9.15.1-2.fc16,ldc-2-3.20110801git58d40d2.fc16,mesa-7.11-2.fc16,pure-0.47-3.fc16,llvm-2.9-2.fc16?_csrf_token=220a1425dd0c2f2856172beb07fca848a8ad73c3

Thank you for the review Richard :)

Ankur

Since F16+ will see llvm 2.9 only, I'm not requesting an F15 branch for this package.

New Package SCM Request
=======================
Package Name: FreeMat
Short Description: A free environment for rapid engineering, scientific prototyping and data processing
Owners: ankursinha
Branches: f16
InitialCC: susmit mrceresa

My apologies for not posting earlier, I just got back from a two week vacation.
I've just built it and tested FreeMat in an F16 alpha virtual machine, and some
serious issues remain:

1. You can't relocate blas.ini without telling FreeMat where to find it in its
new place.  There's a patch in the Mandriva package that handles this:
basically you have to edit libs/libMath/libDynBlas/blas_dyn_link.cpp and change
the location of the ini file in the BlasWrapper::LoadLib function.

2. The .desktop file is broken.  It's trying to execute "freemat", not
"FreeMat."  Less important, but something to look into: there's no icon for the
.desktop file.

3. FreeMat fails to start for me (F16 alpha TC5, build located at [1]).  I will
try rebuilding it locally and re-installing, but the koji build gives me the
following output:

$ FreeMat
QGtkStyle was unable to detect the current GTK+ theme.
RESCAN!!!
Segmentation fault (core dumped)

The backtrace shows that it's crashing somewhere inside libQtGui.so.4.  Have
you tried running this program on an F16 system at all?

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3293825

(In reply to comment #28)
> My apologies for not posting earlier, I just got back from a two week vacation.
> I've just built it and tested FreeMat in an F16 alpha virtual machine, and some
> serious issues remain:
> 
> 1. You can't relocate blas.ini without telling FreeMat where to find it in its
> new place.  There's a patch in the Mandriva package that handles this:
> basically you have to edit libs/libMath/libDynBlas/blas_dyn_link.cpp and change
> the location of the ini file in the BlasWrapper::LoadLib function.

Hrm, I had referred to the mandriva patches. I thought I had made this change. I'll go recheck.

> 
> 2. The .desktop file is broken.  It's trying to execute "freemat", not
> "FreeMat."  Less important, but something to look into: there's no icon for the
> .desktop file.

Corrected. I'll also submit a fresh desktop file to the upstream tracker. 

> 
> 3. FreeMat fails to start for me (F16 alpha TC5, build located at [1]).  I will
> try rebuilding it locally and re-installing, but the koji build gives me the
> following output:
> 
> $ FreeMat
> QGtkStyle was unable to detect the current GTK+ theme.
> RESCAN!!!
> Segmentation fault (core dumped)
> 
> The backtrace shows that it's crashing somewhere inside libQtGui.so.4.  Have
> you tried running this program on an F16 system at all?
> 
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3293825

I'll have to report this issue upstream. I haven't had the chance of testing the f16 rpm, I won't get my f16 system up until later this week. 

Thanks for the prompt comment. I've cancelled the cvs request. I'll request it again once the issues are fixed. 

Regards,
Ankur

f16 faces the problem with freemat 
well freemat is installed but not shown in menu list although you can run it from /usr/bin
./freemat it will run 
what could be the possible reason of missing menu list entry

f16 faces the problem with freemat 
well freemat is installed but not shown in menu list although you can run it from /usr/bin
./freemat it will run 
what could be the possible reason for missing menu list entry

Hello ashay, 

This is a review ticket. The package is not yet in the fedora repositories. Please request assistance on the fedora users mailing list or ask.fedoraproject.org,

Thanks,
Ankur

hello,

Since I'm not working on the fedora medical packages anymore, I am not going to make a cvs request. I shall close this ticket and let someone else take up the package. 

Thanks,
Ankur