17:02:46 #startmeeting Fedora Packaging Committee 17:02:46 Meeting started Wed Feb 6 17:02:46 2013 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:49 #meetingname fpc 17:02:49 The meeting name has been set to 'fpc' 17:02:57 #topic Roll Call 17:03:08 I see limburgher, geppetto, racor, tibbs, abadger1999 17:03:19 greetings 17:03:23 * SmootherFrOgZ is around 17:03:25 here 17:03:37 rdieter: ping? 17:03:59 me as well even if I am not directly responsible for anything I have two tickets in queue :-) 17:04:10 sochotni: 251 and? 17:04:17 252 I believe 17:04:20 though that's low prio 17:04:29 yeah, 252 17:04:43 * SmootherFrOgZ sees only 4 items for today meeting. do you have more? 17:05:04 okay, we have more than quorum 17:05:09 * limburgher contrasts FPC agenda with FESCO agenda for today 17:05:13 Someone was pinging me about some old tickets earlier in the week. 17:05:18 * limburgher feels pretty good right about now 17:05:22 #topic Change BR: maven to BR: maven-local - https://fedorahosted.org/fpc/ticket/251 17:05:41 sochotni: does maven-local exist in F16, F17, F18 ? 17:06:07 * rdieter is 1/2 here , 1/2 occupied @work stuff 17:06:30 spot: just today I've backported package to F17+ 17:06:40 I skipped F16 17:06:48 If it's not in F16, we should probably wait until F16 does EOL. 17:06:50 spot: it exists in all fedoras f16+ 17:06:56 would be nice if that wasn't conditional on f19+ 17:06:59 sochotni: i assume EPEL (EL4, EL5, EL6) does not have it though 17:07:09 spot: there is no maven in epel 17:07:11 spot: EL doesn't have maven at all 17:07:15 easy enough. 17:07:38 I have arranged things with dgilmore so there should be no surprises 17:07:50 In that case this looks pretty painless. 17:09:05 Fedora 16 EOL is Feb 12. 17:09:22 so I think the window of possible pain is very small. I'm fine with making this change now 17:09:23 Meh, probably not worth holding things up. 17:09:25 that was reason why I didn't bother with it 17:09:28 spot: maven-local is in F16 too 17:09:30 +1 to this change 17:09:34 +1 also. 17:09:34 +1 17:09:46 +1 from me 17:09:53 +1 17:10:05 +1 17:10:19 mizdebsk: right, forgotten that it's provided by different package there 17:10:27 but anyway it doesn't matter much :-) 17:10:34 racor, rdieter, if you'd like to vote on the record. 17:10:42 +1 17:10:44 +1 17:10:50 #action Approved (+1:8, 0:0, -1:0) 17:11:00 thanks, we'll get down to it then 17:11:30 #topic Drop Fedora Vendor tag from Desktop files in F19+ - https://fedorahosted.org/fpc/ticket/247 17:11:52 Seems people are just doing this anyway and not caring about the breakage. 17:11:57 I'd like to start off by saying that I hate the vendor tag in the desktop files with a burning passion. 17:12:05 tibbs: doing it on fedora != 19 ? 17:12:05 It should never have been allowed. 17:12:32 I think if we conditionalize it %if 0%{?fedora} > 18 17:12:36 rdieter: I don't see how the release matters. 17:12:49 Guidelines say you cannot change it once you've used it. 17:12:54 then we'll have a one time hit of pain for the people who use tools that make assumptions 17:12:57 tibbs: our current guidelines say on existing releases don't modify vendor, else kill it! 17:13:13 +1 for one time hit of pain. 17:13:20 rdieter: Untrue. 17:13:26 Guidelines say "for the life of the package". 17:13:36 the life of the package *on that release*, no? 17:13:43 No. 17:13:56 http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage 17:13:58 * abadger1999 agrees with tibbs about the current interpretation of the guideline 17:14:00 that was the intent at least (I wrote it), but maybe that verbiage ended up getting removed 17:14:20 sigh 17:14:21 I propose that we amend the guidelines to say that for Fedora 19 and beyond, the vendor tag must not be used. If it was being used in a previous release, it may continue to be used for that previous release, but must be removed in Fedora 19. New packages must not add the vendor tag for any release. 17:14:28 spot: +1 17:14:41 +1 17:14:42 +1 17:14:43 spot: +1 17:14:45 +1 17:14:46 +1 17:14:51 At this point it's more annoying than the breakage. 17:14:57 Any idea how wide a swath this cuts? 17:15:07 There was a repoquery that will show you. 17:15:10 limburgher: i believe that is FESCo's problem. ;) 17:15:13 I saw that. 17:15:27 spot: :) 17:15:36 (which means that two weeks before beta, i'll be committing the changes frantically, but i digress) 17:15:44 +1 17:16:00 geppetto: want to vote on the record? 17:16:05 spot: Feel free to shoot me an email with part of a list if you want extra PP hands. 17:16:11 meh. … sorry was looking away. 17:16:11 I vaguely recall someone throwing around some large number in the hundreds, but I don't see that in the ticket 17:16:25 The piecemeal breakage over the years as people ignored this guideline has been pretty annoying, though. 17:16:26 Was going to ask … is it possible to ship both .desktop files for a release? 17:16:31 Or does that screw thing up? 17:16:38 I do an update and someone complains that some icon of theirs disappeared. 17:16:43 geppetto: that is actually worse. 17:16:49 geppetto: You get doubled entries in various menus. 17:16:53 fair enough … +1 17:17:00 #action spot's proposal approved (+1:8, 0:0, -1:0) 17:18:03 rdieter: the number is hidden in a link contained in comment 4 in trac http://lists.fedoraproject.org/pipermail/packaging/2013-January/008880.html 17:18:10 #topic NodeJS reopened - https://fedorahosted.org/fpc/ticket/246 17:18:23 mentions 618 packages 17:18:30 eep 17:18:36 that's a lot alright 17:18:42 Honestly, with all respect to vondruch, I don't think this merits being revisited. If he (or anyone) wants to propose separate javascript guidelines, they can. 17:19:14 I'm not sure I understand his objection. 17:19:16 the files calling #!/usr/bin/node are almost certainly assuming node, not "any javascript runtime" 17:19:44 so, I propose we reclose the bug. 17:19:55 * rdieter doesn't understand what the problem is either 17:20:01 So, sgallagh mentioned to me at fudcon that almost any JS could be easily adapted to be a nodejs package. 17:20:09 But I'm not sure that addresses vondruch's concern. 17:20:13 Is his complaint simply that there are some javascript-related packages which are not covered by the guideline? 17:20:15 Sounds reasonable. A new one can be opened for js guidelines, be it the mentioned draft or another. 17:20:16 abadger1999: i think thats the opposite. 17:20:25 tibbs: maybe? :) 17:20:28 Because I didn't think it was supposed to cover all of javascript. 17:20:33 If it doesn't, then I'd have to say the package he's talking about is bundling and shouldn't have been approved 17:20:43 it pretty clearly is not intended to cover anything besides node modules 17:20:49 or whatever they call themselves. 17:21:08 spot: well -- coffeescript is listed on the nodejs registry web page thingy. 17:21:34 abadger1999: yes, but just because something can work with node is different from requiring node 17:22:03 is anyone opposed to closing #246? 17:22:43 +1 close. Someone needs to make a draft for server-side js that is not nodejs. 17:22:46 I guess he can clarify his argument and reopen the ticket if he wants. 17:22:48 i hear no objections. 17:23:00 failing that, non-nodejs server side js should be blocked on guidelines. 17:23:30 * SmootherFrOgZ is not 17:24:05 #topic Consider a ban on SysVinit scripts - https://fedorahosted.org/fpc/ticket/243 17:24:24 When we did systemd the first time, there were still packaged and maintained alternatives that used sysvinit 17:24:33 Hence, the subpackage exception 17:24:47 However, since then, I do not believe there are any maintained alternatives 17:25:07 I don't really see the harm in these things 17:25:38 (well, okay, sysv is still maintained, but i don't want to believe anyone is that masochistic) 17:25:54 I'm with tibbs. 17:25:58 On the other side, I don't see the harm in banning sysv scripts in fedora 17:26:17 I think the compromise proposal is that they can be packaged as %doc (and chmod -x) 17:26:48 if someone really wants to use it, it is easy enough for them to copy it into the systemd /etc hierarchy and override the unit file. 17:26:56 sysvinit has: 17:26:59 %if 0 17:27:01 # Disabled for upstart. 17:27:02 %files 17:27:05 [...] 17:27:31 Usually when we get some kind of "Ban it!" request I have to ask if there's something else going on. 17:27:33 spot: +1 (I'm ok without compromise too, for what it's worth) 17:27:38 abadger1999: so, basically, there are no-non systemd interpreters 17:27:39 So I think it's badly butchered. 17:27:41 yeah 17:27:53 s/interpreters/init system/ :-) 17:28:10 Okay. I propose that we drop the exception in the guidelines and reword it to only permit the inclusion of sysv init scripts as %doc. 17:28:23 spot: +1 17:28:25 +1 17:28:42 +1 17:28:46 +1 17:28:48 spot: +1 17:28:52 So we're talking about banning, what, 26 packages here? 17:29:05 I think the main motivation is to wrap up the systemd conversion. 17:29:14 I don't realy like singling out sysvinit... otoh, sysvinit is in a hard place because systemd will read the sysvinit scripts if there's no matching unit file. 17:29:14 tibbs: if a package can't be converted, we can always grant an exception. 17:29:23 err... 17:29:25 i don't think this is a "comply or gtfo" scenario. 17:29:35 I didn't think that was what was beinbg asked 17:29:44 the proposal is only to ban sysvinit support from packages that already have systemd units. 17:29:49 I think there are a couple of things being conflated. 17:29:49 I thought the "separate subpackages" was being asked to be dropped. 17:29:57 One is the separate -sysvinit packages. 17:30:02 abadger1999: yes, sorry, thats what i was referring to. 17:30:07 The other is packages which have not been converted to systemd. 17:30:09 If a package provided sysvinit-style init scripts instead of systemd units, it was fine 17:30:15 abadger1999: yeah. 17:30:30 The title of the ticket and the first sentence talk about different things, which I think is causing confusion. 17:30:44 Each package that contains software that wants/needs to start a traditional service at boot MUST have a systemd unit file. 17:30:53 Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript 17:31:14 thats what the guidelines say now. 17:31:27 I propose that we change that second section to read: 17:32:00 tibbs: Sorry. mea culpa for making the title too generic 17:32:35 Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy. If a package includes a SysV initscript file, it must include it as %doc, and not in the systemd (or old /etc/rc.d/) pathing. 17:34:20 Thoughts? 17:34:56 I guess I'm trying to understand why 26 packages are shipping -sysvinit subpackages right now. 17:34:58 It's good, I have no objections, I'm just not sure what it buys us, other than pushing a bit harder for migration. 17:35:24 * abadger1999 doesn't like the concept but is fine with the guideline being approved. 17:35:25 Do those 26 have bugs filed? 17:35:28 limburgher: i think thats all it buys us, but FESCo asked. 17:35:44 I'll vote +0 unless I'm needed for quorum. 17:35:53 Lets do a fresh vote on my proposal as worded. 17:35:57 +1 17:36:01 +1 17:36:01 +1 17:36:01 +1 17:36:02 +0 17:36:09 0 17:36:16 0 17:36:24 0 17:36:31 Okay. So it does not pass. 17:36:33 I mean, I'd be for it if I knew nobody had a good reason for shipping those files. 17:36:50 Anyone want to put forth any other proposal on this topic? 17:37:01 tibbs: Isn't that the wrong way around? 17:37:01 Or i can propose that we decline to act on this request. 17:37:09 I mean, for some reason most of our MTAs ship them (sendmail, postfix, exim). 17:37:20 tibbs: Isn't it upto them to come here and argue why we should let them do something different? 17:37:30 Erm, no, it isn't. 17:37:43 geppetto: Our default is to allow packagers to package things... 17:37:46 I mean, we're talking about just banning things that people are going. 17:38:06 Saying that they should have found out about some meeting and come to argue their case isn't exactly the right way to go about it. 17:38:07 abadger1999: But not randomly … 17:38:48 Since i'm not hearing people with alternate proposals, I propose that we respond that we have considered a ban and feel that the optional subpackage guideline that exists is sufficient. 17:38:49 if someone wanted to revive initng and start adding the initng init files, they'd be able to and if it gained enough momentum we'd approve guidelines for how the files should be installed. 17:39:03 spot: Sounds good. 17:39:12 +1 to my most recent proposal 17:39:13 abadger1999: Really … you want to ship two init systems? 17:39:14 Cron, at, sendmail, mdadm, lvm2... Those are pretty core system components all of which are shipping sysvinit files. 17:39:17 spot: +1 17:39:24 geppetto: Want is a strong word there :-) 17:39:49 geppetto: "allow" is a better statement of my feelings :-) 17:39:56 tibbs: My guess is that none of those need to do that though, and have roughly 0 users for the sub-packages. 17:40:04 +1 on optional subpackage guideline 17:40:13 We've had multiple init systems in the past. 17:40:14 I would guess that as well, but the point is that, you know, maybe we should ask. 17:40:26 Or is there some urgency here that I'm missing? 17:40:51 Not that I know of 17:41:14 No urgency that I can se. Viking_Ice brought it up in the fesco meeting and fesco passed it on to us. 17:41:21 i see +3 on the latest proposal 17:41:22 Only if systemd is planning on dropping sysv support, which, AFAIK, should be appox. never. 17:41:29 +1 17:41:32 I read: "if both sysv and systemd" are present, systemd will be used => no urgency for anything. 17:41:39 spot: +1 (i guess, that is the message we're sending by not changing things) 17:41:42 sendmail changelog says "Provided SysV initscript in sysvinit subpackage for backward compatibility". 17:42:05 hey, +5. anyone else who wants to vote on the record for this, feel free to do so now. 17:42:58 #action FPC has considered a ban and feels that the optional sysvinit subpackage guideline that exists is sufficient. (+1:5, 0:0, -1:0) 17:44:01 -1 17:44:04 Aside from bundling requests, I think thats it. 17:44:11 #topic Open Floor 17:44:27 oh wait, sorry. 252. 17:44:39 #topic Simplify github guidelines - https://fedorahosted.org/fpc/ticket/252 17:44:42 Someone had pinged me about 241 as well. 17:45:02 sochotni: could you please propose a specific change in wording for us? that makes it much simpler for us to consider and vote on 17:45:04 Oh, github actually fixed something? 17:45:21 I'm all for supporting it, whatever it is. 17:45:27 tibbs: :-) 17:45:31 * limburgher checks temp in hades 17:45:39 spot: I could whip something up, but I guess not before the meeting is over 17:45:48 sochotni: we'll tackle it first thing next week 17:46:04 sure, it's low prio but I noticed a lot of people are not aware still 17:46:32 and I thing a working Source0 URL is going to be a nice change 17:46:43 I certainly agree. 17:46:44 Very. :) 17:46:53 i think we all agree, just looking for the simple wording change. :) 17:47:14 If we get enough votes in the ticket it can go ahead before the meeting. 17:47:18 17:47:40 OK, I'll update stuff in the ticket then 17:47:49 #topic Clarification request: Acceptable use of explicit Conflicts - https://fedorahosted.org/fpc/ticket/241 17:48:32 Honestly I do not know what anaconda and fedup do here. 17:48:33 again … I'm for the idea presented in the ticket, but having some text would be nice. 17:48:35 I've read this a few times, and I'm still not sure I understand why the Conflicts is necessary. 17:48:51 Why not just make the new package f18+ only? 17:48:53 spot: Can't upgrade from F17 to F18 without it. 17:48:55 if the package is F17 only, and F18 has a package which Provides/Obsoletes it 17:49:07 why the Conflicts? 17:49:24 For the packages that exist before the obsolets … ie. F18 GA 17:49:28 * limburgher retracts my last comment 17:49:53 geppetto: not following 17:50:33 spot: There exists an N1-1 in F18 that can't be installed at the same time as their package. 17:50:37 The last paragraph seems to misunderstand what's written in the guidelines. 17:50:54 spot: They need to conflict with that. But N1-2 will come out which will also obsolete them. 17:51:29 If N1-2, why the need for a Conflict? 17:51:39 geppetto: what I don't understand is why they cannot first push an update to F18 that does the provides/obsoletes 17:51:45 spot: this. 17:52:29 spot: I assume it's just a "people try to do 'F17+updates => F18' yum upgrades ... this will tell them it's not going to work" 17:52:46 Not if they do spot's prior update. 17:52:58 geppetto: as opposed to yum telling them "these files conflict, i can't do it" now? :) 17:53:03 limburgher: That requires F17+updates => F18+updates 17:53:03 geppetto: Will that succeed if you "s/yum/fedup/"? 17:53:08 spot: yeh 17:53:26 spot: file conflicts are post download though. 17:53:57 geppetto: Why not just F17=>F18+updates? The update in F18 could handle it correctly. 17:54:11 abadger1999: Not 100% sure, but I don't think fedup requires F18 updates be available. 17:54:11 Sorry, F17* 17:54:23 I don't think this merits an explicit Conflicts, this is something where we just advise that people doing yum dist upgrades enable updates to ensure the best possible outcome. 17:54:32 * geppetto nods 17:55:08 spot: Which is something I can't imagine they wouldn't want to do anyway, if only for security fixes. 17:55:23 limburgher: I assume just that people don't always enable updates, for whatever reason … and they are just trying to make it be "the best" they can. 17:55:33 The only advantage of an explicit Conflicts is to stop the transaction before downloads start. 17:55:41 geppetto: Seems like more churn to do it that way. 17:56:10 * geppetto shrug … I assume the conflicts is pretty much free, as they haven't released the package yet. 17:56:14 And they need the downloads anyway. 17:56:23 But I'm also not bothered if we'd rather they not have conflicts. 17:57:06 There's no changed text to vote on anyway... 17:58:13 So, I propose that we advise that in this situation, we recommend that the guidance on doing yum dist upgrades be amended to recommend enabling the updates repo and that proper Provides/Obsoletes are used for the F18 package. 17:58:27 +1 17:59:29 +1 17:59:31 +1 17:59:36 https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#5._Make_sure_Fedora_is_upgraded is the closest thing to guidance we have, so if anyone wants to insert "turn on the updates repo", it would be appreciated. 17:59:49 +1 17:59:50 +1 17:59:54 +1 17:59:56 But I guess there's a question as to whether our guidelines are clear enough here. 17:59:56 +1 18:00:35 +1 18:01:01 tibbs: I'm trying to decide whether I think that, or if it's simply a difference of understanding about technical capability. 18:01:26 If someone wants to reword that section (again), please open a new ticket. :/ 18:01:42 I don't know; I understand it just fine. 18:02:01 I meant between the participants in the review. :) 18:02:40 Last paragraph of this ticket indicates they don't seem to like the "as a general rule, you must not use conflicts" bit. 18:02:50 But I don't see what's wrong with it. 18:03:11 Me neither. Conflicts are almost never the right way to solve a problem. 18:03:15 #action No Conflicts, use proper Provides/Obsoletes, and turn on updates repo when dist-upgrading (+1:8, 0:0, -1:0) 18:03:40 if someone would be so kind as to amend that Upgrading_Fedora_using_yum page, I would appreciate it 18:03:49 * spot has 2+ weeks worth of backlog work 18:04:11 #topic Open Floor 18:04:17 * kalev raises a hand. 18:04:21 I have a quick issue, regarding the the vendor tag removal from the desktop files: 18:04:24 kalev: sure. 18:04:29 "< spot> I propose that we amend the guidelines to say that for Fedora 19 and beyond, the vendor tag must not be used. If it was being used in a previous release, it may continue to be used for that previous release, but must be removed in Fedora 19. New packages must not add the vendor tag for any release." 18:04:34 Can you amend this to make it clear that the desktop file name shouldn't be changed in a stable Fedora release? 18:04:40 Right now the "it may continue to be used for that previous release" reads as if it was okay to change the desktop file name in F16-F18 18:04:45 Maybe explicitly say "Do not change the desktop file name in a stable Fedora release." or something? 18:04:48 Otherwise looks good to me. 18:05:04 kalev: sure, thats the intent of that wording, so I don't think it hurts to say that. 18:05:21 great, thanks 18:06:00 How about "Packagers are reminded that they must not change the name of the desktop file in a stable Fedora release." 18:06:15 Sure, sounds good 18:06:27 Quick vote on that addendum text? 18:06:28 +1 18:06:50 +1 18:06:58 +1 18:07:17 Not sure enough folks are still around, though. 18:07:33 +1 18:07:35 i know we lost several folks to fesco 18:08:16 +1 18:08:20 hey, +5! 18:08:33 #action addendum to vendor tag item approved (+1:5, 0:0, -1:0) 18:08:59 okay, lets go ahead and close out for this week. Thanks everyone, this was a productive meeting! :) 18:09:06 #endmeeting