16:01:11 #startmeeting Fedora Packaging Committee 16:01:11 Meeting started Wed Oct 6 16:01:11 2010 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:26 #topic Roll Call 16:01:38 Howdy. 16:02:28 * spot really needs to write a cron job to announce this meeting. :/ 16:03:03 rdieter, SmootherFrOgZ: ping? 16:03:05 * gomix_afk waves hi 16:03:16 oh, here! 16:03:45 * abadger1999 here 16:04:49 okay, by my count that is 4 16:04:55 which is not quorum 16:05:08 * spot will wait a bit longer, as racor occasionally shows up late 16:05:29 Maybe we could discuss the candidates for the open seat? 16:06:08 I've worked on https://fedoraproject.org/wiki/User:Tibbs/Text_Relocation_Guidelines a bit. 16:06:36 Needs examples, though, and I don't have any. 16:06:48 Since I don't think I've ever seen non-PIC code anywhere. 16:07:16 okay, we can discuss the candidates for the open seat 16:07:46 tibbs: i threw that URL in ticket #9 16:07:52 Oh, thanks. 16:08:12 which, if i had looked at closely enough, i would note that it was... already there. 16:08:30 Well, sort of; I renamed the existing page. 16:08:33 sorry. had my head shoved too far up chromium's "source code" for the past day and a half. 16:08:45 tibbs: aha! 16:08:48 because we decided it wasn't really about PIC. 16:09:07 But the candidates. 16:09:15 tibbs: it would be worthwhile to note that eu-textrel doesn't work on static binaries or libraries 16:09:26 Crap, I wondered about that. 16:09:38 So we're still stuck with checking logs for the PIC option. 16:09:44 at least for libraries, you do have to convert them to shared libs first 16:09:59 ld -o foo.so --whole-archive foo.a && eu-findtextrel foo.so 16:10:15 Easy enough, I guess. Better if rpmlint handled it, of course. 16:10:24 binaries we don't care. 16:10:37 I'll have to see if they're willing to accept some code. 16:10:38 ajax: a good point. 16:10:52 binaries in general or static binaries? 16:11:00 either. 16:11:18 Really? The selinux issues magically disappear for binaries? 16:11:49 What about the lack of code sharing? Maybe I just don't understand why we wouldn't care about binaries but would care about libraries. 16:12:03 (provided the libraries that were used when linking them were fine, probably yes) 16:12:06 binaries have a fixed load address, so they can be position-dependent. 16:12:24 or that. :) 16:12:24 (gross simplification) 16:12:42 I thought we randomized load addresses for binaries? 16:12:53 i did say simplification 16:13:53 Certainly someone who understands this more than I (of which there are many) could dig into that draft a bit. 16:14:54 abadger1999: out of the responses received (all four of them), there was only one candidate with universal approval. 16:15:43 I still think that it's important to have someone who actually works on the yum/rpm stack on the committee. 16:16:07 If volume and variety of packaging are the important requirements then I should probably resign. 16:16:13 tibbs: :) 16:16:37 tibbs: You make up for packages owned with packages reviewed :-) 16:17:16 Well, maybe, but I haven't done reviews in quite some time. 16:17:27 I see https://fedorahosted.org/fpc/ticket/5 (gtk-doc ownership) ticket still open, can we close that now, or is there more to do here? 16:17:30 * spot wishes he got responses from the other 4 members, but i have lots of wishes 16:18:03 I think volume and variety are only important as an indicator.... if you don't know that hte person is competent to look at guidelines from personal experience, you rely on those to judge. 16:18:08 rdieter: i think it needs to be written up. 16:18:20 oh, :( ok 16:18:23 rdieter: i'll do that today. 16:18:37 fwiw, I have no objections to any of the candidates honestly. 16:18:47 rdieter: do you have any preference? 16:19:28 someone forward me the mail again, I seem to not have it handy right now. 16:19:52 hey! its racor! 16:19:59 nevermind, found it 16:20:11 #action quorum, 20 minutes in. :) 16:20:18 yep, stuck in a traffic jam 16:20:26 racor: glad you could make it. 16:20:48 * spot is going to work backwards today, just for the fun of it 16:20:52 spot: slight preference for james, then sgallagh/mmaslano 16:21:13 #topic Add rationale for trying to eliminate Conflicts - https://fedorahosted.org/fpc/ticket/18 16:21:44 the rationale sounds fine to me 16:22:29 fine++ (better than my first idea, use Conflicts, and we will hunt you down, and inflict pain) 16:22:43 +1 16:22:49 1 16:22:51 +1 16:22:57 +1 16:23:11 This is in a separate document, so no real reason to worry about bloating the main guideline page. 16:23:19 Correct 16:23:33 tibbs: one of these days i'm going to reorg the guidelines, i swear... :/ 16:23:54 * SmootherFrOgZ is here now (sorry i'm late) 16:24:18 SmootherFrOgZ: take a look at ticket 18 (https://fedorahosted.org/fpc/ticket/18) and toss out a vote 16:24:33 ok 16:24:43 * spot waits for SmootherFrOgZ and racor to weigh in 16:25:18 +1 ... I am leary if this change is actually helpful 16:25:29 Well, people do ask about it. 16:25:56 +1 for me 16:25:58 It's probably easier to answer their questions in the document rather than having a separate FAQ section or making them ask on IRC. 16:26:05 Yeah -- it doesn't change reviewing at all -- but EPEL was recently discussing whether they should allow more conflicts than Fedora and it wasn't clear why we have the Conflict Guideline at all. 16:26:24 #agreed The draft is approved, 6 +1, no 0, no -1 16:26:48 I'm tempted to add "if you don't know what this is, don't worry about it" to the "No relocatable packages" guideline. 16:27:18 tibbs: it has been a while since i saw a relocatable package. :) 16:27:38 Someone asked me how they know if they've accidentally made their package relocatable. 16:27:59 #topic Consider expanding on Changelog Guidelines - https://fedoraproject.org/wiki/Changelogs_%28draft%29 - https://fedorahosted.org/fpc/ticket/17 16:28:11 I wish we didn't have to do this. 16:28:36 Does common sense really not win out here? 16:28:58 tibbs: apparently not. 16:29:37 guideline: use common sense. If you have to ask yourself "is this appropriate for an rpm changelog?", it probably isn't. 16:30:00 (yes, that's silly) 16:30:06 I don't disagree with the information in Kevin's first cut. 16:30:16 rdieter: unfortunately, some people seem to think that copying the changes from the source CHANGELOG is acceptable. 16:30:41 :( wrong wrong wrong 16:30:44 perhaps it makes sense to simply state what is unacceptable here? 16:31:28 I suppose that, + what generally considered good couldn't hurt 16:31:32 spot: yeah 16:31:37 * nirik was just intending to open debate. :) (was meaning to mail lists about it too to collect feedback) 16:31:49 16:32:08 Something like "Changelog entries should provide a summary of the changes done to the package between releases. They should never simply contain an entire copy of the source CHANGELOG entries." 16:32:43 * nirik wonders if there couldn't be a rpm or yumdb 'changelog' link, that points to an upstream changelog for that version if available. 16:33:06 Love to have it, but.... 16:33:19 nirik: interesting idea, i bet the rpm guys take patches. ;) 16:34:20 Just after we get a %license file attribute. 16:34:22 is anyone opposed to the simplified text i just pulled out of thin air? 16:34:25 merge those, like "Changelog entries should provide a summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They should never simply contain an entire copy of the source CHANGELOG entries." 16:34:41 rdieter: i could support that as well. 16:34:49 "The intention is to give the user a hint as to what changed in a package update without overpowering them with the nitty gritty that they might not want. Links to upstream changelogs can be entered for those who want additional information." 16:35:11 I think a lot of what I am looking for is not a hard guideline, but a 'best practices' thing... but thats outside the scope of FPC I think. 16:35:14 s/nitty gritty/technical details/ 16:35:35 adding an "intention" statement is good too, yeah 16:36:08 spot: That rewording is fine with me. 16:36:24 adding the word "brief" also would not be a mistake. 16:36:39 racor: agreed 16:36:41 ... brief summary ... yes 16:36:54 okay 16:37:00 i have updated the draft text: https://fedoraproject.org/wiki/Changelogs_%28draft%29 16:37:08 * abadger1999 really mean minutiae but hesitates to use a $10 word. 16:37:09 Can we make "brief" blink? 16:37:13 Changelog entries should provide a brief summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They must never simply contain an entire copy of the source CHANGELOG entries. 16:37:13 The intention is to give the user a hint as to what changed in a package update without overpowering them with the technical details that they might not want. Links to upstream changelogs can be entered for those who want additional information. 16:37:29 i changed "should" to "must" in the "don't be an idiot" line. 16:38:02 "intent"? 16:38:19 likie likie (though part of me would like 'overwhelming' instead of 'overpowering', but meh) 16:38:20 to make at least some of this a bit more FPC guideline-y. ;) 16:38:43 Likes both intent and overwhelming. 16:38:52 We can also remove "that they might not want" 16:38:52 okay. 16:39:04 It's redundant with the overwhelming part. 16:39:12 agreed. less is more 16:39:20 abadger1999: +1 16:39:31 Changelog entries should provide a brief summary of the changes done to the package between releases, including noting updating to a new version, adding a patch, fixing other spec sections, note bugs fixed, and CVE's if any. They must never simply contain an entire copy of the source CHANGELOG entries. 16:39:31 The intent is to give the user a hint as to what changed in a package update without overwhelming them with the technical details. Links to upstream changelogs can be entered for those who want additional information. 16:40:14 Okay, lets vote on that version. 16:40:15 +1 16:40:17 +1 16:40:23 +1 16:40:25 +1 16:40:38 +1 16:40:40 +1 16:40:56 #agreed Draft (as revised) approved. 6 +1, no 0, no -1 16:41:34 #topic Update Perl Provides/Requires Section - https://fedorahosted.org/fpc/ticket/16 16:42:19 those macros live in perl, btw. 16:42:26 and they will be present in RHEL 6. 16:42:33 spot: -devel 16:42:51 abadger1999: yeah, same difference. :) 16:42:55 hehe :-) 16:43:07 so, this is a no brainer for me 16:43:26 racor: you're a perl guru, any disagreement here? 16:44:13 spot: can you elaborate "no brainer for me" .. I am facing a language barrier 16:44:15 Do we want to put %{?perl_default_filter} in the perl page or the filtering page? 16:44:25 abadger1999: Probably both. 16:44:25 racor: a "no brainer" is an obviously correct item 16:44:41 k 16:44:42 racor: in that, i do not need to think very hard to understand/agree with it 16:44:51 spot: So you're in favor of enforcing these macros? 16:45:02 I'm still remembering weird issues preventing this from being used in arch-specific packages. 16:45:15 racor: yes, in that they are a better mechanism than the multitude of half-thought out ways used before. 16:45:57 I for one never liked them 16:46:26 tibbs: Yeah -- I did a bit of research on what we discussed before. Our conclusion was it works unless there's libraries in the library search path or compiled programs. 16:46:42 well, we could drop the admon which says that the old ways are deprecated. 16:47:00 I'm having trouble seeing how the old hacks are better than this. 16:47:04 without the admon, it just documents the macros as the recommended mechanism of filtering 16:47:10 In any subpackage. 16:47:31 (since turning off the internal dep generator is for the whole srpm, not per subpackage) 16:47:33 and doesn't actually prevent the old manual filtering mechanisms 16:47:41 my #1 issue with them is them lacking documentation and enforcing them/converting existing filters causing bugs 16:48:24 https://fedoraproject.org/wiki/Perl_default_filter does exist 16:48:33 We do have this currently in the Guidelines: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Summary 16:48:52 We don't generally require that existing packages switch over wholesale to some new scheme. 16:48:52 The three MUST items at the top say: 16:49:02 MUST filter the provides/requires of junk 16:49:07 MUST use this system 16:49:19 abadger1999: a good point. 16:49:30 We just haven't been enforcing it. 16:49:54 so, i do think we should encorporate the Perl_default_filter info in that change 16:51:49 Okay, after the Section Location of macro invocation 16:52:13 I'd put: Simplified macros for common cases 16:52:24 ==== Perl ==== 16:52:53 abadger1999: this is on Packaging:AutoProvidesAndRequiresFiltering, right? 16:52:53 Use %{?perl_default_filter} 16:52:58 spot: Correct. 16:53:01 * spot nods 16:53:04 thats clean. 16:53:34 spot: I think I'd keep the changes to the perl page as in the ticket -- Point to Packaging:AutoProvidesAndRequiresFiltering for the details. 16:53:47 abadger1999: i'm okay with that. 16:54:37 okay, so lets vote on the draft + the addition of the perl common macros to the Packaging:AutoProvidesAndRequiresFiltering page. 16:54:50 (common macro, to be precise) 16:56:15 well, okay, i'll start. ;) +1 16:56:24 +1 16:56:24 +1 16:56:32 URL to what we are voting on? 16:56:56 https://fedorahosted.org/fpc/ticket/16 + addition of https://fedoraproject.org/wiki/Perl_default_filter content to Packaging:AutoProvidesAndRequiresFiltering 16:57:49 +1 16:57:53 +1 16:58:04 abadger1999? 16:58:14 +1 16:58:38 sorry was working on what the updated page would look like. 16:58:39 #agreed Draft + addition of perl common macro to Packaging:AutoProvidesAndRequiresFiltering is approved, 6 +1, no 0, no -1 16:59:37 abadger1999: did you happen to have a chance to work on the new java guidelines (ticket #13)? 16:59:46 last time we met, you tabled it for next meeting 17:00:10 spot: I reread it with the changes that were made since the meeting and I have no objections now. 17:00:30 we're at the hour mark 17:00:32 Willing to +1 17:00:41 i'd like to try to knock this last one out, so... 17:00:51 #topic New Java Guidelines - https://fedorahosted.org/fpc/ticket/13 17:00:55 http://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate 17:01:07 that contains the revisions from the last meeting's discussions 17:02:03 He really won't give us an overview of the changes? 17:02:47 tibbs: the changes are mostly a rewording of how the filenames need to be handles, as well as some changes to clarify javadoc handling 17:02:51 I recall there being a couple of threads on -java list, but that's it I think 17:03:17 we also cleaned up the maven template a bit to comply with the guidelines 17:03:57 I've no objection with that update draft 17:04:35 okay, then, lets vote on this 17:04:48 +1 17:05:00 +1 17:05:12 +1 17:05:50 +1 17:05:58 +1 17:05:59 tibbs: http://toshio.fedorapeople.org/java.new 17:06:02 tibbs: http://toshio.fedorapeople.org/java.old 17:06:11 You can diff those to see the changes. 17:06:30 * spot will wait for tibbs to vote on the record 17:07:01 I regret, I have to quit now, bye. 17:07:06 racor: thanks! 17:09:15 * spot assumes tibbs is looking over the diff 17:09:36 Yes. 17:09:51 Both templates have added an unversioned symlink for the .jar file. 17:10:43 tibbs: sure, this is expected behavior when the default name is versioned. 17:10:51 and that is the norm in the java space. 17:11:05 Yes, it just wasn't previously mentioned. 17:11:17 "If the package provides a single JAR and the filename provided by the build is %{name}-%{version}.jar then this name MUST be used and a symbolic link %{name}.jar pointing to this file MUST be installed. " 17:11:45 OK, done. 17:12:18 * spot is on the edge of his seat 17:12:35 Under Packaging JAR files that use JNI: 17:12:49 "or a GCJ .so file (see below). " 17:12:52 +1 (sorry, distracted) 17:12:56 What below text is that referring to? 17:13:04 (distracted so much, that I forgot I alrady voted, doh) 17:13:25 I think it's referring to a previous section. 17:13:40 This text is new, so... 17:14:03 yeah, i think "see below" should just be change to a link to the GCJ section above 17:14:24 Yes, I think so. Just making sure I didn't miss anything. 17:14:26 WIth that, +1. 17:14:47 #agreed Draft (with very minor cleanup) is approved 6 +1, no 0, no -1 17:15:04 and with that, I'd like to close out the meeting. 17:15:10 I was thinking the java folks wanted to dispense with gcj altogether, but I guess that's still not in the cards. 17:15:14 any urgent business that can't wait a week? 17:15:19 Not from me. 17:15:23 * spot will wait a minute and close it out. 17:16:19 Thanks everyone. 17:16:23 #endmeeting