Re: [CentOS] home on nfs

2017-10-30 Thread hw
Jonathan Billings  writes:

> On Oct 28, 2017, at 23:15, hw  wrote:
>> 
>> Jonathan Billings  writes:
>> 
 On Oct 27, 2017, at 10:21, hw  wrote:
 
 Hi,
 
 I have the home directory of a user on an nfs server and mount it on a
 client.  When the user logs in, they end up in the root directory rather
 than in their actual home directory and need to cd into it.
 
 The user can read and write to their home directory, so it kinda works
 fine --- but only kinda.  When the user starts emacs, some of the
 settings in ~/.emacs are not applied, but the saved desktop is being
 loaded.
 
 Both machines are running Centos 7.4.  What could be wrong with the nfs
 mount?
>>> 
>>> Sounds like you haven’t set the selinux Boolean for NFS homedirs. 
>>> setsebool -P use_nfs_home_dirs 1
>> 
>> Oh, indeed, I didn´t know that I need to do that.
>> 
>> Do I do this on the client or on the server or both?
>
> Just the client. 

Thanks, I tried that and it works now :)


-- 
"Didn't work" is an error.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Maria 10 breaks unixodbc mysql connector

2017-10-30 Thread John Harragin
Thanks for your input.

It occurred to me that it might just be my config file that needs to be
changed along with a package installation. It was weird that it worked for
days and I was under considerable pressure to get it going quickly (while I
was on vacation) so I am returning to this a while later (with the
problematic package no longer installed). I'll look at this tomorrow and
see if this is a non-issue or not. For now, ignore it...

John

On Mon, Oct 30, 2017 at 4:19 PM, Alexander Dalloz 
wrote:

> Am 30.10.2017 um 20:22 schrieb John Harragin:
>
>> I recently installed mariadb-server 10.1 by adding the following
>> repository:
>>
>> baseurl = http://yum.mariadb.org/10.1/centos7-amd64
>>
>
> [ ... ]
>
> I could reinstall mariadb-server, add a symlink and it would probably work,
>> but I thought it would be better to post and hopefully the maintainer of
>> whichever package (unixodbc, maria, mysql-connector...) should be
>> addressed, could be alerted to this issue in the event that it could (or
>> should) be fixed on a package level.
>>
>> John
>>
>
> CentOS cannot fix packages from yum.mariadb.org.
>
> But the cloud SIG has build newer mariadb packges:
>
> https://cbs.centos.org/koji/packageinfo?packageID=434
>
> You can install them via yum too by the cloud repo.
>
> http://mirror.centos.org/centos-7/7/cloud/x86_64/openstack-ocata/common/
>
> Alexander
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with graphics on latest CentOS 6

2017-10-30 Thread m . roth
Alfred von Campe wrote:
> Am I the only one seeing this issue?  Or is it that so few people are
> still running CentOS 6.x?  Quick summary, on a very recent Dell
> motherboard using the on-board vide and booting the latest CentOS 6 kernel
> with the “vga=xxx” parameter set to any non-default value results in
> unusable X11 graphics.
>

Sorry. I run CentOS 6 at home, may be just the previous kernel, but no
issues.

 mark


