Re: [CentOS-virt] Running graphical applications from CentOS headless vm

2017-02-25 Thread Akemi Yagi 
On Sat, Feb 25, 2017 at 10:49 PM, C. L. Martinez  wrote:
> Hi all,
>
>  I have installed a CentOS7 vm in my home server with all graphical tools 
> installed: Gnome, Chrome, Tor Borwser, etc. My idea is to run these graphical 
> applications from two MacOSX desktops. What I am looking for is something 
> similar like Microsoft RDP services that supports copy and paste between 
> client and server, sound, clipboard, etc ...
>
>  I have seen a possible solution using xrdp: http://www.xrdp.org. But exists 
> some other solution??

To connect to remote desktops, you can try x2go (x2goserver from
EPEL). I think the client is available for MacOSX.

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

[CentOS-virt] Running graphical applications from CentOS headless vm

2017-02-25 Thread C. L. Martinez 
Hi all,

 I have installed a CentOS7 vm in my home server with all graphical tools 
installed: Gnome, Chrome, Tor Borwser, etc. My idea is to run these graphical 
applications from two MacOSX desktops. What I am looking for is something 
similar like Microsoft RDP services that supports copy and paste between client 
and server, sound, clipboard, etc ...

 I have seen a possible solution using xrdp: http://www.xrdp.org. But exists 
some other solution??

Thanks.
-- 
Greetings,
C. L. Martinez
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] Installing support for Chinese text in Centos 7

2017-02-25 Thread Scott Robbins 
On Sat, Feb 25, 2017 at 08:51:41PM -0500, Scott Robbins wrote:
> On Sat, Feb 25, 2017 at 08:42:43PM -0500, H wrote:
> > I have just done a minimal installation of Centos7 followed by X Windows 
> > and the Mate desktop on a workstation. Although the default language is 
> > English, I would like to be able to write Chinese text in various 
> > applications.
> > 
> > I seem to remember this was very easy to do in Centos 6 and Gnome: possibly 
> > only requiring only a simple 'yum groupinstall "Chinese Support"' after 
> > which I could use iBus to switch between languages. This does not seem to 
> > work in Centos 7.
> > 
> 
> 
> These days, I use fcitx-anthy on CentOS (which took some work to set up,
> but ibus-anthy, at least, (for Japanese) worked pretty well. I have
> instructions, again, for Japanese, but quite possibly applicable at
> http://srobb.net/jpninpt.html#CentOS6

I'm going to add that a quick look through pkgs.org shows that CentOS-7x
does have packages for fcitx-pinyin and a few other Chinese engines, and it
might be worth considering making the switch. It seems (general impression
on my part) to be replacing ibus in a lot of places, in the same way ibus
gradually replaced scim. 


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

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

Re: [CentOS] Installing support for Chinese text in Centos 7

2017-02-25 Thread Scott Robbins 
On Sat, Feb 25, 2017 at 08:42:43PM -0500, H wrote:
> I have just done a minimal installation of Centos7 followed by X Windows and 
> the Mate desktop on a workstation. Although the default language is English, 
> I would like to be able to write Chinese text in various applications.
> 
> I seem to remember this was very easy to do in Centos 6 and Gnome: possibly 
> only requiring only a simple 'yum groupinstall "Chinese Support"' after which 
> I could use iBus to switch between languages. This does not seem to work in 
> Centos 7.
> 


These days, I use fcitx-anthy on CentOS (which took some work to set up,
but ibus-anthy, at least, (for Japanese) worked pretty well. I have
instructions, again, for Japanese, but quite possibly applicable at
http://srobb.net/jpninpt.html#CentOS6


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

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

[CentOS] Installing support for Chinese text in Centos 7

2017-02-25 Thread H 

I have just done a minimal installation of Centos7 followed by X Windows and 
the Mate desktop on a workstation. Although the default language is English, I 
would like to be able to write Chinese text in various applications.

I seem to remember this was very easy to do in Centos 6 and Gnome: possibly only 
requiring only a simple 'yum groupinstall "Chinese Support"' after which I 
could use iBus to switch between languages. This does not seem to work in Centos 7.

Suggestions? Thank you.

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

Re: [CentOS-es] Servidor pierde conectividad

2017-02-25 Thread Ricardo J. Barberis 
El Miércoles 22/02/2017, Rommel Rodriguez Toirac escribió:
[ ... ]
>  Ya resolví el problema que tenía con la perdida de conectividad del
> servidor, pero me queda la duda de qué causa esa situación y como
> eliminarla. Les comento: Me di cuenta de algo, las dirección MAC del
> dispositivo de red del servidor en cuestión cambia. Por ejemplo, cuando
> hago un arping desde mi estación de trabajo Kubuntu 16.04, miren lo que
> sucede:

Definitivamente tienes otro dispositivo con la IP 192.168.41.4 configurada 
pero que no responde a los pings (configuracion habitual de los escritorios 
Windows si no me equivoco).

Segun http://www.coffer.com/mac_find/ la MAC 00:1D:09:FF:44:4B corresponde a 
un dispositivo Dell, por si te sirve para rastrearlo.

Tienes un servidor DHCP en tu red? Probablemente este dando direcciones del 
rango 192.168.41.0/24 que no deberia.

> rommel@p6:~$ arping 192.168.41.4
> ARPING 192.168.41.4 from 192.168.41.6 enp3s0
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.653ms
> Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03]  0.683ms
> Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03]  0.622ms
> Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03]  0.631ms
> ^CSent 3 probes (1 broadcast(s))
> Received 4 response(s)
>
> La primera respuesta viene con una dirección MAC diferente a las demás.
> Pero cuando hago arping desde el mismo servidor a su misma dirección IP
> miren la MAC que me contesta:
>
> [root@pgtm ] arping 192.168.41.4 -I eth1
> ARPING 192.168.41.4 from 192.168.41.4 eth1
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.658ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.654ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.654ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.662ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.655ms
> Sent 5 probes (1 broadcast(s))
> Received 5 response(s)
>
>  Cuando miro con ifconfig las configuraciones de los dispositivos de red,
> en ningún lugar encuentro la MAC 00:1D:09:FF:44:4B
>
> [root@pgtm ] ifconfig
> eth0  Link encap:Ethernet  HWaddr 6C:92:BF:26:C7:02
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Memory:c722-c723
>
> eth1  Link encap:Ethernet  HWaddr 6C:92:BF:26:C7:03
>   inet addr:192.168.41.4  Bcast:192.168.41.255  Mask:255.255.255.0
>   inet6 addr: fe80::6e92:bfff:fe26:c703/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:95819 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1924 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:11728605 (11.1 MiB)  TX bytes:263674 (257.4 KiB)
>   Memory:c720-c721
>
> eth2  Link encap:Ethernet  HWaddr 00:E0:ED:33:4E:9C
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Memory:c712-c713
>
> eth3  Link encap:Ethernet  HWaddr 00:E0:ED:33:4E:9D
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>   Memory:c710-c711
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:249609 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:249609 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:52090343 (49.6 MiB)  TX bytes:52090343 (49.6 MiB)
>
>  La solución fue asignarle otra dirección IP a ese servidor y todo se
> resolvió; pero ¿por qué sucede eso?, ¿como eliminar el enlace entre la
> dirección 192.168.41.4 y la dirección MAC 00:1D:09:FF:44:4B? y por último
> ¿donde estara almacenado ese enlace, pues en este momento la dirección IP
> 192.168.41.4 no está asignada a nada en mi red (ni printserver, ni switch,
> ni router, ni estaciones de trabajo o servidores) y sin embargo cuando hago
> un arping 192.168.41.4 obtengo respuesta?
>
> rommel@p6:~$ arping 192.168.41.4
> ARPING 192.168.41.4 from 192.168.41.6 enp3s0
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.631ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.623ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.623ms
> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B]  0.691ms
> ^CSent

