I’m looking for help getting these building so want to compare OS and system configurations to see if I can get them going.
1 Like
Yeah dude I did it all on my “Ubuntop” and everything worked smoothly 
2 Likes
you are talking about compiling from source - don’t you …?
I myself just used the mockup-version (ubuntu 14.04 64bit) - but i could try the “real stuff” tomorrow evening i think 
(In the mean-time I encourage you to watch the trololo-man I had to think of when reading about the trello-board in the safepress-threat 
Trololo... The Full Original Version. - YouTube )
2 Likes
Oh, OK. Yeah I didn’t do all that 
1 Like
I’ve been meaning to try to start compiling these for awhile, now seems like a good time! I’d love to try to walk through and troubleshoot it with you.
Currently running Debian Jessie 86_x64
What problems have/are you running into?
EDIT: Are you planning on compiling it against mock or actual routing?
EDIT2: Just finished compiling dns_example successfully. Only minor hiccup was at $ npm run electron-rebuild - which failed (at grunt rebuild) - but had no impact on the compiled binary.
2 Likes
Great @smacz We’re on same Debian x86 Jesse, though our sources lists will be different as I’ve tweaked mine a bit.
Please let me know what versions of nodejs and npm you have. I’m using real routing so I can run against a local vault network as in the 31 Aug Dec Update, but have also compiled the vaults myself.
dns_example
I hit two different problems with the dns_example and have got different results at different times, some inexplicable, some due to trying latest version of nodejs rather than the Debian packages.
BTW building alone doesn’t count… I managed that with both - they have to work too! 
Although I can’t currently compile dns_example using latest nodejs.
You can see the two states I achieved with dns_example on github as I raised an issue. The first one is probably similar to yours - fails to rebuild electron but completes (lots of version warnings too). The second, “UPDATE” comment, is with latest nodejs / npm and fails early, so no build.
I’m most interested in the browser add-on though, so I’d like to know his you get on with that.
safe_firefox_addon
My safe_firefox_addon locks up Firefox though an earlier one seemed not to, (unless I didn’t install it properly).
Your input has already helped - at least I know you are getting similar results on dns_example with Debian packages… unless of course your version also works! Give it a try. If it doesn’t work straight off I have something else you could try. You can of course try both with the vaults provided by MaidSafe, or compile those yourself - but if you do that you may need delete the vaults config file or they won’t find each other because the file format has changed.
Thanks for your help. Let’s beat this! smile
1 Like
Last time I tried it was 2-3 weeks ago and bower was not updated to work with recent nodejs version that use python 3.
Bower worked only with nodejs 0.10.41 or below if I remember correctly and can only be build with python 2.7 due to incompatible syntax with python 3. That make things a little complicated.
EDIT: It may not be bower but something else dependencies. I can’t remember clearly.
2 Likes
Sounds like we need a reference build platform from MaidSafe, full spec/versions or a docker image?
1 Like
Ran into the same problem you did initially. My notes:
Complains about a legacy
nodebinary. The version I have is0.10.29, and the mimimal that this requires is apparently0.10.40. That may be a problem as the Jessie repos are only populated up to0.10.29andapt-get install nodejsreturnsnodejs is already the newest version.
Per this thread there’s a script that I can run to install the latest binary.
curl -sL https://deb.nodesource.com/setup_0.12 | sudo bash -
[...snip...]
sudo apt-get install -y nodejs
[…snip…]
>#### A reminder that it's a very bad idea to `curl | sudo bash`. You are running a script you did not check with root privileges. It's always better to download the script, read through it, check for malicious commands, and after that, run it. ####
But it looks like you already did that and the script failed at `node-gyp rebuild`. I'll have to try to catch up to you tonight. I'll check in just as soon as I can!
1 Like
okay - long day - since @smacz is on it and has the same OS you have i won’t test it on my machine and just go to bed really early today =)
good luck figuring out what the problem is!
It seems that the node-ffi module is not yet compatible with the latest version of nodejs. There is an issue already raised for this. For now the example seems to work fine on nodejs 0.12 with mock routing feature. There seems to be some problem when trying to connect with local network. have raised an issue for the same. It would be better to stick to the released binary version at this point of time, until we get the tip of tree compiling and tested.
If you find it difficult to juggle between different versions of nodejs, try nvm.
4 Likes
@Ghaunt I actually had no trouble with bower using nodejs version 0.12.X
@happybeing as above I’m using nodejs version 0.12.X using the aforementioned script to install. npm is 4. something? I don’t remember ATM but can find out. (I have an irrational hatred of javascript so please excuse my ignorance!) Which ones are you running?
I just tried to upload via the app and got a module mis-match error. This was done against the vault binary supplied in the github repo (31 Aug Dev Update IIRC) so - live network. As @Krishna_Kumar pointed out, there appears to be a bug against the live network, but I’m more suspicious that the time difference means that I’ll have to compile the vault with the current versions of the modules. (instead of using something that was built a month and a half ago)
Either way, it didn’t work OOTB with the live network. To keep on going with this, I would ask you to attempt to use mock and see what happens then. IIRC you’re attempting to fiddle with the actual API of the app/plugin so the live/mock difference shouldn’t(?) mean that much to you.
So that means compiling safe_ffi using mock. (There’s a --<something> flag to do so when compiling.) Then putting that into the dns_example/src/scripts/safe_api/ directory before compiling. Also making sure that libsodium is correctly setup… (something in your github comments about not using it correctly?)
During which time I’ll try out the firefox plugin and see what I come up with.
2 Likes
I probably won’t have much time to spend on this for the next few days but have plenty of things to try when I do - thanks @smacz & @Krishna_Kumar
What I would like to achieve is:
- extend safe_ffi to include SAFE REST APIs
- build safe_firefox_addon with it
- be able to create an HTML/JS page that can store/retrieve Structured Data using it
@Krishna_Kumar Does mock routing allow the last one? If it simulates storage and retrieval using conventional files that would be fine.
I’m also interested to build dns_example but it’s much less important to me for now.
2 Likes
@happybeing I got very close to testing my compiled version of safe_firefox_addon, but I discovered that it requires Firefox >= 38.0. Debian only includes Iceweasel 31.X. The addon will accept iceweasel for firefox, but the version is too low (IDK what’s in the backend, but it didn’t want to work when I manually adjusted the requirement). Would you say it’s finally time for me to take this install to Sid???
Also, the other problem I had was during compiling, safe_ffi didn’t produce any file libc_wrapper.{so,dylib}. I did get libsafe_ffi.so, but no .dylib. First off, how can I generate the .dylib file? Also, is libsafe_ffi the new libc_wrapper? If not, how do I generate libc_wrapper?
Just using the binary for the time being, huh? Ditto.
1 Like
You will not get a dylib in Linux, In linux it’s the .so file you want which is the shared lib. In OSX it’s .dylib which is the shared lib.
Think your query is very much what @happybeing raised in github for the firefox addon. It was updated for the issue. I’ll get the update to explain extensions over to the DNS Example Readme too
3 Likes
I need to check what version of Firefox I’m using on Debian, but it may be from the Ubuntu repo.
As I mentioned, I can build safe_ffi, and the addon, but it locks up my Firefox. I’m ok with the one MaidSafe provided so don’t think it’s a Firefox version issue but I’ll check what I have.
Sorry for slow responses, I’m not getting much time for this just now 
It was like that with me too when I used the libsafe_ffi.so but after trying with libsafe_ffi.a to compile the firefox_addon and added it to firefox it worked fine.
3 Likes
Thanks for the tip - I think I blithely copied both so that might well be the issue! Hope so!
1 Like
Sorry for the delay @happybeing, but here’s where I’m stuck so far.
- I built
safe_firefox_addonwith themocklibsafe_ffi.so - I compiled
firefox 40.0from source - I downloaded the binary for
dns_example
I ran firefox from the shell to see the output to try to find out where the error was - I actually got the same one that you had, the whole not displaying the content and then freezing epidemic.
After “uploading” my data (the example page via the dns_example) and then installing the compiled safe_firefox_addon into firefox I got:
FfiError::DnsError → DnsError::ClientError → ClientError::UnsuccessfulEncodeDecode
This looks like a Rust error to me. However, I’m still not knowledgable enough about the source code to find out what went wrong where.
As for the libsafe_ffi.a comment above, I tested this three times
- Only
libsafe_ffi.so→ Aforementioned error - Only
libsafe_ffi.a→ Addon didn’t even work (I expected that) - Both → Same error
So that’s where I’m stuck. Have you been able to run firefox from the shell to figure out what error you were receiving?
1 Like