> Alfred
>
>> On Oct 29, 2017, at 15:29, Alfred von Campe 
>> wrote:
>>
>> The thread "Problems with kernel-3.10.0-693.5.2.el7.x86_64” reminded me
>> that I have a similar problem but on the latest CentOS 6 kernel I’ve
>> been meaning to report.  Here is the relevant system information:
>>
>> Linux ssg003.bose.com 2.6.32-696.13.2.el6.i686 #1 SMP Thu Oct 5 20:42:25
>> UTC 2017 i686 i686 i386 GNU/Linux
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev
>> 04) (prog-if 00 [VGA controller])
>>Subsystem: Dell Device 07a2
>>Flags: bus master, fast devsel, latency 0, IRQ 11
>>Memory at f600 (64-bit, non-prefetchable) [size=16M]
>>Memory at e000 (64-bit, prefetchable) [size=256M]
>>I/O ports at f000 [size=64]
>>Expansion ROM at  [disabled]
>>Capabilities: [40] Vendor Specific Information: Len=0c 
>>Capabilities: [70] Express Root Complex Integrated Endpoint, MSI
>> 00
>>Capabilities: [ac] MSI: Enable- Count=1/1 Maskable- 64bit-
>>Capabilities: [d0] Power Management version 2
>>Capabilities: [100] #1b
>>Capabilities: [200] Address Translation Service (ATS)
>>Capabilities: [300] #13
>>
>> I have about 100 Dell desktops deployed with CentOS 6 all using the
>> built-in motherboard graphics.  But on a Dell Optiplex 5050 with an
>> Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz CPU and the above graphics card,
>> the X11 login screen is all distorted and unusable.  There is a simple
>> solution: if I remove the "vga=0x31b” parameter from the kernel boot
>> command it works just fine.  However, I would prefer to have a usable
>> alternate console on our 1900x1200 monitors, but any value I tried for
>> the vga parameter results in a distorted login screen.
>>
>> Any ideas what may be causing this?  This is only an issue on the very
>> latest chipset.  On the next most recent Dell desktops we have (Intel(R)
>> Core(TM) i5-4590 CPU @ 3.30GHz) I do not have this issue.  Here is the
>> VGA controller info:
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th
>> Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00
>> [VGA controller])
>>Subsystem: Dell Device 05a4
>>Flags: bus master, fast devsel, latency 0, IRQ 28
>>Memory at f780 (64-bit, non-prefetchable) [size=4M]
>>Memory at e000 (64-bit, prefetchable) [size=256M]
>>I/O ports at f000 [size=64]
>>Expansion ROM at  [disabled]
>>Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>Capabilities: [d0] Power Management version 2
>>Capabilities: [a4] PCI Advanced Features
>>Kernel driver in use: i915
>>Kernel modules: i915
>>
>> Does anyone else have a similar issue and found a better solution?
>>
>> Alfred
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] R: dplyr, doBy, and ggplot2 in CentOS7

2017-10-30 Thread Larry Martell
On Mon, Oct 30, 2017 at 4:03 PM, Jason Edgecombe  wrote:
> You can install any R packages from CRAN using the "install.packages()"
> command form within R itself. This will download, compile, and install the
> packages into your personal user account. you might need to install some
> supporting *-devel RPM packages via "yum", but otherwise, it should work.

Yes, but as I said I am running R from python with rpy2.

> On Mon, Oct 30, 2017 at 11:05 AM, Larry Martell 
> wrote:
>
>> On Mon, Oct 30, 2017 at 10:56 AM Tony Schreiner 
>> wrote:
>>
>> > On Mon, Oct 30, 2017 at 10:27 AM, Larry Martell > >
>> > wrote:
>> >
>> > > I have a R script that I am running from python with rpy2. On a debian
>> > > system I run this:
>> > >
>> > > apt-get install R-cran-ggplot2 R-cran-caret
>> > >
>> > > And the script works. I want to move this to CentOS 7 system. There it
>> > > cannot find R-cran-ggplot2 or R-cran-caret. Does anyone know what
>> > > packages in CentOS 7 I need for dplyr, doBy, and ggplot2?
>> > >
>> >
>> >
>> > They are not in the CentOS or epel distros. I have built both dplyr and
>> > ggplot2 for CentOS 6 and 7, using the spec file crated by R2spec (from
>> > epell) and rpmbuild. They both require building several other R packages,
>> > and a bit of tweaking to the %files portion of the spec file, but are
>> > doable. I've never tried doBy or caret.
>> > Feel free to contact me directly for more information,
>>
>>
>> Thanks for the reply. At least this will keep me from searching for them.
>> Perhaps I will stick with debian.
>>
>> >
>> >
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Maria 10 breaks unixodbc mysql connector

2017-10-30 Thread Alexander Dalloz

Am 30.10.2017 um 20:22 schrieb John Harragin:

I recently installed mariadb-server 10.1 by adding the following repository:

baseurl = http://yum.mariadb.org/10.1/centos7-amd64


[ ... ]


I could reinstall mariadb-server, add a symlink and it would probably work,
but I thought it would be better to post and hopefully the maintainer of
whichever package (unixodbc, maria, mysql-connector...) should be
addressed, could be alerted to this issue in the event that it could (or
should) be fixed on a package level.

