I suggest updating ruby to 1.8.6p287 in unstable, and pushing it to
stable once people confirm it builds and runs on other system/arch
combinations. This release has a working build system and fixes a
number of vulnerabilities in the interpreter.
1.8.1 build could possible be fixed by build-confli
Daniel,
I disagree. The current packaging I've checked in for relax-py
is as simple as can be done. The scons program uses scripts,
sconstruct and in the scons subdirectory of relax to program the
installation and set the directory environmentals in python. Unless
I want to scrap using scons an
Jack Howarth wrote:
> Daniel,
> I disagree. The current packaging I've checked in for relax-py
> is as simple as can be done. The scons program uses scripts,
> sconstruct and in the scons subdirectory of relax to program the
> installation and set the directory environmentals in python. Unless
Joel.LeBlanc wrote:
> I wanted to let you know that octave-atlas core dumps when trying to use
> atlas : (
>
> The commands I am trying are:
> A = randn(100,100);
> B = randn(100,1);
> T = A\b;
>
> That last line causes the problem, which of coarse is when the call is made
> to ATLAS.
>
> I have at
On 12 Aug 2008, at 16:48, Alexander Hansen wrote:
> Joel.LeBlanc wrote:
>> I wanted to let you know that octave-atlas core dumps when trying
>> to use
>> atlas : (
>>
>> The commands I am trying are:
>> A = randn(100,100);
>> B = randn(100,1);
>> T = A\b;
>>
>> That last line causes the problem
Peter,
I don't know if I would say the scons scripts are broken. The
relax package is designed (by default) to be untarred in some
directory (say /usr/local/relax-1.3.0) and then 'scons' called
to compile the c code for relax followed by 'scons install'
to install relax in /usr/local/relax, crea
Peter,
Do you have an examples of programs using scon that properly
do installations in destdir. My goal in the first pass was just
to get this packaged with the least changes possible. The relax
package currently has no build instructions for Mac OS X so
I felt it would be useful to NMR users.
On Tue, Aug 12, 2008 at 12:16:03PM -0400, Jack Howarth wrote:
> Peter,
>I don't know if I would say the scons scripts are broken. The
> relax package is designed (by default) to be untarred in some
> directory (say /usr/local/relax-1.3.0) and then 'scons' called
> to compile the c code for rela
The discussion on the scons thread brought a question to my mind. Quoting:
"
...
If relax-pyXX is really a clean python-varianted package, it doesn't
need to conflicts/replaces its other variants. If it's a package that
uses python internally but doesn't supply python modules that other
packages
Hello,
I am having problems building the pil-py[24, 25] package on 10.5 and I
was wondering if anybody else is having the same problem.
The error in question is the following:
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/X11R6/
include -I/sw/include -DHAVE_LIBJPEG -DHAVE_LIBZ
Pepe Barbe wrote:
> Hello,
>
> I am having problems building the pil-py[24, 25] package on 10.5 and I
> was wondering if anybody else is having the same problem.
>
> The error in question is the following:
>
> gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/X11R6/
> include -I/sw/in
On Aug 12, 2008, at 12:38 PM, Alexander Hansen wrote:
> The description currently in Fink (1.1.5-3 from stable and 1.1.6-3
> in unstable) worked for me (10.5.4/Intel, Xcode 3.1). It looks like
> you're doing 1.1.5-3, judging from the line of output. Is that the
> case?
I am using 10.5.4/I
Pepe Barbe wrote:
> On Aug 12, 2008, at 12:38 PM, Alexander Hansen wrote:
>
>
>> The description currently in Fink (1.1.5-3 from stable and 1.1.6-3
>> in unstable) worked for me (10.5.4/Intel, Xcode 3.1). It looks like
>> you're doing 1.1.5-3, judging from the line of output. Is that the
On Aug 12, 2008, at 1:08 PM, Alexander Hansen wrote:
> Ah--I must have been looking at the wrong line in my 1.1.6 build;
> it's actually the same for me as on 1.1.5, including the lack of /
> usr/local/include. I've got an explanation for that: I've moved /
> usr/local out of the way, so I g
On Aug 12, 2008, at 2:40 PM, Pepe Barbe wrote:
>
> On Aug 12, 2008, at 1:08 PM, Alexander Hansen wrote:
>
>> Ah--I must have been looking at the wrong line in my 1.1.6 build;
>> it's actually the same for me as on 1.1.5, including the lack of /
>> usr/local/include. I've got an explanation for th
On Aug 12, 2008, at 12:25 PM, Alexander Hansen wrote:
> What if a package has python-versioned dependencies, but does not
> itself build public python modules (e.g. a user-executable
> application)? Should we just pick a single python flavor in such
> cases? This comes up occasionally wit
Pepe Barbe wrote:
> On Aug 12, 2008, at 12:25 PM, Alexander Hansen wrote:
>
>
>> What if a package has python-versioned dependencies, but does not
>> itself build public python modules (e.g. a user-executable
>> application)? Should we just pick a single python flavor in such
>> cases? T
On Aug 12, 2008, at 1:43 PM, Alexander Hansen wrote:
> Let's compare what you get by running the command below with the
> following:
> $ fink dumpinfo -fenv pil-py25
> Information about 7049 packages read in 1 seconds.
> env:
> CCACHE_DIR=/sw/var/ccache
> CFLAGS=-I/usr/X11R6/include
> CLASSPATH=
I just committed a new revision of pil-pyXX that should be better
about omitting flags that could lead to the "wrong" file being found.
dan
On Tue, Aug 12, 2008 at 01:54:43PM -0500, Pepe Barbe wrote:
> On Aug 12, 2008, at 1:43 PM, Alexander Hansen wrote:
>
> > Let's compare what you get by runni
On Mon, Aug 11, 2008 at 11:23 AM, David H.
<[EMAIL PROTECTED]> wrote:
> Hello all.
>
> I am finally in a position where I could offer a full Master mirror as
> a bittorrent mirror. This is due to the fact that I have now
> infrastructure which I could donate to Fink.
> I do nto know whether this is
Here are my two cents on this issue. In the past for the
python variant packages I maintain, I have added conflicts
with the view that it is undesirable to allow users to
install multiple python variants of executable packages.
The user should have the option to build the package against
the pyt
On Wed, Aug 13, 2008 at 12:07:55AM -0400, Jack Howarth wrote:
>Here are my two cents on this issue. In the past for the
> python variant packages I maintain, I have added conflicts
> with the view that it is undesirable to allow users to
> install multiple python variants of executable packages
22 matches
Mail list logo