Re: [CentOS] RHEL 8 speculation ???

2017-02-25 Thread Alice Wonder 
Never been a fan of static linking. Exploit in a library and you have to 
rebuild everything that links against it.


That's one of the problems in the android world. Some library is found 
to be vulnerable, it gets fixed, but a lot of apps on the play store 
remain vulnerable simply because the vendor never submitted a rebuild.


That's also my beef with php composer, a lot of webapps lock the version 
of the library they use and composer happily grabs the crusty old 
version with its flaws.


But anyway, not suggesting a whole new OS just because of gcc and boost. 
It's a trend I've been seeing where recently, more and more apps refuse 
to build become one or more of the build dependencies is too old.


There's always a solution, but its nice when things just work.

On 02/25/2017 10:31 AM, Yan Li wrote:

We use GCC 6 from SoftwareCollection 6 and build our own Boost libraries with 
static linking. The result binaries work on all C7 instances just fine without 
the need to install any extra packages. The binary size isn't bloated too much 
by statically linking Boost, because many Boost functions are header templates 
anyway (but your mileage may vary).

Not sure if you have other dependencies but we never feel the need to upgrade 
the whole OS just to get a newer GCC and Boost.

Yan


On Feb 25, 2017, at 6:23 AM, Johnny Hughes  wrote:


On 02/25/2017 02:20 AM, Alice Wonder wrote:
Is there any blog that has information on a potential RHEL 8 release date?

boost in 7 is now too old for some things, in addition to gcc. There are
solutions in 7 to those issues but it's starting to feel like 6 felt
shortly before 7 came out, so I wonder if it is getting near to time.

I'm working on a major project bitcoin related and it would be
frustrating to deploy a bunch of CentOS 7 virtual machines only to have
8 come out fairly soon afterwards.


