16:05:42 #startmeeting Fedora Packaging Committee 16:05:43 Meeting started Thu Oct 9 16:05:42 2014 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:05:48 #meetingname fpc 16:05:48 The meeting name has been set to 'fpc' 16:05:52 #topic Roll Call 16:06:14 Howdy. 16:06:14 spot: cool, thanks 16:06:29 present 16:06:32 I have to go for a few minutes … should be back in about 10-15 :( 16:06:35 #chair spot tibbs|w geppetto orionp 16:06:35 Current chairs: geppetto orionp spot tibbs|w 16:07:05 spot: new tickets are 459, 460, 461 16:08:26 * spot closes 460 since FESCo closed their respective ticket 16:09:13 * racor is here 16:09:20 #chair racor 16:09:20 Current chairs: geppetto orionp racor spot tibbs|w 16:09:47 SmootherFrOgZ: ping 16:11:07 * SmootherFrOgZ here 16:11:16 #chair SmootherFrOgZ 16:11:16 Current chairs: SmootherFrOgZ geppetto orionp racor spot tibbs|w 16:11:39 Alright. Looks like we have everyone who's available. 16:12:03 #topic Exception for using bundled bullet library for supertuxkart - https://fedorahosted.org/fpc/ticket/459 16:12:47 it looks like there is discussion around this issue happening in bz https://bugzilla.redhat.com/show_bug.cgi?id=1146521 16:13:06 my quick read of it is that the irrlicht and bullet libs that they use are effectively forked for STK 16:14:21 mine too 16:14:23 especially given this upstream statement: "we are now considering using supertuxkart_arrow and supertuxkart_normal_darkness instead of bullet and irrlicht." 16:15:05 Based on that (and their failed attempts to merge changes into the respective upstreams), I'm inclined to simply mark these libs as forked and not bundled. 16:15:34 basically, permit STK to include its forks of bullet and irrlicht. 16:16:48 * spot drops a pin 16:17:00 I agree 16:17:31 I'm leaning towards the "too insignificant to matter" catch-all in any case. 16:17:34 Proposal: Permit supertuxkart to include and use its forks of irrlicht and bullet. 16:17:42 +1 16:17:48 +1 16:18:00 +1 16:18:20 +1 16:18:34 +1 though forking an entire rendering engine seems a poor idea. 16:18:39 Also, isn't the ticket only for bullet? 16:18:50 it is, but irrlicht got pointed out in bz later 16:18:56 might as well hit them both at once. 16:19:28 #action Permit supertuxkart to include and use its forks of irrlicht and bullet. (+1:5, 0:0, -1:0) 16:19:30 tibbs|w: Actually, I think this is a case of an non-cooperative upstream, but like you said ... too unimportant 16:19:30 They also mention glew. 16:20:14 yeah, but i don't know what they're doing there. 16:20:27 should they fork glew, I'll change my vote to -1 and demand to ban this package 16:20:43 I'll add some wording around not forking glew without very good reasons. 16:21:06 I shouldn't have read that bug. 16:21:17 comment 3 makes me wonder why we package this at all. 16:21:21 #topic Code Fragments - Bundling or Not for Binwalk - https://fedorahosted.org/fpc/ticket/461 16:22:31 i really wonder why binwalk is bundling bits of ncompress and minizip 16:23:09 i guess for ncompress, there is no library 16:25:32 and tinfl.c isn't actually in minizip, its in miniz 16:25:33 sorry I'm late 16:25:39 which is designed to be bundled code. 16:25:46 #chair Rathann 16:25:46 Current chairs: Rathann SmootherFrOgZ geppetto orionp racor spot tibbs|w 16:27:08 where do you see that it is designed to be bundled? 16:27:26 I guess we can consider adding both to the copylibs list if there's no alternative. 16:27:37 I think in the ncompress case, since there is no library, the bundling is the only way to get what they want. 16:28:22 at least for now 16:28:41 its a header file library. 16:28:46 there is no .h/.c split 16:29:05 I suppose we could make a miniz package that packaged the .c in the -devel bits 16:31:25 anyone have an opinion on whether we should require a miniz lib package here, or whether we should consider it a copylib? 16:31:35 i can't imagine the package would be hard to make. 16:31:56 then again, i'm so buried at the moment, i'm not volunteering to make it. 16:31:56 I dont' mind treating it as a static only lib 16:32:00 or just shipping it 16:32:03 If it's easy to make, I guess it would be preferable as we've had security issues with compression stuff before. 16:32:32 dealing with arbitrary user input is high-risk 16:32:40 I'd prefer a lib package 16:32:50 so I'd be inclined to require a lib package 16:33:44 Proposal: Permit ncompress fragment bundling, require miniz library package be created and used instead of bundled snippet. 16:34:17 +1 16:34:22 +1 16:34:41 +1 16:34:54 +1 16:35:14 +1 I guess 16:35:56 orionp, racor, feel free to chime in for the record. 16:36:10 +1 16:37:31 #action: Permit ncompress fragment bundling, require miniz library package be created and used instead of bundled snippet. (+1:6, 0:0, -1:0) 16:37:41 #action Permit ncompress fragment bundling, require miniz library package be created and used instead of bundled snippet. (+1:6, 0:0, -1:0) 16:38:21 okay, thats 459-461. 16:38:31 Are there any older tickets that we can work on today? 16:39:19 458 16:39:56 #topic Man page scriptlets draft - https://fedorahosted.org/fpc/ticket/458 16:40:23 I forgot to paste in my stuff until this morning, sigh, but it's there now. 16:40:23 draft is in comment 2 (thanks tibbs|w) 16:40:31 looks sane to me. +1 16:40:43 right, I read that already, so +1 16:41:10 +1 16:41:24 +1 since I wrote it. 16:41:39 just for the record - there is no scriptlet and this won't be in the scriptlet section, right? 16:41:50 that is correct, no scriptlet. 16:42:11 Right, my proposal only replaces the existing man page section. 16:42:12 it'll go into the man pages section of the main guidelines 16:42:23 +1 16:42:24 I don't know how scriptlets got involved. 16:42:38 probably someone who doesn't know what a scriptlet is (how lucky they are) 16:42:51 sorry, distracted on the phne, trying to catch up. 16:43:12 +1 16:43:17 we're at +6 on the man page draft text 16:44:05 +1 to man-page draft 16:44:12 #action Man page guideline draft in comment 2 is approved (+1:7, 0:0, -1:0) 16:45:11 okay. any other older tickets? 16:45:39 * spot has been AWOL for ... a while, due to work, so i'm not sure what is waiting on FPC vs waiting on someone else 16:46:24 #topic Open Floor 16:46:28 * nirik wanted to note/summarize the recent fesco ticket about 'FPC not working' for those that didn't follow it. Or perhaps you all did? 16:46:43 nirik: go ahead 16:46:54 Once we're done, what state is 440 in? 16:47:23 basically fesco asked for wider discussion before anything... so expect a devel list thread soon about perceived issues and such... would be great if you all could weigh in on that when it appears. 16:47:30 I at least didn't follow the fesco stuff. 16:49:04 I read the ticket 16:49:58 i followed a bit of it, but I think the following points are still worth noting 16:50:14 1) FPC works when people participate (on both sides) 16:50:37 some of the tickets referenced (go, SCL) made no progress due to lack of community involvement 16:50:55 * nirik nods 16:51:05 2) FPC is a pretty thankless job. Before FPC, things were... ugly. 16:51:19 it's easy to look at what we have now and think that FPC is not necessary. 16:51:50 remember ftp contrib.redhat.com. ;) 16:52:56 * orionp agrees with spot 16:53:16 i personally don't think there is a sensible model where we have packages officially in Fedora that don't meet guidelines. (I'm not considering copr builds to be official in this context) 16:53:49 i'd much rather prefer healthy discussions around places where our community feels the guidelines are unreasonable 16:54:08 and if there are clear exception cases, document them as permitted and move on 16:54:19 I mostly agree with spot, although I'm more open to a grey area … where we ship "extra" repos. that aren't enabled, and they don't have to follow the guidlines for whatever crazy reasons 16:54:31 that, in my mind, requires either an FPC or some other structured group. 16:55:01 there was also some discussion about improving tools... ie, so things that don't meet guidelines just don't build so people have to fix them 16:55:16 but thats potentially a lot of work 16:55:19 now, we could run Packaging FADs to try to get through bigger issues. We did those a long long time ago. 16:55:23 Although I doubt it's a good idea even then, and I think that all enabled by default repos. need to follow the rules 16:55:35 * spot is open to helping with that 16:55:35 geppetto: I'm not sure with extra repo, people might abuse and only populate this repo to avoid having to deal with FPC approval 16:56:01 well, the stacks and env group was talking about a 'playground' repo. 16:56:08 but it would be populated with copr's 16:56:31 nirik: whether that is permitted to be enabled by default is up to FESCo (IMHO) 16:56:32 also there was talk about relaxing bundling guidelines... 16:56:42 but there is always lots of talk. ;) 16:56:54 SmootherFrOgZ: yeh, but at least there's a hard line of "you enabled crap repo." 16:56:56 yeah. i think the bundling discussion is something that might be worth having. 16:57:06 spot: right, and FPC has no interest in guidelines for it, that would be stacks group right? 16:57:07 nirik: define "relacing bundlibg guidelines" 16:57:47 nirik: for a "stacks" only optional repo not enabled by default? i think we'd defer to FESCo on that. 16:57:57 SmootherFrOgZ: relaxing. as in allowing some cases with some provides or something. Not sure how all it would work. Some folks see FPC as slowing down those packages that need an exception currently. 16:58:28 the way I see it, Fedora is made up of things built via koji, and anything built via koji should be guidelines compliant. 16:58:39 if any of those truths change, we'd need to re-evaluate. 16:58:55 nirik: hm, huh, people always want to get thing right away :( 16:59:22 +1 with packages coming from koji 16:59:23 spot: yeah, I would agree. 16:59:45 things built via copr are permitted to do anything (except be illegal) 17:00:05 yep. it's the wild wild west there. :) 17:00:38 any other thoughts before we look at 440? 17:01:15 * nirik has nothing, just wanted to keep communication flowing. :) 17:01:59 #topic mimeinfo scriptlet update - https://fedorahosted.org/fpc/ticket/440 17:02:14 looks like we approved this draft, then rdieter made a minor change to the draft 17:02:27 and like most of our drafts, is sitting in a pile labeled "to write up" 17:02:55 my only concern with rdieter's change is the -n part 17:03:00 which will only work on F21+ 17:03:46 but i'm not sure if there is a good macro way to say "if fedora && if fedora > 21" 17:03:49 * rdieter waves, sorry for the post edit, I don't care which version is used... but when I started updating packages (which ended up being a *lot* more than I had anticipated), I went with the one that was easier to mass update (ie, easiest to copy-n-paste) 17:04:09 Ugh, finally off the phone with lawyers. 17:04:23 spot: it should work for all fedora releases now 17:04:30 rdieter: oh, good, never mind then. 17:04:39 well, those with updates enabled at least 17:04:41 so i think we just need to write this up. 17:04:59 * spot marks it as ready for writeup 17:05:07 #topic Back log of writeups 17:05:24 We need to start merging approved drafts into the wiki. 17:05:34 everyone on the FPC should have the access to do this 17:05:42 traditionally, me or toshio did these 17:05:52 but lately, with toshio gone and me, well, effectively gone 17:06:04 yeh 17:06:07 it would be very helpful if other FPC members could start helping out here 17:06:39 * SmootherFrOgZ nods 17:06:49 bonus: you'll work your way towards the wiki editing badges. ;) 17:07:37 ha 17:08:38 if everyone did 1 writeup a week we'd clear the backlog in no time 17:08:38 Does the process entail more than just updating the wiki? 17:08:53 announcing as well? 17:08:57 * Rathann promises to do one by the end of the week 17:09:01 spot used to email and update to fedora-devel 17:09:23 devel-announce seems right to me... 17:09:40 Seems like we still want only a single announcement for a batch of changes? 17:10:52 Well, I guess N announcements is better than none 17:11:47 perhaps start a wiki page that is queued announcements 17:12:09 That could work. 17:12:14 So perhaps we can assign tickets to ourselves when we go to write them up? 17:12:20 works for me 17:12:39 lots of tickets are assigned to me or abadger1999, please don't assume either is true 17:12:40 :) 17:13:06 If I find time to write up something, i'll add a comment 17:13:58 #topic Open Floor 2 - Electric Boogaloo 17:14:11 one last chance to tell us we suck^Wrock 17:14:32 should we weigh in on rpm weak deps? 17:14:39 Well, stuff got done today. 17:14:51 one sec, being pulled afk 17:16:55 orionp: what about them? 17:17:19 * Rathann is now familiar with the "Electric Boogaloo" meme 17:17:20 There seems to be discussion about whether to allow them in Fedora packages 17:17:22 orionp: I would assume we'd want to allow them after dnf goes live 17:17:43 does dnf support them in any way already? 17:18:01 AFAIK it's still missing a couple of yum features 17:18:34 and not just dnf, but PackageKit and guis? 17:19:04 Although it's a cart/horse problem 17:19:14 Allowing them in rpm isn't the problem, the problem is using them 17:19:45 orionp: I don't think so. We need a spec to define the desired behavior, 17:20:03 I don't see the point in allowing them before they're testable 17:20:34 * nirik notes some packages are already using them... 3-4 or so 17:20:39 once it's possible, then we can discuss (and I'll probably vote +1) 17:20:47 Well, when dnf goes live PK will only be using the libhawkey part … so that's going to be a disaster anyway 17:20:51 Rathann: What do you want to test for if you don't know what is the nominal behavior 17:20:52 I'm most concerned about them breaking things now 17:21:08 orionp: So am I. 17:21:20 orionp: that was my concern as well... but it might be that they aren't... I'm not sure how they are being used, need to read the info on the list 17:21:39 orionp: Right, which is why I don't think we should do anything until after dnf is live … that way we can know all the differences between dnf/yum aren't due to soft/clever deps. 17:21:47 Yeah, I think we need data, but I also think the FPC needs to be involved 17:21:52 Am also concerned about different expectations mushrooming 17:22:40 racor: I thought their meaning was defined already upstream 17:22:50 ATM, I am not even sure, the implementation in rpm is useful ;) 17:23:13 http://rpm.org/wiki/PackagerDocs/Dependencies 17:23:21 (at the very bottom of the page) 17:23:24 racor: by the way, could you look at my private message (/query)? 17:23:24 Rathann: To rpm they are just database tags without any semantics 17:23:45 * Rathann read that one some time ago 17:23:46 but thats not very exacting on how dnf implements them 17:24:25 nirik: I wasn't aware about this doc until somebody else mentioned it earlier today, I haven't read it yet :( 17:25:02 nirik: dnf implements them by turning a flag on in libsolv (the SuSE thing). So docs. for zypper/libsolv might help. 17:25:20 racor: yeah, me either. (before the thread on the list mentioned it) 17:25:26 nirik: AIUI it's basically … when turned on they work like requires, except if they fail it can just drop them. 17:25:35 ok 17:25:52 Although I'm not sure if it removes stuff if they work and then fail, or if dnf fails that upgrade. 17:26:22 the new dnf guy might know, but I'm not sure even the original dnf guy would without testing it. 17:26:43 racor: they mirror what Debian has (https://www.debian.org/doc/debian-policy/ch-relationships.html) 17:27:40 what debian has that we do not have is two things 17:27:53 A) the idea of a user customized behavior pattern for dealing with the softness 17:28:03 B) the idea of user interactivity at package install 17:28:30 true, however that rpm page says: 17:28:32 without A or B in fedora, softdeps are completely pointless. 17:28:38 In addition there are 4 dependencies that are completely ignored by rpm itself. Their purpose is to be used by dependency solvers to make choices about what packages to install. They come it two different levels of strength: 17:28:38 Weak: By default the dependency solver shall try to fullfill them. If this is not possible then they shold be ignored and not trigger an error or warning. 17:28:38 Very weak: By default the dependency solver shall ignore them. But they may be used to show the matching packages as option to the user. 17:28:55 "by default" suggest it might be user-customizable 17:29:02 I'd like to point out that I'm not particularly interested in how they work or don't, but whether the FPC should weigh in on whether they should be in Fedora rpms at the moment. 17:29:24 orionp: i think that if FESCo says "support soft deps" we'd draft the guidelines. 17:29:53 but i'd caution FESCo to not simply say that without understanding _HOW_ users are supposed to interact with them. 17:30:10 especially in kickstart scenarios. :) 17:30:22 looking at the packages that use them now... bcfg2 is a false positive (it's in a block that excludes it), ceph seems wrong.... Recommends: logrotate, but it installs logrotate files, that should be requires no? 17:30:25 And "we'd draft the guidelines" is a loaded phrase. 17:30:59 geppetto: well, in as much as we'd either do that or tell FESCo that we were unable to meet consensus 17:32:46 spot: I meant more that they can't just wave a wand and assume someone on FPC will have time to create all the policy 17:32:52 true. 17:32:58 spot: kind of gets back to the FPC is broken thing 17:33:12 it would be nice to have whomever from RPM thought softdeps were useful to draft HOW. ;) 17:33:50 or someone from dnf 17:34:32 and looking at dreamchess (the other one using them) they don't actually work. 17:35:03 dnf and yum provide the same list of packages they would install, and dnf doesn't follow the Suggests. Whee. 17:35:28 nirik: that might be intentional 17:35:41 nirik: AIUI they are _very_ easily enabled on the DNF side 17:35:57 Either with a code change to add a flag, or maybe even a user configurable option 17:36:24 But I'd almost certainly told them not to enable it until FPC said they should 17:36:48 for whatever my opinion was worth anyway :-o 17:36:53 ok, thats very handy to know, then enabling them in packages now just does nothing at all and won't break people. 17:37:07 I was thinking it would cause people to get different results and cause confusion 17:38:14 nirik: That's one of the concerns I have about weak deps. They are spanning up another dimension of dep-tracking. 17:38:33 yeah. 17:39:55 This would have to be reflected to repoclosure, repoquery etc. 17:40:21 racor: no, at least as long as yum doesn't enable them 17:40:42 racor: Well, as I said above … at least for install DNF will just drop them if they don't solve. 17:40:58 gepetto: Well, I don't see sense in this. 17:41:14 racor: Ofc. how that works once you have things installed that need updates is another question. 17:41:48 AIUI Weak deps. are kind of useful in a few cases … the bug thing is that they plan on adding "clever deps." or whatever you want to call them, soon after 17:41:58 geppetto: You'd have to check repos for consistency of weak deps as well and to diagnose conflicts/non-fulfilable weak deps ... 17:42:15 Which build on the weak deps. work to allow you to say things like "Require Y if X is installed" 17:42:55 racor: yeh, but then AFAIK dnf guys haven't created a repoclose type app. yet anyway 17:43:17 Anyway … I think we can all agree this is all future stuff 17:43:48 F22 is when DNF should land, assuming everything goes fine we can talk about all the new stuff after that. 17:43:49 geppetto: why doesn't this not surprise me? ;) 17:44:10 racor: You are old and cynical, like everyone on FPC ;) 17:44:21 racor: ACK ;) 17:45:44 Anyway, I once more reget having to quit for today. 17:45:53 bye 17:47:24 i think we're done for today anyways 17:47:27 thanks everyone. :) 17:47:53 * spot will not be here next week, because I will be on a plane coming back from Düsseldorf 17:48:23 #endmeeting