John


CentOS cannot fix packages from yum.mariadb.org.

But the cloud SIG has build newer mariadb packges:

https://cbs.centos.org/koji/packageinfo?packageID=434

You can install them via yum too by the cloud repo.

http://mirror.centos.org/centos-7/7/cloud/x86_64/openstack-ocata/common/

Alexander


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with graphics on latest CentOS 6

2017-10-30 Thread Valeri Galtsev

On Mon, October 30, 2017 2:38 pm, Alfred von Campe wrote:
> Am I the only one seeing this issue?  Or is it that so few people are
> still running CentOS 6.x?

About 2/3 of workstations in our Department are CentS 6 (latest). Neither
of them has any video problems. All of them have decent video cards,
neither of them uses on system board (aka "motherboard") of on CPU die
video.

I know this will not help to solve your trouble...

Valeri

>  Quick summary, on a very recent Dell
> motherboard using the on-board vide and booting the latest CentOS 6 kernel
> with the “vga=xxx” parameter set to any non-default value results in
> unusable X11 graphics.
>
> Alfred
>
>> On Oct 29, 2017, at 15:29, Alfred von Campe 
>> wrote:
>>
>> The thread "Problems with kernel-3.10.0-693.5.2.el7.x86_64” reminded
>> me that I have a similar problem but on the latest CentOS 6 kernel
>> I’ve been meaning to report.  Here is the relevant system information:
>>
>> Linux ssg003.bose.com 2.6.32-696.13.2.el6.i686 #1 SMP Thu Oct 5 20:42:25
>> UTC 2017 i686 i686 i386 GNU/Linux
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev
>> 04) (prog-if 00 [VGA controller])
>>Subsystem: Dell Device 07a2
>>Flags: bus master, fast devsel, latency 0, IRQ 11
>>Memory at f600 (64-bit, non-prefetchable) [size=16M]
>>Memory at e000 (64-bit, prefetchable) [size=256M]
>>I/O ports at f000 [size=64]
>>Expansion ROM at  [disabled]
>>Capabilities: [40] Vendor Specific Information: Len=0c 
>>Capabilities: [70] Express Root Complex Integrated Endpoint, MSI
>> 00
>>Capabilities: [ac] MSI: Enable- Count=1/1 Maskable- 64bit-
>>Capabilities: [d0] Power Management version 2
>>Capabilities: [100] #1b
>>Capabilities: [200] Address Translation Service (ATS)
>>Capabilities: [300] #13
>>
>> I have about 100 Dell desktops deployed with CentOS 6 all using the
>> built-in motherboard graphics.  But on a Dell Optiplex 5050 with an
>> Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz CPU and the above graphics card,
>> the X11 login screen is all distorted and unusable.  There is a simple
>> solution: if I remove the "vga=0x31b” parameter from the kernel boot
>> command it works just fine.  However, I would prefer to have a usable
>> alternate console on our 1900x1200 monitors, but any value I tried for
>> the vga parameter results in a distorted login screen.
>>
>> Any ideas what may be causing this?  This is only an issue on the very
>> latest chipset.  On the next most recent Dell desktops we have (Intel(R)
>> Core(TM) i5-4590 CPU @ 3.30GHz) I do not have this issue.  Here is the
>> VGA controller info:
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th
>> Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00
>> [VGA controller])
>>Subsystem: Dell Device 05a4
>>Flags: bus master, fast devsel, latency 0, IRQ 28
>>Memory at f780 (64-bit, non-prefetchable) [size=4M]
>>Memory at e000 (64-bit, prefetchable) [size=256M]
>>I/O ports at f000 [size=64]
>>Expansion ROM at  [disabled]
>>Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>Capabilities: [d0] Power Management version 2
>>Capabilities: [a4] PCI Advanced Features
>>Kernel driver in use: i915
>>Kernel modules: i915
>>
>> Does anyone else have a similar issue and found a better solution?
>>
>> Alfred
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with graphics on latest CentOS 6

2017-10-30 Thread Alfred von Campe
Am I the only one seeing this issue?  Or is it that so few people are still 
running CentOS 6.x?  Quick summary, on a very recent Dell motherboard using the 
on-board vide and booting the latest CentOS 6 kernel with the “vga=xxx” 
parameter set to any non-default value results in unusable X11 graphics.