I have no real information on this either .. but one thing to think
about is that RHEL-7 is much less conservative with 'rebases' than the
older RHEL versions.  (Case in point, major shifts in Gnome, KDE, Xorg,
etc.)

With containers and software collections, and with more aggressive
rebases in the Desktop space, I see the timelines becoming a little
longer between major versions.

Also, as others have said, I see no alpha or beta for RHEL-8 anywhere.
RHEL-5 does go EOL at the end of March 2017, so I guess a beta could
happen soon(ish).


___
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

[CentOS] Problem loading the VM after reboots.

2017-02-25 Thread Subscriber 

I had a strange problem. After restarting the VM can not always run.
The last line in the console (virsh console):

init: Re-executing /sbin/init
Please stand by while rebooting the system...
Restarting system.
machine restart

At this time, one of the CPU core is loaded 100% (qemu-kvm process,
top command)

%Cpu7  : 41.8 us, 57.6 sy,  0.0 ni,  0.6 id,  0.0 wa,  0.0 hi,  0.0
si,  0.0 st

# free
  totalusedfree  shared  buff/cache  
available
Mem:8009692  377744 11640769392 6467872  
7299800
Swap:   2097148   0 2097148

This behavior only when the virtual machine CentOS 6.8 and HV CentOS
7.3.1116. Unsuccessful restart may occur after 2 successful, and maybe
after 5 successful, and maybe on the first reboot. No clear pattern of
a problem I have not seen. Tested different VM.

Here's how behaved virtual machine if its reboot through virsh reboot:

virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed
virsh # start test1
Domain test1 started
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed
virsh # start test1
Domain test1 started
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted 
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed

If the VM shutdown and then start, the problem does not occur.
The problem does not occur if the VM CentOS 7.3.1611 (10 successful
reboots of 10) or if the VM Windows Server 2008 R2 (10 successful
reboots of 10).
If the VM CentOS 6.8 and HV CentOS 6.8 the problem does not occur.

First HV is:
CentOS 7.3.1611 with 3.10.0-514.6.2.el7.x86_64 and
3.10.0-514.6.1.el7.x86_64
qemu-kvm-ev.x86_6410:2.6.0-28.el7_3.3.1
libvirt.x86_642.0.0-10.el7_3.4

Kernel module: 
kvm_intel 170181
kvm   554609

Second HV is:
CentOS 7.3.1611 with 3.10.0-514.6.2.el7.x86_64

qemu-kvm.x86_6410:1.5.3-126.el7_3.3
libvirt.x86_642.0.0-10.el7_3.4

Kernel module: 
kvm_intel 170181
kvm   554609

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

[CentOS-virt] Problem loading the VM after reboots.

2017-02-25 Thread Subscriber 

I had a strange problem. After restarting the VM can not always run.
The last line in the console (virsh console):

init: Re-executing /sbin/init
Please stand by while rebooting the system...
Restarting system.
machine restart

At this time, one of the CPU core is loaded 100% (qemu-kvm process,
top command)

%Cpu7  : 41.8 us, 57.6 sy,  0.0 ni,  0.6 id,  0.0 wa,  0.0 hi,  0.0
si,  0.0 st

# free
  totalusedfree  shared  buff/cache  
available
Mem:8009692  377744 11640769392 6467872  
7299800
Swap:   2097148   0 2097148

This behavior only when the virtual machine CentOS 6.8 and HV CentOS
7.3.1116. Unsuccessful restart may occur after 2 successful, and maybe
after 5 successful, and maybe on the first reboot. No clear pattern of
a problem I have not seen. Tested different VM.

Here's how behaved virtual machine if its reboot through virsh reboot:

virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed
virsh # start test1
Domain test1 started
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed
virsh # start test1
Domain test1 started
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted 
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # reboot test1
Domain test1 is being rebooted
virsh # destroy test1
Domain test1 destroyed

If the VM shutdown and then start, the problem does not occur.
The problem does not occur if the VM CentOS 7.3.1611 (10 successful
reboots of 10) or if the VM Windows Server 2008 R2 (10 successful
reboots of 10).
If the VM CentOS 6.8 and HV CentOS 6.8 the problem does not occur.

First HV is:
CentOS 7.3.1611 with 3.10.0-514.6.2.el7.x86_64 and
3.10.0-514.6.1.el7.x86_64
qemu-kvm-ev.x86_6410:2.6.0-28.el7_3.3.1
libvirt.x86_642.0.0-10.el7_3.4

Kernel module: 
kvm_intel 170181
kvm   554609

Second HV is:
CentOS 7.3.1611 with 3.10.0-514.6.2.el7.x86_64

qemu-kvm.x86_6410:1.5.3-126.el7_3.3
libvirt.x86_642.0.0-10.el7_3.4

