search

timschmidt / repsnapper

RepSnapper RepRap control software
http://reprap.org/wiki/RepSnapper_Manual:Introduction
154 stars 52 forks source link

Question: A heavily patched copy of libreprap #86

Closed hroncok closed 11 years ago

hroncok commented 11 years ago

Hi, I'm currently packaging Repsnapper for Fedora and there's a rule about bundled libs. Long story short, I need to package libreprap as a standalone package.

From the original repository https://github.com/Ralith/libreprap it seems upstream-dead. However, version in this repo is newer and says:

A heavily patched copy of this is hosted inside repsnapper to avoid the compound grief of multiple repos and permissions.

Are you now supplying fro the upstream, or how it works? Should I package your source as libreprap?

Anyway, what is libreprap's license? I cannot find it anywhere.

Thanks.

hurzl commented 11 years ago

As there is no license mentioned in libreprap I would just guess it is free. Same would apply to the modified version in repsnapper. I don't know Fedora's rules, but I wouldn't package that separately, it's just a part of repsnapper. It should be replaced by something working anyway ...

hroncok commented 11 years ago

As there is no license mentioned in libreprap I would just guess it is free.

That just simply cannot work for me. When there is no license, it is actually not free, as copyright law applies. I'll ask the original author.

I don't know Fedora's rules, but I wouldn't package that separately, it's just a part of repsnapper.

Well, so why it is called a lib(rary)? Is it working separately and can it be used as a library for other project (technically)?

hurzl commented 11 years ago

Repsnapper uses other "libs" too, they are not installed but linked into the executable. If you know how to handle it you can use any part of repsnapper separately ;-) But of course it wouldn't do any harm to ask the author ...

hroncok commented 11 years ago

Repsnapper uses other "libs" too, they are not installed but linked into the executable.

Yes I know, I have to debundle them all.

But of course it wouldn't do any harm to ask the author ...

OK, hope he'll answer https://github.com/Ralith/libreprap/issues/4

hurzl commented 11 years ago

You want to build shared lib packages of all of them? This is very interesting :-) Many (most?) of them don't have a release version And some of them are also patched (amf, clipper probably)!

wijnen commented 11 years ago

On 03-02-13 05:16, hurzl wrote:

You want to build shared lib packages of all of them? This is very interesting :-) Many (most?) of them don't have a release version

When I was planning to build a Debian package, I looked into separating the libraries as well. I did find an upstream for vmmlib. Upstream was very helpful and even released a version to make packaging easier. Repsnapper does need to be changed a bit for it, but that is worthwhile anyway; copies of old libraries in your source is asking for trouble.

You can check Debian's vmmlib package for details; upstream is at http://vmmlib.sourceforge.net/.

FYI, given the notices in the source, I considered libreprap to be forked, meaning that repsnapper is the new repository for it. It's a private library, which doesn't need to be packaged separately. That's how it looked to me, anyway. I didn't notice the missing license; that will obviously need to be cleared up.

I have been planning for a long time to rewrite the copyright file for repsnapper; it mentions things that aren't in the source anymore and now you found that it also doesn't mention things that are. Don't count on me doing that anything soon though; doing it yourself is a better idea. ;-)

Thanks, Bas

Thanks, Bas

thaytan commented 11 years ago

According to http://reprap.org/wiki/Libreprap libreprap is BSD licensed. It would be better if Ralith clarifies so we can add a COPYING file.

I would prefer not to see the libraries unbundled. As hurzl said, many of them are modified from upstream, and upstream often doesn't have a release, or a stable API. In all cases, they are statically linked into Repsnapper, and the fact that we keep them as separate libraries in the source tree is purely a matter of our convenience - we could roll the files directly into the main Repsnapper code.

wijnen commented 11 years ago

On 03-02-13 11:24, Jan Schmidt wrote:

I would prefer not to see the libraries unbundled. As hurzl said, many of them are modified from upstream, and upstream often doesn't have a release, or a stable API. In all cases, they are statically linked into Repsnapper, and the fact that we keep them as separate libraries in the source tree is purely a matter of our convenience - we could roll the files directly into the main Repsnapper code.

The problem with bundling libraries is not that it's not beautiful. It is that you make a copy of a piece of source code. Then if a bug is found in the original, or the copy, it is likely that the fix is not applied in the other. This is unfortunate for regular bugs, and a serious issue for security bugs.

How the thing is linked makes no difference. The fact that the code is copied is the problem.

Sometimes it is reasonable to fork a library and maintain it yourself. But as long as the original is maintained as well, it is always good to try to use that version (possibly getting functionality you need incorporated into it).

