I uploaded a version of gizmod which should have FTBFS bugs fixed and
will build against boost 1.40. It would be nice if someone with a 64-bit
Lucid system (e.g. LiveCD) could check if this bug has been fixed in
gizmod 3.4-0ubuntu2.
--
gizmod in Ibex fails to run on amd64 systems due to bug in bo
Hi James,
Yes sorry for the confusion. I did originally say that, but that was
just my guess without being able to test.
Since then I've learned that either boost 1.36 is required, or python
2.4 is. There's simply no way to make this work with the python 2.5
that's in Ibex's repos, without eith
That sounds preferable to me too.
I don't have time to look into it just now, but I can take a look later.
I don't think it should be a significant change. I keep wondering if
any other packages are dealing with this right now as well?
>From the threads here: http://lists.debian.org/debian-
pyth
On Mon, 2008-11-10 at 15:30 +, Tim Burrell wrote:
> So basically, I'm not sure what the right thing to do is here. It seems
> unlikely that Ibex will push a new version of boost in, or an old
> version of python correct? In that case Is it possible to remove gizmod
> from the amd64 repos? I
Hi,
Now I get
cd /tmp/buildd/gizmod-3.4/obj-i486-linux-gnu/libH && /usr/bin/g++
-DHAVE_CONFIG_H -g -O2 -g -Wall -O2 -O3 -DNDEBUG
-I/tmp/buildd/gizmod-3.4/obj-i486-linux-gnu/libH -I/tmp/buildd/gizmod-3.4/libH
-I/tmp/buildd/gizmod-3.4/obj-i486-linux-gnu -fPIC -Wall -Werror -o
CMakeFiles/H.d
Oh right... yes that's fixed in SVN as well. The -Werror by default is
also fixed in SVN :).
There's a couple other places where that happens with gcc 4.3 I think,
so it might fail again. Was there not a patch for this? How did it end
up building in the first place? Interesting :).
At any rat
Hi Tim,
The error from my PPA build appears to be unrelated to boost.
The code it is complaining about is the ambiguous else clause in
if (BytesRead < 0)
if (errno == EINTR)
return;
else
throw H::Exception("Failed to Read from Inotify Device!", __FILE__,
__FUNCTION__, __LINE__)
I suppose another possibility might be to provide python 2.4 in the
repo, not sure if that's possible either? Technically linking boost <=
1.35 against python > 2.4 is wrong (according to the boost people), so I
guess it's not so much a bug in boost as it is an Ubuntu packaging
issue.
--
gizmod
Hey James,
Yeah unfortunately the bug is with boost and there is no way to fix it
unless the move is made to 1.36. This is why I was wondering if there
was a way forward with this at all?
If not, understandable, given the odd set of circumstances. I don't
mind providing AMD64 debs on the gizmod
On Sun, 2008-11-09 at 21:44 +, Tim Burrell wrote:
> Hi James,
>
> Yes I had to make some source changes to accommodate boost 1.36.
>
> If it's helpful I could push out a new version (3.4.1 perhaps)? Or
> provide a patch set to you? Whatever will be easiest / best for you
> guys is fine by m
Hi James,
Yes I had to make some source changes to accommodate boost 1.36.
If it's helpful I could push out a new version (3.4.1 perhaps)? Or
provide a patch set to you? Whatever will be easiest / best for you
guys is fine by me.
Thanks,
Tim.
--
gizmod in Ibex fails to run on amd64 systems
Hi,
The package does fail to build
[ 1%] Building CXX object libH/CMakeFiles/H.dir/Average.o
cd /build/buildd/gizmod-3.4/obj-i486-linux-gnu/libH && /usr/bin/g++
-DHAVE_CONFIG_H -g -O2 -g -Wall -O2 -O3 -DNDEBUG
-I/build/buildd/gizmod-3.4/obj-i486-linux-gnu/libH
-I/build/buildd/gizmod-3.4/lib
Let me clarify what I did:
Clean Intrepid install (libboost1.34 installed) - gizmod package fails
to run, recompile from SVN stops with boost errors
Intrepid install with libboost1.35 installed from repositories
(proposed?) - same thing as above
Intrepid with libboost1.36 from PPA
(http://ppa.la
Tim,
We can fix this in Intrepid somehow. We need to find out what the fix is
though.
You suggested that a rebuild was fine, but Chistopher is now suggesting that
it fails to build.
I've uploaded gizmod to my PPA at
https://edge.launchpad.net/~james-w/+archive
which will force a rebuild. If
No problem, Time - I'm happy to have gizmod working again, it's a great
program.
I can't offer any advice as to how to get this fixed in Intrepid. I
doubt boost 1.36 will make it to backports, but it's possible a smaller
patch could be pushed. This is almost certainly effecting other packages
as w
Thanks for that Peplin!
I've updated the gizmod svn repo to compile clean with boost 1.36.
Looks like this should be ticket for AMD64 users. Unfortunately I'm not
sure how this affects gizmod's currently broken state in Ibex, being
that 1.36 is a requirement and 1.36 isn't in Ibex.
Are any MOTUs
I had some luck after upgrading to boost 1.36 from this ppa:
http://ppa.launchpad.net/rjmyst3/ubuntu and making a few modifications
to the Gizmod source to compile with the newer library. I've attached a
package build with checkinstall here, if anyone else wants to try it
out.
** Attachment added
I have run into this same bug, and tried to compile from source as
reccomended. I followed up to Bernardo's bug report here:
https://sourceforge.net/tracker/index.php?func=detail&aid=2221145&group_id=139428&atid=743549
.
Chris
--
gizmod in Ibex fails to run on amd64 systems due to bug in boost-1
Hey Bernardo,
Could you either post a message on the gizmod forums or open a new bug
against the documentation, and describe in detail what step(s) when
wrong and where? I think I may know what went wrong already, and
probably has to do with some source changes that were necessary for gcc
4.3 tha
Hello, I am the one who originally reported this problem to Tim.
I am more than willing to help recompiling gizmod to see if the issue
goes away. However, I have been unable to successfully compile by using
the official instructions
(http://gizmod.wiki.sourceforge.net/Compile+from+Source).
Are th
On Mon, 2008-11-03 at 14:33 +, Tim. wrote:
> Hi James,
>
> Unfortunately I don't have confirmation... no one has tried the
> recompile. It's a fairly intensive compile requiring a couple hundred
> megs of dev packages so understandable.
>
> In the interim I've learned a bit more of what's go
Hi James,
Unfortunately I don't have confirmation... no one has tried the
recompile. It's a fairly intensive compile requiring a couple hundred
megs of dev packages so understandable.
In the interim I've learned a bit more of what's going on. I guess the
default in Hardy was python 2.4, and in
Hi,
Thanks for the report, do you have confirmation from someone that
recompiling gizmod fixes the problem? I don't have amd64, otherwise
I would confirm for you.
Thanks,
James
--
gizmod in Ibex fails to run on amd64 systems due to bug in boost-1.34.1
https://bugs.launchpad.net/bugs/293082
You
TEST CASE:
(only affects amd64 Ibex systems)
sudo apt-get install gizmod
gizmod
ACTUAL OUTPUT:
GizmoDaemon v3.4 -=- (c) 2007, Tim Burrell <[EMAIL PROTECTED]>
=-=
gizmod: symbol lookup error: /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1:
undefined symbol: Py_InitModule4
EXPECTED
24 matches
Mail list logo