Alfred

> On Oct 29, 2017, at 15:29, Alfred von Campe  wrote:
> 
> The thread "Problems with kernel-3.10.0-693.5.2.el7.x86_64” reminded me that 
> I have a similar problem but on the latest CentOS 6 kernel I’ve been meaning 
> to report.  Here is the relevant system information:
> 
> Linux ssg003.bose.com 2.6.32-696.13.2.el6.i686 #1 SMP Thu Oct 5 20:42:25 UTC 
> 2017 i686 i686 i386 GNU/Linux
> 
> 00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev 04) 
> (prog-if 00 [VGA controller])
>Subsystem: Dell Device 07a2
>Flags: bus master, fast devsel, latency 0, IRQ 11
>Memory at f600 (64-bit, non-prefetchable) [size=16M]
>Memory at e000 (64-bit, prefetchable) [size=256M]
>I/O ports at f000 [size=64]
>Expansion ROM at  [disabled]
>Capabilities: [40] Vendor Specific Information: Len=0c 
>Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
>Capabilities: [ac] MSI: Enable- Count=1/1 Maskable- 64bit-
>Capabilities: [d0] Power Management version 2
>Capabilities: [100] #1b
>Capabilities: [200] Address Translation Service (ATS)
>Capabilities: [300] #13
> 
> I have about 100 Dell desktops deployed with CentOS 6 all using the built-in 
> motherboard graphics.  But on a Dell Optiplex 5050 with an Intel(R) Core(TM) 
> i7-7700 CPU @ 3.60GHz CPU and the above graphics card, the X11 login screen 
> is all distorted and unusable.  There is a simple solution: if I remove the 
> "vga=0x31b” parameter from the kernel boot command it works just fine.  
> However, I would prefer to have a usable alternate console on our 1900x1200 
> monitors, but any value I tried for the vga parameter results in a distorted 
> login screen.
> 
> Any ideas what may be causing this?  This is only an issue on the very latest 
> chipset.  On the next most recent Dell desktops we have (Intel(R) Core(TM) 
> i5-4590 CPU @ 3.30GHz) I do not have this issue.  Here is the VGA controller 
> info:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
> Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA 
> controller])
>Subsystem: Dell Device 05a4
>Flags: bus master, fast devsel, latency 0, IRQ 28
>Memory at f780 (64-bit, non-prefetchable) [size=4M]
>Memory at e000 (64-bit, prefetchable) [size=256M]
>I/O ports at f000 [size=64]
>Expansion ROM at  [disabled]
>Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>Capabilities: [d0] Power Management version 2
>Capabilities: [a4] PCI Advanced Features
>Kernel driver in use: i915
>Kernel modules: i915
> 
> Does anyone else have a similar issue and found a better solution?
> 
> Alfred

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Maria 10 breaks unixodbc mysql connector

2017-10-30 Thread John Harragin
I recently installed mariadb-server 10.1 by adding the following repository:

baseurl = http://yum.mariadb.org/10.1/centos7-amd64

...all was well until we had a power failure and upon rebooting unixodbc
was segfaulting. Once I did a yum undo, the mysql odbc driver was
functional.

I traced it to the following:

[root@ec-ast yum.repos.d]# ldd /usr/lib64/libmyodbc5w.so | grep -iE
"my|maria"
libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18
(0x7f3dfb34c000)
You have new mail in /var/spool/mail/root
[root@ec-ast yum.repos.d]# repoquery -l MariaDB-server MariaDB-client
MariaDB-commo MariaDB-shared galera boost-program-options jemalloc rsync
lsof | grep lib64 | grep libmysqlclient
/usr/lib64/libmysqlclient.so
/usr/lib64/libmysqlclient.so.18
/usr/lib64/libmysqlclient.so.18.0.0
/usr/lib64/libmysqlclient_r.so
/usr/lib64/libmysqlclient_r.so.18
/usr/lib64/libmysqlclient_r.so.18.0.0

...notice the change in the path (/usr/lib64/mysql/).

