15:59:43 <spot> #startmeeting Fedora Packaging Committee
15:59:43 <zodbot> Meeting started Thu Jun 20 15:59:43 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:46 <spot> #meetingname fpc
15:59:46 <zodbot> The meeting name has been set to 'fpc'
15:59:52 <spot> #topic Roll Call
16:03:36 <RemiFedora> sorry, I'm late, Hi
16:04:09 <spot> abadger1999, limburgher, SmootherFrOgZ, tibbs: ping
16:04:17 * limburgher is here
16:04:18 * abadger1999 here
16:05:30 <spot> well, this might be a short meeting.
16:05:48 <spot> which is fine by me, as it means i get to have lunch. :D
16:06:05 <abadger1999> :-)
16:06:12 <RemiFedora> fine for me too.... was a very long day...
16:06:36 <spot> so, we'll wait 4 or 5 more minutes, and then call it if we don't have quorum
16:06:43 <abadger1999> RemiFedora: Did you have a chance to work on your draft from the last meeting?
16:06:49 <RemiFedora> no
16:07:03 <RemiFedora> hmm.. about BR ?
16:07:59 <abadger1999> RemiFedora: yeah about proper use of %_isa
16:08:08 <abadger1999> I think it was %_isa and Requires...
16:08:09 <RemiFedora> I must admit I'm a bit lost with all this discussion. Panu answer isn't really clear for me.
16:08:21 * SmootherFrOgZ here
16:08:24 <abadger1999> maybe I can explain that portion.
16:08:44 <RemiFedora> Ticket 303 is reopen again
16:08:48 <abadger1999> Panu is basically saying that SRPMS are not quaranteed architecture independent.
16:08:58 <abadger1999> *guaranteed
16:09:09 <abadger1999> and then he states some of the ways in which they are not.
16:09:23 * RemiFedora have undertood that
16:10:11 <abadger1999> The ramifications for the guideline, though....
16:10:15 <abadger1999> less clear on that.
16:10:22 <abadger1999> I think it comes down to tradeoffs.
16:10:40 <spot> okay, well, it looks like we have quorum now.
16:10:44 <abadger1999> If we leve out isa, then querying of the metadata for things that we often think of is easier.
16:10:45 <RemiFedora> I still believe that we should keep the BR without %_isa, but some says, it works, we should use BR with %_isa
16:11:34 <abadger1999> if we have %_isa then rpm --rebuild on a multilib system with a lot of x86 rpms without matching x86_64 rpms is easier
16:12:13 <abadger1999> he's also saying that rpm by and large bypasses this by always using the spec file and ignoring the srpm metadata in most cases.
16:12:25 <abadger1999> we don't have that luxury for things like repoquery.
16:12:29 <spot> maybe this is a silly question, but it seems like trusting the SRPM (as opposed to the SPEC) is a bad approach.
16:12:48 <spot> Perhaps asking upstream RPM to have --rebuild regen from the spec?
16:12:48 <abadger1999> spot: yeah, I think that's what panu is saying... but....
16:13:05 <abadger1999> for things like repoquery.... we don't have that luxury.
16:13:25 <spot> repoquery against the BR of a SRPM?
16:13:26 <abadger1999> because parsing all the spec files on the querying box would be time-prohibitive.
16:13:27 <Rathann> sorry for being late, just got home
16:13:28 <geppetto> spot: FWIW I know Panu has wanted everyone to move to a model where we don't have .src.rpm files, other than a temporary thing was the package is built directly from specfiles+sources.
16:14:05 <geppetto> but that's a huge model change.
16:14:16 <abadger1999> as I think about it... I think that panu said that rpm --rebuild would use the spec.
16:14:21 * abadger1999 checks the ml archive
16:14:26 <spot> Rathann: we haven't really started yet
16:15:01 <tibbs|w> Sorry, folks; Thursday is a bit suboptimal on occasion.
16:15:11 <spot> tibbs|w: no worries.
16:15:29 * spot had to move his whole desk today, was not sure i'd make it at all
16:16:25 <spot> okay, lets go ahead
16:16:44 <spot> #topic Guideline for patches on Source - https://fedorahosted.org/fpc/ticket/300
16:16:46 <abadger1999> yeah, rpm --rebuild uses the spec file
16:17:45 <spot> I'm uncomfortable with permitting wildcard behavior for patches from the filesystem
16:17:57 <spot> for i in debian/patches/*.patch; do ...
16:18:21 <spot> That just seems like a great way to have a patch applied to a local build that isn't in the SRPM.
16:18:50 <abadger1999> note, as a mitigating factor, that filesystem directory is coming out of a tarball that's in Source1:
16:19:00 <Rathann> yes, each patch should be explicitely applied
16:19:25 <limburgher> Is it *always*?  I had to fix an RPM at $DAYJOB that would only build on one person's workstation.
16:19:55 <abadger1999> limburgher: well -- that may be what we want to figure out...
16:20:24 <abadger1999> I think that prohibiting patches that just live in the RPMSOURCE_DIR would go along with our previous guidelines.
16:20:35 <abadger1999> not sure about patches that lve inside a tarball though.
16:20:51 * spot sighs
16:20:53 <abadger1999> since the tarball is specifically stated in a Source: line
16:21:07 <limburgher> That's. . better. . .
16:21:21 <spot> i suppose I'm fine with this draft in comment 4.
16:21:35 <abadger1999> But -- like I said in the ticket -- I'm fine if the majority of people want to tighten it up further.
16:21:44 <abadger1999> b/c the present draft is kinda vague.
16:21:53 <abadger1999> I just couldn't find precedent for making it tighter than that.
16:22:09 <abadger1999> and I know tibbs had concerns about making it too tight.
16:22:31 <spot> Part of me wants to say "check the patch files into git and move on", but if it was 50 patches, I could see how that would be annoying. Especially if the patch tarball is a moving target.
16:23:01 <spot> So I'm +1 on the draft.
16:23:35 <Rathann> does the draft change the current status quo?
16:23:35 <geppetto> yeh, it seems more like Best Practice than real policy, but that's not a bad thing … +1.
16:24:16 <SmootherFrOgZ> geppetto: yep.
16:24:33 <geppetto> It says that patches "must" be checked into the revision control system … which is possibly a change.
16:25:28 <tibbs|w> Let's see how the kernel does it.
16:25:39 <spot> tibbs|w: the kernel has the patches checked into git
16:25:42 <tibbs|w> They check the patch into lookaside.
16:25:51 <tibbs|w> Well, the big patch.
16:26:02 <spot> oh, yeah, the "rc" patchset
16:26:05 <tibbs|w> sources has e282fcff76e975e121e0636018e31a56  patch-3.8.2.xz
16:26:14 <tibbs|w> For my old checkout, of course.
16:26:15 <spot> well, thats a compressed file, no real value to it in git directly.
16:26:25 <tibbs|w> But it is a patch.
16:26:27 <spot> it would fall under this exception I'd think.
16:26:31 <tibbs|w> Of course, kernel is special.
16:26:46 <spot> yes. kernel is "special", we don't really make it follow the rules.
16:26:59 <abadger1999> To make clear that this doesn't change the direct use of patches in RPM_SOURCE_DIR; I can add something like this: |Do not loop over patches in RPM_SOURCE_DIR| Applying patches directly from RPM_SOURCE_DIR (as opposed to those from a tarball) is not allowed.  Please see packaging:RPM_Source_Dir for the complete rationale
16:28:01 <spot> abadger1999: I like that
16:28:06 <RemiFedora> for kernel, iirc rc patchset are really from upstream
16:28:38 <geppetto> yeh, it's basically following the advice in this draft, except instead of a tarball it's just a compressed text file.
16:28:47 <geppetto> We could add that too, I guess.
16:29:15 <abadger1999> yeah -- I'm willing to consider the kernel patch as ocming from upstream (although maybe not the canonical example of that :-).
16:30:20 <abadger1999> how big is the kernel patch uncompressed at minimum?
16:32:17 <tibbs|w> Does the size really matter?  I mean, what if (yeah, random hypothetical, I know) vim patches were distributed as a tarball instead  of as 1189 separate patch files?  Wouldn't that actually improve the situation?
16:32:35 <spot> I don't care about the size.
16:32:42 <abadger1999> that might be the way to go.... "This exception also applies if you're taking a single patch from upstream that is truly huge (100MB+) as a patch that size isn't very readable."
16:33:21 <spot> This exception also applies if you're taking a single patch from upstream that is compressed."
16:33:28 <geppetto> spot: I think you do … if people started putting compressed 4KB patches as source … that's not good.
16:33:31 <abadger1999> tibbs|w: for that hypothetical, Ithink separate patches is a better situation.  As it allows looking at individual changes.
16:34:30 <tibbs|w> I just don't agree; at some point the packager should get to decide which method makes sense for their package, and having 2300 lines of patch definitions and applications just seems hilarious.
16:34:35 <geppetto> I think 100MB+ is a bit on the big side though, 10MB+ I'd certainly be happy with, 1MB+ probably fine too.
16:35:00 <abadger1999> <nod>  /me just threw out 100MB to have a number... 10MB+ is certainly also in the realm
16:35:11 <spot> Maybe not specify a number, just say "large"
16:35:14 <geppetto> I guess current yum has a 5.5MB uncompressed patch checked into revision control.
16:35:15 <spot> and leave it to the packager?
16:35:22 <abadger1999> 1MB+... not sure... I am talking uncompressed.
16:35:33 <geppetto> It's not really usable to look through though.
16:35:37 <abadger1999> <nod>
16:37:23 <geppetto> anyway … as for the draft … spot and I are +1, I assume abadger1999 is … so anyone else want to vote?
16:37:40 <spot> "This exception also applies if you're taking a single large pre-compressed patch from upstream."
16:37:44 <spot> ?
16:37:50 <geppetto> Sure, +1 on that too.
16:37:56 <limburgher> I can +1.
16:38:11 <abadger1999> Does that cover the kernel?
16:38:22 <abadger1999> or will someone nitpick that hte kernel patch isn't "pre-compressed"?
16:38:34 <spot> abadger1999: upstream provides the patch pre-compressed.
16:38:38 <abadger1999> cool.
16:38:54 <SmootherFrOgZ> I'm +1 on this changes
16:38:57 <spot> or at least they did the last time i built kernels by hand. :D
16:39:01 <abadger1999> I'd strike "single"
16:39:08 <spot> abadger1999: fine
16:39:09 <abadger1999> but otherwise +1
16:39:24 <spot> okay, that's +5.
16:39:37 <RemiFedora> +1
16:39:56 <spot> #action abadger1999's draft, plus additional exception wording approved (+1:6, 0:0, -1:0)
16:40:09 <abadger1999> spot: I can write the approval to the ticket
16:40:13 <spot> abadger1999: thanks.
16:40:19 <abadger1999> and note the two additions to the draft when I do.
16:41:06 <spot> #topi Policy around packagers not getting an exception for a library or refusing to comply with an unbundling ruling - https://fedorahosted.org/fpc/ticket/301
16:41:10 <spot> #topic Policy around packagers not getting an exception for a library or refusing to comply with an unbundling ruling - https://fedorahosted.org/fpc/ticket/301
16:41:31 <spot> that proposal is a no-brainer. +1
16:42:06 <limburgher> +1.
16:42:09 <SmootherFrOgZ> +1
16:42:33 <tibbs|w> +1
16:42:52 <abadger1999> +1
16:42:53 <geppetto> +1
16:43:23 <spot> okay, thats +5
16:43:46 <spot> #action policy draft approved (+1:6, 0:0, -1:0)
16:44:28 <Rathann> +1 on #300 and +1 on #301
16:44:48 <Rathann> sorry, had to take care of a small emergency
16:45:36 <spot> #topic Asking for bundling exception for the package "rubygem-rdiscount" - https://fedorahosted.org/fpc/ticket/304
16:46:20 <limburgher> I say table while waiting for answers.
16:46:26 <tibbs|w> We certainly don't have enough information to grant an exception.
16:46:27 <spot> so... the gem bundles a copy of some (all?) of libmarkdown?
16:46:45 * spot doesn't understand why it needs to do that.
16:46:47 <tibbs|w> All of it.  But the maintainer doesn't seem to understand what bundling is.
16:47:02 <limburgher> tibbs|w: Minor detail
16:47:06 <tibbs|w> Note that until recently, there wasn't a standalone libmarkdown package in Fedora.
16:47:19 <RemiFedora> sorry...
16:47:34 <spot> okay, well, i'm fine with tabling this until the maintainer comes back with answers to those questions.
16:47:48 <spot> it might be worthwhile to make it clear in the ticket that we're waiting for them to do that before proceeding.
16:48:03 * spot will do that if there are no objections
16:48:09 <geppetto> sounds good
16:48:13 <Rathann> yes
16:48:28 <SmootherFrOgZ> none
16:49:19 * spot is going to skip to 307
16:49:27 <abadger1999> wfm
16:49:29 <spot> #topic Small changes to PHP Guidelines - https://fedorahosted.org/fpc/ticket/307
16:49:43 <spot> This is an EASYFIX, i think.
16:49:54 <limburgher> Agreed.
16:50:06 <RemiFedora> so first issue (for the trivial second part) => I cannot change the current guidelines
16:50:32 <tibbs|w> And I honestly have no idea how the wiki access system even works these days.
16:50:52 <RemiFedora> (and note having this new provides in RHEL-6 is... hm... quite long)
16:51:36 <spot> i think we just need to ask ianweller to add it
16:53:12 <tibbs|w> Let me see if I can figure out how that gets done these days.
16:53:20 * nirik can likely do it.
16:54:35 <spot> RemiFedora: as soon as you have access, just make that change and close the ticket.
16:55:14 <RemiFedora> ok
16:56:04 <SmootherFrOgZ> sorry, i've to run.
16:56:15 <RemiFedora> bye SmootherFrOgZ
16:56:21 <abadger1999> bye
16:56:40 <abadger1999> does the PSR portion of the ticket need a vote?
16:56:41 <nirik> RemiFedora: should be done. try now.
16:59:52 <spot> abadger1999: i don't think so, its just a correction, but if it does, +1
17:00:39 <RemiFedora> It doesn't change the previous behavior which was 1 folder per library
17:01:09 <RemiFedora> except, it could be a 2 level dir
17:01:13 <limburgher> I'm ok with it too, +1
17:01:57 <spot> well, lets get votes then.
17:02:00 <spot> we're at +2.
17:02:17 <tibbs|w> +1
17:02:17 <abadger1999> +1
17:02:18 <geppetto> +1
17:02:19 <RemiFedora> +1 :)
17:03:03 <spot> okay.
17:03:20 <spot> #action PHP changes approved (+1:6, 0:0, -1:0)
17:04:35 <spot> do we want to go back into 306? or wait for a revised draft?
17:05:08 <abadger1999> I don't think 306 needed a revised draft?
17:05:17 <spot> okay then.
17:05:22 <abadger1999> It only deals with payload, not BuildRequires.
17:05:24 <RemiFedora> yes 306 seems ok
17:05:39 <spot> #topic Prohibit conditionalizing payload on Architecture - https://fedorahosted.org/fpc/ticket/306
17:05:43 <abadger1999> +1
17:05:48 <RemiFedora> +1
17:06:04 <spot> +1
17:06:06 <limburgher> +1
17:06:44 <geppetto> I'm +1 in general … but does the second example actually work?
17:07:03 <geppetto> The %ifarch %patch % endif … ?
17:07:08 <spot> geppetto: absolutely.
17:07:12 <RemiFedora> yes
17:07:13 <tibbs|w> Also, I am slightly confused by the first sentence.
17:07:16 <abadger1999> hmm..
17:07:37 <tibbs|w> How does conditionalizing the BuildRequires change the payload of the package?
17:07:40 <abadger1999> geppetto: I adapted it from something that panu posted but didn't test.  I can do that.
17:07:42 <geppetto> spot: Ok, so that doesn't get encoded in the .src.rpm but happens at buildtime somehow?
17:08:13 <tibbs|w> The ticket seems to be about Source: and Patch:, and I agree that those shouldn't be conditionalized, but that one sentence seems to refer to something else.
17:08:13 <abadger1999> tibbs|w: "Packages MUST NOT have SourceN or PatchN tags which are conditionalized on architecture." ?
17:08:25 <spot> geppetto: it gets encoded as a conditional to be processed, not optimized away
17:08:27 <abadger1999> oops
17:08:33 <tibbs|w> I mean, the first sentence in the description of the ticket.
17:08:42 * geppetto nods … welcome to rpmbuild, here be magic :)
17:08:42 <abadger1999> tibbs|w: I see -- in the initial description -- that's a typo/misthink on my part.
17:08:42 <spot> its a true if, not a #if (in the C equiv)
17:08:55 * geppetto nods
17:09:05 <tibbs|w> abadger1999: OK, thanks, that makes a whole lot more sense to me.
17:09:59 <abadger1999> "Panu brought up the fact that conditionalizing BuildRequires is a much bigger issue as it changes what is in the payload of the srpm "  <=  s/BuildRequires/Source: and Patch:/
17:10:21 <tibbs|w> Anyway, I was +1 in the ticket, still +1 now, but it does make much more sense that way.
17:10:46 * spot notes the proposal draft starts at "Proposal:". :)
17:11:13 <spot> #action Draft approved (+1:6, 0:0, -1:0)
17:11:43 <spot> #topic Open Floor
17:11:49 * spot is hungry. That is all.
17:12:08 * limburgher is too.
17:12:19 <RemiFedora> have a good lunch :)
17:12:25 * RemiFedora will have diner
17:12:47 <limburgher> This is why breakfast is the most perfect meal.  It works any time of day.
17:13:12 <abadger1999> We should probably discuss 302/303 (isa in BR) next week.  Too big to get into now, though.
17:13:20 <limburgher> I can make my kids pancakes for dinner and they're all "w00t!"
17:13:24 <spot> okay, i see no burning topics aside from the fun ones for next week.
17:13:29 <spot> thanks everyone. :)
17:13:31 <spot> #endmeeting