All,
The Beta release of the 32-bit (i686) Architecture of CentOS-7 (1503) is currently on build logs.
Right now, only the boot.iso is available, but after some testing from the users here with feedback, we can spin another tree with fixes and actual installer isos.
http://buildlogs.centos.org/centos/7/os/i386/
updates are also here:
http://buildlogs.centos.org/centos/7/updates/i386/
Current known issues are:
1. If installing on a QEMU (kvm) i386 VM, you must modify the VM cpu to use "copy host cpu"
http://bugs.centos.org/view.php?id=8748
2. The gnome desktop will not exit or log out from the menu.
http://bugs.centos.org/view.php?id=8834
If someone can figure out how to fix this issue, it would be much appreciated :)
======================
Please report bugs on bugs.centos.org or to this Centos-Devel mailing list will we do the beta testing and lets see if we can find/fix all the issues before the full release of this arch.
Thanks, Johnny Hughes
Minimal installs completed successfully in a KVM VM (using copy host CPU workaround) and on my VIA C7 firewall/network server.
The only bug I ran into was this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1074358
Which trashed the existing CentOS 6 initrds on said firewall/network server. :/
On Wed, Jun 3, 2015 at 4:23 PM, Ian Pilcher arequipeno@gmail.com wrote:
Minimal installs completed successfully in a KVM VM (using copy host CPU workaround) and on my VIA C7 firewall/network server.
The only bug I ran into was this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1074358
Which trashed the existing CentOS 6 initrds on said firewall/network server. :/
Which is why no one sane shares the same "/boot" for multiple operating systems, at least in any kind of production environment.
On Tue, Jun 2, 2015 at 6:46 PM, Johnny Hughes johnny@centos.org wrote:
All,
The Beta release of the 32-bit (i686) Architecture of CentOS-7 (1503) is currently on build logs.
[snip]
- The gnome desktop will not exit or log out from the menu.
http://bugs.centos.org/view.php?id=8834
If someone can figure out how to fix this issue, it would be much appreciated :)
Hello, I tested it too and I was able to reproduce the bug. I compared with a CentOS 7.1 x86_64 and verified that apparently it depends on the popped up log-out menu confirmation that by default should come up when you click on "Log Out"
In fact if I disable it, I'm able to logout (without confirmation of course) and then log in again
from inside the gnome session
[g.cecchi@c71i686 ~]$ gsettings get org.gnome.SessionManager logout-prompt true
[g.cecchi@c71i686 ~]$ gsettings set org.gnome.SessionManager logout-prompt false
[g.cecchi@c71i686 ~]$ gsettings get org.gnome.SessionManager logout-prompt false
Now I can log out and then log in again. Another test with shutdown menu: - if no users are connected to the system (eg ssh from remote hosts) when you click poweroff, it is honored and the system powers off - if you log into the system for example with an external ssh session, normally if you select poweroff you should get a confirmation popup window informing that other users are connected. In this case you get the same problem as in the logout example. So it seems a problem regarding the confirmation popup windows... but I don't know gnome-shell so much to analyze more in deep... I keep investigating
Gianluca
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I built the epel xfce-related packages for i386 using these repositories for base and updates and installed CentOS 7 with XFCE on my 32 bit laptop and so far it's working like a charm!
I tried the Logout menu since others are reporting issues with it in gnome3 and it's working fine in XFCE.
The XFCE packages I built are at: http://pajamian.dhs.org/repos/el/7/epel/i386/
...in case anyone else is interested in doing the same thing. I didn't create the actual xfce-desktop group in the repo so you'll have to specify the individual package names when yum installing for now.
Peter
On 06/03/2015 04:46 AM, Johnny Hughes wrote:
All,
The Beta release of the 32-bit (i686) Architecture of CentOS-7 (1503) is currently on build logs.
Right now, only the boot.iso is available, but after some testing from the users here with feedback, we can spin another tree with fixes and actual installer isos.
http://buildlogs.centos.org/centos/7/os/i386/
updates are also here:
http://buildlogs.centos.org/centos/7/updates/i386/
Current known issues are:
- If installing on a QEMU (kvm) i386 VM, you must modify the VM
cpu to use "copy host cpu"
http://bugs.centos.org/view.php?id=8748
- The gnome desktop will not exit or log out from the menu.
http://bugs.centos.org/view.php?id=8834
If someone can figure out how to fix this issue, it would be much appreciated :)
======================
Please report bugs on bugs.centos.org or to this Centos-Devel mailing list will we do the beta testing and lets see if we can find/fix all the issues before the full release of this arch.
Thanks, Johnny Hughes
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible? Thanks!
2015-06-02 19:46 GMT+03:00 Johnny Hughes johnny@centos.org:
All,
The Beta release of the 32-bit (i686) Architecture of CentOS-7 (1503) is currently on build logs.
Right now, only the boot.iso is available, but after some testing from the users here with feedback, we can spin another tree with fixes and actual installer isos.
http://buildlogs.centos.org/centos/7/os/i386/
updates are also here:
http://buildlogs.centos.org/centos/7/updates/i386/
Current known issues are:
- If installing on a QEMU (kvm) i386 VM, you must modify the VM cpu to
use "copy host cpu"
http://bugs.centos.org/view.php?id=8748
- The gnome desktop will not exit or log out from the menu.
http://bugs.centos.org/view.php?id=8834
If someone can figure out how to fix this issue, it would be much appreciated :)
======================
Please report bugs on bugs.centos.org or to this Centos-Devel mailing list will we do the beta testing and lets see if we can find/fix all the issues before the full release of this arch.
Thanks, Johnny Hughes
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hello,
I noticed this too on a Thinkpad T23 which has PIII CPU. Is your rebuild somewhere available for testing?
Thanks.
On Fri, Jun 5, 2015 at 1:46 PM, Vladimir Stackov amigo.elite@gmail.com wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible? Thanks!
2015-06-02 19:46 GMT+03:00 Johnny Hughes johnny@centos.org:
All,
The Beta release of the 32-bit (i686) Architecture of CentOS-7 (1503) is currently on build logs.
Right now, only the boot.iso is available, but after some testing from the users here with feedback, we can spin another tree with fixes and actual installer isos.
http://buildlogs.centos.org/centos/7/os/i386/
updates are also here:
http://buildlogs.centos.org/centos/7/updates/i386/
Current known issues are:
- If installing on a QEMU (kvm) i386 VM, you must modify the VM cpu to
use "copy host cpu"
http://bugs.centos.org/view.php?id=8748
- The gnome desktop will not exit or log out from the menu.
http://bugs.centos.org/view.php?id=8834
If someone can figure out how to fix this issue, it would be much appreciated :)
======================
Please report bugs on bugs.centos.org or to this Centos-Devel mailing list will we do the beta testing and lets see if we can find/fix all the issues before the full release of this arch.
Thanks, Johnny Hughes
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Kind regards, Vladimir.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible? Thanks!
<snip>
I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose.
Thanks, Johnny Hughes
This would be rather unfortunate as that would also leave out all 32-bit only AMD processors (Athlon XP & co) as well according to Wikipedia where it's said Athlon 64 was the first one to add SSE2 and it can already run the 64-bit CentOS anyway.
I'm hoping there is more people that could +1 having support for pre-SSE2 CPUs so it would be seriously considered even though it might need massive rebuild of the multilib packages. EPEL doesn't have multilib yet (right?) so they can still adapt to whatever is going to be done. The packages would run on upstream as well anyway.
Taking into account the actual computing power of CPUs, I don't think it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
Thanks for considering.
On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes johnny@centos.org wrote:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible? Thanks!
<snip>
I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose.
Thanks, Johnny Hughes
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Is it really worth the effort? The last Pentium III was released in 2002 and you couldn't buy them after 2003 so we're talking about machines that are 12 or more years old. The fastest one you could ever buy is outperformed by a factor of more than 2 times by each core on my dual core 2010 vintage Intel Atom D510.
On 05/06/15 21:22, Toni Spets wrote:
This would be rather unfortunate as that would also leave out all 32-bit only AMD processors (Athlon XP & co) as well according to Wikipedia where it's said Athlon 64 was the first one to add SSE2 and it can already run the 64-bit CentOS anyway.
I'm hoping there is more people that could +1 having support for pre-SSE2 CPUs so it would be seriously considered even though it might need massive rebuild of the multilib packages. EPEL doesn't have multilib yet (right?) so they can still adapt to whatever is going to be done. The packages would run on upstream as well anyway.
Taking into account the actual computing power of CPUs, I don't think it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
Thanks for considering.
On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote: > Greetings, > > currently we are maintaining own CentOS 7 i686 rebuild and I would like > to kindly ask you to replace following macros from gcc.spec: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=x86-64 \ > %endif > %ifarch x86_64 > --with-arch_32=x86-64 \ > %endif > > with that: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=i686 \ > %endif > %ifarch x86_64 > --with-arch_32=i686 \ > %endif > > x86-64 causes gcc to use extended instruction set for produced code and > it's impossible to run CentOS 7 i686 on older systems without SSE2 > instruction because of SIGILL. > This affects Pentium 3, old VIA CPUs, old Xeons and some others. > > Is that possible? > Thanks! > <snip> I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose. Thanks, Johnny Hughes _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> http://lists.centos.org/mailman/listinfo/centos-devel-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/05/2015 03:41 PM, Trevor Hemsley wrote:
Is it really worth the effort? The last Pentium III was released in 2002 and you couldn't buy them after 2003 so we're talking about machines that are 12 or more years old. The fastest one you could ever buy is outperformed by a factor of more than 2 times by each core on my dual core 2010 vintage Intel Atom D510.
I don't mind the effort of compiling so much as the potential for massive confusion with 2 packages named the same thing but compiled with different gcc optimizations, as we would still have to provide the other packages i686 packages in x86_64 arch for multilib.
But, I do agree that trying to run this on 12 year old machines is is not going to be easy. CentOS-7 does not perform well without at least 1.5GB - 2GB of RAM as well. (The installer does not even work well with less than 1 GB RAM)
If enough people really want it, I guess it could be done as part of the AltArch Special Interest Group .. but my initial take is not positive because of the confusion potential.
On 05/06/15 21:22, Toni Spets wrote:
This would be rather unfortunate as that would also leave out all 32-bit only AMD processors (Athlon XP & co) as well according to Wikipedia where it's said Athlon 64 was the first one to add SSE2 and it can already run the 64-bit CentOS anyway.
I'm hoping there is more people that could +1 having support for pre-SSE2 CPUs so it would be seriously considered even though it might need massive rebuild of the multilib packages. EPEL doesn't have multilib yet (right?) so they can still adapt to whatever is going to be done. The packages would run on upstream as well anyway.
Taking into account the actual computing power of CPUs, I don't think it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
Thanks for considering.
On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote: > Greetings, > > currently we are maintaining own CentOS 7 i686 rebuild and I would like > to kindly ask you to replace following macros from gcc.spec: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=x86-64 \ > %endif > %ifarch x86_64 > --with-arch_32=x86-64 \ > %endif > > with that: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=i686 \ > %endif > %ifarch x86_64 > --with-arch_32=i686 \ > %endif > > x86-64 causes gcc to use extended instruction set for produced code and > it's impossible to run CentOS 7 i686 on older systems without SSE2 > instruction because of SIGILL. > This affects Pentium 3, old VIA CPUs, old Xeons and some others. > > Is that possible? > Thanks! > <snip> I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose. Thanks, Johnny Hughes
On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes johnny@centos.org wrote:
On 06/05/2015 03:41 PM, Trevor Hemsley wrote:
Is it really worth the effort? The last Pentium III was released in 2002 and you couldn't buy them after 2003 so we're talking about machines that are 12 or more years old. The fastest one you could ever buy is outperformed by a factor of more than 2 times by each core on my dual core 2010 vintage Intel Atom D510.
I don't mind the effort of compiling so much as the potential for massive confusion with 2 packages named the same thing but compiled with different gcc optimizations, as we would still have to provide the other packages i686 packages in x86_64 arch for multilib.
Why its there a need to provide two different builds? Couldn't the multilib packages be rebuilt not to require SSE2? Is the performance penalty bad enough to not even consider it?
But, I do agree that trying to run this on 12 year old machines is is not going to be easy. CentOS-7 does not perform well without at least 1.5GB - 2GB of RAM as well. (The installer does not even work well with less than 1 GB RAM)
The installer does run with 512MB of RAM and it can be run around 384MB of RAM as well without any modifications except lowering the requirement by hand. The use cases would be headless environments like servers where you can better utilize the memory like you do in virtualized environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine for what they are tasked for.
If enough people really want it, I guess it could be done as part of the AltArch Special Interest Group .. but my initial take is not positive because of the confusion potential.
On 05/06/15 21:22, Toni Spets wrote:
This would be rather unfortunate as that would also leave out all 32-bit only AMD processors (Athlon XP & co) as well according to Wikipedia where it's said Athlon 64 was the first one to add SSE2 and it can already run the 64-bit CentOS anyway.
I'm hoping there is more people that could +1 having support for pre-SSE2 CPUs so it would be seriously considered even though it might need massive rebuild of the multilib packages. EPEL doesn't have multilib yet (right?) so they can still adapt to whatever is going to be done. The packages would run on upstream as well anyway.
Taking into account the actual computing power of CPUs, I don't think it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
Thanks for considering.
On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote: > Greetings, > > currently we are maintaining own CentOS 7 i686 rebuild and I would like > to kindly ask you to replace following macros from gcc.spec: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=x86-64 \ > %endif > %ifarch x86_64 > --with-arch_32=x86-64 \ > %endif > > with that: > > %if 0%{?rhel} >= 7 > %ifarch %{ix86} > --with-arch=i686 \ > %endif > %ifarch x86_64 > --with-arch_32=i686 \ > %endif > > x86-64 causes gcc to use extended instruction set for produced code and > it's impossible to run CentOS 7 i686 on older systems without SSE2 > instruction because of SIGILL. > This affects Pentium 3, old VIA CPUs, old Xeons and some others. > > Is that possible? > Thanks! > <snip> I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose. Thanks, Johnny Hughes
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/06/2015 02:43 AM, Toni Spets wrote:
On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 06/05/2015 03:41 PM, Trevor Hemsley wrote: > Is it really worth the effort? The last Pentium III was released in 2002 > and you couldn't buy them after 2003 so we're talking about machines > that are 12 or more years old. The fastest one you could ever buy is > outperformed by a factor of more than 2 times by each core on my dual > core 2010 vintage Intel Atom D510. > I don't mind the effort of compiling so much as the potential for massive confusion with 2 packages named the same thing but compiled with different gcc optimizations, as we would still have to provide the other packages i686 packages in x86_64 arch for multilib.Why its there a need to provide two different builds? Couldn't the multilib packages be rebuilt not to require SSE2? Is the performance penalty bad enough to not even consider it?
The reason the items in CentOS 7 x86_64 (in this case, we are taking about the i686 multilib pacakges) need to be built with an unmodified gcc is that the whole goal of CentOS Linux is to build packages from RHEL sources that are as close to possible to actual Red Hat packages minus branding.
If we change the way gcc produces those i686 packages that we put into our main CentOS 7 x86_64 arch then that is a huge difference. I am quite sure our users do not want us modifying CentOS Linux 7 production packages in this manner.
If has nothing to do with performance, it has to do with producing CentOS Linux 7 x86_64 that deviates from the way the upstream packages are produced.
But, I do agree that trying to run this on 12 year old machines is is not going to be easy. CentOS-7 does not perform well without at least 1.5GB - 2GB of RAM as well. (The installer does not even work well with less than 1 GB RAM)The installer does run with 512MB of RAM and it can be run around 384MB of RAM as well without any modifications except lowering the requirement by hand. The use cases would be headless environments like servers where you can better utilize the memory like you do in virtualized environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine for what they are tasked for.
If enough people really want it, I guess it could be done as part of the AltArch Special Interest Group .. but my initial take is not positive because of the confusion potential. > On 05/06/15 21:22, Toni Spets wrote: >> This would be rather unfortunate as that would also leave out all >> 32-bit only AMD processors (Athlon XP & co) as well according to >> Wikipedia where it's said Athlon 64 was the first one to add SSE2 and >> it can already run the 64-bit CentOS anyway. >> >> I'm hoping there is more people that could +1 having support for >> pre-SSE2 CPUs so it would be seriously considered even though it might >> need massive rebuild of the multilib packages. EPEL doesn't have >> multilib yet (right?) so they can still adapt to whatever is going to >> be done. The packages would run on upstream as well anyway. >> >> Taking into account the actual computing power of CPUs, I don't think >> it's unreasonable to run CentOS 7 on Pentium III or Athlon XP. >> >> Thanks for considering. >> >> On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny@centos.org <mailto:johnny@centos.org> >> <mailto:johnny@centos.org <mailto:johnny@centos.org>>> wrote: >> >> On 06/05/2015 05:46 AM, Vladimir Stackov wrote: >> > Greetings, >> > >> > currently we are maintaining own CentOS 7 i686 rebuild and I >> would like >> > to kindly ask you to replace following macros from gcc.spec: >> > >> > %if 0%{?rhel} >= 7 >> > %ifarch %{ix86} >> > --with-arch=x86-64 \ >> > %endif >> > %ifarch x86_64 >> > --with-arch_32=x86-64 \ >> > %endif >> > >> > with that: >> > >> > %if 0%{?rhel} >= 7 >> > %ifarch %{ix86} >> > --with-arch=i686 \ >> > %endif >> > %ifarch x86_64 >> > --with-arch_32=i686 \ >> > %endif >> > >> > x86-64 causes gcc to use extended instruction set for produced >> code and >> > it's impossible to run CentOS 7 i686 on older systems without SSE2 >> > instruction because of SIGILL. >> > This affects Pentium 3, old VIA CPUs, old Xeons and some others. >> > >> > Is that possible? >> > Thanks! >> > >> >> <snip> >> >> I don't think we can do this as I also use the RPMs produced for the >> multilib portion of CentOS-7 x86_64 and we want our RPMs to be like >> those from upstream for that purpose. >> >> Thanks, >> Johnny Hughes >> >> _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> http://lists.centos.org/mailman/listinfo/centos-devel-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Ok, what should I do if I'm ready to maintain packages for public non-sse2 rebuild? How to get this rebuild covered by CentOS SIG?
As far as I know I'm prohibited to use "CentOS" in public rebuild name until it was explicitly allowed by CentOS project. 06.06.2015 12:44 пользователь "Johnny Hughes" johnny@centos.org написал:
On 06/06/2015 02:43 AM, Toni Spets wrote:
On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 06/05/2015 03:41 PM, Trevor Hemsley wrote: > Is it really worth the effort? The last Pentium III was releasedin 2002
> and you couldn't buy them after 2003 so we're talking aboutmachines
> that are 12 or more years old. The fastest one you could ever buyis
> outperformed by a factor of more than 2 times by each core on mydual
> core 2010 vintage Intel Atom D510. > I don't mind the effort of compiling so much as the potential for massive confusion with 2 packages named the same thing but compiledwith
different gcc optimizations, as we would still have to provide theother
packages i686 packages in x86_64 arch for multilib.Why its there a need to provide two different builds? Couldn't the multilib packages be rebuilt not to require SSE2? Is the performance penalty bad enough to not even consider it?
The reason the items in CentOS 7 x86_64 (in this case, we are taking about the i686 multilib pacakges) need to be built with an unmodified gcc is that the whole goal of CentOS Linux is to build packages from RHEL sources that are as close to possible to actual Red Hat packages minus branding.
If we change the way gcc produces those i686 packages that we put into our main CentOS 7 x86_64 arch then that is a huge difference. I am quite sure our users do not want us modifying CentOS Linux 7 production packages in this manner.
If has nothing to do with performance, it has to do with producing CentOS Linux 7 x86_64 that deviates from the way the upstream packages are produced.
But, I do agree that trying to run this on 12 year old machines is is not going to be easy. CentOS-7 does not perform well without atleast
1.5GB - 2GB of RAM as well. (The installer does not even work wellwith
less than 1 GB RAM)The installer does run with 512MB of RAM and it can be run around 384MB of RAM as well without any modifications except lowering the requirement by hand. The use cases would be headless environments like servers where you can better utilize the memory like you do in virtualized environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine for what they are tasked for.
If enough people really want it, I guess it could be done as part ofthe
AltArch Special Interest Group .. but my initial take is not positive because of the confusion potential. > On 05/06/15 21:22, Toni Spets wrote: >> This would be rather unfortunate as that would also leave out all >> 32-bit only AMD processors (Athlon XP & co) as well according to >> Wikipedia where it's said Athlon 64 was the first one to add SSE2and
>> it can already run the 64-bit CentOS anyway. >> >> I'm hoping there is more people that could +1 having support for >> pre-SSE2 CPUs so it would be seriously considered even though itmight
>> need massive rebuild of the multilib packages. EPEL doesn't have >> multilib yet (right?) so they can still adapt to whatever isgoing to
>> be done. The packages would run on upstream as well anyway. >> >> Taking into account the actual computing power of CPUs, I don'tthink
>> it's unreasonable to run CentOS 7 on Pentium III or Athlon XP. >> >> Thanks for considering. >> >> On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny@centos.org>> <mailto:johnny@centos.org <mailto:johnny@centos.org>>> wrote: >> >> On 06/05/2015 05:46 AM, Vladimir Stackov wrote: >> > Greetings, >> > >> > currently we are maintaining own CentOS 7 i686 rebuild and I >> would like >> > to kindly ask you to replace following macros from gcc.spec: >> > >> > %if 0%{?rhel} >= 7 >> > %ifarch %{ix86} >> > --with-arch=x86-64 \ >> > %endif >> > %ifarch x86_64 >> > --with-arch_32=x86-64 \ >> > %endif >> > >> > with that: >> > >> > %if 0%{?rhel} >= 7 >> > %ifarch %{ix86} >> > --with-arch=i686 \ >> > %endif >> > %ifarch x86_64 >> > --with-arch_32=i686 \ >> > %endif >> > >> > x86-64 causes gcc to use extended instruction set forproduced
>> code and >> > it's impossible to run CentOS 7 i686 on older systems without SSE2 >> > instruction because of SIGILL. >> > This affects Pentium 3, old VIA CPUs, old Xeons and some others. >> > >> > Is that possible? >> > Thanks! >> > >> >> <snip> >> >> I don't think we can do this as I also use the RPMs produced for the >> multilib portion of CentOS-7 x86_64 and we want our RPMs to be like >> those from upstream for that purpose. >> >> Thanks, >> Johnny Hughes >> >> _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> http://lists.centos.org/mailman/listinfo/centos-devel-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
If you think it this way, why bother with the i686 build at all? Your dual core 2010 vintage Intel Atom D510 can run 64-bit CentOS 7 anyway. This is why dropping SSE2 requirement would be benefitical as it would allow running it with a larger amount of x86 CPUs that can't run the 64-bit variation at all.
I do think there are a lot of x86 systems that have around 512 MB of RAM that could still be used as small office servers, routers etc. that would really benefit from a stable and well supported distribution like CentOS is. They are not very useful for desktop use but many server tasks haven't changed that much in 10 years but have been virtualized or have higher traffic handling requirements. Surveying CentOS 6 users who run the i686 version on non-SSE2 CPUs would also give some sort of indication how many potential users are going to be left out and would need to change their enterprise grade distribution to something else when EOL hits.
My specific use case isn't really worth CentOS 7. I don't think I would ever *really* run anything useful on a 12 year old laptop, it was just the only x86 system I still have around. The CPU generation itself, however, isn't completely useless for some other tasks.
On Fri, Jun 5, 2015 at 11:41 PM, Trevor Hemsley <trevor.hemsley@ntlworld.com
wrote:
Is it really worth the effort? The last Pentium III was released in 2002 and you couldn't buy them after 2003 so we're talking about machines that are 12 or more years old. The fastest one you could ever buy is outperformed by a factor of more than 2 times by each core on my dual core 2010 vintage Intel Atom D510.
On 05/06/15 21:22, Toni Spets wrote:
This would be rather unfortunate as that would also leave out all 32-bit only AMD processors (Athlon XP & co) as well according to Wikipedia where it's said Athlon 64 was the first one to add SSE2 and it can already run the 64-bit CentOS anyway.
I'm hoping there is more people that could +1 having support for pre-SSE2 CPUs so it would be seriously considered even though it might need massive rebuild of the multilib packages. EPEL doesn't have multilib yet (right?) so they can still adapt to whatever is going to be done. The packages would run on upstream as well anyway.
Taking into account the actual computing power of CPUs, I don't think it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
Thanks for considering.
On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes johnny@centos.org wrote:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible? Thanks!
<snip>
I don't think we can do this as I also use the RPMs produced for the multilib portion of CentOS-7 x86_64 and we want our RPMs to be like those from upstream for that purpose.
Thanks, Johnny Hughes
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Toni Spets
CentOS-devel mailing listCentOS-devel@centos.orghttp://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/06/2015 03:38 AM, Toni Spets wrote:
If you think it this way, why bother with the i686 build at all? Your dual core 2010 vintage Intel Atom D510 can run 64-bit CentOS 7 anyway. This is why dropping SSE2 requirement would be benefitical as it would allow running it with a larger amount of x86 CPUs that can't run the 64-bit variation at all.
Older Xeon systems that are non-64bit capable are one set of possible targets. If PAE is disabled, Pentium M is likewise a good target (we're running Windows 7 Pro here on some Dell Latitude D610's with reasonable performance; CentOS would run on these quite well, as they are single-core 2GHz Pentium M with 2GB of RAM and somewhat reasonable ATI X300 video, if PAE isn't required). Of course, NetBurst Xeon is a performance pig, but a non-profit that has an older but high-quality server with NetBurst Xeon in it might not have the discretionary funds to obtain a similar quality system with a more modern and power-efficient CPU; they'll run it until it breaks and it's no longer discretionary to replace it.
Pentium M on the other hand performs very well at 2GHz. We have a number of D600's, but they are just not quite up to the task of running Win7 reasonably well. That era, 2004 or so, seems to be the break-point for boxes that are still very usable running modern workloads. D600's still make excellent service laptops for things requiring serial ports (like our datum SSU-2000 timeserver with a PRS45A cesium primary refclock). I have a couple of D600's parked at a co-lo just for that sort of troubleshooting purpose where RS-232 is still needed, and another D600 running the software for our Advin Pilot EPROM programmer, which needs a parallel port connection (I did mention specialty hardware before.....).
Surveying CentOS 6 users who run the i686 version on non-SSE2 CPUs would also give some sort of indication how many potential users are going to be left out and would need to change their enterprise grade distribution to something else when EOL hits.
I'm still running a 32-bit CentOS 5 install due to some proprietary software that is not available yet in a 64-bit form. Keeping up to date with security fixes while running this software will become increasingly difficult, but when a hardware vendor doesn't or didn't provide 64-bit driver modules what exactly are you supposed to do for specialized hardware that is expected to be in production for 15 years? (Yes, 15 years, per the grant proposal language.....)
My specific use case isn't really worth CentOS 7. I don't think I would ever *really* run anything useful on a 12 year old laptop, it was just the only x86 system I still have around. The CPU generation itself, however, isn't completely useless for some other tasks.
I'm finding that laptops from the 2004-2006 era are really robust and seem to continue to just work and do their job sufficiently well to where my employer, a 501(c)(3) not-for-profit public foundation, is having difficulty getting donations of anything dual-core or better, and funding just isn't there yet to roll in newer stuff. So the dozen or so D610's we have running Windows 7 get heavy use, and our few Core Duo Dell Inspiron 640M's and 9400's are still workhorses. Hmph, I just last fall upgraded from a Dell D830 as my primary laptop, and I still use the D830/M4300's I have as CentOS 7 machines that are quite reasonable performers. I'd love to get a dozen or two D830/M4300's donated, as long as they still have good video or are Intel video D830s.
Most end users don't need anything more powerful than a Core 2 Duo T8300 or similar for most tasks.
I'll end this post with the following excerpts from a couple of still-in-production machines just to give an indication of how old things can really get in production in linux-land: one here, and one at a client, both of which are locked at the versions indicated due to various issues, mostly having to do with hardware support (no, neither of them are directly exposed to the internet, and, yes, the client knows how badly they need to upgrade, as do we.... but, both machines are doing their respective jobs, doing them well, and in these particular cases the time won't be funded to upgrade until they actually break...):
+++++++++++++++++++ [root@webcam4 root]# uname -rsvp Linux 2.4.22-1.2129.nptl_24.rhfc1.at #1 Fri Dec 12 20:11:09 EST 2003 i586 [root@webcam4 root]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 300.694 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips : 599.65
[root@webcam4 root]# cat /etc/redhat-release Fedora Core release 1 (Yarrow) [root@webcam4 root]# +++++++++++++++++++ [lowen@intra1 lowen]$ uname -rsvp Linux 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 unknown [lowen@intra1 lowen]$ cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor vendor_id : AuthenticAMD stepping : M fdiv_bug : no hlt_bug : no f00f_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr mce cx8 syscr pge mmx 3dnow bogomips : 999.42 [lowen@intra1 lowen]$ cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) [lowen@intra1 lowen]$ +++++++++++++++++++
On Jun 6, 2015 10:06, "Lamar Owen" lowen@pari.edu wrote:
On 06/06/2015 03:38 AM, Toni Spets wrote:
If you think it this way, why bother with the i686 build at all? Your
dual core 2010 vintage Intel Atom D510 can run 64-bit CentOS 7 anyway. This is why dropping SSE2 requirement would be benefitical as it would allow running it with a larger amount of x86 CPUs that can't run the 64-bit variation at all.
Older Xeon systems that are non-64bit capable are one set of possible
targets. If PAE is disabled, Pentium M is likewise a good target (we're running Windows 7 Pro here on some Dell Latitude D610's with reasonable performance; CentOS would run on these quite well, as they are single-core 2GHz Pentium M with 2GB of RAM and somewhat reasonable ATI X300 video, if PAE isn't required). Of course, NetBurst Xeon is a performance pig, but a non-profit that has an older but high-quality server with NetBurst Xeon in it might not have the discretionary funds to obtain a similar quality system with a more modern and power-efficient CPU; they'll run it until it breaks and it's no longer discretionary to replace it.
Pentium M on the other hand performs very well at 2GHz. We have a number
of D600's, but they are just not quite up to the task of running Win7 reasonably well. That era, 2004 or so, seems to be the break-point for boxes that are still very usable running modern workloads. D600's still make excellent service laptops for things requiring serial ports (like our datum SSU-2000 timeserver with a PRS45A cesium primary refclock). I have a couple of D600's parked at a co-lo just for that sort of troubleshooting purpose where RS-232 is still needed, and another D600 running the software for our Advin Pilot EPROM programmer, which needs a parallel port connection (I did mention specialty hardware before.....).
The part not addressed in this is getting the 2 main windowing systems to work well in such 'constrained' environments as neither KDE or gnome think such hardware worth dealing with issues on (if it works great if it doesn't tough from previous experience trying to get help). So you are ending up having to customize more and .more to the point it isn't really centos anymore.
Surveying CentOS 6 users who run the i686 version on non-SSE2 CPUs would
also give some sort of indication how many potential users are going to be left out and would need to change their enterprise grade distribution to something else when EOL hits.
I'm still running a 32-bit CentOS 5 install due to some proprietary
software that is not available yet in a 64-bit form. Keeping up to date with security fixes while running this software will become increasingly difficult, but when a hardware vendor doesn't or didn't provide 64-bit driver modules what exactly are you supposed to do for specialized hardware that is expected to be in production for 15 years? (Yes, 15 years, per the grant proposal language.....)
My specific use case isn't really worth CentOS 7. I don't think I would
ever *really* run anything useful on a 12 year old laptop, it was just the only x86 system I still have around. The CPU generation itself, however, isn't completely useless for some other tasks.
I'm finding that laptops from the 2004-2006 era are really robust and
seem to continue to just work and do their job sufficiently well to where my employer, a 501(c)(3) not-for-profit public foundation, is having difficulty getting donations of anything dual-core or better, and funding just isn't there yet to roll in newer stuff. So the dozen or so D610's we have running Windows 7 get heavy use, and our few Core Duo Dell Inspiron 640M's and 9400's are still workhorses. Hmph, I just last fall upgraded from a Dell D830 as my primary laptop, and I still use the D830/M4300's I have as CentOS 7 machines that are quite reasonable performers. I'd love to get a dozen or two D830/M4300's donated, as long as they still have good video or are Intel video D830s.
Most end users don't need anything more powerful than a Core 2 Duo T8300
or similar for most tasks.
I'll end this post with the following excerpts from a couple of
still-in-production machines just to give an indication of how old things can really get in production in linux-land: one here, and one at a client, both of which are locked at the versions indicated due to various issues, mostly having to do with hardware support (no, neither of them are directly exposed to the internet, and, yes, the client knows how badly they need to upgrade, as do we.... but, both machines are doing their respective jobs, doing them well, and in these particular cases the time won't be funded to upgrade until they actually break...):
+++++++++++++++++++ [root@webcam4 root]# uname -rsvp Linux 2.4.22-1.2129.nptl_24.rhfc1.at #1 Fri Dec 12 20:11:09 EST 2003 i586 [root@webcam4 root]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 300.694 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
k6_mtrr
bogomips : 599.65
[root@webcam4 root]# cat /etc/redhat-release Fedora Core release 1 (Yarrow) [root@webcam4 root]# +++++++++++++++++++ [lowen@intra1 lowen]$ uname -rsvp Linux 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 unknown [lowen@intra1 lowen]$ cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor vendor_id : AuthenticAMD stepping : M fdiv_bug : no hlt_bug : no f00f_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr mce cx8 syscr pge mmx 3dnow bogomips : 999.42 [lowen@intra1 lowen]$ cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) [lowen@intra1 lowen]$ +++++++++++++++++++
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/06/2015 10:34 PM, Stephen John Smoogen wrote:
On Jun 6, 2015 10:06, "Lamar Owen" <lowen@pari.edu mailto:lowen@pari.edu> wrote:
On 06/06/2015 03:38 AM, Toni Spets wrote:
If you think it this way, why bother with the i686 build at all?
Your dual core 2010 vintage Intel Atom D510 can run 64-bit CentOS 7 anyway. This is why dropping SSE2 requirement would be benefitical as it would allow running it with a larger amount of x86 CPUs that can't run the 64-bit variation at all.
Older Xeon systems that are non-64bit capable are one set of
possible targets. If PAE is disabled, Pentium M is likewise a good target (we're running Windows 7 Pro here on some Dell Latitude D610's with reasonable performance; CentOS would run on these quite well, as they are single-core 2GHz Pentium M with 2GB of RAM and somewhat reasonable ATI X300 video, if PAE isn't required). Of course, NetBurst Xeon is a performance pig, but a non-profit that has an older but high-quality server with NetBurst Xeon in it might not have the discretionary funds to obtain a similar quality system with a more modern and power-efficient CPU; they'll run it until it breaks and it's no longer discretionary to replace it.
Pentium M on the other hand performs very well at 2GHz. We have a
number of D600's, but they are just not quite up to the task of running Win7 reasonably well. That era, 2004 or so, seems to be the break-point for boxes that are still very usable running modern workloads. D600's still make excellent service laptops for things requiring serial ports (like our datum SSU-2000 timeserver with a PRS45A cesium primary refclock). I have a couple of D600's parked at a co-lo just for that sort of troubleshooting purpose where RS-232 is still needed, and another D600 running the software for our Advin Pilot EPROM programmer, which needs a parallel port connection (I did mention specialty hardware before.....).
The part not addressed in this is getting the 2 main windowing systems to work well in such 'constrained' environments as neither KDE or gnome think such hardware worth dealing with issues on (if it works great if it doesn't tough from previous experience trying to get help). So you are ending up having to customize more and .more to the point it isn't really centos anymore.
Lighter desktop environments with far fewer resource requirements exist and are heavily used. And if xfce/lxde or others exist for the ARM platform, I am 100% sure those are ( or will be ) available for i686 as well. I even have friends with PCs assembled from components manufactured in 2014 with SSD and 2 digits worth of RAM ( expressed in GB ) who use xfce ! That the DE will not come from base CentOS ... OK. It won't. So what? A lot of the people who use LAMP stacks based on CentOS replace the core php ( and lately even mysql ) and we do not ban them :) Do we offer support for something we do not ship ? No, we don't. But that's not a reason to not allow it to be done by others. Let us be the foundation !
However, if you want to say that all the i686 stack will need to be [re]generated using the recompiled compiler... yes, I am with you on this one. It will probably be the case and to be honest I am not sure it's worth it. But that would be the exact use case for a "i386" parallel set of packages, as once existed in parallel with i686 ( and athlon!).
For WITW ( and almost unrelated to the matter at hand ), my general manager who is a US citizen but also a freak defined by "I want a very very very light laptop" ( 12 years ago the guy used to travel WITHOUT the battery on his Compaq laptop... ) tasked me 4 days ago to look for a 11.6" (!!) laptop similar to his Sharp MM10 which just died. And NOT a chromebook but something able to run Outlook!
Bottom line, let's not dismiss old hardware just because it's more convenient. If there is a use case and there are people willing to enroll at the task of maintaining it , I'd say "go for it". But once again, as a parallel set of packages, not by replacing what already was built and is shipped for the i686 arch.
wolfy, proud owner of a VIA C3 based fully functional computer
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like to kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible?
Overall, I'm hesitant here as folks (some of the epel devs as well as others) are looking at this as a way to supplement the 32bit environment for the base distro for building things like wine. I don't want to mix gcc build options for things that may live in both places.
Any chances for a dedicated SIG? 08.06.2015 16:59 пользователь "Jim Perrin" jperrin@centos.org написал:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like
to
kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible?
Overall, I'm hesitant here as folks (some of the epel devs as well as others) are looking at this as a way to supplement the 32bit environment for the base distro for building things like wine. I don't want to mix gcc build options for things that may live in both places.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I'm not opposed to that, so long as *something* (disttag?) changes, so that we don't end up with the exact same package name built with a different gcc option. The potential for silent problems due to identical looking package naming with different build options is much higher.
If you can come up with another few people to help you out (so that it's not relying entirely on one person), then it's something we can seriously discuss without the need for hypotheticals.
On 06/08/2015 10:57 AM, Vladimir Stackov wrote:
Any chances for a dedicated SIG? 08.06.2015 16:59 пользователь "Jim Perrin" jperrin@centos.org написал:
On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
Greetings,
currently we are maintaining own CentOS 7 i686 rebuild and I would like
to
kindly ask you to replace following macros from gcc.spec:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=x86-64 \ %endif %ifarch x86_64 --with-arch_32=x86-64 \ %endif
with that:
%if 0%{?rhel} >= 7 %ifarch %{ix86} --with-arch=i686 \ %endif %ifarch x86_64 --with-arch_32=i686 \ %endif
x86-64 causes gcc to use extended instruction set for produced code and it's impossible to run CentOS 7 i686 on older systems without SSE2 instruction because of SIGILL. This affects Pentium 3, old VIA CPUs, old Xeons and some others.
Is that possible?
Overall, I'm hesitant here as folks (some of the epel devs as well as others) are looking at this as a way to supplement the 32bit environment for the base distro for building things like wine. I don't want to mix gcc build options for things that may live in both places.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Gianluca Cecchi -
Ian Pilcher -
Jim Perrin -
Johnny Hughes -
Lamar Owen -
Manuel Wolfshant -
Nico Kadel-Garcia -
Peter -
Stephen John Smoogen -
Toni Spets -
Trevor Hemsley -
Vladimir Stackov