15:00:12 <sgallagh> #startmeeting FESCO (2019-09-30)
15:00:12 <zodbot> Meeting started Mon Sep 30 15:00:12 2019 UTC.
15:00:12 <zodbot> This meeting is logged and archived in a public location.
15:00:12 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:12 <zodbot> The meeting name has been set to 'fesco_(2019-09-30)'
15:00:12 <sgallagh> #meetingname fesco
15:00:12 <sgallagh> #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:12 <zodbot> The meeting name has been set to 'fesco'
15:00:12 <zodbot> Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:12 <sgallagh> #topic init process
15:00:15 <zbyszek> .hello2
15:00:16 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:17 <sgallagh> .hello2
15:00:19 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:20 <jforbes> .hello2
15:00:21 <otaylor> .hello2
15:00:22 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:25 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:00:38 <nirik> .hello kevin
15:00:39 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:01:03 <sgallagh> ignatenkobrain indicated that he could not attend today on account of newborn.
15:01:14 <bookwar1> .hello2
15:01:15 <zodbot> bookwar1: Sorry, but you don't exist
15:01:20 <bookwar1> wow
15:01:27 <sgallagh> your nick doesn't match
15:01:31 <bookwar> .hello2
15:01:32 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:58 <bookwar> sgallagh: yes, but the message is fun )
15:02:05 <sgallagh> agreed :)
15:02:43 <sgallagh> 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 <mhroncok> hey, sorry for the delay
15:03:17 <sgallagh> Perfect timing
15:03:22 <sgallagh> #topic #2231 F32 System-Wide Change: Firewalld Default to nftables
15:03:23 <sgallagh> .fesco 2231
15:03:24 <zodbot> sgallagh: Issue #2231: F32 System-Wide Change: Firewalld Default to nftables - fesco - Pagure.io - https://pagure.io/fesco/issue/2231
15:04:17 <sgallagh> So mhroncok voted -1 because he feels this shouldn't land unless both CRI-O and Docker container ecosystems support it.
15:04:17 <mhroncok> all I ask for is that the maintainer of "docker" is on board
15:04:53 <sgallagh> The counter-argument is that we (Fedora) has little-to-no influence to do that for Docker
15:04:57 <otaylor> mhroncok: moby-engine?
15:05:01 <mhroncok> I realize that docker is no longer considered cool
15:05:02 <zbyszek> Considering that after 12 days there is no reply from @olem... I'd say they are either not onboard or MIA.
15:05:14 <otaylor> mhroncok: or do you mean official docker inc. builds?
15:05:21 <sgallagh> mhroncok: It's not so much about "cool" as "Docker won't accept patches"
15:05:26 <mhroncok> I mean Fedora users who do dnf install docker
15:05:58 <mhroncok> are we OK if they dnf install docker and their container network doesn't work?
15:06:05 <otaylor> mhroncok: via https://download.docker.com/linux/fedora/docker-ce.repo ?
15:06:12 <mhroncok> via fedora repos
15:06:15 <bookwar> 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 <otaylor> 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 <sgallagh> (To be clear, I'm on the fence here. I'm just stating the counter-arguments so we think them through)
15:07:20 <jforbes> 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 <nirik> I think at this point we have given a lot of time...
15:07:29 <mhroncok> otaylor: dnf install docker still gives you something
15:07:34 <nirik> so, I am +1 to approve and release note it.
15:07:41 <sgallagh> 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 <mhroncok> so what is Fedora's docker story?
15:08:19 <nirik> docker or moby?
15:08:27 <mhroncok> is it "use Ubuntu"?
15:08:37 <nirik> use podman
15:08:39 <sgallagh> mhroncok: It really is "use podman"
15:08:43 <mhroncok> while I relaize that docker and moby are different things, user's won't
15:08:44 <otaylor> 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 <sgallagh> .fasinfo olem
15:08:57 <zodbot> 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 <zodbot> sgallagh: Approved Groups: packager fedorabugs cla_done cla_fpca
15:09:05 <sgallagh> otaylor: ^^
15:09:43 <mhroncok> is teh message "Fedora does no longer support docker/moby/whatever"?
15:09:49 <otaylor> 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 <sgallagh> 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 <sgallagh> I wonder if we could just Obsoletes: it and provide a symlink for the command name
15:10:47 <mhroncok> sgallagh: if it works, we probably should
15:11:05 <sgallagh> mhroncok: Should work at least 90% of the time
15:11:38 <nirik> in podman? or moby?
15:11:42 <mhroncok> 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 <zbyszek> BTW, how does moby-engine fare under cgroupsv2?
15:12:40 <mhroncok> no idea
15:12:42 <zbyszek> .bugzilla 1746355
15:12:55 <nirik> mhroncok: that is:
15:12:55 <zbyszek> What is the command do display a bug?
15:12:57 <mhroncok> sgallagh: anyway, I think there is a strong support of this even if I -1 it
15:12:58 <nirik> moby-engine-0:18.09.8-2.ce.git0dd43dd.fc31.x86_64
15:12:58 <nirik> podman-docker-2:1.5.2-0.85.dev.git7875e00.fc32.noarch
15:13:03 <otaylor> 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 <nirik> (at least in rawhide)
15:13:07 <sgallagh> .bug 1746355
15:13:08 <zodbot> sgallagh: 1746355 – Error starting daemon: Devices cgroup isn't mounted - https://bugzilla.redhat.com/1746355
15:13:15 <bookwar> it seems they resolved the issue on debian by providing the iptables-legacy command which does networking for docker
15:13:44 <bookwar> theoretically it is doable for moby on fedora too
15:13:48 <zbyszek> So it seems that moby-engine simply fails to start in F31 without additional work-arounds.
15:14:19 <sgallagh> 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 <otaylor> 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 <sgallagh> When we approve this change, we effectively give moby-engine a deadline: adapt or die.
15:15:11 <zbyszek> bookwar: do you have a link to the Debian patch?
15:15:20 <nirik> well, or workaround by booting with a v1 command...
15:15:30 <jforbes> 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 <bookwar> 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 <sgallagh> Proposal: Change is approved. moby-engine must adapt by Beta Freeze or be dropped from Fedora.
15:17:01 <zbyszek> sgallagh: -1 for the "dropped from Fedora" part.
15:17:26 <sgallagh> zbyszek: Keeping it around and broken doesn't seem any better
15:17:34 <sgallagh> I'd rather see us drop it and Obsoletes it with podman
15:17:50 <sgallagh> It can come back to life later if they want
15:18:23 <jforbes> F32 beta does give a reasonable amount of time
15:18:41 <bookwar> 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 <mhroncok> this sounds reasonable as long as podman provides both the package name and the command
15:18:52 <nirik> I suppose... will any of us remember to do that at that point? :)
15:18:56 <zbyszek> 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 <otaylor> 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 <sgallagh> ok, I withdraw the restriction.
15:19:59 <bookwar> otaylor: +1, afaik one also can configure networking "manually" (don't know how)
15:20:06 <nirik> I thought cgroups was the problem? or is it iptables for moby-engine?
15:20:14 <zbyszek> nirik: both
15:20:20 <mhroncok> 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 <sgallagh> Proposal: Change is approved. The maintainers of moby-engine are responsible for how that turns out for them.
15:20:23 <nirik> double fun
15:20:35 <jforbes> nirik: you can still use cgroups v1 if you want as well, it just isn't the default
15:20:41 <nirik> right, I know.
15:20:42 <jforbes> sgallagh: +1
15:20:44 <otaylor> mhroncok: -1
15:20:46 <otaylor> sgallagh: +1
15:20:52 <nirik> sgallagh: +1
15:21:14 <zbyszek> Before I vote, a quick q:
15:21:40 <zbyszek> 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 <sgallagh> zbyszek: They're not, really.
15:22:00 <nirik> it's not a full replacement tho.
15:22:13 <sgallagh> mhroncok's proposal is essentially declaring a FESCo blocker on the "docker" command working.
15:22:20 <sgallagh> Mine does not include that requirement.
15:22:21 <mhroncok> yes
15:22:39 <otaylor> 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 <mhroncok> if the docker command breaks on fedora, people will blame fedora, not moby engine
15:23:04 <jforbes> mhroncok: I am okay with that
15:23:05 <nirik> podman-docker does provide it.
15:23:18 <nirik> as well as moby-engine (alternatives I think?)
15:23:57 <otaylor> 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 <bookwar> 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 <mhroncok> nirik: moby-engine and podman-docker provide the command, only moby-engne provides the name (rpm provide)
15:24:55 <otaylor> podman is part of the standard workstation install, podman-docker and moby-engine are not
15:25:14 <sgallagh> 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 <nirik> or at least tell us how long it might take to adjust...
15:25:40 <sgallagh> If they don't do that, why are we treating it as more important than any other bitrotten package?
15:26:57 <bookwar> 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 <bookwar> but generally i agree that we shouldn't block the change on that
15:28:26 <zbyszek> bookwar: agreed on not blocking. I'm still not sure what is the best way to smooth the transition.
15:29:02 <mhroncok> BTW you can still approve the change, even if I don't like it
15:29:21 <sgallagh> mhroncok: You can reserve the right to say "I told you so", of course :)
15:29:29 <mhroncok> :D
15:29:31 <jforbes> zbyszek: Which is exactly what sgallagh's proposal says, let the package maintainer decide the best way to smooth the transition
15:29:32 <bookwar> 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 <zbyszek> OK, +1 to sgallagh, -1 to mhroncok
15:30:21 <bookwar> also +1 to sgallagh
15:30:41 <mhroncok> -1 to sgallagh
15:32:08 <sgallagh> #agreed Change is approved. The maintainers of moby-engine are responsible for how that turns out for them. (+6, 0, -1)
15:32:12 <zbyszek> 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 <sgallagh> #topic #2236 Default Stream for Eclipse module
15:32:25 <sgallagh> .fesco 2236
15:32:25 <mhroncok> (a side note, I'll have to leave in ~1 hour. can join via my cellphone)
15:32:26 <zodbot> sgallagh: Issue #2236: Default Stream for Eclipse module - fesco - Pagure.io - https://pagure.io/fesco/issue/2236
15:32:36 <sgallagh> There are only two topics remaining
15:32:40 * mbooth is here to answer questions for this one :-)
15:32:44 <zbyszek> "only" ;)
15:33:11 <sgallagh> As a quick update, we made some progress on Ursa Prime this week.
15:33:35 <sgallagh> MBS builds now have default streams included automatically for their builds.
15:33:45 <mhroncok> 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 <sgallagh> 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 <sgallagh> mhroncok: Correct
15:34:42 <sgallagh> Though we may be able to point to the new default stream policy we approved last week now
15:35:01 <sgallagh> (That default stream contents all have to be treated as if they were non-modular)
15:35:02 <mhroncok> 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 <sgallagh> s/contents/artifacts/
15:35:34 <mhroncok> the list is at https://pagure.io/fesco/issue/2236#comment-601406
15:35:41 <nirik> note we need non default for this case I think...
15:35:53 <mbooth> 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 <sgallagh> nirik: What do you mena?
15:36:19 <mbooth> 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 <mbooth> Anything can be installed from the eclipse market place
15:36:54 <mbooth> 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 <nirik> 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 <mhroncok> mbooth: so all the packages that are listed in there and are called "eclipse-" would go away, correct?
15:38:25 <sgallagh> nirik: That's orthogonal to the question in this topic.
15:39:03 <nirik> ok
15:39:04 <mbooth> mhroncok: Yeah
15:39:49 <mbooth> If someone wants to the maintain ursine eclipse plugins, they will be able to with ursa-major, AIUI
15:40:04 <sgallagh> mbooth: s/Ursa Major/Ursa Prime/
15:40:14 <mhroncok> mbooth: let me update the list then
15:40:18 <sgallagh> They're two different solutions to the modules-in-the-buildroot problem
15:40:38 <mbooth> sgallagh: Both to be deployed?
15:40:47 * mbooth is not quite in charge of all the details
15:40:49 <sgallagh> No
15:40:57 <nirik> usra major is being obsoleted by ursa prime
15:41:07 <sgallagh> Ursa Major was basically v1 which was used for RHEL 8 but rejected by FESCo for FEdora
15:41:14 <sgallagh> Ursa Prime is the replacement
15:41:23 <mbooth> Okay, I will update my vocabulary :-)
15:42:42 <zbyszek> mbooth: will you be willing to create the "standalone swt" package (whatever the final name is)?
15:43:23 <bookwar> 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 <mhroncok> new query almost over...
15:44:15 <mbooth> zbyszek: Yes. It should be pretty easily doable
15:44:45 <mhroncok> 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 <sgallagh> Based on this, I'm +1 here.
15:44:55 * nirik is also +1
15:45:06 <mbooth> 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 <mbooth> Same will be done with SWT
15:45:46 <mhroncok> query complete
15:46:09 <mhroncok> eclipse-swt (solved), eclipse-equinox-osgi and eclipse-platform are needed
15:47:47 <mbooth> 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 <mbooth> We've moved many such packages already in stewardship-sig
15:48:31 <mbooth> Because in reality they should not depend on a particular OSGi implementation
15:49:30 <mbooth> So I can check that, it should just be a trivial change to build requires if so.
15:49:31 <mhroncok> 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 <mhroncok> because the ticket says "Default Stream for Eclipse module" where in fact this is a Fedora Change
15:50:12 <zbyszek> I seems like this should really be a Change, with the description of the impact on all packages, users, etc.
15:51:05 <mbooth> I mean, the point of the ticket was to remove impact on users.
15:51:45 <mhroncok> I don't see how this removes impact
15:51:47 <sgallagh> Can we do things backwards and approve it now, but ask mbooth to file a Late Change Proposal?
15:51:53 <mhroncok> sgallagh: -1
15:52:14 <mbooth> mhroncok: Because without the default stream, installing Eclipse breaks in unexpected ways for users.
15:52:23 <mbooth> I have explained that situation in the ticket
15:52:28 <zbyszek> mysql-connector-java depends on hibernate, which depends on eclipse
15:52:49 <mhroncok> mbooth: enabling the default streams removes this impact and creates more different impact
15:53:29 <bookwar> mbooth: it seems that eclipse is not "leaf enough" for this to be a self-contained change
15:53:39 <mhroncok> "things are broken at place A" isn't a valid argument to break things at place B
15:54:03 <mbooth> mhroncok: How are things breaking in place B?
15:54:24 <sgallagh> mhroncok: What exactly do you think is going to break when this goes to default?
15:55:18 <zbyszek> mbooth, sgallagh: various packages that BR eclipse packages will break.
15:55:29 <mhroncok> 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 <mbooth> This is dealt with by the introduction of swt package
15:56:14 <mhroncok> I appreciate that mbooth is proposing solutions for the problems as they are discovered
15:56:20 <zbyszek> 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 <bookwar> 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 <bookwar> and we need to coordinate it better then via this one fesco ticket
15:57:02 <bookwar> this is why mhroncok proposes to use Fedora Change process for it
15:57:19 <mhroncok> which is a process designed exactly for this kind of changes
15:57:23 <mbooth> bookwar: Coordinating with who? I have been defacto maintainer of all these packages for years
15:57:49 <bookwar> mbooth: like hibernate ?
15:57:59 <mbooth> Actually no-one maintains hibernate -- it should be retiref
15:58:07 <mhroncok> odubaj maintains hibernate
15:58:33 <mhroncok> and by doing this, you make it even harder than it is, I suppose
15:59:03 <mbooth> hibernate package has no commits in 3 years except for mass rebuild bumps.
15:59:07 <mhroncok> this pretty sums up what I'm worried about: https://pagure.io/fesco/issue/2236#comment-600605
15:59:27 <mhroncok> mbooth: can we ignore packages that have no commits in 3 years except for mass rebuild bumps?
15:59:42 <mhroncok> I guess we can, when this is clearly descibed in a change proposal and approved
16:00:18 <mhroncok> 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 <mbooth> 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 <zbyszek> 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 <zbyszek> *about hibernate-to-disk
16:01:48 <mhroncok> I donẗ have anything more to say
16:01:59 <mhroncok> I'm strongly against doing Fedora changes this way
16:02:23 <zbyszek> Proposal: we ask for a Change to be filed using the normal process
16:02:51 <mhroncok> zbyszek: +1
16:03:32 <mbooth> The "change" amounts to keeping things unchanged for users and contributors...
16:03:39 <sgallagh> 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 <mhroncok> teh change can be approved in a week if we determine it is urgent
16:04:16 <bookwar> 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 <bookwar> mbooth: so it is a change
16:04:27 <zbyszek> 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 <mhroncok> but considering that f31 is over and f32 will be released in 6+ months, I don't see the urgency
16:05:05 <mhroncok> or are we going to land this in F31 a week before final freeze?
16:06:06 <sgallagh> 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 <mhroncok> sgallagh: so this is indeed planned for f31?
16:06:29 <zbyszek> Oh, that's for F31, this didn't really come up before.
16:06:43 <mhroncok> where is this said at all?
16:07:23 <mbooth> 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 <mhroncok> sgallagh: you knew about this for months?
16:08:17 <mhroncok> 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 <mhroncok> this is all part of the change process BTW, descibing such things
16:08:50 <mbooth> mhroncok: If the module is enabled (by default or explicitly) it just works (i.e. no change)
16:09:15 <sgallagh> And if it is not enabled: dependency issues I presume?
16:10:51 <nirik> 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 <zbyszek> nirik: it seems we are slowly figuring out the coordination in this meeting.
16:11:26 <mhroncok> I see no coordination done apart from us discovering random issue as mbooth saying how it is posible to fix them
16:11:33 <mbooth> sgallagh: Yes, because some deps moved to maven/ant modules and retired in ursine distro
16:11:49 <nirik> well, whats to be done? default stream... ?
16:12:00 <nirik> which is what this ticket is about.
16:12:14 <bookwar> nirik: we still have a list of depepndent packages
16:12:16 <mhroncok> there are two different issues here
16:12:44 <nirik> in 31 we don't do anything with them, in f32 they get retired as packages normally do?
16:12:46 <mhroncok> 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 <mbooth> bookwar: These dependent packages are not broken by adding a default stream
16:12:51 <mhroncok> that si clearly a Fedora 32 change
16:13:00 <mhroncok> the second problme is, eclipse in Fedora 31 is broken?
16:13:45 <nirik> the first problem is already done tho...? and the second would be fixed by us just approving this.
16:13:45 <bookwar> 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 <mhroncok> is the problem this? https://bugzilla.redhat.com/show_bug.cgi?id=1670518
16:14:40 <mhroncok> nirik: already done how?
16:14:55 <mbooth> mhroncok: That is an unrelated problem
16:15:34 <nirik> 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 <mhroncok> so where is this problem described in the first place?
16:15:45 <zbyszek> 'dnf install eclipse' offers to install 52 packages in F31. Doesn't this work?
16:15:57 <mhroncok> nirik: if the thing is this huge and clearly impacts a lot of other packages, yes, we do
16:16:10 <mhroncok> I've just installed eclipse in 31 mock
16:16:46 <mbooth> Without the module stream enabled, you get this kind of error: https://paste.fedoraproject.org/paste/C6oa2uMXOU2JdUEQZ5ylfw
16:17:43 <nirik> so, I guess we could say... disable/remove the module for f31 and do it all in f32 then...
16:18:08 <nirik> mhroncok: mock has no modular repos enabled, so you bypassed the module
16:18:08 <mbooth> mhroncok: This is what prompted me to file this FESCo ticket: https://pagure.io/fedora-comps/pull-request/409
16:18:20 <mhroncok> nirik: so removing the module fixes the problem?
16:18:45 <sgallagh> Mock shouldn’t work unless there’s a non-modular version around somewhere.
16:18:49 <nirik> mhroncok: I don't know for sure, but it sounds like if you got it to work in mock...
16:18:50 <mhroncok> there is
16:19:04 <mhroncok> sgallagh: that's my point here, there is nonmodular version
16:19:16 <sgallagh> Sounds like it wasn’t retired properly then
16:19:26 <mhroncok> it wasn't ever retired at all
16:19:39 <bookwar> mbooth: nonmodular version is older then the modular one?
16:19:46 <mbooth> bookwar: Yes
16:20:03 <mbooth> Because it's impossible to build Eclipse for non-modular in f31+
16:20:10 <jforbes> which seems like a bit  of a mess at this point
16:20:11 <mhroncok> can we at least please have a ticket that describes this all?
16:20:18 <mbooth> So I can't fix bugs in non-modular
16:20:30 <bookwar> so we can go with old version, but then no chance to update it, no bugfixes and so
16:20:41 <nirik> sounds like.
16:21:17 <bookwar> and then there is a modular version which will do the "shadowing" Miro mentioned, if we enable default stream for it
16:22:03 <mhroncok> I need to leave, sorry
16:22:10 <bookwar> 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 <zbyszek> Final freeze is in 9 days. I don't want to do such massive changes at this point.
16:22:21 <sgallagh> bookwar: Not untested
16:22:27 <sgallagh> We've been doing that for Node.js since F29
16:22:33 <mhroncok> I'm with zbyszek on this
16:22:48 <nirik> but we have to move forward, we can't easily go back... :(
16:22:55 <mbooth> IMO adding a default stream is not a "massive change"
16:23:09 <sgallagh> It's also trivial to revert if it somehow breaks
16:23:22 <sgallagh> So I still move that we go ahead and do it.
16:23:30 <bookwar> after f31 release, will we be able to add default streams for f31?
16:23:33 <zbyszek> nirik: it is changing how packages are built and installed, with possible ripple effects throughout the distro.
16:23:34 <nirik> 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 <jforbes> And it lessens the problem of people installing an eclipse that can't get updates for security or bugs
16:23:50 <sgallagh> bookwar: Technically or by policy?
16:24:08 <sgallagh> Eh, either way the answer is "yes" for FESCo.
16:24:17 <bookwar> sgallagh: everything is possible technically )
16:24:25 <nirik> 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 <jforbes> I don't see much of a way around it at this point. I am +1 here
16:24:58 <sgallagh> As before, I'm +1
16:25:00 <zbyszek> nirik: Well, the version in F31 works, no? I.e. not doing anything is a valid option.
16:25:13 <mbooth> zbyszek: No: https://paste.fedoraproject.org/paste/C6oa2uMXOU2JdUEQZ5ylfw
16:25:18 <nirik> zbyszek: and never to get updates? what if there's a nasty security bug?
16:25:40 * nirik is +1
16:25:41 <jforbes> nirik: +1
16:25:46 <sgallagh> mbooth: That's a plugin, what about the bare minimum IDE?
16:26:08 <nirik> mbooth: you would need to --disablerepo=\*modular\*
16:26:21 <nirik> (to simulate dropping the module)
16:26:30 <mbooth> For the IDE alone, the error is more concise, obvs https://paste.fedoraproject.org/paste/vGWW80WQcPKCrp1yK8tvwQ
16:26:55 <mbooth> I am really not prepared to tell users to disable update repos :-/
16:27:08 <nirik> mbooth: no, you misunderstand.
16:27:24 <sgallagh> Where does glassfish come from?
16:27:26 <nirik> there's 3 options: a) do nothing, leave it as now. This gives broken deps as you see.
16:27:36 <mbooth> sgallagh: Eclipse module
16:27:41 <sgallagh> ok
16:27:44 <nirik> b) drop the modular eclipse in f31. This leaves the non modular one that you can't update
16:27:55 <zbyszek> mbooth: how exactly is the error you are showing generated? You don't show the system version.
16:28:12 <mbooth> zbyszek: It is a F31 system
16:28:15 <nirik> c) keep the modular one, make it default and retire the non modular stuff
16:28:45 <bookwar> nirik: retire only eclipse itself, one package?
16:28:46 <nirik> mbooth: a f31 system where you have not enabled the eclipse module right?
16:28:47 <zbyszek> 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 <sgallagh> d) Make the eclipse module a default stream and retire stuff only in F32
16:29:16 <nirik> zbyszek: do you have the modular repos enabled? did you at some time 'dnf enable eclipse'
16:29:32 <zbyszek> nirik: yes, no
16:29:43 <zbyszek> (afaict, afaik, ttbomk)
16:30:01 <zbyszek> $ rpm -q --whatprovides eclipse
16:30:01 <zbyszek> eclipse-jdt-4.11-3.fc31.noarch
16:30:15 <sgallagh> Yeah, I also don't get broken deps
16:30:43 <sgallagh> I have several modules enabled, though. Notably ant
16:30:45 <nirik> hum.
16:30:57 <sgallagh> and maven
16:30:59 <bookwar> i get, on a clean fedora:31 container
16:31:00 <zbyszek> 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 <nirik> sudo dnf module --enabled list ? show eclipse enabled?
16:31:44 <sgallagh> Not on mine
16:31:56 <zbyszek> nirik: that gives an error
16:32:06 <zbyszek> dnf module: error: the following arguments are required: subcmd, module-spec
16:32:14 <sgallagh> `sudo dnf module list --enabled`
16:32:20 <nirik> sorry, ordering
16:32:38 * nirik is puzzled.
16:33:29 <sgallagh> mbooth: Can you run that command too?
16:33:34 <bookwar> https://paste.fedoraproject.org/paste/uWICYrVLx-nQCYRvrw2Ceg
16:34:06 <nirik> bookwar: thats what I see too...
16:34:15 <sgallagh> bookwar: Could you try enabling ant and maven and do it again.
16:34:17 <zbyszek> https://paste.fedoraproject.org/paste/Jdobm6RBKrFm5bMk9h13CQ — that's from dnf list --enabled
16:34:17 <sgallagh> I have a hunch
16:34:35 <sgallagh> Or maybe just ant
16:34:39 <sgallagh> Since zbyszek doesn't have maven
16:34:46 <mbooth> I get no output for "sudo dnf module list --enabled"
16:34:53 <sgallagh> Or rather, the other way around
16:35:01 <mbooth> I had previously run "sudo dnf module reset eclipse ant maven"
16:35:16 <mbooth> To get into what I understand to be the OOTB state
16:35:32 <sgallagh> bookwar: Could you try that with maven and see?
16:36:04 <sgallagh> ahhh I see it
16:36:09 <sgallagh> glassfish-el is included in maven
16:36:28 <mbooth> And maven has a default stream ;-)
16:36:36 <sgallagh> https://src.fedoraproject.org/modules/maven/blob/3.5/f/maven.yaml#_186
16:36:40 <sgallagh> joyous...
16:36:56 <zbyszek> OK, I don't think we should be figuring this out in the meeting.
16:37:16 <nirik> I still can't install it after enabling maven.
16:37:20 <nirik> zbyszek: yeah.
16:37:23 <sgallagh> mbooth: Can you please work out the ownership of glassfish?
16:37:29 <sgallagh> nirik: Same conflict or different?
16:37:32 <zbyszek> nirik: I don't have maven enabled.
16:37:36 <nirik> same
16:37:40 <mbooth> sgallagh: In what sense?
16:37:50 <sgallagh> mbooth: We can't have two default streams providing it
16:38:12 <mbooth> Why not?
16:38:13 <sgallagh> 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 <zbyszek> mbooth: Because then you get different and conflicting versions *by default*.
16:38:51 <sgallagh> *potentially* conflicting versions, yes
16:38:59 <mbooth> zbyszek: So why does all work well when eclipse module is enabled?
16:39:17 <bookwar> 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 <sgallagh> Because they happen to be compatible and the higher ENVR gets picked by DNF
16:39:33 <bookwar> i think we can setup out of the schedule fesco session this week, as it seems to be pretty urgent
16:39:42 <zbyszek> bookwar: +1
16:39:43 * sgallagh nods
16:39:46 <sgallagh> bookwar: +1
16:39:47 <bookwar> but only if there will be bug to talk about
16:39:54 <mhroncok_mobile1> +1
16:40:13 <nirik> +1... I can't get it to install on f31 even with eclipse enabled.
16:40:37 <mbooth> nirik: Did you specify a profile? My default profile only just got merged
16:40:39 <jforbes> +1
16:40:42 <zbyszek> bookwar: I think we can discuss&vote in the ticket. BUt if a live session would help, then sure.
16:40:53 <nirik> mbooth: ah, could be...
16:41:02 <nirik> more fun Problem: module eclipse:2019-06:3120190902131726:efdece7d-0.x86_64 requires module(maven:3.5)
16:41:19 <nirik> who is filing this ticket/bug?
16:41:26 <bookwar> zbyszek: ok, voting in the ticket, if there is no quorum - meet?
16:43:07 <zbyszek> bookwar: if there's no quorum, let's badger the people who didn't respond.
16:43:16 <bookwar> zbyszek: ok
16:43:38 <mbooth> nirik: I can file bugs if you tell me where
16:44:10 <zbyszek> mbooth: the bug would be against eclipse package, about how it FTI
16:44:20 <nirik> well, I've gotten confused so not sure. ;)
16:44:38 <mhroncok_mobile1> Against modular eclipse
16:44:41 <zbyszek> Then this bug can be proposed as a blocker (https://qa.fedoraproject.org/blockerbugs/propose_bug)
16:44:44 <nirik> yeah, I guess a eclipse module bug about the various not installing cases?
16:44:50 <mhroncok_mobile1> The nonmodular eclipse installs ok
16:44:59 <mbooth> mhroncok_mobile1: It's not modular eclipse that fails to install OOTB
16:45:05 <nirik> but... say we fix those, I think we still need to allow the default eclipse module for f31.
16:45:14 <zbyszek> 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 <nirik> I cannot currently get eclipse to install anywhere. ;)
16:45:38 <sgallagh> Normal eclipse should be retired once modular is available.
16:45:59 <sgallagh> Modular eclipse can't be default until the glassfish-el conflict (and any others) are sorted out.
16:45:59 <bookwar> sgallagh: in f31?
16:46:34 <sgallagh> bookwar: Yes, since it's already out of date and unmaintained.
16:46:35 <nirik> 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 <mbooth> 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 <sgallagh> The retirement would reflect reality
16:46:52 <bookwar> anyway, let's not continue here
16:47:03 <mbooth> sgallagh: Can I really force other maintainers to support packages they don't want to for their application?
16:47:09 <sgallagh> nirik: Rawhide may be a different issue
16:47:12 <nirik> the problem is, despite these issues, we still have the same question in front of us.
16:47:27 <sgallagh> mbooth: Right now, the maven package is out of compliance with the rules we set last week.
16:47:32 <sgallagh> So we have to fix that anyway
16:48:00 <zbyszek> 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 <nirik> 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 <mbooth> nirik: I think that would be negligent to do so
16:50:31 <zbyszek> Anyway, we have +5 for bookwar's proposal.
16:50:41 <zbyszek> Should we move on?
16:50:43 <nirik> right, so we have no real choice but to approve the module default... but ok.
16:50:49 <sgallagh> Yes, let's move on
16:51:21 <sgallagh> #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 <sgallagh> #topic #2238 GIMP: exception to continue using Python 2
16:51:29 <sgallagh> .fesco 2238
16:51:31 <zodbot> sgallagh: Issue #2238: GIMP: exception to continue using Python 2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2238
16:52:11 <sgallagh> 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 <sgallagh> (Given that one already exists)
16:52:38 <mhroncok_mobile1> We can remove the packages later
16:53:25 <jforbes> It gets interesting with the upgrade story there though.
16:53:31 <sgallagh> True enough.
16:53:43 <bookwar> 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 <sgallagh> And it sounds like  Python SIG doesn't mind, so I am okay with it.
16:53:48 <bookwar> i'd rather keep the package
16:53:58 * nirik is ok with the exception
16:54:02 <sgallagh> Just wanted to make sure we considered alternatives.
16:54:18 <zbyszek> FTR: mhroncok, me, nirik were +1 in the ticket
16:55:00 <jforbes> 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 <jforbes> +1
16:55:23 <bookwar> so, formal +1 from me
16:56:11 <sgallagh> +1
16:56:24 <sgallagh> That's +6
16:56:55 <sgallagh> #agreed GIMP is granted an exception to continue using Python 2 (+6, 0, -0)
16:57:03 <sgallagh> #topic Next week's chair
16:57:06 <zbyszek> I can.
16:57:21 <sgallagh> #action zbyszek will chair next meeting
16:57:25 <sgallagh> #ropic Open Floor
16:57:29 <sgallagh> #topic Open Floor
16:58:05 * mhroncok_mobile1 needs to leave completely, sorry
16:58:43 <sgallagh> I don't hear anything, so I'll close down.
16:58:47 <sgallagh> Thank you for coming.
16:59:00 <bookwar> thanks, sgallagh, today was a good one :)
16:59:02 <sgallagh> #endmeeting