17:00:38 <kalev> #startmeeting FESCO (2016-04-01)
17:00:38 <zodbot> Meeting started Fri Apr  1 17:00:38 2016 UTC.  The chair is kalev. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:38 <zodbot> The meeting name has been set to 'fesco_(2016-04-01)'
17:00:43 <kalev> #meetingname fesco
17:00:43 <zodbot> The meeting name has been set to 'fesco'
17:00:45 <kalev> #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh
17:00:45 <zodbot> Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh
17:00:50 <kalev> #topic init process
17:00:53 <sgallagh> .hello sgallagh
17:00:54 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:00 <kalev> .hello kalev
17:01:01 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
17:01:04 <nirik> .hello kevin
17:01:05 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:01:08 <paragan> .hello pnemade
17:01:11 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
17:02:28 <kalev> let's see, not sure if we have a quorum today
17:02:50 <maxamillion> .hello maxamillion
17:02:51 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:02:55 <kalev> dgilmore and jwb sent their regards
17:03:05 <maxamillion> sorry for the delay, firefox was trying to eat my machine
17:03:16 <kalev> ahh good, looks like we have 5 now
17:03:38 <kalev> so we have a bunch of new items and a Change review
17:03:42 <kalev> let's get started then
17:03:48 <kalev> #topic #1552 Review of delayed Changes for F24
17:03:51 <kalev> .fesco 1552
17:03:52 <zodbot> kalev: #1552 (Review of delayed Changes for F24) – FESCo - https://fedorahosted.org/fesco/ticket/1552
17:04:29 <kalev> I think we went through the systemd split, but there's still a question about the Layered Docker Image Build Service
17:04:35 <kalev> maxamillion, do you know how it's coming along?
17:04:53 <sgallagh> I'm not sure if I should mention it here or in Open Floor, but there's a bit of a snarl with the Node.js Change that came up today and should probably be discussed by FESCo how best to proceed.
17:05:10 <maxamillion> kalev: it's good, we did an end-to-end build yesterday with Koji Content Generators included .... I'm getting patches upstream now and will be redeploying stage later today or Monday
17:05:34 <maxamillion> kalev: I will update the tracker BZ
17:05:35 <kalev> okay perfect, can you comment to that effect in the ticket too please?
17:05:36 <kalev> thanks
17:05:38 <maxamillion> +1
17:05:40 <maxamillion> will do
17:05:57 <kalev> let's do the Node.js thing next then
17:06:07 <kalev> #topic Node.js Change discussion
17:06:11 <kalev> sgallagh: go ahead
17:06:58 <sgallagh> OK, so we're in an unenviable position right now due to a lack of foresight and a serious CVE
17:07:21 <sgallagh> When we made the Node.js 4.x jump, we pulled in the latest LTS version of Node.js and the latest stable version of npm (at the time)
17:08:40 <sgallagh> However, there has been a very serious MITM bug fixed in NPM today, except that upstream only made releases that supports either the latest stable NPM available today or the bundled version that would have come with Node 4.x if we had used that one.
17:09:09 <sgallagh> So we're in the position of either downgrading NPM to the LTS version with the fix or upgrading Node.js to the latest stable release instead of the LTS release.
17:09:29 <nirik> how long are LTS releases vs non LTS support cycles?
17:09:31 <sgallagh> (Which would differ from the original Change Proposal, particularly since it involves a backwards-incompatible change)
17:10:01 <sgallagh> nirik: 4.x LTS is until April 2018
17:10:12 <sgallagh> 5.x is unspecified.
17:11:12 <nirik> IMHO the downgrade seems best... unless maintainers intend to follow the non LTS in each release...
17:11:31 <maxamillion> nirik: +1
17:11:42 <maxamillion> I hate to downgrade, but LTS on both seems safer long term
17:11:48 <kalev> I don't really know which option is best, but I think both make sense, depending on how the maintainers would like to go forward
17:12:06 <sgallagh> nirik: Well, the reason we went for the LTS version in F24 was so it would be easy to put into EPEL if we wanted to.
17:12:12 <nirik> kalev: yeah. moving up to 5 seems like a lot of short term work, then more work to keep going to 6, etc
17:12:15 <sgallagh> But for Fedora 25 we've already moved to 5.x
17:12:23 <kalev> probably makes sense in the future to keep NPM on an LTS release as well if we're keeping Node.js on LTS
17:12:45 <sgallagh> We've proven with Rawhide that there is only one package in our collection that is incompatible with 5.x vs. 4.x
17:13:04 <nirik> so, I guess I would be ok with either path... leaving it up to the maintainers since they are doing the work. I would suggest deciding really soon tho so we can get it done by beta freeze?
17:13:20 <sgallagh> nirik, kalev: I'm the maintainer :)
17:13:29 <kalev> how about the developer community, would they expect us to ship the latest version or the LTS one? I am pretty sure we can make the packages in the Fedora collection work either way, but how would 3rd parties want it?
17:13:33 <nirik> well, then... what would you prefer? ;)
17:13:33 <kalev> sgallagh: ahh good :)
17:14:19 <sgallagh> kalev: The Node SIG intends to keep up with the latest major release in Fedora except when backwards-incompatible changes hit
17:14:56 <sgallagh> We probably should have gone straight to 5.x in the first place, but we were holding out hope that someone would come along and want to maintain the EPEL version, so we were trying to make that minimally-difficult
17:15:11 <sgallagh> No one has (and I don't want to own it for that long)
17:15:52 <sgallagh> So I guess I'm slightly in favor of just jumping forward to 5.10
17:16:00 <sgallagh> Which I can probably have done before the end of next week
17:16:14 <maxamillion> ah
17:16:18 <sgallagh> (since it's basically just a backport from Rawhide and a couple minor changes)
17:16:33 <maxamillion> sgallagh: you're the one doing the work, I think it's mostly up to you :)
17:16:35 <nirik> ok. update the change too?
17:16:37 <sgallagh> I just don't love changing this after Alpha
17:16:57 <sgallagh> Yeah, if FESCo is okay with rewriting the Change this late, I'll make sure to update the page
17:17:17 <kalev> sure, we can rubber stamp it here
17:17:24 <paragan> good to update in the Change page
17:17:31 * nirik doesn't love it either, but hopefully it won't be too bad.
17:17:55 <kalev> proposal: Ship F24 with Node.js 5.x
17:18:04 <nirik> +1
17:18:05 <kalev> +1
17:18:09 <paragan> +1
17:18:29 <maxamillion> +1
17:18:44 <sgallagh> +1
17:18:47 <sgallagh> OK, thanks
17:18:49 <kalev> #agreed Ship F24 with Node.js 5.x
17:19:05 <kalev> ok, onwards!
17:19:07 <kalev> #topic #1562 drop exception to proven packager access to packages
17:19:12 <kalev> .fesco 1562
17:19:13 <zodbot> kalev: #1562 (drop exception to proven packager access to packages) – FESCo - https://fedorahosted.org/fesco/ticket/1562
17:20:08 <nirik> so where are we with this...
17:20:17 <paragan> I don't think we need any action here. What is written there in policy looks good.
17:20:24 <nirik> I guess to me it sounds like we should add things to the page instead of removing things. ;)
17:20:52 * zbyszek is OK with leaving things as they are if it is too complicated to simplify them
17:20:52 <nirik> or... we could try and ask 'special' packages to always include a note or tag ?
17:21:00 <nirik> (in their spec files)
17:21:25 <maxamillion> is it possible to query the package list that is closed off to provenpackagers?
17:21:33 <kalev> I am generally in favour of a open by default policy and trusting our maintainers
17:21:34 <paragan> yes this is also good that special packages should add not in spec file
17:21:39 <paragan> *note
17:21:56 <maxamillion> kalev: we are open by default, this is an exception to that
17:22:02 <nirik> maxamillion: not really, because packages are closed for different reasons
17:22:09 <kalev> not sure firefox needs to be closed off to provenpackagers, maybe a note would suffice
17:22:22 <maxamillion> nirik: oh
17:22:25 <nirik> and some aren't closed, but maintained elsewhere, so changes local to fedora will be poverwritten
17:22:45 <nirik> so to me it makes the most sense to make sure all those have a note in the spec...
17:23:12 <nirik> and have the policy say: look at the spec before you commit.
17:23:26 <sgallagh> Yeah, certainly anything like Anaconda or Cockpit that merges their spec files from upstream should have dire warnings in the spec
17:23:27 <maxamillion> yeah, that's fair
17:23:49 <sgallagh> As for Firefox, I think the concern is more around legality.
17:24:03 <sgallagh> Technically we only have permission to use their trademarks if we're using approved patches.
17:24:08 <nirik> yep.
17:24:20 <sgallagh> A provenpackager who doesn't understand that could get us into shaky legal ground.
17:24:32 <sgallagh> (Though I think Mozilla would be understanding if we just agreed to roll it back)
17:24:33 <nirik> Then there is also a set of packages that you can commit to, but cannot do official builds of...
17:24:43 <paragan> I think all such different reasons for different packages should be documented somewhere in fedora wiki
17:25:12 <kalev> yeah, dgilmore noted those in the ticket -- it's really weird when one can commit, but can't do builds. may be better to restrict commiting too in that case?
17:25:53 <nirik> we could I suppose sure.
17:25:55 <zbyszek> I don't think so. Sometimes you want to fix a typo and can wait for the next build without issue.
17:26:03 <kalev> true
17:26:50 <sgallagh> zbyszek: I think that's too edgy of a case to affect policy :)
17:27:03 <nirik> anyhow, how about this: we update the wiki page with the cases we know about, and send a email to devel-announce asking anyone who maintains their spec elsewhere to note it at the top of there spec and ask FPC to add that to guidelines.
17:27:12 <sgallagh> I think it's fair that one should not be able to commit if they cannot build
17:27:28 <sgallagh> They can always send their changes as a patch to a full maintainer
17:27:52 <paragan> nirik, +1
17:28:05 <maxamillion> nirik: +
17:28:08 <maxamillion> nirik: +1
17:28:23 <sgallagh> nirik: +1
17:28:32 <tibbs|w> BTW, isn't firefox restricted from modification by provenpackagers?
17:28:39 <nirik> it is
17:28:45 <maxamillion> tibbs|w: yes, that's in the ticket
17:29:02 <kalev> nirik: +1
17:29:31 <nirik> I can update the wiki page... anyone else want to do the other parts?
17:29:37 <kalev> it may be worth standardizing the note somehow so that automatic scripts can parse it
17:29:41 <nirik> I guess I can send email too
17:29:54 <nirik> so, perhaps we should go to FPC first...
17:30:03 <tibbs|w> Since I'm planning to modify 4000+ packages to remove useless %defattr at some point in the near future, I'm trying to pay attention herfe.
17:30:03 <kalev> like, if I have a script that does some trivial modification over all the package collection and commits + builds
17:30:06 <nirik> if they want to figure out the best way to implement that?
17:30:17 <kalev> right, what tibbs|w said :)
17:30:28 <nirik> # provenpackager: no
17:30:37 <nirik> # here is why
17:31:08 <maxamillion> nirik: +1 .. maybe all caps or something to make it a little more "in your face"
17:31:11 <nirik> or perhaps we should only have the specific reasons.
17:31:26 <nirik> to avoid someone just putting that because they don't like to play well with others.
17:32:59 <maxamillion> nirik: yeah, that's a good point ... should there be a pre-set list of "accepted reasons"?
17:33:01 <nirik> hum, so perhaps it is just easier to add them all to the no provenpackager thing... then commits just don't work and problem solved.
17:34:27 <nirik> but we don't really know the set of ones that are maintained elsewhere...
17:34:42 <tibbs|w> Back in the day, we determined that said flag was incredibly antisocial and we would use it only in extreme cases.
17:34:51 <kalev> in some cases, like anaconda where the spec file is maintained elsewhere -- adding it to the no provenpackager thing would break the workflow for anyone who needs to rebuild anaconda for soname bumps
17:35:06 <kalev> and for a trivial rebuild commit, it's totally fine if the spec file change gets overwritten later
17:35:23 <nirik> I suppose so
17:35:23 <kalev> but disabling commit would just make it impossible to do those kinds of rebuilds
17:35:36 <nirik> tibbs|w: yeah.
17:36:01 <nirik> so if we don't use that we are back to making a standard spec tag
17:36:23 <nirik> tibbs|w: would that be something FPC would be willing to draft/add? or should we try and come up with it here?
17:36:53 <tibbs|w> I can draft something.
17:37:03 <zbyszek> nirik: I think the spec tag that you can knowingly ignore is a much better solution. Just simpler for everybody.
17:37:16 <tibbs|w> Just make sure to file an FPC ticket.
17:37:36 <kalev> zbyszek: yeah, I am leaning that way as well
17:37:41 <tibbs|w> I'll have to re-read the fesco ticket and discussion here to make sure I know just is being requested here.
17:38:00 <kalev> zbyszek: want to file the FPC ticket?
17:38:28 <tibbs|w> Personally I'm of the opinion that nobody should be so antisocial as to restrict commits in this way, so without clear guidance I'm obviously going to lean that way when drafting something.
17:38:32 <zbyszek> kalev: OK
17:38:49 <kalev> zbyszek: great, thanks.
17:39:00 <nirik> tibbs|w: we have 3 reasons currently... 1) trademark (firefox, xulrunner)
17:39:24 <nirik> 2) some packages that need secure boot (kernel, shim, grub2) we don't want anyone doing official builds of
17:39:45 <nirik> 3) some packages maintain their spec upstream and just overwrite any local fedora changes. Changes there should be coordinated with them
17:40:12 <sgallagh> 3) Includes Anaconda, Cockpit, fedora-release and fedora-repos
17:40:17 <kalev> 3) is where a note makes most sense I think
17:40:22 <sgallagh> Probably other rel-eng things
17:40:38 <kalev> not sure fedora-release and fedora-repos should be in the secure boot channel though
17:40:47 <nirik> I suppose we could drop the perm thing for 1 and add it to the place in koji where 2 is... so those cases collapse into 'commit, but it won't tag your build)
17:40:50 <pjones> I'd like to point out that I think #3 is often reflective of bad process; making a new package version for upstream should most often be a read-modify-write cycle that imports the changes back in to upstream.
17:41:07 <tibbs|w> pjones: I agree.
17:41:13 <pjones> that's not to say it isn't unavoidable in some cases, but I think it's overused.
17:41:33 * nirik nods. agree also, but it's easier to just overwrite so thats what most places do
17:42:14 <pjones> kalev: I don't think they should - at one point we intended to use them to solve part of bz#998, and that meant they'd need to be built on the kernel builders.  But we never implemented that, so they could easily be moved back out.
17:42:25 * kalev nods.
17:42:57 <maxamillion> is there anything else needed on this? more discussion? should we table?
17:43:03 * maxamillion has to leave at the hour
17:43:03 <pjones> I also don't think the rel-eng role should magically get you the ability to build packages that do have strong restrictions, fwiw :)
17:43:06 <paragan> its 20 min already
17:43:15 <maxamillion> and if I leave, we lose quarum
17:43:22 <kalev> I need to leave at the hour as well
17:43:27 <pjones> (But that's a harder problem.)
17:43:48 * nirik notes he doesn't have perms to build those things, but then I have perms to grant myself the perms
17:44:03 <nirik> anyhow, lets wait for a FPC ticket and some feedback and revisit?
17:44:07 <maxamillion> nirik: +1
17:44:15 <kalev> I would be fine with moving firefox and xulrunner to a koji channel that provenpackagers can't use so builds don't get tagged, + add a note in the spec file
17:45:00 <kalev> I think maintainers review other people's commits anyway and if the other people can't do builds, it should give them time to review those changes
17:45:17 <nirik> in practice I don't think it happens that often.
17:45:24 * kalev nods.
17:45:32 <paragan> right
17:45:46 <kalev> ok, zbyszek when you file the FPC ticket, can you link it in the fesco ticket as well, please?
17:46:11 <kalev> let's move on then
17:46:38 <zbyszek> of course
17:46:41 <kalev> #action zbyszek to file an FPC ticket for special package handling
17:46:48 * nirik wont do anything with the wiki page and announce yet then...
17:47:14 <kalev> yeah, let's wait for the FPC ticket and see how this goes first
17:47:16 <kalev> #topic #1563 "Rich Dependencies" vs. DNF vs. YUM issues
17:47:21 <kalev> .fesco 1563
17:47:24 <zodbot> kalev: #1563 ("Rich Dependencies" vs. DNF vs. YUM issues) – FESCo - https://fedorahosted.org/fesco/ticket/1563
17:47:54 <nirik> hard to know what actions are desired here...
17:47:55 <kalev> not sure there's anything for us to do here
17:47:59 <paragan> I think dnf developers are ready to accept the requests or patches. its just that report issues/patches to them
17:48:10 <nirik> but there's one thing: rich deps with Requires/Recommends.
17:48:19 <sgallagh> nirik: The only way I can read any of this is "We don't want to use DNF, so add every DNF feature back to yum"
17:48:22 <nirik> we should forbid those for now.
17:48:22 <kalev> let's just close the ticket and I'll thank the reporter for pointing those issues out when I close it?
17:48:36 <kalev> nirik: ahh yes, because of mash, right?
17:48:42 <nirik> yeah.
17:49:02 <nirik> we cannot currently push any updates where there are rich Requires/Recommends in the set of updates.
17:49:12 * nirik is currently trying to figure out where one more is.
17:49:15 <sgallagh> nirik: Forbidding rich deps for Requires: completely breaks the langpack feature, doesn't it?
17:49:28 <nirik> sgallagh: I don't think so? but could be wrong.
17:49:33 <tibbs|w> I'm really sorry FPC moved ahead with the langpacks thing and allowing these deps.  We really thought it was all good to go now.
17:49:49 <sgallagh> #link https://fedoraproject.org/wiki/Packaging:Langpacks
17:49:57 <sgallagh> Ah, you're right
17:49:58 <tibbs|w> And of course our testing showed that dnf and such handled everything fine.
17:50:02 <sgallagh> That only uses "Supplements"
17:50:03 <kalev> it turns out mash is still yum based and breaks when it sees those deps
17:50:06 <sgallagh> Which would be ignored
17:50:07 <paragan> langpacks uses weakdeps Supplement tag
17:50:26 <nirik> but anaconda was hoping to use them for the langpacks feature... ;(
17:50:40 <sgallagh> nirik: Do you have a link to their exact usaeg?
17:50:42 <sgallagh> *usage
17:51:19 <nirik> Requires: (glibc-langpack-en or glibc-all-langpacks)
17:51:28 <sgallagh> Ah, right. That.
17:51:42 <sgallagh> OK, I think we can solve that pretty easily.
17:51:51 <nirik> well, they can just require en I guess.
17:52:49 <sgallagh> I think the side-effect there is that every system ends up with *at least* en_US, but that's probably acceptable
17:53:19 <kalev> sounds acceptable to me
17:53:33 <sgallagh> (and the installed system will have both glibc-langpack-en and glibc-all-langpacks which looks odd but is completely valid)
17:53:49 <nirik> why would it have all?
17:54:06 <sgallagh> IIRC, that's a workaround for the fact that the UI doesn't have language pack selection today.
17:54:16 <sgallagh> But that may have changed; my information is pre-Alpha
17:54:56 <nirik> anyhow, should we send out something about not using these? or wait for FPC to send something or ?
17:55:13 <kalev> I think it makes sense to send out something if it's breaking composes
17:55:24 <paragan> anyone knows how many releng tools are remaining to migrate from using yum to dnf?
17:55:50 <nirik> mash at least, I think dennis said pungi still uses yum someplaces
17:56:24 <paragan> ok
17:56:30 <kalev> proposal: Avoid rich deps for now as our compose tools can't handle it
17:56:47 <paragan> but how are we going to achieve this?
17:56:48 <nirik> well, should we say all rich deps? or just Requires and Recommends?
17:57:02 <nirik> if we say all, glibc will have to redo the suggests stuff
17:57:03 <sgallagh> kalev: Too broad
17:57:08 <kalev> I don't know, just those that break composes :)
17:57:11 <maxamillion> I wish dgilmore was here, he would have better perspective on the status of the tooling port work
17:58:05 <sgallagh> Proposal: FESCo bans the use of "rich deps" ('and' and 'or') from use in Requires: or Recommends: in Fedora 25 due to bugs in rel-eng tools
17:58:13 <sgallagh> err, Fedora 24
17:58:24 <maxamillion> bugs?
17:58:38 <nirik> tooling issues?
17:58:51 <sgallagh> Fine, whichever
17:58:59 <maxamillion> bugs just seems misleading
17:59:02 <sgallagh> Proposal: FESCo bans the use of "rich deps" ('and' and 'or') from use in Requires: or Recommends: in Fedora 24 due to rel-eng tooling issues
17:59:20 <sgallagh> maxamillion: Well, the tools don't properly support the RPM features and crash... that's a bug in my definition
17:59:27 <kalev> should it say "Fedora 24" there? doesn't it break rawhide as well?
17:59:28 <zbyszek> incomplete support in rel-eng tools?
17:59:52 <maxamillion> sgallagh: RPM added a new feature and not everything has added support for that new feature ... is that a bug?
18:00:23 <nirik> kalev: it doesn't seem to I don't think...
18:00:30 <sgallagh> kalev: I'd like for us to strongly suggest that this be fixed for F25. That's why I specified only F24
18:00:38 <nirik> pungi seems to handle it, but I am not 100% sure thats the case
18:00:45 <maxamillion> sgallagh: because by that definition, everything that doesn't run on python3 that is written in python has a giant bug
18:01:06 <sgallagh> maxamillion: Oh good, so you agree with me, then :-P
18:01:24 <maxamillion> sgallagh: I'm game, why not
18:01:39 <kalev> anyway, let's ban this for F24 now as this is what's breaking composes
18:01:45 <kalev> can always revisit it for F25
18:02:00 <maxamillion> I really need to leave, but if I do then we lose quarum ... do we want to make this decision today or do we want/need any more information and should table it?
18:02:11 <sgallagh> I'll talk with the glibc folks about possibly arranging a virtual provides solution for anaconda to use to make sure they have EN available
18:02:22 <kalev> I think nirik has been having trouble pushing updates out due to this, so we need to take immediate action I'd say
18:02:39 <nirik> yeah, if we can agree on f24 at least...
18:02:40 <kalev> +1 to sgallagh's proposal above
18:02:46 <sgallagh> I didn't hear any objection to banning for F24 at least
18:02:52 <jsilhan> https://bugzilla.redhat.com/show_bug.cgi?id=1156546 they should have migrated it to DNF. New Pungi uses DNF and will probably replace mash. But it still not in production. Can we postpone it to wait for Dennis input? we can probably still port mash
18:03:19 <maxamillion> jsilhan: +1
18:03:20 <kalev> we need to push out updates in the mean time while mash is being ported though
18:03:31 <kalev> otherwise no security fixes are going out ...
18:03:34 <nirik> well, "they" have a lot of things going on...
18:03:43 <maxamillion> kalev: yeah, fair
18:03:45 <maxamillion> hrm
18:04:03 <nirik> right, if we can port mash that would be great.
18:04:10 <nirik> but in the mean time, I suspect people may want updates.
18:04:25 <maxamillion> yeah ... +1 sgallagh's proposal
18:04:42 <nirik> so yeah, +1 for now, if we can get mash moved we can remove the injuction.
18:04:45 <paragan> so no f24 updates at all can be pushed because of this mash bug?
18:04:49 <kalev> yeah
18:05:00 <nirik> paragan: right.
18:05:04 <paragan> oh
18:05:17 <nirik> it doesn't even tell me which package is to blame.
18:05:21 <nirik> I have to try and find them
18:07:09 <kalev> paragan: missing your vote
18:07:31 <paragan> I still don't understand banning rich deps, how can it help here
18:07:50 <paragan> are we going to ask all such package owners to drop rich deps?
18:08:19 <nirik> for f24 yes in requires and recommends
18:08:23 <kalev> paragan: pushing out updates uses a thing called "mash", which uses yum which in turn tracebacks when it sees rich deps. because of that, rich deps == no updates going out
18:08:47 <paragan> if that is the way to achieve this then okay
18:08:50 <nirik> it's only the boolean and/or that confuses it.
18:08:51 <paragan> +1 to ban
18:09:11 <nirik> well, I don't want to. I'd love to fix it... but we can only do so much without a fix in hand.
18:09:23 <maxamillion> nirik: +1
18:09:35 <kalev> yeah, I am sure everyone sees it that way :)
18:09:37 <kalev> #agreed FESCo bans the use of "rich deps" ('and' and 'or') from use in Requires: or Recommends: in Fedora 24 due to rel-eng tooling issues (+1:5, 0:0, -1:0)
18:09:50 <kalev> ok, as maxamillion's and my time is over, let's wrap this up
18:10:02 <maxamillion> kalev: +1
18:10:10 <kalev> #topic Next week's chair
18:10:18 <kalev> who wants to chair next week?
18:10:32 <kalev> I'll be travelling and not sure I can attend next week
18:10:39 <paragan> I will
18:10:52 <kalev> #info paragan to chair next week
18:10:53 <kalev> thanks paragan
18:10:57 <kalev> #topic Open Floor
18:11:34 <kalev> I'll close out in a minute if there's nothing
18:11:41 <maxamillion> kalev: +1
18:11:41 <kalev> thanks for coming everybody
18:11:50 <maxamillion> kalev: thanks for hosting!
18:12:13 <kalev> #endmeeting