Experiment with sagemath and Polybori needs to be built

[Paulo César Pereira de Andrade]

  Polybori needs to be built. In Fedora 16, essentially, this is
required to build
with current cudd-devel

polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
--- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig
    2012-04-24 23:17:47.328677842 -0300
+++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
 2012-04-24 23:17:53.406678079 -0300
@@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF
       return("Invalid argument.");
     case CUDD_INTERNAL_ERROR:
       return("Internal error.");
-    case CUDD_TIMEOUT_EXPIRED:
-      return("Timed out.");
     case CUDD_NO_ERROR:
       return("No error. (Should not reach here!)");
     }

too bad cudd.h version identifier is only a string

#define CUDD_VERSION "2.4.2"

so, probably need to write a check in

polybori-0.8.1/SConstruct

  It is also required a patch similar to this one to be able to build
sagemath with it:

http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/pol...

[...]
  I am still too noob with fedora, so, I could not finish the build,
because, while I know
how to git clone a fedora package, do not know how to fetch sources.
For example,
I see easily how to clone http://pkgs.fedoraproject.org/gitweb/?p=polybori.git

but failed to finish build (did download upstream tarball) due to missing
+ tar xJf /home/pcpa/rpmbuild/SOURCES/polybori-logos.tar.xz -C
/home/pcpa/rpmbuild/BUILDROOT/polybori-0.8.1-2.fc16.x86_64/usr/share/icons/hicolor
tar (child): /home/pcpa/rpmbuild/SOURCES/polybori-logos.tar.xz: Cannot
open: No such file or directory
tar (child): Error is not recoverable: exiting now

and my guess to what to do failed also :-) Need to read more wiki
pages and check
fedpkg options for a readonly checkout, and if it can also be used to
fetch sources.

$ fedpkg clone polybori
Cloning into 'polybori'...
The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)'
can't be established.
RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4'
(RSA) to the list of known hosts.
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Could not execute clone: Command '['git', 'clone',
'ssh://[e-mail]/polybori']' returned non-zero exit
status 128

but as stated above, it would still fail to build sagemath anyway:

Traceback (most recent call last):
  File "./setup.py", line 18, in <module>
    from module_list import ext_modules
  File "/home/pcpa/rpmbuild/BUILD/sage-4.8/spkg/build/sage-4.8/module_list.py",
line 80, in <module>
    for line in open(SAGE_LOCAL + "/share/polybori/flags.conf"):
IOError: [Errno 2] No such file or directory:
'/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/share/polybori/flags.conf'

[...]
  Just so that it should be easy to reproduce what I did tonight in a
quick check of "how deep the water is", and initial adaptation of my
Mandriva sagemath spec, I will attach the spec and patches.

  So far, mpir is not packaged in Mandriva, and besides sagemath, I also patched
Macaulay2 to not hardcode mpir dependency also, and use gmp5.

  The patch to use unpatched ntl should have a nasty side effect in the notebook
because it will miss the error message, if in the terminal, it will
print the error message
to stderr anyway before calling abort. But really, it should have been sagemath
to convince upstream NTL for the need of a more complete api.

Thanks,
Paulo

[Paulo César Pereira de Andrade]

>  and my guess to what to do failed also :-) Need to read more wiki
  Learned about -a or --anonymous, but I used the sequence:
  CONFFILE=%{buildroot}%{_includedir}/polybori/flags.conf
perl -pi -e 's|%{buildroot}||g;' %{buildroot}%{_includedir}/polybori/flags.conf

that is, also moved it to /usr/include/polybori/flags.conf, otherwise
it would require masking who owns the file; in Mandriva I did a different
package approach, with ipbori in the main polybori package. Only issue
with putting it in /usr/include is that it then needs an extra patch to
sagemath's module_list.py:

...
 polybori_extra_compile_args = []
-for line in open(SAGE_LOCAL + "/share/polybori/flags.conf"):
+for line in open(SAGE_INC + "polybori/flags.conf"):
     if not line.startswith("CPPDEFINES"):
...

  Now, with polybori-devel installed, after some extra patches the
failure is:

...
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include
-Ic_lib/include
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/graphs/cliquer.c -o
build/temp.linux-x86_64-2.7/sage/graphs/cliquer.o -w
sage/graphs/cliquer.c:235:27: fatal error: cliquer/graph.h: No such
file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1
...

  I will later (probably tomorrow) use the srpm at
http://jjames.fedorapeople.org/cliquer/ but either way, the
package I use in Mandriva is
http://svn.mandriva.com/viewvc/packages/cooker/cliquer/

Thanks and sorry for replying to myself,
Paulo

[Jerry James]

2012/4/24 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>  that is, also moved it to /usr/include/polybori/flags.conf,
> otherwise
>  it would require masking who owns the file; in Mandriva I did a different
>  package approach, with ipbori in the main polybori package. Only issue
>  with putting it in /usr/include is that it then needs an extra patch to
>  sagemath's module_list.py: 
I don't see a problem with adding it as
/usr/share/polybori/flags.conf.  We should be able to make that work.

>   I will later (probably tomorrow) use the srpm at
>  http://jjames.fedorapeople.org/cliquer/ but either way, the
>  package I use in Mandriva is
>  http://svn.mandriva.com/viewvc/packages/cooker/cliquer/ 
Hmmm, I threw that package together some time ago and haven't touched
it since.  I hope it still works!

>  Thanks and sorry for replying to myself, 
Heh.  Sometimes that's the best way to have an intelligent conversation. :-)
-- 
Jerry James
http://www.jamezone.org/

[Jerry James]

2012/4/24 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>   Polybori needs to be built. In Fedora 16, essentially, this is
>  required to build
>  with current cudd-devel
>
>  polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
>  --- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig
>     2012-04-24 23:17:47.328677842 -0300
>  +++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
>   2012-04-24 23:17:53.406678079 -0300
>  @@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF
>        return("Invalid argument.");
>      case CUDD_INTERNAL_ERROR:
>        return("Internal error.");
>  -    case CUDD_TIMEOUT_EXPIRED:
>  -      return("Timed out.");
>      case CUDD_NO_ERROR:
>        return("No error. (Should not reach here!)");
>      } 
I don't understand.  What problem does this solve?

Also, note that up through Fedora 16, we had a package named
python-polybori, with various subpackages.  A few months ago, I
reorganized the packages to produce a package named polybori and
various subpackages (including a python-polybori subpackage).  This is
available in Fedora 17 (to be released in about a month) and Fedora
Rawhide.  I will probably not backport that reorganization to Fedora
16, as it would involve making some changes that violate the Package
Update Policy; see https://fedoraproject.org/wiki/Updates_Policy.

Bottom line: Fedora 16 has polybori 0.7.2 and cudd 2.4.2, and will
probably stay that way.  Fedora 17 and above currently have polybori
0.8.1 and cudd 2.5.0.  Any changes we need to make should be done
there.

>   It is also required a patch similar to this one to be able to build
>  sagemath with it:
>
>
> http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/pol...
>
>  [...] 
Okay, I can add that easily.  I'm going to wait until I understand why
you wanted the other change above, though.

Also, I haven't yet built polybori with NTL support.  Is that going to
be necessary for Sage?

>   I am still too noob with fedora, so, I could not finish the build,
>  because, while I know
>  how to git clone a fedora package, do not know how to fetch sources. 
Use "fedpkg sources", or you can even run "fedpkg srpm" to build the
source RPM.

>  $ fedpkg clone polybori
>  Cloning into 'polybori'...
>  The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)'
>  can't be established.
>  RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d.
>  Are you sure you want to continue connecting (yes/no)? yes
>  Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4'
>  (RSA) to the list of known hosts.
>  Permission denied (publickey).
>  fatal: The remote end hung up unexpectedly
>  Could not execute clone: Command '['git', 'clone',
>  'ssh://[e-mail]/polybori']' returned non-zero exit
>  status 128 
I believe this is because you are not yet a packager.  Once you are
sponsored, this problem should go away.  If I'm wrong about that,
hopefully someone else reading this will correct me.

