[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: precompiled 3.4 for Debian/Ubuntu: was Re: still problems, version?

From: Uwe Brauer
Subject: Re: precompiled 3.4 for Debian/Ubuntu: was Re: still problems, version?
Date: Tue, 19 Jul 2011 18:42:56 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b29 (linux)

   > 2011/7/19 Uwe Brauer <address@hidden>:

   > I've never used auto-apt, but it only seems to install
   > missing debs detected when building. It shouldn't be
   > necessary because you installed the build-deps, and if
   > it *was* necessary, then the build-deps are indeed
   > outdated and we need to update them for 3.4.

Another issue, after building and installing I wanted to
save a graphic and it turned out that I had to install 
 pstoedit and  epstool

   > This is an ok way of generating personal debs, but
   > please don't upload them to a PPA and encourage people
   > to use them. Octave packaging is not a trivial task
   > that can be automated. If you want to help, please read
   > the Debian new maintainer's guide and help us update
   > our packaging, that has many intricate details related
   > to bugs and situations that have arisen over the years
   > while packaging Octave.

   > We need to update our webpage, but most of the information here is
   > still relevant:


Ok that seems to be a good place to start.
   > What commands?

Well basically the following script should work:
| graphics_toolkit fltk %3.4
| %backend fltk % 3.2
| function Psi=FdOn320(x,y,z)
| r=sqrt(x.^2+y.^2+z.^2);
| Psi=exp(-r./3).*(3*z.^2-r.^2).*2*sqrt(15/(120*pi))/81;
| end
| [x,y,z]=meshgrid(-20:.5:20);
| Psi=FdOn320(x,y,z);
| m=min(Psi(:));
| M=max(Psi(:));
| color=[1 1 0;1 0 1; 0 1 1;0 1 0;1 0 0; 0 0 1; 0 0 0];
| n=2;
| for i=1:n-1
|     isovalue=m+i*(M-m)/n;
|     fv = isosurface(x,y,z,Psi,isovalue);
|     hpatch = patch(fv)
|     isonormals(x,y,z,Psi,hpatch);
|     Alphalevel=0.2+0.8*i/n;
| %    
|      set(hpatch,'FaceColor',color(i,:),'EdgeColor','black')
| %     daspect([1,1,1])
|      view(3); 
|      axis tight
| %     camlight left; 
| end

It does not work in 3.2 (there already a tread about this
issue) and it seems to work in 3.4, although I must add that
the results I obtain are slightly different from the results
of others, but that is a different issue.

   > Because people want to install Octave in clusters, so why should we
   > force them to install the documentation on every cluster, in both HTML
   > and TeXinfo? Why should people that don't intend to help us debug wait
   > longer downloading and installing the debug symbols, which are almost
   > eight times the size of Octave itself? If you are not going to be
   > building oct files, why should you also need Octave's headers? Why
   > should every single Octave-Forge package be installed, some of which
   > may be broken, as is or was for a long time the case oct2mat on the
   > Windows distribution, and many are in fact incompatible with each
   > other and with core Octave functions?

I don't want to start a flame war or anything like this and
the reasons you give below seem sound, however for me they
look valid at a time, where disk space was small and
bandwidth tiny. Today I fail to see that the complication
caused by this approach outweights really its
disadvantages (that is make if difficult for volunteers to enter). 

   > I know this seems like unnecessary complication from
   > the outside, but it's not. Every person has different
   > needs, and Debian needs to cater to many different
   > needs, plus 11 different architectures. A personal .deb
   > package is fine for personal builds, but it won't
   > satisfy our users, and you can't ignore the complexity
   > that building a proper package entails.
How is the situation with rpm, it is so long time ago that I
used them, are they also parted in many small rpms? 

   > It's not that they're picky, anyone who does the work
   > can be a maintainer. The problem is that being a
   > maintainer is hard work and not just a matter of
   > running a few automated tools that build a low quality
   > deb that only works on very specific environments and
   > for very specific usages.
I know,  I maintain some Xemacs pkg myself (which is not
very hard work) but to be  a Debian or Ubuntu is a very
different situation.

   > Ubuntu encourages people to modify their sources.list file to point to
   > any old repository with little regard for the quality or safety of the
   > packages installed from that repository. I would prefer if you didn't
   > encourage Ubuntu users to do this for Octave packages and instead you
   > helped us update the Octave package correctly. This is not plain
   > snobbery; it is simple the best use of our limited volunteer-driven
   > efforts.
This I can believe, it is that I am forced to consider 3.4
and haven't found any precompiled packages. What is wrong
with the approach to have experimental debs for the
impatient with a big warning message and wait for Ubuntu and
Debian to catch up?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]