build process bugs
jl
ran into several problems. The unsolved two first:
a) The bugtracker does not work with my ff 3.6.8 (when opening a new
ticket, the form says "Item 1" as "repository", click on select box
and the item vanishes and the UI freezes)
Since my connection is very bad ATM, it could just be some timeout
occurring, but that is just a guess.
b) Installing node 0.2.0 fails with
arg[0] directory does not contain a wscript file
Error running: ./configure --prefix=/usr/home/ampify/ampify/environ/
local cwd=/tmp/amp-build-\ 801582eb/node
!! ERROR: Building node 0.2.0 failed
*** Error code 1
Stop in /usr/home/ampify/ampify.
Another two issues I'd classify as bugs, but one can work around them
(as I did):
c) The name of the GCC-binary is hardcoded ("gcc"), though not on
every system "gcc" is a GCC > 4.0 - for example on mine, "gcc" is a
GCC 3.x and "gcc44" is the GCC ampify wants. To "fix" this, I can
either rename my GCC 3.x (bad idea, that's the one used by the system
itself) or do weird path-acrobatics (works, but *will* lead to
confusion one day and is questionable from a security point of view)
d) The docs say that a "java" is required... apparently openjdk7 is
too new, since the version is checked for equality and 1.6 is actually
expected.
jl
tav
And, wow, after years of this list being created (initially named
plexnet), we finally have a first post!
> a) The bugtracker does not work with my ff 3.6.8 (when opening a new
> ticket, the form says "Item 1" as "repository", click on select box
> and the item vanishes and the UI freezes)
> Since my connection is very bad ATM, it could just be some timeout
> occurring, but that is just a guess.
It works fine here on Firefox 3.6. Is it still not working for you? If
so, here's the issue tracker for the issue tracker:
* http://github.com/280north/issues/issues
> b) Installing node 0.2.0 fails with
> arg[0] directory does not contain a wscript file
> Error running: ./configure --prefix=/usr/home/ampify/ampify/environ/
> local cwd=/tmp/amp-build-\ 801582eb/node
> !! ERROR: Building node 0.2.0 failed
> *** Error code 1
> Stop in /usr/home/ampify/ampify.
How bizarre. For starters, the build directory should be:
/tmp/amp-build-801582eb/
And not:
/tmp/amp-build-\ 801582eb/
It's defined by the following line of code:
'/tmp/amp-build-%s' % sha1(ROOT).hexdigest()[:8]
So I'm not sure how a space could ever be a part of the path??
Secondly, there should definitely be a file at this path if the
download/untar of the node distfile worked:
/tmp/amp-build-801582eb/node/wscript
What output do you get for `ls /tmp/amp-build*` and for `ls
/tmp/amp-build*/node/*` ?
> c) The name of the GCC-binary is hardcoded ("gcc"), though not on
> every system "gcc" is a GCC > 4.0 - for example on mine, "gcc" is a
> GCC 3.x and "gcc44" is the GCC ampify wants. To "fix" this, I can
> either rename my GCC 3.x (bad idea, that's the one used by the system
> itself) or do weird path-acrobatics (works, but *will* lead to
> confusion one day and is questionable from a security point of view)
Thanks, I've now replaced the single place where 'gcc' was hardcoded
in amp build with:
os.environ.get('CC', 'gcc')
However, I'm not sure if all the build scripts respect $CC and friends.
I generally tend to add `~/.local/bin` to the local user $PATH and
symlink appropriate versions there. I don't see any security downsides
to this, but am happy to be proven wrong =)
I guess the ideal solution would be to enforce all dependencies to
respect $CC? Or is there a better alternative?
> d) The docs say that a "java" is required... apparently openjdk7 is
> too new, since the version is checked for equality and 1.6 is actually
> expected.
Good catch, thanks. Should be fixed now (assuming openjdk7 has the
same output format for -version).
--
love, tav
plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
Jan Ludewig
> And, wow, after years of this list being created (initially named
plexnet), we finally have a first post!
is *moderated* ;)
[a]
> It works fine here on Firefox 3.6. Is it still not working for you? If
> so, here's the issue tracker for the issue tracker:
> * http://github.com/280north/issues/issues
It still does not work for me - I might file a bug report in the
tracker for the tracker...
[b]
>> b) Installing node 0.2.0 fails with
>> arg[0] directory does not contain a wscript file
>> Error running: ./configure --prefix=/usr/home/ampify/ampify/environ/
>> local cwd=/tmp/amp-build-\ 801582eb/node
>> !! ERROR: Building node 0.2.0 failed
>> *** Error code 1
>> Stop in /usr/home/ampify/ampify.
>
> How bizarre. For starters, the build directory should be:
That was just formatting fuckup, the "\" was introduced by me to
indicate a line-break in the mail but I guess gmail reformatted that
again..
> Secondly, there should definitely be a file at this path if the
> download/untar of the node distfile worked:
>
> /tmp/amp-build-801582eb/node/wscript
>
> What output do you get for `ls /tmp/amp-build*` and for `ls
> /tmp/amp-build*/node/*` ?
I removed /tmp/amp* and restarted, here is the output:
>> Installing node 0.2.0
## Unpacking node-0.2.0.tar.bz2
## Running: ./configure --prefix=/usr/home/ampify/ampify/environ/local
arg[0] directory does not contain a wscript file
Error running: ./configure
--prefix=/usr/home/ampify/ampify/environ/local
cwd=/tmp/amp-build-801582eb/node
!! ERROR: Building node 0.2.0 failed
%ls /tmp/amp-build-801582eb/node/wscript
/tmp/amp-build-801582eb/node/wscript
%cd /tmp/amp-build-801582eb/node
%./configure --prefix=/usr/home/ampify/ampify/environ/local
Checking for program g++ or c++ : /usr/bin/g++
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/local/bin/ar
Checking for program ranlib : /usr/local/bin/ranlib
Checking for g++ : ok
Checking for program gcc or cc : /usr/local/bin/gcc
Checking for gcc : ok
Checking for library dl : not found
Checking for library kvm : yes
Checking for library execinfo : not found
/tmp/amp-build-801582eb/node/wscript:169: error: Install the
libexecinfo port from /usr/ports/devel/libexecinfo.
After installing libexecinfo, configure succeeds when called from
within the correct directory but make still fails with the error
above.
I guess I will just leave the rest of the setup/debugging to you, tav,
after all it's your buildhost =)
You'll receive access coordinates in a private mail.
[c]
> I generally tend to add `~/.local/bin` to the local user $PATH and
> symlink appropriate versions there. I don't see any security downsides
> to this, but am happy to be proven wrong =)
I prefer the (usually) read-only mounted partitions that carry
system-tools (/bin, /sbin, /usr/bin, /usr/sbin) to come
before /usr/local in the path so that nobody can inject "alternative"
versions of standard tools by placing
them in the potentially less secured /usr/local tree. ("cp /bin/rm
/usr/local/bin/ls; rehash; ls *.py")
> I guess the ideal solution would be to enforce all dependencies to
> respect $CC? Or is there a better alternative?
I'd expect them to do that anyway, but maybe I'm just spoiled by 15
years of "make".
jl