Github's linguist is detecting many files in my repos which are vendored, especially JavaScript. I found out that a .gitattributes can be used to configure linguist to ignore several files for statistics count.
But this doesn't work, in any way I try. It seems like it simply doesn't matter whats defined in my .gitattributes. So far, I've tried the following:
deploy/static/js/pdfjs/* linguist-vendored
deploy/static/py/Brython-3.7.1/* linguist-vendored
deploy/static/js/pdfjs/build/pdf.js linguist-vendored
deploy/static/js/pdfjs/web/debugger.js linguist-vendored
deploy/static/js/pdfjs/web/viewer.js linguist-vendored
deploy/static/py/Brython-3.7.1/brython.js linguist-vendored
/deploy/static/js/pdfjs/* linguist-vendored
/deploy/static/py/Brython-3.7.1/* linguist-vendored
**/pdfjs/* linguist-vendored
**/Brython-3.7.1/* linguist-vendored
The result when I run github-linguist --breakdown is always
JavaScript:
deploy/static/js/app.js
deploy/static/js/pagination.js
deploy/static/js/pdfjs/build/pdf.js
deploy/static/js/pdfjs/web/debugger.js
deploy/static/js/pdfjs/web/viewer.js
deploy/static/py/Brython-3.7.1/brython.js
sources/gulpfile.js
What am I doing wrong?
Related
I have faced a problem with Sphinx in Python. Even if I have followed the instructions from https://groups.google.com/forum/#!topic/sphinx-users/lO4CeNJQWjg I was not able to solve it.
I have Docs/source folder which contains:
conf.py
index.rst
RstFiles (the folder which contains .rst files for each module).
In conf.py I specify the abs path in the following way:
sys.path.insert(0, os.path.abspath('..'))
In index.rst I call all the modules from RstFiles folder in the following way:
.. toctree::
:maxdepth: 2
:caption: Contents:
BatchDataContainer.rst
BatchDefaultValues.rst
BatchTypes.rst
And finally, the content of each .rst file is in the following way:
BatchDataContainer
==================
.. automodule:: RstFiles.BatchDataContainer
:members:
When I run sphinx-build I get 2 main errors:
D:\hfTools\Projects\Validation-Source\Docs\source\RstFiles\BatchDataContainer.rst:
WARNING: document isn't included in any toctree
and
WARNING: autodoc: failed to import module 'BatchDataContainer' from
module 'RstFiles'; the following exception was raised: No module named
'RstFiles'
Any ideas what might be wrong cause I have tried different things already and nothing has helped?
If conf.py is located in this directory,
D:\hfTools\Projects\Validation-Source\Docs\source,
and the project's Python modules (including BatchDataContainer.py) are in
D:\hfTools\Projects\Validation-Source\Products,
then you need sys.path.insert(0, os.path.abspath('../..')) in conf.py.
The automodule directive needs to be updated as well:
.. automodule:: Products.BatchDataContainer
:members:
I have been able to install and start a program with CMake (with HDF5) but once I access the "about" drop-down link for said program it crashes with the following error:
python: symbol lookup error: /nobackup/<user id>/program-devel/dist_linux/bin_linux/libprogramDLL.so: undefined symbol: h5lib_MP_h5get_libversion_f_
I believe it is an issue with linking static libraries but I am, unfortunately, quite new to CMake and unable to isolate the root problem. I know that this "symbol" is tied somehow to a libhdf5_fortran.a and this is listed in my Cache with:
$ grep -rnw '/nobackup/<user id>/program-devel/build' -e "libhdf5_fortran"
/nobackup/<user id>/program-devel/build/CMakeCache.txt:234:ToolkitLib_LIB_DEPENDS:STATIC=general;SomeLib;general;libz.a;general;libhdf5.a;general;libhdf5_fortran.a;
I’m not sure if this might be where the problem is or not but this is from the ToolKit file - CMakeLists.txt.
if (${USE_HDF5})
#link_directories (${HDF5_DIRECTORY}/lib)
if (WIN32)
target_link_libraries(ToolkitLib libszip libzlib libhdf5 libhdf5_f90cstub libhdf5_fortran)
else ()
# doesn't seem to work on Linux for some reason....
#target_link_libraries(ToolkitLib libsz libz libhdf5 libhdf5_fortran)
# ... try this ... seems to be getting the shared libs...not the static ones...
# set(HDF5_LINK_FLAGS "-L${HDF5_DIRECTORY}/lib -lz -lhdf5_fortran -lhdf5")
# SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# ... doesn't work either ...
target_link_libraries(ToolkitLib libz.a libhdf5.a libhdf5_fortran.a)
endif()
endif()
The last 4 "target_link_library" elements are in directories I've added to my LD_LIBRARY_PATH (although, I've heard this isn't the preferred approach). There is also a final output line when I issue gmake install that might be relevant:
-- Set runtime path of "/nobackup/<user id>/program-devel/dist_linux/bin_linux/libProgramDLL.so" to "$ORIGIN/"
It seems I fixed my problem by adding a --with-pic on the hdf5 installation bash scripts. I also had to remove a -standard-semantics from the CMAKE_Fortran_FLAGS in the src directory. Those two things along with the help you provided fixed my problem. Thanks a lot Pierre de Buyl!
When setting advanced properties on a program/link to start as another user it is throwing the error:
Sorry - Plasma
KDEInit could not launch 'kdesu':
Could not open library 'libkdeinit5_kdesu'.
Cannot load library /run/current-system/sw/lib/libkdeinit5_kdesu: (/run/current-system/sw/lib/libkdeinit5_kdesu.so: cannot open shared object file: No such file or directory)
I tried to install kdesu using:
[root#nixos:~]# nix-env -qaP kdesu
nixos.kdeFrameworks.kdesu kdesu-5.36.0
[root#nixos:~]# nix-env -iA nixos.kdeFrameworks.kdesu
replacing old ‘kdesu-5.36.0’
installing ‘kdesu-5.36.0’
building path(s) ‘/nix/store/2bn27h5drw0800gk5z2rmwfx78gqbbdc-user-environment’
created 2209 symlinks in user environment
[root#nixos:~]# kdesu
bash: kdesu: command not found
[root#nixos:~]# which kdesu
which: no kdesu in (/root/bin:/run/wrappers/bin:/etc/per-user-pkgs/root/bin:/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
I also tried installing nix-env -iA nixos.kde-cli-tools but that does not work either.
Any suggestions on how to get kdesu installed on NixOS?
As a general rule, unlike many distros on NixOS installing a library directly doesn't work as intended; the application that needs the library won't be able to find it. Instead, the package must declare all it's dependencies.
Packages which have optional dependencies tend to have a way to add them via configuration. You may want to try something like this in /etc/nixos/configuration.nix
services.xserver.desktopManager.plasma5.extraPackages = with kdeFrameworks;
[ kdesu
];
I'm glad to see that you filed an issue on Nixpkgs, because this is not a configuration issue but a packaging bug.
It looks like kdesu lives in some libexec dir that doesn't hasn't been added to your PATH. It belongs to the kde-cli-tools package. You can run it with
$(nix-build '<nixpkgs>' -A kde-cli-tools --no-out-link)/lib/libexec/kf5/kdesu
You can use the above as an alias to launch kdesu until the fix to the packaging bug arrives.
How are the outcome of these two methods different? Why use one over the other? I believe they both end up enabling you to issue 'rake' or 'rspec' without the preceeding 'bundle exec". My guess - with method 1 you only have to do this once, and then on ALL new rails project for the rvm ruby version will automatically have the desired feature ( as explained above)?
Method 1:
rvm get head && rvm reload
chmod +x $rvm_path/hooks/after_cd_bundler
bundle install --binstubs
OR
Method 2:
bundle install --binstubs
If found this documentation, but it did not help me understand which method to use. I looked on http://rvm.io and found intergration/bundler and /workflow/hooks.
The is code for after_cd_bundler (but I cannot post anymore links due to stackoverflow.com limitations on me)
This are not two different methods, this is one method and it is described in more detail here: http://robots.thoughtbot.com/post/15346721484/use-bundlers-binstubs
If you are using RVM then you do not need any of this, using --binstubs requires adding to PATH - which is big security risk if used from project directory, RVM comes with rubygems-bundler gem preinstalled which does the automatic loading of bundler (no need for bundle exec), you can find more details about the gem here: https://github.com/mpapis/rubygems-bundler#readme
I am author of rubygems-bundler and maintainer of RVM.
I'm creating a library libgdata that has some tests and non-installed programs. I am running into the problem that once I've installed the library once, the programs seem to be linking to the installed version and not the local version in ../src/libgdata.la any longer.
What could cause this? Am I doing something horribly wrong?
Here is what my test/Makefile.am looks like:
INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/
# libapiutil contains all of our dependencies!
AM_CXXFLAGS = $(APIUTIL_CFLAGS)
AM_LDFLAGS = $(APIUTIL_LIBS)
LDADD = $(top_builddir)/src/libgdata.la
noinst_PROGRAMS = gdatacalendar gdatayoutube
gdatacalendar_SOURCES = gdatacalendar.cc
gdatayoutube_SOURCES = gdatayoutube.cc
TESTS = check_bare
check_PROGRAMS = $(TESTS)
check_bare_SOURCES = check_bare.cc
(libapiutil is another library that has some helper stuff for dealing with libcurl and libxml++)
So, for instance, if I run the tests without having installed anything, everything works fine. I can make changes locally and they are picked up by these programs right away.
If I install the package, these programs will compile (it seems like it does actually look locally for the headers), but once I run the program it complains about missing symbols.
As far as I can tell, it is linking against the newly built library (../src/libgdata.la) based on the make output, so I'm not sure why this would be happening. If i remove the installed files, the local changes to src/* are picked up just fine.
I've included the make output for gdatacalendar below.
g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -o gdatacalendar gdatacalendar.o ../src/libgdata.la
mkdir .libs
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib
creating gdatacalendar
Help. :)
UPDATE
I get the following messages when I try to run the calendar program when I've added the addCommonRequestHeader() method to the Service class after I had installed the library without the addCommonRequestHeader() method.
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
symbol lookup error:
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
undefined symbol:
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_
Eugene's suggestion to try setting the $LD_LIBRARY_PATH variable did not help.
UPDATE 2
I did two tests. First, I did this after blowing away my dev-install directory (--prefix) and in that case, it creates test/.libs/lt-gdatacalendar. Once I have installed the library, though, it creates test/.libs/gdatacalendar instead. The output of ldd is the same for both with one exception:
# before install
# ldd test/.libs/lt-gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000)
# after install
# ldd test/.libs/gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000)
What would cause this to create lt-gdatacalendar in one case but gdatacalendar in another?
The output of ldd on libgdata is:
altern8#goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0
linux-gate.so.1 => (0xb7f7c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)
/lib/ld-linux.so.2 (0xb7f7d000)
I think I've sorted this out.
The problem should be that libtool sees the "-L" flag in the command line before it sees the "../src/libgdata.so" part. In this case, it executes the linker with "-Wl,-rpath,..." for that "-L" path. If that path contains "libgdata.so", then it will always be used, which is the case here.
In my case, I've rearranged "prog_LDADD" to like like this:
"prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"
In your case, try to delete AM_LDFLAGS and write:
LDADD = $(top_builddir)/src/libgdata.la $(APIUTIL_LIBS)
Not sure how to do that in autoconf, but final command might need to have -L../src, so linker can find newly built library first.
Try manually running last command with that addition and see if that helps.
EDIT: Ok, I guess misread it, thought it wasn't linking, but you are saying it links but doesn't run?
If that is the case, run ldd on your binary and see which .so it picks up -- most likely installed (and outdated) ones.
In this case, either install updated libs before running, or export LD_LIBRARY_PATH env variable before running.
export LD_LIBRARY_PATH="/path to freshly built libs"
I know that for dependencies to work correctly, you need to refer to libgdata.la with a relative path in LDADD; it's possible that affects the situation you're describing as well.
I'm not sure why, though. The behavior you're describing does seem a bit odd; and perhaps worth reporting to the libtool developers.
Without -no-install libtool creates script wrappers and puts the executables into the .libs/ subdir (linked with the installed libraries). Calling the wrapper makes your executable load/link with your local (not installed) library - so everything works fine, e.g. make check does not test the installed but your freshly baken library.
In some cases (e.g. when debugging or valgrinding), you do not want to have those wrappers, but real executables directly linked with your local library. For this you use AM_LDFLAGS = -no-install (or just set it for single targets).
More details here