16:00:25 #startmeeting Fedora Packaging Committee 16:00:25 Meeting started Thu Jun 5 16:00:25 2014 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:28 #meetingname fpc 16:00:28 The meeting name has been set to 'fpc' 16:00:31 #topic Roll Call 16:02:16 * geppetto is here 16:02:23 abadger1999, RemiFedora, SmootherFrOgZ, tibbs: ping 16:02:28 Howdy. 16:02:35 * RemiFedora exhausted but here 16:02:52 * Rathann is semi-here 16:03:08 #char RemiFedora geppetto tibbs|w 16:03:13 haha, char. 16:03:16 #chair RemiFedora geppetto tibbs|w 16:03:16 Current chairs: RemiFedora geppetto spot tibbs|w 16:03:25 * spot cooks everyone present to a nice crisp 16:03:35 Greetings 16:03:41 #chair abadger1999 16:03:41 Current chairs: RemiFedora abadger1999 geppetto spot tibbs|w 16:03:46 is it bad that my first thought was of the C type? 16:03:47 * SmootherFrOgZ is around (in a day-job meeting at the same time, if you see me lagging on reponses) 16:04:01 #chair SmootherFrOgZ 16:04:01 Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto spot tibbs|w 16:04:02 GM says: spot, you are now a dragon. 16:04:09 WOOOOOOOO 16:04:12 geppetto, it's critical 16:04:37 #chair Rathann 16:04:37 Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto spot tibbs|w 16:04:39 In my defense … I don't have small human trying to set fire to my house ;) 16:04:58 geppetto: ugh. my house still smells awful. 16:05:35 okay, we've got enough, lets get rolling. 16:05:52 #topic software collections in Fedora - https://fedorahosted.org/fpc/ticket/339 16:06:23 any action items here or are we waiting on mmaslano? 16:07:15 didn't she respond … does she have more to do? 16:07:33 I think there is a problem with proposed naming 16:07:48 if i'm reading it right, #4 needs an updated template from her, and whoever the "naming SCL team" is wants to rework the naming proposal 16:08:04 AFAIK, we're waiting on a few blockers. The bug I've mentioned in meetings abot /var/opt/$vendor and /etc/opt/$vendor; information from RemiFedora about scldevel subpackage, a few other things... 16:08:12 It was in my list of blockers from a few meetings ago. 16:08:21 :-/ 16:08:21 i discussed a bit with her yesterday.. its not necessarily a problem with current naming proposal just needs some more eval 16:08:30 k. 16:08:45 I sent in a request for /opt/fedora from LANANANANANA a while ago without any response 16:08:50 langdon: So we don't need to take another vote on dots in name or anything else related to naming now? 16:08:52 i think we should just use it. 16:09:18 abadger1999: not today, hopefully next meeting 16:09:29 spot: yeah... we can ping orc_fedo as well. 16:09:39 there is also a question about consistency of vendor=fedora in path and vendor=fdr in package name 16:09:41 langdon: oaky -- do you know what hte changes encompass? 16:09:54 * abadger1999 wants to get a feel for just how controversial it will be. 16:10:19 RemiFedora: Well... if that's the case, we probably should go with fdr in the path as well. 16:10:33 There's alrady a bunch of packages that have fedora as a prefix to the package name 16:10:52 abadger1999: maybe nothing, i just wanted to be sure that the customer use cases are satisified and i am not sure we have all of them yet 16:10:58 langdon: k 16:11:24 langdon: Did the SCL team look at hte problematic case of naming when there's interdependents among scls at all 16:11:50 abadger1999: you mean when one scl depends on another? 16:11:50 langdon: We couldn't find a non-ugly way of dealing with that... I think we're ignoring it for now but it will bite us eventually. 16:12:58 langdon: yeah -- one scl depends on another and you might want multiple versions of that software where one depends on $OTHER-scl1.0 and the other version depends on $OTHER-scl2.0 (or maybe more realistically, $SYSTEM-PACKAGE-2.0) 16:13:51 abadger1999: yeah.. i wanted to poke at that a bit more.. i am worried about the "biting part".. 16:14:11 abadger1999: like it might be a lot sooner than "eventually" 16:14:18 :-( 16:14:35 Well, let us know if you come up with some ideas... I'm aroiund to bounce ideas off of. 16:15:08 abadger1999: yeah.. for sure.. 16:15:42 okay, seems like no actions on our end for this week... right? 16:15:48 So... Re: LANANA -- I can contact orc_fedo -- do we want to do that npow and ask for fedora or do we want to hold off and ask for fdr? 16:16:03 or both (red hat has both redhat and rht) 16:16:14 spot: not being a "real" person, i can't say.. but i would recommend wait 16:16:23 probably both... already spent too much time waiting 16:16:52 how about just /opt/fedora 16:16:54 for now 16:17:02 we can add /opt/fdr if it is an issue. 16:17:41 k. I'll ping him about getting /opt/fedora registered with LANANA. 16:18:00 #action abadger1999 to ping orc_fedo (LSB contact) about getting /opt/fedora registered with LANANA 16:18:22 #topic Go Packaging Guidelines Draft - https://fedorahosted.org/fpc/ticket/382 16:18:35 status - still waiting on update from go peoples. 16:18:55 #action tabling until next week 16:19:28 #topic Exception for bundled library FoX in exciting - https://fedorahosted.org/fpc/ticket/400 16:19:53 I made a package for FoX which marcindulak confirmed worked with exciting, and he took it to review. 16:19:59 Thanks spot! 16:20:32 I'm going to close out that ticket, since the exception is no longer needed. 16:20:43 #action FoX package in review, exception no longer needed. 16:21:21 #topic Please consider requiring AppData for all desktop applications - https://fedorahosted.org/fpc/ticket/414 16:22:07 is there a draft in there somewhere? 16:22:49 https://fedorahosted.org/fpc/ticket/414#comment:3 16:23:15 That's the update to the .desktop guidelines. rhughes was going to propose a new AppData draft after we approvd that 16:23:44 geppetto: So I thought we were discussing something slightly different 16:24:22 * spot is unsure why the change in comment:3 is relevant 16:24:32 Maybe something more like: "If a package contains a GUI application, that the packager wants to be found and started directly by the user then it MUST also include a properly installed .desktop file. " 16:24:58 the intent of that rule was to mandate .desktop files for all packaged GUI applications. 16:25:00 sounds better 16:25:05 abadger1999: isn't that what I said ?:-o 16:25:15 I thought what we were aiming for was both .desktop and AppData were going to be about hte packager choosing whether they want the packaged software to show up in some other service. 16:25:17 when we add things like "that the packager wants to be found and started".... 16:25:24 abadger1999: I guess the s/that could be/that the packager wants/ ? 16:25:25 aren't we just making a loophole? 16:25:33 What the draft says is "If a package contains a GUI application, that could be found and started directly by the user " 16:25:50 which seems like it's not a packager decision... it's a quality of the application. 16:26:00 abadger1999: because it isn't. 16:26:20 if you're packaging a GUI app (opens an X window, runs from within it), include a desktop file. 16:26:26 Don't want people to use it? Don't package it. 16:26:26 spot: yes, I think we are crafting a loophole... at least, that was the impression I had of what people wanted to do. 16:26:44 abadger1999: I guess I was looking at it differently … I was thinking more that if upstream doesn't really want a desktop/appdata … the packager shouldn't force it on them 16:27:12 spot: so where this came up in relation to AppData is -- rhughes wants to not display packages in the gnome-software center if it doesn't have AppData. 16:27:15 abadger1999: But your wording sounds more like … even if upstream wants it, the packager can not bother if they want 16:27:51 geppetto: Yeah, that was what I thought we meant... but I'm flexible 16:28:03 abadger1999: i suppose that's his prerogative. i'm guessing he doesn't want the desktop files if there is no appdata? 16:28:31 * spot doesn't see how A leads to B there... 16:28:54 spot: So he wanted guidelines that forced packagers to add an AppData file so they'd display properly in gnome-software center. 16:29:05 * spot has no issue requiring appdata to go with .desktop files 16:29:17 And it seemed like the .desktop file guidelines were asking for a similar forcing of adding a .desktop file. 16:29:31 but i don't want to add loopholes for people to not include desktop files with GUI apps 16:30:19 In an FPC meeting, people thought that the intention of the .desktop section wasn't to force people to do that but merely to make the packager recognize that they had to add a .desktop iff they wanted to appear in the menus. 16:30:19 Does xmessage require a .desktop file? 16:31:05 I think that tibbs|w was the ones who originally mentioned thinking that was the intention. 16:31:20 tomprince: not really, it doesn't "run" from within the window. 16:31:25 tibbs|w: Did I misinterpret what you were trying to say? 16:31:26 That was a long time ago, but yes. 16:31:38 Well, no, you didn't misinterpret. 16:31:50 k 16:32:33 * spot wrote that wording a million years ago, and it was absolutely my intention to have the desktop files so that GUI apps would appear in a findable way to the end-user 16:33:32 we had a real problem where people were not bothering with it and users didn't understand why they had installed foo but it wasn't in the menus. 16:33:53 "just open xterm and launch it" is not acceptable, since it is not 2001. 16:34:44 wow 16:35:15 I think there are probably some situations where that still makes sense, but they should be pretty rare these days. 16:35:15 * spot turns off the wayback machine. :) 16:35:54 tibbs|w: nevertheless, i see no real need to add any sort of explicit loophole to the requirement for desktop files to go with GUI apps 16:36:25 99% of apps will have desktop files from upstream, 1% can add them. 16:36:59 I would also support changing "properly installed .desktop file" to "properly installed .desktop file and AppData file" 16:37:21 (assuming we get some additional material on how to make/handle AppData) 16:38:18 So let's take a straw poll on whether we want to add a loophole for .desktop and then we can decide how AppData fits in? 16:38:20 Straw poll: should we modify the .desktop guidelines to make adding a .desktop file for GUI apps optional? 16:38:22 -1 16:38:29 -1 16:38:44 -1 16:38:49 -1, I guess. 16:38:58 -1 16:39:20 Exceptions should be damn rare these days, and can be dealt with as any other exception to the guidelines. 16:39:26 tibbs|w: agreed 16:39:28 16:39:34 And that's 5 so it's quorum. 16:39:41 So AppData... 16:40:01 it's similar in that it's multiple packages fitting in with one piece of software at runtime. 16:40:04 I think AppData should stay optional for a few release 16:40:31 * spot has no issue making AppData inclusion a SHOULD, it just means most people won't bother. SHOULD == WILL NOT in practice. 16:40:41 16:40:47 I have to agree that it shouldn't be mandatory. 16:41:05 spot: I agree with both parts of that statement. 16:41:11 I mean, someone comes up with some random new standard, thousands of packages have to adopt it. 16:41:16 does anyone use software center? 16:41:28 I don't even use gnome. 16:41:32 * spot is sure _someone_ uses it. 16:41:32 I don't and probably will never 16:41:33 I mean … in the FPC … are any of you using it a significant amount? 16:41:48 * langdon did a couple times! 16:41:50 I don't think we're the target, though. 16:41:55 tibbs|w: yeah, i agree 16:42:10 arguably, we're not the target for desktop files either. ;) 16:42:17 Ok … so I'm kind of worried that desktop == no exceptions allowed, and appdata == exceptions allowed … is coming from the fact that nobody here uses appdata 16:42:30 I do launch things from the menu occasionally, and I'm sure my users do all the time. 16:42:33 geppetto: I don't even know where to begin with installing it... would I need to run gnome to use it? Does have a cli? I don't know anything about it... 16:42:56 So, yeah, I think we are the target audience for desktop files. But my users will never use the software center, because they don't have the ability to install anything. 16:43:16 tibbs|w: in current fedora, users can install packages without admin perms 16:43:21 (at least in gnome) 16:43:29 via the software center 16:43:31 FFS I hope not. 16:43:38 spot: I thought that was turned off 16:43:40 they can't _uninstall_ 16:43:45 spot: because it's all or nothing 16:43:48 that was my understanding. 16:43:53 Things get crazier all the time. 16:43:57 spot: unlike in ubuntu where they can install just games or something 16:44:09 * spot is admittedly disconnected from the particular drugs those people seem to be taking 16:44:19 spot: the idea being you didn't want users being able to install random security problem servers 16:44:28 :) 16:44:29 two cents, I have used software center and it is definitely a little glaring when some apps dont have screenshots.. especially featured ones.. it is kinda nice for discovery 16:44:33 geppetto: i don't think they're in the SC 16:45:24 I thought there was the ability to do updates but nothing else... but I admit I don't run gnome so I have never tested any of that. 16:45:44 as much as I don't care about the SC, i don't see why we can't try to be consistent re: desktop files and appdata. 16:46:18 So one questoin that bothers me... 16:46:20 spot, because 99,5% of upstream have .desktop, which is really different 16:46:26 if there was a draft for how to handle appdata, i'd be supportive of a SHOULD or a MUST include appdata. 16:46:39 RemiFedora: true, but when we made the .desktop rule, it wasn't quite that way 16:46:41 Is there an AppData consumer for anything other than the Workstation Product? 16:46:56 abadger1999: rhughes listed "Apper" from KDE 16:47:05 and having tried to explain need for an appdata file to an upstream... just a nightmare... nobody care for this "fedora only file" 16:47:29 Okay, that makes me feel better about making it mandatory... 16:47:38 I wouldn't wnat to get into a situation where 16:47:53 we could make it a SHOULD, and advise rhughes that A) we really want a draft on how to handle it and B) that he should feel empowered as a provenpackager to add appdata wherever he sees fit 16:47:59 it's mandatory and makes software center work but there's similar software that uses a different standard. 16:48:25 and those don't function correctly so we have to make those redundant data formats mandatory as well. 16:48:33 just a thought... shouldnt the gnome folks be getting their upstream to approve it first? aka free desktop? 16:48:42 isn't that why .desktop is out there? 16:49:10 langdon: i believe this is already done in that way: http://www.freedesktop.org/wiki/Distributions/AppStream/ 16:49:25 appdata is a subset of that 16:49:27 I'd also definitely be okay with a "MUST ACCEPT" a patch to add AppData. 16:49:44 langdon: From the ticket … 89% of gnome is done … but most other desktops have done nothing. 16:49:49 even if we don't make it mandatory for packagers to add AppData to the packages they maintain on their own. 16:50:21 abadger1999: i'm not sure how we word that, i think if we make it a SHOULD and someone else does it, its very unlikely to be removed. 16:50:23 abadger1999: from what I could tell Richard hasn't had a problem with getting patches accepeted … it's just that he's the only one writing them. 16:50:38 spot: it's always kinda kludgey but we've done it at least once before. 16:51:12 * abadger1999 would have to dig through a bunch of meeting logs to figure out where, though. 16:51:53 I think I'd rather worry about that if it is a problem. 16:52:15 it seems unnecessarily antagonistic to assume people will tear out patches to add appdata. 16:52:20 spot: Maybe we should just vote on it as a MUST and see where the votes presently stand. 16:52:31 abadger1999: sure, proposal away. :) 16:53:19 geppetto: was that a "real" number or an example? i assumed it was an example because it was the exact same percentage as the apps not shipping it in fedora... 16:54:10 langdon: I read it as a real number … but, yeh, I see now the 11/89% usage in multiple places so I'm not sure. 16:54:11 Proposal: GUI applications (the same ones that have .desktop files) MUST also ship an AppData file so that their packages show up in application-oriented software installers (Software Center, Apper, etc). 16:54:53 -1 right now, at least. 16:55:16 +0.4... 0, but I could be persuaded up. 16:55:17 -1 (too sonn, will review it in >1 uear) 16:55:50 I'm 0 on that, could be convinced to go +1 16:56:52 I'm +1, even though I don't use it … as it doesn't seem different to the desktop file case, to me. I also worry that too much random stuff will be in app. data, and I have a feeling that SC could do a lot better than it does without app. data. But meh. 16:57:34 The last bit is a long way of saying I'm not going to fight that hard for it, or try to convince anyone to change to +1 16:57:40 * geppetto shrugs 16:57:48 Well, I don't think this will pass today at least. 16:58:08 Proposal: GUI applications (the same ones that have .desktop files) SHOULD also ship an AppData file so that their packages show up in application-oriented software installers (Software Center, Apper, etc). 16:58:15 +1 16:58:17 +1 16:58:27 +1, mostly same reservations/etc. 16:58:33 +1 on should 16:58:51 +1 16:59:02 * spot would want an AppData draft on how to handle/add it before it got written up. 16:59:39 +1, same as spot 16:59:56 and the appdata license seems a mess... 17:00:06 Okay... So FPC is okay with making a guideline that has AppData files as a SHOULD but not a MUST at this point. Please writeup a draft on how they are added (similar to the .desktop file ScriptletSnippets[link]) for us to vote on to go along with this. 17:00:45 wait... what's the license controversy? 17:00:59 i think his appdata licensing is really a bit of a screwup. 17:01:33 appdata have a license tag... so could be different than the app license, make mandaory to have 2 licenses in the spec 17:01:47 he was trying to push for PD licensing for the appdata files at one point 17:01:52 (mostly because appdata is often copied from a templace with CC0) 17:02:29 and after you convince upstream to add the fucking appdata file, you need to also convince them to add a second license file 17:02:38 i'd recommend appdata license matching upstream, but to be fair, if its under a Free license, its not a Fedora blocker. 17:02:58 just annoying to upstream 17:03:18 spot: I'm +1 to the appdata license matching upstream. 17:03:39 Unless I'm mistaken, that's the policy for everything else that we add locally right? 17:04:20 i'm not sure thats actually a policy. 17:04:36 it certainly is good common sense. 17:04:49 FPCA says unlicensed things are MIT 17:05:07 but i don't think we actually say "if you license an addition, it needs to match the upstream" 17:05:23 * spot isn't opposed to saying that in the Appdata case though 17:05:49 appdata is different as the license must explicitly set 17:06:13 RemiFedora: which is why i'd support a requirement of explicit license match when added by Fedora packagers 17:06:50 but that would be part of an appdata draft which currently. does not exist. 17:07:28 #info In the guidelines about adding AppData, please include the requirement for metadata licenses to match the upstream code license if we're creating the AppData file. 17:07:57 Unless someone objects to that, I think that can just be part of what we ask from rhughes. Sound good? 17:07:58 i think the status here is that FPC supports GUI applications (the same ones that have .desktop files) SHOULD also ship an AppData file so that their packages show up in application-oriented software installers (Software Center, Apper, etc). (+1:6, 0:0, -1:0), but needs to see a draft on adding and packaging AppData files in Fedora. 17:08:07 abadger1999: sure 17:08:34 Cool. 17:08:48 abadger1999: can you update the ticket? 17:08:53 spot: yep, I'll do so. 17:09:22 abadger1999: should i assume that the ruby in SCL ticket is blocking on the earlier SCL ticket? 17:09:35 very probably 17:09:47 yeh 17:09:53 spot: It should be independent but it is blocking on its own set of subissues. 17:10:00 abadger1999: okay, fair enough. 17:10:06 dots in name -- but as langdon said, that's all being revisited 17:10:13 we'll just skip this php ticket since no one cares abou... oh hi Remi. :) 17:10:14 We do have something there that we can vote on though 17:10:21 whoops. 17:10:34 #topic ruby193 in SCL - https://fedorahosted.org/fpc/ticket/419 17:10:37 abadger1999: go ahead 17:11:08 https://fedoraproject.org/wiki/User:Toshio/Multiple_packages_with_the_same_base_name%28draft%29 17:11:45 There's two changes in there. One is about dots in name. We can decide that later if it's not the non-contraversial thing I think it is in FPC. 17:12:11 The other is giving approval to using underscore in compat packages when the package's base name ends in a digit. 17:12:17 The example is v8 17:12:26 wher instead of having v8313 17:12:28 yeah, that seems reasonable. 17:12:32 We want to have v8_3.13 17:12:58 ugly, but i can't think of any other way 17:14:09 yeh 17:14:23 Hmm... looks like I messed up the history so that the diff is pretty ugly (by removing all the sections that aren't being modified) 17:14:40 So the diff would be: 17:14:42 https://fedoraproject.org/w/index.php?title=User%3AToshio%2FMultiple_packages_with_the_same_base_name%28draft%29&diff=379342&oldid=379341 17:14:47 Look only at these sections: 17:14:56 === Separators === 17:15:17 {{Anchor|MultiplePackages}} 17:16:02 Note that half of the MultiplePackages section is near the top of that diff's secton and hte other half is down at the bottom of the page. 17:16:24 silly mediawiki 17:16:33 * spot is +1 on the whole draft 17:16:35 +1 17:17:30 looks good, +1 from me 17:17:31 if we approve this for system package... it seems it should also apply to scl... 17:17:50 seems ugly but don't seems better solution so 17:17:51 +1 17:18:19 RemiFedora: yes, it will. that's a major motivation. But if the scl people bring a naming convention to the tbale that makes sense we can change part of the naming guidelines to allow that as well. 17:18:34 +1 17:19:07 * RemiFedora see five 17:19:25 +1 17:19:49 #action abadger1999's draft approved (+1:6, 0:0, -1:0) 17:20:34 #topic PHP Guidelines change - composer/packagist registered packages - https://fedorahosted.org/fpc/ticket/434 17:22:06 as usual, these PHP changes may as well be written in Russian, but they seem sensible enough. :) 17:22:17 notice, lot of package in the repo already have moved away from pear. So I think we "really" need such a guidelines. asap 17:22:27 * spot is +1 on the draft 17:22:46 * geppetto is willing to give RemiFedora a +1 and hope it's all good ;) 17:23:22 "As for other packages, name should only use lowercase, underscore and slash replaced by dash." 17:23:33 That appears to be unrelated to the composer changes. Or is it? 17:23:47 yes this is unrelated 17:23:55 RemiFedora: composer packages are compatible enough to replace pear packages at hte code level? 17:24:17 OK, I didn't know if composer introduces some additional weird naming. 17:24:19 usually, yes (just a move from /usr/share/pear to /usr/share/php, both in default include path) 17:24:38 k 17:24:40 +1 from me 17:25:09 tibbs|w, while pear have a quite high entry level (review before inclusion in the forge) 17:25:24 +1 on draft 17:25:42 anyone can import anything in packagist... so there are a lot of strange things... but composer.json is well defined 17:25:53 +1 (of course, for the record) 17:26:08 I don't completely understand why PEAR packages must have dependencies only on other PEAR packages. 17:26:27 tibbs|w, by design. pear can only pull dep. from pear channel 17:26:49 For that exception to be there, it must actually work if that's not the case. 17:27:16 ? 17:28:24 I just mean that there's an exception for unbundled libraries and such, so things must work if some dependencies aren't available via PEAR. 17:29:11 dependency out of pear doesn't exists in upstream pear package 17:29:12 why are we forbidding requires on php-pear(foo)? 17:30:09 or does it apply only to Composer packages? 17:30:12 so for exemple horde_dav bundles sabre-dav. As we remove this bundles lib, we have to require it outside of php-pear() namespace 17:30:37 yes, "forbidding requires on php-pear(foo)" is only for composer/packagist package 17:30:45 ok 17:31:12 useful to track that nothing require anymore the pear package, so we can drop the temporary provides 17:31:29 +1 17:31:53 #action draft approved (+1:6, 0:0, -1:0) 17:32:31 #topic %py3dir not removed by rpmbuild --clean - https://fedorahosted.org/fpc/ticket/435 17:32:32 It does need a few spelling and grammar fixes, though. 17:32:33 spot, notice than 420, 430 and 434 need a annoucement, I will prepare the text in the FPC ticket (I don't know if I'm allowed to post to annouce) 17:32:48 RemiFedora: feel free to announce and close if you wish 17:32:55 I will do 17:33:01 I don't understand why 435 landed with us. 17:33:07 tibbs|w, fix for my poor english are very welcome ;) 17:33:59 I think 435 needs to be fixed but it's too soon to come to us. 17:34:21 abadger1999: yep. 17:34:21 need input from the python maintainers (past and present) about what to do. 17:34:32 #action tabled until we hear from the python maintainers 17:34:42 #topic Open Floor 17:35:44 If I don't hear anything in the next minute or so, I'll close out the meeting. 17:36:15 spot: the shared lib for dSFMT package has been done but i was too lazy to open up a review. will do it before next week. 17:36:16 Nothing from me. Should I try to lint the PHP draft before it gets written up? 17:36:49 yes please (I will merge it in Guideline tomorrow, and will prepare the announce) 17:38:20 okay, thanks everyone! 17:38:22 #endmeeting