I tried to build Spring from source using: ./gradlew install
It fails with:
/home/dk/.gradle/caches/1.12/scripts/build_68eiq5ktt9740a7l1bofab8a9a/ProjectScript/no_buildscript/classes/build_68eiq5ktt9740a7l1bofab8a9a$_run_closure27_closure138_closure139_closure140_closure141_closure142_closure143_closure144_closure146_closure147.class (File name too long)
This was reported earlier but should have been fixed in Gradle 0.9.1. However I still have this error with Gradle 1.12. I'm using Ubuntu 14.04 with an ext4 filesystem.
What's the recommend workaround for this?
It seems that this error occurs when using an encrypted home directory. I've set GRADLE_USER_HOME to an unencrypted directory and everything works fine.
The only solutions I'm aware of are to use a filesystem that can handle long filenames, or to ask the Spring folks to change their build script so that it doesn't use such deep nesting levels (10 seems way too much). In any case, this question should be brought to attention of Spring developers (e.g. in their JIRA). I'd be surprised if none of them used Ubuntu/ext4.
I think it is not too late to post it back to this thread. Based on the answer provided by Dennis, Here is what needs to be done to ensure you are able to compile Spring Source on encrypted files system.
$ sudo mkdir /opt/gradle/home
$ sudo chown -R $USER:$USER /opt/gradle/home
$ export GRADLE_USER_HOME=/opt/gradle/home # Probably add it to .zshrc or .bashrc files
Related
I'm beginning with Spark so not really sure where my problem is and looking for a helpful hint here. I'm trying to run Spark (pyspark) on a windows 7 machine as an admin but it does not seem to be working (I still get the WindowsError 5). See image below:
I've downloaded the file (release 1.2.0 with pre-built for Hadoop 2.4 or later), unzipped it using tar via command line and set IPYTHON=1 before calling bin\pyspark. When I call it, pyspark runs but I get the error below as per image.
When I try calling certain SparkContext objects, I get name 'sc' is not defined.
I've got python 2.7.8 installed, Spyder IDE and am in a corporate network environment.
Does any one have a clue what could be going on here? I've looked up a few questions such as Why am i getting WindowsError: [Error 5] Access is denied? but could not find a clue.
Briefly:
I had what should be the same problem. For me, it was that the *.cmd files in the $spark/bin directory weren't marked as executable; please try to confirm by:
right clicking on pyspark2.cmd and:
properties / security tab then examine 'Read & execute'
I found the workaround on another site, that recommended downloading hadoop-winutils-2.6.0.zip (sorry don't have a link). Here is an example of the cmd to use (after moving to proper directory):
t:\hadoop-winutils-2.6.0\bin\winutils.exe chmod 777 *
I did need to run the chmod 777 cmd to make the /tmp/hive writeable too.
good luck!
(... new here - sorry for the poor formatting)
(update: Matt thanks for fixing formatting issues!)
root cause: the tar program i used on windows via tar -zxf <file.tgz> did not apply
the proper attributes to the extracted files. in this case the 'executable' files
weren't properly set. yeah, maybe i should update my version of cygwin.
I manged to get my spring boot website online on Heroku. But I also use wkhtmltopdf to create a pdf. This works locally but now I have some problems.
Offline it works as follow :
ProcessBuilder pb = new ProcessBuilder
("cmd.exe",
"/c",
" cd C:\\Program Files\\wkhtmltopdf\\bin && wkhtmltopdf.exe "
+ "http://google.com C:\\MainWebApps\\TestApp\\src\\main\\resources\\userstorage\\Google2.pdf");
But how do I install this on Heroku?
Where do I store the temporarily html page so I can create a pdf from it ?
And where is wkhtmltopdf installed on Heroku ?
Can I call the wkhtmltopdf with a processbuilder on heroku?
EDIT
So after the comment of ceejayoz I googled a bit more and did find some interesting stuff.
So for Compile the binaries on Heroku I used this:
heroku run /bin/bash
Then I did a curl of wkhtmltopdf like this:
curl -O http://download.gna.org/wkhtmltopdf/0.12/0.12.0/wkhtmltox-linux-amd64_0.12.0-03c001d.tar.xz
Then I tried to extract it on the server but without success:
$ tar -xjvf wkhtmltox-linux-amd64_0.12.0-03c001d.tar.xz
tar (child): wkhtmltox-linux-amd64_0.12.0-03c001d.tar.xz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
EDIT2
I also found this https://github.com/dscout/wkhtmltopdf-buildpack on github.
So I did following :
heroku buildpacks:set 'https://github.com/heroku/heroku-buildpack-multi.git'
echo 'https://github.com/dscout/wkhtmltopdf-buildpack.git' >> .buildpacks
This created a file named .buildpacks but how do I proceed from there on ?
I also found this post but vulcan is deprecated and uses ruby
Using Wkhtmltopdf with Nodejs on Heroku
Can somebody provide me with good information because I am completely stuck with this?
You actually have two problems that you need to solve -
How to install/invoke the executable
How to handle the generated .pdf
Assuming you have the basics of Heroku deployment (push to the Heroku git remote), for #1, #ceejayoz is right - check the binary into your git repository. For example, under a ./bin directory. The root of your project (where the Procfile is) will be your working directory, and you should be able to invoke the program with ProcessBuilder using relative paths.
Caveat - since it looks like you are developing on Windows, you will need to pay attention to ensuring both platform-specific binaries are available, and add some logic to know which one to invoke (for example, by setting/checking a specific environment variable).
I recommend against trying to build with a custom build pack - you will spend a lot of energy for little to no benefit. Aside from the platform issue, you don't need to rebuild a third party tool when your code changes...
The second problem is that you can't leave the generated PDF in place. It will go away when the dyno is restarted (see https://devcenter.heroku.com/articles/dynos#ephemeral-filesystem). Thus, the first thing you should do when the process completes is move the generated file to an external storage service (Amazon S3 is a good starting point).
Hope this helps.
You might want to use wkhtmltopdf-binary. With that solution, you do not need to put wkhtmltopdf executable into your VCS. You can use it for example with Maven or Gradle.
OS: Ubuntu 12.04
Go version reporting: 1.1.1
Action:
I have configured the .profile to contain the following lines:
export GOPATH="$HOME/workspace"
export PATH=$PATH:$GOPATH/bin
I have ensured that they are set in the go configuration by running "go env". However when I try to run the command, the screen reports as shown in the image below:
Possible constraining issues:
1) The box originally had Go v1.0 on it and I upgraded it to go version1.1.1, not sure that should mean anything...but if there is some twin configuration madness at work that may explain the fact it's not working despite the path being set.
2) I had the export commands in the .profile file but I see some threads indicate to put it in .bashrc, trying in either still gives the same problem.
Do I need to uninstall go 1.0 ? I just assumed version 1.1.1 would over ride it but that could be wrong. Ideally I wanted to uninstall go entirely and then install version 1.1.2 but I couldn't find anything at golang.org on uninstalling assuming that does solve the problem.
Thanks in advance for any assistance.
As the commenter above stated, you should not use sudo with go get. When you do, you have the root user's environment (which doesn't have your GOPATH) and any files or directories it creates won't be editable by your user. In the past, the go get command would not warn about not having a $GOPATH and so it was easier to get tripped up by this.
To fix your permissions, run the following command to change ownership back to your user:
sudo chown -R "$USER:" "$GOPATH"
You should only ever need to run a plain go get because you can (and should) set your $GOPATH to be a directory you can control. Be sure to read the How To Write Go Code and in particular its discusson on GOPATH.
What: I've a shell script that I'd like to distribute to my LUG.
I believe that a debian package will be the easiest way to distribute it. I want to create a .deb file for the script in this repository
Where: I want it to be placed in some directory like /usr/local/bin so that it is easy to execute and maybe create some symbolic links
Problem: How to write make file for it and/or other files and folders required to do that. I researched a lot when I tried to do it couple of months ago but no luck then. Here are the files from my previous attempt Now I'm trying to pack this for a tutorial on shell script in my LUG and facing similar situation again.
I'll be really glad if someone can be patient enough to guide me through it.
Any kind of resources or details will be much appreciated.
PS: I also intend to port the script to perl soon.
As mirabilos said, you should at least have a look to the packaging-tutorial written by Lucas Nussbaum, the current Debian Project Leader. You can install it directly from a Debian repository:
# apt-get install packaging-tutorial
Then, open and skim the PDF located at /usr/share/doc/packaging-tutorial/packaging-tutorial.pdf. After skimming it you'll have the basic knowledge needed to understand the structure of a Debian package.
Now let's get our hands dirty. mv your script to a new directory. The name of the directory must follow the nomenclature upstreamname-*version*.
rul#helicon:/tmp/a$ mkdir script-0.1
rul#helicon:/tmp/a$ mv script.sh script-0.1
cd to the directory where your script is and run dh_make --createorig. Choose single binary. You'll now have a debian/ directory with lots of file in it. This files are the ones you need to make your package. In your case, most, if not all, of the *.ex files are safe to be removed. Read and modify when needed the remaining files.
Now let's write the core of our package. You want to install a script in /usr/local/bin. The good news is that there is already a program that does that for you. You just have to specify the file name and where to put it. This program is dh_install. It has a very complete man page. After reading it, you should now understand that you have to create a install file in the debian/ directory.
rul#helicon:/tmp/a/script-0.1$ echo "script.sh usr/local/bin/" > debian/install
Here you have a real example of this file usage.
That's it! You have all you need to build your package. cd to the root directory of your package and run dpkg-buildpackage. If all went well, you'll have your fresh new .deb in ../.
You really should have a look at, in this order, the inofficial packaging tutorial, the Debian New Maintainers' Guide, Debian Developer's Reference and Policy. (The order is also increasingly dry, and reversed for formalness.)
It may take two days or so, but is really worth it.
Also, look at other small packages shipping only scripts, or other mere “file installers” (like php-htmlpurifier, first example I remembered while writing this).
If your package will only have a single file (or small number of files) in it, going through the full Debian toolchain might be overkill.
For packaging single files, I recommend you use the equivs tool. Install the equivs package, then run equivs-control to create a template file.
Edit the template file (give your package a name, version number etc.).
Add the name of your script to the Files: attribute in the template, for example:
Package: my-awesome-script
Version: 4.2
Files: my-awesome-script.sh /usr/local/bin
Section: misc
Priority: optional
Standards-Version: 3.9.2
Maintainer: Me <me#gmail.com>
Description: An awesome script doing stuff
Lorem ipsum etc. pp.
Put the script file alongside the template file.
Run equivs-build which will create your Debian package.
This is much easier for these simple cases than anything else – and the package that you get is standards compliant without resorting to any hacks or jumping through hoops.
for pre install, write your script in file DEBAIN/preinst;
for post install, write your script in file DEBAIN/postinst;
Use checkinstall or fpm to build your packages in minutes not hours or days!:
sudo checkinstall --fstrans=yes --install=no -D --pkgname=script \
--maintainer='Name <name#domain.tld>' --pkgarch=all --pkgversion=0.1 \
--nodoc cp script.sh /usr/local/bin
fpm -s dir -t deb --prefix /usr/local/bin -n script -v 0.1 -a all ./script.sh
Note: checkinstall requires dpkg/dpkg-deb (only works on Debian/Ubuntu), fpm is platform independent but requires ruby.
I'm trying to get the Mercurial Eclipse plugin to use my MacPorts version of Mercurial (since I need to access a repo that's using the new dotencode format), but I can't get the Mercurial preference page under "Team" to save the changes. It will recognize "/opt/local/bin" as a valid directory for the "hg" executable, but when exiting the workspace the changes don't appear to be saved properly, since the next time I launch Eclipse, the old "/usr/local/bin" is back there again.
Has anyone else had problems with this? "/opt/local/bin/hg" is a symlink to "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/hg" on my system, but that file also contains a shebang ("#!") with the same path (duh!). Is that known to cause any problems on anyone else's machine?
Edit: Symlinking /usr/local/bin/hg to /opt/local/bin/hg works, but this doesn't fix the cause of the problem.
There are no errors being logged in the Eclipse Error Log view, other than "abort: requirement 'dotencode' not supported!" on startup. I.e. no errors on validating the settings or when saving the workspace.
Do you have another version of hg in /usr/local/bin? If not or if you no longer need it, you might be able to work around the issue by making a symlink:
sudo ln -s /opt/local/bin/hg /usr/local/bin/hg
sudo chmod -h g+rx,o+rx /usr/local/bin/hg