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

[CentOS-announce] CESA-2017:3081 Important CentOS 7 tomcat Security Update

2017-10-30 Thread Johnny Hughes 

CentOS Errata and Security Advisory 2017:3081 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2017:3081

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
1d033d848fb070ce731bfc768129169c2cd611bc11dc8653f5c58cb1bdfd05b9  
tomcat-7.0.76-3.el7_4.noarch.rpm
3fef90d9cd773b7c399ed6ad442d6bc6380c0c314e99d92d583c8aae5b369c70  
tomcat-admin-webapps-7.0.76-3.el7_4.noarch.rpm
cc9dd653559a23925e450bfb446d94d2bda2a98f22bf4109e030240fa2ad20a3  
tomcat-docs-webapp-7.0.76-3.el7_4.noarch.rpm
156136608e5705defebcd04383800714ac64368b390e1992099db8fe147046eb  
tomcat-el-2.2-api-7.0.76-3.el7_4.noarch.rpm
aaa1246b0c12bd623bba6542c6cedaad6a97d3e38fad4966e1f7fbbadb6908ed  
tomcat-javadoc-7.0.76-3.el7_4.noarch.rpm
3286080d1506c088e8e68c9c41ed8fd5724465ab5b7e322ef9c8ff6d6d60df16  
tomcat-jsp-2.2-api-7.0.76-3.el7_4.noarch.rpm
f6c79a4f7d436f6f619be26db6eef983ab97add568110ad8aa23ee0ea50e7eb3  
tomcat-jsvc-7.0.76-3.el7_4.noarch.rpm
5c867e9a48a014d635134a35b7cfa16433bf58119cca39a0194e4163dff5ed54  
tomcat-lib-7.0.76-3.el7_4.noarch.rpm
961dc90fbf11540be166f76a98224ca6ec920060a48bfdab9d2ef525026991f2  
tomcat-servlet-3.0-api-7.0.76-3.el7_4.noarch.rpm
6415299b2dd85e5fd14ac1b183dc1a297f94db23ad0be08ea8e7d0ae53dc  
tomcat-webapps-7.0.76-3.el7_4.noarch.rpm

Source:
3b05b59c5528f3efa27c0d843a6801a0c9ba8804aff08ffb0b6103379b84cd2a  
tomcat-7.0.76-3.el7_4.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

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

[CentOS-announce] CESA-2017:3080 Important CentOS 6 tomcat6 Security Update

2017-10-30 Thread Johnny Hughes 

CentOS Errata and Security Advisory 2017:3080 Important

Upstream details at : https://access.redhat.com/errata/RHSA-2017:3080

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
f54b6d93d6877aa8d15e0b1910dab0560b9f439ac53cc6171c7da57d5287e3be  
tomcat6-6.0.24-111.el6_9.noarch.rpm
0249d6b4061656e106a48680caa74706e6a856640bf304d1d7534c59a6eacb7b  
tomcat6-admin-webapps-6.0.24-111.el6_9.noarch.rpm
d67864afbf9585832bfbc2711b89a628d1cc1be4bea3d075b93318115a50fd84  
tomcat6-docs-webapp-6.0.24-111.el6_9.noarch.rpm
3653f1d30cdb47d423b28ecf217bcba8346ec2849ca00c329a692d872088173b  
tomcat6-el-2.1-api-6.0.24-111.el6_9.noarch.rpm
0f597cddfa8240ccc4606542f52f664783d55162ea2a2b5f48f3efdb0d953982  
tomcat6-javadoc-6.0.24-111.el6_9.noarch.rpm
709845ffeb526027fba6f819236edeb50f21fe59e67eb55eb76fbbee31635708  
tomcat6-jsp-2.1-api-6.0.24-111.el6_9.noarch.rpm
6cb703774287209f9c8c591007798309089446a76c621a91b2200c1a2504b924  
tomcat6-lib-6.0.24-111.el6_9.noarch.rpm
d48b5d92a79b9b98f74fd007dd16c96314e6f51c58563487f16a74146d9f64ea  
tomcat6-servlet-2.5-api-6.0.24-111.el6_9.noarch.rpm
88ec61de388e1dd353e87636442ee7fb835ab5212645652bab3f2a5464b2f317  
tomcat6-webapps-6.0.24-111.el6_9.noarch.rpm

x86_64:
f54b6d93d6877aa8d15e0b1910dab0560b9f439ac53cc6171c7da57d5287e3be  
tomcat6-6.0.24-111.el6_9.noarch.rpm
0249d6b4061656e106a48680caa74706e6a856640bf304d1d7534c59a6eacb7b  
tomcat6-admin-webapps-6.0.24-111.el6_9.noarch.rpm
d67864afbf9585832bfbc2711b89a628d1cc1be4bea3d075b93318115a50fd84  
tomcat6-docs-webapp-6.0.24-111.el6_9.noarch.rpm
3653f1d30cdb47d423b28ecf217bcba8346ec2849ca00c329a692d872088173b  
tomcat6-el-2.1-api-6.0.24-111.el6_9.noarch.rpm
0f597cddfa8240ccc4606542f52f664783d55162ea2a2b5f48f3efdb0d953982  
tomcat6-javadoc-6.0.24-111.el6_9.noarch.rpm
709845ffeb526027fba6f819236edeb50f21fe59e67eb55eb76fbbee31635708  
tomcat6-jsp-2.1-api-6.0.24-111.el6_9.noarch.rpm
6cb703774287209f9c8c591007798309089446a76c621a91b2200c1a2504b924  
tomcat6-lib-6.0.24-111.el6_9.noarch.rpm
d48b5d92a79b9b98f74fd007dd16c96314e6f51c58563487f16a74146d9f64ea  
tomcat6-servlet-2.5-api-6.0.24-111.el6_9.noarch.rpm
88ec61de388e1dd353e87636442ee7fb835ab5212645652bab3f2a5464b2f317  
tomcat6-webapps-6.0.24-111.el6_9.noarch.rpm

Source:
ba857eb2777da91f86634ead63fa60f762cd4035919bef69966d7d95ee708c79  
tomcat6-6.0.24-111.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

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

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