16:00:30 #startmeeting fpc 16:00:30 Meeting started Thu Apr 28 16:00:30 2016 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:30 The meeting name has been set to 'fpc' 16:00:31 #meetingname fpc 16:00:31 The meeting name has been set to 'fpc' 16:00:31 #topic Roll Call 16:02:03 .fas jdulaney 16:02:03 handsome_pirate: jdulaney 'John Dulaney' 16:03:17 Hi 16:03:19 morning 16:03:35 #chair mbooth 16:03:35 Current chairs: geppetto mbooth 16:03:37 #chair orionp 16:03:37 Current chairs: geppetto mbooth orionp 16:03:41 hey 16:04:37 * Rathann here 16:05:32 * tomspur is also here 16:05:35 #chair Rathann 16:05:35 Current chairs: Rathann geppetto mbooth orionp 16:05:38 #chair tomspur 16:05:38 Current chairs: Rathann geppetto mbooth orionp tomspur 16:05:43 cool, we have 5 :) 16:05:46 Sorry guys for missing quite often in the last time... 16:05:53 * handsome_pirate thinks he's here 16:06:09 Doh. 16:06:30 Busy morning, and I was in jury duty all of yesterday. 16:06:39 * racor is also here 16:06:54 It was a murder trial; fortunately they didn't pick me, though it would have been interesting. 16:07:03 But voir dire took hours. 16:07:19 #chair tibbs|w 16:07:19 Current chairs: Rathann geppetto mbooth orionp tibbs|w tomspur 16:07:30 #chair racor 16:07:30 Current chairs: Rathann geppetto mbooth orionp racor tibbs|w tomspur 16:07:42 Cool … we have most everyone … woo 16:07:45 I'm behind again, by the way, and have sort of lost context on what I'm supposed to be working on. 16:07:48 #topic Schedule 16:07:55 #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/4KIN4E3ETHOAUA5GYIG653XHQX5XWS73/ 16:07:58 So if you're waiting on me for something, do let me know. 16:08:03 #topic #618 drop prohibition of socket activated services 16:08:07 .fpc 618 16:08:09 geppetto: #618 (drop prohibition of socket activated services) – fpc - https://fedorahosted.org/fpc/ticket/618 16:08:28 I've never really understood why we had that. 16:08:41 I think our reasoning here was that we didn't want "big" services like apache-httpd being converted "just because" 16:08:45 Especially since there are already socket activated services. 16:09:06 Or maybe we wanted more testing … who knows. 16:09:11 I'm happy to +1 this change though. 16:09:18 I don't think it was a "we" thing. 16:09:32 It was more of a thing where the systemd folks didn't want us using it yet. 16:09:38 But that was years ago. 16:09:43 +1 for removing the prohibition. 16:09:44 yup 16:09:50 +1 as well 16:09:53 60dSnf*s7 16:10:02 Well, time to change that password. 16:10:03 ooh, not a bad one 16:10:08 but it was short 16:10:30 I read that anything <13 chars can be brute-forced in <14h 16:10:33 9 characters isn't bad these days. All of my passwords are completely random. 16:10:36 +1 to remove 16:10:36 I mean <24h 16:11:29 +1 16:11:29 +1 to remove this prohibition also 16:12:01 At +6 … racor you want to vote for the record? 16:12:02 tibbs|w: IIRC, the motivation for the prohibition was us not wanting to have some arbitrary freaky service to fire up at boot 16:12:06 +1 16:12:22 I don't know; if you don't want it starting, you shouldn't enable it. 16:12:38 I think we can trust the people who make the preset files to not enable dumb things at boot. 16:12:38 #action drop prohibition of socket activated services (+1:7, 0:0, -1:0) 16:12:47 #topic #619 Need a statically reserved uid and gid for heketi 16:12:51 .fpc 619 16:12:54 geppetto: #619 (Need a statically reserved uid and gid for heketi) – fpc - https://fedorahosted.org/fpc/ticket/619 16:13:19 tibbs|w: we had a time people submitted series of freaky services hardly anybody will want ;) 16:14:25 unfortunately lpabon isn't here to answer any questions 16:14:40 I'm sure there's still plenty of that, and I guess people could do systemctl enable in %post, but they can do all sorts of crazy things. 16:14:40 Can we go back to 618 for a bit? 16:14:52 orionp: Sure 16:15:02 #topic #618 drop prohibition of socket activated services 16:15:49 There is some intermingling of socket activation and Fesco approval for autostarting of services 16:16:19 That's true. 16:16:23 What prohibition on socket-activted services? 16:16:50 sgallagh: There's been a longstanding prohibition against socket-activated services in the packaging guidelines. 16:17:02 Dates from the original drafts of the systemd guidelines. 16:17:23 tibbs|w: We adjusted those rules a while ago 16:17:37 Who is "we"? 16:17:50 Because the prohibition is still in the packaging guidelines. 16:18:00 https://fedoraproject.org/wiki/Packaging:DefaultServices 16:18:11 tibbs|w: That's the canonical page. 16:18:15 https://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation 16:18:22 If the guidelines are conflicting anywhere, that should be fixed. 16:18:35 We just voted on it like 10 minutes ago 16:18:41 Right, that's what we're dealing with now. 16:18:51 interestingly enough, what sgallagh linked isn't linked from the main Guidelines or Systemd service guidelines 16:19:04 geppetto: Sorry, haven't read the scrollback (I have an IRC watch on "fesco" which summoned me) 16:19:12 ahh 16:19:16 it's only mentioned in Packaging:Scriptlets 16:20:19 ok so we need to link to this one from Packaging:Systemd 16:20:47 And remove a bit of text there as well. 16:20:53 sgallagh: so, I need only say 'fesco' and you will come running to save the day? 16:20:55 Yeah, I think the implication there is that socket-activation is fine, but it's treated identically to the "running at boot" case 16:20:59 I'll work on a draft... 16:21:13 handsome_pirate: Only if I feel like it ;-) 16:21:17 orionp: I'd go for just fixing this, honestly. 16:21:37 I'll be ready in a minute... 16:23:32 BTW, I think we can skip 619 since we really don't have enough info. 16:23:56 yup 16:24:00 yeh, all I can see is that it's related to glusterfs 16:25:16 How about https://fedoraproject.org/w/index.php?title=PackagingDrafts%3ASystemd&diff=curr&oldid=444672 16:25:51 orionp: +1 16:26:59 +1 16:27:06 seems fine, +1 16:28:26 mbooth: Rathann: racor: vote? 16:28:33 orionp: I assume you ar +1 :) 16:28:40 Yeah, +1 16:28:45 geppetto: I already did 16:29:14 Rathann: yeh, sorry. need better tracking 16:29:42 +1 16:30:17 tomspur: racor: vote? 16:30:29 +1 16:30:52 no, was distracted and did not follow 16:31:33 #action Change wording about auto starting networked socket activated services. (+1:6, 0:1, -1:0) 16:31:45 Ok, moving onto 620 16:31:47 #topic #620 Perl Build-Requires Packaging guidelines update 16:31:52 .fpc 620 16:31:54 geppetto: #620 (Perl Build-Requires Packaging guidelines update) – fpc - https://fedorahosted.org/fpc/ticket/620 16:31:58 Okay, I changed the packaging page 16:32:04 yay 16:32:25 so this is a long one 16:32:33 I wonder if the next one will be removing python from buildroot ;) 16:33:17 I'm happy with the desire to get rid of perl, but perl-generators doesn't seem like a great name 16:33:20 I'm pretty happy with this now that there seems to be assurances the changes will be made and monitored 16:33:44 yeah, the name sucks 16:34:08 perl-build? perl-rpm-build? … even perl-rpm-generators seems better 16:34:50 tibbs: How do you feel about the rest of the ticket now? 16:35:04 perl-macros? 16:35:07 f'ing dnf repoquery.... 16:35:24 You can still install the real one ;) 16:35:48 geppetto: I think we need a real proposal/diff 16:36:43 https://fedoraproject.org/wiki/PackagingDrafts/Packaging:Perl/BuildRequires 16:37:08 I see it didn't change during the conversation in the ticket, but I'm not 100% it needed to 16:37:16 hm why not rpm-build-perl? 16:37:48 Rathann: it seems weird to ship that in perl … perl-rpm-build seems better … but I'm happier with that name than the original 16:38:37 geppetto: not sure why it would be weird, but perl-rpm-build works for me, too, if everyone else is happier about that 16:38:50 geppetto: I've decided to be against the "Build-Requires" section, because I find it non-workable 16:39:12 racor: why? 16:39:40 racor: Any changes you'd suggest? 16:39:42 geppetto: The build-requires need to be a single "BR: something" which catches all cases 16:40:10 So you'd want them in perl-devel? 16:40:42 I don't think perl-devel is required in every case 16:40:45 As long as perl-devel requires perl-rpm-build or whatever, I think it's fine … one BR for arch and another for noarch. 16:41:14 not necessarily, I just want to keep things simple, and consider this proposal to be too complex and bureaucratic 16:42:07 racor: what do you propose for the case where your package doesn't require perl for building, but just ships some perl scripts? 16:43:06 there are three use cases to cover, I think: 16:43:12 Rathann: all perl packages, which run-time require perl-modules to BR: them. 16:43:43 1. perl not required for build, but ships perl scripts -> BR: perl-rpm-build 16:44:00 Rathann: correct. 16:44:11 2. perl (but not perl-devel) required for build -> BR: perl perl-rpm-build 16:44:32 3. perl-devel required for build -> BR: perl-devel perl-rpm-build 16:44:56 Rathann: We seem to talking past each other 16:45:26 The proposal does have perl-macros and perl-srpm-macros too 16:45:51 I was referring to the case of a package which run-time requires perl-modules must also BR: these modules. 16:46:02 why? 16:46:02 racor: Can you think of suggestions for simplifying the proposal? 16:46:07 racor: Why? 16:46:14 Sorry, someone was at the door. 16:46:21 racor: I don't see why it must be true in general 16:46:28 This is to assure these modules are provided. 16:46:42 also it means manually doing for BRs what perl-rpm-build does for Requires: 16:46:47 Rathann: I am 16:47:25 and also that means bloating the buildroot 16:47:28 Rathann: It's a very common case of perl dep breakage 16:47:28 I probably shouldn't have gone off like that, but I don't understand why anyone would think that FPC will just rubber stamp something like this 16:47:37 Oh fun, there already is a (mainly unused) perl-rpm-build-perl package... 16:47:48 LOL 16:48:02 more confusion ahead ;) 16:48:02 nice package name :) 16:48:41 ah it's just badly named 16:49:15 or maybe not 16:49:17 what does it do? 16:49:43 I think it's obvious that the situation is kind of a mess. 16:49:57 B::PerlReq is a back-end module for the Perl compiler that extracts dependencies from Perl source code, based on the internal compiled structure that Perl itself creates after parsing a program. The output of B::PerlReq is suitable for automatic dependency tracking (e.g. for RPM packaging). 16:50:09 I'm not going to quibble over package naming if we have a way out of the mess. 16:50:14 tibb|w: Perl packages follow strict conventions: perl- 16:50:16 Presumably the same thing perl-generators does 16:50:27 racor: Yes, I know. 16:50:35 tibb|w: so perl-rpm-build-perl likely is a cpan module 16:50:45 I mean, I'm not going to quibble over calling the thing perl-rpm-generators or whatever. 16:51:11 tibb|w: or to put it converse: non cpan packages should not be named perl-* 16:51:24 yeah, there is no naming consistency at all in this space currently 16:51:24 I don't think we can get around that. 16:51:34 perl-devel, for example, has existed forever. 16:52:02 And I don't think perl-XXX implies there's a CPAN module called XXX. 16:52:13 Otherwise you could never package anything that isn't on CPAN. 16:52:33 Or anything that isn't actually a Perl module, for that matter. 16:53:31 orionp: the description suggests it is 16:53:32 tibbs|w: FWIW: perl-rpm-build-perl in fact is a CPAN-module. 16:53:58 let's ask what's the difference between those two and if there's little, why they're reinventing the wheel? ;) 16:54:02 anyway, this is just a distraction 16:55:53 hm jplesnik/ppisar/psabata are all (co-)maintainers of both perl-generators and perl-rpm-build-perl 16:56:00 curious 16:59:18 so … what to do? 17:00:05 I'm mostly ok with it as is … even though it could be better 17:00:48 We could ask to cleanup the perl-generators and perl-macros/perl-rpm-build-perl … can take a look at it again? 17:00:51 I noticed the change is a bit more extensive than just introducing perl-generators 17:01:23 AFAIK the diff seems to be: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FPackaging%3APerl%2FBuildRequires&diff=443150&oldid=442425 17:01:31 Which is basically the entire BR section 17:01:34 there's a whole new section about BuildRequires 17:01:37 yes 17:01:43 I'm just concerned that unlike any normal guideline change, we only have a chance to get this right once. 17:01:49 Because they're going to change every package. 17:02:02 I suggest removing perl-srpm-macros since that will always be in the buildroot 17:02:04 I notice the current guidelines prohibit using perl-devel at all 17:02:21 also, why is perl-macros needed to be required explicitly? 17:02:37 * tomspur just had the same question... 17:02:43 Rathann: I agree, esp since perl requires it 17:02:58 But only on EPEL <= 6 (at least to that text) 17:03:37 repoquery --whatrequires perl-macros -> perl-4:5.22.1-360.fc25.x86_64 17:03:39 tomspur: no, it says perl-devel provides perl-macros on EPEL<=6 17:04:14 ah, yes... 17:04:27 right, no perl-macros package in EL6 - even more reason not to mention it... 17:04:38 I don't see the reason for splitting perl-srpm-macros and perl-macros 17:05:02 srpm-macros are for building srpms and must be in every build root 17:05:48 yeah, but what's the harm in having perl-macros as well? 17:06:29 not much, except that they wont work.. 17:06:31 it's just one file in /usr/lib/rpm/macros.d/ with no extra dependencies 17:06:46 huh? why won't they work? 17:06:56 because they call perl 17:06:56 what's the point of the package then if it doesn't work 17:07:06 it should require perl then 17:07:18 ah it does 17:07:22 ok 17:07:26 I see the point now 17:07:30 Which then puts perl in every buildroot. 17:07:33 yup 17:07:34 And that's the issue. 17:07:42 Now, rewrite the Perl generators in Python.... 17:07:43 yes, understood 17:07:49 Problem goes away! 17:07:55 Not volunteering. 17:08:11 hehe 17:08:14 tibbs_: :p 17:08:25 *sigh* 17:08:43 well then at least fold perl-macros with perl-generators/perl-rpm-build-perl 17:08:55 I don't like this proliferation of small packages 17:09:26 https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FPackaging%3APerl%2FBuildRequires&diff=curr&oldid=442425 17:09:40 Removed mention of the macros packages... 17:11:11 #action Cut down on the number of different packages needed for building. Simplify the BR section to cover the 3 cases: 1. perl not required to build, but need generators. 2. perl required for build. 3. perl-devel required for build. 17:11:40 If that fine? Or add anything else for the next tiem we look at this? 17:12:15 If nobody speaks up I'll move onto 621 in a minutes 17:12:58 I'm basically fine with this current draft 17:12:59 it seems both perl-macros and perl-generators/perl-rpm-build-perl are useful only when building packages with perl code, so IMHO it makes sense to combine them 17:13:53 orionp: is there really a change from 'buildrequire' to 'require' in the first part? 17:13:57 agree 17:14:07 The draft could use a lint for grammar. 17:14:31 I think a lot of the conflict here comes from the fact that nobody here was in on the perl-devel discussion. 17:14:39 geppetto: please also add a question about perl-generators vs perl-rpm-build-perl 17:14:41 It was dumb to not mention it to us somehow. 17:14:55 tibbs|w: it was only mentioned in the ticket 17:15:00 I try to follow that list but it's pretty much useless. 17:15:04 #action Also need to know why we have perl-generators and perl-rpm-build-perl 17:15:15 Rathann: yes, that's a correct change 17:15:20 Ok, moving on 17:15:23 #topic #621 Restore Bundled Libraries page 17:15:25 I mean, let us be in on the discussion, instead of having it presented to us as something which was already "complete". 17:15:29 .fpc 621 17:15:29 geppetto: #621 (Restore Bundled Libraries page) – fpc - https://fedorahosted.org/fpc/ticket/621 17:15:45 I'm fine with this. 17:15:47 Rathann: this is you 17:15:53 yes, that's me :) 17:16:21 anything you want to say? 17:16:36 I don't think we want to make any promises about the virtual provides list being complete 17:16:39 But obviously the current page isn't correct, because it still has the old policy. 17:16:54 We should demand of packagers that it be complete. 17:17:06 But sure, we can't ever make any promises about anything in Fedora. 17:17:15 * geppetto gets out his demand stick 17:17:31 tibbs|w: I'd be inclined to move it out of Packaging: namespace so that packagers can add to it themselves 17:17:57 That's reasonable, I think. It's not really policy, but an advocacy document. 17:18:27 yeh, a lot of the wording seems wrong in that regard too 17:18:37 I meant the virtual provides list, but of course you're right about the main document too 17:18:47 there is no power behind it … so it's "we think you should do this, but really you can do whatever you want now" 17:19:09 geppetto: well, not entirely - you MUST add Provides: bundled(foo) for any bundled stuff 17:19:14 Maybe label it some kind of best practice? 17:19:19 sure 17:19:30 Rathann: yeh, in theory … but with no checks I won't be holding my breath. 17:20:40 I thought there was a new tool tracking all source code added into Fedora that would help in this regard 17:20:56 Not really. 17:20:57 but its name escapes me at the moment 17:21:04 Datanommer, maybe? 17:21:17 hm no, the name was a bit more complicated and weird 17:21:24 Right, that's not it. 17:21:27 summershum or something like that 17:21:34 Right. 17:22:11 It says you can easily find bundling with it, but.... 17:22:26 anyway, that's beside the point - I'll simply move the page into the general namespace so that anyone can edit it 17:22:36 Basically you can take a file hash and see if any source packages in the distro include a file with that hash. 17:22:51 Mostly a dead project currently, though. 17:22:57 oh... 17:23:03 too bad, it looked promising 17:23:31 though a similarity metric instead of a hash would work much better 17:24:25 yeh, single hash seems too fragile 17:24:58 Anyway … if it's not under Packaging: then we don't need to vote on it 17:25:17 So is there anything else we should discuss about it Rathann ? 17:25:30 tibbs|w: you said the current page (I assume you meant https://fedoraproject.org/wiki/Packaging:Bundled_Libraries) isn't correct 17:25:40 Right. 17:26:01 "When a Bundled Library is Discovered", for example. 17:26:41 oh, ok, yeah, I can remove that and standard questions 17:27:04 and just leave the treatment subsection here 17:27:08 anything else? 17:27:25 Well, the NEVER bit in the treatment subsection. 17:27:43 I'm actually not sure we care about that currently. 17:28:21 A significant portion of the "Acceptable bundling" section is no longer correct, either. 17:28:49 Since it's pretty much always "acceptable" now. 17:29:15 I regret, but I need to quit now. 17:29:23 Yeah, we're at 90 minutes. 17:29:28 yeah, but if you're actually unbundling then it makes sense to ensure the bundled stuff doesn't get used actually 17:29:32 * geppetto nods … only one more ticket 17:29:41 Seems pretty simple 17:29:48 Rathann: I agree, but the NEVER is really strong. 17:29:54 point taken 17:29:55 I can move to it, as I don't think we need to do anything for Rathann's bundling one anyway 17:30:00 #topic #622 improve description of /run 17:30:04 .fpc 622 17:30:05 geppetto: #622 (improve description of /run) – fpc - https://fedorahosted.org/fpc/ticket/622 17:30:13 I think this is just a simple +1 17:30:20 Also, next Thursday is a public holiday, which means I'll very likely not be able to attend 17:30:27 * geppetto nods 17:30:33 +1 17:30:39 racor: Which holiday? 17:30:42 +1 17:30:44 Just curious. 17:31:16 +1 17:31:45 "Ascension of Jesus" 17:31:45 right, there's also a holiday in Poland next week, but on Tuesday 17:32:02 the Constitution Day 17:32:04 had to look it up from a dictionary 17:32:54 so for the bundling page, is there a general agreement to move it out of Packaging: ? 17:33:30 traditionally used as "Father's Day" 17:34:34 Rathann: I think so 17:35:00 Rathann: We don't realy have any control over it … so it makes sense to not control the page 17:35:20 mbooth: orionp: want to vote on 622? 17:35:32 bye 17:35:33 ok 17:35:42 Rathann: I think it should certainly be somewhere, but not under Packaging: 17:35:51 understood 17:36:18 +1 17:37:34 ok, mbooth last +1 and we can go get lunch ;) 17:37:47 done: https://fedoraproject.org/wiki/Bundled_Libraries 17:38:09 also, dropped most sections according to geppetto's suggestions 17:41:50 mbooth: care to vote? 17:42:10 I need to drop off as well soon 17:42:21 * geppetto nods 17:42:49 mbooth: might already have gone … we can leave it for next week. 17:43:01 Or just a +1 in the ticket will do.... 17:43:08 or vote in the ticket, as it needs just one more +1 to pass 17:43:10 :) 17:43:23 #info improve description of /run (+1:4, 0:0, -1:0) … mbooth, racor, tomspur. didn't vote yet. 17:43:36 #topic Open Floor 17:43:47 I'm assuming nobody has anything left at this point? 17:43:54 nothing new from me 17:43:55 If not I'll close in a minute 17:44:50 Nothing but a note that I've been messing with macros for gpg signature checking. 17:44:52 Still. 17:44:59 ok, cool 17:45:03 * Rathann hopes his unbundling workshop gets accepted for this year's Flock ;) 17:45:13 I've only had a few minutes. There will be a pagure repo when I get something useful working. 17:45:29 * geppetto nods 17:45:35 Rathann: good luck 17:46:01 #endmeeting