make giac/giacpy a standard package

[Ralf Stephan]

The giac and giacpy packages are now one year optional (#12375). Since

pynac-0.6.6 (#20742) has optional support for giac, and uses it to fix a bug,

as well as a much faster GCD, I'm proposing to make the giac/giacpy packages

a standard part of Sage. In a recent thread we could also read about the

speed of its Gröbner basis implementation.

It is planned to do all of Pynac's multivariate polynomial calculations with the

help of libgiac. Alternatively, the 4.x versions of Singular are still not integrated,

and if they were they would still be inferior, so I see no alternative for Pynac.

Please give your opinion.

Regards,

[Dima Pasechnik]

An alternative would be a proper Macaulay2 backend - actually, something that I plan to 

implement.

Anyway, it would be great to have giac/giacpy as standard packages!

[Ralf Stephan]

On Wednesday, June 1, 2016 at 10:00:34 AM UTC+2, Ralf Stephan wrote:

The giac and giacpy packages are now one year optional (#12375). Since

pynac-0.6.6 (#20742) has optional support for giac, and uses it to fix a bug,

as well as a much faster GCD, I'm proposing to make the giac/giacpy packages

a standard part of Sage. In a recent thread we could also read about the

speed of its Gröbner basis implementation.

There were no negative arguments to this. Also meanwhile, a standard installation

would ease Pynac's task of handling potentially different libgiac versions

with different needs that may be installed system-wide.

So what would be the next step in this procedure?

[William Stein]

+1.    Giac definitely seems to be one of the most innovative pieces of OSS math software right now, exactly in areas we tend not to focus on, but are very important for users. Also giac tends to focus on speed and correctness which is again what we need.   The code is also likely to be good quality...   I'm curious what the Windows situation is like...   

Anyway +1 from me. 

 

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my massive iPhone 6 plus.

[mmarco]

+1 

[leif]

Strip the latest version offered by Sage? ;-)

12M giac-1.2.0.19.tar.gz
44M giac-1.2.2.37.tar.gz
41K giacpy-0.5.6.tar.gz

Haven't examined why it has grown by 300% in a minor version update though.


Otherwise additional ~12 MB to the Sage tarball would IMHO be ok; it
exploded during the last few years anyway...


-leif

[leif]

leif wrote:
> Ralf Stephan wrote:
>> On Wednesday, June 1, 2016 at 10:00:34 AM UTC+2, Ralf Stephan wrote:
>>
>> The giac and giacpy packages are now one year optional (#12375). Since
>> pynac-0.6.6 (#20742) has optional support for giac, and uses it to
>> fix a bug,
>> as well as a much faster GCD, I'm proposing to make the giac/giacpy
>> packages
>> a standard part of Sage. In a recent thread we could also read about the
>> speed of its Gröbner basis implementation.
>>
>>
>> There were no negative arguments to this. Also meanwhile, a standard
>> installation
>> would ease Pynac's task of handling potentially different libgiac versions
>> with different needs that may be installed system-wide.
>>
>> So what would be the next step in this procedure?
>
> Strip the latest version offered by Sage? ;-)
>
> 12M giac-1.2.0.19.tar.gz
> 44M giac-1.2.2.37.tar.gz
> 41K giacpy-0.5.6.tar.gz
>
> Haven't examined why it has grown by 300% in a minor version update though.

There's at least

28M giac-1.2.2.37/src/javagiac_linux32.tgz
394K giac-1.2.2.37/src/javagiac_linux64.tgz
28M total

which we certainly don't have to ship, besides perhaps some prepared
documentation (dvi, ps, pdf etc.), and documentation on PARI/GP.

I'd also bzip2 the tarball.

With just the two files above removed (but still a lot more than in the
previous version):

11M giac-1.2.2.37.tar.bz2


-leif

[Han Frederic]

Yes these binaries were left in upstream 1.2.2-37 source tarball, but it is a mistake. I didn't notice this when I made the 1.2.2.37 spkg but the next spkg won't have this. I should update it soon.


For windows performance I can only test through virtual box, so it is not very significant.

[François Bissey]

So I have been inspecting giac, as any discussion of making something
a standard package as an impact for sage-on-gentoo.
We have an old version in the science overlay so I am working on
upgrading it.

1) current 1.2.2-63 and a few earlier versions need the gui, compiling
with "--disable-gui" is broken.
2) the dependency on libao was making me curious so I investigated.
It is an "automagic" dependency. There is a line
AC_CHECK_LIB(ao, main)
in configure.in and the library can be used in src/maple.cc.
What this means is that if you build sage binary on a machine that
has libao, giac will be broken when the binary is installed on
machines without it. So this has to be fixed when giac becomes
standard.
3) lapack can be used but detection is strange and it could lead to
similar pitfalls than libao if the right files are present on the build
system. It currently cannot pick up sage's lapack. It is a default
configure option.

I haven't gone through giacpy yet, but I don't like the fact there
is a sage specific version. Something could be done to only have one
source if my understanding of the issues and solution are correct.

Francois

[Thierry]

Hi,

On Mon, Jul 04, 2016 at 02:14:20PM +1200, François Bissey wrote:
> So I have been inspecting giac, as any discussion of making something
> a standard package as an impact for sage-on-gentoo.
> We have an old version in the science overlay so I am working on
> upgrading it.
>
> 1) current 1.2.2-63 and a few earlier versions need the gui, compiling
> with "--disable-gui" is broken.

