Re: End of i686 Support
by Jeff Backus
On Sun, Sep 3, 2017 at 7:54 PM, Eddie O'Connor <eoconnor25(a)gmail.com> wrote:
> While I myself don't have any x86 hardware, I know many people whom I've
> introduced to Linux that are running it on their x86 machines. SO yes, this
> architecture should still be supported, (at least until say...'20?...a nice
> round figure!) After that? I might make more sense to drop it since most of
> the OEM's are manufacturing x64 machines only. (Very rarely can you find old
> technology on a manufacturer's web site. check Dell, HP, Lenovo, Acer,
> etc....you'll see nothing but x64 machines)....just my two cents. Also I'll
> be passing this link on to those who might be able to contribute. I might
> even find an old PC and try to help out myself....anything for the
> "Fedorians" that make my computing life easier and more pleasant!)
Great! Thanks for spreading the word. The more the merrier!
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
6 years, 7 months
Re: X86 meeting 1900 UTC 2017-09-06
by Stephen John Smoogen
My apologies. I put in the wrong month. It will be September 6, 2017.
On 2 September 2017 at 15:57, Stephen John Smoogen <smooge(a)gmail.com> wrote:
> There will be a meeting in #fedora-meeting-2 on 1900 UTC (1500 EDT for
> US timezones) to go over the setup of the x86 group
>
> #startmeeting x86
> #meetingname x86
> #chair smooge jbackus
> #topic Roll Call
> #topic What does FESCO want
> #info People who know how to advocate to upstreams
> #info Advocating does not mean 'whining or begging'.
> #info Advocating means working with upstream maintainers (kernel-list,
> glibc, etc) to fix bugs.
> #info Fedora is always moving forward. What does x86_32 have?
> #topic What next?
> #info Who will advocate?
> #info Who will fix packages?
> #info Who will show up?
> #endmeeting
>
>
>
> --
> Stephen J Smoogen.
--
Stephen J Smoogen.
6 years, 7 months
End of i686 Support
by Jeff Backus
Hello Fedora!
As you may or may not be aware, there is an active discussion on the development side as to whether or not we continue to support the x86 architecture.
There are a lot of exciting things happening within the Fedora community on top of the amazing and significant effort we put into making sure Fedora is stable, robust, and on the bleeding edge. And unfortunately, the contributors doing all of this work are a limited resource so we have to prioritize where we focus our attention.
Since x86-based hardware isn't very common anymore, it is understandable that most of the development side of the community is ready to move on and focus on other things that directly impact them. However, some of us still have a desire to see Fedora continue to support this venerable architecture.
Is x86 support still important to you? If so, then come join us! We need all of the help we can get. Not a developer? No problem! We still need people with hardware to help us evaluate software.
For those interested, you can find more information on the x86 Architectures page:
https://fedoraproject.org/wiki/Architectures/x86
You can also find us on the x86 mailing list:
x86(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/x86.lists.fedoraproject.org/
We're also holding an organizational meeting on IRC in #fedora-meeting-2 on September 6th at 1900 UTC. We'd love to see you there!
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
http://gitlab.com/jsbackus
6 years, 7 months
Re: Organizational Deadline
by Jeff Backus
On Sat, Sep 02, 2017 at 01:32:11PM -0700, Adam Williamson wrote:
>On Fri, 2017-09-01 at 22:09 -0400, Jeff Backus wrote:
>>
>> Thanks for so much information. Very helpful. The automated tests,
>> are they easy to automate on actual hardware? or do key parts of the
>> automated tests sit outside of the VM?
>
>It's possible, but not easy. The test runner sits outside the system
>under test and does several things - mainly, inject keypresses and
>mouse movements, and watch the screen. It also needs to monitor the
>serial output. There are some other things (like taking snapshots, and
>monitoring audio) but those are the main ones. Upstream openQA (which
>is basically SUSE) *does* have backends (the test runner's a pretty
>modular design) which use real hardware, rather than virtual machines,
>but it requires several special bits of hardware to achieve all the
>above, and I've never tried it out at all, only looked at the code and
>thought 'huh, that looks interesting' - I don't even know whether the
>code is really used in anger at all at SUSE. Looking into this is
>possible, but it would not be trivial - it'd be a multi-week project
>for someone.
Interesting! Yes, I think that is a much larger effort than we have resources for. Thanks for the clarification.
>> It sounds to me like the best ways the SIG can help QA is:
>> * Be a primary resource (hardware and warm bodies) for debugging
>> i686-related boot, kernel, driver, and instruction-set related issues
>> * Help with testing
>> * Help triage all other i686-related issues in Bugzilla
>> * more testing!
>
>This sounds about right, except that I'd conceive of it exactly the
>other way around: *we* (QA) are helping *you* (the SIG), by providing
>test cases, release validation events and so on. We're providing
>resources to help you ensure the x86 packages and deliverables work
>well. That's kinda the model I like to use for thinking about things in
>these days where we have zillions of arches and different bits of the
>distro that people are interested in; it's never going to be the case
>that QA per se is going to test them all, so especially outside of the
>release-critical stuff, we like to think of ourselves as providing the
>support for SIGs, WGs and interested users to test the bits they care
>about.
Gah. Yes, you're right. That point of view makes a lot more sense in the grand scheme of things.
>> Are there any additional critical shortfalls? I know there is no
>> shortage of ways we can help, but I want to start with the severe
>> needs first.
>
>That was all I had off the top of my head, as I said, I'm happy to
>answer any other specific questions :)
You have been very helpful. I think we have enough to get started. Thanks again for all of your insight!
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
http://gitlab.com/jsbackus
6 years, 7 months
X86 meeting 1900 UTC 2017-08-06
by Stephen John Smoogen
There will be a meeting in #fedora-meeting-2 on 1900 UTC (1500 EDT for
US timezones) to go over the setup of the x86 group
#startmeeting x86
#meetingname x86
#chair smooge jbackus
#topic Roll Call
#topic What does FESCO want
#info People who know how to advocate to upstreams
#info Advocating does not mean 'whining or begging'.
#info Advocating means working with upstream maintainers (kernel-list,
glibc, etc) to fix bugs.
#info Fedora is always moving forward. What does x86_32 have?
#topic What next?
#info Who will advocate?
#info Who will fix packages?
#info Who will show up?
#endmeeting
--
Stephen J Smoogen.
6 years, 7 months
Fwd: No i686 kernel: Can we require SSE2 for i686?
by Stephen John Smoogen
Can anyone look at these and look for fixes? Thanks
---------- Forwarded message ----------
From: Ralf Corsepius <rc040203(a)freenet.de>
Date: 28 August 2017 at 11:05
Subject: Re: No i686 kernel: Can we require SSE2 for i686?
To: devel(a)lists.fedoraproject.org
On 08/28/2017 04:35 PM, Florian Weimer wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1482798
>> (Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd)
>
>
> That's definitely a bug for F27.
nss-softok is broken in similar ways on fedora-26-i686
Ralf
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
6 years, 7 months
Re: Organizational Deadline
by Jeff Backus
On Wed, Aug 30, 2017 at 07:57:39AM -0400, Adam Williamson wrote:
>
>Not sure specifically what I can contribute, but please do say a bit
>more precisely what you think I could help with and I'll do my best to
>either provide answers/help or point you to someone more useful than
>myself :)
>
>AFAIK there are no formal functionality requirements for non-release-
>blocking arches...really anywhere. You can obviously use the release
>criteria that apply to release-blocking arches as a general guide to
>what a 'working Fedora' looks like, but you aren't required by any
>process to fully meet them at any point.
>
>We do run automated testing of i686 composes in openQA, and packages in
>Taskotron. The openQA tests are run on x86_64 VMs, however; we ran them
>on emulated 32-bit VMs for a while but ran into several problems there
>which were apparently specific to the qemu/kvm emulation of a 32-bit
>CPU (qemu32) and were told it's a path that isn't heavily supported by
>the virt folks, so we stopped doing that. We also don't run anywhere
>close to the *whole* set of tests on i686, mainly because we don't have
>enough worker capacity to do that. We run a subset of key tests.
>
>I don't believe the Red Hat Fedora QA team has any non-x64 testing
>hardware in our regular inventory, but it's likely that some Fedora QA
>contributors do.
>
>Just as a general note, although it's kinda obvious and you may well
>have thought of it already, I would suggest talking to the other
>currently-active and organized non-blocking arch groups about their
>process and see what you can crib. The ppc64 group in particular is
>pretty active.
Thanks for taking the time to respond!
Contacting the ppc64 group is a great suggestion. I'll try to touch base with them.
Thanks for so much information. Very helpful. The automated tests, are they easy to automate on actual hardware? or do key parts of the automated tests sit outside of the VM?
It sounds to me like the best ways the SIG can help QA is:
* Be a primary resource (hardware and warm bodies) for debugging i686-related boot, kernel, driver, and instruction-set related issues
* Help with testing
* Help triage all other i686-related issues in Bugzilla
* more testing!
Are there any additional critical shortfalls? I know there is no shortage of ways we can help, but I want to start with the severe needs first.
Thanks!
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
http://gitlab.com/jsbackus
6 years, 7 months
Organizational Deadline
by Jeff Backus
Hi All,
Not sure if anyone else is aware, but it looks like FESCo voted to give us
until September 8th to get organized or i686 is being pulled from kernels
for F28. The good news is that they are letting us define what "organized"
means. The bad news is that the clocks ticking.
So, thoughts?
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
6 years, 7 months
