17:00:25 #startmeeting fpc 17:00:25 Meeting started Wed Jul 26 17:00:25 2017 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:25 The meeting name has been set to 'fpc' 17:00:25 #meetingname fpc 17:00:25 #topic Roll Call 17:00:25 The meeting name has been set to 'fpc' 17:00:43 Too many channels. 17:00:48 Yeh 17:01:01 I hadn't realized I'd used meeting-2 in the calendar too 17:01:07 #chair tibbs 17:01:07 Current chairs: geppetto tibbs 17:01:20 Hi 17:01:31 #chair mbooth 17:01:31 Current chairs: geppetto mbooth tibbs 17:02:50 I'll just be in all the rooms all the time :-p 17:02:55 :) 17:04:09 I don't want my channel list to have to scroll. Æsthetics are important. 17:04:39 ha 17:05:05 * mbooth has irc on his portrait monitor :-p 17:05:29 Me, too, along with two cameras, my music player and my browser. 17:05:50 But I have a 34" monitor in portrait mode. 17:05:56 two cameras? 17:06:00 .hello ignatenkobrain 17:06:01 IgorGnatenko: ignatenkobrain 'Igor Gnatenko' 17:06:34 hi 17:06:35 I have security cameras all over the place here. 17:06:43 #chair Rathann 17:06:43 Current chairs: Rathann geppetto mbooth tibbs 17:09:13 limburgher said he would be here. 17:09:33 tibbs: so you switch between them on your camera outputs … like a ninja security guard ? 17:09:35 yeh 17:10:12 I've pinged him again 17:10:27 Ah, there it is 17:10:28 Hi 17:10:44 I just watch the space outside my office door and the nearest elevator lobby. 17:10:52 In the calender entry #fedora-meeting-2 is mentioned 17:10:59 #chair tomspur 17:10:59 Current chairs: Rathann geppetto mbooth tibbs tomspur 17:11:15 yay 17:11:28 yeh, I didn't realize I'd put different channels in the calendar and the emails 17:11:47 I was surprised we had -3 channel ;) 17:11:48 I guess we'll merge to -2 … for two weeks from now :) 17:12:29 #topic Schedule 17:12:31 https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/ITFHNHIPCXAEEMOF7OJRPQ3TXB3HFQ5I/ 17:12:41 #topic #691 noarch *sub*packages with arch-specific dependencies 17:12:44 .fpc 691 17:12:46 geppetto: Issue #691: guidelines change: noarch *sub*packages with arch-specific dependencies - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/691 17:13:30 So, no changes since we talked about it last … anyone spoken to releng? 17:14:52 I don't think so 17:15:38 #topic #693 Wiki:Packaging:RPMMacros 17:15:43 .fpc 693 17:15:44 geppetto: Issue #693: Wiki:Packaging:RPMMacros - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/693 17:16:09 Ok, this one was on tibbs … did you manage anything with holidays etc? 17:16:18 I have basically done nothing at all, sadly. 17:16:27 * limburgher here, late, sorry, call ran over. 17:16:29 I did think about this some more. 17:16:43 #chair limburgher 17:16:43 Current chairs: Rathann geppetto limburgher mbooth tibbs tomspur 17:16:52 Thing is, we really do have to document some of these; I just don't know what needs to be in there. 17:16:56 limburgher: we waited for you, it's all good :) 17:17:06 w0000000h0000 17:17:42 tibbs: ok, want to leave it for next week or talk about some of it? 17:17:44 Seeing how the flatpack macros work by redefining many of these settings, I guess we do need to document the ones that people will be needing to use. 17:18:00 %{_prefix} for sure 17:18:01 The problem is, really, figuring out what to document and what to leave out. 17:18:20 Rathann: It's way more than just %_prefix. 17:18:47 I mean, just that one thing may be redefined, but that changes the definitions of other macros which people will be using. 17:20:00 indeed 17:20:14 But the rest of the work there is still the same: rip out the stuff that really doesn't need to be in there. Rewrite the stuff that does. 17:21:08 Also, I really wish that we could have far more useful names for most of these. 17:21:37 They're so inconsistent. Some have "dir" appended. Some have "path" appended. 17:22:02 lol, good luck fixing any of that 17:22:10 Just saying use %_var %_usr %_lib %_bin is at least readable. 17:22:34 Some of those at least exist now; they're just de-emphasized. 17:22:42 * geppetto nods 17:22:47 right 17:22:49 It's part of the reason I just don't use them (except for %_lib). 17:23:17 Seeing the actual paths everywhere makes things so much more understandable. 17:23:36 yeh, it tends to be pretty ugly with the macros 17:23:52 Right, and poor first time packagers get crazy confused. 17:24:03 And so much of it is useless anyway, just one fix in rpm and 95%+ of it can go 17:24:13 Are you supposed to use them? If several of them mean the same thing, which should I use? 17:24:24 whatever the reviewer wants ;) 17:24:43 I understand that some of it comes from autoconf but... there is plenty of stuff that doesn't use autoconf at all. 17:25:50 I did at least make a start at https://fedoraproject.org/wiki/User:Tibbs/RPMMacros 17:25:53 But it's just a start. 17:25:59 cool 17:26:54 So my plan is to stop emphasizing autoconf-relatedness and instead try to list the macros which are closest to the actual directory name. 17:27:06 Sounds fine to me 17:27:14 good plan 17:27:23 And if I grep the specfiles and can find only a few packages using one of the macros then I just won't list it. 17:27:36 Heh, %_initddir..... 17:27:50 Because we still use init. 17:28:10 move to EPEL:Packaging ;) 17:28:36 Can we just pretend %_localstatedir doesn't exist? 17:28:42 hehe 17:28:48 sure 17:28:50 But now I can't install proprietary-crap-from-2005-14.3-1.i686.rpm!!!!! 17:28:52 I mean, I type fast but "/var".... 17:29:22 Anyway, I have a few minutes today while I do another kernel build so I'll put a little more work into this. 17:29:51 On old systems I call initscripts with /etc/rc.d/init.d/FOO because god knows why. 17:29:56 ok, cool. Can come back to it next week 17:30:14 #topic #696 Many packages are not following the Guidelines for bundled libraries 17:30:19 .fpc 696 17:30:20 geppetto: Issue #696: Many packages are not following the Guidelines for bundled libraries - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/696 17:30:52 limburgher: Because habit. 17:31:20 So I did reply in the ticket. 17:31:36 Yeh, I agree with everything you said 17:31:58 I am really trying to avoid being passive-aggressive with this, though. 17:32:25 can we point to community-maintained wiki page for the list of bundled names that are not packaged in Fedora (and are probably never going to be)? 17:32:39 Does such a page exist? 17:33:18 Basically, I think we should add a note to attempt to follow the versioning and naming guidelines for determine and in that guideline. 17:33:21 https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries 17:33:29 yes, I kept it when we deleted everything about bundling from Packaging: 17:33:31 https://fedoraproject.org/wiki/Bundled_Libraries_Virtual_Provides 17:34:05 But I'm not sure that "Provides: bundled(foo) = 0" is any better than "Provides: bundled(foo)". 17:34:46 "Version can be omitted if it cannot be determined with reasonable effort." 17:34:49 We could also add a note that it is better to use the version from which the bundled version was forked than to use nothing. 17:34:50 something like that? 17:35:15 Thing is, I don't know how these bundled(x) provides are actually being used. 17:35:38 I don't think they are being used by non-humans, are they? 17:35:40 What or who wants to use them? What would actually help them? 17:35:54 I thought they were all just data for repoquery and nothing else 17:36:10 Sure, but this issue was raised for some reason. 17:36:31 I hope it was just more than someone doing a query, finding these things without versions and deciding to ask us to do work. 17:37:08 I think that's exactly what happened 17:37:09 I'd rather not make something up which turns out not to be useful for whatever wants to consume these things. 17:38:23 Can we agree on omitting it, when "it cannot be determined with reasonable effort"? 17:38:48 sure, at least I'm fine with that 17:39:02 If FESCO wants to have a 0 in that case, that might work too... up to FESCO 17:39:11 "= 0" might be better if some tools were looking at it … but AFAIK there are no tools 17:39:44 I would prefer to omit version at all 17:40:10 I don't see any reason why "= 0" is better than without it 17:40:31 +1 17:40:47 +1 to omitting when it can't be reasonably determined. 17:41:23 But I do believe that _some_ information is better than none. 17:41:42 I think we all agree on that 17:42:17 tibbs: Perhaps with some leeway that if a *specific* version cannot be determined, an approximate version with a trailing .0 makes the most sense? 17:42:19 The version of the upstream source which was last merged. Or if there has never been a re-merge of upstream, the version that upstream when the original fork happened. 17:42:37 sgallagh: Sadly 1.1.0 is strictly newer than just "1.1". 17:42:47 e.g. if a package has forked some other package at 1.2.3, but it includes some backported packages from 1.2.6 and 1.2.7, we just call it bundled at 1.2 ? 17:42:57 tibbs: Sorry, I phrased that poorly. 17:43:04 So adding a trailing zero would mean that looking for all foo <= 1.1 wouldn't find 1.1.0. 17:43:09 I meant to go for "lowest common denominator" where reasonable 17:43:32 sgallagh: If it won't mess up sorting, yes, but won't it? 17:44:04 Not sure. I was just trying to figure out how we could maximize information on a search while minimizing packager effort. 17:44:11 If that's not a valid answer, so be it 17:44:35 sgallagh: If you last merged or forked version 1.1, then just saying that you bundle 1.1 should be quite good for all reasonable uses of this bundling information. 17:44:53 Right, that's kind of what I was trying to say. 17:45:03 Though clearly not phrased well :) 17:45:08 If someone finds a security bug in 1.1, that tells them that they need to at least look at your package to see if it has the bug. 17:45:21 tibbs: Yeah, that was exactly where I was going with that 17:45:46 My understanding is that is what these bundled(x) tags are really for. 17:45:52 yes 17:46:13 So just saying "the version that was last merged or forked" should be sufficient, yes? 17:46:48 tibbs: Yes, I agree. That was exactly what I was trying (and failing) to communicate when I said "lowest common denominator") 17:47:06 tibbs: +1 to that 17:47:11 yeh 17:47:20 OK, that's what I'll use. 17:48:11 #info We discussed some wording based on tibbs's comment. 17:48:34 #action tibbs Write up a page for recommendations on provides. 17:48:50 Good? 17:48:50 Fortunately the section is short so this should be easy. 17:54:59 Ok 17:55:04 #topic Open Floor 17:55:18 Anything else anyone wants to talk about in the last 5 minutes? 17:55:36 Not from me. Looks like I have stuff to do. 17:57:34 Not particularly. 17:58:31 Was that really it? 17:59:32 yeh 17:59:36 #endmeeting