>   The patch to use unpatched ntl should have a nasty side effect in
> the notebook
>  because it will miss the error message, if in the terminal, it will
>  print the error message
>  to stderr anyway before calling abort. But really, it should have been sagemath
>  to convince upstream NTL for the need of a more complete api. 
What patch would NTL need to solve this problem?
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

Em 25 de abril de 2012 17:35, Jerry James <loganjerry(a)gmail.com&gt; escreveu:
>  2012/4/24 Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
> >  Polybori needs to be built. In Fedora 16, essentially, this is
> > required to build
> > with current cudd-devel
> >
> > polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
> > --- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig
> >    2012-04-24 23:17:47.328677842 -0300
> > +++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h
> >  2012-04-24 23:17:53.406678079 -0300
> > @@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF
> >       return("Invalid argument.");
> >     case CUDD_INTERNAL_ERROR:
> >       return("Internal error.");
> > -    case CUDD_TIMEOUT_EXPIRED:
> > -      return("Timed out.");
> >     case CUDD_NO_ERROR:
> >       return("No error. (Should not reach here!)");
> >     }
>
>  I don't understand.  What problem does this solve? 
  polybori does not build because CUDD_TIMEOUT_EXPIRED is
not defined in cudd.h (it should be in an enum).

>  Also, note that up through Fedora 16, we had a package named
>  python-polybori, with various subpackages.  A few months ago, I
>  reorganized the packages to produce a package named polybori and
>  various subpackages (including a python-polybori subpackage).  This is
>  available in Fedora 17 (to be released in about a month) and Fedora
>  Rawhide.  I will probably not backport that reorganization to Fedora
>  16, as it would involve making some changes that violate the Package
>  Update Policy; see https://fedoraproject.org/wiki/Updates_Policy. 
  Ok. I am currently running fedora 16 in my home computer, but
should update to use rawhide at some point.

>  Bottom line: Fedora 16 has polybori 0.7.2 and cudd 2.4.2, and will
  I found only python-polybori{,-devel} with "yum search polybori", so, I
built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git
but used the available cudd-devel.

>  probably stay that way.  Fedora 17 and above currently have polybori
>  0.8.1 and cudd 2.5.0.  Any changes we need to make should be done
>  there.
>
> >  It is also required a patch similar to this one to be able to build
> > sagemath with it:
> >
> >
> http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/pol...
> >
> > [...]
>
>  Okay, I can add that easily.  I'm going to wait until I understand why
>  you wanted the other change above, though.
>
>  Also, I haven't yet built polybori with NTL support.  Is that going to
>  be necessary for Sage? 
  Not 100% sure, but several other issues are likely to happen,
and "sage -testall" will show the problems, while others should
also appear until actually getting everything built. But at first
I think it is required. I remember polybori being one of the major
source of problems in my first sagemath packages.

> >  I am still too noob with fedora, so, I could not finish the
> build,
> > because, while I know
> > how to git clone a fedora package, do not know how to fetch sources.
>
>  Use "fedpkg sources", or you can even run "fedpkg srpm" to build the
> source RPM.
>
> > $ fedpkg clone polybori
> > Cloning into 'polybori'...
> > The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)'
> > can't be established.
> > RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d.
> > Are you sure you want to continue connecting (yes/no)? yes
> > Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4'
> > (RSA) to the list of known hosts.
> > Permission denied (publickey).
> > fatal: The remote end hung up unexpectedly
> > Could not execute clone: Command '['git', 'clone',
> > 'ssh://[e-mail]/polybori']' returned non-zero exit
> > status 128
>
>  I believe this is because you are not yet a packager.  Once you are
>  sponsored, this problem should go away.  If I'm wrong about that,
>  hopefully someone else reading this will correct me.
>
> >  The patch to use unpatched ntl should have a nasty side effect in the notebook
> > because it will miss the error message, if in the terminal, it will
> > print the error message
> > to stderr anyway before calling abort. But really, it should have been sagemath
> > to convince upstream NTL for the need of a more complete api.
>
>  What patch would NTL need to solve this problem? 
  It is basically to allow sagemath cython code to have access to the
error string NTL my print.

  The patch I have been using is
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SO...

  You may also want to package and build ntl with gf2x support.

  For the NTL patch probably we should contact upstream to attempt
to have it (not exactly as is in the above link), or an alternate patch with
the same feature added.

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Jerry James]

2012/4/25 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>  Em 25 de abril de 2012 17:35, Jerry James
> <loganjerry(a)gmail.com&gt; escreveu: 
[snip]

>   polybori does not build because CUDD_TIMEOUT_EXPIRED is
>  not defined in cudd.h (it should be in an enum). 
Sorry to be slow.  So the current polybori effectively requires cudd
2.5.0, but Fedora 16 has cudd 2.4.2.  Got it.  This patch isn't
necessary for Fedora 17 or Rawhide, which have cudd 2.5.0, so I will
probably do nothing about this problem.  Sorry.

>   Ok. I am currently running fedora 16 in my home computer, but
>  should update to use rawhide at some point. 
I run Rawhide inside virtual machines, since it can get a bit rough at
times.  But Fedora 17 Beta just came out.  Perhaps it would be worth
updating to that.

>   I found only python-polybori{,-devel} with "yum search
> polybori", so, I
>  built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git
>  but used the available cudd-devel. 
Right.  The situation is not great on Fedora 16, but is too painful to
change now.  Let's focus on making the Fedora 17 versions be all that
we need.

> > Also, I haven't yet built polybori with NTL support.  Is that
> going to
> > be necessary for Sage?
>
>   Not 100% sure, but several other issues are likely to happen,
>  and "sage -testall" will show the problems, while others should
>  also appear until actually getting everything built. But at first
>  I think it is required. I remember polybori being one of the major
>  source of problems in my first sagemath packages. 
Okay, I'll see what needs to happen to build polybori with NTL
support, and add the patch to install flags.conf.

> > What patch would NTL need to solve this problem?
>
>   It is basically to allow sagemath cython code to have access to the
>  error string NTL my print.
>
>   The patch I have been using is
>
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SO...
>
>   You may also want to package and build ntl with gf2x support.
>
>   For the NTL patch probably we should contact upstream to attempt
>  to have it (not exactly as is in the above link), or an alternate patch with
>  the same feature added. 
I am adding the NTL package maintainer to CC to make him aware of this
issue.  Regards,
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

Em 25 de abril de 2012 18:39, Jerry James <loganjerry(a)gmail.com&gt; escreveu:
>  2012/4/25 Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
> > Em 25 de abril de 2012 17:35, Jerry James <loganjerry(a)gmail.com&gt; escreveu:
>
>  [snip]
>
> >  polybori does not build because CUDD_TIMEOUT_EXPIRED is
> > not defined in cudd.h (it should be in an enum).
>
>  Sorry to be slow.  So the current polybori effectively requires cudd
>  2.5.0, but Fedora 16 has cudd 2.4.2.  Got it.  This patch isn't
>  necessary for Fedora 17 or Rawhide, which have cudd 2.5.0, so I will
>  probably do nothing about this problem.  Sorry. 
  No problems. I am doing a test build and package adaptation to
know ahead of time most issues that will need to be solved.

> >  Ok. I am currently running fedora 16 in my home computer, but
> > should update to use rawhide at some point.
>
>  I run Rawhide inside virtual machines, since it can get a bit rough at
>  times.  But Fedora 17 Beta just came out.  Perhaps it would be worth
>  updating to that. 
  Well, until last sunday I was running Mandriva cooker at home, so, I
am used to things breaking, badly :-)