Kernel module: 
kvm_intel 170181
kvm   554609

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

Re: [CentOS] RHEL 8 speculation ???

2017-02-25 Thread Yan Li 
We use GCC 6 from SoftwareCollection 6 and build our own Boost libraries with 
static linking. The result binaries work on all C7 instances just fine without 
the need to install any extra packages. The binary size isn't bloated too much 
by statically linking Boost, because many Boost functions are header templates 
anyway (but your mileage may vary). 

Not sure if you have other dependencies but we never feel the need to upgrade 
the whole OS just to get a newer GCC and Boost. 

Yan

> On Feb 25, 2017, at 6:23 AM, Johnny Hughes  wrote:
> 
>> On 02/25/2017 02:20 AM, Alice Wonder wrote:
>> Is there any blog that has information on a potential RHEL 8 release date?
>> 
>> boost in 7 is now too old for some things, in addition to gcc. There are
>> solutions in 7 to those issues but it's starting to feel like 6 felt
>> shortly before 7 came out, so I wonder if it is getting near to time.
>> 
>> I'm working on a major project bitcoin related and it would be
>> frustrating to deploy a bunch of CentOS 7 virtual machines only to have
>> 8 come out fairly soon afterwards.
> 
> I have no real information on this either .. but one thing to think
> about is that RHEL-7 is much less conservative with 'rebases' than the
> older RHEL versions.  (Case in point, major shifts in Gnome, KDE, Xorg,
> etc.)
> 
> With containers and software collections, and with more aggressive
> rebases in the Desktop space, I see the timelines becoming a little
> longer between major versions.
> 
> Also, as others have said, I see no alpha or beta for RHEL-8 anywhere.
> RHEL-5 does go EOL at the end of March 2017, so I guess a beta could
> happen soon(ish).
> 
> 
> ___
> 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-announce] CESA-2017:0323 Important CentOS 5 kernel Security Update

2017-02-25 Thread Johnny Hughes 

CentOS Errata and Security Advisory 2017:0323 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0323.html

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

i386:
019a5946e25b89c2d0ee356e588f0fa0899a8e0742d7fb54ff075c8ba2085d41  
kernel-2.6.18-419.el5.i686.rpm
04999d388f09b47faad898788ddb48706ae83e941ba8d4f8b3d0922b0d757937  
kernel-debug-2.6.18-419.el5.i686.rpm
bce1ad740f84730eac3e6ad8153c4748e45485fea938ddcb512c8fab5200bec6  
kernel-debug-devel-2.6.18-419.el5.i686.rpm
2029c432d99fb27611918b74a087d4280b13d5b08a80211b30fb7d61ee6b427f  
kernel-devel-2.6.18-419.el5.i686.rpm
44c69f8dc8622d48b018ca658b6ffebb2ab9a4bde2e2ab996bf55c8395c32bb4  
kernel-doc-2.6.18-419.el5.noarch.rpm
f50709be8b7678576e31dd4f0be48a56373ea9dff41de1518f1f1a72344487a4  
kernel-headers-2.6.18-419.el5.i386.rpm
a95b656d0a233a9c65b503524ae9153052ca16f1932140e7d8bd0a5a9d020969  
kernel-PAE-2.6.18-419.el5.i686.rpm
913b066902e9a694cd8dacfed10cccad3828ea117705df72b31c44e0174f534e  
kernel-PAE-devel-2.6.18-419.el5.i686.rpm
1df361995538b14778060829f9bdc2506b91fe56135570e53f0b6c8d348998ab  
kernel-xen-2.6.18-419.el5.i686.rpm
626c4071b7811031ed605c17e54fd1185765d38d2912bf377a23d3486836e729  
kernel-xen-devel-2.6.18-419.el5.i686.rpm

x86_64:
6c4558babe0b37022c1999231ad64116767001ef414bd8b65d66918a56dcaed1  
kernel-2.6.18-419.el5.x86_64.rpm
e7dec9fb687ef00bb29351361e7e5365b324046a9223f8fe363a809f6344c597  
kernel-debug-2.6.18-419.el5.x86_64.rpm
687f5550c5a35526c37f213f303b635078e9cdfa13534a84f7be88d2d37b5954  
kernel-debug-devel-2.6.18-419.el5.x86_64.rpm
dd57d4ca8c328a0701a4bdf2c571ba16d28cfadfda4d7329a1d89b74d2a45f1b  
kernel-devel-2.6.18-419.el5.x86_64.rpm
44c69f8dc8622d48b018ca658b6ffebb2ab9a4bde2e2ab996bf55c8395c32bb4  
kernel-doc-2.6.18-419.el5.noarch.rpm
ab01f7fe8a199ec0debbbe8ee672eb3d9ad7191305b75d5b4afdff957b15f569  
kernel-headers-2.6.18-419.el5.x86_64.rpm
f846028137b73dc155e20b78ad9726ed54936ca4953743cad43d35907229962a  
kernel-xen-2.6.18-419.el5.x86_64.rpm
1f37799de9f2a3910ce1ca37be50b325943e9842051a633e6ba1d041ac784dd9  
kernel-xen-devel-2.6.18-419.el5.x86_64.rpm

