17:00:22 #startmeeting fpc 17:00:22 Meeting started Thu Nov 19 17:00:22 2015 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:22 The meeting name has been set to 'fpc' 17:00:22 #meetingname fpc 17:00:22 The meeting name has been set to 'fpc' 17:00:22 #topic Roll Call 17:00:41 hi 17:00:56 #chair Rathann 17:00:56 Current chairs: Rathann geppetto 17:01:23 limburgher mbooth orionp racor SmootherFr0gZ tomspur: FPC ping 17:01:32 hello 17:01:35 Hi 17:01:37 #chair orionp 17:01:37 Current chairs: Rathann geppetto orionp 17:01:41 #chair mbooth 17:01:41 Current chairs: Rathann geppetto mbooth orionp 17:01:47 #chair racor 17:01:47 Current chairs: Rathann geppetto mbooth orionp racor 17:02:11 Hey 17:04:03 #topic Schedule 17:04:07 https://lists.fedoraproject.org/archives/list/packaging%40lists.fedoraproject.org/thread/L3QD2JPSIIFN2M6BHLJJVLRHTYNR2LFN/ 17:04:16 Welcome to hyperkitty urls :) 17:04:20 Hello 17:04:40 #topic #579 Mention abipkgdiff and abidiff instead of abi-compliance-checker 17:04:45 .fpc 579 17:04:46 geppetto: #579 (Mention abipkgdiff and abidiff in the Packaging Guidelines instead of abi-compliance-checker) – fpc - https://fedorahosted.org/fpc/ticket/579 17:04:54 https://fedorahosted.org/fpc/ticket/579 17:05:44 Dodji: Anything you want to say? 17:09:12 geppetto: Good question :-) 17:09:23 I thought I'd have questions I'd have to anwser 17:09:57 Other than that, I'd guess I'd like to say that I think that we'd make people a favour by mentionning abipkgdiff as an alternative at least 17:10:21 Just to clarify … you do have man pages for the commands, right? 17:10:26 yes 17:10:29 Just only have html/info for the API? 17:10:31 Cool 17:10:46 Dodji: are the man pages included in the main package now? 17:10:49 I think I'll put those manpages back into the package itself 17:10:53 i.e. the one with tools? 17:10:56 as opposed to having in a -doc package 17:11:02 I think Ralf is right 17:11:12 Rathann: sadly, not yet 17:11:15 I agree with him on that point 17:11:24 yes I agree with him too 17:11:44 we generate manpage, html, info documentation :-) 17:11:55 * geppetto nods 17:11:55 it's a shame to not just put those in the package directly :-) 17:12:02 yan, info and manpages belong in the main package 17:12:03 I'm +1 on the draft 17:12:27 orionp: API info docs too? 17:12:39 Having html in *doc is fine, IMO. 17:12:49 No, I didn't say that :) 17:13:29 racor: yeah, ok, noted. 17:13:46 I'll do that. 17:13:56 +1 on the draft from me also 17:13:57 I think a mention of abi-compliance-checker is still warranted, even if not preferred 17:14:23 orionp: I am not against that, fwiw. 17:14:28 you could move the tools to libabigail-tools along with manpages and info pages 17:14:55 Dodji: FYI: The original purpose of *docs packages was to reduce bloat by moving optional docs out of packages. 17:15:37 libabigail-devel and libabigail are multilib'd 17:16:06 racor: I see. 17:17:26 Rathann: Doesn't matter wrt. docs, if they are properly formated (Identical on all archs) 17:18:03 Rathann: actually, I have updated the Fedora (wiki) documentation that talks about ABI comparison at https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_in_a_package 17:18:15 woops, sorry, that was for orionp ^^^ 17:18:24 orionp: and as you can see, in there I mention both tools 17:19:35 So something is going to link to that? 17:20:18 sadly nothing was linking to that before I made the change. 17:23:33 orionp: actually, I think after the change, the packaging guidelines are going to link to that page indirectly, as I have put that page in the same (new) category named "ABI" as the packages that describe abipkgidiff only and a-c-c only ... 17:23:47 racor: it does matter for the binaries though 17:24:44 s/as the packages/as the pages/ 17:26:19 if you install both libabigail.x86_64 and libabigail.i686 you'll only get the x86_64 binaries in /usr/bin 17:26:53 Dodji: Are you tweaking the draft now? 17:26:58 geppetto: no no 17:27:09 geppetto: why? 17:27:52 Well from orionp's point that abi-compliance-checker should still be mentioned … and that nobody else is voting on it as is :) 17:28:17 Also wasn't sure if you were tweaking what it pointed to etc. 17:29:04 My suggestion would be to only link to "How_to_check_for_ABI_changes_in_a_package" in the packaging guidelines 17:29:17 at the appropriate places 17:29:59 okay you want me to do that and update the ticket then? 17:30:12 and then we'll meet again next thursday? 17:30:18 Because other than the FPC having an interest in that people check for ABI/API changes, I don't think we want to care *how* they do it. 17:30:19 so that we don't rush this? 17:30:37 orionp: fair enough 17:30:59 It shouldn't take long, and yours is the only new ticket 17:31:12 okay okay I'll do that then 17:31:16 So if you want to do it now we can wait … but if you'd prefer to wait until next week that's fine 17:32:48 Rathann: are you trying to say, abigail.x86_64 is unable to process i386.rpms? 17:33:42 geppetto: I'd rather wait to do it properly :-) 17:35:19 racor: I didn't say that, though for example chrpath can't 17:35:29 for instance, the guidelines talk about comparing the ABI of a given shared library, whereas the page I linked to above talks about comparing stuff in a package 17:35:47 Dodji: Ok, no problem 17:36:00 so I need a new "indirection" page I think 17:36:03 to do it right 17:36:24 #action Dodji Will tweak the draft for the week after next. 17:36:31 Also, I have no idea if the other FPC members share my view :) 17:36:31 right 17:36:33 Rathann: OK, then the conflicting binaries should not be a problem. It's the normal situation in 100s of packages. 17:36:49 orionp: well, no problem. I just want to improve things :-) 17:36:59 racor: yes, it is, though I do find it a bit weird 17:37:04 and on the ABI front we can only improve from where we at today ;-) 17:37:17 so what you say is already progress from now, IMHO. I'll take that :-) 17:37:30 if there's a use case for running the 32-bit binaries on x86_64 then it should stay as it is 17:37:49 Rathann: are you trying to say, abigail.x86_64 is unable to process i386.rpms? 17:37:52 orionp: I am with you. I actually do not care what tools people use, except that I have a problem in recommending/favoring one. 17:38:03 if the x86_64 binaries can handle 32bit packages then moving them out to -tools would save some space 17:38:04 FWIW, that is not true 17:38:19 I mean, a given abigail can process rpms of any arch 17:38:19 17:38:44 so abigail.x86_64 can process rpms ppc rpms 17:38:49 ok, then there's no need to have two sets of binaries in libabigail.i686 and .x86_64 17:38:54 ppc rpms, sorry. 17:39:12 in the repos 17:39:40 #topic #558 Application/Library distinction and package splitting .fpc 558 https://fedorahosted.org/fpc/ticket/558 17:39:46 thanks guys 17:39:48 ttyl 17:39:49 #topic #558 Application/Library distinction and package splitting 17:39:59 .fpc 558 17:40:00 geppetto: #558 (Application/Library distinction and package splitting) – fpc - https://fedorahosted.org/fpc/ticket/558 17:40:00 https://fedorahosted.org/fpc/ticket/558 17:40:03 It woud be better if the package wasn't named "libabigail" from a multi-lib perspective 17:40:19 why? 17:40:22 Rathann: My wild guess would be, mash (or what ever the tool is) to automatically process multilibs is being confused by the name "libabigail". 17:40:26 orionp: but the upstream project is named like this 17:40:53 hence my suggestion to move the tools to subpackage libabigail-tools 17:41:10 which actually is a common enough practice 17:41:43 Ah, does -tools not get multi-lib mashed? 17:41:49 exactly 17:42:04 only libfoo{,-devel} do get multilibbed 17:42:07 that's the ticket then 17:44:43 geppetto: tibbs is out I think and it doesn't seem there was any progress in #558 17:44:57 * geppetto nods 17:45:02 I just wondered due to the comment 17:45:09 I thought orionp was looking at it too 17:45:33 not me, though I may add -tools to the AppsVsLibs page 17:45:42 Ok 17:45:46 #topic Open Floor 17:45:50 Anything else? 17:48:50 Ok, going to close the meeting in a minute 17:48:59 Thanks for coming everyone … remember no meeting next week due to thanksgiving in the US 17:49:12 So I'll see you again in two weeks. 17:49:14 oh, right 17:49:29 happy Thanksgiving to all US folks, then 17:49:33 :) 17:51:29 #endmeeting