> >  I found only python-polybori{,-devel} with "yum search
> polybori", so, I
> > built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git
> > but used the available cudd-devel.
>
>  Right.  The situation is not great on Fedora 16, but is too painful to
>  change now.  Let's focus on making the Fedora 17 versions be all that
>  we need.
>
> >> Also, I haven't yet built polybori with NTL support.  Is that going to
> >> be necessary for Sage?
> >
> >  Not 100% sure, but several other issues are likely to happen,
> > and "sage -testall" will show the problems, while others should
> > also appear until actually getting everything built. But at first
> > I think it is required. I remember polybori being one of the major
> > source of problems in my first sagemath packages.
>
>  Okay, I'll see what needs to happen to build polybori with NTL
>  support, and add the patch to install flags.conf.
>
> >> What patch would NTL need to solve this problem?
> >
> >  It is basically to allow sagemath cython code to have access to the
> > error string NTL my print. 
  Note accurate :-) What happens is basically that sagemath has
a interface to handle signals, etc, and have a place for a static
string that should describe an error, and it wants to wrap "NTL
print string to stderr and call abort" logic, what makes sense
when NTL is a library it is linked to. The sagemath patch also
adds an extra context pointer to the callback.

> >  The patch I have been using is
> >
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SO...
> >
> >  You may also want to package and build ntl with gf2x support.
> >
> >  For the NTL patch probably we should contact upstream to attempt
> > to have it (not exactly as is in the above link), or an alternate patch with
> > the same feature added.
>
>  I am adding the NTL package maintainer to CC to make him aware of this
>  issue.  Regards, 
  Ok. I just got home, built your cliquer package, but no luck:

...
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include
-Ic_lib/include
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/graphs/cliquer.c -o
build/temp.linux-x86_64-2.7/sage/graphs/cliquer.o -w
In file included from /usr/include/cliquer/graph.h:5:0,
                 from sage/graphs/cliquer.c:235:
/usr/include/cliquer/set.h:16:18: fatal error: misc.h: No such file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1
...

cliquer probably would need this patch, otherwise unsure how
to handle it:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/cliquer/curren...
and there is another header file in the SOURCES dir.

  I also packaged cliquer 1.2 and not updated it, and 1.2 happens
to be the one used at least by sagemath 4.8.

  This is another case we should push for upstream adding
support to the desired interface, not necessarily verbatim
patch and adding new sage_xyz symbols.

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Paulo César Pereira de Andrade]

[...]

>  cliquer probably would need this patch, otherwise unsure how
>  to handle it:
>
>
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/cliquer/curren...
>  and there is another header file in the SOURCES dir.
>
>   I also packaged cliquer 1.2 and not updated it, and 1.2 happens
>  to be the one used at least by sagemath 4.8.
>
>   This is another case we should push for upstream adding
>  support to the desired interface, not necessarily verbatim
>  patch and adding new sage_xyz symbols. 
  For the sake of checking what is next, I patched your cliquer
package, and built this srpm:

http://kenobi.mandriva.com/~pcpa/cliquer-1.21-1.fc16.src.rpm

(not that I did not bump release from yours cliquer srpm)

basically, it installs the new cl.h header, because it appears
to be missing from the main tarball, but some source includes
it, and installed other headers:

cp -p %{SOURCE9} cliquer.h cliquerconf.h graph.h misc.h reorder.h
set.h $RPM_BUILD_ROOT%{_includedir}/cliquer

  After installing a few extra packages, ecl, gc-devel, libfplll-devel, etc,
the next problem is linbox (needs sage specific patches) and missing
lcalc. Note, I feel major problems will be with singular, but that should
show itself shortly :-)

I also scp'ed a sample build log, to have an idea of what I have
building right now:

http://kenobi.mandriva.com/~pcpa/sagemath.log.gz

  Note that at first I want to have it working, then after that redesign
the package to split in multiple components, change some paths,
etc. And from previous experience, once getting it built, expect
very long gdb&valgrind sessions until figuring out what causes
several different crashes.

> > --
> > Jerry James
> > http://www.jamezone.org/ 
Thanks,
Paulo

[Paulo César Pereira de Andrade]

Em 25 de abril de 2012 21:37, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; escreveu:
[...]

  I did a test build with the linbox in fedora, but note that in Mandriva
I packaged linbox 1.1.6 and did not upgrade to have it matching
sagemath spkg version. So, using linbox 1.2.2 in fedora, I see:

sage/libs/linbox/linbox.cpp: In function 'int
__pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_echelonize(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)':
sage/libs/linbox/linbox.cpp:2308:123: error:
'linbox_modn_dense_echelonize' was not declared in this scope
sage/libs/linbox/linbox.cpp: In function 'PyObject*
__pyx_pf_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_4_poly(PyObject*,
PyObject*)':
sage/libs/linbox/linbox.cpp:2480:335: error: no matching function for
call to 'linbox_modn_dense_minpoly(size_t&, size_t**, size_t*,
size_t&, size_t**&, int&)'
sage/libs/linbox/linbox.cpp:2480:335: note: candidate is:
/usr/include/linbox/linbox-sage.h:65:11: note: template<class Element>
Element* linbox_modn_dense_minpoly(Element, Element**, size_t*,
size_t, Element*)
sage/libs/linbox/linbox.cpp:2527:43: error:
'linbox_modn_dense_delete_array' was not declared in this scope
sage/libs/linbox/linbox.cpp: In function 'PyObject*
__pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_matrix_matrix_multiply(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*,
size_t**, size_t**, size_t, size_t)':
sage/libs/linbox/linbox.cpp:2578:187: error: no matching function for
call to 'linbox_modn_dense_matrix_matrix_multiply(size_t&, size_t**&,
size_t**&, size_t**&, size_t&, size_t&, size_t&, size_t&)'
sage/libs/linbox/linbox.cpp:2578:187: note: candidate is:
/usr/include/linbox/linbox-sage.h:77:9: note: template<class Element>
Element* linbox_modn_dense_matrix_matrix_multiply(Element, Element*,
Element*, Element*, size_t, size_t, size_t)
sage/libs/linbox/linbox.cpp: In function 'long unsigned int
__pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_rank(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)':
sage/libs/linbox/linbox.cpp:2634:117: error: 'linbox_modn_dense_rank'
was not declared in this scope
sage/libs/linbox/linbox.cpp: In function 'size_t
__pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_det(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*,
int)':
sage/libs/linbox/linbox.cpp:2697:116: error: no matching function for
call to 'linbox_modn_dense_det(size_t&, size_t**&, size_t&,
size_t&)'
sage/libs/linbox/linbox.cpp:2697:116: note: candidate is:
/usr/include/linbox/linbox-sage.h:59:9: note: template<class Element>
Element linbox_modn_dense_det(Element, Element*, size_t, size_t)
sage/libs/linbox/linbox.cpp: In function 'PyObject*
__pyx_pf_4sage_4libs_6linbox_6linbox_20Linbox_integer_dense_2_poly(PyObject*,
PyObject*)':
sage/libs/linbox/linbox.cpp:5127:253: error: invalid initialization of
non-const reference of type '__mpz_struct (*&)[1]' from an rvalue of
type '__mpz_struct (**)[1]'
/usr/include/linbox/linbox-sage.h:108:6: error: in passing argument 1
of 'void linbox_integer_dense_minpoly(__mpz_struct (*&)[1], size_t&,
size_t, __mpz_struct (**)[1])'
sage/libs/linbox/linbox.cpp:5139:254: error: invalid initialization of
non-const reference of type '__mpz_struct (*&)[1]' from an rvalue of
type '__mpz_struct (**)[1]'
/usr/include/linbox/linbox-sage.h:110:6: error: in passing argument 1
of 'void linbox_integer_dense_charpoly(__mpz_struct (*&)[1], size_t&,
size_t, __mpz_struct (**)[1])'
sage/libs/linbox/linbox.cpp: In function 'PyObject*
__pyx_f_4sage_4libs_6linbox_6linbox_20Linbox_integer_dense_matrix_matrix_multiply(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_integer_dense*,
__mpz_struct (**)[1], __mpz_struct (**)[1], size_t, size_t)':
sage/libs/linbox/linbox.cpp:5283:173: error: too many arguments to
function 'int linbox_integer_dense_matrix_matrix_multiply(__mpz_struct
(**)[1], __mpz_struct (**)[1], __mpz_struct (**)[1], size_t, size_t,
size_t)'
/usr/include/linbox/linbox-sage.h:115:5: note: declared here
error: command 'gcc' failed with exit status 1