Source:
c37156be43391a11612a558e2b9732fdf37da0002d0eeb0d4aecd57bcd497cce  
kernel-2.6.18-419.el5.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] Would this be considered a packaging bug?

2017-02-25 Thread Alice Wonder 

On 02/25/2017 07:27 AM, Alice Wonder wrote:

On 02/25/2017 06:33 AM, Alice Wonder wrote:

On 02/25/2017 06:12 AM, Johnny Hughes wrote:

On 02/25/2017 06:52 AM, Alice Wonder wrote:

https://koji.fedoraproject.org/koji/buildinfo?buildID=861692

The source RPM there uses

%if 0%{?rhel}
# not upstreamed
Patch500: 0001-disable-libe-book-support.patch
Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
Patch503: 0001-impl.-missing-function.patch
%endif

(and more than just those) resulting in those patches not being
included
in the src.rpm because the rpm was not built on rhel/centos.

My understanding was that platform specific patches were suppose to
have
the %if macro where the patch is applied, but should not be where the
source for the patch is defined.

Been a long time since I was a fedora packager so I don't know what
current packaging guidelines are, but that just seems wrong.

Is it wrong?


It depends .. in the Red Hat world, this is used so that patches are
applied on RHEL but not on Fedora.  That is the purpose of that patch.
The RHEL team added something to that patch for RHEL that is different
than Fedora.

So, if built on Fedora, those patches are not installed.  Why would that
be a problem?




Ouch, looking through the spec file it appears that it doesn't use the
normal %patch mechanism to apply patches. Looks like a change in RPM
itself that I am not very fond of.

It appears to use a git command to apply patches from some kind of a
patch macro, and apparently with sources too.

It's just my opinion but I am becoming less and less fond of RPM - just
like I became less and less fond of GNOME which I use to really love.

Guess I now know how dad felt when all the AIX servers he managed
started switching to that new-fangled Linux operating system...

___


Applying: installation fix
Applying: never run autogen.sh
error: patch failed: Makefile.in:14
error: Makefile.in: patch does not apply
Patch failed at 0002 never run autogen.sh
The copy of the patch that failed is found in:
   /builddir/build/BUILD/libreoffice-5.3.1.1/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
error: Bad exit status from /var/tmp/rpm-tmp.c4c5hh (%prep)

-=-=-
That's progress, eh? ;)

git is a source management tool. It's not a build tool. Ah well.

___


Ouch some of the patches are failing because I took them from CentOS 
src, because they were missing from Fedora source.rpm - it appears that 
in the newer Libre Office src.rpm - the rhel specific patches that are 
in the spec file but are not in the src.rpm share the same filename but 
different content than in the CentOS version of the older libreoffice.


I'm guessing it is possible those patches haven't even been ported to 
the newer LibreOffice - I'll try building without them, but that is what 
was wrong with the never run autogen patch.


I installed the CentOS src.rpm to get missing files and that also 
over-wrote some of the more current Fedora sources with the same name.


Guess using GIT means version control in filenames themselves is no 
longer being used.


Well in my quest to build rawhide libreoffice in CentOS 7 - I only have 
one more bad patch to deal with, I will try building without it.


I don't like RPM using git to apply patches though. It was much easier 
when I could just look at the failed hunks to see what went wrong.

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

Re: [CentOS] Would this be considered a packaging bug?

2017-02-25 Thread Alice Wonder 

On 02/25/2017 06:33 AM, Alice Wonder wrote:

On 02/25/2017 06:12 AM, Johnny Hughes wrote:

On 02/25/2017 06:52 AM, Alice Wonder wrote:

https://koji.fedoraproject.org/koji/buildinfo?buildID=861692

The source RPM there uses

%if 0%{?rhel}
# not upstreamed
Patch500: 0001-disable-libe-book-support.patch
Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
Patch503: 0001-impl.-missing-function.patch
%endif

(and more than just those) resulting in those patches not being included
in the src.rpm because the rpm was not built on rhel/centos.

My understanding was that platform specific patches were suppose to have
the %if macro where the patch is applied, but should not be where the
source for the patch is defined.

Been a long time since I was a fedora packager so I don't know what
current packaging guidelines are, but that just seems wrong.

Is it wrong?


It depends .. in the Red Hat world, this is used so that patches are
applied on RHEL but not on Fedora.  That is the purpose of that patch.
The RHEL team added something to that patch for RHEL that is different
than Fedora.

