On our CentOS 6.5 no mysql was installed, but as dependency was automtaically installed mysql-libs version: 5.1.73 Release: 3.el6_5.
Cannot we safely remove mysql-libs as we remove also dependencies. Is safe to replace mysql-libs with MariaDB one ?
Actual dependency from "yum remove mysql-libs":
Removing:
mysql-libs x86_64 5.1.73-3.el6_5 #updates 4.0 M
Removing for dependencies:
cronie x86_64 1.4.4-12.el6 #base 174 k
cronie-anacron x86_64 1.4.4-12.el6 #base 43 k
crontabs noarch 1.10-33.el6 #anaconda-CentOS-
201303020151.x86_64/6.4 2.4 k
munin noarch 2.0.20-1.el6 #epel 534 k
munin-node noarch 2.0.20-1.el6 #epel 1.3 M
postfix x86_64 2:2.6.6-6.el6_5 #updates 9.7 M
sysstat x86_64 9.0.4-22.el6 #base 824 k
If it can help someone... we found this solution:
https://mariadb.com/kb/en/centos-5x6x-mysql-lib-conflicts-and-postfix/
http://blog.johannes-beck.name/?p=199
Related
This is a bit of a conundrum for me.
In the image below tesseract package in R totally ignores the second occurrence of 1 on the fourth line, no matter what I do (meaning, it reads it as 1 instead of 11). The image here is already preprocessed - upscaled via nn, cleaned, and binarized. It's the same thing even if I just lightly preprocess the source image.
Cropping the noise on the right does not help. Changing the tessedit_pageseg_mode options can only make things worse, but does not help with this particular problem.
Where the heck did the 1 go? I need to know for the sake of my sanity.
While waiting for R to compile tesseract package, I tested the command line version:
$ tesseract --version
tesseract 4.1.1
leptonica-1.79.0 #...etc
$ tesseract ocr_test.png test
obec TREBOHOSTICE 2021
okres Strakonice, Jihocesky kraj
Poéet osob starSich 15 let 274
Poéet osob v exekuci 11
Podil osob v exekuci 4,01 %
Celkovy pocet exekuci 106
Prumérny poéet exekuci na osobu 9.6
Z toho:
podil (pocet) osob s 1 — 9 exekucemi 45% (5)
podil (pocet) osob s 10 a vice exekucemi 55% (6)
PM. 2
CLI output looks good. Might be to do with the underlying versions of leptonica installed on your system
\\
Clean compile of R tesseract package plus Linux packages:
#Linux command line
$ sudo apt install libpoppler-cpp-dev libtesseract-dev libleptonica-dev
#In R
install.packages("tesseract") # version 5.1.0
library(tesseract)
ocr(file.choose())
Output of row 4 11 looks good:
obec TREBOHOSTICE 2021
okres Strakonice, Jihocesky kraj
Poéet osob starSich 15 let 274
Poéet osob v exekuci 11
Podil osob v exekuci 401% |
Celkovy pocet exekuci 106
Prumérny poéet exekuci na osobu 9.6
Z toho: on
podil (pocet) osob s 1 — 9 exekucemi 45% (5) ;
podil (pocet) osob s 10 a vice exekucemi 55% (6) >
The problem stems from using Czech engine engine = tesseract(language = "ces") for tesseract.
I am getting the following error when trying to install the lme4 package in R.
install.packages("lme4")
Installing package into ‘/usr/local/lib/R/4.2/site-library’
(as ‘lib’ is unspecified)
also installing the dependency ‘minqa’
trying URL 'https://cloud.r-project.org/src/contrib/minqa_1.2.4.tar.gz'
Content type 'application/x-gzip' length 53548 bytes (52 KB)
==================================================
downloaded 52 KB
trying URL 'https://cloud.r-project.org/src/contrib/lme4_1.1-29.tar.gz'
Content type 'application/x-gzip' length 3306026 bytes (3.2 MB)
==================================================
downloaded 3.2 MB
* installing *source* package ‘minqa’ ...
** package ‘minqa’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
/usr/local/opt/gcc/bin/gfortran -fno-optimize-sibling-calls -fPIC -g -O2 -c altmov.f -o altmov.o
altmov.f:42:72:
42 | 10 HCOL(K)=ZERO
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 10 at (1)
altmov.f:45:72:
45 | DO 20 K=1,NPT
| 1
Warning: Fortran 2018 deleted feature: Shared DO termination label 20 at (1)
altmov.f:46:72:
46 | 20 HCOL(K)=HCOL(K)+TEMP*ZMAT(K,J)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 20 at (1)
altmov.f:53:72:
53 | 30 GLAG(I)=BMAT(KNEW,I)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 30 at (1)
altmov.f:57:72:
57 | 40 TEMP=TEMP+XPT(K,J)*XOPT(J)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 40 at (1)
altmov.f:59:72:
59 | DO 50 I=1,N
| 1
Warning: Fortran 2018 deleted feature: Shared DO termination label 50 at (1)
altmov.f:60:72:
60 | 50 GLAG(I)=GLAG(I)+TEMP*XPT(K,I)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 50 at (1)
altmov.f:76:72:
76 | 60 DISTSQ=DISTSQ+TEMP*TEMP
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 60 at (1)
altmov.f:172:72:
172 | 90 XNEW(I)=DMAX1(SL(I),DMIN1(SU(I),TEMP))
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 90 at (1)
altmov.f:237:72:
237 | 140 GW=GW+GLAG(I)*W(I)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 140 at (1)
altmov.f:248:72:
248 | 150 TEMP=TEMP+XPT(K,J)*W(J)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 150 at (1)
altmov.f:249:72:
249 | 160 CURV=CURV+HCOL(K)*TEMP*TEMP
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 160 at (1)
altmov.f:255:72:
255 | 170 XALT(I)=DMAX1(SL(I),DMIN1(SU(I),TEMP))
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 170 at (1)
altmov.f:268:72:
268 | 180 W(N+I)=XALT(I)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 180 at (1)
altmov.f:275:72:
275 | 190 XALT(I)=W(N+I)
| 1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 190 at (1)
clang (LLVM option parsing): Unknown command line argument '-x86-pad-for-align=false'. Try: 'clang (LLVM option parsing) --help'
clang (LLVM option parsing): Did you mean '--x86-slh-loads=false'?
make: *** [altmov.o] Error 1
ERROR: compilation failed for package ‘minqa’
* removing ‘/usr/local/lib/R/4.2/site-library/minqa’
ERROR: dependency ‘minqa’ is not available for package ‘lme4’
* removing ‘/usr/local/lib/R/4.2/site-library/lme4’
The downloaded source packages are in
‘/private/var/folders/02/6dwz1gvd1qz4gml8v_wv6n980000gp/T/RtmpVREiYV/downloaded_packages’
Warning messages:
1: In install.packages("lme4") :
installation of package ‘minqa’ had non-zero exit status
2: In install.packages("lme4") :
installation of package ‘lme4’ had non-zero exit status
I recently upgraded my OS to MacOSX Monterey (12.3.1) in a MacBook 2020 (intel chip).
I have tried reinstalling gcc and gccfortran using brew with no effect.
Can anyone help me with the issue?
Removing xcode command line tools and reinstalling it solved the issue.
$ xcode-select --print-path
/Library/Developer/CommandLineTools
$ sudo rm -r -f /Library/Developer/CommandLineTools
$ xcode-select --install
I'm struggling to understand why reading in a NetCDF file using open_dataarray in the HPC I use produces a Segmentation fault (core dumped). However, when I read in the file using open_dataarray on my Mac it works fine.
From looking into this further it is the NPac file (the sub-section) which I created which seems to have issues. Here is the steps I took to generate the file:
WaveWatchIII outputs a file
Extract July: $ncks -d time,0,30 in.nc out.nc Can open out.nc in HPC
Extract variable: $ncks -v hs in.nc out.nc Can open out.nc in HPC
Extract domain: $ncks -d longitude,100.0,290.0 -d latitude,0.0,65.0 in.nc out.nc Cannot open out.nc on HPC but can open out.nc on Mac.
This is the first time i've seen this issue and I believe it is due to properties of the domain of the NetCDF file. I'm guessing it may have something to do with versions as well? I do most of the heavy lifting on the HPC and use my Mac for testing and understanding so it would be nice to get this working on the HPC.
The NetCDF file can be downloaded here
ncdump -h ww3.Hs.July.NPac.nc
netcdf ww3.Hs.July.NPac {
dimensions:
time = UNLIMITED ; // (31 currently)
latitude = 66 ;
longitude = 191 ;
variables:
short hs(time, latitude, longitude) ;
hs:long_name = "significant height of wind and swell waves" ;
hs:standard_name = "sea_surface_wave_significant_height" ;
hs:globwave_name = "significant_wave_height" ;
hs:units = "m" ;
hs:_FillValue = -32767s ;
hs:scale_factor = 0.002f ;
hs:add_offset = 0.f ;
hs:valid_min = 0 ;
hs:valid_max = 32000 ;
float latitude(latitude) ;
latitude:units = "degree_north" ;
latitude:long_name = "latitude" ;
latitude:standard_name = "latitude" ;
latitude:valid_min = -90.f ;
latitude:valid_max = 90.f ;
latitude:axis = "Y" ;
float longitude(longitude) ;
longitude:units = "degree_east" ;
longitude:long_name = "longitude" ;
longitude:standard_name = "longitude" ;
longitude:valid_min = -180.f ;
longitude:valid_max = 180.f ;
longitude:axis = "X" ;
double time(time) ;
time:long_name = "julian day (UT)" ;
time:standard_name = "time" ;
time:units = "days since 1850-01-01T00:00:00Z" ;
time:conventions = "relative julian days with decimal part (as parts of the day )" ;
time:axis = "T" ;
// global attributes:
:WAVEWATCH_III_version_number = "4.18b" ;
:WAVEWATCH_III_switches = "NC4 F90 NOGRB NOPA LRB4 SHRD PR3 UQ FLX0 LN1 ST4 STAB0 NL1 BT1 DB1 MLIM TR0 BS0 IC0 REF0 XX0 WNT1 WNX1 CRT1 CRX1 O0 O1 O2 O3 O4 O5 O6 O7 O11 O14 TRKNC" ;
:SDS4\ namelist\ parameter\ WHITECAPWIDTH = 0.3f ;
:product_name = "ww3.199307.nc" ;
:area = "Indian Ocean Pacfic 1 degree" ;
:latitude_resolution = " 1.0000000" ;
:longitude_resolution = " 1.0000000" ;
:southernmost_latitude = "-70.0000000" ;
:northernmost_latitude = "65.0000000" ;
:westernmost_longitude = "20.0000000" ;
:easternmost_longitude = "295.0000000" ;
:minimum_altitude = "-12000 m" ;
:maximum_altitude = "9000 m" ;
:altitude_resolution = "n/a" ;
:start_date = "1993-07-01T00:00:00Z" ;
:stop_date = "1993-07-31T00:00:00Z" ;
:history = "Sat Dec 2 17:53:06 2017: ncks -O -d longitude,100.0,290.0 -d latitude,0.0,65.0 /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.Hs.July.nc /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.Hs.July.NPac.nc\nSat Dec 2 17:53:06 2017: ncks -O -v hs /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.July.nc /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.Hs.July.nc\nSat Dec 2 17:53:05 2017: ncks -O -d time,0,30 /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.19930701_19940630.nc /projects/rsmas/kirtman/rxb826/WW3exps/IO_Pac_CCSM4/CCSM4_19930701_19940630_1a1/work/ww3.July.nc\nFri Nov 4 13:50:57 2016: ncrcat -O -o tmp.nc ww3.199307.nc ww3.199308.nc ww3.199309.nc ww3.199310.nc ww3.199311.nc ww3.199312.nc ww3.199401.nc ww3.199402.nc ww3.199403.nc ww3.199404.nc ww3.199405.nc ww3.199406.nc" ;
:nco_openmp_thread_number = 1 ;
:NCO = "4.3.7" ;
On the HPC:
$ nc-config --version
netCDF 4.2.1.1
>>> xr.show_versions()
INSTALLED VERSIONS
------------------
commit: None
python: 3.6.3.final.0
python-bits: 64
OS: Linux
OS-release: 2.6.32-431.el6.x86_64
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8
xarray: 0.10.0
pandas: 0.20.2
numpy: 1.13.1
scipy: 0.19.1
netCDF4: 1.2.4
h5netcdf: None
Nio: None
bottleneck: 1.2.1
cyordereddict: None
dask: 0.16.0
matplotlib: 2.0.2
cartopy: 0.15.1
seaborn: None
setuptools: 27.2.0
pip: 9.0.1
conda: 4.3.30
pytest: None
IPython: None
sphinx: None
>>> xr.open_dataarray('ww3.Hs.July.NPac.nc')
Segmentation fault (core dumped)
On my Mac:
$ nc-config --version
netCDF 4.4.1
xr.show_versions()
INSTALLED VERSIONS
------------------
commit: None
python: 3.6.3.final.0
python-bits: 64
OS: Darwin
OS-release: 17.2.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8
xarray: 0.10.0
pandas: 0.20.1
numpy: 1.12.1
scipy: 1.0.0
netCDF4: 1.2.4
h5netcdf: None
Nio: None
bottleneck: 1.2.1
cyordereddict: None
dask: 0.16.0
matplotlib: 2.1.0
cartopy: 0.15.1
seaborn: 0.8.1
setuptools: 36.2.7
pip: 9.0.1
conda: 4.3.29
pytest: 3.2.0
IPython: 6.2.1
sphinx: 1.5.6
In [10]:xr.open_dataarray('ww3.Hs.July.NPac.nc')
Out[10]:
<xarray.DataArray 'hs' (time: 31, latitude: 66, longitude: 191)>
[390786 values with dtype=float64]
Coordinates:
* latitude (latitude) float32 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 ...
* longitude (longitude) float32 100.0 101.0 102.0 103.0 104.0 105.0 106.0 ...
* time (time) datetime64[ns] 2013-07-01 2013-07-02 2013-07-03 ...
Attributes:
long_name: significant height of wind and swell waves
standard_name: sea_surface_wave_significant_height
globwave_name: significant_wave_height
units: m
valid_min: 0
valid_max: 32000
Apologies. It looks like my ncks command wasn't completing property. Nothing to do with xarray just strange my Mac wasn't throwing up an error. Stranger still that giving out.nc a different file name seems to fix it
$ncks -O -d longitude,100.0,290.0 -d latitude,0.0,65.0 ww3.Hs.July.nc ww3.Hs.July.NPac.nc
$python
>>>import xarray as xr
>>>xr.open_dataarray('ww3.Hs.July.NPac.nc')
Segmentation fault (core dumped)
$ncks -O -d longitude,100.0,290.0 -d latitude,0.0,65.0 ww3.Hs.July.nc ww3.Hs.July.NPac1.nc
$python
>>>import xarray as xr
>>>xr.open_dataarray('ww3.Hs.July.NPac1.nc')
<xarray.DataArray 'hs' (time: 31, latitude: 66, longitude: 191)>
[390786 values with dtype=float64]
Coordinates:
* latitude (latitude) float32 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 ...
* longitude (longitude) float32 100.0 101.0 102.0 103.0 104.0 105.0 106.0 ...
* time (time) datetime64[ns] 1993-07-01 1993-07-02 1993-07-03 ...
Attributes:
long_name: significant height of wind and swell waves
standard_name: sea_surface_wave_significant_height
globwave_name: significant_wave_height
units: m
valid_min: 0
valid_max: 32000
Very strange error on a value being not null, but is claimed to be null, even though it evaluates to FALSE on is.null() test. See below. In this case, pid seems to be null, but the test fails, causing me all sorts of 'next step' problems in the code.
> pid <- system2('ps', args = "-ef | grep 'ssh -f' | grep -v grep | tr -s ' ' | \ cut -d ' ' -f 3", stdout = TRUE)
> pid
character(0)
> is.null(pid)
[1] FALSE
> if(!is.null(pid) && nchar(pid)) {cat('got some pid')}
Error in if (!is.null(pid) && nchar(pid)) { :
missing value where TRUE/FALSE needed
> if(!is.null(pid)) {cat('got some pid? Really?')}
got some pid? Really?
What does folks think is happening here? Here is my version information of R:
> version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 3
minor 2.2
year 2015
month 08
day 14
svn rev 69053
language R
version.string R version 3.2.2 (2015-08-14)
nickname Fire Safety
Full version of the OS:
Linux rserver 3.16.0-44-generic #59~14.04.1-Ubuntu SMP Tue Jul 7 15:07:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
In the end, I simply want this code to run:
> if (nchar(pid) > 0) {
+ cat('do something\n')
+ }
Error in if (nchar(pid) > 0) { : argument is of length zero
The fact that you have an empty character variable doesn't mean that it's NULL. Here's an example:
pid <- character()
> pid
character(0)
> is.null(pid)
[1] FALSE
> pid <- NULL
> pid
NULL
> is.null(pid)
[1] TRUE
I am using R 2.14.0 64 bit on Linux. I went ahead and used the example described here. I am then running the example -
library(doMC)
registerDoMC()
system.time({
r <- foreach(icount(trials), .combine=cbind) %dopar% {
ind <- sample(100, 100, replace=TRUE)
result1 <- glm(x[ind,2]~x[ind,1], family=binomial(logit))
coefficients(result1)
} })
However, I see in top that it is using only one CPU core. To prove it another way, if I check a process that uses all cores, I see -
ignorant#mybox: ~/R$ ps -p 5369 -L -o pid,tid,psr,pcpu
PID TID PSR %CPU
5369 5369 0 0.1
5369 5371 1 0.0
5369 5372 2 0.0
5369 5373 3 0.0
5369 5374 4 0.0
5369 5375 5 0.0
5369 5376 6 0.0
5369 5377 7 0.0
But in this case, I see -
ignorant#mybox: ~/R$ ps -p 7988 -L -o pid,tid,psr,pcpu
PID TID PSR %CPU
7988 7988 0 19.9
ignorant#mybox: ~/R$ ps -p 7991 -L -o pid,tid,psr,pcpu
PID TID PSR %CPU
7991 7991 0 19.9
How can I get it to use multiple cores? I am using multicore instead of doSMP or something else, because I do not want to have copies of my data for each process.
You could try executing your script using the command:
$ taskset 0xffff R --slave -f parglm.R
If this fixes the problem, then you may have a version of R that was built with OpenBLAS or GotoBlas2 which sets the CPU affinity so that you can only use one core, which is a known problem.
If you want to run your example interactively, start R with:
$ taskset 0xffff R
First, you might want to look at htop, which is probably available for your distribution. You can clearly see the usage for each CPU.
Second, have you tried setting the number of cores on the machine directly?
Run this with htop open:
library(doMC)
registerDoMC(cores=12) # Try setting this appropriately.
system.time({
r <- foreach(1:1000, .combine=cbind) %dopar% {
mean(rnorm(100000))
} })
# I get:
# user system elapsed
# 12.789 1.136 1.860
If the user time is much higher than elapsed (not always -- I know, but a rule of thumb), you are probably using more than one core.