But hopefully it would not crash as it appears to have a different
approach to an issue that causes crashes when built with --enable-sage
that is linbox-destructor.patch.

  The patch I use in Mandriva for linbox 1.1.6 is

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/linalg-linbox/...

  Need to check also upcoming sagemath 5.0 sources, but at first
testing 4.8 that is the latest release.

>   Note that at first I want to have it working, then after that
> redesign
>  the package to split in multiple components, change some paths,
>  etc. And from previous experience, once getting it built, expect
>  very long gdb&valgrind sessions until figuring out what causes
>  several different crashes.
>
> >> --
> >> Jerry James
> >> http://www.jamezone.org/
>
>  Thanks,
>  Paulo

[Paulo César Pereira de Andrade]

Em 25 de abril de 2012 22:24, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; escreveu:
>  Em 25 de abril de 2012 21:37, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; escreveu:
>  [...]
>
>   I did a test build with the linbox in fedora, but note that in Mandriva
>  I packaged linbox 1.1.6 and did not upgrade to have it matching
>  sagemath spkg version. So, using linbox 1.2.2 in fedora, I see:
>
>  sage/libs/linbox/linbox.cpp: In function 'int
>
> __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_echelonize(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)':
>  sage/libs/linbox/linbox.cpp:2308:123: error:
>  'linbox_modn_dense_echelonize' was not declared in this scope 
[...]

  I think this is the major showstopper for now.

  Jerry, do you think it is reasonably to downngrade and use
linbox 1.1.6? Patching should be possible, but not much
trivial, quick guess would be to use mpz interfaces for the
apparently now deprecated or available elsewhere or other
interfaces, integer matrix operations.

  Sorry for more fedora newbie questions, but how do I query
what requires a package? E.g. in Mandriva I can use

urpmq --whatrequires foobar

asking it to know what, if anything requires linbox.

>   Need to check also upcoming sagemath 5.0 sources, but at first
>  testing 4.8 that is the latest release. 
  sage 5.0 will also use linbox 1.1.6 from what I understand, or at
least should be what is used in alpha builds.

Thanks,
Paulo

[Jerry James]

2012/4/25 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>   I think this is the major showstopper for now.
>
>   Jerry, do you think it is reasonably to downngrade and use
>  linbox 1.1.6? Patching should be possible, but not much
>  trivial, quick guess would be to use mpz interfaces for the
>  apparently now deprecated or available elsewhere or other
>  interfaces, integer matrix operations. 
Linbox was updated from 1.1.6 to 1.1.7 before I became involved with
it.  Judging by the changelog, though, the problem is that 1.1.6
failed to build due to requiring an old version of givaro and 1.1.7
fixed the build problem:  I became involved when the same problem
occurred; givaro was updated, and then linbox 1.1.7 failed to build.
I contacted upstream about the problem, and they suggested moving to
linbox 1.2.1, which did solve it.  The move to linbox 1.2.2 was
coordinated with another new release of givaro.

In short, moving backwards in linbox versions will require also moving
backwards in givaro versions.

>   Sorry for more fedora newbie questions, but how do I query
>  what requires a package? E.g. in Mandriva I can use
>
>  urpmq --whatrequires foobar
>
>  asking it to know what, if anything requires linbox. 
repoquery --whatrequires foobar

Or, to find the total set of affected packages:

repoquery --whatrequires --recursive foobar

The repoquery command is provided by the yum-utils package.

>   sage 5.0 will also use linbox 1.1.6 from what I understand, or at
>  least should be what is used in alpha builds. 
Hmmm, that puts us in a difficult position.  Fedora is all about being
on the cutting edge, so moving backwards in versions is ... painful.
What might be reasonable is to make new packages, linbox11 and
givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for
the use of sage.  That way we can keep the newer versions around for
anybody who might be using them, but still support sage.  What do you
think?
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

Em 26 de abril de 2012 11:30, Jerry James <loganjerry(a)gmail.com&gt; escreveu:
>  2012/4/25 Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
> >  I think this is the major showstopper for now.
> >
> >  Jerry, do you think it is reasonably to downngrade and use
> > linbox 1.1.6? Patching should be possible, but not much
> > trivial, quick guess would be to use mpz interfaces for the
> > apparently now deprecated or available elsewhere or other
> > interfaces, integer matrix operations.
>
>  Linbox was updated from 1.1.6 to 1.1.7 before I became involved with
>  it.  Judging by the changelog, though, the problem is that 1.1.6
>  failed to build due to requiring an old version of givaro and 1.1.7
>  fixed the build problem:  I became involved when the same problem
>  occurred; givaro was updated, and then linbox 1.1.7 failed to build.
>  I contacted upstream about the problem, and they suggested moving to
>  linbox 1.2.1, which did solve it.  The move to linbox 1.2.2 was
>  coordinated with another new release of givaro.
>
>  In short, moving backwards in linbox versions will require also moving
>  backwards in givaro versions. 
  Ok. Actually, I have been carrying patches for newer givaro with
linbox 1.1.6 and sagemath in Mandriva for quite some time.

  There is this request to update givaro
http://trac.sagemath.org/sage_trac/ticket/9511
and it appears to have been updated, causing linbox to fail :-)
http://trac.sagemath.org/sage_trac/ticket/12349

  I just sent an email to linbox-devel asking for some help in
integrating linbox 1.2.2 with sagemath 4.8 or newer, see
http://groups.google.com/group/linbox-use/browse_thread/thread/713663b790...

> >  Sorry for more fedora newbie questions, but how do I query
> > what requires a package? E.g. in Mandriva I can use
> >
> > urpmq --whatrequires foobar
> >
> > asking it to know what, if anything requires linbox.
>
>  repoquery --whatrequires foobar
>
>  Or, to find the total set of affected packages:
>
>  repoquery --whatrequires --recursive foobar
>
>  The repoquery command is provided by the yum-utils package. 
  Thanks!

> >  sage 5.0 will also use linbox 1.1.6 from what I understand, or
> at
> > least should be what is used in alpha builds.
>
>  Hmmm, that puts us in a difficult position.  Fedora is all about being
>  on the cutting edge, so moving backwards in versions is ... painful.
>  What might be reasonable is to make new packages, linbox11 and
>  givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for
>  the use of sage.  That way we can keep the newer versions around for
>  anybody who might be using them, but still support sage.  What do you
>  think? 
  givaro should be ok, but by contacting upstream we hopefully should
have all components working together. I just reported in sagemath trac:
http://trac.sagemath.org/sage_trac/ticket/12883

