16:00:28 <geppetto> #startmeeting fpc
16:00:28 <zodbot> Meeting started Thu Jun  6 16:00:28 2019 UTC.
16:00:28 <zodbot> This meeting is logged and archived in a public location.
16:00:28 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:28 <zodbot> The meeting name has been set to 'fpc'
16:00:28 <geppetto> #meetingname fpc
16:00:28 <geppetto> #topic Roll Call
16:00:28 <zodbot> The meeting name has been set to 'fpc'
16:00:36 <tibbs> Hey, folks.
16:00:43 <geppetto> #chair tibbs
16:00:43 <zodbot> Current chairs: geppetto tibbs
16:00:45 <geppetto> #chair decathorpe
16:00:45 <zodbot> Current chairs: decathorpe geppetto tibbs
16:00:48 <decathorpe> hello o/
16:00:52 <mhroncok> hey, I'm here, but I'm super tired :(
16:00:57 <geppetto> #chair mhroncok
16:00:57 <zodbot> Current chairs: decathorpe geppetto mhroncok tibbs
16:01:30 <geppetto> #chair redi
16:01:30 <zodbot> Current chairs: decathorpe geppetto mhroncok redi tibbs
16:01:34 * limburgher here
16:01:43 <redi> hi there
16:03:28 <geppetto> #chair limburgher
16:03:28 <zodbot> Current chairs: decathorpe geppetto limburgher mhroncok redi tibbs
16:06:08 <geppetto> Ok
16:06:12 <geppetto> #topic Schedule
16:06:15 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/V65QYD2PRYERNLUECSEKZUHYIUYJUBDW/
16:06:25 <geppetto> #topic #888 How to install "/afs" directory for kafs-client package
16:06:32 <geppetto> .fpc 888
16:06:33 <zodbot> geppetto: Issue #888: Need to work out how to install "/afs" directory for upcoming kafs-client package - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/888
16:07:42 <ignatenkobrain> .hello2
16:07:43 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:08:09 <limburgher> New to this ticket, I feel like since it's in the kernel, /afs should be in the filesystem package.
16:09:22 <geppetto> yeh, that seems like the easiest solution to me
16:09:37 <geppetto> just skip an empty /afs everywhere … is there a real problem with that?
16:09:43 <geppetto> s/skip/ship/
16:09:45 <limburgher> And least complex, least bitrotty...
16:10:37 <limburgher> I can't imagine. Worst case, multiple packages provide it. Maybe the client package could require that dir. So if it moves, they don't have to care.
16:11:01 <geppetto> tibbs: you have any problems with empty /afs everywhere?
16:11:27 <tibbs> The only caveat is that it can't be introduced in an existing release, for the reasons already discussed.
16:11:39 <limburgher> Right.
16:12:21 <geppetto> What is the problem with upgrades?
16:12:30 <tibbs> Otherwise, I've no real problem with it. It doesn't really _have_ to be in filesystem; if they would rather put it in afs-filesystem then I don't particularly care.
16:13:22 <tibbs> RPM may not behave well if asked to create or modify a directory that has a kernel magic filesystem mounted on it already.
16:13:52 <tibbs> So it's really only safe to try to mkdir /afs when you can be sure that AFS isn't already running.
16:13:56 <geppetto> yeh, I'm just confused about how that happens
16:14:20 <redi> somebody might have manually set up AFS themselves, presumably
16:14:36 <redi> so they already have /afs there, and mounted
16:14:47 <geppetto> ahh, sure.
16:14:55 <tibbs> Right, currently it's something you have to do manually, but if the kernel client is already live on /afs then things may go badly if RPM tries to poke at it.
16:15:31 <tibbs> You might think it would jujst ignore it if it's already there, but it may want to change ownership or permissions and that wouldn't always work well.
16:15:39 <geppetto> fair enough … I guess it's not a big deal to wait until f31
16:15:41 <mhroncok> can a postinstall script try to mkdir it and do nothing if it is already there?
16:15:52 <mhroncok> and the package %ghost it
16:15:58 <geppetto> mhroncok: that's in the ticket
16:16:06 <mhroncok> oh, sorry
16:16:22 <geppetto> although in general %post is crappy, and we want less of them
16:16:39 <tibbs> Yes.  And sure, that works; if rpmlint didn't complain they might not have asked.
16:16:43 <geppetto> eh … anything we need to vote on here?
16:16:46 <tibbs> Eventually the ostree people would be asking.
16:17:08 <tibbs> Yes, I think there is an item for a vote.
16:17:29 <geppetto> Proposal: Allow /afs to be included in filesystem, or afs-filesystem if desired for rawhide/f31
16:17:48 <tibbs> +1
16:18:03 <geppetto> +1
16:18:10 <mhroncok> +1
16:18:18 <decathorpe> +1
16:18:33 <tibbs> I think it's also worth telling them that they can do the %post thing in existing releases but to please not do that in F31+.
16:18:47 <limburgher> +1
16:18:56 <geppetto> redi: vote?
16:18:59 <redi> +1
16:19:07 <geppetto> #action Allow /afs to be included in filesystem, or afs-filesystem if desired, for rawhide/f31 (+1:6, 0:0, -1:0)
16:19:36 <geppetto> #info Can use the scriptlet dir. creation hack for f30, but not f31+
16:19:56 <geppetto> #topic #893 Proposal: Cython sources must be regenerated
16:20:00 <geppetto> .fpc 893
16:20:03 <zodbot> geppetto: Issue #893: Proposal: Cython sources must be regenerated - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/893
16:20:44 <mhroncok> I'm OK if the guideline is reworded by tibbs or anybody else
16:21:20 <ignatenkobrain> I'm +1 (as in the ticket)
16:21:23 <tibbs> Sorry for not actually making those comments.  So much is going on.
16:22:18 <geppetto> +1
16:22:24 <tibbs> +1 to making this a "must".
16:22:32 <decathorpe> +1
16:22:37 <limburgher> +1
16:22:40 <redi> +1
16:22:52 <mhroncok> +1 FTR
16:22:56 <geppetto> #action PR 894 (+1:6, 0:0, -1:0)
16:23:31 <geppetto> #topic #899 Need to define ticket policy
16:23:35 <geppetto> .fpc 899
16:23:36 <zodbot> geppetto: Issue #899: Need to define ticket policy - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/899
16:25:21 <ignatenkobrain_> so apparently I realized that my messages are not going out =(
16:25:50 <limburgher> Oof.
16:25:57 <geppetto> yeh, last I got from you was the +1
16:26:07 <ignatenkobrain_> For this one I feel that we are not moving fast with some of tickets (like re-bootstrap exception)
16:26:41 <ignatenkobrain> yeah, I feel that for some tickets we do very slow
16:27:18 <tibbs> You're right, but some of that lately is summer and some of it is that we aren't sufficiently gardening the ticket queue.
16:27:30 <tibbs> I don't think "auto-pass if nobody complains" is the right way around that.
16:27:53 <ignatenkobrain_> no, but something like "+3 is enough if nobody complains within a week for this type of a ticket"
16:28:24 <tibbs> That's possible, maybe, but we do have mostly regular meetings.  We just don't actually get to all of the tickets.
16:28:41 <geppetto> Yeh, the last month has been pretty bad … but normally we are good
16:28:56 <tibbs> I was in the dentist chair for two consecutive meetings.
16:29:05 <geppetto> I'd much rather have some process to ping people on IRC to vote in the ticket
16:29:16 <tibbs> I think it may be worth considering every ticket not otherwise tagged as something to discuss at the meeting.
16:29:23 <tibbs> And abandoning the "meeting" tag.
16:29:27 <geppetto> but, eh, I could go for the +3 thing too if people prefer
16:29:51 <mhroncok> currently, it requires explicit action to put something in the agenda
16:30:02 <mhroncok> and sometimes, tickets go for weeks without somebody doing that action
16:30:05 <tibbs> mhroncok: Right, that's what I'm suggesting we change.
16:30:20 <mhroncok> so "explicitly on agenda if at least X days old and not tagged with Y" might do it
16:30:33 <tibbs> Tag things as "stalled" or "needinfo" or whatever, but otherwise they should go on the agenda.
16:30:44 <tibbs> If we dislike five hour meetings then eventually we'll get things pruned.
16:31:27 <geppetto> I don't mind doing that, as long as there's a url I can use to get the scedule done
16:31:33 <tibbs> And then of course we'll end up with tickets incorrectly marked as stalled or needinfo.  But that should be at least slightly easier to deal with.
16:32:16 <tibbs> The other thing is that more than 25 issues open is too damn many, and is a signal that we're not doing what we need to be doing.
16:33:03 <limburgher> Agreed.
16:33:06 <tibbs> The other thing is that if you assign a ticket to yourself, you should be prepared to give a status update at each meeting.
16:33:28 * mhroncok has some, stalled, sorry
16:33:57 <tibbs> So, I have vacation next week and it's pretty slow this week.  I will try to do a runthrough.
16:34:26 <tibbs> One other thing is that we have tickets like https://pagure.io/packaging-committee/issue/756 which nobody wants to touch.
16:34:52 <tibbs> I mean, I don't want to talk about SCLs again.
16:35:13 <tibbs> Maybe modules obviated the need for this, I don't know.
16:36:19 <ignatenkobrain_> I suppose we need to close 756
16:36:41 <geppetto> yeh
16:36:50 <tibbs> Yes, I think that one needs to go away.
16:37:29 <tibbs> The Go ones might be closable soon, too.
16:37:57 <tibbs> I think we should probably just close https://pagure.io/packaging-committee/issue/874 unless there is something that we can do separately from the docs team.
16:40:04 <tibbs> But anyway, a couple of hours of work should get things into a better state.  I will try to do that today but certainly anyone else is welcome to work on it too.
16:40:30 * geppetto nods
16:40:43 <geppetto> In a similar vein I won't be around next week.
16:41:22 <tibbs> Another thing to do is to just sort by last modified date and try to hit the top five every meeting until everything is relatively fresh.
16:41:33 <geppetto> So do we want to table this ticket and see if we can make it not needed … or vote on something?
16:42:20 <tibbs> Personally I'm against a process change like that while we're still in a disorganized state.
16:42:48 <tibbs> But other process changes which would keep us in an organized state would certainly be good, and I think we've talked about a few.
16:43:09 <geppetto> Looking at last modified the ones we don't have on the agenda are 901 and 902
16:44:37 <tibbs> Yeah, those are pretty new.
16:44:54 <tibbs> I had some opinions on 902.
16:45:43 <tibbs> One of the proposed cleanups is good, but points to the need for a bit of rewording in the guidelines.  The old ones can be pretty conversational.
16:45:47 <tibbs> I will send a PR for that.
16:46:00 <tibbs> The other stuff seems to be just pointless busy work.
16:46:50 <tibbs> "No need to put %doc before %_mandir" is... true but it doesn't hurt anything by being there and packagers could find it to be a useful marker.
16:47:12 <tibbs> I'm not sure about %verify() with %ghost.  Seems to be the same thing.
16:47:39 <tibbs> This seems on the level of someone going through and adding or removing trailing slashes from directories in the %files list.
16:48:00 <geppetto> yeh, I prefer doc at the top … not sure why people want that to change.
16:48:33 <limburgher> I like %license then %doc then everything else but whatevs
16:48:56 <geppetto> Anyway … seems like no vote, so moving to …
16:49:01 <geppetto> #topic Open Floor
16:49:05 <tibbs> I mean, I'm guilty of doing mostly pointless cleanups but they've all been for actual guidelines issues.
16:49:24 <tibbs> And yeah, I'll send a PR for the change I'd like to see as part of 902.
16:49:31 <geppetto> cool
16:49:37 <ignatenkobrain_> tibbs++
16:49:48 <tibbs> What about 901?
16:50:14 <tibbs> This is an exception for renaming a big load of golang packages.
16:50:30 <decathorpe> I posted some opinions on that one ..
16:50:40 <tibbs> I don't have a problem with it, really, but it seems to me that they're chasing a draft.
16:51:41 <geppetto> lowercase is generally better … but meh. … I'm happy with whatever decathorpe thinks
16:51:53 <geppetto> tibbs: I thought the draft was approved
16:52:00 <tibbs> I do generally prefer lower case package names, certainly, but Perl packages are a valid exception.
16:52:11 <tibbs> geppetto: It's possible, I think I missed that meeting.
16:52:27 <decathorpe> yes, we approved the Go Packaging Guidelines
16:52:36 <decathorpe> but this is about renaming a few hundred packages
16:52:46 * decathorpe shrugs
16:53:05 <tibbs> And sure, I know that we don't generally _force_ things to be retroactive.
16:53:26 <geppetto> macros kind of have to though
16:53:29 <limburgher> *cough*mergereviews*cough*
16:53:40 <tibbs> Forgive me for not reading through the new things, but do the new guidelines require lower case package names for golang?
16:54:06 <decathorpe> no, but the macro generating the value for "%{name}" is case insensitive
16:54:30 <decathorpe> which leads to problems for packages that used the old macros or gofed for that, which were case sensitive
16:55:05 <tibbs> OK, so it's basically up to what the maintainers want to do.
16:55:50 <mhroncok> as long as they don't use the new macro
16:55:53 <tibbs> You are right that maybe the macros could do things differently and it might be less annoying, but that's not really for us to mess with unless we think the current behavior is just broken.
16:56:17 <tibbs> But if maintainers want to do this, I don't think we should let process stand in the way.
16:56:29 <decathorpe> that's true
16:57:09 <decathorpe> some of my packages are affected by this, but I'll just let the other Go SIG members handle this if that's really what they want to do
16:57:34 <mhroncok> will hey request the new repos for all of them and hand them to the original maintainers?
16:57:39 <tibbs> Personally I would +1 an exception to the review process for _any_ package that wants to downcase its name.
16:57:59 <decathorpe> mhroncok: I have no idea.
16:58:06 <tibbs> But certainly those who want this should all be discussing it, and nobody should be renaming packages against the wishes of the maintainers.
16:58:09 <ignatenkobrain_> I would prefer to have package names as in upstream
16:58:19 <ignatenkobrain_> doing any mangling is just confusing everyone
16:58:29 <limburgher> Same
16:58:31 <tibbs> Then I'm confused; didn't you +1 the ticket?
16:58:50 <decathorpe> I think it's too late to change the macro implementation.
16:59:04 <decathorpe> since getting it this far took years ...
16:59:17 <tibbs> True, but things can always be changed.
16:59:31 <ignatenkobrain_> well, I did +1 because I didn't know that those are re
16:59:41 <ignatenkobrain_> ..already packaged
16:59:55 <ignatenkobrain_> I thought those are new packages needed for new guidelines bootstrap
17:00:04 <ignatenkobrain_> decathorpe: it is never late :)
17:00:10 <tibbs> Well you might want to update your comment.
17:00:25 <decathorpe> AFAICT, these are all already packaged under different names.
17:00:45 <tibbs> Personally I would +1 this only because I don't have a problem with letting packagers downcase things if they want.  I take no position on what the Go macros should do.
17:01:02 <geppetto> yeh, I think we could easily get +1 for a change to the macro to not lowercase is that was wanted
17:01:20 <decathorpe> gepetto: you don't know the Go SIG ;)
17:01:37 <geppetto> I was thinking here, if the Go sig wanted that :)
17:01:40 <tibbs> In fact, I would consider simply allowing package renames without review, since time has shown that the fallout for getting it wrong is something we can deal with well enough.
17:01:45 <decathorpe> ah. true
17:02:04 * decathorpe shrugs, doesn't care enough about go anymore
17:02:06 <geppetto> But if you think it'll be difficult to get past the Go sig. I guess we just shrug and live with it
17:02:06 <mhroncok> +1 on the exception
17:02:35 <geppetto> decathorpe: ?
17:02:48 <decathorpe> I can give +1 to this exception
17:02:57 <decathorpe> grumble grumble ;)
17:03:07 <geppetto> decathorpe: The go sig.; the language; or the 100s of packages you own ?;)
17:03:37 <ignatenkobrain_> yeah, Go ecosystem is just broken by design :)
17:03:38 * geppetto shrugs … if everyone else is doing it … +1
17:03:58 <ignatenkobrain_> we can ask Go SIG to clarify why it was chosen lower case
17:04:08 <ignatenkobrain_> one week won't kill anybody
17:04:26 <decathorpe> right
17:04:46 <decathorpe> geppetto: both (and I only own ~30 go packages, the rest is from the SIG)
17:04:51 <tibbs> I added my comments to 901.
17:05:18 <geppetto> ok, you wan tto postpone until the next meeting then?
17:05:29 <geppetto> We are 5 mins. over
17:05:54 <geppetto> And, again, I'll be unavailable next week … and tibbs said he's out too … so probably two weeks from now
17:06:12 <decathorpe> I don't think there's a need to hurry this
17:06:19 <tibbs> Actually I will be on vacation and should be around.  I'm just terrible at running meetings.
17:06:30 * geppetto nods
17:06:37 <geppetto> Ok, I'll end the meeting then
17:06:38 <tibbs> We can always vote in tickets... if only that happened more often, we'd have less meeting.
17:06:47 <geppetto> maybe ignatenkobrain or mhroncok can run it next week?
17:06:48 <Rombobeorn> May I bring up issue 610 again, or are you guys out of time?
17:06:48 <ignatenkobrain_> https://pagure.io/GoSIG/go-sig/issue/31
17:06:56 <ignatenkobrain_> I've opened this one for Go SIG
17:07:01 <ignatenkobrain_> hey Rombobeorn
17:07:02 <geppetto> Rombobeorn: We were out of time 5 minutes ago :)
17:07:06 * mhroncok is not available next week either, pycon cz
17:07:38 <geppetto> Rombobeorn: If it's super quick we could m.fpc 610
17:07:42 <tibbs> Then it looks like two weeks is better.
17:07:44 <geppetto> .fpc 610
17:07:48 <zodbot> geppetto: Issue #610: Packaging guidelines: Check upstream tarball signatures - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/610
17:07:58 <ignatenkobrain_> tl;dr redhat-rpm-config was merged by me few days ago
17:08:02 <ignatenkobrain_> and there is PR to change guidelines
17:08:08 <Rombobeorn> The current status is that gpgverify is functional in Rawhide, so the method prescribed in https://pagure.io/packaging-committee/pull-request/836#_1__35 works. It is also in Git for EPEL 6 and 7, but not released yet.
17:08:12 <ignatenkobrain_> geppetto: yes, I can run it next week
17:08:21 <Rombobeorn> So does the FPC want a source file verification policy, and for which releases?
17:08:22 <geppetto> ok, seems like a go then
17:08:25 <tibbs> ignatenkobrain: did you merge for just rawhide or back to F29 as well?
17:08:25 <geppetto> ignatenkobrain: cool
17:08:27 <geppetto> ignatenkobrain++
17:08:28 <zodbot> geppetto: Karma for ignatenkobrain changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:08:42 <ignatenkobrain_> tibbs: just rawhide, but I can backport into other fedora
17:09:24 <Rombobeorn> If you guys want to apply this policy to Fedora 29 and 30, then I think the text is ready, but gpgverify should be ported to those releases of redhat-rpm-config. This is not technically difficult to do.
17:09:25 <Rombobeorn> If you want to apply it beginning with Fedora 31, then I think a few words about that should be added to the text, but the code is ready.
17:09:27 <tibbs> Just because the guidelines would need a note if it's F31+.
17:09:45 <ignatenkobrain_> tibbs: technically not, our guidelines explicitly say "rawhide"
17:09:56 <ignatenkobrain_> even systemd-rpm-macros exist only in f30+ IIRC
17:10:01 <ignatenkobrain_> but there is no note about that
17:10:17 <ignatenkobrain_> anyway, for this one we should just proceed with review of PR and that's it
17:10:33 <tibbs> Generally we try not to do that.  Our guidelines apply to Fedora, and should state when they don't apply to all Fedora.
17:11:07 <tibbs> That literally the first sentence after the table of contents.
17:12:22 <ignatenkobrain_> anyway, I can backport it to f29/f30, there is no problem
17:12:28 <ignatenkobrain_> along with probably few more things.
17:13:16 * geppetto nods
17:13:27 <geppetto> Ok, on that note I'll end it
17:13:32 <tibbs> Thanks, folks.
17:13:40 <geppetto> #endmeeting