17:00:41 <geppetto> #startmeeting fpc
17:00:41 <zodbot> Meeting started Thu Feb  1 17:00:41 2018 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:41 <zodbot> The meeting name has been set to 'fpc'
17:00:41 <geppetto> #meetingname fpc
17:00:41 <geppetto> #topic Roll Call
17:00:41 <zodbot> The meeting name has been set to 'fpc'
17:00:46 <mbooth> Go!
17:00:48 <geppetto> #chair mbooth
17:00:48 <zodbot> Current chairs: geppetto mbooth
17:00:49 <limburgher> We've got meeting sign!
17:00:51 <geppetto> #chair tibbs
17:00:51 <zodbot> Current chairs: geppetto mbooth tibbs
17:00:53 * limburgher here
17:00:53 <geppetto> #chair Rathann|Mobile
17:00:53 <zodbot> Current chairs: Rathann|Mobile geppetto mbooth tibbs
17:00:59 <geppetto> #chair limburgher
17:00:59 <zodbot> Current chairs: Rathann|Mobile geppetto limburgher mbooth tibbs
17:01:25 <tibbs> Wow, we're good from the start.
17:01:49 <limburgher> BSMBH
17:05:07 <geppetto> #topic Schedule
17:05:08 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/AHRSA6QDS32YGV65QYA5KR4OB4JJHR3A/
17:06:35 <geppetto> tibbs: Do you want to look at 654?
17:06:42 <geppetto> tibbs: the glibc file triggers ticket?
17:06:50 <tibbs> If we can, it would be good to get it done.
17:07:20 <tibbs> I edited the message in the ticket with all of the comments I received as of yesterday.  Haven't been able to get through my email yet this morning.
17:07:34 <geppetto> #topic #654 glibc file triggers
17:07:37 <geppetto> .fpc 654
17:07:38 <zodbot> geppetto: Issue #654: glibc file triggers - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/654
17:07:45 <geppetto> Yeh., everything is old … and this is the oldest :-o
17:08:21 <tibbs> I find it easier to just do things in the ticket when it's not super long or something you need to diff.
17:08:39 <tibbs> But basically, finally half of the file triggers went into glibc.
17:08:47 <limburgher> whoa
17:09:17 <tibbs> The fact that it's not _all_ of the triggers complicates things a little on our end but not really.
17:09:39 <tibbs> The fact that it's rawhide only means that we needed magic macros to make things work everywhere.
17:09:56 <tibbs> Those macros are also in rawhide and in a pile of updates for Fedora and epel.
17:10:12 <tibbs> Would be great if those could get karma.  (I need to do that myself, since I didn't submit the updates.)
17:10:37 * geppetto nods … reading through the ticket I'm fine with everything
17:12:07 <Rathann|Mobile> this is great
17:12:15 <tibbs> There was one question: Is it problematic to have dependencies on /sbin/ldconfig even when it's not strictly necessary (rawhide)?
17:12:24 <Rathann|Mobile> +1 from me
17:12:32 <limburgher> +1 here too.
17:12:46 <geppetto> tibbs: I'm fine with it … it basically has to be there anyway
17:13:06 <geppetto> tibbs: But if you wanted to do the %ldconfig_requires I'm ok with that too
17:13:16 <tibbs> Well, we could have a magic macro %ldconfig_requires which does the right thing in all cases.
17:13:19 <mbooth> Hmm good updates
17:13:40 <geppetto> +1 officially
17:13:44 <tibbs> I may add that after these updates push, but doing it now would delay the stuff we need.
17:13:51 <Rathann|Mobile> yup
17:13:55 <tibbs> And if I do add it then we can change these guidelines.
17:13:56 <geppetto> Which is +4 … just mbooth to vote.
17:14:02 <tibbs> +1 from me, obviously.
17:14:07 <mbooth> Yeah +1
17:14:26 <tibbs> I dislike rush jobs but everyone is racing the mass rebuild.  Which I thought was supposed to happen yesterday.
17:14:48 <Rathann|Mobile> isn't it possible to autogenerate ldconfig dep?
17:15:03 <geppetto> #action Policy changes due to glibc file triggers from the ticket (+1:5, 0:0, -1:0)
17:15:38 <geppetto> #topic #702 C/C++ guidelines should say using clang needs an exception
17:15:41 <geppetto> .fpc 702
17:15:42 <zodbot> geppetto: Issue #702: C/C++ guidelines should mention that using clang needs an exception - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/702
17:15:50 <tibbs> If a couple more folks could test the updates that are pending (listed in 654) then this can all get written up.
17:16:14 <tibbs> This never got the meeting tag.  Honestly I'm not sure what to do about it.
17:16:40 <tibbs> Is there any policy from FESCo that says anything about this, really?
17:16:42 <mbooth> Is GCC mandatory? I'm not sure.
17:16:56 <geppetto> I thought GCC was mandatory
17:17:07 <geppetto> like glibc is and you need an exception for dietlibc
17:17:08 <tibbs> The "gcc is the compiler" thing comes from the early days of llvm/clang and honestly I don't know what the current state is.
17:17:35 <geppetto> maybe it's just a corner case of bundling now ;)
17:17:37 <tibbs> These days it's certainly possible for some upstream to only support clang, though I would imagine that's rare.
17:18:05 <tibbs> Right now we just say you may only build with something other than gcc if upstream does not support gcc.
17:18:30 * geppetto shrugs … do we need anything else then?
17:18:41 <tibbs> I can reword that slightly to use MUST and the like, but... it seems to say everything that needs to be said already.
17:18:58 <mbooth> Yeah, I'm not sure anything needs to change
17:19:13 <tibbs> At the beginning of the guidelines we say what you have to do when you violate a MUST.
17:19:22 <mbooth> The general guideline is clear, the C/C++ guidelines tell you how to get clang if you need it
17:19:24 <tibbs> Which just amounts to documenting things.
17:19:50 <tibbs> I don't think there is any policy that says you need to actually get some committee's approval if you have a reason for using clang.
17:20:34 <geppetto> #info Policy already says to use GCC if it's possible, which seems strong enough.
17:20:38 <mbooth> No, I don't think it needs a MUST. A MUST with an UNLESS is not really a MUST :-)
17:20:40 <tibbs> Say you have some random package that gets 30% better performance when built with clang.  So you violate the MUST, build with clang, and document in your spec that you're doing it because you get better performance.  (Or it doesn't segfault, or whatever.)
17:21:21 <tibbs> Well, it's basically a MUST now, it's just that you have to switch the order of two clauses to make MUST work grammatically.
17:21:29 <geppetto> #topic #733 'users and groups' should link to prealloc. list
17:21:31 <geppetto> .fpc 733
17:21:32 <zodbot> geppetto: Issue #733: 'users and groups' guidelines need a link to the current list of preallocated users - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/733
17:21:41 <geppetto> I thought we discussed this last week
17:21:53 <tibbs> I'm not sure I see the value in this.  Can't remember last week at this point.
17:22:12 <mbooth> I think we did discuss last week
17:22:17 <Rathann|Mobile> as long as all the hardening flags are effective, clang should be fine
17:22:22 <tibbs> But, I mean, if someone really needs to see the list and they end up at the guidelines, I guess it doesn't hurt so I'm not going to go against it.
17:22:46 <tibbs> Rathann|Mobile: I'm pretty sure they aren't.  But if we do want to change the "must use gcc" policy then that would be a different discussion.
17:23:02 <Rathann|Mobile> ok
17:23:06 <geppetto> Yeh we did … missed the update
17:23:12 <geppetto> updating the ticket now
17:25:55 <geppetto> #topic Open Floor
17:26:05 <tibbs> Hmm, that's it?
17:26:09 <geppetto> I think that's it for tickets with updates
17:26:24 <geppetto> We can obviously talk about any of the others that are open and tagged meeting
17:26:40 <tibbs> Well, first, there's the env thing.
17:26:46 <geppetto> But AFAICS things need to happen before we can do anything
17:26:53 <geppetto> env thing?
17:27:30 <tibbs> RPM will now automatically fix #!/usr/bin/env foo in rawhide.
17:27:44 <geppetto> fix how?
17:28:19 <tibbs> Any executable that starts with #!/usr/bin/env XXX will be modified automatically to have #!/usr/bin/XXX instead.
17:28:38 <geppetto> ok
17:28:43 <tibbs> And then anything that uses #!/usr/bin/python will be changed to #!/usr/bin/python2
17:29:16 <mbooth> I suppose this requires a mass rebuild before it's effective everywhere?
17:29:41 <tibbs> Well, anything that gets built with redhat-rpm-config-91 in the buildroot will have that done automatically.
17:29:54 <tibbs> Also, rawhide gained a consistent method for disabling all brp-* scripte.
17:30:09 <Rathann|Mobile> consistency is good
17:30:14 <mbooth> At last
17:30:38 <tibbs> What I'm not sure about is what guideline changes are needed for this.
17:31:04 <mbooth> tibbs: Point me to the change and I can have a look and propose something
17:31:17 <tibbs> We could mention it in the python guidelines and wherever we banned use of env, but... those still need fixing on <=F27 and epel, so.
17:31:45 <tibbs> The FPC ticket is 738, BTW.
17:32:04 <mbooth> I have to disable various burp scripts in a few of my packages, so I could write a guideline while making it consistent for my own packages
17:32:14 <mbooth> thanks
17:32:37 <Rathann|Mobile> easily discoverable docs for this will be a big help
17:33:38 <tibbs> For the brp-* disabling thing, I was thinking that maybe we could have a guideline which indicates at least some of the ones which runs, mentions __os_install_post, the method for disabling them, and then have an actual guideline which says that you SHOULD let all of them run.
17:34:22 <tibbs> If you do rpm --showrc on rawhide and look at __os_install_post, you'll see the ones which get called.
17:34:42 <tibbs> And to disable, say, the brp-compress script, you just %undefine __brp_compress and it goes away.
17:35:08 <tibbs> The old methods still work, too (%undefine py_auto_byte_compile for that one, for example).
17:35:38 <geppetto> Do we really need to document how to turn it off?
17:35:43 <tibbs> For the shebang thing, it's %undefine __brp_mangle_shebangs.
17:35:50 <tibbs> geppetto: I don't know, honestly.
17:35:57 <mbooth> Can't wait to get rid of this comedy line:
17:35:58 <mbooth> %global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')
17:36:19 <tibbs> mbooth: You haven't needed that one in Fedora for some time now.
17:36:20 <geppetto> I'm fine with not bothering … if someone really needs to do it they can ask around in fedora-devel or something
17:36:30 <tibbs> Just clear py_auto_byte_compile.
17:36:48 <mbooth> tibbs: One of those "it was like that when I inherited the package" situations
17:37:21 <limburgher> ugh. ::)
17:37:29 <tibbs> Actually you still need that crap on EL6, sorry.
17:37:40 <geppetto> 👍
17:38:37 <tibbs> geppetto: So the thing with the env mangling is that I know there were some strong objections to us banning use of env.
17:39:14 <tibbs> And now we've gone one step further and it just gets automagically fixed up.  (For some value of "we".)
17:39:25 <geppetto> I remember some people saying it had always been done that way etc. … but I don't remember strong objections
17:39:42 <tibbs> There's even a ticket....
17:39:52 <tibbs> https://pagure.io/packaging-committee/issue/725
17:40:08 <geppetto> Yeh, it is def. some other version of we … so we can point at those "we" ;)
17:40:34 <tibbs> And we should really address 725 at some point, too.
17:41:20 <geppetto> Close rejected?
17:41:57 <geppetto> "Fedora project should TRUST Fedora packagers and their work. If the packager thinks it is acceptable, and wants to support it, this is his choice."
17:42:19 <tibbs> I keep pointing to the general exception policy.
17:42:20 <geppetto> That could argue against pretty much every line of the guidelines
17:42:55 <limburgher> oy
17:43:01 <tibbs> But to be fair, I actually disagree with multiple things in 725.
17:43:11 <tibbs> Having guidelines doesn't mean we don't trust packagers.
17:43:23 <limburgher> Indeed.
17:43:26 <tibbs> Trusting packagers doesn't mean we can't say that there are things you mustn't do.
17:44:29 * geppetto nods … I'll update the ticket
17:44:30 <limburgher> I agree.
17:44:31 <tibbs> Plus, our MUSTs are pretty weak and our SHOULDs are merely strong suggestions.
17:44:38 <Rathann|Mobile> sorry have to drop off now
17:45:06 <tibbs> In the end he'll just ignore whatever we say anyway because he basically does his own thing.
17:45:52 <tibbs> When the rebuild hits, he'll probably be unhappier because of the brp-mangle-shebangs thing but he can yell at me for that (since I was the one who pushed the change).
17:46:03 * limburgher nods
17:46:17 <tibbs> So what else is there?
17:46:33 <tibbs> Florian did a lot of nice work on compiler flags which deserves a look.
17:46:54 <tibbs> .fpc 743
17:46:55 <zodbot> tibbs: Issue #743: Add link to C/C++ build flag documentation in redhat-rpm-config - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/743
17:47:10 <tibbs> I keep changing my mind on what I want to say.
17:47:32 <tibbs> On one hand, if we're going to talk about compiler flags then we should at least provide a reference to what those flags are.
17:47:50 <limburgher> I thought we weren't going to link into pagure.
17:47:50 <geppetto> We can tag it with meeting and talk about it next wed.
17:48:09 <tibbs> But on the other hand, there's an argument to be made that at least some of what he wrote should actually be in the guidelines.
17:48:30 <geppetto> We only have a few minutes left
17:48:47 <tibbs> Thing is, as people move away from the wiki, we may need to link into pagure if we want to reference external things.
17:49:02 <tibbs> I don't really know, which is why I haven't gotten around to commenting.
17:49:16 <tibbs> It's the old question of how much you actually put into the guidelines.
17:49:19 <limburgher> ffffppllbbbbbbbpt.
17:49:28 <limburgher> Yeah.
17:49:32 <tibbs> So, yeah, it certainly deserves proper discussion.
17:49:36 <limburgher> For sure.
17:50:20 <tibbs> We need to get back to the ruby guidelines.  I hope we can do it next week.
17:50:28 <tibbs> I think they've been ready for us for some time now.
17:51:12 <tibbs> That whole "forge hosted project" thing did also land in redhat-rpm-config.
17:51:27 <tibbs> That's 719 and should also be on our radar.
17:51:58 <geppetto> I looked at that, and it seemed like nirik wanted you to write some policy
17:52:16 <tibbs> You mean nim.
17:52:20 <geppetto> Yeh
17:52:43 <limburgher> autoincorrect?
17:52:47 <tibbs> Yeah, it needs a draft.
17:53:14 <tibbs> It's tagged hasdraft but I think maybe it needs cleaning up.
17:53:18 <geppetto> But we shouldn't need to do it … we just don't have the resources to do that
17:53:25 <tibbs> Currently this stuff is just soaking in rawhide anyway.
17:53:50 <tibbs> After I merged it Panu came out against merging it.
17:54:04 <geppetto> :)
17:54:46 <tibbs> Yeah, one of those things where it sits for a while, "I'll merge it if nobody objects", I merge it, and then "suddenly" it got merged without anyone having a chance to look at it.
17:55:01 <limburgher> Tale as old as time. . .
17:55:03 <tibbs> I don't agree with all of it but, I mean, I'm not Linus.
17:55:30 <tibbs> And at some point things have to be available for people to actually test them and see what does and doesn't work.
17:55:47 * geppetto nods
17:56:10 <tibbs> nim did a lot of good work in those things, so if the only objections are that "forge" and "project" and such are too generic for macro names, I don't see much point in arguing about it.
17:56:18 <geppetto> Anyway, going to close in a minute unless anyone shouts about anything that is related to FPC ;)
17:56:38 <tibbs> My list grows longer....
17:56:59 <tibbs> geppetto: BTW, did you email the less-present folks?
17:57:13 <geppetto> no, because we actually had a meeting I didn't
17:57:41 <tibbs> I do think we need to.  I can do it, though.
17:57:53 <geppetto> if you think we need to I can
17:58:12 <geppetto> I mean, I don't disagree … just didn't seem as important because we managed to have the meeting
17:58:30 <mbooth> Right-o, I need to go now anyway
17:58:35 * geppetto adds it to his todo list again
17:58:38 <mbooth> Home time
17:58:39 * geppetto nods … we all do :)
18:00:03 <geppetto> #endmeeting