I'm wondering if the aur/ceph-libs can be removed as it looks like it's not required by anyone :
pacman -Qi ceph-libs
Name : ceph-libs
Version : 16.2.7-1
Description : Distributed, fault-tolerant storage platform delivering object, block, and file system
Architecture : x86_64
URL : https://ceph.com/
Licenses : GPL
Groups : None
Provides : ceph-libs=16.2.7-1
Depends On : boost-libs curl glibc keyutils libutil-linux bzip2 lz4 nss oath-toolkit python snappy systemd-libs fmt cryptsetup lua librdkafka python-prettytable python-yaml python-setuptools
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : ceph-libs-bin
Replaces : None
Installed Size : 73.35 MiB
Packager : Unknown Packager
Build Date : Tue 11 Oct 2022 08:12:31 PM CEST
Install Date : Wed 12 Oct 2022 08:28:54 AM CEST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : None
Note : if this package is somehow needed, looks like pre-built binaries exist here for faster installation:
https://aur.archlinux.org/packages/ceph-libs-bin
Any clue ?
Only you can know if you need it. You could remove it and install it again if you do need it.
If you ran into the 30 hour build issue on the AUR package, here is some more info: https://archlinux.org/todo/removal-of-ceph-from/
Related
Brand new install of centos 9. (mostly minimal)
I did a find and there is no libl.so on my machine.
sudo yum install bison
Last metadata expiration check: 1:52:29 ago on Wed 23 Feb 2022 01:25:31 PM EST.
Package bison-3.7.4-5.el9.x86_64 is already installed.
sudo yum install flex
Last metadata expiration check: 1:52:25 ago on Wed 23 Feb 2022 01:25:31 PM EST.
Package flex-2.6.4-9.el9.x86_64 is already installed.
sudo yum install flex-devel
Last metadata expiration check: 1:52:35 ago on Wed 23 Feb 2022 01:25:31 PM EST.
No match for argument: flex-devel
I tried installing sudo yum groupinstall 'Development Tools'
nothing works, any ideas?
The static libraries (libfl.a and libl.a), which is what were provided before in the package flex-devel, have been moved to the package libfl-static. I don't know if RedHat ever provided shared objects; there's a note in the libfl-static ChangeLog that seems to be saying that there is a new package called libfl2 with shared objects, but I don't see it in the package repo. Anyway, static libraries should be fine. There's hardly anything there.
If you're using libl, that means that:
you aren't using %option noyywrap, which will remove the call to yywrap (and if you're using the version of yywrap in libl, then you don't need it to call the function, since that version unconditionally returns 1), and/or
you haven't provided your own main function.
I strongly recommend including the following options in all flex files, unless you have a clear need for the suppressed features:
%option noinput nounput noyywrap nodefault
The main function in libl is also trivial. It can be replaced with:
int main(void) {
while (yylex() != 0) { }
return 0;
}
As you pointed out in the question - flex-devel is not found.
It's in the PowerTools repo.
The 'official' way to enable the repo is to use the yum config-manager command line:
yum config-manager --set-enabled powertools
This may give an error about being missing the config-manager command:
No such command: config-manager
If this happens, then you can install the dnf-plugins-core package:
yum install -y dnf-plugins-core
and then enable the powertools repo, and then you should be able to yum install flex-devel, which provides:
$ rpmquery --list flex-devel
/usr/lib64/libfl.a
/usr/lib64/libfl_pic.a
/usr/lib64/libl.a
/usr/share/doc/flex
/usr/share/licenses/flex-devel
/usr/share/licenses/flex-devel/COPYING
I have plumber version 1.0.0 installed and I also installed jsonlite 1.7.1 when I try to load library(jsonlite) I get back:
Error in value[[3L]](cond) :
Package ‘jsonlite’ version 1.6 cannot be unloaded:
Error in unloadNamespace(package) : namespace ‘jsonlite’ is imported by ‘webutils’, ‘plumber’ so cannot be unloaded
In addition: Warning message:
package ‘jsonlite’ was built under R version 3.6.3
So I thought that some of jsonlite functions are already available through plumber, but toJSON(some_df, pretty = T) generates error:
Error in toJSON(some_df, pretty = T) : could not find function "toJSON"
Any thoughts?
When I using conda search anaconda I found a few custom version packages, shown as follow:
Fetching package metadata: ....
anaconda 1.6.0 np17py33_0 defaults
... ... ...
4.0.0 np110py35_0 defaults
4.0.0 np110py34_0 defaults
4.0.0 np110py27_0 defaults
custom py35_0 defaults
custom py34_0 defaults
custom py27_0 defaults
Note that these three custom version pkgs are shown at the end of conda search anaconda results, so they are considered the newest version by conda, which also affects conda install anaconda results (so I have to using conda install anaconda=4.0.0).
Then conda info anaconda=custom gives following results:
Fetching package metadata: ....
anaconda custom py35_0
----------------------
file name : anaconda-custom-py35_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py35_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 47c237b38bfc175cb73aed8b8b33ade7
space : python
installed environments:
dependencies:
python 3.5*
anaconda custom py34_0
----------------------
file name : anaconda-custom-py34_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py34_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 767a59923372d998b8c83fb16ac035a1
space : python
installed environments:
dependencies:
python 3.4*
anaconda custom py27_0
----------------------
file name : anaconda-custom-py27_0.tar.bz2
name : anaconda
version : custom
build number: 0
build string: py27_0
channel : defaults
size : 3 KB
date : 2016-03-14
license : BSD
md5 : 8288aef529d5a46d07bd84b4fcf4308a
space : python
installed environments:
dependencies:
python 2.7*
BUT I don't know/remeber HOW and WHY these three packages appear in this computer, can anyone explain:
How these custom version pkgs are created in the first place?
How/Why these custom version pkgs are shown in the conda search results?
How to remove these custom version pkgs?
The one custom version of any package that exists (right now, in the official repos) is for the anaconda package.
Here's there reason... The anaconda conda packages are metapackages, meaning they are packages of packages--or packages that have no real source code and only bring in a bunch of dependencies. Each anaconda package has every sub-package pinned to an explicit and specific version of that sub-package. That's because Continuum does extensive testing on the interoperability of that set of packages (and those specific versions).
Now, after you've installed anaconda, either through the Anaconda Installer or installing Miniconda and then conda install anaconda, you have a set of packages with all of these tested guarantees. There's no reason you have to stick to this locked set of packages--you can install anything and any version you want. You no longer have a version-identifiable Anaconda Distribution though. You've customized it. Thus, when you run conda list and the version of the anaconda package shows custom, you know you've diverged from the set of packages in the Anaconda Distribution that are robustly tested for interoperability.
Your conda search anaconda query just reflects an artifact of how this is implemented. You'll notice in that query that custom packages are listed first, meaning they have the lowest sort order when comparing versions. Thus, if you run conda update anaconda after you've diverged from the specifically-pinned anaconda packages, you'll be back to a numbered version of the Anaconda Distribution.
This is really a partial answer. I'm not positive why exactly this version exists.
(1) In terms of the specific version value of custom it seems this is allowed from here:
version: string
The package version, which may not contain -. Conda acknowledges PEP 440.
So this anaconda package would be created in the same way as any of the other versions. I would assume using conda build.
(2) They are shown in the search results because they exist in the anaconda cloud. It seems this is an officially released version of anaconda.
As for why it exists, if you download one of the actual package files (for example linux-64-anaconda-custom-py35_0.tar.bz2), expand it, and read the info/index.json file it looks like this package will simply install python and the other bare bones needs. Compare this to anaconda version 4.0.0, or one of the others, and you will see a ton of packages. I assume this package exists so that if someone installs the custom version they will just get the bare bones packages and then they go through conda install-ing any others they want.
For example, look at the packages when you do conda create -n anc-test anaconda=4.0.0 vs. conda create -n anc-test anaconda=custom.
EDIT: Just saw that that is also in your conda info so you are probably already aware of the difference in dependencies.
(3) I don't think you can remove these custom packages from your search call as they are legitimate packages in the anaconda cloud. You might be able to exclude them from the conda search via regex. It doesn't look like from your output that they have been installed -- at least not in the current environment.
I am trying to install the lattest armadillo version. From the package list I can see rawhide 7.100.3-2.fc25.
I run Fedora 23 and cannot manage to install this package directly.
So following this postI did
dnf install fedora-repos-rawhide
dnf install --enablerepo rawhide armadillo
I get:
Last metadata expiration check: 1:16:40 ago on Tue May 31 18:20:30 2016.
Package armadillo-6.700.6-1.fc23.x86_64 is already installed, skipping.
How can I install using dnf the proper package ?
You need to use update, since your package is already installed:
dnf update --enablerepo rawhide armadillo
I am manually building httpd-2.2.17 from the source. Just to make sure I have the configuration options right, I checked the latest CENTOS apache srpm (which is for httpd-2.2.3). In the httpd.spec I find this line:
# forcibly prevent use of bundled apr, apr-util, pcre
rm -rf srclib/{apr,apr-util,pcre}
I was wondering why this is required ? What's wrong with using the apr included within the default httpd source ?
Was wondering why this is required ?
To prevent the bundled apr/pcre libraries to be used and possibly installed. RedHat/CentOS would rather want to ship a standalone package of the apr and pcre libraries.
Whats wrong with using the apr included within apache ?
You might get out of sync regarding the apr/apr-util/pcre versions that apache bundleds vs the apr/apr-utl/pcre libraries that CentoS/RHEL packages. I.e. you want to ship one particular release of pcre from http://www.pcre.org/ (+ perhaps custom patches) that several packages can use , not just apache, and you want apache to build against that library instead of the one apache bundle.
Removing those directories, and it's a safe bet building apache won't pick up any of the bundled headers/libraries.