I am trying to build GNOME Calendar on my Ubuntu 18.04.2 system, and so I do
$ meson ./gnome-calendar ./myGCbuild
and then have been installing the missing dependencies that it tells me one by one using apt.
But eventually I run into some more "non-trivial" things such as that my glib-2.0 version needs to be >= 2.58.0 but the latest on apt repository is 2.56.3 and so guess I need to make another build of the latest glib or maybe find on PPA; but so I'm wondering:
Is there some way meson or something else can take care of automatically installing the missing dependencies with the right versions, etc?
Meson isn't a dependency solver. So, No, meson doesn't take care that.
However, if you want to build gnome applications, there is The Newcomers Guide. Check out the Build Project page. It tells you about "Flatpak, a technology for installing and distributing applications and an IDE called Builder, which has good integration with GNOME technologies and Flatpak. This is the recommended method for new contributors, and is the easiest way to get started."
Happy Hacking.
You can have it fall back to a subproject and build the library as a private dependency, however that is not what you want in this case and no its not Mesons job to understand package managers.
You can use conan to manage your third party dependency and then have meson call conan for fetching them.
Your conan file:
[requires]
glib/2.58.3#bincrafters/stable
[generators]
pkg_config
And in your meson.build put:
run_command('conan', 'install', '--install-folder', meson.build_root(), meson.source_root, check: true)
glib_dep = dependecy('glib')
Apt can do this for you: apt-get build-dep gnome-calendar.
Related
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
When using the version of fastlane installed from Homebrew, I don't know how to use a development build of a plugin. I see fastlane add_plugin still generates a Pluginfile. If I try adding gem "fastlane-plugin-xxx", git: "https://github.com/yyy/xxx" or something similar using a :path argument, it always tries to install the version from RubyGems.
I have two specific cases where this makes things inconvenient:
I'm building a new plugin for a client. I want mobile devs to review it internally before it is published.
A user reported an error from a published plugin. I want them to try a dev version from the master branch in order to get more information.
In both cases, I think it's necessary to use Ruby and the Bundler. Not everyone has lots of Ruby experience, so getting someone set up can be an obstacle.
Edited 2017-07-06:
Part of the answer is obvious. When you run fastlane add_plugin, it prompts you if it cannot find the gem:
[jdee#Jimmy-Dees-MacBookPro TestApp]$ fastlane add_plugin my_new_action
[10:46:28]: Seems like the plugin is not available on RubyGems, what do you want to do?
1. Git URL
2. Local Path
3. RubyGems.org ('fastlane-plugin-my_new_action' seems to not be available there)
?
This works well with the fastlane gem, e.g. with RVM:
gem install fastlane
fastlane add_plugin my_new_action
The self-contained binary from Homebrew also prompts you for a Git URL or a local path, but I consistently get build failures from native extensions in the json gem on OS X Sierra. This may be due to plugin dependencies, but I'm not sure. This can still be a little awkward for the use cases above, and I'm surprised that this fails with the self-contained version, which I'd expect to be more robust than using Ruby. At least this removes the need for bundle install and bundle exec.
The answer here is basically that the self-contained version of Fastlane does not really work with plugins. In particular, when fastlane add_plugin or fastlane install_plugins runs bundle install, it tries to install the json gem, a dependency of the fastlane gem, which has native dependencies, and it cannot find <stdio.h>, presumably because /usr/include is screened out in the self-contained bundle in order to insulate it from the system Ruby. After this, you can run bundle install and bundle exec yourself, but in general a Gemfile is required to work with Fastlane plugins. The CLI will even tell you to run bundle exec once you have a Gemfile.
When using the fastlane gem, fastlane add_plugin will usually work, but again you will have a Gemfile and want to run bundle exec fastlane afterward.
You can just modify your Pluginfile to use a path or a git repo and rerun bundle install. There's not a much easier way to do this at the moment.
I'm running Centos 6.7 on my server and am trying to install Erlang/Rabbitmq following these instructions:
Erlang Installation
RabbitMQ Installation
The trouble is that at time of writing these install Erlang 19.0 with RabbitMQ 3.6.3, which leads to a pretty major bug as far as my client who occasionally looks at the management interface to monitor queues is concerned.
The guidance in the error ticket is not to use erlang 19 until RabbitMQ 3.6.4 is released. But how can I install a specific version of Erlang?
These steps worked for me:
Go to the download page here: https://packages.erlang-solutions.com/erlang/
Select your appropriate package -- you can copy/peek the link then download it using wget.
Install it using rpm.
Example:
# Download erlang 19
$ wget http://packages.erlang-solutions.com/site/esl/esl-erlang/FLAVOUR_1_general/esl-erlang_19.0~centos~7_amd64.rpm
# Install
rpm -Uvh esl-erlang_19.0~centos~7_amd64.rpm
You can always build install from source.
Go to the Erlang.org Downloads page, pick your version from the right side.
From there you can follow the instructions. Although they are for Ubuntu, the commands are the same except for the dependencies part where you can use the command below to install what you need:
sudo yum install g++ openssl-devel unixodbc-devel autoconf ncurses-devel
Another option would be to use kerl, which is similar to rvm in some sense and very (very!) easy to use. It will let you install different Erlang versions and switch between them any time you want.
I prefer this approach instead of looking up packages myself (with possible incompatibilities in the dependencies required) or downloading and compiling everything myself every time I want to try a new Erlang version.
I would like to change some code in one element X in gstreamer ugly plugin and rebuild and use it.
How I can do it?
I have gstreamer-0.10 and installed gstreamer-ugly plugin.
I would like to download only gstreamer0-10 ugly plugin code and change it and would like to use the new lib file. How I can do it?
unfortunately gstreamer-ugly depends on a lot of stuff in at least libgstreamer and plugins-base (if you're using linux and your distro provides *-dev packages as debian/ubuntu does).
If you're on debian you could use dpkg-buildpackage after checking out the source using apt-source. The big advantage here is that all the build dependencies can be easily installed.
The manual way will probably need you to first build all the other gstreamer packages have a close look on what ./configure tells you
I'm workin on debian and have already built gstreamer+plugins to backport the recent ones to ubuntu (although I'm not sure if I did it in a best-practice way ;) )
/edit: I'll try to cover the basic steps for ubuntu here:
add the source repositories to apt (check the "source code" checkbox in the ubuntu software center's "software sources" tool
sudo apt-get install dpkg-dev devscripts
sudo apt-get build-dep gst-plugins-ugly0.10
apt-get source gst-plugins-ugly0.10
change to the newly created gst-plugins-base* folder
dpkg-buildpackage (and make sure it works)
change the source to your needs
you can rebuild it any time using dpkg-buildpackage (to simply see if it compiles make might be faster though). This creates a .deb file in the parent folder that you can simply install using dpkg -i
If it's a useful change you might want to get in touch with the gstreamer-devs ;)
On a debian system, run apt-get build-dep gstreamer0.10-plugins-ugly to get all the build dependencies for that package. After that you can build the package from git, source tarball or even rebuild the debian package (using dkgp-buildpackage).
After testing my Catalyst application and deciding to deploy it I would like to package it up so I can easily pull it in on the staging and live servers, manage dependencies and easily roll-back via the flexibility of package versioning. As my production OS is Ubuntu I figured packaging it as a deb package would make most sense.
I am predicting I will have to create a second package of all my perl module dependencies as many are not provided by my distribution, or package them independently - though that may be a lot of work.
Does anyone have any experience of doing this - or a sane, similar alternative?
To build your own Debian packages out of CPAN packages:
Install Debian helper scripts
sudo apt-get install dh-make-perl
Download MODULE from CPAN and build Debian package
cpan2deb MODULE
dh-make-perl is actually the right tool to put CPAN modules into Debian packages. Together with apt-file it can even prepare proper dependencies for you.
About being able to "easily roll-back" though requires special attention to versioning or workflows. There are several approaches that might get your job done here:
If you can force-downgrade packages you have won already most of the time unless you have very specific maintainer scripts that do jobs on package upgrades - then you will have to make them able to handle the downgrade, too
If you have to go the regular upgrade-path, using approaches like using "< newversion>+rollback< oldversion>" or similar might be something to consider.
Dependency-packages are always a good idea for deployments to make sure no required package actually is missing. Also, you might want to invest some time in management frameworks like puppet, they might come handy here, too.