>  --
>  Jerry James
>  http://www.jamezone.org/
>  _______________________________________________
>  scitech mailing list
>  scitech(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/scitech 
Paulo

[Paulo César Pereira de Andrade]

2012/4/26 Jerry James <loganjerry(a)gmail.com&gt;:


> >  Jerry, do you think it is reasonably to downngrade and use
> > linbox 1.1.6? Patching should be possible, but not much
> > trivial, quick guess would be to use mpz interfaces for the
> > apparently now deprecated or available elsewhere or other
> > interfaces, integer matrix operations.
>
>  Linbox was updated from 1.1.6 to 1.1.7 before I became involved with
>  it.  Judging by the changelog, though, the problem is that 1.1.6
>  failed to build due to requiring an old version of givaro and 1.1.7
>  fixed the build problem:  I became involved when the same problem
>  occurred; givaro was updated, and then linbox 1.1.7 failed to build.
>  I contacted upstream about the problem, and they suggested moving to
>  linbox 1.2.1, which did solve it.  The move to linbox 1.2.2 was
>  coordinated with another new release of givaro.
>
>  In short, moving backwards in linbox versions will require also moving
>  backwards in givaro versions. 
[...]

>  Hmmm, that puts us in a difficult position.  Fedora is all about
> being
>  on the cutting edge, so moving backwards in versions is ... painful.
>  What might be reasonable is to make new packages, linbox11 and
>  givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for
>  the use of sage.  That way we can keep the newer versions around for
>  anybody who might be using them, but still support sage.  What do you
>  think? 
  Packaging linbox 1.1.6 may be an alternative, but proper approach
should be to get both components to work together. I just attached
two patches to http://trac.sagemath.org/sage_trac/ticket/12883
The sagemath side patch is
http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbo...
and the patch for linbox 1.2.2, that would need to be applied to
Fedora linbox package is:
http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemat...

  As I stated in the trac, these are not final patches, just a call for
feedback, as, while they most likely are correct, I did only test
that it builds and makes both sides agree on api/abi.

  Now my fedora sagemath package is stuck in lcalc :-)

gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include/lcalc/
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include
-Ic_lib/include
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/libs/lcalc/lcalc_Lfunction.cpp -o
build/temp.linux-x86_64-2.7/sage/libs/lcalc/lcalc_Lfunction.o -O3
-ffast-math -w
In file included from sage/libs/lcalc/lcalc_Lfunction.cpp:242:0:
sage/libs/lcalc/lcalc_sage.h:1:15: fatal error: L.h: No such file or directory
compilation terminated.

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Jerry James]

Hi Paulo,

Sorry for the silence.  I was sick for a few days, and spent yesterday
playing catchup at work.  Nevertheless, late in the day yesterday, I
updated the Fedora polybori package to install flags.conf and to build
with NTL support.  The new polybori build should be in today's Rawhide
compose, and here is the Fedora 17 update:

https://admin.fedoraproject.org/updates/polybori-0.8.1-3.fc17

On Sat, Apr 28, 2012 at 7:44 PM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>   Packaging linbox 1.1.6 may be an alternative, but proper approach
>  should be to get both components to work together. I just attached
>  two patches to http://trac.sagemath.org/sage_trac/ticket/12883
>  The sagemath side patch is
>  http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbo...
>  and the patch for linbox 1.2.2, that would need to be applied to
>  Fedora linbox package is:
>  http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemat... 
Okay, let's see what the Sage and linbox upstreams have to say about
your patches.

>   As I stated in the trac, these are not final patches, just a call
> for
>  feedback, as, while they most likely are correct, I did only test
>  that it builds and makes both sides agree on api/abi.
>
>   Now my fedora sagemath package is stuck in lcalc :-) 
Right, nobody has packaged lcalc for Fedora yet.  I'll say more about
that in reply to your other email.
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

2012/5/1 Jerry James <loganjerry(a)gmail.com&gt;:
>  Hi Paulo, 
  Hi Jerry,

>  Sorry for the silence.  I was sick for a few days, and spent
> yesterday
>  playing catchup at work.  Nevertheless, late in the day yesterday, I 
  Hope you are already well now :-)

>  updated the Fedora polybori package to install flags.conf and to
> build
>  with NTL support.  The new polybori build should be in today's Rawhide
>  compose, and here is the Fedora 17 update:
>
>  https://admin.fedoraproject.org/updates/polybori-0.8.1-3.fc17 
  Ok, I am still figuring out my way with fedora, so, currently still
running Fedora16 plus all updates, but plan to switch to rawhide shortly.
For now I am ok with rebuilding some packages, like polybori, or
already running a newer pari.

>  On Sat, Apr 28, 2012 at 7:44 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >  Packaging linbox 1.1.6 may be an alternative, but proper approach
> > should be to get both components to work together. I just attached
> > two patches to http://trac.sagemath.org/sage_trac/ticket/12883
> > The sagemath side patch is
> > http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbo...
> > and the patch for linbox 1.2.2, that would need to be applied to
> > Fedora linbox package is:
> > http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemat...
>
>  Okay, let's see what the Sage and linbox upstreams have to say about
>  your patches. 
  Me too also waiting, otherwise, will take me some time to actually
run sagemath in Fedora and debug it myself, as I believe if there
is something wrong with the patch, it was my misunderstanding
of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed
to "m, n, k" as the constraint is number of rows of A must match
number of columns of B (for multiplication), or missed some place
where there could be a double dereference or double free as
linbox 1.1.6 did allocate a buffer for every matrix row and
linbox 1.2.2 allocates a single buffer.

> >  As I stated in the trac, these are not final patches, just a
> call for
> > feedback, as, while they most likely are correct, I did only test
> > that it builds and makes both sides agree on api/abi.
> >
> >  Now my fedora sagemath package is stuck in lcalc :-)
>
>  Right, nobody has packaged lcalc for Fedora yet.  I'll say more about
>  that in reply to your other email. 
  Ok. Once a newer pari is available I will update the lcalc package,
but it is just a matter of applying the pari patch. Could add a
build requires versioned, but not required as if applying the patch
it would not build with an older pari anyway.

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Thanks,
Paulo

[Paulo César Pereira de Andrade]

2012/5/1 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:

[...]

> > Okay, let's see what the Sage and linbox upstreams have to
> say about
> > your patches.
>
>   Me too also waiting, otherwise, will take me some time to actually
>  run sagemath in Fedora and debug it myself, as I believe if there
>  is something wrong with the patch, it was my misunderstanding
>  of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed
>  to "m, n, k" as the constraint is number of rows of A must match
>  number of columns of B (for multiplication), or missed some place
>  where there could be a double dereference or double free as
>  linbox 1.1.6 did allocate a buffer for every matrix row and
>  linbox 1.2.2 allocates a single buffer. 
  Today I made some experimental builds in a Mandriva computer
where I have sagemath-4.8 working, to update to use givaro 3.5.0
and linbox 1.2.2. It is required significant extra patches to fully
build sagemath, and a new patch is not yet complete, but by doing
this, I will have a better idea of viability of using linbox 1.2.2, or
patching linbox 1.1.6 to use newer givaro.

  Once done the test build, I will see what breaks in sage doctests,
hopefully nothing, or just require trivial patches, and then it should
be easier to get it integrated in sagemath. Too bad I am afraid it
will not be in time for sagemath 5.0, kind like too late even if patches
were available and known to work 3 months ago...

Paulo

[Paulo César Pereira de Andrade]

2012/5/2 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>  2012/5/1 Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:
>
>  [...]
>
> >> Okay, let's see what the Sage and linbox upstreams have to say about
> >> your patches.
> >
> >  Me too also waiting, otherwise, will take me some time to actually
> > run sagemath in Fedora and debug it myself, as I believe if there
> > is something wrong with the patch, it was my misunderstanding
> > of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed
> > to "m, n, k" as the constraint is number of rows of A must match
> > number of columns of B (for multiplication), or missed some place
> > where there could be a double dereference or double free as
> > linbox 1.1.6 did allocate a buffer for every matrix row and
> > linbox 1.2.2 allocates a single buffer.
>
>   Today I made some experimental builds in a Mandriva computer
>  where I have sagemath-4.8 working, to update to use givaro 3.5.0
>  and linbox 1.2.2. It is required significant extra patches to fully
>  build sagemath, and a new patch is not yet complete, but by doing
>  this, I will have a better idea of viability of using linbox 1.2.2, or
>  patching linbox 1.1.6 to use newer givaro.
>
>   Once done the test build, I will see what breaks in sage doctests,
>  hopefully nothing, or just require trivial patches, and then it should
>  be easier to get it integrated in sagemath. Too bad I am afraid it
>  will not be in time for sagemath 5.0, kind like too late even if patches
>  were available and known to work 3 months ago... 
  Jerry, can you please add the attached patch to fflas-ffpack and