I could reinstall mariadb-server, add a symlink and it would probably work,
but I thought it would be better to post and hopefully the maintainer of
whichever package (unixodbc, maria, mysql-connector...) should be
addressed, could be alerted to this issue in the event that it could (or
should) be fixed on a package level.

John
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Gulliver

2017-10-30 Thread Stephen John Smoogen
On 30 October 2017 at 13:07, Chris Olson  wrote:
> We have been fortunate to hang onto one of our summer interns
> for part time work on weekends during the current school year.
> One of the intern's jobs is to load documents and data which
> are then processed.  The documents are .txt, .docx, and .pdf
> files. The data files are raw sensor outputs usually captured
> using ADCs mostly with eight bit precision.  All files are
> loaded or moved from one machine to another with sftp.
>
> The intern noticed right a way that the documents will transfer
> perfectly from our PPC and SPARC machines to our Intel/CentOS
> platforms.  The raw data files, not so much.  There is always
> an Endian (Thanks Gulliver) issue, which we assume is due to
> the bytes of data being formatted into 32 bit words somewhere
> in the Big Endian systems.  It is not totally clear why the
> document files do not have this issue.  If there is a known
> principle behind these observations, we would appreciate very
> much any information that can shared.
>
>

Text files which are ascii are generally 7->8 bit so don't tend to
have bit endian problems in 8+ bit architectures. [I expect a 4 bit
architecture would have problems].  Now 8+ bit UTF can have some
problems with endianess but it is usually not following some standard
and assuming that writing data works the same as it did with ascii
(mainly because few people dealt with 4 bit computers).

docx and pdf is written for a fixed endian format so even if
built/written on a big endian system the data itself is formatted to
be little endian. Raw data files are usually endian if they are 'raw'
memory dumps or similar. Some 'data' formats which are mostly raw are
actually written to a standard which will work because both the little
endian and big endian expects the data to be written in 'big' or
'little' endian and read in as such.



> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Gulliver

2017-10-30 Thread Peter Kjellström
On Mon, 30 Oct 2017 17:07:31 + (UTC)
Chris Olson  wrote:

> We have been fortunate to hang onto one of our summer interns
> for part time work on weekends during the current school year.
> One of the intern's jobs is to load documents and data which
> are then processed.  The documents are .txt, .docx, and .pdf
> files. The data files are raw sensor outputs usually captured
> using ADCs mostly with eight bit precision.  All files are
> loaded or moved from one machine to another with sftp.
> 
> The intern noticed right a way that the documents will transfer
> perfectly from our PPC and SPARC machines to our Intel/CentOS
> platforms.  The raw data files, not so much.  There is always
> an Endian (Thanks Gulliver) issue, which we assume is due to
> the bytes of data being formatted into 32 bit words somewhere
> in the Big Endian systems.  It is not totally clear why the
> document files do not have this issue.  If there is a known
> principle behind these observations, we would appreciate very
> much any information that can shared.

Transferring a file will not change anything. It will be bit-wise
identical.

However the data in the file may be in bit-wise little or big endian
order. A file format may or may not have metadata indicating this.
That is, some files will read differently on different arch'es and
some will be immune (due to more sophisticated abstractions).

So it's not surprising that your raw files will have problems.

If you want to prove this to yourself simply md5sum/sha1sum/etc the
files on both sides.

/Peter K
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Gulliver

2017-10-30 Thread Chris Olson
We have been fortunate to hang onto one of our summer interns
for part time work on weekends during the current school year.
One of the intern's jobs is to load documents and data which
are then processed.  The documents are .txt, .docx, and .pdf
files. The data files are raw sensor outputs usually captured
using ADCs mostly with eight bit precision.  All files are
loaded or moved from one machine to another with sftp.

The intern noticed right a way that the documents will transfer
perfectly from our PPC and SPARC machines to our Intel/CentOS
platforms.  The raw data files, not so much.  There is always
an Endian (Thanks Gulliver) issue, which we assume is due to
the bytes of data being formatted into 32 bit words somewhere
in the Big Endian systems.  It is not totally clear why the
document files do not have this issue.  If there is a known
principle behind these observations, we would appreciate very
much any information that can shared.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] R: dplyr, doBy, and ggplot2 in CentOS7

