15:00:12 #startmeeting FESCO (2019-09-30) 15:00:12 Meeting started Mon Sep 30 15:00:12 2019 UTC. 15:00:12 This meeting is logged and archived in a public location. 15:00:12 The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:12 The meeting name has been set to 'fesco_(2019-09-30)' 15:00:12 #meetingname fesco 15:00:12 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:12 The meeting name has been set to 'fesco' 15:00:12 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:12 #topic init process 15:00:15 .hello2 15:00:16 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:17 .hello2 15:00:19 sgallagh: sgallagh 'Stephen Gallagher' 15:00:20 .hello2 15:00:21 .hello2 15:00:22 jforbes: jforbes 'Justin M. Forbes' 15:00:25 otaylor: otaylor 'Owen Taylor' 15:00:38 .hello kevin 15:00:39 nirik: kevin 'Kevin Fenzi' 15:01:03 ignatenkobrain indicated that he could not attend today on account of newborn. 15:01:14 .hello2 15:01:15 bookwar1: Sorry, but you don't exist 15:01:20 wow 15:01:27 your nick doesn't match 15:01:31 .hello2 15:01:32 bookwar: bookwar 'Aleksandra Fedorova' 15:01:58 sgallagh: yes, but the message is fun ) 15:02:05 agreed :) 15:02:43 We have enough people to get started, though I was hoping mhroncok would be here for the second item on the agenda 15:03:08 hey, sorry for the delay 15:03:17 Perfect timing 15:03:22 #topic #2231 F32 System-Wide Change: Firewalld Default to nftables 15:03:23 .fesco 2231 15:03:24 sgallagh: Issue #2231: F32 System-Wide Change: Firewalld Default to nftables - fesco - Pagure.io - https://pagure.io/fesco/issue/2231 15:04:17 So mhroncok voted -1 because he feels this shouldn't land unless both CRI-O and Docker container ecosystems support it. 15:04:17 all I ask for is that the maintainer of "docker" is on board 15:04:53 The counter-argument is that we (Fedora) has little-to-no influence to do that for Docker 15:04:57 mhroncok: moby-engine? 15:05:01 I realize that docker is no longer considered cool 15:05:02 Considering that after 12 days there is no reply from @olem... I'd say they are either not onboard or MIA. 15:05:14 mhroncok: or do you mean official docker inc. builds? 15:05:21 mhroncok: It's not so much about "cool" as "Docker won't accept patches" 15:05:26 I mean Fedora users who do dnf install docker 15:05:58 are we OK if they dnf install docker and their container network doesn't work? 15:06:05 mhroncok: via https://download.docker.com/linux/fedora/docker-ce.repo ? 15:06:12 via fedora repos 15:06:15 i think we need to set a deadline for feedback from moby-engine maintainer, if there is no response - we approve the change, but then the impact on moby/docker should be mentioned in release notes 15:06:32 mhroncok: we don't have 'docker' in Fedora repos any more. We have moby-engine, but that's not strongly supported by anybody. 15:06:35 (To be clear, I'm on the fence here. I'm just stating the counter-arguments so we think them through) 15:07:20 Which is really the issue, it isn't strongly supported by anyone, and should we really let that hold back things which are? 15:07:24 I think at this point we have given a lot of time... 15:07:29 otaylor: dnf install docker still gives you something 15:07:34 so, I am +1 to approve and release note it. 15:07:41 Proposal: Approve contingent upon the Docker maintainer not objecting before our next meeting. If they do object, we hold another vote at next meeting. 15:08:15 so what is Fedora's docker story? 15:08:19 docker or moby? 15:08:27 is it "use Ubuntu"? 15:08:37 use podman 15:08:39 mhroncok: It really is "use podman" 15:08:43 while I relaize that docker and moby are different things, user's won't 15:08:44 sgallagh: who is "docker maintainer" - it's apparently dwalsh, who no longer cares about the old docker fork we have in fedora? 15:08:56 .fasinfo olem 15:08:57 sgallagh: User: olem, Name: Olivier Lemasle, email: o.lemasle@gmail.com, Creation: 2016-01-11, IRC Nick: None, Timezone: Europe/Paris, Locale: en, GPG key ID: E0809AA5, Status: active 15:09:00 sgallagh: Approved Groups: packager fedorabugs cla_done cla_fpca 15:09:05 otaylor: ^^ 15:09:43 is teh message "Fedora does no longer support docker/moby/whatever"? 15:09:49 mhroncok: Fedora's story is "use podman" and there's tons of docs about that. *mostly* it works quite well as a drop-in, though docker-compose is an issue. 15:09:57 Insofar as we have ever supported Docker, yes 15:10:28 * mhroncok if afraid that this change is going to bite us if "docker" is not on borad 15:10:29 I wonder if we could just Obsoletes: it and provide a symlink for the command name 15:10:47 sgallagh: if it works, we probably should 15:11:05 mhroncok: Should work at least 90% of the time 15:11:38 in podman? or moby? 15:11:42 I'd +1 the change if "the thing that provides the docker command and is installed when users install docker" is on board 15:12:03 BTW, how does moby-engine fare under cgroupsv2? 15:12:40 no idea 15:12:42 .bugzilla 1746355 15:12:55 mhroncok: that is: 15:12:55 What is the command do display a bug? 15:12:57 sgallagh: anyway, I think there is a strong support of this even if I -1 it 15:12:58 moby-engine-0:18.09.8-2.ce.git0dd43dd.fc31.x86_64 15:12:58 podman-docker-2:1.5.2-0.85.dev.git7875e00.fc32.noarch 15:13:03 sgallagh: we can wait for olem to respond, though I'd still be inclined to proceed if he said "I don't know of plans upstream, and I don't have resources to work on it downstream" 15:13:04 (at least in rawhide) 15:13:07 .bug 1746355 15:13:08 sgallagh: 1746355 – Error starting daemon: Devices cgroup isn't mounted - https://bugzilla.redhat.com/1746355 15:13:15 it seems they resolved the issue on debian by providing the iptables-legacy command which does networking for docker 15:13:44 theoretically it is doable for moby on fedora too 15:13:48 So it seems that moby-engine simply fails to start in F31 without additional work-arounds. 15:14:19 I'm coming down on the side of "We shouldn't hold this up waiting for the maintainer of a less-preferred stack to keep up" 15:14:25 sgallagh: personally, I think we can't let progress on fedora be constrained by a container system we have no control over, when we have a different system we advertise and we have strong development alignment with 15:14:36 * nirik nods. 15:14:40 When we approve this change, we effectively give moby-engine a deadline: adapt or die. 15:15:11 bookwar: do you have a link to the Debian patch? 15:15:20 well, or workaround by booting with a v1 command... 15:15:30 sgallagh: Given the article on Docker from CNBC on Friday, I am not sure they are putting resources to too much right now 15:16:30 zbyszek: actually more research needed, i was reading here: https://github.com/chaifeng/ufw-docker/issues/9 but the last comment makes it all confusing 15:16:35 Proposal: Change is approved. moby-engine must adapt by Beta Freeze or be dropped from Fedora. 15:17:01 sgallagh: -1 for the "dropped from Fedora" part. 15:17:26 zbyszek: Keeping it around and broken doesn't seem any better 15:17:34 I'd rather see us drop it and Obsoletes it with podman 15:17:50 It can come back to life later if they want 15:18:23 F32 beta does give a reasonable amount of time 15:18:41 sgallagh: -1 for obsoletes with podman, i think it is up to a moby-engine maintainer to decide what to do with the package 15:18:45 this sounds reasonable as long as podman provides both the package name and the command 15:18:52 I suppose... will any of us remember to do that at that point? :) 15:18:56 I'd leave that up to the maintainers. In particular, it is possible to use a container without any networking, and it might be a perfectly fine mode for some poeple. 15:19:04 As long as firewalld *can* still be configured to use iptables, it seems unreasonable to force moby-engine out of the distro 15:19:57 ok, I withdraw the restriction. 15:19:59 otaylor: +1, afaik one also can configure networking "manually" (don't know how) 15:20:06 I thought cgroups was the problem? or is it iptables for moby-engine? 15:20:14 nirik: both 15:20:20 Proposal: +1 for the change assuming the thing that get's installed with "dnf install docker" and run with "docker" works, whether it is podman or moby-engine 15:20:21 Proposal: Change is approved. The maintainers of moby-engine are responsible for how that turns out for them. 15:20:23 double fun 15:20:35 nirik: you can still use cgroups v1 if you want as well, it just isn't the default 15:20:41 right, I know. 15:20:42 sgallagh: +1 15:20:44 mhroncok: -1 15:20:46 sgallagh: +1 15:20:52 sgallagh: +1 15:21:14 Before I vote, a quick q: 15:21:40 the two proposals are mostly equivalent, except that mhroncok wants Provides:docker added to podman. What do podman maintainers think about this? 15:21:54 zbyszek: They're not, really. 15:22:00 it's not a full replacement tho. 15:22:13 mhroncok's proposal is essentially declaring a FESCo blocker on the "docker" command working. 15:22:20 Mine does not include that requirement. 15:22:21 yes 15:22:39 zbyszek: I think it's probably too far to make podman provide docker, it's not a drop-in - it's something that there's a strong attempt to make it easy to migrate too 15:22:47 if the docker command breaks on fedora, people will blame fedora, not moby engine 15:23:04 mhroncok: I am okay with that 15:23:05 podman-docker does provide it. 15:23:18 as well as moby-engine (alternatives I think?) 15:23:57 What I'd like to see if you 'dnf install docker' and run 'docker' and it doesn't start because of nftables or cgroupsv2, the error message has a link to a document that *both* tells you about th ewonders of podman, and also describes what you need to do get moby-engine working, if that's what you actually want. 15:24:25 podman is not equivalent to docker, there could be some broken expectations, so i don't think we should have podman installed instead of docker by default, it should be an informed decision 15:24:47 nirik: moby-engine and podman-docker provide the command, only moby-engne provides the name (rpm provide) 15:24:55 podman is part of the standard workstation install, podman-docker and moby-engine are not 15:25:14 Fedora is a volunteer community. If the moby-engine maintainers want the docker command to continue to work, they need to put in the effort to ensure it continues to work. 15:25:38 or at least tell us how long it might take to adjust... 15:25:40 If they don't do that, why are we treating it as more important than any other bitrotten package? 15:26:57 sgallagh: because of users there is a difference, it is like we should consider for example steam when we talk about workstation, even if it is outside of our reach 15:27:43 but generally i agree that we shouldn't block the change on that 15:28:26 bookwar: agreed on not blocking. I'm still not sure what is the best way to smooth the transition. 15:29:02 BTW you can still approve the change, even if I don't like it 15:29:21 mhroncok: You can reserve the right to say "I told you so", of course :) 15:29:29 :D 15:29:31 zbyszek: Which is exactly what sgallagh's proposal says, let the package maintainer decide the best way to smooth the transition 15:29:32 i think it is better to not have a docker package and to have a shiny doc which says "We recommend to switch to podman, but if you want to fool yourself use 'dnf install podman-docker'" :) 15:29:57 OK, +1 to sgallagh, -1 to mhroncok 15:30:21 also +1 to sgallagh 15:30:41 -1 to sgallagh 15:32:08 #agreed Change is approved. The maintainers of moby-engine are responsible for how that turns out for them. (+6, 0, -1) 15:32:12 I have to say that the docker's use of commit messages is a good example of how not to do it. 15:32:25 #topic #2236 Default Stream for Eclipse module 15:32:25 .fesco 2236 15:32:25 (a side note, I'll have to leave in ~1 hour. can join via my cellphone) 15:32:26 sgallagh: Issue #2236: Default Stream for Eclipse module - fesco - Pagure.io - https://pagure.io/fesco/issue/2236 15:32:36 There are only two topics remaining 15:32:40 * mbooth is here to answer questions for this one :-) 15:32:44 "only" ;) 15:33:11 As a quick update, we made some progress on Ursa Prime this week. 15:33:35 MBS builds now have default streams included automatically for their builds. 15:33:45 about the default stream, IIRC the reason we have the policy for fesco to approve default streams is that random modules don't override ursine packages and creating the java/stewardship sig problem 15:34:06 I'm working on pungi to generate the buildroot repos and hope to have that done tomorrow, with an eye to deploying next week. 15:34:20 mhroncok: Correct 15:34:42 Though we may be able to point to the new default stream policy we approved last week now 15:35:01 (That default stream contents all have to be treated as if they were non-modular) 15:35:02 mbooth: it seems that there are "eclipse-*" packages in regular repos that are not part of the module, according to my latest query (is the query correct?). what happens to them? 15:35:06 s/contents/artifacts/ 15:35:34 the list is at https://pagure.io/fesco/issue/2236#comment-601406 15:35:41 note we need non default for this case I think... 15:35:53 mhroncok: My plan is to retire them. Eclipse's Market Place CLient is the canonical place from which to install plugins these days. 15:36:16 nirik: What do you mena? 15:36:19 In general if a plugin is a part of my module it is because it benefits in some way from deep integration with Fedora 15:36:47 Anything can be installed from the eclipse market place 15:36:54 Anything *else* 15:36:56 * mhroncok would be much happier to hear the entire plan of this instead of getting the plan in parts. if only Fedora had a documented policy for doing changes 15:37:11 sgallagh: I might be mixing the rhel and fedora cases... but we want to add some few non default modules to the buildroot too right? like javapackage-tools ? 15:37:57 mbooth: so all the packages that are listed in there and are called "eclipse-" would go away, correct? 15:38:25 nirik: That's orthogonal to the question in this topic. 15:39:03 ok 15:39:04 mhroncok: Yeah 15:39:49 If someone wants to the maintain ursine eclipse plugins, they will be able to with ursa-major, AIUI 15:40:04 mbooth: s/Ursa Major/Ursa Prime/ 15:40:14 mbooth: let me update the list then 15:40:18 They're two different solutions to the modules-in-the-buildroot problem 15:40:38 sgallagh: Both to be deployed? 15:40:47 * mbooth is not quite in charge of all the details 15:40:49 No 15:40:57 usra major is being obsoleted by ursa prime 15:41:07 Ursa Major was basically v1 which was used for RHEL 8 but rejected by FESCo for FEdora 15:41:14 Ursa Prime is the replacement 15:41:23 Okay, I will update my vocabulary :-) 15:42:42 mbooth: will you be willing to create the "standalone swt" package (whatever the final name is)? 15:43:23 so 1)eclipse goes modular, 2) plugins are removed (except some basic which go modular)3) there is one non-modular package"swt" which will be built for fedora - is it right? 15:43:36 new query almost over... 15:44:15 zbyszek: Yes. It should be pretty easily doable 15:44:45 query stuck at eclipse-tests for some reason, here's what I got so far https://pagure.io/fesco/issue/2236#comment-601410 15:44:49 Based on this, I'm +1 here. 15:44:55 * nirik is also +1 15:45:06 zbyszek: FWIW I did the same thing for jgit package (of which there were downstream consumers, so I split it out into a special jgit library-only package) 15:45:20 Same will be done with SWT 15:45:46 query complete 15:46:09 eclipse-swt (solved), eclipse-equinox-osgi and eclipse-platform are needed 15:47:47 For packages that depend on eclipse-equinox-osgi there is a 99% chance that they just require the OSGi APIs, in which case they should be built against osgi-core and osgi-compendium packages instead. 15:48:01 We've moved many such packages already in stewardship-sig 15:48:31 Because in reality they should not depend on a particular OSGi implementation 15:49:30 So I can check that, it should just be a trivial change to build requires if so. 15:49:31 can we have an updated proposal abou what is actually happening, who's doing it, in what fedora version and what time frame? 15:50:01 because the ticket says "Default Stream for Eclipse module" where in fact this is a Fedora Change 15:50:12 I seems like this should really be a Change, with the description of the impact on all packages, users, etc. 15:51:05 I mean, the point of the ticket was to remove impact on users. 15:51:45 I don't see how this removes impact 15:51:47 Can we do things backwards and approve it now, but ask mbooth to file a Late Change Proposal? 15:51:53 sgallagh: -1 15:52:14 mhroncok: Because without the default stream, installing Eclipse breaks in unexpected ways for users. 15:52:23 I have explained that situation in the ticket 15:52:28 mysql-connector-java depends on hibernate, which depends on eclipse 15:52:49 mbooth: enabling the default streams removes this impact and creates more different impact 15:53:29 mbooth: it seems that eclipse is not "leaf enough" for this to be a self-contained change 15:53:39 "things are broken at place A" isn't a valid argument to break things at place B 15:54:03 mhroncok: How are things breaking in place B? 15:54:24 mhroncok: What exactly do you think is going to break when this goes to default? 15:55:18 mbooth, sgallagh: various packages that BR eclipse packages will break. 15:55:29 sgallagh: the nonmodular packages will either be retired - breaks dependent packages, or orphaned - creates the "java situation" once again, or wokr needs to be coordinated to make this smooth 15:56:09 This is dealt with by the introduction of swt package 15:56:14 I appreciate that mbooth is proposing solutions for the problems as they are discovered 15:56:20 I agree with mhroncok here: we should ask for a Change page that lists the steps needed (or nothing) for each dependent package, and who will do it. 15:56:29 mbooth: i think it is less about breaking right now, and more about coordinating, as it seems it goes beyond the eclipse set of packages 15:56:44 and we need to coordinate it better then via this one fesco ticket 15:57:02 this is why mhroncok proposes to use Fedora Change process for it 15:57:19 which is a process designed exactly for this kind of changes 15:57:23 bookwar: Coordinating with who? I have been defacto maintainer of all these packages for years 15:57:49 mbooth: like hibernate ? 15:57:59 Actually no-one maintains hibernate -- it should be retiref 15:58:07 odubaj maintains hibernate 15:58:33 and by doing this, you make it even harder than it is, I suppose 15:59:03 hibernate package has no commits in 3 years except for mass rebuild bumps. 15:59:07 this pretty sums up what I'm worried about: https://pagure.io/fesco/issue/2236#comment-600605 15:59:27 mbooth: can we ignore packages that have no commits in 3 years except for mass rebuild bumps? 15:59:42 I guess we can, when this is clearly descibed in a change proposal and approved 16:00:18 can we just decided that we don't care about the packages and that our contributors don't even need to know about this? 16:00:30 mhroncok: For the sake of determining if a package is maintained in Fedora? Yeah it's going to me that works on it ;-) 16:01:09 All bugz under https://apps.fedoraproject.org/packages/hibernate/bugs/all are except hibernate-to-disk, except the one about hibernate FTBFS in F31 ;) 16:01:25 *about hibernate-to-disk 16:01:48 I donẗ have anything more to say 16:01:59 I'm strongly against doing Fedora changes this way 16:02:23 Proposal: we ask for a Change to be filed using the normal process 16:02:51 zbyszek: +1 16:03:32 The "change" amounts to keeping things unchanged for users and contributors... 16:03:39 I'd like a Change to be filed, but I don't think it makes sense to block the fix to navigate the bureaucracy 16:04:12 teh change can be approved in a week if we determine it is urgent 16:04:16 mbooth: i think you said there will be list of orphaned packages, some are going to be split and some change the dependencies 16:04:26 mbooth: so it is a change 16:04:27 mbooth: no. It amounts to describing the necessary steps in a way that is more accessible to packagers and users than an IRC log. 16:04:51 but considering that f31 is over and f32 will be released in 6+ months, I don't see the urgency 16:05:05 or are we going to land this in F31 a week before final freeze? 16:06:06 mhroncok: mbooth has been working on landing this in F31 for months. If the only thing stopping him from being finished is FESCo... let him get on with it already 16:06:29 sgallagh: so this is indeed planned for f31? 16:06:29 Oh, that's for F31, this didn't really come up before. 16:06:43 where is this said at all? 16:07:23 I want the default stream for F31, yes. Sorry I should probably have filed a PR too to make that clear. Retirement of packages would happen in Rawhide only at this point 16:07:24 sgallagh: you knew about this for months? 16:08:17 mbooth: so what is the user experiance in Fedora 31 when they do dnf install eclipse-(whatnot) that is not part of the module? 16:08:39 this is all part of the change process BTW, descibing such things 16:08:50 mhroncok: If the module is enabled (by default or explicitly) it just works (i.e. no change) 16:09:15 And if it is not enabled: dependency issues I presume? 16:10:51 I think a change would have been nice if we had a time machine, but now we should just approve the default. I guess we could have a change, but it sounds like all the coordination is already done at this point. 16:11:15 nirik: it seems we are slowly figuring out the coordination in this meeting. 16:11:26 I see no coordination done apart from us discovering random issue as mbooth saying how it is posible to fix them 16:11:33 sgallagh: Yes, because some deps moved to maven/ant modules and retired in ursine distro 16:11:49 well, whats to be done? default stream... ? 16:12:00 which is what this ticket is about. 16:12:14 nirik: we still have a list of depepndent packages 16:12:16 there are two different issues here 16:12:44 in 31 we don't do anything with them, in f32 they get retired as packages normally do? 16:12:46 we want to redo the way we ship eclipse and we want to mass retire all eclipse packages and ship only some trough a module 16:12:46 bookwar: These dependent packages are not broken by adding a default stream 16:12:51 that si clearly a Fedora 32 change 16:13:00 the second problme is, eclipse in Fedora 31 is broken? 16:13:45 the first problem is already done tho...? and the second would be fixed by us just approving this. 16:13:45 ok, so for f31 we have a bug that eclipse can not be installed by 'dnf install eclipse', we want to solve it, no other packages are going to be affected 16:14:01 is the problem this? https://bugzilla.redhat.com/show_bug.cgi?id=1670518 16:14:40 nirik: already done how? 16:14:55 mhroncok: That is an unrelated problem 16:15:34 mhroncok: ok, I guess it's partly done... the moving to module, but not the retirements... but I am not sure we want a change for everything that moves to a module, do we? 16:15:37 so where is this problem described in the first place? 16:15:45 'dnf install eclipse' offers to install 52 packages in F31. Doesn't this work? 16:15:57 nirik: if the thing is this huge and clearly impacts a lot of other packages, yes, we do 16:16:10 I've just installed eclipse in 31 mock 16:16:46 Without the module stream enabled, you get this kind of error: https://paste.fedoraproject.org/paste/C6oa2uMXOU2JdUEQZ5ylfw 16:17:43 so, I guess we could say... disable/remove the module for f31 and do it all in f32 then... 16:18:08 mhroncok: mock has no modular repos enabled, so you bypassed the module 16:18:08 mhroncok: This is what prompted me to file this FESCo ticket: https://pagure.io/fedora-comps/pull-request/409 16:18:20 nirik: so removing the module fixes the problem? 16:18:45 Mock shouldn’t work unless there’s a non-modular version around somewhere. 16:18:49 mhroncok: I don't know for sure, but it sounds like if you got it to work in mock... 16:18:50 there is 16:19:04 sgallagh: that's my point here, there is nonmodular version 16:19:16 Sounds like it wasn’t retired properly then 16:19:26 it wasn't ever retired at all 16:19:39 mbooth: nonmodular version is older then the modular one? 16:19:46 bookwar: Yes 16:20:03 Because it's impossible to build Eclipse for non-modular in f31+ 16:20:10 which seems like a bit of a mess at this point 16:20:11 can we at least please have a ticket that describes this all? 16:20:18 So I can't fix bugs in non-modular 16:20:30 so we can go with old version, but then no chance to update it, no bugfixes and so 16:20:41 sounds like. 16:21:17 and then there is a modular version which will do the "shadowing" Miro mentioned, if we enable default stream for it 16:22:03 I need to leave, sorry 16:22:10 which is untested and it might be we get into troubles with nonmodular packages which depend on partially shadowed and partially old packages 16:22:13 Final freeze is in 9 days. I don't want to do such massive changes at this point. 16:22:21 bookwar: Not untested 16:22:27 We've been doing that for Node.js since F29 16:22:33 I'm with zbyszek on this 16:22:48 but we have to move forward, we can't easily go back... :( 16:22:55 IMO adding a default stream is not a "massive change" 16:23:09 It's also trivial to revert if it somehow breaks 16:23:22 So I still move that we go ahead and do it. 16:23:30 after f31 release, will we be able to add default streams for f31? 16:23:33 nirik: it is changing how packages are built and installed, with possible ripple effects throughout the distro. 16:23:34 I think we have not much choice on enabling the default here... since the alternative leaves us either with broken deps or unfixable packages 16:23:41 And it lessens the problem of people installing an eclipse that can't get updates for security or bugs 16:23:50 bookwar: Technically or by policy? 16:24:08 Eh, either way the answer is "yes" for FESCo. 16:24:17 sgallagh: everything is possible technically ) 16:24:25 zbyszek: what do you suggest? delay f31 and ask all the nonmodular java needed for eclipse is re-added as non modular packages? 16:24:40 I don't see much of a way around it at this point. I am +1 here 16:24:58 As before, I'm +1 16:25:00 nirik: Well, the version in F31 works, no? I.e. not doing anything is a valid option. 16:25:13 zbyszek: No: https://paste.fedoraproject.org/paste/C6oa2uMXOU2JdUEQZ5ylfw 16:25:18 zbyszek: and never to get updates? what if there's a nasty security bug? 16:25:40 * nirik is +1 16:25:41 nirik: +1 16:25:46 mbooth: That's a plugin, what about the bare minimum IDE? 16:26:08 mbooth: you would need to --disablerepo=\*modular\* 16:26:21 (to simulate dropping the module) 16:26:30 For the IDE alone, the error is more concise, obvs https://paste.fedoraproject.org/paste/vGWW80WQcPKCrp1yK8tvwQ 16:26:55 I am really not prepared to tell users to disable update repos :-/ 16:27:08 mbooth: no, you misunderstand. 16:27:24 Where does glassfish come from? 16:27:26 there's 3 options: a) do nothing, leave it as now. This gives broken deps as you see. 16:27:36 sgallagh: Eclipse module 16:27:41 ok 16:27:44 b) drop the modular eclipse in f31. This leaves the non modular one that you can't update 16:27:55 mbooth: how exactly is the error you are showing generated? You don't show the system version. 16:28:12 zbyszek: It is a F31 system 16:28:15 c) keep the modular one, make it default and retire the non modular stuff 16:28:45 nirik: retire only eclipse itself, one package? 16:28:46 mbooth: a f31 system where you have not enabled the eclipse module right? 16:28:47 nirik, mbooth: I just did 'dnf install eclipse' on a F31 system, and I don't see any broken deps. Please explain what I'm doing wrong. 16:29:07 d) Make the eclipse module a default stream and retire stuff only in F32 16:29:16 zbyszek: do you have the modular repos enabled? did you at some time 'dnf enable eclipse' 16:29:32 nirik: yes, no 16:29:43 (afaict, afaik, ttbomk) 16:30:01 $ rpm -q --whatprovides eclipse 16:30:01 eclipse-jdt-4.11-3.fc31.noarch 16:30:15 Yeah, I also don't get broken deps 16:30:43 I have several modules enabled, though. Notably ant 16:30:45 hum. 16:30:57 and maven 16:30:59 i get, on a clean fedora:31 container 16:31:00 So sorry, I'll vote -1 on doing this for F31. If both the breakage and the solutions is described clearly, I'd be willing to change that. 16:31:29 sudo dnf module --enabled list ? show eclipse enabled? 16:31:44 Not on mine 16:31:56 nirik: that gives an error 16:32:06 dnf module: error: the following arguments are required: subcmd, module-spec 16:32:14 `sudo dnf module list --enabled` 16:32:20 sorry, ordering 16:32:38 * nirik is puzzled. 16:33:29 mbooth: Can you run that command too? 16:33:34 https://paste.fedoraproject.org/paste/uWICYrVLx-nQCYRvrw2Ceg 16:34:06 bookwar: thats what I see too... 16:34:15 bookwar: Could you try enabling ant and maven and do it again. 16:34:17 https://paste.fedoraproject.org/paste/Jdobm6RBKrFm5bMk9h13CQ — that's from dnf list --enabled 16:34:17 I have a hunch 16:34:35 Or maybe just ant 16:34:39 Since zbyszek doesn't have maven 16:34:46 I get no output for "sudo dnf module list --enabled" 16:34:53 Or rather, the other way around 16:35:01 I had previously run "sudo dnf module reset eclipse ant maven" 16:35:16 To get into what I understand to be the OOTB state 16:35:32 bookwar: Could you try that with maven and see? 16:36:04 ahhh I see it 16:36:09 glassfish-el is included in maven 16:36:28 And maven has a default stream ;-) 16:36:36 https://src.fedoraproject.org/modules/maven/blob/3.5/f/maven.yaml#_186 16:36:40 joyous... 16:36:56 OK, I don't think we should be figuring this out in the meeting. 16:37:16 I still can't install it after enabling maven. 16:37:20 zbyszek: yeah. 16:37:23 mbooth: Can you please work out the ownership of glassfish? 16:37:29 nirik: Same conflict or different? 16:37:32 nirik: I don't have maven enabled. 16:37:36 same 16:37:40 sgallagh: In what sense? 16:37:50 mbooth: We can't have two default streams providing it 16:38:12 Why not? 16:38:13 So either one or the other of you needs to own it or you need to agree to split it out to a third one 16:38:39 mbooth: Because then you get different and conflicting versions *by default*. 16:38:51 *potentially* conflicting versions, yes 16:38:59 zbyszek: So why does all work well when eclipse module is enabled? 16:39:17 let's 1) have a bug filed and propose it as a blocker for the release 2) figure out details in the bugreport, especially the doble ownership, 3) get fesco to vote again on resolution 16:39:22 Because they happen to be compatible and the higher ENVR gets picked by DNF 16:39:33 i think we can setup out of the schedule fesco session this week, as it seems to be pretty urgent 16:39:42 bookwar: +1 16:39:43 * sgallagh nods 16:39:46 bookwar: +1 16:39:47 but only if there will be bug to talk about 16:39:54 +1 16:40:13 +1... I can't get it to install on f31 even with eclipse enabled. 16:40:37 nirik: Did you specify a profile? My default profile only just got merged 16:40:39 +1 16:40:42 bookwar: I think we can discuss&vote in the ticket. BUt if a live session would help, then sure. 16:40:53 mbooth: ah, could be... 16:41:02 more fun Problem: module eclipse:2019-06:3120190902131726:efdece7d-0.x86_64 requires module(maven:3.5) 16:41:19 who is filing this ticket/bug? 16:41:26 zbyszek: ok, voting in the ticket, if there is no quorum - meet? 16:43:07 bookwar: if there's no quorum, let's badger the people who didn't respond. 16:43:16 zbyszek: ok 16:43:38 nirik: I can file bugs if you tell me where 16:44:10 mbooth: the bug would be against eclipse package, about how it FTI 16:44:20 well, I've gotten confused so not sure. ;) 16:44:38 Against modular eclipse 16:44:41 Then this bug can be proposed as a blocker (https://qa.fedoraproject.org/blockerbugs/propose_bug) 16:44:44 yeah, I guess a eclipse module bug about the various not installing cases? 16:44:50 The nonmodular eclipse installs ok 16:44:59 mhroncok_mobile1: It's not modular eclipse that fails to install OOTB 16:45:05 but... say we fix those, I think we still need to allow the default eclipse module for f31. 16:45:14 Hmm, I think we might need two bugs: against normal eclipse, and against modular eclipse, since those are likely to be different issues. 16:45:32 I cannot currently get eclipse to install anywhere. ;) 16:45:38 Normal eclipse should be retired once modular is available. 16:45:59 Modular eclipse can't be default until the glassfish-el conflict (and any others) are sorted out. 16:45:59 sgallagh: in f31? 16:46:34 bookwar: Yes, since it's already out of date and unmaintained. 16:46:35 rawhide is giving me: Problem: package eclipse-jdt-1:4.12-6.module_f32+6163+c0e6dcb2.noarch requires osgi(org.opentest4j), but none of the providers can be installed 16:46:39 sgallagh: Well, glassfish-el in eclipse module is because one of the sub-packages I need is filtered out of the maven module 16:46:45 The retirement would reflect reality 16:46:52 anyway, let's not continue here 16:47:03 sgallagh: Can I really force other maintainers to support packages they don't want to for their application? 16:47:09 nirik: Rawhide may be a different issue 16:47:12 the problem is, despite these issues, we still have the same question in front of us. 16:47:27 mbooth: Right now, the maven package is out of compliance with the rules we set last week. 16:47:32 So we have to fix that anyway 16:48:00 nirik: not entirely, because we started on the presumption that eclipse FTI in F31, and it isn't clear if it does. 16:48:36 sure, but according to mbooth it fails to build... so I don't think we can ship something we can't ever update... 16:49:13 nirik: I think that would be negligent to do so 16:50:31 Anyway, we have +5 for bookwar's proposal. 16:50:41 Should we move on? 16:50:43 right, so we have no real choice but to approve the module default... but ok. 16:50:49 Yes, let's move on 16:51:21 #agreed 1) have a bug filed and propose it as a blocker for the release 2) figure out details in the bugreport, especially the doble ownership, 3) get fesco to vote again on resolution (+5, 0, -0) 16:51:29 #topic #2238 GIMP: exception to continue using Python 2 16:51:29 .fesco 2238 16:51:31 sgallagh: Issue #2238: GIMP: exception to continue using Python 2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2238 16:52:11 My question on this one was whether it makes sense to carry py2 pygtk stuff in Fedora just for GIMP or if a flatpak would be the better option. 16:52:23 (Given that one already exists) 16:52:38 We can remove the packages later 16:53:25 It gets interesting with the upgrade story there though. 16:53:31 True enough. 16:53:43 i have personally avoided flatpacks so far, and i think i am not the only one, so i wouldn't say flatpack is a drop-in replacement for a usual package 16:53:47 And it sounds like Python SIG doesn't mind, so I am okay with it. 16:53:48 i'd rather keep the package 16:53:58 * nirik is ok with the exception 16:54:02 Just wanted to make sure we considered alternatives. 16:54:18 FTR: mhroncok, me, nirik were +1 in the ticket 16:55:00 I get the reasoning, but yes, I am another who avoids flatpacks if possible. They are certainly not in the typical path. Upgrades get weird. I am fine with the exception 16:55:02 +1 16:55:23 so, formal +1 from me 16:56:11 +1 16:56:24 That's +6 16:56:55 #agreed GIMP is granted an exception to continue using Python 2 (+6, 0, -0) 16:57:03 #topic Next week's chair 16:57:06 I can. 16:57:21 #action zbyszek will chair next meeting 16:57:25 #ropic Open Floor 16:57:29 #topic Open Floor 16:58:05 * mhroncok_mobile1 needs to leave completely, sorry 16:58:43 I don't hear anything, so I'll close down. 16:58:47 Thank you for coming. 16:59:00 thanks, sgallagh, today was a good one :) 16:59:02 #endmeeting