(This is a duplicate question from ServerFault, but seems that is not a right place to ask and it got downvoted for no reason, so I re-post here)
Basically I am setting up an OpenDaylight controller for my SDN. And I am trying to install an application - Defense4All, which from the documentation, will communicate with the controller host.
I am reading the installation guide of it in https://wiki.opendaylight.org/view/Defense4All:Installation_Guide , but it seems that the link of getting binary of Defense4All is dead, and I can't find a way to get the binary of Defense4All. I managed to compile from source but I have no idea how to proceed after successful build. Anyone idea?
I finally fixed the issue. Hope someone feels useful.
I managed to compile the source with mvn install, which it successfully did all the compilation but it did not give me a binary. But I am able to do so using mvn package.
To be specific, under directory dfapp after unzipping the source zip file:
vm:~/defense4all-release-helium-sr3/dfapp$ mvn package
After a long build, you will find the binary file in dfapp.aggregate/target
Make sure you allocate enough memory (say, 2048) to the VM or it will suffer from insufficient memory error.
There are also some dependencies such as git and rpm, it varies with your machines, so take notice of the error log.
Related
I have been trying to build the desktop client for about a week now so that I can dig in and try to mess with some theming and turn off some features I wont be needing. In the process I have run into numerous issues and have managed to resolve them in one way or another. I have a VM running openSUSE and I have downloaded the source file ownCloudClient-2.3.2.tar.xz file and unzipped it all into my home/jwarren/client folder. I then ran:
cd admin/win/docker
docker build . -t owncloud-client-win32:
Which I was able to get through. Now I am on the second command:
docker run -v "$PWD:/home/user/client" owncloud-client-win32: \
/home/user/client/admin/win/docker/build.sh client/ $(id -u)
Here I am getting almost to the end and then I receive this error message which I cant figure out how to resolve.
CPack Error: Problem running NSIS command "user/bin/makensis"
CPack Error: Problem Compressing Directory
Can anyone help me out with this? Or maybe point me in the direction of better instructions for the ownCloud Desktop Client theming. I noticed that once you get it installed properly there is no instructions explaining where anything is to edit.
I wrote a comprehensive guide to build the Windows client using the cross-compilation toolchain in the Dockerfile some time ago in ownCloud's central: https://central.owncloud.org/t/error-using-docker-to-build-the-windows-client/5107/5
What you're probably missing out is the git-submodule initialization; i.e. running git submodule update --init on your unzipped repository. You need these to bundle on the installer some pre-compiled binaries used by the shell integrations.
Also, on a side note, there was some problems last month with mingw toolchain compiler (gcc7) - in case you get some dll error after installing the client with your self-generated installer, refer to https://central.owncloud.org/t/building-the-windows-installer/8403/4 for an snapshot of a fully working Docker image to use instead of your self-built.
About the docs to build your own theme: those can be found in https://doc.owncloud.org/branded_clients/branded_desktop_client/index.html (for enterprise installations of ownCloud) - and for an unsupported version, you can also check the source in
https://github.com/owncloud/client/blob/master/src/libsync/theme.cpp for some hints about what settings can be overwritten from there.
I've found the "Beginner's Guide to Setup Xuggler" article from here. I was trying to follow the best chosen answer. While going through the steps, I got stuck # "Run ivy from command-line as follows:" I didn't had Ivy at first, so I headed to Ivy's download page, and downloaded from the Snapshot Build section of the site. Then, I tested with both jar files, but while running the command stated in the Beginner's Guide, I'm getting this message: "ivy configuration file not found: ivysettings.xml". So, what did I do wrong, need I follow the "Building from source" section from the site? If so, can you please give me a detailed description of how to do it, I'm kinda new in these things. Long story short, I need to know how o get a legit "ivy.jar" file as stated in the command line of the Guide.
Ok, so I've solved the problem my own way, kind of. So, I'm gonna share it here so that other fellows like me may profit from it. So, what I did was that I (obviously) downloaded Xuggler 5.4. Then, I downloaded its dependencies manually as listed here. Then, on my IDE, I just had to import Xuggler and all of its dependencies which I previously downloaded and BAM, it worked like a charm. So, if any of you are having problem finding those dependencies or have any queries concerning this "unofficial" method of mine, you can contact me via email. I'll gladly help. :)
I don't know from Xuggler, but... the error message said you're missing ivysettings.xml. The message is probably from ivy.jar, so you definitely have that. ivysettings.xml is a required Ivy config file that tells what repositories you want to pull jars from. There may be a default one in the Xuggler distro, but probably not. You need to look at the ivy documentation to get farther. Or, use Maven instead. While I'm not a fan of Maven, for this kind of situation it may be easier.
During my time as a SysAdmin, I have encountered applications that provide no rpm packages to install on redhat-based distributions - only a source tarball. The source tarball does not provide a spec file which would simplify the process of rpm package creation. Instead, the source tarball only provides a bash/ksh/ script which must be executed as root to install the application on the system.
I have tried to create an rpm package which essentially runs the install script to perform the install script. I have also tried to do the right thing by attempting to rpmbuild the package as a non-root user, and modifying the install script as best i can to ensure that the script's install dirs refer to rpm enviromentals/macros. But with a complicated install script that is a few hundred lines long, which also calls other scripts into play... well, I was bound to fail in this endeavour.
Is there a better way to package up such .spec-less source tarballs? Would a better solution be to:
somehow take a snapshot of the system before the application install
install the source tarball with the provided install script
take a snapshot of the system after the installation, and determine the changes/additions made by the installation
put the list of changes/additions in a spec file, and create an rpm package this way?
Any useful/relevant/instructive/amusing/profound input and advice to this problem will be much appreciated.
Thank you in advance
I think the best solution is to request the upstream to provide a spec file for the applications. Another way could be request experience package maintainer to package the application. Or you can probably explore to checkinstall as it tracked the install file using Makefile. If you want to package yourself, you should read this link as it provides explanation and with many examples.
I've seen many scripts like you mention, and I suspect I can tell you with certainty the company selling you these horrible installs.
Your best bet is to request a proper installable package. Read up on why a package is better than a configure;make;make-install and is better than this install.sh nonsense. Armed with that, even if it's talking points, try and get them into the 3rd millennium . It will be hard, but ultimately most rewarding.
Barring that, you will need that package built (and by now you will have read why). Unfortunately, there are some apps and vendors whose payload can't be packaged, because they compile, query the destination host, look for a license, compile a bit more, etc. My bias here is well-honed.
Well I've recently come out of the dark ages and upgraded my GCC from 3.4.4 to 4.5.0 with Cygwin (I use Netbeans 6.8 on Windows for future reference). I tried testing the new compiler by attempting to run a simple program through it. The run failed however, citing that NetBeans "cannot find -lstdc++".
Interesting.
I look in ...
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.0
...where libstdc++.a, libstdc++.dll.a, libstdc++.la, libsupc++.a, and libsupc++.la are supposed to be (they're in that spot in the 3.4.4 folder), and they're not there. I also notice something else: there's a 4.3.4 folder in...
C:\cygwin\lib\gcc\i686-pc-cygwin
which contains these exact files! Good. So I copy them in to the 4.5.0 folder and try to run the program again. This time i'm getting two other errors:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1435: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
and:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1451: undefined reference to `std::_List_node_base::_M_unhook()'
At this point I figured that I was way over my head and decided to come for help before copying and pasting any more files. If anyone could tell me how to get this working, i'd be really appreciative.
(If any solutions involve the command line, please be warned that i'm not well versed in it... you may have to provide extra details that you wouldn't need to to other SO users!)
EDIT: The PATH variables are as follows:
C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Program Files\CVSNT\;C:\cygwin\bin
And yes, the Cygwin installed is the latest from the site.
You need to install version 4.5.0 of libstdc++6-devel.
I am getting the above error message randomly (so far as I can tell) on iPhone projects. Occasionally it will go away upon either:
Clean
Restart XCode
Reboot
Reinstall XCode
But sometimes it won't. When it won't the only solution I have found is to take all the source material, import it into a new project, and then redo all the connections in IB. Then I'm good until it strikes again.
Anybody have any suggestions?
[update 20091030]
I have tried building both debug and release versions, both full and lite versions. I've also tried switching the debug symbols from DWARF with external dSYM file to DWARF and to stabs. Clean builds in all formats make no differences.
Permission repairs change nothing.
Setting up a new user has no effect. Same error on the builds.
Thanks for the suggestions!
[Update 20091031]
Here's an easier and (apparently) reliable workaround. It hinges upon the discovery that the problem is linked to a target not a project
In the same project file, create a new target
Option-Drag (copy) all the files from the BAD target 'Copy Bundle Resources' folder to the NEW target 'Copy Bundle Resources' folder
Repeat (2) with 'Compile Sources' and 'Link Binary With Libraries'
Duplicate the Info.plist file for the BAD target and name it correctly for the NEW target.
Build the NEW target!
[Update 20100222]
Apparently an IDE bug, now apparently fixed, although Apple does not allow direct access to the original bug of a duplicate. I can no longer reproduce this behaviour, so hopefully it is dead, dead, dead.
Troubleshooting steps:
(1) dsymutil deals with debug information so you should probably start with the debug build. Once the problem starts can you run the release build?
(2) Create a new users and work from there to see if the problem follows. If not the problem is most likely a corrupted file in your user's directory.
(3) In my experience most linker problems are caused a permission problem somewhere. (We have to pay for security.) I would repair permissions and see if the problem goes away.
(4) In the extreme you can uninstall the dev tools from the command line:
sudo /Developer/Library/uninstall-devtools --mode=all
However, this won't help if the problem is in your user's directory. In that case, you might need to work under a new user or spend a lot of time tracking down every dev related file in the user directory.