better yet if get it in upstream :-)
  I am working on linbox 1.2.2 patches, that also need
-D__LINBOX_HAVE_INT64=1 in CFLAGS and CXXFLAGS
(optional for 32 bit arches and sagemath), as that is not defined
anywhere, and should be done either in configure.ac and autoreconf,
or just set it in linbox.spec, but still trying to get all bits together
to get things to compile and then check if everything works...

Paulo

[Jerry James]

On Thu, May 3, 2012 at 1:03 PM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>   Jerry, can you please add the attached patch to fflas-ffpack and
>  better yet if get it in upstream :-) 
I have sent the patch upstream, and am building a new fflas-ffpack
package now (for Rawhide and F17).
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

2012/5/3 Jerry James <loganjerry(a)gmail.com&gt;:
>  On Thu, May 3, 2012 at 1:03 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >  Jerry, can you please add the attached patch to fflas-ffpack and
> > better yet if get it in upstream :-)
>
>  I have sent the patch upstream, and am building a new fflas-ffpack
>  package now (for Rawhide and F17). 
  Thanks!

  I did get sagemath to build in mandriva with fflas-ffpack with that
patch, and the new linbox and sagemath I am attaching, but for
now, only for documentation purposes.

  linbox 1.2.2 needs to be built with -D__LINBOX_HAVE_INT64=1
in CXXFLAGS and CFLAGS (otherwise the fflas-ffpack patch is
not required).

  The linbox patch corrects some prototypes, adds some extra
definitions (cut&paste&adapt from modular-int32.h) and forces
instantiation of some templates.

  The sagemath patch builds the linbox interface and the matrix
interfaces, but stops when building the givaro interface, as I also
did need to update it in my Mandriva build as newer linbox wants
it. I will get to the same state when I have singular package in
fedora... But it may fail earlier if there is another component
that does not match versions.

  The sage-4.8-linbox.patch also needs to redefine mod_int to
ssize_t instead of size_t, otherwise a very large patch would
be required to implement uint64_t interfaces, or, could use the
unsigned interfaces and force it to use uint32_t.

  I also need to check more carefully
sage/matrix/matrix_integer_dense.pyx because I may have
missed the part where it free's it, and may not be using the
__dealloc__ in sage/libs/linbox/linbox.pyx

  The givaro build failure looks like:

gcc -pthread -shared -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro
-Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags
build/temp.linux-x86_64-2.7/sage/libs/ratpoints.o -Lc_lib
-L/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/lib
-L/usr/lib64 -lcsage -lratpoints -lgmp -lstdc++ -lntl -lm -lgmp -ldl
-lpython2.7 -o build/lib.linux-x86_64-2.7/sage/libs/ratpoints.so
gcc -pthread -fno-strict-aliasing -O2 -Wa,--compress-debug-sections
-gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches
-Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fPIC -DNDEBUG -O2 -Wa,--compress-debug-sections -gdwarf-4
-fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2
-pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4 -fPIC -fPIC -fno-PIE
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/singular
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/factory
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include
-Ic_lib/include
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/libs/singular/singular.cpp -o
build/temp.linux-x86_64-2.7/sage/libs/singular/singular.o -w
In file included from sage/libs/singular/singular.cpp:252:0:
/usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning
somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
In file included from sage/libs/singular/singular.cpp:252:0:
/usr/include/givaro/givconfig.h:91:17: note: #pragma message: #warning
somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:97:17: note: #pragma message: #warning
somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:103:17: note: #pragma message:
#warning somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:109:17: note: #pragma message:
#warning somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:115:17: note: #pragma message:
#warning somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:121:17: note: #pragma message:
#warning somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
/usr/include/givaro/givconfig.h:127:17: note: #pragma message:
#warning somebody nasty previously included <stdint.h> without
__STDC_LIMIT_MACROS :)
sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a type
sage/libs/singular/singular.cpp: In function
'__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_FiniteField_givaroElement*
__pyx_f_4sage_4libs_8singular_8singular_si2sa_GFqGivaro(snumber*,
ip_sring*, __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro*)':
sage/libs/singular/singular.cpp:3383:30: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3392:32: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3401:35: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3421:32: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3449:36: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3461:48: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp:3470:36: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
sage/libs/singular/singular.cpp: In function 'snumber*
__pyx_f_4sage_4libs_8singular_8singular_sa2si(__pyx_obj_4sage_9structure_7element_Element*,
ip_sring*)':
sage/libs/singular/singular.cpp:6150:186: error: 'struct
__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro'
has no member named 'objectptr'
error: command 'gcc' failed with exit status 1

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Paulo César Pereira de Andrade]

2012/5/3 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:

[...]

>  /usr/include/givaro/givconfig.h:85:17: note: #pragma message:
> #warning
>  somebody nasty previously included <stdint.h> without
>  __STDC_LIMIT_MACROS :) 
  This warning is all over the place, but so far, with the attached
linbox-integer.patch on top of an installed system it does not
fail earlier. But should get  __STDC_LIMIT_MACROS defined
before the first c++ code includes stdint.h ...

[...]


>  sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does
> not name a type
>  sage/libs/singular/singular.cpp: In function 
  The attached sage-fedora-prepare.patch is another work in progress
patch,  that should be helpful to give an idea of what needs to be patched
to build with newer linbox, sytem cudd, m4ri, m4rie, etc.

  I did some work to attempt to have Mandriva using the same versions
and as close as possible packages, so that I can know more of what
to expect during preparation to package sagemath in Fedora.

  BTW, current build failure looks like:

gcc -pthread -fno-strict-aliasing -O2 -Wa,--compress-debug-sections
-gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches
-Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fPIC -DNDEBUG -O2 -Wa,--compress-debug-sections -gdwarf-4
-fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2
-pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4 -fPIC -fPIC -fno-PIE
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/cudd
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/polybori
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/polybori/groebner
-Isage/libs/polybori
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include
-Ic_lib/include
-I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/rings/polynomial/pbori.cpp -o
build/temp.linux-x86_64-2.7/sage/rings/polynomial/pbori.o
-DPBORI_NDEBUG -DSIZEOF_VOID_P=8 -DSIZEOF_INT=4 -DSIZEOF_LONG=8
-DPBORI_HAVE_GD -DPBORI_HAVE_TR1_UNORDERED_MAP -DPBORI_HAVE_M4RI
-DPBORI_USE_ORIGINAL_CUDD -DPBORI_HAVE_NTL -mmmx -msse -msse2 -w
sage/rings/polynomial/pbori.cpp: In function 'int
__pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing___init__(PyObject*,
PyObject*, PyObject*)':
sage/rings/polynomial/pbori.cpp:4937:5: error: 'appendBlock' is not a
member of 'polybori::BooleEnv'
sage/rings/polynomial/pbori.cpp: In function 'PyObject*
__pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing_4gen(PyObject*,
PyObject*, PyObject*)':
sage/rings/polynomial/pbori.cpp:5485:393: error: could not convert
'polybori::BoolePolyRing::variable(polybori::BoolePolyRing::checked_idx_type)
const(polybori::CCheckedIdx(((polybori::CAuxTypes::idx_type)(*(((__pyx_obj_4sage_5rings_10polynomial_5pbori_BooleanPolynomialRing*)__pyx_v_self)->__pyx_obj_4sage_5rings_10polynomial_5pbori_BooleanPolynomialRing::pbind
+ ((long unsigned int)(((long unsigned int)__pyx_t_3) * 8ul)))))))'
from 'polybori::BoolePolyRing::var_type {aka polybori::BooleVariable}'
to 'polybori::BooleSet'

