Re: 32-bit UEFI (was: Re: Validity of i686 as a release blocker)

On Sat, 2016-04-23 at 09:27 -0600, Stephen John Smoogen wrote: > >> > >> Just to this point - if we wanted to support the Baytrail tablets > >> properly we should probably get 64-on-32 working. Allowing 32-bit > UEFI > >> installs probably isn't something we want to do officially. > > > > > > Has

Re: 32-bit UEFI (was: Re: Validity of i686 as a release blocker)

On Apr 23, 2016 09:18, "Florian Weimer" wrote: > > On 08/13/2015 03:17 PM, Adam Williamson wrote: >> >> On Tue, 2015-08-04 at 10:47 -0400, Matthew Miller wrote: >>> >>> On Tue, Aug 04, 2015 at 10:40:28AM -0400, Paul W. Frields wrote: "Ambivalent" is probably

32-bit UEFI (was: Re: Validity of i686 as a release blocker)

On 08/13/2015 03:17 PM, Adam Williamson wrote: On Tue, 2015-08-04 at 10:47 -0400, Matthew Miller wrote: On Tue, Aug 04, 2015 at 10:40:28AM -0400, Paul W. Frields wrote: "Ambivalent" is probably understated here. It's hard to imagine people securing i686 hardware these days to run a

Re: Validity of i686 as a release blocker

Am 15.08.2015 um 14:50 schrieb Matthew Miller: On Sat, Aug 15, 2015 at 06:47:44AM +0200, Ralf Corsepius wrote: Definitely. 10/15 years+ ago, [...] [...] Also, in those days, devs cared about efficiency. Nowadays, they don't care as much, People have been making this exact complaint since

Re: Validity of i686 as a release blocker

On Sat, Aug 15, 2015 at 06:47:44AM +0200, Ralf Corsepius wrote: Definitely. 10/15 years+ ago, [...] [...] Also, in those days, devs cared about efficiency. Nowadays, they don't care as much, People have been making this exact complaint since the 1970s. Probably before. -- Matthew Miller

Re: Validity of i686 as a release blocker

On 08/14/2015 12:00 PM, Richard Z wrote: I regularly use i686 and have not done a fresh install since years so would not detect this. Maybe fresh installs aren't such a deal for i686 users Well, from my experience, fresh installs on i686 are a major problem w/ Fedora, because Fedora's SW

Re: Validity of i686 as a release blocker

On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: In February[2] we sent out an email highlighting that the kernel team was not going to treat i686 bugs as a priority. Since that time, we have held true to our word and have not focused on fixing i686 bugs at all. It seems that the

Re: Validity of i686 as a release blocker

On Tue, 2015-08-04 at 10:47 -0400, Matthew Miller wrote: On Tue, Aug 04, 2015 at 10:40:28AM -0400, Paul W. Frields wrote: Ambivalent is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. The question, I

Re: Validity of i686 as a release blocker

On 6 August 2015 at 10:04, Pete Travis li...@petetravis.com wrote: \ Perhaps the best approach, from a community perspective, would be to promote a spin to Edition status and recommend *that* for i686 or low resource desktop use cases. --Pete That would require people volunteering to

Re: Validity of i686 as a release blocker

On Tue, Aug 04, 2015 at 10:40:28 -0400, Paul W. Frields sticks...@gmail.com wrote: Ambivalent is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. I still use i686 for my primary server, primary desktop and

Re: Validity of i686 as a release blocker

On Aug 4, 2015 9:40 AM, Paul W. Frields sticks...@gmail.com wrote: On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: [...snip...] Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it

Re: Validity of i686 as a release blocker

On 08/04/2015 05:12 PM, Bill Nottingham wrote: Paul W. Frields (sticks...@gmail.com) said: Here's my perspective as an i686 Fedora user... I have a box (2009-ish) that's in use as a file/backup server. I have 3 i686 boxen. 2 are 2009-ish atom-netbook, one is a 2000-ish PIII-desktop. As

Re: Validity of i686 as a release blocker

On Tue, 2015-08-04 at 11:12 -0400, Bill Nottingham wrote: Here's my perspective as an i686 Fedora user... I have a box (2009-ish) that's in use as a file/backup server. As such, I don't spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs the prereleases until

Validity of i686 as a release blocker

Hello, Over the past week, we've been dealing with a kernel bug[1] that prevents i686 machines from booting. Help was requested and given, and it has been excellent and most welcome. This email has no reflection on that, and is instead focused on the reality of where i686 stands today. In

Re: Validity of i686 as a release blocker

On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: [...snip...] Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking architecture. This is not the same as demotion to

Re: Validity of i686 as a release blocker

On Tue, Aug 04, 2015 at 10:40:28AM -0400, Paul W. Frields wrote: Ambivalent is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. The question, I think, is how much we want to prioritize the Workstation

Re: Validity of i686 as a release blocker

Paul W. Frields (sticks...@gmail.com) said: On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: [...snip...] Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking

Re: Validity of i686 as a release blocker

Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking architecture. This is not the same as demotion to secondary architecture status. That has broader implications in

Re: Validity of i686 as a release blocker

On 08/04/2015 08:38 AM, Peter Robinson wrote: A lot of the users of i686 that I know use it from live images or installing live images which, and I've not followed the issue too closely so might be a little off here, wouldn't have hit the bug that was being seen by the installer side of things.