2017-10-30 Thread Jason Edgecombe
You can install any R packages from CRAN using the ​"install.packages()"
command form within R itself. This will download, compile, and install the
packages into your personal user account. you might need to install some
supporting *-devel RPM packages via "yum", but otherwise, it should work.

---
Jason Edgecombe | Linux Administrator
UNC Charlotte | The William States Lee College of Engineering
9201 University City Blvd. | Charlotte, NC 28223-0001
Phone: 704-687-1943
jwedg...@uncc.edu | http://engr.uncc.edu |  Facebook
---
If you are not the intended recipient of this transmission or a person
responsible for delivering it to the intended recipient, any disclosure,
copying, distribution, or other use of any of the information in this
transmission is strictly prohibited. If you have received this transmission
in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

On Mon, Oct 30, 2017 at 11:05 AM, Larry Martell 
wrote:

> On Mon, Oct 30, 2017 at 10:56 AM Tony Schreiner 
> wrote:
>
> > On Mon, Oct 30, 2017 at 10:27 AM, Larry Martell  >
> > wrote:
> >
> > > I have a R script that I am running from python with rpy2. On a debian
> > > system I run this:
> > >
> > > apt-get install R-cran-ggplot2 R-cran-caret
> > >
> > > And the script works. I want to move this to CentOS 7 system. There it
> > > cannot find R-cran-ggplot2 or R-cran-caret. Does anyone know what
> > > packages in CentOS 7 I need for dplyr, doBy, and ggplot2?
> > >
> >
> >
> > They are not in the CentOS or epel distros. I have built both dplyr and
> > ggplot2 for CentOS 6 and 7, using the spec file crated by R2spec (from
> > epell) and rpmbuild. They both require building several other R packages,
> > and a bit of tweaking to the %files portion of the spec file, but are
> > doable. I've never tried doBy or caret.
> > Feel free to contact me directly for more information,
>
>
> Thanks for the reply. At least this will keep me from searching for them.
> Perhaps I will stick with debian.
>
> >
> >
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] How to encourage maintainers to update their software

2017-10-30 Thread vychytraly .
Thank you all very much for explaining this, it is very interesting topic :)

On Mon, Oct 30, 2017 at 12:27 PM, James Hogarth 
wrote:

> On 29 October 2017 at 13:40, vychytraly .  wrote:
> > Frank please could you explain how to create rpms for el7 from fedora
> > src.rpms?
> >
> >
>
> You may find this a useful read:
>
> https://www.hogarthuk.com/?q=node/11
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] NBD does not compile for 3.10.0-514.26.2.el7.x86_64

2017-10-30 Thread Phil Perry

On 30/10/17 14:19, Thanos Makatos wrote:

Compiling NBD kernel module for kernel 3.10.0-514.26.2.el7.x86_64
fails as follows:

# make -C ../../ M=`pwd` nbd.o
make: Entering directory
`/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64'
   CC  
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:
In function ‘__nbd_ioctl’:
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19:
error: ‘REQ_TYPE_SPECIAL’ undeclared (first use in this function)
sreq.cmd_type = REQ_TYPE_SPECIAL;
^
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19:
note: each undeclared identifier is reported only once for each
function it appears in
make[1]: *** 
[/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o]
Error 1
make: *** [nbd.o] Error 2
make: Leaving directory
`/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64'

Was support for NBD dropped or was this just a human error?



Because Red Hat do not configure and build this module, they do not 
maintain the code for it in their kernel.


REQ_TYPE_SPECIAL was renamed to REQ_TYPE_DRV_PRIV some time back, so try 
patching for that in nbd.c and rebuilding.


Be aware that by building the unmaintained module you will be missing 
all relevant security patches for this module since RHEL7 was first 
released some 3.5 years ago. A better solution would be to backport the 
module from the latest upstream kernel and maintain it out of tree.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] R: dplyr, doBy, and ggplot2 in CentOS7

2017-10-30 Thread Larry Martell
On Mon, Oct 30, 2017 at 10:56 AM Tony Schreiner 
wrote:

