15:02:05 <zbyszek> #startmeeting FESCO (2018-11-05)
15:02:05 <zodbot> Meeting started Mon Nov  5 15:02:05 2018 UTC.
15:02:05 <zodbot> This meeting is logged and archived in a public location.
15:02:05 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:05 <zodbot> The meeting name has been set to 'fesco_(2018-11-05)'
15:02:05 <zbyszek> #meetingname fesco
15:02:05 <zodbot> The meeting name has been set to 'fesco'
15:02:05 <zbyszek> #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:02:05 <zodbot> Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek
15:02:08 <zbyszek> #topic init process
15:02:12 <maxamillion> .hello2
15:02:13 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:02:14 <zbyszek> .hello2
15:02:16 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:16 <jforbes> .hello2
15:02:21 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:02:28 <tyll> .hello till
15:02:29 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
15:02:44 <bowlofeggs> .hello2
15:02:45 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:03:04 <zbyszek> We have quorumn
15:03:13 <zbyszek> Sorry I wasn't here last week. I messed up the time zones.
15:03:22 <zbyszek> sgallagh has a conflict and wont' be attending today.
15:03:22 <zbyszek> Nevertheless, he reported progress on #2005:
15:03:22 <zbyszek> sgallagh> zbyszek: However, if the NFS thing comes up, steved and I worked together on that last week and I think we've got a more-or-less working plan in place. I can share that at next week's meeting if needed.
15:03:37 <zbyszek> Let's roll.
15:03:40 <zbyszek> #topic follow-ups
15:03:53 <zbyszek> #topic 2003 Ursa Major (modules in buildroot) enablement
15:03:56 <zbyszek> .fesco 2003
15:03:58 <zodbot> zbyszek: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003
15:03:59 <zbyszek> https://pagure.io/fesco/issue/2003
15:04:38 <zbyszek> This is a tough one, but I don't think we have much choice, and I'm leaning towards accepting the proposed solution.
15:05:25 <zbyszek> Does anyone know of any fundamental problems with the proposed solution of having a prepopulated repo that could be used for external builds?
15:06:20 <jforbes> So, there is some work to be done to ensure that such a repo could be accessible for mock builds, but I don't think it is fundamentally difficult
15:06:36 <bowlofeggs> last week we said we'd send an e-mail to devel - did that happen?
15:06:41 <zbyszek> Nope.
15:07:05 <bowlofeggs> i think i would still benefit from feedback from devel list
15:07:07 <jforbes> No, that was completely my failure. it is sitting in "drafts"
15:08:42 <zbyszek> Do you want to send out the e-mail and leave another week for discussion?
15:08:54 <jforbes> I am not opposed to it
15:09:18 <tyll> +1 for asking devel
15:09:19 <bowlofeggs> i think it would still be good to do
15:09:46 <zbyszek> #action jforbes to send out an e-mail to devel mailing list
15:09:54 <tyll> since it will break developer's workflows it would be great to get some feedback about how much it would break things
15:10:04 <ignatenkobrain> it would be great if we would move forward with it because it is creating maintenance burden =)
15:11:15 <zbyszek> Yeah, but there is only so much we can do in a meeting. There's only a few people here.
15:11:35 <zbyszek> jforbes: +1 to waiting another week?
15:11:42 <maxamillion> +1 to waiting another week
15:11:58 <jforbes> tyll: it can break workflows, although those could be fixed with dnf changes and some infra changes
15:12:05 <jforbes> zbyszek: +1
15:12:12 <zbyszek> #agreed Let's wait another week for discussion on fedora-devel (+5, 0, 0)
15:12:28 <zbyszek> sorry ignatenkobrain
15:12:46 <zbyszek> The next topic is slightly easier, if not by much
15:12:47 <zbyszek> #topic 2004 Enabling pm_request in fedoraproject koji
15:12:47 <zbyszek> .fesco 2004
15:12:47 <zbyszek> https://pagure.io/fesco/issue/2004
15:12:48 <tyll> jforbes, the question is, could it be fixed or will it be fixed ;-)
15:12:50 <zodbot> zbyszek: Issue #2004: Enabling pm_request in fedoraproject koji - fesco - Pagure.io - https://pagure.io/fesco/issue/2004
15:13:06 <jforbes> tyll: Yes, and IDK
15:13:48 <zbyszek> So I spent a chunk of today reading through all the tickets about pm_requests, and I think we should do it, fwiw.
15:15:15 <zbyszek> Opinions?
15:15:55 <tyll> do I understand correctly, that it will make mock required for all packages that want to use it or is there going to be some rpmbuild support as well?
15:16:12 <jforbes> So, I am kind of concerned that some of this is dependent on an RFE to RPM from 2016
15:16:14 <bowlofeggs> zbyszek: is it possible to limit what pm_request can do with current release, or is that a feature request for pm_request?
15:16:34 <zbyszek> bowlofeggs: future request afaik
15:16:53 <maxamillion> jforbes: +1
15:16:59 <zbyszek> jforbes: that RFE is about making this nicer, I think we can ignore that as irrelevant for now
15:17:23 <zbyszek> tyll: the way I understand, we could either:
15:17:41 <zbyszek> - run a mock build, take the list of requests, do dnf install $list locally, and build without pm_requests
15:17:42 <bowlofeggs> i find mizdebsk's concerns compelling so i think it would be imperative to ensure those attacks are not possible
15:17:46 <jforbes> Either way, any RPM changes will likely not matter for a very long time, EPEL won't get them
15:18:34 <zbyszek> - or provide a re-implemention of pm_requests that gives a socket and turns it into either local dnf calls or just a list of packages
15:18:54 <zbyszek> This should be just a few lines of python code, to read from a socket
15:18:57 <tyll> zbyszek, I would the second one to be part of rpmbuild
15:19:02 <tyll> *would like
15:19:31 <tyll> is anyone planning to do it?
15:19:43 <tyll> or better, committing to do it
15:20:01 <zbyszek> tyll: can you clarify what is "the second one"?
15:20:22 <bowlofeggs> i think i prefer not to vote on hypothetical future features
15:20:34 <tyll> zbyszek, have a re-implementation in rpmbuild, so that it works without mock
15:20:38 <bowlofeggs> should we just say "as it is, pm_requests is not acceptable due to x,y,z"
15:21:09 <tyll> but does it need to be a re-implementation? Is pm_request specific for mock?
15:21:24 <bowlofeggs> i'm not opposed to the goal of this ticket, but i do not like the sound of the existing proposed software's security implications
15:21:38 <zbyszek> tyll: that would be an inversion of roles, because now rpmbuild doesn't know anything about package resolution, this is something that dnf and higher levels do
15:22:39 <tyll> bowlofeggs, I guess we should at least commit to allowing this if our concerns are addressed to ensure that the people working on this can rely on it going to be used if they address the concerns
15:23:00 <jforbes> bowlofeggs: again, even if such things are fixed fairly quickly in fedora, how long before they impact the epel environments?
15:23:12 <zbyszek> tyll: agreed
15:24:28 <bowlofeggs> tyll: yeah i suppose i could agree to that, though i'd have pretty general concerns
15:24:55 <bowlofeggs> jforbes: we might be able to just let the feature happen in fedora only?
15:24:57 <tyll> zbyszek, ok, I am not sure about the scope of pm_requests . I understood it would open a socket that can be written to from a spec file and then pm_requests will build a dnf command-line that mock can use to install the packages - in the rpmbuild case, then rpmbuild could show this command
15:25:04 <bowlofeggs> i guess that would be up tot he proposers
15:25:46 <jforbes> Is that possible with our current koji implementation?
15:26:40 <zbyszek> I think with current koji implementation, pm_requests is not safe, so it'd need to be improved first.
15:27:28 <zbyszek> tyll: I'm not sure about doing this in rpmbuild. It seems much easier to provide an external wrapper that opens the socket and then we let rpmbuild run.
15:27:43 <zbyszek> rpmbuild would need to learn the protocol.
15:28:30 <jforbes> Right.  As things stand I am pretty -1 to the proposal. If further work is done to improve the implementation, I could be convinced otherwise, but they could ask again at that point too
15:28:32 <tyll> zbyszek, from the user/developer perspective it makes IMHO sense to have just one tool to build rpms
15:29:14 <zbyszek> I'm not against having it there in any way
15:29:30 <zbyszek> FTR, https://github.com/rpm-software-management/mock/blob/devel/mock/py/mockbuild/plugins/pm_request.py is the plugin.
15:30:38 <bowlofeggs> so it sounds like none of us oppose the goal, just the implementation?
15:31:40 <jforbes> That seems to be the case
15:31:50 <zbyszek> proposal: The use of pm_requests is accepted in general, but the security and logging issues need to be resolved, and a way to run without mock must be implemented
15:32:32 <tyll> zbyszek, running it without mock should also be pain-free and secure
15:32:52 <zbyszek> proposal: The use of pm_requests is accepted in general, but the security and logging issues need to be resolved, and a way to run without mock easily and securely must be implemented
15:33:07 <bowlofeggs> zbyszek: i would reword it a bit: "The use of prep generated BRs is accepted in general, but must not introduce new security risks over the current implementation and must not require mock to build"
15:33:36 <bowlofeggs> i think we should be clear that we are not approving the current proposal too actually
15:33:57 <bowlofeggs> like that the current release of pm_requests is not acceptable
15:34:05 <tyll> +1 to bowlofeggs
15:34:05 <zbyszek> bowlofeggs: hmm, I think that's vague enough to not be useful
15:34:47 <jforbes> Richt, I would propose that we decline, with encouragement to request again when issues are resolved
15:34:58 <bowlofeggs> zbyszek: i was attempting to highlight that we are +1 to the goal and that the implementation as is is -1
15:35:02 <zbyszek> For example, "must not require mock to build" could be read as "the srpm with BR generated in %prep will just build"
15:35:09 <bowlofeggs> jforbes: yeah that would work for me too
15:35:25 <bowlofeggs> we could -1 and state clearly why and that we are open to reconsidering if our concerns are addressed
15:35:50 <zbyszek> We generally aprove features before they are implemented. I don't see why this case should be any different.
15:36:32 <tyll> zbyszek, the feature is to install dynamic BRs, pm_requests just an implementation
15:36:37 <tyll> IMHO
15:36:41 <jforbes> Because I think the implementation needs discussion before it is approved. There is not a clear plan here, with backout, etc
15:36:57 <bowlofeggs> yeah this isn't really a proposal i'd accept as is
15:37:40 <jforbes> If we +1 now, we never see it again, things get implemented at some point, and we don't know what that will look like.
15:37:46 <zbyszek> OK, so what the list of issues that need to be resolved?
15:38:06 <jforbes> First and foremost security.
15:38:17 <bowlofeggs> one is that it must not be possible for the spec file to act as root on the builder
15:38:25 <bowlofeggs> but yeah, "security"
15:38:29 <bowlofeggs> that's the huge one to me
15:38:42 <jforbes> Also, if that is dependent on RPM changes, those need to be made available to EPEL, or we need a way to disable the feature for EPEL builds
15:38:45 <bowlofeggs> how packagers build locally is also important to me, but nowhere near as important as security of our builders
15:39:49 <jforbes> Agreed, local build workflow is actually rather important, just not as important as builder security issues
15:39:58 <maxamillion> agreed
15:40:07 <tyll> the "dynamic BRs" also describes the security problems btw, because the current implementation does more and therefore introduces security problems
15:40:49 <tyll> if it would just create new BRs and feed them into mock, then it would not be as problematic as actually being able to call dnf
15:41:48 * nirik arrives late. I thought we were moving times for some reason.
15:42:16 <zbyszek> tyll: I think that after the filters that are requisted to solve the security issues are added, it'll be equivalent to generating new BRs
15:42:32 <zbyszek> nirik: DST end?
15:42:38 <nirik> yeah
15:43:22 <zbyszek> OK, so we have three things: 1) security issues, 2) if that is dependent on RPM changes, those need to be made available to EPEL, or we need a way to disable the feature for EPEL builds, c) local build workflow
15:43:40 <tyll> zbyszek, addint filters sounds like black listing, IMHO it should be a whitelist by just accepting package names or requirements. Then mock itself will make sure that for example only active repos are used
15:44:22 <zbyszek> tyll: it's a filter in the sense that current plugin allows e.g. 'uninstall' or '--root=/...'.
15:44:50 <zbyszek> The "filter" is about allowing 'dnf install package-name package-name package-name'.
15:45:25 <zbyszek> tyll: so what you said, except that there's no blacklist
15:45:51 <zbyszek> semantics
15:46:11 <tyll> zbyszek, yes, seems like we mean the same
15:48:17 <zbyszek> proposal: current proposal is rejected. FESCo asks for a new proposal which addresses issues 1), 2), 3) above.
15:49:16 <tyll> zbyszek, +1
15:49:27 <jforbes> +1
15:50:18 <nirik> +1
15:51:05 <zbyszek> #agreed current proposal is rejected. FESCo asks for a new proposal which addresses issues 1-3
15:51:08 <zbyszek> #undo
15:51:08 <zodbot> Removing item from minutes: AGREED by zbyszek at 15:51:05 : current proposal is rejected. FESCo asks for a new proposal which addresses issues 1-3
15:51:21 <zbyszek> Sorry, typing-ahead failure :/
15:51:28 <maxamillion> +1
15:51:42 <maxamillion> bleh, trying to multitask
15:51:57 <maxamillion> I constantly have conflicting meetings with this one :(
15:52:09 <zbyszek> bowlofeggs?
15:52:28 <zbyszek> The time is not very convenient, I agree
15:52:32 <bowlofeggs> zbyszek: +1
15:52:36 <zbyszek> #agreed current proposal is rejected. FESCo asks for a new proposal which addresses issues 1-3 (+6, 0, 0)
15:52:41 <bowlofeggs> sorry i was away briefly :/
15:52:50 <zbyszek> #topic Next week's chair
15:52:50 <zbyszek> #action NAME will chair next meeting
15:52:54 <tyll> zbyszek, the agreed command should probably spell out the issues
15:53:01 <tyll> for the minutes
15:53:26 <zbyszek> I'll paste it from the log. It's too long to fit and zodbot will split it anyway.
15:53:37 <bowlofeggs> i can take next week
15:53:39 <zbyszek> If that's OK?
15:53:43 <tyll> ok
15:53:54 <zbyszek> #action bowlofeggs will chair next meeting
15:54:00 <zbyszek> #topic Open Floor
15:54:18 <zbyszek> #info Reminder: fesco members, please vote on https://pagure.io/fesco/issue/2009
15:54:21 <zbyszek> .fesco .2009
15:54:21 <zodbot> zbyszek: Error: '.2009' is not a valid integer.
15:54:25 <zbyszek> .fesco 2009
15:54:28 <zodbot> zbyszek: Issue #2009: libsolv SONAME bump in stable - fesco - Pagure.io - https://pagure.io/fesco/issue/2009
15:54:33 <jforbes> I will actually be out the next 2 weeks due to Plumbers, then PTO. I will vote in ticket on issues
15:55:09 <zbyszek> Anyone else?
15:55:44 <zbyszek> I'll close in a minute.
15:56:51 <zbyszek> See y'all next week.
15:56:54 <zbyszek> #endmeeting