Thanks for the response and sorry for taking so long to reply.
On Mon, Jun 18, 2018 at 10:05 PM, Kevin Kofler
wrote:
> Jeff Backus wrote:
> > Hmm.. Yes, we've had discussions within the SIG re: window managers that
> > support i586/i686, and KDE was on the list of WMs that no longer support
> >
Gerd Hoffmann wrote:
> If someone wants keep 32bit fedora alive for pre-sse2 hardware I think
> the only reasonable thing would be to undust the i586 target, then go
> build software which requires sse2 as --target i686 and everything else
> as --target i586, i.e. basically stop the effort to patch
Hi,
> > effort, and nobody outside of Fedora cares about non-SSE2 anymore. Even
> > distros that claim to support non-SSE2 hardware just ship QtWebEngine as
> > SSE2 only. I haven't seen any other distro even picking up my patch, let
> > alone working on it. The Fedora Chromium, V8 and Node.j
On 06/18/2018 07:05 PM, Kevin Kofler wrote:
> Jeff Backus wrote:
>> Hmm.. Yes, we've had discussions within the SIG re: window managers that
>> support i586/i686, and KDE was on the list of WMs that no longer support
>> our target system. Do these patches/hacks only apply to KDE or do they
>> apply
Jeff Backus wrote:
> Hmm.. Yes, we've had discussions within the SIG re: window managers that
> support i586/i686, and KDE was on the list of WMs that no longer support
> our target system. Do these patches/hacks only apply to KDE or do they
> apply to Qt in general?
The absolute worst is QtWebEng
I clarified some aspects of this proposal.
After consulting with Jakub Jelinek, I'm now proposing to use
“-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign”. This
is very close to previous proposal. Only a few preprocessor macros are
different:
@@ -142,3 +142,2 @@
#define __FL
On Wed, Jun 6, 2018 at 2:09 PM, Florian Weimer wrote:
> On 06/04/2018 06:55 PM, Jeff Backus wrote:
>
> Thanks for the insight. Yes, I can see the advantages. However, have
>> things really gotten so bad that it justifies ejecting part of the
>> community?
>>
>
> The cost of i686 support is not in
El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
>
> > as part of this change I suspect we would need to make kernel
> > changes
> > to stop building a i686 kernel, and all i686 deliverables would
> > stop
> > being made.
>
>
Michal Schorm writes:
> Can someone explain me *real quick* what is the multilib good for? - or
> more precisely, why whould anone run 32-bit software on x86_64 OS?
Among other reasons, 32-bit code can be smaller and faster than 64-bit
code for some applications. When trying to stuff many conta
On 7 June 2018 at 09:07, Michal Schorm wrote:
> On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw wrote:
>>
>> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm wrote:
>>>
>>> Can someone explain me *real quick* what is the multilib good for? - or
>>> more precisely, why whould anone run 32-bit software o
On Thu, Jun 7, 2018 at 8:17 AM Richard Shaw wrote:
> The other is The Dark Mod, which is open source but they're still using
> the DOOM 3 graphics engine IIRC and their buildsystem which is still 32bit
> only.
>
HAH! Writing this caused me to google it and apparently with the latest
release ther
On Thu, Jun 7, 2018 at 6:19 AM Jan Pazdziora wrote:
>
> On Mon, Jun 04, 2018 at 10:35:34AM +0200, Jan Kurik wrote:
> > = Proposed System Wide Change: i686 Is For x86-64 =
> > https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> >
> >
> > Owner(s):
> > * Florian Weimer
> >
> >
> > Fedora
On Thu, Jun 7, 2018 at 8:09 AM Michal Schorm wrote:
> On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw wrote:
>
>> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm wrote:
>>
>>> Can someone explain me *real quick* what is the multilib good for? - or
>>> more precisely, why whould anone run 32-bit softw
On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw wrote:
> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm wrote:
>
>> Can someone explain me *real quick* what is the multilib good for? - or
>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>
> In my case, there are a couple of game
On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm wrote:
> Can someone explain me *real quick* what is the multilib good for? - or
> more precisely, why whould anone run 32-bit software on x86_64 OS?
>
In my case, there are a couple of games that are either older, or just not
provided in 64bit so I n
Because sometimes the software I'm developing needs to link with
a proprietary library that is only available as 32 bit library.
It's a lot rarer than it used to be but there are still a few
databases that I work with that don't have 64 bit libraries.
Or indeed just because our customers want a
On Mon, Jun 04, 2018 at 10:35:34AM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
> * Florian Weimer
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
>
Can someone explain me *real quick* what is the multilib good for? - or
more precisely, why whould anone run 32-bit software on x86_64 OS?
>From what I googled, it look like everyone does it yet nobody explains why
:D
--
Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Re
On 06/04/2018 06:55 PM, Jeff Backus wrote:
Thanks for the insight. Yes, I can see the advantages. However, have
things really gotten so bad that it justifies ejecting part of the
community?
The cost of i686 support is not insignificant. Most of that happens
upstream (like features only gett
On 06/04/2018 03:59 PM, Ian Pilcher wrote:
On 06/04/2018 04:28 AM, Florian Weimer wrote:
It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon
MP supports both. But the intent is what the subject says: i686
binaries are for running legacy software on x86-64 systems, and
nothin
On 06/06/2018 06:38 PM, Adam Jackson wrote:
On Mon, 2018-06-04 at 10:35 +0200, Jan Kurik wrote:
== Scope ==
* Proposal owners:
Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
new compiler flags. Except for mstackrealign, there is substantial
experience with this configura
On Mon, 2018-06-04 at 10:35 +0200, Jan Kurik wrote:
> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.
Does this change in
On Wed, 6 Jun 2018, at 2:38 AM, Dennis Gilmore wrote:
> El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> > On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> >
> > > as part of this change I suspect we would need to make kernel
> > > changes
> > > to stop building a i686 ke
El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
>
> > as part of this change I suspect we would need to make kernel
> > changes
> > to stop building a i686 kernel, and all i686 deliverables would
> > stop
> > being made.
>
>
On Tue, Jun 5, 2018 at 1:54 PM, Stephen John Smoogen
wrote:
> On 5 June 2018 at 12:49, Jeff Backus wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller <
> mat...@fedoraproject.org>
> > wrote:
> >>
> >> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> >> > Thanks for
On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> as part of this change I suspect we would need to make kernel changes
> to stop building a i686 kernel, and all i686 deliverables would stop
> being made.
We would?
- ajax
___
devel mailing lis
as part of this change I suspect we would need to make kernel changes
to stop building a i686 kernel, and all i686 deliverables would stop
being made. With the current tooling we would never be able to build 32
bit x86 containers, which is not something that is done today. I would
also be curious
On Tue, Jun 5, 2018 at 1:55 PM Stephen John Smoogen wrote:
>
> On 5 June 2018 at 12:49, Jeff Backus wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller
> > wrote:
> >>
> >> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> >> > Thanks for the data. 25k is still a pret
On 5 June 2018 at 12:49, Jeff Backus wrote:
>
>
> On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller
> wrote:
>>
>> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
>> > Thanks for the data. 25k is still a pretty healthy number. :) I realize
>>
>> Yeah, absolutely. And it's likely that t
On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller
wrote:
> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> > Thanks for the data. 25k is still a pretty healthy number. :) I realize
>
> Yeah, absolutely. And it's likely that those mirror numbers undercount,
> because not every system
On Mon, Jun 04, 2018 at 10:07:55PM -0400, Matthew Miller wrote:
> But, my gut feeling is that about half of those are not using a current
> release _anyway_. Honest question: do you think that 12k would still
> count as a healthy number? I mean, it's not peanuts. But maybe it'd be
Ooh, I should re
On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> Thanks for the data. 25k is still a pretty healthy number. :) I realize
Yeah, absolutely. And it's likely that those mirror numbers undercount,
because not every system checks in daily, and then there's also NAT.
But, my gut feeling i
On Mon, Jun 4, 2018 at 3:08 PM, Jeff Backus wrote:
>
>
> On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen
> wrote:
>>
>> On 4 June 2018 at 14:18, Matthew Miller wrote:
>> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> >> > >>support long NOPs, for Intel CET. However, t
On Mon, Jun 4, 2018 at 4:41 PM, Rex Dieter wrote:
> Jeff Backus wrote:
>
> > On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter wrote:
> >
> >> Jeff Backus wrote:
> >>
> >>
> >> > Until (unless?) we have data indicating that this is a major drain on
> >> > community resources, I'd push back on a change
Jeff Backus wrote:
> On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter wrote:
>
>> Jeff Backus wrote:
>>
>>
>> > Until (unless?) we have data indicating that this is a major drain on
>> > community resources, I'd push back on a change that actively excludes
>> part
>> > of the community. Now, if we do
On Mon, Jun 4, 2018 at 4:00 PM, Michael Cronenworth wrote:
> On 06/04/2018 02:50 PM, Jeff Backus wrote:
>
>> Thanks for the data. 25k is still a pretty healthy number. :) I realize
>> that there are a lot of unknowns in the data, so it is difficult to draw
>> any hard conclusions, but 25k is stil
On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen
wrote:
> On 4 June 2018 at 14:18, Matthew Miller wrote:
> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> >> > >>support long NOPs, for Intel CET. However, the majority of
> >> > >>installations of i686 packages is for use
On 06/04/2018 02:50 PM, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize that there
are a lot of unknowns in the data, so it is difficult to draw any hard
conclusions, but 25k is still much larger than 0. Splitting into i686 into i586
and i686 would giv
On Mon, Jun 4, 2018 at 2:18 PM, Matthew Miller
wrote:
> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > > >>support long NOPs, for Intel CET. However, the majority of
> > > >>installations of i686 packages is for use on x86_64 systems, as
> > > >>multi-lib RPMs.
> > > >Based
On 4 June 2018 at 14:18, Matthew Miller wrote:
> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> > >>support long NOPs, for Intel CET. However, the majority of
>> > >>installations of i686 packages is for use on x86_64 systems, as
>> > >>multi-lib RPMs.
>> > >Based on what data
On Mon, Jun 4, 2018 at 2:01 PM, Matthew Miller
wrote:
> On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> > >>only addition over the i686/Pentium Pro baseline is a requirement to
> > >>support long NOPs, for Intel CET. However, the majority of
> > >>installations of i686 packages
On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter wrote:
> Jeff Backus wrote:
>
>
> > Until (unless?) we have data indicating that this is a major drain on
> > community resources, I'd push back on a change that actively excludes
> part
> > of the community. Now, if we do have data indicating that suppo
On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer
wrote:
> On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus wrote:
> >
> >
> >
> > On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer
> wrote:
> >>
> >> On 06/04/2018 05:55 PM, Jeff Backus wrote:
> >>>
> >>> Would you please provide more detail on what problem o
On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > >>support long NOPs, for Intel CET. However, the majority of
> > >>installations of i686 packages is for use on x86_64 systems, as
> > >>multi-lib RPMs.
> > >Based on what data?
> > The mirror data I've seen, but it's really outda
On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> >>only addition over the i686/Pentium Pro baseline is a requirement to
> >>support long NOPs, for Intel CET. However, the majority of
> >>installations of i686 packages is for use on x86_64 systems, as
> >>multi-lib RPMs.
> >Based o
On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus wrote:
>
>
>
> On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer wrote:
>>
>> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>>>
>>> Would you please provide more detail on what problem or problems we are
>>> trying to solve? Is this purely for efficiency re
Jeff Backus wrote:
> Until (unless?) we have data indicating that this is a major drain on
> community resources, I'd push back on a change that actively excludes part
> of the community. Now, if we do have data indicating that supporting
> non-SSE2 systems with the i686 architecture is a not-ins
On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer wrote:
> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>
>> Would you please provide more detail on what problem or problems we are
>> trying to solve? Is this purely for efficiency reasons?
>>
>
> Mainly developer efficiency. There will be fewer test
* Chris Adams [04/06/2018 10:58] :
>
> I think you are missing a some of The Atom chips that are 32-bit only;
> there are versions that were released as late as 2010 that don't support
> 64-bit (I don't know when they were discontinued).
You're thinking of the Lincroft series of Intel CPUs:
http:/
On 06/04/2018 05:55 PM, Jeff Backus wrote:
Would you please provide more detail on what problem or problems we are
trying to solve? Is this purely for efficiency reasons?
Mainly developer efficiency. There will be fewer test suite problems
due to excess precision (a bunch of packages carry pa
On Mon, Jun 4, 2018 at 11:52 AM, Adam Jackson wrote:
> On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> > On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > >
> > > > > > This proposal suggests to accept this reality and build
On Mon, Jun 4, 2018 at 11:01 AM, Adam Jackson wrote:
> On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> > On 06/04/2018 04:28 AM, Florian Weimer wrote:
> > > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon
> MP
> > > supports both. But the intent is what the subject
Once upon a time, Adam Jackson said:
> Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
> Intel chip was Yonah (Core 1), which went out of production in 2008-
> ish, so there's about seven years worth of CPUs between the
> introductions of SSE2 and AMD64.
I think you are missing
On Mon, Jun 4, 2018 at 7:20 AM, Florian Weimer wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
> * Florian Weimer
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib
> RPMs.
>
>
>
On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> >
> > > > > This proposal suggests to accept this reality and build the i686
> > > > > packages in such a way that they require the
On Mon, Jun 4, 2018 at 8:23 AM, Ralf Corsepius wrote:
> On 06/04/2018 11:28 AM, Florian Weimer wrote:
>>
>> On 06/04/2018 10:50 AM, Guido Aulisi wrote:
>
>
>> It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
>> supports both. But the intent is what the subject says: i686 b
On Monday, June 4, 2018, 4:35:34 AM, Jan Kurik wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> Owner(s):
> * Florian Weimer
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
> == Detailed d
On 06/04/2018 05:07 PM, Adam Jackson wrote:
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.
On which x86 CPU families will Fedora continue t
On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > > This proposal suggests to accept this reality and build the i686
> > > packages in such a way that they require the ISA level of (early)
> > > x86-64 CPUs.
> >
> > On which x86 CPU families will Fedora continue to work?
>
> Based on
On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> On 06/04/2018 04:28 AM, Florian Weimer wrote:
> > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
> > supports both. But the intent is what the subject says: i686 binaries
> > are for running legacy software on x86-
On Mon, Jun 4, 2018 at 10:09 AM Ralf Corsepius wrote:
>
> On 06/04/2018 11:28 AM, Florian Weimer wrote:
> > On 06/04/2018 10:50 AM, Guido Aulisi wrote:
>
> > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
> > supports both. But the intent is what the subject says: i686 b
On 06/04/2018 02:39 PM, Alexander Ploumistos wrote:
== Detailed description ==
Currently, the i686 RPM packages are built in such a way that they are
compatible with very old i686 systems, such as the Pentium III. The
only addition over the i686/Pentium Pro baseline is a requirement to
support l
On 06/04/2018 04:28 AM, Florian Weimer wrote:
It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
supports both. But the intent is what the subject says: i686 binaries
are for running legacy software on x86-64 systems, and nothing more.
So the 32-bit x86 SIG would be requ
On 06/04/2018 11:28 AM, Florian Weimer wrote:
On 06/04/2018 10:50 AM, Guido Aulisi wrote:
It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
supports both. But the intent is what the subject says: i686 binaries
are for running legacy software on x86-64 systems, and noth
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III. The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET. However, the major
On 06/04/2018 10:50 AM, Guido Aulisi wrote:
This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.
Will Fedora 29 run on the CPU listed above?
It should, because -march=x86-64 implies just SSE2 and FXSR,
2018-06-04 10:35 GMT+02:00 Jan Kurik :
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
> * Florian Weimer
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
>
>
>
> == Detailed descr
= Proposed System Wide Change: i686 Is For x86-64 =
https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
Owner(s):
* Florian Weimer
Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
== Detailed description ==
Currently, the i686 RPM packages are built in su
68 matches
Mail list logo
