I am looking for some documentation on syslog-ng version 2.0.9. I have to tweak on an old SUSE 11.2 installation. Official syslog-ng has only documentation starting from 3.5 version. Anyone may share a link to access documentation for older versions ?
It used to be in the syslog-ng source tree, its last revision from roughly that time is here https://github.com/syslog-ng/syslog-ng/blob/1bffb002ab3ef4b9854e1379cd9dc329523059df/doc/reference/syslog-ng.xml
It is a docbook format which you can convert to HTML using:
xsltproc --nonet --path ./doc -o ./doc/reference/syslog-ng.html/index.html \
./doc/reference/syslog-ng.xsl \
./doc/reference/syslog-ng.xml
If you download the source tree for that version, the documentation is in its doc/reference folder.
Related
What will happen if the "package.json" version is not followed in sequence and the same version is repeated in the history with different code-base?
Let us suppose:
Project-XYZ package.json version 1.0.0 is published with the changes in the files (file1, file2)
Project-XYZ package.json version 1.1.0 is published with the changes in the files (file2, file3)
Project-XYZ package.json version 2.0.0 is published with the changes in the files (file3, file1)
Project-XYZ package.json version 1.0.0 is published with the changes in the files (file4, file2)
Project-XYZ package.json version 1.0.1 is published with the changes in the files (file5, file1)
Project-XYZ package.json version 1.0.2 is published with the changes in the files (file2, file1)
Project-XYZ package.json version 1.1.0 is published with the changes in the files (file1, file2)
Project-XYZ package.json version 2.0.0 is published with the changes in the files (file4, file5)
package.json version 1.0.0 is published twice with the different codebase, should this work or would it cause any problem.
I am actually experiencing an error called Timeout._onTimeout after particular commit in the Gitlab pipeline but the only difference I could see in the code was this versioning order, it is certain that the engineer missed the actual version and tried pushing on the older version only and since then on the sequence continued for the same versions in the history repeating with the different codebase.
should this cause any problem ? have any of you come across such a scenario?
Please help. Thanks in advance!
I found an answer on npmjs docs and it says:
Fails if the package name and version combination already exists in the specified registry.
Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm-unpublish.
As of npm#5, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. Subsequent installs will use the strongest supported algorithm to verify downloads.
So, clearly we can't have such versioning and I will try and fix the above issue moving the code-based to new and unused versions.
How can you get the Linux-Headers for a different Kernel Version than the one installed on the system?(Debian) I searched the whole Web and couldn't find anything other than that you can download the Headers for you current running kernel, why is it so hard to get the Headers for a non running kernel?
I need the 4.16 headers to compile a LKM, but im running on 4.9.
You can get the kernel headers and source for any of the standard releases from:
git clone https://github.com/torvalds/linux
Or from: https://cdn.kernel.org/pub/linux/kernel/v4.x/
If pulling from the git repo, you will need to checkout the specific version you wish to build for. In your case:
git checkout v4.16
I'm trying to build cpp-netlib 0.12.0 stable in Ubuntu 18.04, but when I get to running
$ make -j4
I get a lot of errors, such as:
error: ‘SSL_R_SHORT_READ’ was not declared in this scope
ERR_PACK(ERR_LIB_SSL, 0, SSL_R_SHORT_READ)
Google told me this was because the make variables -DOPENSSL_INCLUDE_DIR and -DOPENSSL_SSL_LIBRARY need to be defined. However, I can't find the directories/libraries I need to set them to. Examples give /usr/lib/openssl-1.0 and /usr/include/openssl-1.0, but I can't find anything like those, even though I have the latest version of openssl installed through apt-get.
My /usr/include directory contains the folder 'openssl', but usr/lib doesn't have even that, only 'openssh', which doesn't appear to contain anything relevant.
How can I fix this?
Fixed by cloning latest version from git repository and building from that.
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 am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.