[[ at least 100Kb of error messages here ]]

/usr/include/polybori/BooleVariable.h:63:3: note:   no known
conversion for argument 1 from 'const int' to 'const ring_type& {aka
const polybori::BoolePolyRing&}'
/usr/include/polybori/BooleVariable.h:59:3: note:
polybori::BooleVariable::BooleVariable(polybori::CAuxTypes::idx_type,
const ring_type&)
/usr/include/polybori/BooleVariable.h:59:3: note:   candidate expects
2 arguments, 1 provided
error: command 'gcc' failed with exit status 1

  Well, for singular, at least for now I think it is better to use exactly the
version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora)
appears to be going to require quite some work ...

Paulo

[Jerry James]

On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> > /usr/include/givaro/givconfig.h:85:17: note: #pragma message:
> #warning
> > somebody nasty previously included <stdint.h> without
> > __STDC_LIMIT_MACROS :)
>
>   This warning is all over the place, but so far, with the attached
>  linbox-integer.patch on top of an installed system it does not
>  fail earlier. But should get  __STDC_LIMIT_MACROS defined
>  before the first c++ code includes stdint.h ... 
Right, I had to do that with m4rie also.

> > sage/libs/singular/singular.cpp:922:3: error: 'GFqDom'
> does not name a type
> > sage/libs/singular/singular.cpp: In function 
Also an issue with m4rie.  The problem is that there is now a
namespace involved, so you have to change all instances of GFqDom to
Givaro::GFqDom.

>   The attached sage-fedora-prepare.patch is another work in progress
>  patch,  that should be helpful to give an idea of what needs to be patched
>  to build with newer linbox, sytem cudd, m4ri, m4rie, etc. 
Okay, I'll look through it over the weekend.  If you have parts that
you think are ready to go, the best thing to do is file a bug.  That
way the patches won't get lost or forgotten.

>   Well, for singular, at least for now I think it is better to use
> exactly the
>  version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora)
>  appears to be going to require quite some work ... 
Okay, we can pursue that path.

Incidentally, looking at the latest Singular release, I see that it
can use flint if it is available.  We have flint 1.6, which I kept
deliberately because Sage's flint package is at 1.5.0.  However,
Singular wants flint 2.3!  What should we do there?  Is there a part
of sage that really needs the older flint version, or should I upgrade
it for Singular?
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

2012/5/4 Jerry James <loganjerry(a)gmail.com&gt;:
>  On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >> /usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning
> >> somebody nasty previously included <stdint.h> without
> >> __STDC_LIMIT_MACROS :)
> >
> >  This warning is all over the place, but so far, with the attached
> > linbox-integer.patch on top of an installed system it does not
> > fail earlier. But should get  __STDC_LIMIT_MACROS defined
> > before the first c++ code includes stdint.h ...
>
>  Right, I had to do that with m4rie also.
>
> >> sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a
> type
> >> sage/libs/singular/singular.cpp: In function
>
>  Also an issue with m4rie.  The problem is that there is now a
>  namespace involved, so you have to change all instances of GFqDom to
>  Givaro::GFqDom. 
  Yes, that was what I did, plus a few other Givaro:: added to the cython
sources in sage-fedora-prepare.patch.

> >  The attached sage-fedora-prepare.patch is another work in
> progress
> > patch,  that should be helpful to give an idea of what needs to be patched
> > to build with newer linbox, sytem cudd, m4ri, m4rie, etc.
>
>  Okay, I'll look through it over the weekend.  If you have parts that
>  you think are ready to go, the best thing to do is file a bug.  That
>  way the patches won't get lost or forgotten. 
  Right now I will prefer to avoid proposing incomplete patches over
incomplete patches; I already submitted two patches to the sagemath
trac, but specified that they were only to give an idea of the issue,
and a call for feedback...

> >  Well, for singular, at least for now I think it is better to use
> exactly the
> > version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora)
> > appears to be going to require quite some work ...
>
>  Okay, we can pursue that path. 
  I am going to also give up in attempting to get sage-4.8 working, and
work on sage-5.0-rc0, at least it already uses polybori-0.8.1, what makes
life easier for me :-) But I am afraid it may not be easy to get all patches
integrated, because too many components will need to be updated
at once. But IMHO it is sage that is not playing so nice with upstream,
letting several components versions rot, and making things harder for
anybody willing to get sagemath working with system packages in a
Linux distro.

>  Incidentally, looking at the latest Singular release, I see that it
>  can use flint if it is available.  We have flint 1.6, which I kept
>  deliberately because Sage's flint package is at 1.5.0.  However,
>  Singular wants flint 2.3!  What should we do there?  Is there a part
>  of sage that really needs the older flint version, or should I upgrade
>  it for Singular? 
  I really hope flint 2.3 is api compatible with flint 1.5.0, but did not
look at details so far.

  Well, in Mandriva, unless it was an already a system package,
or maintained by somebody else, I always packaged the version
required by sagemath, this way things are easier to handle. And
still took me quite some time to have a usable package after
getting all components working together. But I plan to submit
a singular package for review shortly, unless you want to beat
me to that, then, I suggest following the pattern of the Mandriva
package to avoid too much problems with missing headers,
as well as the sagemath patches:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/singular/curre...

>  --
>  Jerry James
>  http://www.jamezone.org/
>  _______________________________________________
>  scitech mailing list
>  scitech(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/scitech 
Paulo

[Paulo César Pereira de Andrade]

2012/5/4 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt;:

[...]
> >>  Well, for singular, at least for now I think it is better to
> use exactly the
> >> version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora)
> >> appears to be going to require quite some work ...
> >
> > Okay, we can pursue that path. 
[...]
> > Incidentally, looking at the latest Singular release, I see that
> it
> > can use flint if it is available.  We have flint 1.6, which I kept
> > deliberately because Sage's flint package is at 1.5.0.  However,
> > Singular wants flint 2.3!  What should we do there?  Is there a part
> > of sage that really needs the older flint version, or should I upgrade
> > it for Singular?
>
>   I really hope flint 2.3 is api compatible with flint 1.5.0, but did not
>  look at details so far. 
  I made a review request for a Singular package at
https://bugzilla.redhat.com/show_bug.cgi?id=819264

  With the generated Singular and Singular-devel the sagemath 5.0.rc0
build fails at:

gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC
-I/usr/include/malloc/
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.x86_64/usr/share/sagemath/local/include
-Ic_lib/include
-I/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.x86_64/usr/share/sagemath/devel/sage/sage/ext
-I/usr/include/python2.7 -c sage/libs/symmetrica/symmetrica.c -o
build/temp.linux-x86_64-2.7/sage/libs/symmetrica/symmetrica.o -w
In file included from sage/libs/symmetrica/symmetrica.c:237:0:
/usr/include/symmetrica/macro.h:174:1: error: unknown type name 'INT'
In file included from sage/libs/symmetrica/symmetrica.c:237:0:
/usr/include/symmetrica/macro.h:269:1: error: unknown type name 'INT'
In file included from sage/libs/symmetrica/symmetrica.c:237:0:
/usr/include/symmetrica/macro.h:557:1: error: unknown type name 'INT'
/usr/include/symmetrica/macro.h:560:1: error: unknown type name 'INT'
error: command 'gcc' failed with exit status 1

  symmetrica as packaged in Fedora should have the sagemath patches
added to it. First the above case due to symmetrica/macros.h needing a
typedef in symmetrica/def.h. The other patches are to not have the
symbols "sort" and "sum" in global namespace, and the other patch
is to avoid it printing a banner.

  The patches can be fetched from the sagemath package, or also from
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/symmetrica/cur...

  Jerry, a possible issue with the Singular package is that the