So, if built on Fedora, those patches are not installed.  Why would that
be a problem?




Ouch, looking through the spec file it appears that it doesn't use the
normal %patch mechanism to apply patches. Looks like a change in RPM
itself that I am not very fond of.

It appears to use a git command to apply patches from some kind of a
patch macro, and apparently with sources too.

It's just my opinion but I am becoming less and less fond of RPM - just
like I became less and less fond of GNOME which I use to really love.

Guess I now know how dad felt when all the AIX servers he managed
started switching to that new-fangled Linux operating system...

___


Applying: installation fix
Applying: never run autogen.sh
error: patch failed: Makefile.in:14
error: Makefile.in: patch does not apply
Patch failed at 0002 never run autogen.sh
The copy of the patch that failed is found in:
   /builddir/build/BUILD/libreoffice-5.3.1.1/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
error: Bad exit status from /var/tmp/rpm-tmp.c4c5hh (%prep)

-=-=-
That's progress, eh? ;)

git is a source management tool. It's not a build tool. Ah well.

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

Re: [CentOS] Would this be considered a packaging bug?

2017-02-25 Thread Alice Wonder 

On 02/25/2017 06:12 AM, Johnny Hughes wrote:

On 02/25/2017 06:52 AM, Alice Wonder wrote:

https://koji.fedoraproject.org/koji/buildinfo?buildID=861692

The source RPM there uses

%if 0%{?rhel}
# not upstreamed
Patch500: 0001-disable-libe-book-support.patch
Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
Patch503: 0001-impl.-missing-function.patch
%endif

(and more than just those) resulting in those patches not being included
in the src.rpm because the rpm was not built on rhel/centos.

My understanding was that platform specific patches were suppose to have
the %if macro where the patch is applied, but should not be where the
source for the patch is defined.

Been a long time since I was a fedora packager so I don't know what
current packaging guidelines are, but that just seems wrong.

Is it wrong?


It depends .. in the Red Hat world, this is used so that patches are
applied on RHEL but not on Fedora.  That is the purpose of that patch.
The RHEL team added something to that patch for RHEL that is different
than Fedora.

So, if built on Fedora, those patches are not installed.  Why would that
be a problem?




Ouch, looking through the spec file it appears that it doesn't use the 
normal %patch mechanism to apply patches. Looks like a change in RPM 
itself that I am not very fond of.


It appears to use a git command to apply patches from some kind of a 
patch macro, and apparently with sources too.


It's just my opinion but I am becoming less and less fond of RPM - just 
like I became less and less fond of GNOME which I use to really love.


Guess I now know how dad felt when all the AIX servers he managed 
started switching to that new-fangled Linux operating system...


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

Re: [CentOS] RHEL 8 speculation ???

2017-02-25 Thread Johnny Hughes 
On 02/25/2017 02:20 AM, Alice Wonder wrote:
> Is there any blog that has information on a potential RHEL 8 release date?
> 
> boost in 7 is now too old for some things, in addition to gcc. There are
> solutions in 7 to those issues but it's starting to feel like 6 felt
> shortly before 7 came out, so I wonder if it is getting near to time.
> 
> I'm working on a major project bitcoin related and it would be
> frustrating to deploy a bunch of CentOS 7 virtual machines only to have
> 8 come out fairly soon afterwards.

I have no real information on this either .. but one thing to think
about is that RHEL-7 is much less conservative with 'rebases' than the
older RHEL versions.  (Case in point, major shifts in Gnome, KDE, Xorg,
etc.)

With containers and software collections, and with more aggressive
rebases in the Desktop space, I see the timelines becoming a little
longer between major versions.

Also, as others have said, I see no alpha or beta for RHEL-8 anywhere.
RHEL-5 does go EOL at the end of March 2017, so I guess a beta could
happen soon(ish).




signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Would this be considered a packaging bug?

2017-02-25 Thread Jonathan Billings 

> On Feb 25, 2017, at 7:52 AM, Alice Wonder  wrote:
> My understanding was that platform specific patches were suppose to have the 
> %if macro where the patch is applied, but should not be where the source for 
> the patch is defined.


It could be that the packagers did not want the patches distributed with the 
RHEL source packages as well (maybe something licensing related?  Or not 
distributable as part of RHEL?).  I agree that its annoying because you can’t 
take the RHEL srpm and rebuild on Fedora.

--
Jonathan Billings 


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

Re: [CentOS] Would this be considered a packaging bug?

2017-02-25 Thread Johnny Hughes 
On 02/25/2017 06:52 AM, Alice Wonder wrote:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=861692
> 
> The source RPM there uses
> 
> %if 0%{?rhel}
> # not upstreamed
> Patch500: 0001-disable-libe-book-support.patch
> Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
> Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
> Patch503: 0001-impl.-missing-function.patch
> %endif
> 
> (and more than just those) resulting in those patches not being included
> in the src.rpm because the rpm was not built on rhel/centos.
> 
> My understanding was that platform specific patches were suppose to have
> the %if macro where the patch is applied, but should not be where the
> source for the patch is defined.
> 
> Been a long time since I was a fedora packager so I don't know what
> current packaging guidelines are, but that just seems wrong.
> 
> Is it wrong?