If there is a choice there, i would vote for having the gui compiled by
default, and have a 'sage -giac' and/or 'sage -xcas' commands available.

Ciao,
Thierry

> 2) the dependency on libao was making me curious so I investigated.
> It is an "automagic" dependency. There is a line
> AC_CHECK_LIB(ao, main)
> in configure.in and the library can be used in src/maple.cc.
> What this means is that if you build sage binary on a machine that
> has libao, giac will be broken when the binary is installed on
> machines without it. So this has to be fixed when giac becomes
> standard.
> 3) lapack can be used but detection is strange and it could lead to
> similar pitfalls than libao if the right files are present on the build
> system. It currently cannot pick up sage's lapack. It is a default
> configure option.
>
> I haven't gone through giacpy yet, but I don't like the fact there
> is a sage specific version. Something could be done to only have one
> source if my understanding of the issues and solution are correct.
>
> Francois
>

[Francois Bissey]

> On 4/07/2016, at 20:45, Thierry <sage-goo...@lma.metelu.net> wrote:
>
> Hi,
>
> On Mon, Jul 04, 2016 at 02:14:20PM +1200, François Bissey wrote:
>> So I have been inspecting giac, as any discussion of making something
>> a standard package as an impact for sage-on-gentoo.
>> We have an old version in the science overlay so I am working on
>> upgrading it.
>>
>> 1) current 1.2.2-63 and a few earlier versions need the gui, compiling
>> with "--disable-gui" is broken.
>
> If there is a choice there, i would vote for having the gui compiled by
> default, and have a 'sage -giac' and/or 'sage -xcas' commands available.

You intend to have “sage” package fltk?

François

[Han Frederic]

Le lundi 4 juillet 2016 04:14:26 UTC+2, François a écrit :

So I have been inspecting giac, as any discussion of making something
a standard package as an impact for sage-on-gentoo.
We have an old version in the science overlay so I am working on
upgrading it.

1) current 1.2.2-63 and a few earlier versions need the gui, compiling
with "--disable-gui" is broken.

 

I have noticed this also and reported it yesterday. I have tried a very short patch and it looks to solve this.

I haven't gone through giacpy yet, but I don't like the fact there
is a sage specific version. Something could be done to only have one
source if my understanding of the issues and solution are correct.

This need works and it could ends with another split (Ex the non sage version have an experimental Qt output)
giacpy status is different from giac: Giac has regular users through xcas while giacpy is unknown, so the answer to Ralf's question could be different. Any help to merge the 2 versions would be welcome but I would like to still be able to cross build some giacpy for windows from linux.
 

Francois

[parisse]

I'm fixing the build for --disable-gui and I will also add a --disable-ao flag in configure.in (ao is used for the playsnd command). You can --disable-lapack if you think it will cause problems, LAPACK is interesting inside giac only for large matrices (more than 1000x1000, otherwise giac builtin algorithms are fast) or for ill-conditionned SVD (giac builtin svd algorithm is naive).
The GUI will obviously fail in a server-client session. If used locally, it might however be useful, to display giac graphs of course, but also for the prototype code that translates latex files with giac commands inside to interactive HTML5 and to PDF (GUI required for PDF inclusion of images generated by commands returning 2-d graphs).
Stable release 1.2.2-65 will soon be available (it seems that our lab web server is down).

[Francois Bissey]

I am not sure about lapack. Its usefulness may be limited but you
probably want to configure it some other way than looking for
libgfortan, libblas and liblapack in that order.
you probably want to be able to pass linking flags for it through
configure. And replace configure.in by configure.ac. configure.in
is deprecated and support for it may disappear sooner rather than
later.

François

[parisse]

You are welcome if you know how to fix configure.in for lapack support (as long as it does not break my current compilations configurations).

[Dima Pasechnik]

On Monday, July 4, 2016 at 12:07:40 PM UTC+1, parisse wrote:

You are welcome if you know how to fix configure.in for lapack support (as long as it does not break my current compilations configurations).

do you have an online repo available?

Currently http://www-fourier.ujf-grenoble.fr/~parisse/

(or any of its subdirectories) is not working

 

[parisse]

It's back online.

[Dima Pasechnik]

On Monday, July 4, 2016 at 1:06:06 PM UTC+1, parisse wrote:

It's back online.

OK, I just wanted to look at congure.in we are talking about. 

There are AX_BLAS and AX_LAPACK macros which are (semi)standard:

http://www.gnu.org/software/autoconf-archive/ax_blas.html

and  

http://www.gnu.org/software/autoconf-archive/ax_lapack.html

these URLS also point you to .m4 files one can simply put in your m4/

(perhaps sufficiently modern autotools even ship

these macros, I don't know)

[parisse]

How is it supposed to work? I have copied the m4 files into m4/, then if I put
  AX_BLAS([],AX_LAPACK())
instead of
    AC_CHECK_LIB(gfortran, main)
    AC_CHECK_LIB(blas, main)
    AC_CHECK_LIB(lapack, main, [], [CONFIG_LAPACK="no"])
configure fails
./configure: line 15831: syntax error near unexpected token `,AX_LAPACK'
./configure: line 15831: `    AX_BLAS(,AX_LAPACK())'

[Dima Pasechnik]

something like :

AX_BLAS([have_blas=yes], [have_blas=no]) if test "x${have_blas}" = xno; then ... stuff.. ... this is how I used them here: https://github.com/dimpase/csdp/blob/master/configure.ac

[Dima Pasechnik]

also note that lapack needs blas, and in fact AX_LAPACK calls AX_BLAS itself.

Perhaps your line has lead to unwanted recursion...

On Monday, July 4, 2016 at 2:11:54 PM UTC+1, parisse wrote:

[parisse]

Tried

        AX_BLAS([have_blas=yes],[have_blas=no])

        AX_LAPACK([have_lapack=yes],[have_lapack=no])
without success as I feared (my autoconf is 2.69). I will stick to the current checks.

[Francois Bissey]

I wouldn’t try to use one of these. Detecting blas/lapack automatically is
a fool’s errand. There are no standard naming scheme for the libraries
and distress can mess things up on top of it.
The only safe way is to get the stuff needed to link on the command line.
You may want to add detection of the fortran mangling, that suppose you
will be making your code able to cope with that too.

However I would like to know more about the particular lapack install
you are trying to detect:
1) is it in /usr/lib(64) or /usr/local/lib?
2) is it all shared object or static [the way you look at gfortran, blas and then
lapack, suggests static]

François

[Francois Bissey]

> On 5/07/2016, at 09:10, Francois Bissey <francoi...@canterbury.ac.nz> wrote:
>
> I wouldn’t try to use one of these. Detecting blas/lapack automatically is
> a fool’s errand. There are no standard naming scheme for the libraries
> and distress can mess things up on top of it.

distress -> distros [thank you automatic spell checking for this interesting
substitution]

François

[François Bissey]

On 04/07/16 22:41, parisse wrote:
> I will also add a --disable-ao flag in configure.in (ao is used for the
> playsnd command)

Do you have an ETA for that? I noticed it has not landed in 1.2.2-65.

Francois

[François Bissey]

On 04/07/16 22:41, parisse wrote:

> I'm fixing the build for --disable-gui

And I am guessing you didn't mean that it would be in 1.2.2-65 either.
I am still getting

/bin/sh ../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++
-DHAVE_CONFIG_H -I. -I.. -DIN_GIAC -I. -I.. -I. -I.. -O1
-march=native -pipe -ggdb -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS
-c -o Xcas1.lo Xcas1.cc
libtool: compile: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I..
-DIN_GIAC -I. -I.. -I. -I.. -O1 -march=native -pipe -ggdb
-fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -c Xcas1.cc -fPIC -DPIC
-o .libs/Xcas1.o
In file included from Xcas1.cc:39:0:
Xcas1.h:151:3: error: ‘History_Fold’ does not name a type
History_Fold * load_history_fold(int sx,int sy,int sw,int sh,int
sl,const char * filename,bool modified); // might be used from icas.cc
to call xcas online
^
Xcas1.cc: In function ‘void xcas::quit_idle_function(void*)’:
Xcas1.cc:3300:5: error: ‘Fl_Widget’ was not declared in this scope
Fl_Widget * w=(Fl_Widget *)(widget);
^
Xcas1.cc:3300:17: error: ‘w’ was not declared in this scope
Fl_Widget * w=(Fl_Widget *)(widget);
^
Xcas1.cc:3300:31: error: expected primary-expression before ‘)’ token
Fl_Widget * w=(Fl_Widget *)(widget);
^
Makefile:880: recipe for target 'Xcas1.lo' failed


when configuring with --disable-gui in 1.2.2-65.
Do you make release notes or changelog available anywhere? It is
difficult to know what changed from one release to another.

Francois

[parisse]

disable-gui should be working. If not, then I probably made a mistake while copying the archive, you can try http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz
I don't know what you mean by ETA, but disable-ao should also be working. For lapack, it was a little nightmare before I got it working for the various binaries of Xcas I provide on my site. I don't want to spend time on this again since it works for me, and if it does not work for you, you can patch configure.in or disable-lapack.

[Dima Pasechnik]

On Tuesday, July 5, 2016 at 6:13:53 AM UTC+1, parisse wrote:

disable-gui should be working. If not, then I probably made a mistake while copying the archive, you can try http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz
I don't know what you mean by ETA, but disable-ao should also be working. For lapack, it was a little nightmare before I got it working for the various binaries of Xcas I provide on my site. I don't want to spend time on this again since it works for me, and if it does not work for you, you can patch configure.in or disable-lapack.

ETA == https://en.wikipedia.org/wiki/Estimated_time_of_arrival 

[Francois Bissey]

> On 5/07/2016, at 17:13, parisse <bernard...@ujf-grenoble.fr> wrote:
>
> disable-gui should be working. If not, then I probably made a mistake while copying the archive, you can try http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz

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.

> I don't know what you mean by ETA, but disable-ao should also be working.

Dima answered that beautifully.

> For lapack, it was a little nightmare before I got it working for the various binaries of Xcas I provide on my site. I don't want to spend time on this again since it works for me, and if it does not work for you, you can patch configure.in or disable-lapack.
>

You have my sympathy. That it works across the various binaries
you distribute is a small miracle in and of itself.
Auto detection of lapack without help of something like a .pc file
is a nut job. It only works for you because someone decided to
normalise the naming on the platforms you support.

François

[Dima Pasechnik]

On Tuesday, July 5, 2016 at 7:48:51 AM UTC+1, François wrote:

> On 5/07/2016, at 17:13, parisse <bernard...@ujf-grenoble.fr> wrote:
>
> disable-gui should be working. If not, then I probably made a mistake while copying the archive, you can try http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz

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.

[Ralf Stephan]

Bernard sent me earlier:

https://dev.geogebra.org/trac/browser/trunk/geogebra/giac/src/giac

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/HI0uZra5_iI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[Francois Bissey]

> On 4/07/2016, at 22:17, Han Frederic <h...@math.jussieu.fr> wrote:
>
> I haven't gone through giacpy yet, but I don't like the fact there
> is a sage specific version. Something could be done to only have one
> source if my understanding of the issues and solution are correct.
>
> This need works and it could ends with another split (Ex the non sage version have an experimental Qt output)
> giacpy status is different from giac: Giac has regular users through xcas while giacpy is unknown, so the answer to Ralf's question could be different. Any help to merge the 2 versions would be welcome but I would like to still be able to cross build some giacpy for windows from linux.
>

