I've been been trying to rework the debian racket packaging, and to
understand the new racket build system. I need to have the two seperate
targets, which most of the package installation is done in the the
"build-indep-stamp" target.
The following makefile snippet is _almost_ working, except th
Matthew Flatt writes:
>
> That said, is there a particular reason that basing the build on the
> git repo would be better?
>
One reason is that I need I need to track from release to release the
files that are removed from the racket source by debian for
licensing-related reasons. Currently this
Matthew Flatt writes:
>
> Meanwhile, I haven't answered your original question. Can you remind me
> of the specific steps that I'd need to follow to try the script that
> you sent before?
With your indulgence, I'll just answer this part now. I have re-included
the Makefile as an attachment, sinc
Building racket 6.1, from racket-6.1-src.tgz, the debian build
calls make install twice,
the first time with PLT_EXTRA="--no-docs --no-zo", and the second time
with PLT_EXTRA="--no-launcher --no-install --no-post-install". This
second (main) call is crashing after some recent change in Debian
unst
David Bremner writes:
> Building racket 6.1, from racket-6.1-src.tgz, the debian build
> calls make install twice,
> the first time with PLT_EXTRA="--no-docs --no-zo", and the second time
> with PLT_EXTRA="--no-launcher --no-install --no-post-install". This
> s
David Bremner writes:
>
> As a point of information, I can duplicate the crash with yesterdays
> snapshot (20141022-d9f2a84). I didn't bother getting a backtrace there,
> but I can if it would help.
I verified that the version of libcairo2 is what makes a difference.
Installi
Jens Axel Søgaard writes:
>
> It might me worth doubling checking that the versions of the shared
> libaries that Racket loads matches your expectations.
>
> Then again, maybe there were an API change in Cairo that
> caused the problem - and if so the above is irrelevant.
>
Since I'm building fo
A user submitted the attached patch for partial support for arm64 on
Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation.
If the patch makes sense to you, perhaps you'd like to apply it
upstream.
d
>From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001
From: Y
Hi All;
I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with
src/racket/src/port.c
The main problems stem from MZ_FLUSH_* not being defined. This in turn
seems to be because MZ_FDS is not defined at line 259. At that point I
got stuck, I couldn't see what controlled this def
On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt wrote:
> At Thu, 21 Apr 2011 22:22:00 -0300, David Bremner wrote:
>
> Besides some code-organization problems, my guess is that "sconfig.h"
> doesn't figure out that you're on a FreeBSD variant. Do you know what
&
On Thu, 21 Apr 2011 23:06:23 -0300, David Bremner wrote:
> On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt wrote:
>
> > Besides some code-organization problems, my guess is that "sconfig.h"
> > doesn't figure out that you're on a FreeBSD variant. Do you
On Sun, 24 Apr 2011 08:58:19 -0600, Matthew Flatt wrote:
> It's in the "racket" subdirectory. I've changed the `configure' case
> from "FreeBSD" to "*FreeBSD", which I think is the right fix.
Latest master and 5.1+your patch builds on Debian/kFreeBSD, _if_ I use
configure --enable-cgcdefault. Ot
On Fri, 22 Apr 2011 12:06:10 -0400, Asumu Takikawa wrote:
> Since collects/openssl/mzssl.rkt depends on SSLv2 (presumably for legacy
> support?), this seems to cause a build failure on Debian testing and
> newer using the system libraries.
Yeah, this is a problem for the official Debian builds a
matic? Can someone with a stock FreeBSD-i386
confirm that 5.1 (or git) builds there?
>From 5da8f3df6174e509c60fc62b3ad0dd6b8ce572cf Mon Sep 17 00:00:00 2001
From: David Bremner
Date: Tue, 26 Apr 2011 22:25:55 -0300
Subject: [PATCH] add sys/cdefs.h and sys/param.h before floatingpoint.h
This
On Wed, 27 Apr 2011 18:48:51 -0600, Matthew Flatt wrote:
>
> Do you have any process limits set? (My impression is memory is often
> limited by default on FreeBSD systems.)
>
There was a limit of 512M on data segment size, which I raised to 2G, but it
doesn't seem to change much. Resident set s
ep 17 00:00:00 2001
From: David Bremner
Date: Thu, 28 Apr 2011 20:00:37 -0300
Subject: [PATCH] Add cdefs.h and param.h before ieeefp.h. Change ieeefp.h to
machine/ieeefp.h
---
src/racket/src/number.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/racket/src/n
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt wrote:
> To make 3m work right, "src/racket/gc2/sighand.c" needs a
> __FreeBSD_kernel__ on line 128:
>
> #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
> defined(__NetBSD__) || defined(__OpenBSD__)
>
> Does that avoid the bus error
On Thu, 28 Apr 2011 19:37:42 -0600, Matthew Flatt wrote:
>
> > But then I had a bus error, as before.
>
> A stack trace might be helpful. Otherwise, I guess I'll have to set up
> a kFreeBSD virtual machine.
>
I couldn't find any documentation on fpsetmask so far, but here is a
traceback from
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt wrote:
> I've pushed fixes for kFreeBSD, so let me know if you encounter further
> problems.
>
The latest commit (b5f86a26...) seems to fix all the remaining problems
I know about. The current git master builds, build collects, and passes
minimal
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt wrote:
> I've pushed fixes for kFreeBSD, so let me know if you encounter further
> problems.
It seems the updates (gcc?) on kFreeBSD (i386 and amd64) cause a
regression: I am getting a segmentation fault from "make gracket3m" with
current git mast
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt wrote:
> Maybe someone decided that SIGSEGV is the right signal after all for an
> mprotect() violation (which Rackets catches as a write barrier) instead
> of SIGBUS.
This seems to be about right. In Debian/kFreeBSD stable (squeeze), one should
On Tue, 10 May 2011 00:14:42 -0300, David Bremner wrote:
> On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt wrote:
> > Maybe someone decided that SIGSEGV is the right signal after all for an
> > mprotect() violation (which Rackets catches as a write barrier) instead
> > of S
On Tue, 10 May 2011 23:58:07 -0300, David Bremner wrote:
> I don't claim to understand all the implications yet, but the following
> patch seems to work, i.e. catching both SIGSEGV and SIGBUS with the same
> handler.
As a followup, I talked a bit more to the Debian/kFreeBSD dev
Hi, it's the debian guys again and their wacky architectures.
The build on the s390x (64 bit version) seems to hang at the following
place
/usr/bin/make ../gracket3m
make[6]: Entering directory `/home/bremner/racket-5.2.1+dfsg1/build/gracket/gc2'
../../racket/racket3m -cqu
/home/bremner/racket-
On Mon, 27 Feb 2012 09:46:43 -0700, Matthew Flatt wrote:
> My guess is that something is going wrong with the GC's write barrier.
>
> In "src/racket/gc2/newgc.c" around line 2677, if you change 1 to 0 in
>
> newgc->generations_available = 1;
>
> does the build make further progress?
It doesn
Hi All;
We're currently trying to figure out the right way to handle a name
conflict in Debian between racket and an rss aggregator named
planet-venus.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685
I don't use the command /usr/bin/planet myself, so I was wondering if
anybody c
26 matches
Mail list logo