In extreme cases it may not be possible. But just saying "it's more convenient for us" and accepting the risk of serious security problems for the users is not a good thing to do.

Thanks, Bas

thaytan commented 11 years ago

Yes yes, yada yada dangerous upstream security bugs. I know why we'd use upstream versions. If they were usable like that, we would have - the same way we use libgtk and Xlib etc from the system. In this case, the libraries we've pulled into our tree are that way because upstream doesn't do tarball releases, or they don't provide API stability (meaning every new version has to be manually vetted before we include it), or they're not packaged into distributions in any reliable form.

mmeeks commented 11 years ago

On Sat, 2013-02-02 at 18:42 -0800, Miro Hrončok wrote:

    A heavily patched copy of this is hosted inside repsnapper to
    avoid the compound grief of multiple repos and permissions.
Heavily patched is something of an under-statement; I very

substantially re-worked that code.

Are you now supplying fro the upstream, or how it works? Should I package your source as libreprap?

IMHO the value of libreprap as a standalone thing is pretty minimal,

even if it did a great job of serial communication (which it ~doesn't ;-). Last I heard we wanted to rip/replace that anyway.

So I'd treat it as an internal implementation library. Lots of GNOME

packages do that - libnautilus-private (as a historical example) ;-) so

michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot

hroncok commented 11 years ago

You want to build shared lib packages of all of them?

Yes. Some of them ale already in Fedora.

https://admin.fedoraproject.org/pkgdb/acls/name/vmmlib https://admin.fedoraproject.org/pkgdb/acls/name/polyclipping (clipper) https://admin.fedoraproject.org/pkgdb/acls/name/muParser

Many (most?) of them don't have a release version

That's not such a big problem.

According to http://reprap.org/wiki/Libreprap libreprap is BSD licensed. It would be better if Ralith clarifies so we can add a COPYING file.

Looking through the history, it was obviously not putted there by Ralith.

I would prefer not to see the libraries unbundled.

Well, if anyone things like that, we would have thousands of copies of one library in one system.

FYI, given the notices in the source, I considered libreprap to be forked, meaning that repsnapper is the new repository for it.

Looks like that to me too.

It's a private library, which doesn't need to be packaged separately. That's how it looked to me, anyway

Heavily patched is something of an under-statement; I very substantially re-worked that code.

Well it seems like this to me: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Modified_beyond_a_certain_extent

or they don't provide API stability (meaning every new version has to be manually vetted before we include it), or they're not packaged into distributions in any reliable form

That's now my trouble in Fedora.

hroncok commented 11 years ago

I would prefer not to see the libraries unbundled.

Not to mention, that statically linking amftools code (GNU LGPLv3) into Repsanpper (GNU GPLv2) and distributing the binary might be a problem.

thaytan commented 11 years ago

On Sun, 2013-02-03 at 04:04 -0800, Miro Hrončok wrote:

    You want to build shared lib packages of all of them?

Yes. Some of them ale already in Fedora.

https://admin.fedoraproject.org/pkgdb/acls/name/vmmlib https://admin.fedoraproject.org/pkgdb/acls/name/polyclipping (clipper) https://admin.fedoraproject.org/pkgdb/acls/name/muParser

I'd be OK with adding configure checks for a suitable external version before choosing the internal copy, but retaining the internal copies. I'm using the usual argument of making it easy for people to download and build without having to fetch a bunch of dependencies that aren't widely packaged (yet).

    Many (most?) of them don't have a release version

That's not such a big problem.

    According to http://reprap.org/wiki/Libreprap libreprap is BSD
    licensed. It would be better if Ralith clarifies so we can add
    a COPYING file.

Looking through the history, it was obviously not putted there by Ralith.

I haven't seen Ralith around for a while (over a year on #reprap), so he might be hard to ask. Let's see if he replies. At the time we were integrating libreprap, he was well aware of the use and was OK with it. It's an oversight not to have the license stated, but one that definitely needs fixing - even if it's by ripping out libreprap and replacing it with something that works across more platforms.

    or they don't provide API stability (meaning every new version
    has to be manually vetted before we include it), or they're
    not packaged into distributions in any reliable form

That's now my trouble in Fedora.

Well, as usual - I'll believe that the first time someone installs Repsnapper from Fedora and it crashes because the API-unstable and poorly-version-numbered dep libraries changed from the ones we built and tested... and the users first thought is 'oh, I'd better go file a bug against Fedora because they have a packaging problem' instead of 'oh, Repsnapper is a crashy piece of shit, I'll tell all my friends to go use Slic3r instead'

J.

Jan Schmidt thaytan@noraisin.net

hroncok commented 11 years ago

Well, as usual - I'll believe that the first time someone installs Repsnapper from Fedora and it crashes because the API-unstable and poorly-version-numbered dep libraries changed from the ones we built and tested... and the users first thought is 'oh, I'd better go file a bug against Fedora because they have a packaging problem' instead of 'oh, Repsnapper is a crashy piece of shit, I'll tell all my friends to go use Slic3r instead'

Very well written. :)

So amftools might have a bit unstable API. But if the API changes, will it even compile? Could you provide some tests to run when building Repsnapper to check if every lib is suitable?

hurzl commented 11 years ago

I had to hack clipper and poly2tri in several versions for crashes and nonsense-results. vmmlib seems ok. In amftools I added zip support, which is probably now included upstream (link to patch on http://sourceforge.net/p/amftools/code/32/tree/ is not working)

hroncok commented 11 years ago

Poly2tri is upstream version in this repo, diff returns nothing. Cannot tell about clipper, because there's no 4.6.3 version to download anymore. Amftools seems to be different in upstream and here, please tell me what to do to test it -> opening AMF file is enough?

hurzl commented 11 years ago

Just tried to update clipper. It has changed paths, and seems to have changed the API again. So when you unbundle it, it will not work.

RS should be able to read and write (simple) AMFs

hroncok commented 11 years ago

So when you unbundle it, it will not work.

Could you please provide some steps I should do to test this statement? It compiles and runs just fine.

hroncok commented 11 years ago

RS should be able to read and write (simple) AMFs

It opens and saves files form http://amf.wikispaces.com/AMF+test+files

hurzl commented 11 years ago

If the saved AMF file is in ZIP format it seems ok. I have no objection against unbundling AMF.

With clipper I'm not sure (yet) I get linking errors

hroncok commented 11 years ago

This what I had to do on Fedora.

diff -ru a/src/Makefile.am b/src/Makefile.am

-repsnapper_LDADD = libreprap.la libclipper.la libpoly2tri.la liblmfit.la libamf.la $(OPENMP_CFLAGS) $(OPENVRML_LIBS) $(GTKMM_LIBS) $(GL_LIBS) $(XMLPP_LIBS) $(LIBZIP_LIBS) $(BOOST_LDFLAGS)
+repsnapper_LDADD = libreprap.la libpoly2tri.la liblmfit.la libamf.la $(OPENMP_CFLAGS) $(OPENVRML_LIBS) $(GTKMM_LIBS) $(GL_LIBS) $(XMLPP_LIBS) $(LIBZIP_LIBS) $(BOOST_LDFLAGS)  -lpolyclipping

diff -ru a/src/slicer/clipping.h b/src/slicer/clipping.h

-#include <clipper/clipper/polyclipping/trunk/cpp/clipper.hpp>
+#include <polyclipping/clipper.hpp>
hurzl commented 11 years ago

There is no clipper package on many systems, like FreeBSD ...

... so please write the autoconf stuff for detecting this and the other libs ;)

hroncok commented 11 years ago

I agree. There is one on Fedora. And Fedora is what I am talking about now. I don't suggest to you to stop bundling clipper. I'm just staying, it works well with unbundled one.

hurzl commented 11 years ago

Of course it "works" unbundled, the questions are:

Except for the ZIP part of AMF there were no added features, so I think everything will work unbundled ...

hroncok commented 11 years ago

are the bugs we had fixed on the local version also fixed upstream?

I'd strongly suggest to push your fixes to upstream.

hroncok commented 11 years ago
hurzl commented 11 years ago

There is a big API change coming in clipper, see svn version 5.1.0. That's why it was not compiling for me ...

hroncok commented 11 years ago

We are aware of this in Fedora and watching it.

http://upstream-tracker.org/versions/clipper.html

hurzl commented 11 years ago

FreeBSD now has a clipper package

maurerpe commented 11 years ago

I was having trouble printing with repsnapper. The printer would hang for a few seconds and then start again. It did this several times during the print. I rewrote the code in the /printer directory to make the printer multithreaded so it would not hang. It works really well. This was a from scratch rewrite and does not use libreprap at all.

To make a long story short, the maurerpe/repsnapper branch does not use libreprap. I have deleted the libreprap directory and removed it from the build process. If there is interest in getting this code folded back into the main line timschmidt / repsnapper, the whole issue of separate libs and licences for libreprap would be moot. (All my contributions are under the standard repsnapper licence and include the standard header).