16:00:07 <geppetto> #startmeeting fpc
16:00:07 <zodbot> Meeting started Thu Sep 27 16:00:07 2018 UTC.
16:00:07 <zodbot> This meeting is logged and archived in a public location.
16:00:07 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:07 <zodbot> The meeting name has been set to 'fpc'
16:00:08 <geppetto> #meetingname fpc
16:00:08 <zodbot> The meeting name has been set to 'fpc'
16:00:08 <geppetto> #topic Roll Call
16:00:14 * limburgher here
16:00:15 <tibbs> Hello.
16:00:26 * decathorpe says hello
16:00:32 <geppetto> #chair limburgher
16:00:32 <zodbot> Current chairs: geppetto limburgher
16:00:38 <geppetto> #chair tibbs
16:00:38 <zodbot> Current chairs: geppetto limburgher tibbs
16:00:38 <tibbs> limburgher: While we're in init, did you see the issue with SCM request processing?
16:00:40 <mhroncok> hi
16:00:42 <geppetto> #chair decathorpe
16:00:42 <zodbot> Current chairs: decathorpe geppetto limburgher tibbs
16:01:17 <tibbs> limburgher: Basically I don't understand why I can create F29 branches fine, but the tool just auto-closes the requests when you run it.
16:03:09 <ignatenkobrain> .hello2
16:03:10 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:03:15 <geppetto> #chair ignatenkobrain
16:03:15 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher tibbs
16:03:40 * mhroncok has some internet torubles. not sure if it works at all
16:03:51 <redi> hi
16:04:22 <ignatenkobrain> I have some inet connectivity problems too, so might take a while before I reply
16:04:37 <ignatenkobrain> #chair mhroncok
16:04:37 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok tibbs
16:05:28 <decathorpe> #chair redi
16:05:28 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain limburgher mhroncok redi tibbs
16:05:50 <geppetto> Ok, 5 past … and only missed 2 people ;)
16:06:13 <geppetto> #topic Schedule
16:06:15 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/CLIG7B6RWI2D6LDIDIIJD345PJ2Y2RUI/
16:06:27 <geppetto> #topic #795 Nice diffs in git-based guidelines
16:06:30 <geppetto> .fpc 795
16:06:31 <zodbot> geppetto: Issue #795: Nice diffs in git-based guidelines - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/795
16:07:08 <ignatenkobrain> PROPOSAL: use Semantic Breaks for our guidelines code
16:07:16 <mhroncok> +1
16:07:35 <tibbs> Might as well.
16:07:54 <tibbs> Though... does that mean someone's going to do that for the existing pages?
16:07:56 <decathorpe> well, +1, but I don't see anyone rewriting all guideline text for this. so ... realistically, it will updated over time?
16:08:05 <geppetto> sure +1
16:08:25 <redi> definitely +1 from me
16:08:29 <tibbs> Really I think this is up to the person doing the typing. We have never really cared about what the unformatted wiki pages looked like.
16:08:32 <geppetto> redi: is it possible to auto convert?
16:08:42 <redi> I doubt it, not easily
16:08:55 <redi> imho there's no need to change existing pages, just use it going forward
16:09:08 <limburgher> +1
16:09:20 <redi> when editing a paragraph, reformat it to break at periods and commas
16:09:30 * geppetto nods
16:09:34 <decathorpe> sounds good
16:09:41 <tibbs> The problem is that if people do that as part of other changes, then the diff is even less useful.
16:09:52 <redi> then the next time someone edits that para, it'll be a smaller diff
16:09:59 <redi> yeah maybe
16:10:05 <ignatenkobrain> tibbs: geppetto redi let's do it on the way
16:10:14 <ignatenkobrain> When touching some part, just convert that part
16:10:18 <redi> you don't have to do the whole paragraph even
16:10:21 <tibbs> You need convert before or after changing something, as separate commits.
16:10:36 * geppetto nods
16:10:42 <redi> why?
16:11:01 <geppetto> redi: otherwise it's noise for the commit itself
16:11:01 <tibbs> Because otherwise the diff is useless.
16:11:06 <redi> if you're only changing one word, then sure, splitting at semantic breaks makes a larger diff
16:11:13 <redi> but that's not always going to be the case
16:11:27 <geppetto> tibbs: Was your "might as well" a +1 ?
16:11:39 <redi> if you're rewriting a whole paragraph anyway, where you put the line breaks doesn't make the diff any worse
16:11:43 <tibbs> Sure, I mean, I'll hit enter when I feel I need to regardless of whether we pass this or not.
16:11:49 <redi> :)
16:12:16 <redi> it doesn't need to be a MUST, but it's good if everybody knows the convention, and keeps it in mind
16:12:45 <redi> I won't be asking anybody to re-edit pages if they forget to insert semantic breaks
16:13:10 <mhroncok> that works for me. I don't think bikeshedding about line breaks is a good thing, when the guidelines look as they do (i.e. not allright)
16:13:46 <mhroncok> the first priority should be: make it work, switch from wiki altogether, get things running
16:13:48 <redi> :)
16:13:51 <redi> yeah
16:13:53 <mhroncok> and then we can bikeshed about linebreaks
16:14:05 <mhroncok> (all day long)
16:14:42 <redi> I can't wait ;)
16:14:54 <geppetto> tibbs: Was your "might as well" a +1 ?
16:15:00 <tibbs> Sure, +1.
16:15:08 <geppetto> #action use Semantic Breaks for our guidelines code (+1:7, 0:0, -1:0)
16:15:36 <geppetto> #topic #667 Recommend use of systemd sandboxing directives
16:15:39 <geppetto> .fpc 667
16:15:40 <zodbot> geppetto: Issue #667: Recommend use of systemd sandboxing directives - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/667
16:15:58 <geppetto> ignatenkobrain: You pinged this for the meeting
16:16:28 <geppetto> Kind of responding to Matt's ping, I guess
16:17:07 <tibbs> Have things changed since my initial comment?
16:17:22 <geppetto> FESCo approved: https://fedoraproject.org/wiki/User:Zbyszek/ProtectionsPolicyDraft#Proposed_FESCo_decision
16:17:37 <tibbs> Ah, OK.
16:17:38 <geppetto> IIUC
16:18:03 <ignatenkobrain> Just wanted to ask what's the status of it
16:18:52 <tibbs> You wanted to ask FPC or someone else?
16:19:05 <tibbs> I guess this is the draft under consideration: https://fedoraproject.org/wiki/User:Zbyszek/ProtectionsPolicyDraft
16:19:40 <tibbs> I would really prefer that we not put all of that documentation into packaging guidelies.
16:19:48 <tibbs> Or even guidelines.
16:19:57 <tibbs> Though guidelies has a certain ring to it.
16:20:34 <tibbs> So maybe just the "proposed fesco decision" part is what they want us to put into the guidelines.
16:21:26 <redi> that last part seems reasonable to me. I bet there are loads of packages currently not following them, but the "guidelies" do seem ok
16:21:27 <mhroncok> having somehere to link for the firt part woud be fgood
16:21:29 <geppetto> tibbs: yeh, I think so
16:22:04 <tibbs> All of those are documented in the systemd.exec manpage, aren't they?
16:22:05 <redi> I agree the earlier stuff on the page belongs elsewhere
16:23:15 <tibbs> So just a sentence mentioning the systemd.exec manpage should be sufficient, though I guess a link to https://www.freedesktop.org/software/systemd/man/systemd.exec.html wouldn't hurt.
16:25:06 <mhroncok> ok. do we know where to put this?
16:25:28 <tibbs> Packaging:Systemd
16:25:36 <tibbs> Or obviously the new equivalent of taht.
16:27:17 <mhroncok> +1 to put the second part, link to https://www.freedesktop.org/software/systemd/man/systemd.exec.html  for explanation, don't have the first part
16:27:26 <redi> +1
16:27:27 <geppetto> Sure, +1
16:28:31 <decathorpe> +1, shrug
16:28:54 <tibbs> +1
16:29:28 <tibbs> Though getting this actually implemented would be fun.
16:30:46 <redi> I have to go and pick up my kid again. This is becoming a regular thing on thursdays, so this time slot might not work well for me any longer :-(
16:30:55 <geppetto> :(
16:31:09 <geppetto> limburgher: ignatenkobrain: Vote?
16:31:53 <limburgher> +1
16:34:51 <geppetto> #action Recommend use of systemd sandboxing directives (+1:6, 0:0, -1:0)
16:34:56 <geppetto> #topic Open Floor
16:35:10 <tibbs> One thing about the PR workflow.
16:35:19 <geppetto> Sure?
16:35:32 <tibbs> I see PRs from ignatenkobrain.  They're mostly fine and I'd just merge them.
16:35:46 <tibbs> But do I really kick it back for a grammar error or typo?
16:36:02 <tibbs> Seems easier to me to just merge and fix that stuff up afterwards.
16:36:02 <mhroncok> tibbs: you can pull it, change it, amend it and push ti to master
16:36:17 <tibbs> mhroncok: OK, see, I have no idea how to do that.
16:36:23 <mhroncok> tibbs: git pull origin refs/pull/<num>/head
16:36:37 <mhroncok> pulls the commits from PR to your local cloned repo
16:36:43 <mhroncok> you can do changes
16:36:55 <geppetto> Eh, I'd just merge it and then fixup with a new commit quickly.
16:36:57 <mhroncok> and git commit them with --amend, later push
16:36:59 <tibbs> Wait, I can pull his PR from the master repo before it's been merged?
16:37:08 <mhroncok> yes
16:37:11 <mhroncok> that's the thing
16:37:23 <tibbs> I thought I had to pull from his fork.
16:37:37 <geppetto> tibbs: yeh, because you are pulling from his pull request
16:37:46 <mhroncok> nope, pagure (ang github, gitlab etc..) expose the PR stuff via refs/pull
16:38:05 <mhroncok> so you don't need yo juggle around with multiple remotes etc.
16:38:18 <tibbs> With the wiki workflow I could either fix up as applying, or immediately afterwards.
16:38:38 <tibbs> I just don't know if it's still acceptable for me to work that way.
16:38:43 <mhroncok> yes, and you can the the same here as well
16:39:03 <mhroncok> I'd prefer to see that typo fix as part of the commit, but if it's another commit, i don't really care either
16:40:15 <tibbs> I'll have to go through another git tutorial.  Most of the time I just end up with a repo in a totally bizarre state and I do reset --hard and start over.
16:40:30 <geppetto> decathorpe: Want to say anything about: https://pagure.io/packaging-committee/issue/784 ?
16:41:49 <mhroncok> tibbs: this one (git is a grpah) made me undersand how to recover form such states: http://think-like-a-git.net/
16:41:54 <geppetto> tibbs: Might just want to look at: https://github.com/git-tips/tips
16:42:58 <tibbs> I also need to learn asciidoc format.  The `...` versus `+...+` thing is really unfortunate.
16:42:59 <decathorpe> gepetto: I'm busy until tomorrow, but I'll whip up a pull request tomorrow or over the weekend
16:43:27 <tibbs> Still better than <code>...</code> but it seems asciidoc isn't particularly RSI-friendly.
16:43:44 <geppetto> decathorpe: ok, no problem … just wanted to make sure you didn't want to say anything about it here
16:44:14 <tibbs> And I'm still working through the selinux thing.  It's really relevant to me now that I have an add-on policy to package.
16:44:32 <geppetto> tibbs: cool, let us know how it goes
16:45:29 <tibbs> As an aside, the idea that we want most packagers maintaining policy is tough to swallow.
16:45:44 <tibbs> Not this committee's decision, of course.
16:46:30 * geppetto nods
16:46:40 <geppetto> Ok, going to close in a min. unless anyone shouts about something
16:46:50 <tibbs> It's not actually hard to make the absolute simplest policy possible by declaring a few types and file contexts and then running audit2allow a lot.
16:47:09 <decathorpe> gepetto: I'll update the wording for the library glob thing proposal one last time and make a pull request
16:47:19 <tibbs> But the result isn't necessarily something that's maintainable or particularly secure.
16:48:06 <geppetto> tibbs: I think the idea is more that packages will update them on a schedule aligned with the package … but will still get help from SELinux knowledgeable people
16:48:18 <decathorpe> ^ that's what I assumed
16:49:20 <tibbs> I don't know; if they have hundreds of outstanding policy bugs, what's to say they have the time to provide that assistance?  It's far less time consuming to maintain the policy files than it is to teach someone else how to do it.
16:50:35 <geppetto> #endmeeting