17:00:29 <geppetto> #startmeeting fpc
17:00:29 <zodbot> Meeting started Thu Nov  9 17:00:29 2017 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:29 <zodbot> The meeting name has been set to 'fpc'
17:00:29 <geppetto> #meetingname fpc
17:00:29 <geppetto> #topic Roll Call
17:00:29 <zodbot> The meeting name has been set to 'fpc'
17:00:37 <mbooth> Hola
17:00:39 <tibbs> Hey, folks.
17:00:50 * limburgher here
17:00:54 <orionp> hello
17:01:20 <geppetto> #chair tibbs
17:01:20 <zodbot> Current chairs: geppetto tibbs
17:01:23 <geppetto> #chair orionp
17:01:23 <zodbot> Current chairs: geppetto orionp tibbs
17:01:27 <geppetto> #chair limburgher
17:01:28 <zodbot> Current chairs: geppetto limburgher orionp tibbs
17:01:33 <geppetto> #chair mbooth
17:01:33 <zodbot> Current chairs: geppetto limburgher mbooth orionp tibbs
17:04:14 <geppetto> #topic #720 Easy way of changing/removing shebangs
17:04:16 <geppetto> .fpc 720
17:04:17 <zodbot> geppetto: Issue #720: Easy way of changing/removing shebangs - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/720
17:04:32 <tibbs> So I like the idea of having macros like this, and think we should have more of them.
17:04:54 <tibbs> But it's all down to bikeshedding, and in this case may not be needed anyway.
17:05:48 <tibbs> It's possible to do this automagically in RPM via a brp script and a tweak of %__os_install_post, and a commit to do that was sent upstream.
17:05:54 <tibbs> I don't know what's happening with it, though.
17:05:57 <geppetto> Yeh, we didn't get a real draft … and I forgot to move it to followups
17:06:11 <geppetto> my bad … let's move on
17:06:13 <tibbs> ignatenkobrain might be able to tell us what happened with that.
17:06:27 <geppetto> #topic #723 Guidelines for handling deprecated dependencies during review
17:06:27 <tibbs> Honestly I don't think this even needs a draft.
17:06:30 <geppetto> .fpc 723
17:06:31 <zodbot> geppetto: Issue #723: Guidelines for handling deprecated dependencies during review - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/723
17:06:47 <ignatenkobrain> tibbs: still waiting for feedback from upstream and would be good to get one from you ;)
17:06:53 <geppetto> #chair racor
17:06:53 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor tibbs
17:06:58 <ignatenkobrain> this would simplify of packagers a lot
17:07:07 <ignatenkobrain> life*
17:07:09 <geppetto> tibbs: We can come back to it if you have a proposal you want to vote on?
17:07:26 <tibbs> No, let's move on.
17:07:51 <limburgher> Looks great.
17:07:54 <tibbs> I just like convenience macros, and if RPM will just take care of it without anyone caring, then that's even better.
17:08:50 * geppetto nods
17:08:57 <tibbs> As for 723, well, I was not really sure which part of the "draft" was actually the draft.  I guess just the last sentence.
17:09:19 <geppetto> I'm happy with a simple "provides: deprecated-package" or whatever for 723
17:09:21 <tibbs> But I don't like the idea of telling people to do something when there's no reasonable way for them to know if they've actually done it.
17:09:57 <tibbs> And this isn't about reviews anyway.
17:10:35 <tibbs> It's just that we have a window between deprecation and removal where you don't want any new dependencies to show up.
17:10:52 <tibbs> So, first question is how on earth someone is supposed to know a package is deprecated?
17:11:26 <limburgher> A list on the wiki?
17:11:29 * limburgher ducks
17:11:45 <tibbs> Is there any issue with multiple things providing "deprecated-package"?
17:12:25 <tibbs> We tend to abuse dependencies for random metadata.  I wonder if RPM gives a place to hang things like that which we're not utilizing.
17:12:53 <tibbs> And even if it did, that would have to trickle down to something dnf repoquery can inspect.
17:13:47 <mbooth> I'm not sure why there should be a window between deprecation and removal -- just remove package from rawhide and be done with it. Packagers should be scratch-building against rawhide anyway and will see that a dep disappeared there
17:13:59 * mbooth shrugs
17:14:11 <tibbs> Well, the idea is that end users might still need the thing, but we still don't want other packages to depend on it.
17:14:49 <limburgher> Yeah, Ideally, what mbooth said, but that won't be all cases. I wish it was because just checking for dead.package would be simpler.
17:15:13 <tibbs> The road to deprecation can often take many years.  Still doesn't mean you want new things starting to use the stuff.
17:15:49 <geppetto> Eh, if deprecation is going to take years I'm not sure I want review failures because people are depending on it
17:16:22 <tibbs> So, bikeshed time: Provides: deprecated-package, Provides: deprecated(%name), some other provides, or something not involving Provides: at all?
17:16:54 <geppetto> I was thinking more like you are trying to do an "orderly" deprecation over a few weeks/months
17:17:20 <tibbs> geppetto: Well, in this case FESCo has approved the deprecation and all, so I'm just looking at the way to implement that reasonably.
17:17:46 <geppetto> I'm not sure how useful it will be to have deprecated(%name)
17:17:46 <tibbs> And personally I have no problems with having packages in the distribution which other packages can't depend upon.
17:18:18 <geppetto> Yeh, that's fair enough
17:18:19 <tibbs> Since we have *-static (which until recently required committee approval to use) and the weird versioned python interpreter thing.
17:18:46 <mbooth> Well, is this a real-world problem? It seems entirely notional to me. Has there been a case where a new package was introduced that requires net-tools?
17:18:54 <geppetto> Do we want something more general then "provides: leaf-only" ?
17:19:22 <tibbs> mbooth: That was kind of my question, but I assume there's a real world example or the ticket wouldn't have been opened.
17:19:28 <geppetto> mbooth: I kind of hope that's what triggered the ticket and not just doing it randomly
17:20:11 <mbooth> Ticket says "but I'm concerned that future packages may sneak it back in" ... no concrete example
17:20:19 <mbooth> It's just a "concern"
17:20:20 <tibbs> I don't think jhogarth is on IRC often.
17:20:22 * geppetto sighs
17:20:50 <tibbs> I'm happy to punt if it's just a "concern" but honestly I don't think it's a bad idea to have some metadata for this.
17:21:21 <tibbs> Since the end user might also like to have a way to know if a particular package is in some way deprecated.
17:21:54 <tibbs> I don't know if the modular SLA stuff can work for that, really, since it kind of answers a different question.
17:22:01 <mbooth> More metadata for people to ignore :-) This should come with fedora-review or lint rules that checks a package's deps for deprecated packages
17:22:03 <gholms> That info isn't doable with SLAs, is it?
17:22:08 <gholms> Bah, ninja'd
17:24:20 <geppetto> I mean if everything was in modules you could probably use the SLA or API parts of modules to solve it
17:24:33 <geppetto> But back to the world we are currently living in …
17:25:49 <geppetto> Just adding a simple provide for deprecated packages seems like we'll solve 98% of the problem at least.
17:25:51 <tibbs> Anyway, if there's concensus that Provides: deprecated-package is generally useful and that it wouldn't hurt to have a "SHOULD NOT depend on deprecated packages" rule, then I can write that up.
17:26:00 <geppetto> yeh
17:26:01 <geppetto> +1
17:26:13 <racor> -1
17:26:18 <tibbs> +1
17:26:55 <tibbs> Won't take me but a few minutes to write up anyway.
17:27:23 <geppetto> racor: Do you want to talk about your concerns, or propose something different?
17:27:46 <geppetto> mbooth: limburgher vote?
17:28:06 <racor> To me, this all is bureaucratic featuritis
17:28:07 <geppetto> orionp: You too :)
17:28:08 <tibbs> Well, not really a vote, but if people have objections to it then I'll save my time.
17:28:30 * geppetto nods
17:28:35 <tibbs> It is bureaucratic, and mostly pointless, but FESCo seems to have embraced the concept of "deprecated package".
17:28:44 <racor> deprecation isn't planable it just happens
17:29:02 <racor> undeprecation, also happens
17:29:05 <tibbs> Well that statement doesn't represent the reality of what's happening with net-tools.
17:29:27 <tibbs> Fortunately deletion of Provides: foo from the spec can also happen, so the undeprecation case is covered, too.
17:30:09 <racor> net-tools actually is a trivial case, similar to many, we've had throughout the last >10 years.
17:31:09 <tibbs> To be honest I don't know why this is such a big deal, But the "solution" on our end seems trivial, too.
17:31:32 <tibbs> Anyway, if there's no consensus then we should move on.
17:31:53 <tibbs> If I have a few minutes I'll just add a quick proposal to the ticket.
17:31:57 <limburgher> +1
17:32:01 <limburgher> Sorry.
17:32:15 <geppetto> mbooth: orionp: Any comments?
17:32:26 <racor> tibbs: may-be I am missing something, but which aspect does "Provides deprecated" actually solve? I don't see any.
17:32:44 <tibbs> racor: How do you know if a package is deprecated?
17:32:59 <geppetto> racor: the aspect of being able to notify other packages that something is deprecated before it happens
17:33:12 <orionp> not really.  I'm +1
17:33:14 <mbooth> geppetto: As I say, I prefer the "obsolete it and just fix usages using a provenpackager" approach, which completely obviates the problem
17:33:14 <tibbs> The submitted draft talks about searching bugzilla and such.  But bugzilla is a pretty terrible place to put RPM metadata.
17:33:26 <racor> tibbs: you don't need to know this. It's maintainers need to chase down all use-cases.
17:34:04 <tibbs> Well, the problem raised in the ticket which we're discussing is that new packages can enter the distribution in the interim.
17:34:19 <tibbs> So the maintainers can't chase down a use case which doesn't actually exist in the distribution at the time.
17:34:45 <mbooth> IMHO it's an imagined problem, until I'm shown otherwise
17:35:13 <tibbs> I don't disagree, but I don't object to working in theory.
17:35:39 <tibbs> I can certainly understand the objections.  I kind of object to spending 30 minutes of meeting time on it.
17:35:53 <mbooth> And you're usually so against unnecessarily bloating the guidelines :-)
17:35:57 <mbooth> Let's move on then
17:36:16 <geppetto> #topic #726 Review for SELinux Independent Policy packaging Draft
17:36:21 <geppetto> .fpc 726
17:36:22 <zodbot> geppetto: Issue #726: Review for SELinux Independent Policy packaging Draft - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/726
17:38:01 <tibbs> So the selinux folks actually put up a "guideline" document some time ago.  When I saw it I agitated for it to be made a real guideline (and added that "Not official" thing at the top).  After some time it's now come to us.
17:38:34 <tibbs> I agree that we really, really need this.  But sadly I haven't had enough time to review it properly.
17:38:45 <limburgher> How does End-User determine whether a problem is with the rpm policy or the distro policy?
17:38:56 <tibbs> I don't think they can easily.
17:39:37 <limburgher> Ok. Bummer, but I still see value in this draft.
17:39:40 <tibbs> I do think the draft needs a lot of work.
17:39:56 <tibbs> I mean, we don't need to tell people how to create a github repository.
17:41:00 <tibbs> So what's there needs to be distilled down to "here's what you put in your package".
17:41:21 <limburgher> Agreed.
17:41:22 <tibbs> They can have a separate tutorial document for how to actually maintain policies.
17:42:25 <tibbs> The guidelines can include stuff about how policies should be structured, I guess, so that they interface properly with the distribution policy, but I don't know if that kind of thing is ever a concern.
17:42:40 <tibbs> In any case, the "creating the specfile" section is where we want to be looking.
17:43:10 <tibbs> But it seems to me that most of these "foo-selinux" packages will be subpackages of something else, and that it would be better to reflect that.
17:43:29 <geppetto> Yeh, I feel like the packager side should be "take this blob and put it in your package"
17:43:33 <tibbs> The document as written assumes that they will be completely separate packages.
17:43:42 <limburgher> geppetto ^^^^ Yes
17:44:03 <tibbs> I don't know which way makes more sense, really.  It might be context-dependent.  But which will be the more common case?
17:44:41 <tibbs> I mean, I wouldn't call a selinux policy a "separate upstream project" but maybe I'm thinking about it the wrong way.
17:44:51 <geppetto> yeh, maybe
17:45:20 <geppetto> I mean, I can certainly see it from that POV from the packager
17:45:24 <limburgher> Does the draft address when a packager would want to ship a policy rather than send upstream?
17:45:25 <ignatenkobrain> one thing I would like to see is file triggers
17:45:36 <ignatenkobrain> would simplify packaging selinux policies
17:46:19 <geppetto> ignatenkobrain: My guess is that they'd need your help to change to use them
17:46:21 <tibbs> I have no idea how that would even work.
17:46:49 <geppetto> I guess you'd drop the selinux policy files in a specific place and they'd be a filetrigger on that dir.
17:47:26 <tibbs> But if packaging comes down to "drop this file in place and the rest happens magically" then great.
17:48:03 * geppetto nods
17:50:13 <ignatenkobrain> tibbs: isn't that what we are aiming for? ;)
17:50:38 <tibbs> Well it would be nice.  But we recognize our limitations.
17:51:00 <tibbs> So I guess what I need to do is take this thing apart and try to extract the parts that are actually packaging guidelines.
17:51:09 <limburgher> As part of a system to automate the design, composition, distribution, packaging, and use of all software, yes. :)
17:51:49 <ignatenkobrain> limburgher: :D
17:51:57 <limburgher> I just hope it doesn't file bugs on itself or fedpkg retire us.
17:52:21 <ignatenkobrain> it would give you to `orphan` user
17:52:35 <limburgher> i would be so lonely
17:52:49 * limburgher feels small and cold
17:53:42 <tibbs> So, I guess I can add that to my list and we can move on.
17:54:01 <ignatenkobrain> I wonder if we can discuss my issue now-ish
17:54:08 <ignatenkobrain> because I will need to leave in 20 mins
17:54:15 <tibbs> Yeah, can we touch on the rich deps thing?
17:54:26 <ignatenkobrain> https://pagure.io/packaging-committee/issue/724
17:54:29 <ignatenkobrain> yeah
17:54:42 <ignatenkobrain> tibbs: with **new** rich deps thing ;)
17:54:46 <ignatenkobrain> it's quite different from just rich deps thing
17:55:51 <tibbs> Let's wait for geppetto to move the topic on.
17:56:54 <geppetto> #topic Open Floor
17:57:08 <tibbs> So basically the rich deps thing is a quagmire.
17:57:16 <geppetto> That's the new tickets, and we only have a couple of minutes left …
17:57:24 * ignatenkobrain googles that word, never heard about it
17:57:35 <geppetto> Has the ticket moved?
17:57:39 <tibbs> A muddy swamp that you get stuck in.
17:57:41 <geppetto> ignatenkobrain: think swamp
17:57:44 <tibbs> This is 724.
17:57:45 <ignatenkobrain> ah
17:57:50 <limburgher> ignatenkobrain like the Vietnam conflict for the U.S.
17:58:03 <limburgher> or subsequent discussion of same. ;)
17:58:21 <tibbs> So Fedora upgrades are done with the RPM from the old OS release, not the new one.
17:58:32 <geppetto> is that true anymore?
17:58:35 <tibbs> Which means that F26 RPM has to understand everything in the new F27 RPMs.
17:58:36 <ignatenkobrain> so tl;dr there is problem with upgradepath from F25/F26 -> F27+ if packages from F27+ started to use new rich deps (and they are not supported by F25/F26)
17:58:46 <limburgher> I thought that had been changed some time ago.
17:59:00 <geppetto> If you use system-upgrade it uses the new one AIUI
17:59:09 <tibbs> I'm not entirely sure of that.
17:59:16 <tibbs> Would want confirmation regardless.
17:59:21 <limburgher> If you do it manually with bash and cpio you're on your own.
17:59:21 <ignatenkobrain> tibbs: or dnf just pass --nodeps to RPM and no prblems
17:59:31 <ignatenkobrain> geppetto: no, it uses old RPM
17:59:38 <ignatenkobrain> system-upgrade just reboots to safer env
17:59:39 <limburgher> Fuuuuuuuuuuuuuuuuuuuuuuuuuuuu
17:59:42 <limburgher> etc.
17:59:42 <ignatenkobrain> nothing more, really
17:59:56 <geppetto> Wow, I assumed it had fixed that problem too
17:59:59 <tibbs> And I asked about this, but everyone answered from a releng perspective.
18:00:01 <geppetto> Oh well
18:00:12 <tibbs> And rpm is not onboard with backporting the new stuff.
18:00:20 <jkurik> Hi, I am sorry for disturbing, but we have Go/No-Go meeting on this channel starting now :-)
18:00:23 <limburgher> Which I totally get.
18:00:29 <limburgher> So we should Go. :)
18:00:36 <tibbs> So... we support F25->F27 upgrades, which means that we have to ban rich deps again.
18:00:38 <ignatenkobrain> no excuses!
18:00:47 <ignatenkobrain> tibbs: or we can limit set
18:00:55 <tibbs> Except for packages which only exist in F27+.
18:01:04 <ignatenkobrain> and only new richops, not old ones
18:01:08 <mboddu> .next
18:01:13 <tibbs> Anyway, we have to stop.
18:01:16 <ignatenkobrain> =)
18:01:22 <geppetto> jkurik: Yeh, will be 1 minute or so
18:01:22 <limburgher> Bye all, and thanks!
18:01:23 <ignatenkobrain> tibbs: let's talk about it on #fedora-devel
18:01:36 <geppetto> Ok, thanks for coming everyone
18:01:37 * mboddu sorry, wrong channel
18:01:46 <geppetto> #endmeeting