<p dir="ltr">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?</p>
<p dir="ltr">As far as I know I'm prohibited to use "CentOS" in public rebuild name until it was explicitly allowed by CentOS project.</p>
<div class="gmail_quote">06.06.2015 12:44 пользователь "Johnny Hughes" <<a href="mailto:johnny@centos.org">johnny@centos.org</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/06/2015 02:43 AM, Toni Spets wrote:<br>
><br>
><br>
> On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <<a href="mailto:johnny@centos.org">johnny@centos.org</a><br>
> <mailto:<a href="mailto:johnny@centos.org">johnny@centos.org</a>>> wrote:<br>
><br>
>     On 06/05/2015 03:41 PM, Trevor Hemsley wrote:<br>
>     > Is it really worth the effort? The last Pentium III was released in 2002<br>
>     > and you couldn't buy them after 2003 so we're talking about machines<br>
>     > that are 12 or more years old. The fastest one you could ever buy is<br>
>     > outperformed by a factor of more than 2 times by each core on my dual<br>
>     > core 2010 vintage Intel Atom D510.<br>
>     ><br>
><br>
>     I don't mind the effort of compiling so much as the potential for<br>
>     massive confusion with 2 packages named the same thing but compiled with<br>
>     different gcc optimizations, as we would still have to provide the other<br>
>     packages i686 packages in x86_64 arch for multilib.<br>
><br>
><br>
> Why its there a need to provide two different builds? Couldn't the<br>
> multilib packages be rebuilt not to require SSE2? Is the performance<br>
> penalty bad enough to not even consider it?<br>
<br>
The reason the items in CentOS 7 x86_64 (in this case, we are taking<br>
about the i686 multilib pacakges) need to be built with an unmodified<br>
gcc is that the whole goal of CentOS Linux is to build packages from<br>
RHEL sources that are as close to possible to actual Red Hat packages<br>
minus branding.<br>
<br>
If we change the way gcc produces those i686 packages that we put into<br>
our main CentOS 7 x86_64 arch then that is a huge difference.  I am<br>
quite sure our users do not want us modifying CentOS Linux 7 production<br>
packages in this manner.<br>
<br>
If has nothing to do with performance, it has to do with producing<br>
CentOS Linux 7 x86_64 that deviates from the way the upstream packages<br>
are produced.<br>
<br>
<br>
><br>
><br>
><br>
>     But, I do agree that trying to run this on 12 year old machines is is<br>
>     not going to be easy.  CentOS-7 does not perform well without at least<br>
>     1.5GB - 2GB of RAM as well.  (The installer does not even work well with<br>
>     less than 1 GB RAM)<br>
><br>
><br>
> The installer does run with 512MB of RAM and it can be run around 384MB<br>
> of RAM as well without any modifications except lowering the requirement<br>
> by hand. The use cases would be headless environments like servers where<br>
> you can better utilize the memory like you do in virtualized<br>
> environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine<br>
> for what they are tasked for.<br>
><br>
><br>
><br>
>     If enough people really want it, I guess it could be done as part of the<br>
>     AltArch Special Interest Group .. but my initial take is not positive<br>
>     because of the confusion potential.<br>
><br>
><br>
>     > On 05/06/15 21:22, Toni Spets wrote:<br>
>     >> This would be rather unfortunate as that would also leave out all<br>
>     >> 32-bit only AMD processors (Athlon XP & co) as well according to<br>
>     >> Wikipedia where it's said Athlon 64 was the first one to add SSE2 and<br>
>     >> it can already run the 64-bit CentOS anyway.<br>
>     >><br>
>     >> I'm hoping there is more people that could +1 having support for<br>
>     >> pre-SSE2 CPUs so it would be seriously considered even though it might<br>
>     >> need massive rebuild of the multilib packages. EPEL doesn't have<br>
>     >> multilib yet (right?) so they can still adapt to whatever is going to<br>
>     >> be done. The packages would run on upstream as well anyway.<br>
>     >><br>
>     >> Taking into account the actual computing power of CPUs, I don't think<br>
>     >> it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.<br>
>     >><br>
>     >> Thanks for considering.<br>
>     >><br>
>     >> On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <<a href="mailto:johnny@centos.org">johnny@centos.org</a> <mailto:<a href="mailto:johnny@centos.org">johnny@centos.org</a>><br>
>     >> <mailto:<a href="mailto:johnny@centos.org">johnny@centos.org</a> <mailto:<a href="mailto:johnny@centos.org">johnny@centos.org</a>>>> wrote:<br>
>     >><br>
>     >>     On 06/05/2015 05:46 AM, Vladimir Stackov wrote:<br>
>     >>     > Greetings,<br>
>     >>     ><br>
>     >>     > currently we are maintaining own CentOS 7 i686 rebuild and I<br>
>     >>     would like<br>
>     >>     > to kindly ask you to replace following macros from gcc.spec:<br>
>     >>     ><br>
>     >>     > %if 0%{?rhel} >= 7<br>
>     >>     > %ifarch %{ix86}<br>
>     >>     >    --with-arch=x86-64 \<br>
>     >>     > %endif<br>
>     >>     > %ifarch x86_64<br>
>     >>     >    --with-arch_32=x86-64 \<br>
>     >>     > %endif<br>
>     >>     ><br>
>     >>     > with that:<br>
>     >>     ><br>
>     >>     > %if 0%{?rhel} >= 7<br>
>     >>     > %ifarch %{ix86}<br>
>     >>     >         --with-arch=i686 \<br>
>     >>     > %endif<br>
>     >>     > %ifarch x86_64<br>
>     >>     >         --with-arch_32=i686 \<br>
>     >>     > %endif<br>
>     >>     ><br>
>     >>     > x86-64 causes gcc to use extended instruction set for produced<br>
>     >>     code and<br>
>     >>     > it's impossible to run CentOS 7 i686 on older systems<br>
>     without SSE2<br>
>     >>     > instruction because of SIGILL.<br>
>     >>     > This affects Pentium 3, old VIA CPUs, old Xeons and some<br>
>     others.<br>
>     >>     ><br>
>     >>     > Is that possible?<br>
>     >>     > Thanks!<br>
>     >>     ><br>
>     >><br>
>     >>     <snip><br>
>     >><br>
>     >>     I don't think we can do this as I also use the RPMs produced<br>
>     for the<br>
>     >>     multilib portion of CentOS-7 x86_64 and we want our RPMs to<br>
>     be like<br>
>     >>     those from upstream for that purpose.<br>
>     >><br>
>     >>     Thanks,<br>
>     >>     Johnny Hughes<br>
>     >><br>
>     >><br>
><br>
><br>
><br>
>     _______________________________________________<br>
>     CentOS-devel mailing list<br>
>     <a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a> <mailto:<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a>><br>
>     <a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Toni Spets<br>
><br>
><br>
> _______________________________________________<br>
> CentOS-devel mailing list<br>
> <a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
> <a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
><br>
<br>
<br>
<br>_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
<br></blockquote></div>