Le vendredi 2 décembre 2016 08:37:20 UTC+1, Ralf Stephan a écrit : > > 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 >>> times. >> >> >> 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. >> > > But the giac spkg is always built from these sources via the spkg-src: http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/ and they have a meaningful name. Ex: spkg 1.2.2.103 is from source 1.2.2-103. it worked fine since the begining of this repo (in 2014) so I don't understand the need of a new libgiac package from git that will conflict with the optional giac spkg.
Although giacpy_sage could be built from your package(sage/libs/giac.py), I guess that the pexpect interface (sage/interfaces/giac.py) won't work (need the built of icas). > 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: > > [svn-remote "svn"] > 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 "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