It depends .. in the Red Hat world, this is used so that patches are
applied on RHEL but not on Fedora.  That is the purpose of that patch.
The RHEL team added something to that patch for RHEL that is different
than Fedora.

So, if built on Fedora, those patches are not installed.  Why would that
be a problem?




signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Would this be considered a packaging bug?

2017-02-25 Thread Alice Wonder 

https://koji.fedoraproject.org/koji/buildinfo?buildID=861692

The source RPM there uses

%if 0%{?rhel}
# not upstreamed
Patch500: 0001-disable-libe-book-support.patch
Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch
Patch502: 0001-allow-to-build-bundled-libzmf-on-aarch64.patch
Patch503: 0001-impl.-missing-function.patch
%endif

(and more than just those) resulting in those patches not being included 
in the src.rpm because the rpm was not built on rhel/centos.


My understanding was that platform specific patches were suppose to have 
the %if macro where the patch is applied, but should not be where the 
source for the patch is defined.


Been a long time since I was a fedora packager so I don't know what 
current packaging guidelines are, but that just seems wrong.


Is it wrong?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 144, Issue 8

2017-02-25 Thread centos-announce-request 
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CESA-2017:0307 Moderate CentOS 6 kernel Security  Update
  (Johnny Hughes)
   2. CEBA-2017:0302 CentOS 6 ding-libs BugFix Update (Johnny Hughes)
   3. CEBA-2017:0313 CentOS 6 initscripts BugFix Update (Johnny Hughes)
   4. CEBA-2017:0312  CentOS 6 lldpad BugFix Update (Johnny Hughes)
   5. CEBA-2017:0306 CentOS 6 selinux-policy BugFix Update
  (Johnny Hughes)
   6. CEBA-2017:0304 CentOS 6 gnome-settings-daemon BugFix Update
  (Johnny Hughes)
   7. CESA-2017:0309 Important CentOS 6 qemu-kvmSecurity Update
  (Johnny Hughes)
   8. CEBA-2017:0302  CentOS 6 sssd BugFix Update (Johnny Hughes)
   9. CEBA-2017:0308  CentOS 6 gpxe BugFix Update (Johnny Hughes)
  10. CEBA-2017:0305 CentOS 6 kexec-tools BugFix Update (Johnny Hughes)
  11. CEEA-2017:0310 CentOS 6 resource-agents   Enhancement Update
  (Johnny Hughes)
  12. CEBA-2017:0311 CentOS 6 util-linux-ng BugFix  Update
  (Johnny Hughes)


--

Message: 1
Date: Fri, 24 Feb 2017 20:45:23 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2017:0307 Moderate CentOS 6 kernel
SecurityUpdate
Message-ID: <20170224204523.ga44...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2017:0307 Moderate

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0307.html

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

i386:
4b19afbec2ec90db7ab39adb3b3caa40d0ce9d49897b613bdd20e77714f1be21  
kernel-2.6.32-642.15.1.el6.i686.rpm
c784e1a7a1339f05c0d0df7fe6bac6fbb0b7a480a1af6ad24116a41b98e38eb6  
kernel-abi-whitelists-2.6.32-642.15.1.el6.noarch.rpm
2b8e6351259af887492c593fd5f608983fa79f9c84fe2023456493d389b9dc41  
kernel-debug-2.6.32-642.15.1.el6.i686.rpm
db434c849f711e6800b56bf3ddc4f77c71a67648e14ec149733bd8b2527d65ca  
kernel-debug-devel-2.6.32-642.15.1.el6.i686.rpm
0c6a706bbf6b167be4fecf464291ebfbc01d1b4981f55e43a8ed74dd32b8fb11  
kernel-devel-2.6.32-642.15.1.el6.i686.rpm
118d0af31dc23edff429fbeeadc65e9d13bd5e639a2b0a9aaeacbfd578a1b878  
kernel-doc-2.6.32-642.15.1.el6.noarch.rpm
177d9718e7126987080c204c791f455c784e298dc76b06a69c333b77d831fb47  
kernel-firmware-2.6.32-642.15.1.el6.noarch.rpm
5052e87aacf81ae123a87a0e5002db149a31f27034b857b1654639204ba8dd23  
kernel-headers-2.6.32-642.15.1.el6.i686.rpm
772129d87b1914d0529b57da4b7271b2fdb70c389ec9c7cc2ce51c694ded0846  
perf-2.6.32-642.15.1.el6.i686.rpm
fd73990afe6d4f3a33de5e1d3ebfb77582017513235a95ae3cc933d72e892da9  
python-perf-2.6.32-642.15.1.el6.i686.rpm