Han, I have looked at both giacpy and giacpy-sage now. They hardly
have anything in common anymore.
At least, it is not obvious from the repos.

Given that the split is already that wide, would there be an objection
to them having different “name” in setup.py so they can be installed
side by side?

François

[Han Frederic]

Le mardi 5 juillet 2016 10:43:52 UTC+2, François a écrit :

Han, I have looked at both giacpy and giacpy-sage now. They hardly
have anything in common anymore.
At least, it is not obvious from the repos.

Given that the split is already that wide, would there be an objection
to them having different “name” in setup.py so they can be installed
side by side?

François

 

 Indeed  I think also that changing the name is slightly better than managing a non conflictual installation because one could install only the bad one.

May be giacpysage or giacpy_sage ?
If so, should we change also the spkg name? (may be we should not, so people will really upgrade?)

[parisse]

1.2.2-67 is ready.

[leif]

Han Frederic wrote:
> Le mardi 5 juillet 2016 10:43:52 UTC+2, François a écrit :
>
>
> Han, I have looked at both giacpy and giacpy-sage now. They hardly
> have anything in common anymore.
> At least, it is not obvious from the repos.
>
> Given that the split is already that wide, would there be an objection
> to them having different “name” in setup.py so they can be installed
> side by side?
>
> François
>
>
> Indeed I think also that changing the name is slightly better than
> managing a non conflictual installation because one could install only
> the bad one.
>
> May be giacpysage or giacpy_sage ?

sagiac, or sagiacpy.

> If so, should we change also the spkg name? (may be we should not, so
> people will really upgrade?)

That's not a problem, since Sage releases and specific spkg versions are
now stupidly tied together (even for optional spkgs).


-leif

[Thierry Dumont]

Le 04/07/2016 23:10, Francois Bissey a écrit :
> I wouldn’t try to use one of these. Detecting blas/lapack automatically is
> a fool’s errand. There are no standard naming scheme for the libraries
> and distress can mess things up on top of it.
> The only safe way is to get the stuff needed to link on the command line.
> You may want to add detection of the fortran mangling, that suppose you
> will be making your code able to cope with that too.
>

Not sure...

I am a cmake user; I do not propose to include cmake in sage :-), but
cmake comes with a lot of scripts like FindBLAS.cmake and FindLAPACK.cmake

I have used them on many linux distributions and it always worked.

So it is certainly possible to mimic what cmake is doing, say with a
python script. Maybe it already exists...

t.d.

[Han Frederic]

I am opening  https://trac.sagemath.org/ticket/20946
to update the giac spkg

[Dima Pasechnik]

On Tuesday, July 5, 2016 at 7:33:50 PM UTC+1, tdumont wrote:

Le 04/07/2016 23:10, Francois Bissey a écrit :
> I wouldn’t try to use one of these. Detecting blas/lapack automatically is
> a fool’s errand. There are no standard naming scheme for the libraries
> and distress can mess things up on top of it.
> The only safe way is to get the stuff needed to link on the command line.
> You may want to add detection of the fortran mangling, that suppose you
> will be making your code able to cope with that too.
>


Not sure...

I am a cmake user; I do not propose to include cmake in sage :-), but
cmake comes with a lot of scripts like FindBLAS.cmake and FindLAPACK.cmake

cmake  is a Sage experimental package, in fact...

[François Bissey]

On 06/07/16 04:16, leif wrote:
>> If so, should we change also the spkg name? (may be we should not, so
>> > people will really upgrade?)
> That's not a problem, since Sage releases and specific spkg versions are
> now stupidly tied together (even for optional spkgs).

Upgrade has to be handled carefully - the new spkg
has to remove the old install whatever its name is.

As for Leif's comment it has always been mostly the
case for sage the distribution.
I have a bit more freedom in sage-on-gentoo but not
all that much. If anything I am sometime pressured to
push upgrade in sage.

Francois

[Ralf Stephan]

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.

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.

[Han Frederic]

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).


 

[Ralf Stephan]

