18:00:19 #startmeeting FESCO (2022-03-15)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f0e5009e37f1c570d2bcffca2107e9d250de840d) 18:00:19 Meeting started Tue Mar 15 18:00:19 2022 UTC. 18:00:19 This meeting is logged and archived in a public location. 18:00:19 The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:19 The meeting name has been set to 'fesco_(2022-03-15)..._(full_message_at_https://libera.ems.host/_matrix/media/r0/download/libera.chat/f0e5009e37f1c570d2bcffca2107e9d250de840d)' 18:00:23 I'm in WA and I haven't really heard it discussed 18:00:34 .hello 18:00:34 salimma: (hello ) -- Alias for "hellomynameis $1". 18:00:37 morning 18:00:37 https://www.transportation.gov/regulations/procedure-moving-area-one-time-zone-another 18:00:40 .hi 18:00:41 salimma: salimma 'Michel Alexandre Salim' 18:00:43 .hello2 18:00:44 so there you go: open a ticket 18:00:44 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 18:00:47 .hello2 18:00:47 dcantrell: dcantrell 'David Cantrell' 18:01:17 Grr, it didn't like my multiline paste. 18:01:22 #meetingname fesco 18:01:22 The meeting name has been set to 'fesco' 18:01:26 #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 18:01:26 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek 18:01:30 #topic init process 18:01:31 .hi 18:01:32 sgallagh: sgallagh 'Stephen Gallagher' 18:01:41 .hello ngompa 18:01:42 Eighth_Doctor: ngompa 'Neal Gompa' 18:02:10 .hi 18:02:11 dustymabe: dustymabe 'Dusty Mabe' 18:02:44 .hi 18:02:45 trodgers: trodgers 'Thomas Rodgers' 18:03:02 .hello churchyard 18:03:03 mhroncok: churchyard 'Miro Hrončok' 18:03:12 OK, we have quorum 18:03:22 .hello tstellar 18:03:23 tstellar: tstellar 'Tom Stellard' 18:04:00 #2772 Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards 18:04:03 .fesco 2772 18:04:04 sgallagh: Issue #2772: Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards - fesco - Pagure.io - https://pagure.io/fesco/issue/2772 18:04:16 #topic #2772 Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards 18:04:26 .fesco 2772 18:04:27 sgallagh: Issue #2772: Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards - fesco - Pagure.io - https://pagure.io/fesco/issue/2772 18:04:57 I think this needs to be more exacting what it's affecting... (as others mentioned on list) 18:04:58 I put this on the agenda since it's received multiple negative votes. 18:05:29 Alternately, we need to finally hammer the last nail into i686 18:05:43 I'm thinking a wooden nail, right in its withered heart. 18:05:45 I happen to have a meeting with jvanek tmrw 18:05:53 about a different java thing 18:05:57 will ask them about this 18:06:26 sadly, due to wine I think we cannot kill i686... unless we decide wine users aren't that important I guess... 18:06:50 Please don't do that 18:06:50 Or we accept that realistically wine users are PROBABLY going to prefer the Flatpak version anyway. 18:07:03 Why? 18:07:12 FWIW we (libstdc++) use wine to test mingw goo 18:07:19 so please don't do that 18:07:27 the devel thread about the other change makes me think we are far from ready on dropping 32bit wine 18:07:29 Yes, I think there are many reasons not to drop i686 yet. 18:07:42 Arguably, most wine users don't want to use Flatpak 18:07:43 * sgallagh sighs 18:07:52 can the wine flatpak even run 32bit stuff? 18:07:58 I think we actually need to figure out how to drop most of our i686 18:08:07 As I commented on https://pagure.io/fesco/issue/2772 If we aren't going to drop i686 altogether, then we really need to documenent what use cases are supported for i686. 18:08:19 but pulling the rug out of a stack is not the way 18:08:20 maybe we could come up with a minimal package set for just the use cases we care about for i686? 18:08:33 I am 90% sure that we were debating when to sunset i686 when I originally joined FESCo. 18:08:40 Which was 2009 18:08:48 tstellar: +1 18:09:10 That goes back to my suggestion on list about adding a flag file to enable i686 in the arch set for packages 18:09:31 thats implementation, we need to figure out what end goal is. 18:09:33 That's what openSUSE does today and I'd rather do that 18:10:08 I think most of us already have the goal in mind 18:10:24 So all we have to debate is implementation 18:10:39 Conan Kudo: I think it's sensible for us to spell out that goal explicitly 18:10:41 I am afraid taht if we go into the i686 thing here today... this meeting wil last forever and we will not figure it out anyway 18:10:47 well, I think the goal is bigger than most of us think it is. I'd say wine and steam, some would say just wine, a lot of users likely have other use cases we don't know about. 18:11:03 let's try to focus on the java thing? 18:11:13 also there a bunch of allowlisted multilib stuff we have added into pungi over the years. would we drop all that? 18:11:41 FWIW, yes there are flatpaks of wine and steam that will run on systems with no glibc.i686 on my system 18:12:10 * nirik only sees x86_64 wine on flathub, but ok. 18:12:23 So… returning to java: can we drop 32bit java and libreoffice? 18:12:40 * and octave 18:12:53 i686 liberoffice right? 18:12:57 I think we might 18:13:02 might be able 18:13:13 but we need to figure it out before we actually attempt it 18:13:22 or even drop java support on it, but keep building for i686? 18:13:28 If we drop libreoffice and octave, are there important use cases for 32bit java remaining? 18:13:38 traverse the recursion, see where it goes to far and needs to be stopped (e.g. by conditionalizing some java stuff) 18:14:13 It's too bad we can't thunk 32 bit to 64 bit libraries... 18:14:20 e.g. the page now only lists binary packages that require java 18:14:35 that are not noarch 18:14:44 it doe snot list noarch packages that require java 18:14:58 "thunk"? 18:15:08 it does not list components that buildrequire java 18:15:15 Translate across ISAs 18:15:21 it does not list packages that (build)require the above 18:16:20 Yes, we should start with a proper list of R and BR packages. 18:16:23 if we get that list (graph), we might now if we can drop 32bit java 18:16:28 *know 18:16:37 so, this change would just drop javai i686 and leave all those maintainers to decide if they build without java on i686 or just exclude i686? 18:16:47 and I am confident that if enogh nergy is put into cutting some dead branches, it's quite realistically possible 18:16:56 Stephen Gallagher: or more accurately, translate API calls across arch ABIs 18:17:00 *enough energy 18:17:20 however, I am not confident the change owners have the resources to commit to do this 18:17:35 e.g. something requests libcurl API signature from a 32-bit libcurl and it's transparently redirected and handled by 64-bit libcurl 18:17:39 but maybe I am underestimating them :) 18:18:06 Also, the list in the Change page lists recursive dependencies which is mostly useless. 18:18:11 .hello mohanboddu 18:18:12 mboddu: mohanboddu 'Mohan Boddu' 18:18:17 * mboddu is late, sorry 18:18:25 Stephen Gallagher: https://en.wikipedia.org/wiki/Thunk#Interoperability 18:18:36 Because we'll be dropping support for java on the 32bit arches, not dropping packages altogether, in many cases. 18:18:45 i think the best option here is to wait for the change owners to respond to the feedback in ticket 18:18:54 mhroncok: +1 18:19:36 +1 18:19:55 +1 18:20:00 Good enough, I guess. 18:20:40 +1 18:21:02 +1 18:21:15 #agreed FESCo awaits more feedback from the Change owners (+7, 0, -0) 18:21:50 It's not on the agenda, but I'd like to add a general i686 support topic (to be capped at ten minutes) 18:22:11 #topic Sunsetting i686 in Fedora 18:23:00 I'd like to raise the topic on Devel about picking a forthcoming Fedora release in which we shut off i686 completely. I'd like to see what the general community's view on it would be. 18:23:26 Essentially a straw-poll consisting of Fedoras 37-50 or "Never". 18:23:27 well, I already suggested it and there was definitely some folks that don't want that to happen 18:23:46 Realistically, it will end someday. 18:24:00 I'd like to get a general sense of when people think its time will have passed. 18:25:09 can we take bets? 18:25:16 sgallagh: This would be a good opportunity to collect the relevant use cases from users too. 18:25:32 A good point. 18:25:40 sgallagh: I think we shouldn't try to set a sunset date, but instead cut the level of support down in degrees. E.g. it seems likely that we'll start dropping leaf packages in F36–37, and java, probably rust and other languages. In a few releases we'll be left with some small core of support that can remain supported for a long time with minimal effort. 18:25:41 As long as we support multilib on packages that are needed, I am okay with killing i686 18:25:45 I'm not sure devel list would be a very good place to sample this... 18:26:01 I think that " collecting the relevant use cases " is far more important than guessing what will happen in 2027 18:26:25 after all, the humans might EOL by that time, as it seems 18:26:39 Well, that's bleak. 18:26:39 Like we had python27 available for a few years after it became obsolete, in a very mimal form. 18:26:51 I think framing it as "What do you use i686 for?" vs "When an we drop i686?" will lead to a more productive discussion. 18:26:57 *can we 18:27:03 hey, I'm here, but I'm distracted. 18:27:06 zbyszek: yeah, but doing it all at once saves us a lot of spec file churn and maintainer work... 18:27:58 * mhroncok likes the extra koji target approach, as long as we figure out the minimal package set somehow 18:28:08 BTW: I'm open to doing it all at once. But I'll not be working on that change. My proposal deliberately has very limited scope and impact 18:28:12 Yeah, but there are important use cases. So if we frame it in binary as "drop now" or "continue", the answer will either be "continue" or we'll make many users unhappy. 18:28:28 Fabio Valentini: yes, we are now discussing the general i686 future in Fedora 18:29:01 If things go according to plan, in a few releases we can pull the plug with minimal disruption. 18:29:02 OK, I promised to cap this at ten minutes, and it has been eight already. 18:29:26 Let's shelve this for the moment and come back to it another time. 18:29:41 next steps: 1) collecting the use cases 2) trying to figure out what is the resolved package set we would need to keep 18:29:46 I was mostly curious if we would even have consensus among OURSELVES about the desire/need to retire i686. 18:29:49 We clearly do not. 18:30:13 then, based on size of (2), we can see if opt-in or opt-out makes more sense 18:30:36 dropping i686 in Fedora 40 (or similar) does not sond realisitc to me 18:30:46 *sound 18:31:01 perhaps 42 :) 18:31:13 perhaps 86 18:31:19 mhroncok: will you start a thread on fedora-devel about the usecases? 18:31:32 I think we are going to be forced to make a decision at some point as more packages run up against the 4GB limit when building. 18:31:36 I want to be rid of it before I retire. 18:31:45 I want that as part of my legacy, dammit. 18:31:51 Please make it clear that this thread then has nothing to do with my proposed change .... 18:31:51 tstellar: yes. like, does nodejs build on i686 now? 18:31:58 * dcantrell looks 18:32:05 dcantrell: It does... barely. 18:32:13 I'm actually surprised 18:32:23 I've had to play some tricks with the linker to get it to work, but it does. 18:32:28 10 minutes have passed 18:32:35 Right, let's move on. 18:32:53 #topic Next week's chair 18:32:57 just to answer zbyszek -- I'D rtaher not 18:33:14 I can chair 18:35:23 I don't mind starting the devel list thread about i686 18:35:35 dcantrell++ 18:35:35 mhroncok: Karma for dcantrell changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:36:12 #action mhroncok will chair the next meeting 18:36:15 #topic Open Floor 18:36:26 Anything for Open Floor? 18:36:44 time of this meeting 18:36:47 after DST changes 18:37:03 I'd rather move it in UTC, so it matches the previous time 18:37:11 *the previous local time 18:37:35 mhroncok: +1 18:37:41 (so I'd rather it effectively does not change in northern hemisphere countries that do observe DST) 18:38:00 mhroncok: Tracking *which* DST, then? 18:38:09 either US or EU 18:38:13 yup ^^ - madness ensues 18:38:17 both is fine, I can survive the time in between 18:38:21 so from 18UTC to 17UTC? 18:38:24 in FCOS we follow UTC just for this reason 18:38:34 US 18:38:44 we track US DST 18:39:01 (currently) 18:39:03 I'm fine either way, so count me as +/- 0 18:39:15 now it is 18:00 UTC 18:39:24 I propose it starts 17:00 UTC 18:39:26 if we didn't, I'd have to permanently skip this meeting going forward :/ 18:39:27 fesco has done it various ways over the years. 18:39:46 and after next elections we likely will change it again anyhow. 18:39:51 most likely 18:40:02 we got lucky this time around where the date and time was easy 18:40:08 it'll probably be difficult post-election again :) 18:40:10 Conan Kudo: when does DST start for you? what date? 18:40:11 we should use Swatch Internet Time 18:40:20 it started on Sunday 18:40:21 it already has in the US 18:40:25 ok 18:40:26 I'm in US/Eastern 18:40:30 dcantrell: ha. 18:40:30 US is two weeks early 18:40:35 Conan Kudo: how are you ehre then? :D 18:40:40 *here 18:40:46 are we here? 18:40:52 you don't want to know :D 18:41:00 as it is, I mostly wasn't here 18:41:05 all of us are just in Conan Kudo's imagination 18:41:12 anyway, my proposal is: We move the start to 17:00 UTC starting next meeting 18:41:24 michel: I don't know if I should feel good or bad about that 18:41:27 * sgallagh is fine either way. 18:41:27 sure, +1 18:41:29 Eighth_Doctor: is zodbot masquerading as a human 18:41:35 the US's big energy saving policy change was to shorten standard time by two weeks 18:41:45 it was still stupid 18:41:49 trodgers: isn't it 4 weeks? I think ours end later too 18:41:56 Yeah 17:00 UTC is better 18:41:58 since the beginning of snivilisation, no one has understood time 18:41:58 * michel agrees it's totally stupid 18:41:59 Conan Kudo: Definitely bad. Anyone that could imagine *me* is clearly unsuited to life outside of an asylum. 18:41:59 yeah everything is shifted a bit 18:42:12 😆 18:42:17 thought it was one week at each end, I could be misremembering, time is hard 18:42:25 Stephen Gallagher: there are two types of people. Those who know they're insane and those who don't 18:42:28 UTC time isn't hard :) 18:42:41 I count at least 6 people who can have it either way or explitly prefer 17:00 UTC 18:43:13 #agree FESCo meeting is at 17:00 UTC from now on 18:43:28 umm 18:43:28 #action mhroncok to update the wiki 18:43:35 #action somebody to update fedocal 18:43:43 lol 18:43:47 i feel like what people wanted was it to follow eastern time 18:43:58 yeah, that's I think what we were saying 18:44:00 that doesn'T matter 18:44:07 yes it does 18:44:15 otherwise you'll be changing it twice a year 18:44:21 no, we will have a new vote about time slot before dst ends 18:44:33 why would you put yourself through that? 18:44:49 becouse we love pain 18:45:00 * Eighth_Doctor nods and cries 18:45:02 masochismisreal 18:45:11 :) 18:45:26 Fedora KDE SIG meetings are set to US/Eastern to make my life easier :D 18:45:40 Workstation WG meetings are similarly so (though not just for me :P) 18:45:41 the thing is, if we follow us dst, we will need to define the time of the meting in non-utc and that is hard for me :D 18:46:38 I'll handle updating the fedocal meeting 18:46:42 thanks 18:46:53 We'll go back to America/NYC I suppose 18:47:05 * nirik already updated it, but ok 18:47:09 :D 18:47:16 we don't have to solve that here 18:47:20 overachiever 18:47:28 OK, you win, nirik 18:47:32 the time of the next meeting was the only thing thta mattered 18:47:45 Anything else, or can we end the meeting? 18:47:54 as for what timezone to follow, feel free to have and async bikeshedding party :D 18:48:11 OK, what time should we scheduled the party? 18:48:12 * sgallagh runs 18:48:28 lol 18:48:58 GMT-3.5 18:49:11 OK, closing out the meeting in 120s 18:50:35 at least duration are zoneless 18:50:38 *is 18:52:17 mhroncok: no, that's actually incorrect 18:52:45 #endmeeting