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 at centos.org> написал: > On 06/06/2015 02:43 AM, Toni Spets wrote: > > > > > > On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <johnny at centos.org > > <mailto:johnny at 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 at centos.org > <mailto:johnny at centos.org> > > >> <mailto:johnny at centos.org <mailto:johnny at 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 at centos.org <mailto:CentOS-devel at centos.org> > > http://lists.centos.org/mailman/listinfo/centos-devel > > > > > > > > > > -- > > Toni Spets > > > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > http://lists.centos.org/mailman/listinfo/centos-devel > > > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150606/d7e19cdb/attachment-0008.html>