15:00:16 <dcantrell> #startmeeting FESCO (2020-02-17)
15:00:16 <zodbot> Meeting started Mon Feb 17 15:00:16 2020 UTC.
15:00:16 <zodbot> This meeting is logged and archived in a public location.
15:00:16 <zodbot> The chair is dcantrell. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:16 <zodbot> The meeting name has been set to 'fesco_(2020-02-17)'
15:00:16 <dcantrell> #meetingname fesco
15:00:16 <dcantrell> #chair dcantrel
15:00:16 <dcantrell> #topic init process
15:00:16 <zodbot> The meeting name has been set to 'fesco'
15:00:16 <zodbot> Current chairs: dcantrel dcantrell
15:00:24 <dcantrell> .hello dcantrel
15:00:25 <zodbot> dcantrell: dcantrel 'David Cantrell' <dcantrell@redhat.com>
15:00:29 <bcotton> .hello2
15:00:30 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:00:41 <contyk> .hello psabata
15:00:42 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:09 <nirik> morning
15:01:36 <bookwar> .hello2
15:01:36 <dcantrell> hi everyone
15:01:37 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:40 * pwhalen is here
15:01:47 <pwhalen> good morning
15:02:12 <zbyszek> .hello2
15:02:13 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:27 <dcantrell> ok, I count 5
15:02:39 <dcantrell> everyone ready?
15:02:48 <contyk> I'm not sure.
15:02:52 <contyk> Need more coffee.
15:03:01 * dcantrell has coffee on the desk now
15:03:03 * bcotton hands contyk a cup of coffee
15:03:05 <dcantrell> we'll go slowly
15:03:09 <bcotton> dcantrell: in a cup, i hope!
15:03:17 <dcantrell> OH NO, I MESSED UP!
15:03:44 <dcantrell> ok, so no questions on the followups.  fair amount of stuff announced and tickets closed
15:03:56 <decathorpe> I'm here too o/
15:03:57 <dcantrell> I've got two items for new business.  there is the maven one which I will mention in open floor
15:04:00 <dcantrell> hi!
15:04:06 <dcantrell> #topic #2333 mingw CVEs aren't getting fixed
15:04:10 <dcantrell> .fesco 2333
15:04:12 <zodbot> dcantrell: Issue #2333: mingw CVEs aren't getting fixed - fesco - Pagure.io - https://pagure.io/fesco/issue/2333
15:04:33 <decathorpe> dcantrell: you still need to add the present members as chairs
15:04:46 <dcantrell> ooops
15:04:53 <dcantrell> so many hashes
15:05:26 <dcantrell> #chair dcantrel
15:05:26 <zodbot> Current chairs: dcantrel dcantrell
15:05:43 <nirik> dcantrell: https://fedoraproject.org/wiki/FESCo_meeting_process has copy/paste for the meeting too. ;)
15:05:45 <dcantrell> what, do I just write out who's here?  there's nothing in the script for this
15:05:55 <dcantrell> I'm reading that now
15:06:02 <nirik> day of the meeting section
15:06:30 <zbyszek> just paste the whole list
15:06:49 <dcantrell> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrel
15:06:49 <zodbot> Current chairs: bookwar contyk dcantrel dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:07:03 <dcantrell> I see no other list to paste
15:07:10 <dcantrell> I pasted the rest of this stuff at 10am in the channel
15:07:13 <contyk> That's the one.
15:07:30 <dcantrell> alright, I thought I was supposed to reduce that to who was actually the chair for the meeting
15:07:33 <dcantrell> instructions unclear
15:08:09 <zbyszek> dcantrell: do you spell your irc nick with two "l"s always?
15:08:14 <dcantrell> yes
15:08:24 <dcantrell> because my actual last name is Cantrell
15:08:34 <zbyszek> I'll update the wiki page to that then
15:08:35 <contyk> You should change your name.
15:08:37 <dcantrell> Red Hat account username limitations forced it to 'dcantrel' when Iw as hired
15:08:43 <dcantrell> yeah, I thought about it
15:08:55 <dcantrell> *but* RH is actually changing my username to dcantrell next month
15:09:00 <dcantrell> so I fully expect everything to break
15:09:04 <bcotton> contyk++
15:09:08 <ignatenkobrain> .hello2
15:09:09 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:09:12 <ignatenkobrain> sorry for being late
15:09:13 <dcantrell> anyways, shall we move on or have I forgotten something else totally and completely obvious?
15:09:31 <zbyszek> I think we're on the first bug
15:09:39 <dcantrell> #topic #2333 mingw CVEs aren't getting fixed
15:09:42 <dcantrell> .fesco 2333
15:09:43 <zodbot> dcantrell: Issue #2333: mingw CVEs aren't getting fixed - fesco - Pagure.io - https://pagure.io/fesco/issue/2333
15:10:00 <dcantrell> I put this on the agenda because I wanted to make sure it's proceeding as we all think it should.
15:10:10 <dcantrell> is there any action needed from us on it
15:10:30 <zbyszek> I don't have much of an opinion except being a bit sad to see so many packages go.
15:10:41 <nirik> I think we can close this...
15:11:04 <nirik> I don't have a easy way to verify it off hand...someone could construct a bugzilla query
15:11:44 <nirik> oh duh, queries in the initial ticket content
15:11:56 <dcantrell> just saw that too
15:12:19 <nirik> there's now 154 bugs
15:12:24 <nirik> was 459
15:12:40 <dcantrell> well, 154 < 459
15:13:03 <nirik> progress. I don't know if there's more we want to do tho... urge the maintainers to try and get things updated...
15:13:14 <dcantrell> I think so
15:13:43 <dcantrell> I propose to vote to close this one as accepted
15:13:56 <zbyszek> We could make a push to move the sub[D[D[D[C[C[D[D[C[C[D[D[C[C[D[C[C
15:14:11 <zbyszek> sorry, to move to subpackages
15:14:40 <zbyszek> I agree with the opionion that the split into separate srpms has outlived its usefulness.
15:14:52 * nirik recalls this was suggested and rejected when they were first being added. I don't recall the reasons tho
15:15:14 <dcantrell> theoretically it reduces churn since they are all builds of separate upstreams
15:15:25 <dcantrell> otherwise you're maintaining a huge monolith package
15:16:03 <nirik> but also if they break they break the main/linux version... which maintainers will not be very happy about.
15:16:37 <zbyszek> dcantrell: the idea is to simply build a mingw subpackage from the respective package of the project, not to put various mingw packages together.
15:16:46 <zbyszek> At least if I'm not totally confused.
15:16:49 * nirik thinks thats a larger question that someone needs to make a proposal/change for and get discussed.
15:16:51 <dcantrell> right
15:17:01 <dcantrell> I'm rereading what I wrote and it doesn't parse right
15:17:06 <dcantrell> I blame lack of coffee
15:17:27 <zbyszek> nirik: see https://pagure.io/fesco/issue/2333#comment-626175, it seems that the worries were not realized.
15:17:36 <dcantrell> so mingw subpackages off regular packages does mean you're asking those package maintainers to also be on the mingw bandwagon and have at least a passive understanding of that stuff, which they may not
15:17:50 <dcantrell> oh well there we go
15:18:11 <dcantrell> you know, this would be nice as an RPM spec file macro or set of macros that maintainers could just carry
15:18:33 <dcantrell> (don't know if the mingw stuff is already a macro or not)
15:18:35 <nirik> zbyszek: which worries?
15:19:02 <zbyszek> nirik: > mingw packages don't carry custom non-upstream patches, and are not significantly more likely to break during build than native already are
15:19:11 <dcantrell> package maintainers were worried they would also have to be mingw environment experts
15:19:14 <zbyszek> >  We picked separate mingw src.rpms originally because we were indeed afraid that their would be many mingw specific maint problems needing custom patching, or frequently breaking builds. In practice that turned out to not be the case, and the maint problems we face are actually caused by the use of separate src.rpms, not solve by it.
15:19:20 <dcantrell> and it is significantly divergent from upstream
15:19:21 <nirik> anyhow, I am in favor of closing this for now, asking them to try and fix things and if there's a proposal for moving things into main packages, make that a change and get it discussed in the normal process of things.
15:19:28 <kalev> re merged spec files, I am personally not interested in fixing any mingw build issues when we need to get new GNOME into Fedora at the last minute
15:19:41 <nirik> zbyszek: ah, thanks.
15:19:56 <dcantrell> kalev: fair point
15:20:12 <decathorpe> kalev: I think there's some room for compromise there. not 100% of packages need to be merged together.
15:20:15 <dcantrell> nirik: ok, you want to take that action then with a final comment in the ticket?
15:20:18 <zbyszek> nirik: "in favor of closing this for now" - ack
15:20:21 <dcantrell> or should we all vote on that?
15:20:51 <nirik> If folks agree, happy to note that in the ticket...
15:21:05 <dcantrell> all in favor of nirik closing the ticket and adding final comment
15:21:08 <dcantrell> +1
15:21:11 <zbyszek> +1
15:21:25 <nirik> +1 myself. ;)
15:21:37 <decathorpe> +1
15:21:43 <contyk> +1
15:22:05 <bookwar> +1
15:22:21 <dcantrell> ignatenkobrain?
15:22:52 <dcantrell> #agree APPROVED (+6, 0, -0)
15:22:57 <dcantrell> alright, moving on
15:23:05 <dcantrell> #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) - https://fedoraproject.org/wiki/\
15:23:09 <dcantrell> Changes/ARM_Release_Criteria_Changes
15:23:13 <dcantrell> yikes
15:23:16 <dcantrell> copy and paste madness
15:23:27 <decathorpe> dcantrell: take it slow ;)
15:23:34 <dcantrell> #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) - https://fedoraproject.org/wiki/Changes/ARM_Release_Criteria_Changes
15:23:40 <dcantrell> .fesco 2339
15:23:42 <zodbot> dcantrell: Issue #2339: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) - fesco - Pagure.io - https://pagure.io/fesco/issue/2339
15:23:50 <dcantrell> decathorpe: noted  :)
15:25:15 <nirik> so I didn't see any objections on the list to this...
15:25:17 <dcantrell> so I don't really have any comments to add on this one
15:25:18 <contyk> So I wouldn't even require a Change for changes in release criteria.
15:25:30 <contyk> But since there is one now, +1.
15:25:52 <nirik> it was requested in this case since it was so late I think... and only arm/qa was involved in the early discussion.
15:25:55 <dcantrell> pwhalen: have anything to add on this one?
15:25:58 <nirik> anyhow, yeah, +1
15:26:08 <bookwar> there are no objections but there is no commitment from workstation group either
15:26:08 <ignatenkobrain> +1
15:26:10 <contyk> We sometimes change criteria during the go/no-go meeting :)
15:26:35 <pwhalen> dcantrell, nothing to add , but here for any questions or concerns
15:26:39 <decathorpe> +1
15:26:47 * zbyszek is still +1
15:26:58 <dcantrell> +1
15:28:45 <dcantrell> pwhalen: what are your thoughts on bookwar's comment in the ticket?  the most recent comment
15:28:50 <bookwar> I am concerned that workstation WG explicitly states that they don't care about ARM
15:29:13 <bookwar> given by this, whatever we define as release blocking criteria has almost no impact
15:29:54 <pbrobinson> bookwar: the arm side of things is fine, we have people at Arm itself that are engaged here
15:30:21 <pbrobinson> with things like the $200 pine book pro there's a lot of interest in general
15:30:33 <bcotton> bookwar: on the other hand, if we don't release because of blocker bugs, then the WG has to care about arm :-)
15:30:34 <pwhalen> we should be able to assist with any issues as they arise.
15:30:42 <dcantrell> that's fair, but without the Workstation WG buy in, does this have effect?
15:30:58 <bookwar> pbrobinson: sure, the arm part is ok, but if Workstation SIG decides for example to change the list of default apps in the spin or default settings, without checking the arm support for them, how you are going to be informed?
15:31:03 <dcantrell> without the Workstation WG ack on this proposal, it really just becomes "drop Xfce on 32-bit ARM from release blocking"
15:31:05 <pbrobinson> and we started build aarch64 workstation back around F-23 and have never had an issue with it that wasn't reproducible on x86, I feel this change is mostly just process
15:31:32 <pbrobinson> bookwar: we have 100% of stuff built, for ages, I don't see that is an issue at all
15:32:01 <pbrobinson> and the build for all architectures is already a policy for the project as a whole anyway
15:32:59 <dcantrell> it sounds then to me that the arm group will handle any workstation issues that become blocking on arm
15:33:50 <pbrobinson> most of the arm specific issues are likely to be things like mesa drivers and we have engagement there
15:34:13 <pbrobinson> we've been supporting it already on this arch for 8+ releases without any major issues
15:34:36 <dcantrell> and I see in the ticket comments to that effect as well
15:34:39 <bookwar> ok, if ARM group is confident, i don't have objections really
15:34:39 <dcantrell> I'm still a +1
15:35:03 <bookwar> +1 from me
15:35:04 <dcantrell> everyone else already voted +1, that leaves bookwar outstanding
15:35:08 <dcantrell> whoops, not now  :)
15:35:33 <dcantrell> #agree APPROVED (+7, 0, -0)
15:35:52 <dcantrell> #topic Next week's chair
15:36:14 <dcantrell> any volunteers?
15:36:54 <contyk> No one?
15:36:58 <dcantrell> wow
15:37:01 <contyk> I suppose it could be me again.
15:37:12 <contyk> I'll be around at least.
15:37:16 <decathorpe> I'm a second-level volunteer as well ;)
15:37:25 <zbyszek> I can take it the week after that.
15:37:35 <dcantrell> ok, sounds good
15:37:41 <dcantrell> #action contyk will chair next meeting
15:38:04 <dcantrell> #topic Open Floor
15:38:42 <dcantrell> so the only thing I wanted to ask about was 2341
15:38:46 <dcantrell> .fesco 2341
15:38:48 <zodbot> dcantrell: Issue #2341: maven and ant: sfl4j-jdk14 filtered - fesco - Pagure.io - https://pagure.io/fesco/issue/2341
15:39:00 <dcantrell> I didn't put it on the agenda because the ticket was too new
15:39:12 <dcantrell> but we should all look at this one this week
15:39:48 <dcantrell> anyone have anything to add to this one now or shall we just take it to the ticket?
15:40:18 <decathorpe> I have nothing to add that I didn't already write 5 times at various places, so ...
15:40:40 <dcantrell> right  :)
15:41:09 <dcantrell> so I'm trying to think about this issue specifically and what the options are now and what, if any, policy we should carry in fedora now
15:41:10 <zbyszek> Sorry, I didn't have time to dig into this.
15:41:21 <dcantrell> no worries, it was posted late in the week
15:41:42 <bookwar> i see the update in the eclipse bug was made today
15:41:55 <dcantrell> please post comments in the ticket and proposals for how best to handle this and similar problems in fedora
15:42:33 * contyk nods
15:42:35 <cipherboy> bookwar: Miro had filed it against dnf, but they kicked it back to maven today, making it essentially a duplicate (or better behaved, as in this case it isn't a version difference).
15:43:56 <dcantrell> I don't even understand the last comment in https://bugzilla.redhat.com/show_bug.cgi?id=1800528
15:44:56 <cipherboy> However, the eclipse issue will go away if/when maven 3.6 becomes the default stream, because it no longer builds/filters glassfish-el. The slf4j-jdk14 issue
15:45:43 <cipherboy> dcantrell: There's two options: Mikolaj updates maven3.5 to quit filtering glassfish-el (what Jaroslav commented to the effect of), and/or maven3.6 becomes the default stream.
15:46:32 * pwhalen has to run, thanks all
15:46:38 <dcantrell> ugh, this is so needlessly complicated
15:46:41 <dcantrell> pwhalen: thank you!
15:46:49 <dcantrell> ok, I'll comment in the ticket
15:46:56 <dcantrell> anything else for the open floor?
15:47:05 <bookwar> cipherboy: do you have a dedicated bz for sfl4j-jdk14 ?
15:47:34 <bookwar> found it, sorry
15:47:40 <bookwar> https://bugzilla.redhat.com/show_bug.cgi?id=1801882
15:48:51 <bookwar> both bugs have comments from today, i think we need more time for this topic
15:48:57 <dcantrell> agreed
15:49:18 <zbyszek> >
15:49:21 <zbyszek> A much better long-term solution that I was working on is "module namespacing" - making maven module non-conflicting and parallel-installable with ursine packages by including module name and stream in all binary package names, provides, file paths etc.
15:49:37 <zbyszek> Heh, that's essentially compat packages done in a different way.
15:49:47 <bookwar> or scl
15:50:01 <zbyszek> (The quote is from Mikołaj in #1801882.)
15:50:26 <dcantrell> we have multiple ways to do what modularity is trying to do
15:50:47 <zbyszek> Compat packages much more than scl, because there's no content mangling, just package name mangling.
15:51:29 <cipherboy> zbyszek: That has been discussed since late last year (Oct? Nov?) and still is blocked. Just like Ursa {Major,Prime}.......
15:51:38 <decathorpe> I still don't get why there has to be a maven module. but well
15:52:21 <dcantrell> please add your comments to the ticket
15:52:22 <zbyszek> cipherboy: I'm not saying that this is a viable solution. I think it's a pie-in-the-sky thing.
15:53:21 <dcantrell> alright, nearing an hour here.  last call for open floor items
15:54:28 <dcantrell> ok, thanks everyone!  I hope you look forward to a future bumpy irc meeting chaired by me.  :)
15:54:50 <decathorpe> dcantrel++
15:55:01 <dcantrell> #endmeeting