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