x86_64:
644ddd5f661a1ec7674edb21a55fe7187dc418e7ef900fe862df79e2fb6b8af0  
kernel-2.6.32-642.15.1.el6.x86_64.rpm
c784e1a7a1339f05c0d0df7fe6bac6fbb0b7a480a1af6ad24116a41b98e38eb6  
kernel-abi-whitelists-2.6.32-642.15.1.el6.noarch.rpm
f27b11a0b8e127f44e7e11e6cab0d48c463d68616cb48337a936052e5ac62874  
kernel-debug-2.6.32-642.15.1.el6.x86_64.rpm
db434c849f711e6800b56bf3ddc4f77c71a67648e14ec149733bd8b2527d65ca  
kernel-debug-devel-2.6.32-642.15.1.el6.i686.rpm
c572e0950b1960586d541ce30e2ea0f86b49cbb9f5d51170cd7a5a481ca0617e  
kernel-debug-devel-2.6.32-642.15.1.el6.x86_64.rpm
a8795311c6c552044450f11a810c285a1c05d6175cb8db313d092ef063ce2673  
kernel-devel-2.6.32-642.15.1.el6.x86_64.rpm
118d0af31dc23edff429fbeeadc65e9d13bd5e639a2b0a9aaeacbfd578a1b878  
kernel-doc-2.6.32-642.15.1.el6.noarch.rpm
177d9718e7126987080c204c791f455c784e298dc76b06a69c333b77d831fb47  
kernel-firmware-2.6.32-642.15.1.el6.noarch.rpm
c54cca97f5e22b0ceaa0c06fe49cb6027dc5a4d8bc5131fb516240a1877608cd  
kernel-headers-2.6.32-642.15.1.el6.x86_64.rpm
2ee22bfd1cef9df4bc99b20c3c205725d9d38a6fbb4063c9cb96007db753efc1  
perf-2.6.32-642.15.1.el6.x86_64.rpm
b8a6e1441a00e961340514f0d5db8faec46c914a041a5eab2d2adf896cc5c79f  
python-perf-2.6.32-642.15.1.el6.x86_64.rpm

Source:
aab44f74bf793af1559f121a1081a455bce337b0dac04cc504bff37bad40a224  
kernel-2.6.32-642.15.1.el6.src.rpm



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



--

Message: 2
Date: Fri, 24 Feb 2017 20:47:24 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2017:0302 CentOS 6 ding-libs BugFix
Update
Message-ID: <20170224204724.ga45...@n04.lon1.karan.org>

Re: [CentOS] RHEL 8 speculation ???

2017-02-25 Thread Gordon Messmer 

On 02/25/2017 12:20 AM, Alice Wonder wrote:
I'm working on a major project bitcoin related and it would be 
frustrating to deploy a bunch of CentOS 7 virtual machines only to 
have 8 come out fairly soon afterwards. 



I'd expect the release of RHEL 8 no less than 6 months after a beta was 
released, and I haven't heard anything about a new beta release.  It's 
probably not going to happen real soon.


Having said that, I didn't realize until how close RHEL 7 is getting to 
the three-year mark.  I wouldn't be surprised to see a beta 6-12 months 
from now, and a new release in 12-18 months.



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

Re: [CentOS] RHEL 8 speculation ???

2017-02-25 Thread Jos Vos 
Hi,

On Sat, Feb 25, 2017 at 12:20:22AM -0800, Alice Wonder wrote:

> boost in 7 is now too old for some things, in addition to gcc. There are 
> solutions in 7 to those issues but it's starting to feel like 6 felt 
> shortly before 7 came out, so I wonder if it is getting near to time.
> 
> I'm working on a major project bitcoin related and it would be 
> frustrating to deploy a bunch of CentOS 7 virtual machines only to have 
> 8 come out fairly soon afterwards.

Take a look at

https://upload.wikimedia.org/wikipedia/en/timeline/d35cef040ea408360c44950a23d813ed.png

Given that, don't count on a release real soon.  Furthermore, a RHEL
release normally has a public beta period of at least 6 months or so.
So, even if a public RHEL 8 beta would be released now (which is
very unlikelely), CentOS 8 would not become available in 2017.

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] RHEL 8 speculation ???

2017-02-25 Thread Alice Wonder 

Is there any blog that has information on a potential RHEL 8 release date?

boost in 7 is now too old for some things, in addition to gcc. There are 
solutions in 7 to those issues but it's starting to feel like 6 felt 
shortly before 7 came out, so I wonder if it is getting near to time.


I'm working on a major project bitcoin related and it would be 
frustrating to deploy a bunch of CentOS 7 virtual machines only to have 
8 come out fairly soon afterwards.

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