x86
LOGS
19:00:06 <smooge> #startmeeting x86
19:00:06 <zodbot> Meeting started Wed Sep  6 19:00:06 2017 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:06 <zodbot> The meeting name has been set to 'x86'
19:00:06 <smooge> #meetingname x86
19:00:06 <zodbot> The meeting name has been set to 'x86'
19:00:06 <smooge> #chair smooge jsbackus
19:00:06 <zodbot> Current chairs: jsbackus smooge
19:00:06 <smooge> #topic Roll Call
19:00:33 <smooge> Hello I am not sure jsbackus will be able to be here. but I am looking for which people are here for a meeting on the future of x86
19:02:20 <athos> Hello! I am here. No kernel experience though :( I do want to see how things go here and if this would be a oportinuty to help somehow :)
19:02:44 <smooge> hello athos
19:03:04 <alexpl> .hello alexpl
19:03:05 <zodbot> alexpl: alexpl 'None' <alex.ploumistos@gmail.com>
19:04:01 <alexpl> wow, great, I forgot to set up my ID
19:04:10 <smooge> or you have privacy set up
19:04:38 <jsbackus> hi all
19:04:42 <smooge> So the goal of the meeting is to go over what is needed to found a group and to get it working
19:04:50 <smooge> #chair smooge jsbackus
19:04:50 <zodbot> Current chairs: jsbackus smooge
19:05:08 <smooge> #topic What does FESCO want
19:05:09 <smooge> #info People who know how to advocate to upstreams
19:05:09 <smooge> #info Advocating does not mean 'whining or begging'.
19:05:09 <smooge> #info Advocating means working with upstream maintainers (kernel-list,
19:05:09 <smooge> glibc, etc) to fix bugs.
19:05:10 <smooge> #info Fedora is always moving forward. What does x86_32 have?
19:05:41 <smooge> So last week was Fedora Flock conference and I tried to talk with various fesco and kernel people on what is wanted and needed for x86
19:06:15 <smooge> the main thing was to find people who are interested in advocating to upstream on problems found and getting them fixed.
19:06:58 <smooge> advocating is a task where you communicate what the bug is, how it is seen, and finding the appropriate people in the correct upstream to see if it is fixable
19:07:27 <smooge> so for the kernel, it is finding who the maintainer of a section of the kernel is and seeing if they can fix the problem.
19:08:38 <smooge> one of the problems is that a lot of people who try to advocate can do it all wrong by coming across as passive aggressive and make the maintainer more angry than actually get a fix
19:09:10 <smooge> so the people involved in this need to be able to work with other people
19:10:58 <alexpl> And when upstream is unwilling or non-existent, we drop the packages from the arch?
19:11:49 <jsbackus> I suppose it depends on what the issue is. If it is related to build flags, we can probably just include a patch in the spec. e.g. sse2
19:12:17 <smooge> The other item in talking with various developers (all over not just on Fesco) was that people wanting to keep x86 in Fedora need to have a story about why x86 is important and something to move forward on. Keeping it up for old hardware to keep running might be better off using CentOS-6 or something similar because many new features use more memory or cpu characteristics that x86_32 does not have
19:12:55 <jsbackus> Hmmm..
19:13:39 <smooge> that is pretty much all I have from Flock that I can remember.
19:14:01 <jsbackus> Thanks! Very helpful.
19:14:34 <jsbackus> To the first point, sounds reasonable and I'm willing to help with interfacing with upstream.
19:15:31 <jsbackus> I suppose two implicit parts of that first point are a) we need to trawl bugzilla looking for issues and b) we need to also follow-up with upstream on fixes that they agreed to do, etc.
19:16:07 <alexpl> And I suppose we should also keep in touch with packagers
19:16:31 <jsbackus> Good point. grub is a good example of that
19:17:00 <smooge> oh from the kernel devels: a third point which would make kernel easier to deal with is if you drop PAE and add SSE2 a lot of code paths are more used/less buggy.
19:19:58 <jsbackus> Ahh. Good to know. Do we have an idea of how prevalent PAE is?
19:21:36 <jsbackus> I don't have any machines that need it, so I won't object to it being dropped.
19:21:56 <smooge> PAE was really a hack to get around the 3.2 GB limit on x86_32
19:22:28 <alexpl> Not that I consider this a comprehensive sample, but of all the systems I have worked with in the last decade, there might have been just a couple outside datacenter equipment
19:22:31 <smooge> when I dealt with it, it slowed down usage by 30-60%
19:22:42 <smooge> so we moved it all to x86_64
19:23:37 <jsbackus> Sounds like it was for an edge case that is better served by x86_64 anyway. Plus, it only affects the kernel, so worst case we could set up a PAE copr if there was a lot of interest
19:24:16 <alexpl> Dropping SSE2 is quite the opposite though
19:24:27 <smooge> well it isn't dropping. it is enabling it
19:24:35 <jsbackus> Agreed. It affects everything.
19:24:43 <alexpl> mispoke
19:24:46 <smooge> no problem
19:26:02 <jsbackus> Did the kernel devs give any indication if adding SSE2 was a big benefit or a nice to have? i.e. I'm sure dropping PAE makes their lives much easier. Same with adding SSE2?
19:27:10 <smooge> I didn't ask about that. It helped some security issues and helped with the glibc/etc builds because less special cases needing to be taken care of
19:27:38 <jsbackus> Ahh. Yes, I can see that.
19:29:27 <smooge> brb
19:29:34 <jsbackus> Perhaps we put a "we'll see" on adding SSE2 while we gauge interest
19:31:21 <alexpl> That should leave 2 out of 3 machines I have available out. On the other hand, by mid-November I will be going away until sometime in August, so I won't be able to test anything on them.
19:31:50 <alexpl> One is a PIII, the other has dual Athlon MP
19:32:16 <smooge> What would you run on them?
19:32:50 <jsbackus> Your PIII still runs current "i686" Fedora?
19:33:41 <alexpl> The PIII is a server, which (happily) runs Gentoo. I was considering switching over to Fedora, but at that time I saw the first discussions about dropping support for old hardware, so I left it with Gentoo
19:34:05 <alexpl> updates are always long and painful, but it is still running
19:34:47 <jsbackus> I bet
19:35:24 <alexpl> The venerable Athlon MP workstation has been struggling with our default settings, so I've had to rebuild some rpms from time to time
19:36:13 <alexpl> some things run slower on it than on my old Aspire One
19:37:19 <smooge> the desktop people I talked with did not expect any of the modern desktops to work on less machines with 2-4GB ram
19:38:07 <jsbackus> Well, if we have the interest and the hardware, I'm willing to try supporting non-SSE2 hardware. I suspect the PIII will have trouble. I'm sure MMX is fairly common.
19:38:36 <alexpl> so, should we go back to re-examining our motives for this SIG?
19:38:37 <jsbackus> Not surprising, though XFCE still runs pretty well on <1GB. Haven't tried LXDE in a while.
19:39:37 <jsbackus> The modern desktops aspect doesn't have much interest to me - they require a lot of hardware beyond memory to run well
19:40:00 <smooge> this goes into what kind if i686 spin you will be wanting to build
19:40:09 <jsbackus> Gnome 2 used to run fine on <1GB. MATE might still?
19:40:11 <smooge> so it does answer alexpl's question
19:40:29 <jsbackus> Good point.
19:40:45 <smooge> MATE, XFCE, LXDE are moving to the newer gtk which wants hardware rendering
19:40:58 <jsbackus> Oh
19:41:01 <jsbackus> Youch.
19:41:14 <smooge> without it you end up needing to do software rendering which eats ram
19:41:24 <smooge> and cpu
19:41:28 <jsbackus> What about LXQt?
19:41:38 <jsbackus> Yeah, good point.
19:41:44 <smooge> Qt went to hardware rendering a while ago
19:42:01 <jsbackus> Ahh.
19:42:18 <asunz> Hello, hope I'm not too late
19:42:27 <jsbackus> Welcome!
19:43:19 <alexpl> do you know if enlightenment might still be usable?
19:43:26 <jsbackus> We're discussing what desktop to target, since many of the lower-spec ones are moving to hardware rendering
19:43:46 <jsbackus> Been a while since I tried it
19:44:17 <smooge> well first do you want to target a desktop?
19:44:51 <asunz> Has LXDE been mentioned yet?
19:45:01 <smooge> many have been mentioned
19:45:04 <alexpl> (10:40:45 PM) smooge: MATE, XFCE, LXDE are moving to the newer gtk which wants hardware rendering
19:45:29 <jsbackus> Good point re: target. We might be better served targeting 'tiny server'
19:45:41 <smooge> so next thing. I have had a horrible track record today so please test and look at these things before assuming I am right
19:46:05 <jsbackus> Funny thing about short weeks - every day is a Monday.
19:46:55 <smooge> I would say if you are going to look at a desktop, choose a particular hardware you want to support. [AKA say you will want to test/work on x86 OLPC hardware or something like that]
19:47:25 <smooge> trying to do anything broadstream is going to end up with trying to get x86 people to look at hardware they may not have anymore etc etc
19:47:35 <jsbackus> Good point.
19:48:18 <smooge> having a working story of what you are going to accomplish will help make sure Fedora developers are wanting to work with you versus ignore.
19:49:08 <smooge> and I expect I should move this to the topic we are actually talking about
19:49:15 <smooge> #topic What next?
19:49:15 <smooge> #info Who will advocate?
19:49:16 <smooge> #info Who will fix packages?
19:49:16 <smooge> #info Who will show up?
19:50:24 <jsbackus> These days I don't have much free time, but I'm willing to help advocate and fix packages.
19:51:21 <jsbackus> We seem to have had some luck with people who don't want to officially commit helping out from time to time.
19:51:42 <smooge> So confession time. I worked on the the x86 mailing list, irc channel etc mainly because certain emails on devel said that it was too hard to do any of that so they were sort of false barriers to making a SIG possible. I figured if they were too hard I would do it and turn it over to people who really were interested
19:52:22 <asunz> Sorry if this has been mentioned already, but there's cases of modern-ish Atom cpu's that, even though they're 64-bit capable, manufacturers sometimes disable 64-bit support
19:52:35 <jsbackus> Yes, I figured, and I appreciate the help.
19:52:57 <smooge> my main goal is to make sure any internal barriers are cleared up and that you knew who to talk to in case there were still barriers
19:53:00 <jsbackus> Ahh. Interesting. Is this due to EFI?
19:53:58 <asunz> I haven't been able to determine exactly why, but such is my case with an Atom N2600 cpu
19:54:16 <jsbackus> Thanks. Particularly helpful for those of us who haven't been heavily involved with Fedora for years.
19:55:12 <smooge> Most of the time I dealt with locked down cpus it is a pricing issue. Chips which are 64 bit but don't pass 64 bit testing can still work fine in 32 bit mode for a while
19:55:58 <asunz> Makes sense, these laptops are given to students where I live
19:56:51 <smooge> The other issue is that some sites have licensing issues and want to make sure that the hardware does not accidently cause a license issue. [AKA oracle asking for money because you ran a 64 bit version but you were only supposed to use 32 bit]
19:57:03 <jsbackus> With respect to FESCo, I think we present a plan and if we can demonstrate long-term commitment, then we keep i686 support in F28. Otherwise, we gave it a try and can be content with that. As you mentioned earlier - this needs to survive without heroic effort
19:58:02 <smooge> jsbackus, I think that if there are 1 person committed to it and 3-4 people picking up the edge cases it should be provable to see if it can work in F28 timeframe
19:58:07 <athos> Well, I am willing to put some time here :) I do have access to an old athlon and I can help fixing packages. I may take some time/bothering some of you since I have no previous experience with kernel stuff
19:58:25 <smooge> Most of the issues are mostly choosing some solution and sticking to it
19:59:09 <asunz> I'm not a OS developer (I know very little C) but I'm willing to help in any way I can
19:59:16 <smooge> the problems in i386 usually end up being too much spread for such a 'small' hardware
19:59:47 <alexpl> More confessions: Things have changed for me for the worse since the first call for this group. I will be leaving the country at the end of the year and I need to finish a thesis asap. Starting next month, I will also be working two jobs, trying to stay afloat (financially). I will have to part with my PIII and Athlon MP while I'm away, but I could take the Aspire One with me and use it for testing. Though, if we are opting for
19:59:48 <alexpl> a "tiny server" solution, that would mean testing only base packages.
20:00:52 <smooge> so for the ARM and other os's. it was build to a particular set of systems and only say X->Z were hardware which are 'critical'. Stuff outside fo that is 'nice if it works' and 'fix if we can'.
20:01:16 <smooge> Then once an OS was built and shown that it worked, people started coming into help more and more.
20:01:53 <jsbackus> Good point. For us it will hopefully be a little bit easier - we just have to keep it running. :)
20:02:06 <smooge> jsbackus, the other person who would be useful in any problematic code would be Hans de Goede. He is an excellent coder who does seem intersted in the amount of time he can give
20:03:04 <smooge> jsbackus, I was thinking that it would be useful to have a similar story. When ARM was starting up, a lot of energy was getting sapped by everyone wanting every board, every software and every combination all supported.
20:03:51 <smooge> They went to the limited set because it was clearer to say "For this release this is what we are working on. If you aren't in that group we can look at you after this or you can help us help you.. but we aren't able to focus outside of this"
20:04:43 <smooge> so for people who are interested and can give even small amounts of time which sound like asunz and athos. Please put your names on the Fedora wiki page for the group. That will help FESCO know you are interested
20:04:55 <jsbackus> smooge, Yes, there is a lot of wisdom in that. I propose: we drop PAE. We tentatively support non-SSE2. We target a second tier desktop, i.e. LXDE or XFCE until they switch to GTK3, then we will revisit. We target >512MB. Thoughts?
20:04:57 <smooge> alexpl, I understand completely what that can be like
20:05:28 <smooge> so if you feel good about signing up do so, but if you don't there is no problem with you not doing so
20:06:01 <jsbackus> alexpl, ouch! I understand completely. I've been there.
20:06:27 <asunz> Will do, I signed up a few days ago already
20:06:35 <smooge> jsbackus, I would be a bit more aggressive. I would say that for F27, each current desktop would be tested and one will be focused on for F28 as a spin.
20:07:08 <smooge> tested being "we ran it on X,Y,Z systems and found it worked or the box went to swap heaven" (or something like that)
20:07:22 <jsbackus> Yes, I see your point.
20:07:33 <jsbackus> We want the data anyway to help focus us.
20:07:53 <alexpl> Thank you. I would like to keep at least that Aspire One going for as long as possible, so I am willing to commit time and effort in the middle of the stream, talking to people, but I am lacking on the coding side.
20:07:58 <smooge> it probably would take people a weekend to do that and it would allow for "we chose not your favourite desktop because of X" to be written u
20:08:37 <jsbackus> alexpl, what you can provide would be greatly appreciated - but focus on what is most important.
20:08:41 <smooge> jsbackus, also please tell me to shut the hell up when you want.. its your meeting :0
20:08:55 <jsbackus> smooge, hah! No, you are super helpful.
20:09:07 <jsbackus> I think I have enough to make a case to FESCo.
20:09:28 <jsbackus> I'll take on responsibility for trying to keep the lights on.
20:09:52 <smooge> ok cool.
20:10:08 <jsbackus> We'll see how much participation we actually get. If events leading up to now are any indication, I think we'll be pleasantly surprised.
20:10:28 <jsbackus> But yes, we need to define a target (for F28) and go from there - or we'll drive ourselves nuts.
20:12:04 <jsbackus> I'll put some thought into your point #2, the story part. Easy to underestimate that, but is important to be able to verbalize how i686 still fits into the grander vision of Fedora.
20:13:30 <jsbackus> Probably time to wrap this up. Any final thoughts? Everyone signed up for the mailing list?
20:13:31 <smooge> Yeah. it helps get people to see why to care
20:13:38 <smooge> #topic Open Floor
20:14:17 <jsbackus> Yes. Very good point. "Because I want" doesn't work so well
20:14:30 <alexpl> Honestly, for me it is mainly a matter of convenience:
20:15:46 <alexpl> it IS convenient to switch all my machines to a single distro and deal with one set of problems, without having to learn a different workflow when on another computer
20:16:24 <alexpl> and having all the recent packages that we get in Fedora, is also a huge bonus
20:16:45 <athos> can I get a link to the wiki?
20:16:47 <jsbackus> I think part of that is highlighting that there are many important parts of Fedora that aren't related to the "new hotness".
20:16:50 <athos> maling list etc
20:17:11 <jsbackus> https://fedoraproject.org/wiki/Architectures/x86
20:17:23 <jsbackus> Mailing list is referenced on the wiki.
20:18:01 <smooge> #fedora-x86 is the IRC channel dedicated to x86
20:18:06 <alexpl> plus, managing a number of systems is a lot easier when they are all on the same distro, e.g. a local mirror makes a lot of sense and we also carry tools that work well even on small scale deployments
20:18:30 <alexpl> so these are my selfish motives
20:18:45 <jsbackus> There is a lot of focus on containers and related technologies (flatpak, etc), but containers are nothing without the other pieces - servers, etc. And those run just fine on i686.
20:19:58 <asunz> Well, I'm adding my name as soon as I get approved in a group so I can login to the wiki. Or if anyone wants to add it that's fine by me.
20:20:14 <asunz> I'm already following the mail list anyways
20:20:35 <jsbackus> Great!
20:20:54 <smooge> asunz, pm me the info you want on the wiki
20:21:47 <alexpl> Do we get any homework for the next meeting?
20:21:53 <jsbackus> Alright, I'll start working on a proposal to FESCo in prep for Friday.
20:22:13 <jsbackus> Good question. We do need someone to scan bugzilla looking for issues with i686.
20:22:31 <jsbackus> We should maintain a list. I suppose the wiki is as good a place as any.
20:23:37 <athos> maybe a BZ tracker bug would be more consistent for that?
20:23:46 <jsbackus> We should also take a look at the latest F27 composes to see if they boot.
20:24:12 <alexpl> Should we also be checking desktop projects' roadmaps or getting in touch with them in the meantime, or is that for later?
20:24:12 <jsbackus> yes, good point. I believe we co-opted one at one point. Might make sense to make a new one?
20:24:26 <jsbackus> No, I think that is a good idea to do now.
20:24:50 <jsbackus> Especially LXDE, XFCE, and related.
20:25:01 <jsbackus> Might be good to add Enlightenment, too.
20:25:11 <jsbackus> alexpl, would you care to do that?
20:25:21 <alexpl> Yes, I will
20:25:34 <jsbackus> Thanks!
20:26:31 <alexpl> Just the desktops we carry though, right?
20:26:52 <jsbackus> athos, would you like to take a look at either using the current BZ tracker bug or setting up a BZ tracker bug? I think the original is mentioned in the mailing list. You'd want to check the archives.
20:27:33 <jsbackus> alexpl, Yeah, let's stick with what is currently in Fedora. If we need to add a new one so that we have an option, we'll deal with it when we come to it.
20:27:38 <athos> ok, jsbackus
20:27:55 <jsbackus> Great! Thanks!
20:29:11 <smooge> ok jsbackus I need to go focus on another fire. You can end the meeting yourself or ping me to do so later
20:29:17 <alexpl> Shall we reschedule now, or through the mailing list?
20:29:23 <jsbackus> Alright, I'd better run. Let's use the e-mail list for the time being. We'll try to work out another meeting.
20:29:30 <jsbackus> thanks smooge!
20:30:18 <jsbackus> argh. meant we'll try to work out another meeting later. They're hard for me to arrange and I don't want things to go too long without talking
20:30:54 <nb> hi
20:30:56 <jsbackus> Sound good?
20:31:00 * nb is interested in Fedora on x86
20:31:01 <jsbackus> hi
20:31:15 <jsbackus> great! Unfortunately, we're just finishing up.
20:31:33 <jsbackus> We'd love to have you join, though
20:31:44 <alexpl> sure jsbackus, let's schedule one when we have something to report
20:32:08 <jsbackus> sounds like a plan, alexpl.
20:32:27 <jsbackus> nb, have you joined the mailing list?
20:32:57 <asunz> Which is https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/
20:33:15 <jsbackus> yep!
20:33:34 * nb will go subscribe
20:34:34 <jsbackus> nb, great! might I ask, do you have a need for PAE support or do you have hardware that doesn't have SSE2 support?
20:34:59 * nb doesn't need PAE
20:35:05 <nb> I think my hardware supports SSE2
20:35:42 <jsbackus> Good to know.
20:36:41 <jsbackus> nb, would you be willing to help us test install images and to interface with project upstreams?
20:36:50 <nb> sure
20:37:09 <jsbackus> great! We definitely need the help.
20:37:48 <jsbackus> Unfortunately, I do have to run. Thanks again for everyone attending!
20:38:03 <alexpl> great talking to you all
20:38:06 <alexpl> bye!
20:38:08 <jsbackus> I'll send out the meeting minutes once I figure out how to get them out of meetbot.
20:38:24 <smooge> #endmeeting