> On Mon, Oct 30, 2017 at 10:27 AM, Larry Martell 
> wrote:
>
> > I have a R script that I am running from python with rpy2. On a debian
> > system I run this:
> >
> > apt-get install R-cran-ggplot2 R-cran-caret
> >
> > And the script works. I want to move this to CentOS 7 system. There it
> > cannot find R-cran-ggplot2 or R-cran-caret. Does anyone know what
> > packages in CentOS 7 I need for dplyr, doBy, and ggplot2?
> >
>
>
> They are not in the CentOS or epel distros. I have built both dplyr and
> ggplot2 for CentOS 6 and 7, using the spec file crated by R2spec (from
> epell) and rpmbuild. They both require building several other R packages,
> and a bit of tweaking to the %files portion of the spec file, but are
> doable. I've never tried doBy or caret.
> Feel free to contact me directly for more information,


Thanks for the reply. At least this will keep me from searching for them.
Perhaps I will stick with debian.

>
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] R: dplyr, doBy, and ggplot2 in CentOS7

2017-10-30 Thread Tony Schreiner
On Mon, Oct 30, 2017 at 10:27 AM, Larry Martell 
wrote:

> I have a R script that I am running from python with rpy2. On a debian
> system I run this:
>
> apt-get install R-cran-ggplot2 R-cran-caret
>
> And the script works. I want to move this to CentOS 7 system. There it
> cannot find R-cran-ggplot2 or R-cran-caret. Does anyone know what
> packages in CentOS 7 I need for dplyr, doBy, and ggplot2?
>


They are not in the CentOS or epel distros. I have built both dplyr and
ggplot2 for CentOS 6 and 7, using the spec file crated by R2spec (from
epell) and rpmbuild. They both require building several other R packages,
and a bit of tweaking to the %files portion of the spec file, but are
doable. I've never tried doBy or caret.
Feel free to contact me directly for more information,

Tony Schreiner
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] R: dplyr, doBy, and ggplot2 in CentOS7

2017-10-30 Thread Larry Martell
I have a R script that I am running from python with rpy2. On a debian
system I run this:

apt-get install R-cran-ggplot2 R-cran-caret

And the script works. I want to move this to CentOS 7 system. There it
cannot find R-cran-ggplot2 or R-cran-caret. Does anyone know what
packages in CentOS 7 I need for dplyr, doBy, and ggplot2?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] NBD does not compile for 3.10.0-514.26.2.el7.x86_64

2017-10-30 Thread Thanos Makatos
Compiling NBD kernel module for kernel 3.10.0-514.26.2.el7.x86_64
fails as follows:

# make -C ../../ M=`pwd` nbd.o
make: Entering directory
`/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64'
  CC  
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:
In function ‘__nbd_ioctl’:
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19:
error: ‘REQ_TYPE_SPECIAL’ undeclared (first use in this function)
   sreq.cmd_type = REQ_TYPE_SPECIAL;
   ^
/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19:
note: each undeclared identifier is reported only once for each
function it appears in
make[1]: *** 
[/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o]
Error 1
make: *** [nbd.o] Error 2
make: Leaving directory
`/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64'

Was support for NBD dropped or was this just a human error?

-- 
Thanos Makatos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] How to encourage maintainers to update their software

2017-10-30 Thread James Hogarth
On 29 October 2017 at 13:40, vychytraly .  wrote:
> Frank please could you explain how to create rpms for el7 from fedora
> src.rpms?
>
>

You may find this a useful read:

https://www.hogarthuk.com/?q=node/11
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Comparing directories recursively

2017-10-30 Thread Tony Mountifield
In article <20171027175431.e265479c4f9b4658fe217...@sasktel.net>,
Frank Cox  wrote:
> On Sat, 28 Oct 2017 00:47:32 +0200
> Leon Fauster wrote:
> 
> > source:
> > 
> > find . -type f -exec md5sum \{\} \; > checksum.list
> > 
> > destination:
> > 
> > md5sum -c checksum.list
> 
> Wouldn't diff be faster because it doesn't have to read to the end of every 
> file and it isn't really calculating
> anything?  Or am I looking at this in the wrong way.

If the files are the same (which is what the OP is hoping), then diff does
indeed have to read to the end of both files to be certain of this. Only
if they differ can it stop reading the files as soon as a difference
between them is found.

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos