On Tuesday, July 5, 2016 at 9:31:04 AM UTC+2, Dima Pasechnik wrote:
> Yes that tarball has the goods. I’ll wait for a new 1.2.2-xx tarball
>> though. No self respecting
>> packager wants to deal with an upstream tarball which changes all the
> We had this argument already. If you prefer to keep it this way, please
> provide us a VCS (git preferred) repo
> off which we can label releases by the latest commit in the master branch,
> or something like this.
> This way at least meaningful bug reports can be filed. Please...
> We (or in fact any Linux/OSX distribution system) cannot work with
> different tarballs that are named the same, we do not have tools to support
> this. Each tarball change without name change triggers an alert screaming
> that it has been tampered with.
As it seems (#21963) linking problems cannot be resolved without a standard
Giac package I'd like to restart the argument here.
I successully cloned the giac core from the geogebra repo given here and
today fetched current changes, all via "git svn".
That anwers the question of availability of an actively maintained and
public giac repo. Git config:
url = https://dev.geogebra.org/svn/trunk/geogebra/giac/src/giac
fetch = :refs/remotes/git-svn
However, the code in that giac subdirectory is bare bones, i.e., without
any autotools. The other question is, is this code sufficient to support
both sage/interfaces/giac.py and sage/libs/giac.py and if not,what would be
needed? Would it be easy to add the parser to it in C++ (the one in
geogebra is in java)? If not I might be tempted to create a third giac
package (libgiac) just for linking with Pynac, and the other giac package
can stay optional for eternity.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.