Bug 483663

Sorry, but this isn't eligible for Fedora. The licence is non-free. You're welcome to try and convince upstream to release it under a free licence.

Indeed. This not MIT but a poorly worded custom license with a clear commercial use restriction. Closing this out as CANTFIX.

Someone should let berlios know that this software should not be hosted there.

*** Bug 714336 has been marked as a duplicate of this bug. ***

> Someone should let berlios know that this software should not be hosted there.

+1. Over 2 years have passed and this software which is neither Free nor Open Source is still hosted on BerliOS, which claims to be about Open Source hosting.

Mailed them.

I would note that Jörg Schilling is the BerliOS admin, so it is possible that his licensing interpretations differ from the rest of the universe.

tetgen is now relicenced as AGPL [1].
[1] http://wias-berlin.de/software/tetgen/1.5/FAQ-license.html

Good news!

If anyone would like to resubmit the package, then I'll review it. It's actually an optional build dependency of one of my packages, so I'm still interested in this.

I sent a message to upstream. They placed the source tarball behind a registration form.

The AGPL (like any Free Software license) allows you to register once, download the tarball and redistribute it.

This silly "free registration" bullsh*t is unfortunately quite common in the academic world. ("We want to know who uses our software.") They don't realize that it just doesn't work for packaging, nor that they can't force registration for Free Software.