On Friday, December 2, 2016 at 10:51:47 AM UTC+1, Han Frederic wrote:

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.

I think numbering changes at level 4 are the problem that Dima (quote above) meant.

None of the toolos support it.

[Han Frederic]

 I thought that dima was talking of the unstable file with only 1.2.2 in the name but was  OK with 1.2.2-xx?

    > On 5/07/2016, at 17:13, parisse <bernard...@ujf-grenoble.fr> wrote:

>
> disable-gui should be working. If not, then I probably made a mistake while copying the archive, you can try http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac-1.2.2.tar.gz

[Dima Pasechnik]

I was talking about silently changing a tarfile, without changing its name at all.

 

[Ralf Stephan]

On Friday, December 2, 2016 at 1:49:57 PM UTC+1, Dima Pasechnik wrote:

I was talking about silently changing a tarfile, without changing its name at all.

That could happen with any package where the tarball is not on a typical repo server.

Is there a way for the release manager to check validity of the tarball link, e.g. automatically comparing with a template? If so then, as Han says, use the tarball from the official giac site with patches reviewed on trac. What else prevents giac from becoming a standard package?

[Ralf Stephan]

I opened https://trac.sagemath.org/ticket/22011

to prepare the giac package to use the official tarballs.

Regards,

[Thierry]

Hi,

On Fri, Dec 02, 2016 at 07:54:29AM -0800, Ralf Stephan wrote:
> I opened https://trac.sagemath.org/ticket/22011
> to prepare the giac package to use the official tarballs.

What is the logical relation between "make giac a standard Sage package"
and "use the upstream unmodified tarball" ?

While both are legitimate, i do not understand the tie.

Ciao,
Thierry



> Regards,
>
> --

> 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+...@googlegroups.com.

[Han Frederic]

Hi ralf,
I am also lost because what you ask in this trac is what is done by the build/pkg/giac/spkg-src
{{{
VERSION="1.2.2"
VERSIONREV="103"

# The upstream tarball name is: giac"$SOURCEORIG".tar.gz
SOURCEORIG=_"$VERSION"-"$VERSIONREV"

...

# Downloading upstream source
sage-download-file "http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac$SOURCEORIG.tar.gz" "giac$SOURCEORIG.tar.gz"
}}}
and I can see that bzip2, gap and singular also use a spkg-src so it looks allowed for a standard package to use an spkg-src when there is a reason right?
In giac I delete all the french html doc to have a 15Mb gpl tarball instead of the 49Mb original one. (the french html doc is only on a non commercial licence that's why I delete it)

So may be there is a misunderstanding somewhere?

If anyone still have explicit requirement for the giac spkg let me know.

Best
Frederic

[Ralf Stephan]

Apologies. I had the impression that repackaging is frowned upon for security reasons. However, just removing files can be automated, either by the original author or the Sage release manager, so there is room for improvement.

So, for making giac standard package, we are practically waiting for the release manager to just do it, right?

[Thierry]

Hi,

On Fri, Dec 02, 2016 at 10:59:48PM -0800, Ralf Stephan wrote:
> Apologies. I had the impression that repackaging is frowned upon for
> security reasons. However, just removing files can be automated, either by
> the original author or the Sage release manager, so there is room for
> improvement.

I also like the fact that we use untouched upstream tarball. I was just
pointing that it was not related to making a package standard (look, e.g.
at rubiks bundle). It would be good to transform the 'sed' part of giac's
spkg-src into a real patch.

> So, for making giac standard package, we are practically waiting for the
> release manager to just do it, right?

I guess the usual procedure is to ask for consensus on sage-devel, then
create a ticket that changes the 'type' file from 'optional' to
'standard', then indeed the release-manager will add the tarball to Sage
source tarball.

Ciao,
Thierry

[Jeroen Demeyer]

On 2016-07-03 21:08, Han Frederic wrote:
> Yes these binaries were left in upstream 1.2.2-37 source tarball, but it
> is a mistake.

How do you create those binaries? It should be done by a script ("make
dist" if you use autotools), not by hand.

[Han Frederic]

I don't create binaries, they were alerady in B.Parisse's tarball by mistake from (1.2.2-35 to 1.2.2-45) cf the bigger files in:
http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/

But I have missed they were there, I should have deleted them.