generated Singular-devel package conflicts with libfac-devel,
but only headers, because all code is in libsingular.so, so,
I believe  it could be changed to install headers in
/usr/include/singular, as code compiling with it should be
using
#include <factory/...>
and having
-I/usr/include/singular
in CPPPATH.

Paulo

[Paulo César Pereira de Andrade]

2012/5/4 Jerry James <loganjerry(a)gmail.com&gt;:
>  On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >> /usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning
> >> somebody nasty previously included <stdint.h> without
> >> __STDC_LIMIT_MACROS :)
> >
> >  This warning is all over the place, but so far, with the attached
> > linbox-integer.patch on top of an installed system it does not
> > fail earlier. But should get  __STDC_LIMIT_MACROS defined
> > before the first c++ code includes stdint.h ...
>
>  Right, I had to do that with m4rie also. 
  Jerry, sorry for more newbie questions, but what is the procedure to
request a package update?

  I did upload a new symmetrica  with patches to continue sagemath build:

Spec URL: http://kenobi.mandriva.com/~pcpa/symmetrica.spec
SRPM URL: http://kenobi.mandriva.com/~pcpa/symmetrica-2.0-7.fc16.src.rpm

  Also, what you suggest to "update" to run rawhide?

Thanks,
Paulo

[Jerry James]

On Sat, May 5, 2012 at 10:20 PM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>   Jerry, sorry for more newbie questions, but what is the procedure
> to
>  request a package update? 
File a bug against the package in bugzilla.  Often, people will prefix
the bug summary with "RFE: " (Request For Enhancement).  The current
symmetrica maintainer is Conrad Meyer.  I am comaintaining several of
his packages, because he has been short on time recently for working
on Fedora packaging.  I will contact him about comaintaining
symmetrica also.

>   Also, what you suggest to "update" to run rawhide? 
I still think you should update to F-17.  Really.  It's about to be
released, but you can get the nearly final version as described here:

http://lists.fedoraproject.org/pipermail/devel/2012-May/166719.html

I'm not sure if the preupgrade package is ready to go yet or not, but
you could try that as well.  If you really, really want to install
Rawhide, then install the fedora-release-rawhide package, then edit
the files in /etc/yum.repos.d to enable the Rawhide repositories and
disable your current repositories.  Then run "yum distro-sync" and
cross your fingers.  Backup your system first, either way!
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

2012/5/7 Jerry James <loganjerry(a)gmail.com&gt;:
>  On Sat, May 5, 2012 at 10:20 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >  Jerry, sorry for more newbie questions, but what is the procedure to
> > request a package update?
>
>  File a bug against the package in bugzilla.  Often, people will prefix
>  the bug summary with "RFE: " (Request For Enhancement).  The current
>  symmetrica maintainer is Conrad Meyer.  I am comaintaining several of
>  his packages, because he has been short on time recently for working
>  on Fedora packaging.  I will contact him about comaintaining
>  symmetrica also. 
  Ok. Thanks for addressing the flint problem. I did not add RFE:
to the symmetrica bug report, but can do that. I think it would be
also reasonably to rename more functions, because they use names
too much generic, e.g. add, sub, mult, div, sum, sort, etc.

> >  Also, what you suggest to "update" to run rawhide?
>
>  I still think you should update to F-17.  Really.  It's about to be
>  released, but you can get the nearly final version as described here:
>
>  http://lists.fedoraproject.org/pipermail/devel/2012-May/166719.html
>
>  I'm not sure if the preupgrade package is ready to go yet or not, but
>  you could try that as well.  If you really, really want to install
>  Rawhide, then install the fedora-release-rawhide package, then edit
>  the files in /etc/yum.repos.d to enable the Rawhide repositories and
>  disable your current repositories.  Then run "yum distro-sync" and
>  cross your fingers.  Backup your system first, either way! 
  Thanks! I will wait a bit more, as for now I can build from sources
whatever I need, but should shortly attempt to switch to rawhide,
as I am used to run bleeding edge :-)

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Jerry James]

On Mon, May 7, 2012 at 10:48 PM, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>   Ok. Thanks for addressing the flint problem. I did not add RFE:
>  to the symmetrica bug report, but can do that. I think it would be
>  also reasonably to rename more functions, because they use names
>  too much generic, e.g. add, sub, mult, div, sum, sort, etc. 
I have rebuilt symmetrica.  I addressed one other problem.  I saw lots
of complaints in the initial build log about printf format specifiers
being the wrong width.  A little investigation found multiple comments
in the sources about the INT type being 4 bytes.  But it was 4 bytes
on some architectures and 8 bytes on others.  I fixed the headers to
ensure that INT is always 4 bytes, which led to a different set of
printf format specifier problems.  Sigh.  I finally got the thing
patched so that all of the code agrees that INT is 4 bytes.

>   Thanks! I will wait a bit more, as for now I can build from sources
>  whatever I need, but should shortly attempt to switch to rawhide,
>  as I am used to run bleeding edge :-) 
Good luck. :-)
-- 
Jerry James
http://www.jamezone.org/

[Paulo César Pereira de Andrade]

2012/5/8 Jerry James <loganjerry(a)gmail.com&gt;:
>  On Mon, May 7, 2012 at 10:48 PM, Paulo César Pereira de Andrade
>  <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >  Ok. Thanks for addressing the flint problem. I did not add RFE:
> > to the symmetrica bug report, but can do that. I think it would be
> > also reasonably to rename more functions, because they use names
> > too much generic, e.g. add, sub, mult, div, sum, sort, etc.
>
>  I have rebuilt symmetrica.  I addressed one other problem.  I saw lots
>  of complaints in the initial build log about printf format specifiers
>  being the wrong width.  A little investigation found multiple comments
>  in the sources about the INT type being 4 bytes.  But it was 4 bytes
>  on some architectures and 8 bytes on others.  I fixed the headers to
>  ensure that INT is always 4 bytes, which led to a different set of
>  printf format specifier problems.  Sigh.  I finally got the thing
>  patched so that all of the code agrees that INT is 4 bytes. 
  There is still a problem:

Exception occurred:
  File
"/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/libs/symmetrica/all.py",
line 3, in <module>
    from symmetrica import start, end
ImportError: /usr/lib64/libsymmetrica.so.0: undefined symbol: local_ende

  It probably would be better to set DFLAGS in symmetrica,spec to
-DALLTRUE -DFAST like the original makefile does, otherwise, it
is required to remove -DLOCALTRUE

$ grep local_ende BUILD/symmetrica-2.0/*.c
BUILD/symmetrica-2.0/de.c:    local_ende(); /* AK 280705 */
$ grep local_anfang BUILD/symmetrica-2.0/*.c
BUILD/symmetrica-2.0/de.c:    local_anfang(); /* AK 280705 */

  I asked and was granted commit access in the symmetrica
bugzilla, but I think it is better for you to correct it as you already
did a lot of extra work on it :-)

> >  Thanks! I will wait a bit more, as for now I can build from
> sources
> > whatever I need, but should shortly attempt to switch to rawhide,
> > as I am used to run bleeding edge :-)
>
>  Good luck. :-) 
  Thanks :-)

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo

[Paulo César Pereira de Andrade]

Em 25 de abril de 2012 18:39, Jerry James <loganjerry(a)gmail.com&gt; escreveu:

[...]

> >  For the NTL patch probably we should contact upstream to
> attempt
> > to have it (not exactly as is in the above link), or an alternate patch with
> > the same feature added.
>
>  I am adding the NTL package maintainer to CC to make him aware of this
>  issue.  Regards, 
  Ok. I am reviewing some cases where I did the dirty&easy way of just
adapt sagemath patches and not report upstream :-( So, I just requested
the feature, posting to ntl upstream mailing list.

>  --
>  Jerry James
>  http://www.jamezone.org/ 
Paulo