(By the way, I recommend that you download it NOW, because if they realize they can't force you to register under the new license, they might change it back to something more restrictive. :-( )

I'd like to move on with this:

Spec URL: http://smani.fedorapeople.org/review/tetgen.spec
SRPM URL: http://smani.fedorapeople.org/review/tetgen-1.5.0-1.fc21.src.rpm

I can review this unless rathann (or someone else) will take care of it ....

@Fabian: Mind if I take over?

Taking review.

Downloaded sources match SRPM:
$ sha256sum tetgen1.5.0.tar.gz 
4d114861d5ef2063afd06ef38885ec46822e90e7b4ea38c864f76493451f9cf3  tetgen1.5.0.tar.gz

rpmlint:
Checking: tetgen-1.5.0-1.fc20.x86_64.rpm
          tetgen-devel-1.5.0-1.fc20.x86_64.rpm
          tetgen-1.5.0-1.fc20.src.rpm
tetgen.x86_64: W: spelling-error %description -l en_US tetrahedralizations -> rationalizations, liberalizations
tetgen.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/tetgen/example.poly

Please convert.

tetgen.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libtet.so

It looks like it's getting caught by:
%{_libdir}/libtet.so*

Try using
%{_libdir}/libtet.so.*
instead.

tetgen.x86_64: W: no-manual-page-for-binary tetgen
tetgen-devel.x86_64: W: no-documentation
tetgen.src: W: spelling-error %description -l en_US tetrahedralizations -> rationalizations, liberalizations
tetgen.src: W: patch-not-applied Patch0: tetgen_cmake.patch
3 packages and 0 specfiles checked; 0 errors, 7 warnings.

The rest seem to be false positives.

Looking at the tetgen-cmake.patch, I notice that you arbitrarily set the SO version to 1. I suggest starting from 0. Is there a good reason to start from 1?

Also, I don't like it that (almost) the same code is compiled in /usr/bin/tetgen and in %{_libdir}/libtet.so.* . Is it not possible to patch the code so that /usr/bin/tetgen is linked against the library?

Spec URL: http://smani.fedorapeople.org/review/tetgen.spec
SRPM URL: http://smani.fedorapeople.org/review/tetgen-1.5.0-2.fc21.src.rpm

%changelog
* Sat Jun 14 2014 Sandro Mani <manisandro> - 1.5.0-2
- Fix line endings of example.poly
- Fix libtet.so in main package
- Replace tetgen_cmake.patch with tetgen_build.patch

(Fixed date)

Spec URL: http://smani.fedorapeople.org/review/tetgen.spec
SRPM URL: http://smani.fedorapeople.org/review/tetgen-1.5.0-2.fc21.src.rpm

%changelog
* Thu Jun 19 2014 Sandro Mani <manisandro> - 1.5.0-2
- Fix line endings of example.poly
- Fix libtet.so in main package
- Replace tetgen_cmake.patch with tetgen_build.patch

This looks much better, thanks.

One more thing. I see that a 2MB PDF manual file is available at
http://wias-berlin.de/software/tetgen/#Documentation

Don't you think it's a good idea to package that as a noarch -doc subpackage?

Yes good idea!

Spec URL: http://smani.fedorapeople.org/review/tetgen.spec
SRPM URL: http://smani.fedorapeople.org/review/tetgen-1.5.0-3.fc21.src.rpm

%changelog
* Fri Jun 20 2014 Sandro Mani <manisandro> - 1.5.0-3
- Add doc subpackage

My 2 cents:

%doc README example.poly LICENSE

Are you sure that example belongs to the main package?

example.poly can indeed go into -doc, but I'd keep readme in the main package, given its contents.

SPEC and SRPM updated (no release bump).

Two more nitpicks:

The -doc subpackage doesn't depend on the main package, so it could be installed without it and the LICENSE file would not be present then.

The -doc subpackage places its files in:
/usr/share/doc/tetgen-doc
this is not ideal and you could use _pkgdocdir macro to keep manual.pdf in /usr/share/doc/tetgen

For example, like this:

%install
...
cp -p %{SOURCE1} %{buildroot}%{_pkgdocdir}/

%files
...
%exclude %{_pkgdocdir}/manual.pdf


%files doc
%{_pkgdocdir}/manual.pdf

Documentation packages that pull in dependencies (just for a license file) are inconvenient. Please duplicate the license file instead of adding dependencies on base packages and lots of other stuff.

Uhm, the -doc is not requiring the main package, and does ship a copy of the license file.

As for the pkgdocdir, /usr/share/doc/tetgen-doc would need to exist anyways for LICENSE, so I would end up having

%files
%doc README LICENSE
%dir %{_pkgdocdir}
%exclude %{_pkgdocdir}/manual.pdf
%exclude %{_pkgdocdir}/example.poly

%files doc
%doc LICENSE
%dir %{_pkgdocdir}
%{_pkgdocdir}/manual.pdf
%{_pkgdocdir}/example.poly


In my opinion, it is cleaner to just keep

%files
%doc README LICENSE

%files doc
%doc example.poly LICENSE manual.pdf

Well, the Guidelines don't mandate putting docs in %{_pkgdocdir} yet, so I won't consider this a review blocker.

You could expand the description of the -doc subpackage a bit (saying that it contains the manual and an example file), but that's not a blocker either.

Source checksums match:
----------------
http://www.tetgen.org/1.5/src/tetgen1.5.0.tar.gz :
  CHECKSUM(SHA256) this package     : 4d114861d5ef2063afd06ef38885ec46822e90e7b4ea38c864f76493451f9cf3
  CHECKSUM(SHA256) upstream package : 4d114861d5ef2063afd06ef38885ec46822e90e7b4ea38c864f76493451f9cf3
http://www.tetgen.org/1.5/doc/manual/manual.pdf :
  CHECKSUM(SHA256) this package     : ce71e755c33dc518b1a3bc376fb860c0659e7e14b18e4d9798edcbda05a24eca
  CHECKSUM(SHA256) upstream package : ce71e755c33dc518b1a3bc376fb860c0659e7e14b18e4d9798edcbda05a24eca
     
Package APPROVED.

> Well, the Guidelines don't mandate putting docs in %{_pkgdocdir} yet, so I won't consider this a review blocker.

yet -> Do you know whether a corresponding discussion ongoing? Personally I'd also like to see the -doc situation cleaned up, since most of the time when packaged separately they should most likely either go into %{_datadir}/doc/%{name} or in %{_datadir}/doc/%{name}-devel. However, the issue that remains is what to do with the license file.

Anyhow, thanks for the review! Will adapt the -doc description when importing.

New Package SCM Request
=======================
Package Name: tetgen
Short Description: A tetrahedral mesh generator (
Owners: smani
Branches: f20 el6 epel7
InitialCC:

(Copy-paste mistake fix...)

New Package SCM Request
=======================
Package Name: tetgen
Short Description: A tetrahedral mesh generator
Owners: smani
Branches: f20 el6 epel7
InitialCC:

Git done (by process-git-requests).

tetgen-1.5.0-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/tetgen-1.5.0-3.fc20

Re: comment 28

Doubtful that there will ever be guidelines that suggest/mandate putting subpackage documentation into %_pkgdocdir. That would be a Herculean task for some packages [1], considering that you would have to %exclude lots of files and directories as not to duplicate files in multiple packages.

[1] Packages, which put many files directly into the top doc directory and/or which distinguish between user docs and developer docs.


Where all docs can be packaged in %_pkgdocdir without a lot effort, that's convenient for the package users, however, IMO.

tetgen-1.5.0-3.fc20 has been pushed to the Fedora 20 testing repository.

tetgen-1.5.0-3.fc20 has been pushed to the Fedora 20 stable repository.

tetgen-1.5.0-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/tetgen-1.5.0-4.el6

tetgen-1.5.0-4.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/tetgen-1.5.0-4.el7

tetgen-1.5.0-4.el6 has been pushed to the Fedora EPEL 6 stable repository.

tetgen-1.5.0-4.el7 has been pushed to the Fedora EPEL 7 stable repository.