I am looking for npruntime/npapi plugin samples which were earlier present under "https://hg.mozilla.org/mozilla-central/file/2255d7d187b2/modules", But it looks like these samples were removed from the mozilla-central repository possibly for all good reasons,
Where can I find these samples and process to compile those under Ubuntu/Linux environment.
You can get NPAPI headers and samples from https://code.google.com/p/npapi-sdk/
Building sample process:
check out the repository.
$ svn checkout http://npapi-sdk.googlecode.com/svn/trunk/ npapi-sdk-read-only
build basic sample.
$ cd npapi-sdk-read-only/samples/unix-basic
$ make
Related
Steps:
Installed coverity
Configured compiler
cov-configure --javascript
cov-configure --cs
I am stuck at the build step of cov-build. Yarn is used to run and configure the service. But I am not sure what coverity wants here.
I tried a couple of npm run commands, every time end up getting this:
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
I also tried different compilers, but no luck.
What should be done in this case?
You need to do a file system capture for Javascript files. You can accomplish this by running cov-build with the --no-command flag.
cov-build --dir CoverityIntermedediateDir --no-command --fs-capture-list list.txt
Lets break down these commands:
--dir: intermediate directory to store the emitted results (used for cov-analyze later).
--no-command: Do not run a build command and to look for certain file types
--fs-capture-list: Use the file that is provided to specify which files to look at and possibly emit to the intermediate directory.
A recommended way to generate the list.txt file is to grab it from your source control. If using git run:
git ls-files > list.txt
I want to also point out that if you don't have a convenient way to get a file listing in order to use the --fs-capture-list command you can use --fs-capture-search command and pair that with a filter to exclude the node_modules directory.
The coverity forums have some useful questions and answers:
Node.js File system capture
Really, the best place to look is at the documentation. There are several examples of what you want to do in their guides.
I am new to calabash and working with it since past few months. When I execute the pre-defined step I get below path "# calabash-cucumber-0.11.4/feature/step-definitios/calabash-steps.rb"
I know its associated with my workspace somehow but I am not able to get this calabash-steps.rb file (neither in my system nor on Google)
Can someone help me in getting this file. I just wanna see how the implementation is done for the step.
A lot of thanks in advance!
Those files will be in the gems library itself. If you are on a mac, open a terminal and type
which calabash-android
The output will be a file path to where the gem is installed. If you look there there will be the files you are looking for.
If you are on windows you can run
gem env
and it will output a bunch of info and the GEM PATH section is the bit you want.
Mine looks like this
GEM PATHS:
C:/Ruby193/lib/ruby/gems/1.9.1
If you're getting started writing custom steps then you should check out the docs - https://github.com/calabash/calabash-ios/wiki/03-Writing-custom-steps
The file can be found in the Calabash iOS repo.
One of the of the problems with using predefined steps is that you can't edit them (easily).
If you want to explore the predefined steps (edit them, set break points, etc.), I suggest copying the calabash_steps.rb file into your local features/step_definitions directory and updating your features/support/env.rb file to not load the predefined steps from the gem.
This code comment in the features explains how to not include the predefined steps shipped with the Calabash gem.
If you use bundler + Gemfile (which we strongly recommend), you can find where the gem is installed:
$ bundle show calabash-cucumber
As an aside, you should update to the most recent version of Calabash iOS (0.14.3 as of this writing).
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
I would like to know if that's possible to declare a dependency to a library via GIT. My usecase is simple, I have some tools, that I would like to share between my projects, but I don't want to add them to haxelib (because this tools are not really interesting for someone else). Otherwise, I would like that people who will install my lib, get my tools too (without the need to use manually haxelib git ....).
Is it possible ? (I didn't read anything about that in documentation)
This is currently not supported in Haxelib, though it would be great to see, and not too hard to implement. If you're interested in working on Haxelib, it's not too hard, open an Issue on the Haxelib Github project and perhaps we can help you figure out how to contribute.
One alternative if you need a workaround is to create a "run" script, so you can do:
# Run the project's run.n file
haxelib run mylib
# Your "run.n" file could have a "setup" command that runs
# the "haxelib git" commands for the user
haxelib run mylib setup
It's a bit of a hack, but it could work in the interim. See http://haxe.org/doc/haxelib/using_haxelib#runnable-project for more info on how to have a run script for your haxelib.
As of 2016, this is now natively supported by Haxelib. You can see the PR here.
As mentioned in the PR, you can use the one of these two:
haxelib git:<url> (similar to cloning the git repository).
haxelib git:<url>#commit-ish (clones to a specific commit, specify the hash.
Shameless plug, BUT you can checkout my http://lib.haxe.org/p/hxmlinstall/
1. Add -lib hxmlinstall to your hxml.
2. Annotate your tools like so
#git https://github.com/you/tools commithash
-lib forkedlib:git
On build you will be warned if your lib repository is not on specified %commithash%
Run haxelib run hxmlinstall to install / pull / update all dependencies
I have a little problem.
I wanted to install buildbot so I followed the doc: http://buildbot.net/buildbot/docs/latest/Installation.html
For the master.cfg, I just copy the sample.
But when I start BuildBot I got that :
gitpoller: repo poll failed
....
No such file or directory: \'/tmp/gitpoller_work
I don't know why ?
If you have an idea,
thanks.
In short, configuring buildbot is more involved that just copying a generic config file. The master.cfg.sample is merely meant to provide a rough starting point for configuring your buildmaster and slaves. In other words, you're going to have to provide the information about your actual projects, repositories, and build environments in the config file.
If you're having trouble with the configuration, the doc is pretty comprehensive. I only had a few problems with stuff more obscure than the doc can answer, at which point I turned to the nice folks - a number of their developers - on their IRC channel (#buildbot on freenode), who were very helpful.
The directory that the git poller seems to be looking for seems quite strange (it has ` and \ and /). Personally (and matching the current sample config), I prefer using a directory under the master directory. The current sample config uses workdir='gitpoller-workdir'. If you have more than one GitPoller, you will need to use more than one directory, currently.
Update: With buildbot 0.8.7, there is a new GitPoller, that doesn't require multiple workdirs, and defaults to something sensible. If using 0.8.7+, you should just not specify workdir.