16:06:01 <abadger1999> #startmeeting fpc
16:06:01 <zodbot> Meeting started Thu Jun 13 16:06:01 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:14 <abadger1999> #meetingname fpc
16:06:14 <zodbot> The meeting name has been set to 'fpc'
16:06:37 <abadger1999> #chair tibbs|w RemiFedora limburgher racor geppetto spot Smoother1rOgZ
16:06:37 <zodbot> Current chairs: RemiFedora Smoother1rOgZ abadger1999 geppetto limburgher racor spot tibbs|w
16:06:57 <abadger1999> #topic Rollcall
16:07:15 * limburgher here
16:07:24 * RemiFedora here
16:08:18 * racor is here for the moment, but may have to quit early
16:11:35 <abadger1999> Apologies.
16:11:36 <tibbs|w> And there's the first emergency.  Back in a few.
16:11:47 * geppetto is here
16:12:52 <abadger1999> #topic Guideline for patches on Source?: https://fedorahosted.org/fpc/ticket/300
16:13:25 <abadger1999> Do we want to add a packaging guideline for this?
16:13:49 * Smoother1rOgZ here
16:13:50 <abadger1999> I vaguely recalled something along these lines from several years ago but searching the guidelines, I didn't find anything written in them.
16:14:02 <tibbs|w> Back.
16:14:08 <abadger1999> so it must not have made it to the guidelines proper.
16:14:16 <limburgher> I don't really see a proposed change, and I think it's more critical that we patch, include the patches, and that they're repeatably applied, than that we define precisely HOW.
16:14:34 <tibbs|w> I'm not seeing why there's any conflict here.
16:15:28 <abadger1999> I think there's two things happening:
16:15:36 <abadger1999> instead of storing individual patches in git,
16:15:51 <racor> limburgher: I think, the actual question here is whether the package submitter is allowed to use debian tarballs instead of upstream tarballs. AFAIU, the packager is trying to avoid explicitly inheriting patches from Debian by reusing their tarball.
16:15:51 <abadger1999> there's one large tarball of patches (and other, debian information) in the lookaside cache.
16:16:17 <Smoother1rOgZ> abadger1999: indeed, I also recall having written a patch_best_practive long time ago about it.
16:16:26 <tibbs|w> They're not using debian for the source.
16:16:30 <limburgher> racor:  Oh, I took it to mean they were using tar'd debian patches.
16:16:44 <abadger1999> then, when the patches are applied, the spec file is doing: untar the tarball of patches.   loop through a subdirectory and run patch on eachfile.
16:16:47 <Smoother1rOgZ> practice*
16:16:49 <limburgher> WHich is a pain, but not too bad.
16:17:09 <abadger1999> they do seem to originate from debian.
16:17:19 <limburgher> abadger1999:  I mean, it's sort of icky*  but I don't see a major issue with it.  *technical term
16:17:27 <geppetto> Yeh … basically the question is two parts: 1) Is it "fine" to have giant patches, which might well be 666 patches combined. 2) Is it fine to distribute those patches as a tarball
16:17:40 <tibbs|w> I mean, this is no worse than what the kernel does.
16:17:41 <limburgher> What's the alternative, make people break out the tarball into text patches?
16:17:50 <abadger1999> I'd be -1 to distributing as a tarball.
16:18:03 <tibbs|w> What would anyone gain from making all of those patches get checked in separately?
16:18:21 <tibbs|w> Force more overhead on the maintainer for no gain?
16:18:21 <limburgher> We used to with cernlib, some were tar'd as I recall.
16:18:31 <abadger1999> since the patches were originally broken out separately it seems silly to combine them into one huge patch but... that seems like one step in the right direction.
16:18:41 <geppetto> I think we pretty much have to say #1 is fine … and while the tarball isn't great it might have some advantages. I'm not going to argue too strongly for it though.
16:18:43 <limburgher> tibbs|w not NO gain exactly, easier to visualize changes with git tools.
16:18:44 <racor> limburgher: The alternative is to let Fedora maintainers maintain their patches themselves.
16:18:56 <geppetto> The usual way I do #2 is to cat them all into a giant patch file.
16:19:02 <abadger1999> tarball vs git is what^W yeah, what limburgher said.
16:19:05 <limburgher> racor:  A superset of what I said, yes. :)
16:19:22 <geppetto> Recent rpm also has some support for having 666 patches files named foo-1.patch to foo-666.patch.
16:20:21 <geppetto> The support being in that the .spec file only needs 2 files instead of 666 x2.
16:20:28 <geppetto> s/2 files/2 lines/
16:20:43 <racor> limburgher: Provided Debian has this package's patches in git, it should not be a mayor effort for the Fedora maintainer to fork his own clone (w/o Debian-specific clutter, but w/ Fedora specific stuff added).
16:21:13 <limburgher> racor:  Or, frankly, wget the tarball, unpack, cp, etc.
16:21:45 <limburgher> Probably wise anyway, I imagine many don't cleanly work out of the box on Fedora anyway.
16:22:10 <racor> liburgher: No, ...  this would be grossly negligent. I am expecting Fedora packagers to review Debian patches and to be selective.
16:22:35 <limburgher> racor:  My preference as well.
16:22:56 <limburgher> So I think we're all converging on one decision from different directions.
16:22:57 <RemiFedora> I really  prefer patch in git to follow changes in git history. And I can't understand how to apply debian patch in fedora without any check.
16:23:45 <limburgher> RemiFedora: Right, you often have to unpack anyway.  And to racor's point, you should.  Otherwise you might end up patching in mp3 support or something. :)
16:24:01 <racor> racor: BTW, this package's submitter also pronounced to be submitting this package for EPEL6 only  and not to submit it for Fedora - Is this case allowed? I thought not.
16:24:18 <tibbs|w> Honestly I don't see the problem here.  You're dealing with some hilariously ancient codebase, which debian has essentially forked; they are being treated as upstream.  Nothing they're doing appears to be wrong to me.
16:24:25 <limburgher> racor: Yes. See trac10.
16:24:41 <limburgher> racor:  They just immediately retire the devel branch.
16:26:25 <abadger1999> racor: I think in the dim recesses of the past the fedora project wished that everything packaged for epel would also be in fedora but over time that's been discarded -- the most notable reason is for forwards compat packages.
16:27:15 <limburgher> abadger1999:  Add to that the need for stable older versions installable alongside newer versions of the same thing.
16:28:06 <abadger1999> I'm willing to write a draft for this.... it still seems like we're a little bit split here but it also sounds like we could agree to something along the lines of patches need to be checked into git, not in lookaside.
16:28:37 <abadger1999> maybe with an additional should of packagers should be reviewing the patches they apply.
16:28:38 <RemiFedora> "patches need to be checked into git, not in lookaside"  => +1
16:28:49 <tibbs|w> -1 to that.  I don't see the point.
16:29:10 <abadger1999> k
16:29:45 <tibbs|w> And honestly the kernel's mega-patch belongs in lookaside, not in git.
16:29:53 <geppetto> I would be +1 on wording to the affect of "You should think multiple times before you just checkin a giant tarball of patches."
16:30:28 <RemiFedora> perhaps not something mandatory but encouraged
16:30:29 <geppetto> But I can see that it'd be useful in some cases (where the tarball of patches is really the new upstream tarball of code).
16:30:33 <tibbs|w> In this case the giant tarball of patches is the upstream source distribution method.  I see no reason why the packager shouldn't follow upstream here.
16:30:36 <geppetto> RemiFedora: yeh
16:30:37 <limburgher> geppetto:  Should be common sense, but. . .you know. . .
16:30:43 <geppetto> limburgher: yeh that too
16:31:03 <geppetto> limburgher: Kind of feels like "think about it and do the right thing, and stop bothering us"
16:31:03 <limburgher> tibbs|w: A valid argument.
16:31:18 <tibbs|w> No question that debian kind of sucks as an upstream here, and they should really just fork the code properly.
16:31:19 * RemiFedora thinks debian should do a real fork, with a new project source repo, history, tarball, bug tracking, ...
16:31:34 <limburgher> I'd also love a unicorn.
16:31:49 <tibbs|w> Of course, I'm sure you can point to some cases where Fedora is doing the same kind of thing.
16:31:56 <tibbs|w> But that's a separate argument.
16:31:59 <abadger1999> tibbs|w: There is a precedent for patches=git -- when people take a release and apply a series of commits to pull that forward to a new upstream snapshot... if that's done as a patch we do it via git rather than lookaside.
16:32:05 <limburgher> <cough>agg<cough>
16:32:29 <racor> tibbs|w: The "hilarious old code" claim is not true. Debian has forked yes, but the Debian code is not newer than the OpenBSD code base. Both are similarly "outdated".
16:32:59 <tibbs|w> But openbsd code is rarely portable.
16:33:08 <tibbs|w> So not useful to Linux as a whole in any case.
16:34:00 <tibbs|w> And, yeah, this code is pretty ancient, crufty, randomly forked by everyone who incorporated it, etc.
16:34:57 <limburgher> I thought SCO was alleging that kernel code was stolen, not userspace app code. <rimshot>
16:37:48 <geppetto> anyway … do we want to vote on any of this?
16:38:09 <tibbs|w> Would probably have to see a draft first.
16:38:20 <abadger1999> <nod>
16:38:29 <limburgher> tibbs|w: nod
16:38:52 <abadger1999> Okay, I think we've got all the variables talked about.  I don't think I'll be able to draft something that satisfies everyone but I'll do my best for next week.
16:39:05 <abadger1999> and then we'll see if passes or fails :-)
16:39:07 <limburgher> Thanks!
16:39:58 <abadger1999> #topic Bundling exception for nodejs-expect-js https://fedorahosted.org/fpc/ticket/297
16:40:45 <tibbs|w> Looks like nodejs is going to be the source of endless fun.
16:41:12 <abadger1999> yeah.
16:41:16 <limburgher> Eh. . .so if you use modified code, doesn't that somewhat compromise the value of the test?
16:41:32 <limburgher> Unless I'm misunderstanding. . .hardly the first time. . .
16:41:36 <abadger1999> The language in the ticket seems like I'd vote for an exception but -- I'd like to see the code first.
16:41:48 <limburgher> This ^^^^^
16:42:10 <abadger1999> So.. I'm going to request a link to the code and review request.
16:42:15 <abadger1999> anything else we want to ask for?
16:42:30 <limburgher> That'll do it for me, other than why using the existing code won't work.
16:42:50 <geppetto> Be nice to confirm if this code is only ever used in %check … or if it's actually shipped to users.
16:43:15 <tibbs|w> I guess the primary issue here is that the original code isn't exported anywhere for external use, so people just lift it and then start editing.
16:43:31 <limburgher> tibbs|w:  Wheeee!  Happy Fun Time!
16:43:49 <tibbs|w> The obvious solution here seems to have eluded the nodejs community.
16:44:23 <tibbs|w> Hey, guys, if everyone keeps lifting code like that, maybe you should, you know, stick that code in a library for everyone to use?
16:44:37 <limburgher> tibbs|w:  Get.  Out.  You can do that?
16:45:49 * abadger1999 adds these questions to the ticket.
16:46:26 <abadger1999> #topic Bundling exception request for watchman (to bundle jansson) https://fedorahosted.org/fpc/ticket/298
16:48:12 <abadger1999> I haven't gotten too deep into this one yet but I'm not sure about it.  It seems like a method of compressing the data that is transmitted might be generally useful.
16:48:15 <limburgher> I think watchman's upstream's reasoning here is a bit circular.  The changes are no good to anyone but watchman now, but they might be valuable to others, who could start using them if the were included in upstream jansson
16:48:36 <tibbs|w> I agree; this seems quite generally useful.
16:48:41 <limburgher> Too bad our authority doesn't extend to upstreams. ;)
16:48:55 <abadger1999> limburgher: If only .... :-)
16:48:57 <geppetto> ha
16:49:10 <tibbs|w> More likely it's just a new thing, the API wasn't worked out with upstream or upstream just isn't interested.
16:49:10 <limburgher> Has there been discussion with the Fedora jansson maintainer about applying patches there?
16:49:53 <limburgher> tibbs|w: Sounds like a good starting point for collaboration.
16:51:14 <racor> sorry folks, I need to quit now.
16:51:18 <racor> bye
16:51:22 <limburgher> racor:  Sorry, bye!
16:52:49 <abadger1999> huh: "All integers are signed and transmitted in the host byte order of the system running the watchman daemon."  <= It may be that the changes need some cleaning up in order to be widely useful (even in watchman)...
16:54:47 <abadger1999> So...
16:55:41 <abadger1999> So I'll say from the description of changes, they don't sound highly specific to jansson.  Could we get more information/the full set of questions answered.
16:56:56 <limburgher> Hmm.
16:59:01 <abadger1999> although -- it may be that "wire compression" isn't a good description of the functionality...
17:00:41 <limburgher> I use pliers for that.
17:00:47 <geppetto> :)
17:00:55 <limburgher> Cool that they can do it in software now.
17:01:00 <abadger1999> :-)
17:02:47 <abadger1999> #topic Open floor
17:02:57 <abadger1999> Anyone have anything they want to talk about before I close the meeting?
17:03:19 <RemiFedora> again, discussion about BuildRequires and %{_isa} have raised
17:03:27 <Smoother1rOgZ> nope
17:04:12 <tibbs|w> Ah, there was one thing.
17:04:44 <tibbs|w> What's the proper policy when someone points out a bundling issue, but the maintainer doesn't want to (or doesn't know how to) deal with it?
17:05:10 <RemiFedora> asking for a co-owner ?
17:05:18 <tibbs|w> There was one recent incident where someone pointed out a bundling and the maintainer basically said that he couldn't do anything about it and closed the ticket.
17:05:41 <RemiFedora> bad...
17:05:42 <tibbs|w> Not that I could find that bug now if I tried; something related to ruby and markdown, I think.
17:05:54 <mjg59> https://bugzilla.redhat.com/show_bug.cgi?id=964940
17:06:15 <tibbs|w> Yep, that's it.
17:06:23 <Smoother1rOgZ> tibbs|w: do we, fpc, have to handle such issue?
17:06:31 <tibbs|w> Well, that's what I'm asking.
17:06:37 <tibbs|w> I mean, we don't generally do enforcement.
17:06:55 <tibbs|w> If someone wanted to open a ticket for an exception, obviously we'd look at it, but I guess anything else is up to fesco.
17:07:01 <limburgher> We could cite that incident in a FESCO ticket.
17:07:33 <Smoother1rOgZ> tibbs|w: +1
17:08:03 <Smoother1rOgZ> this is more related to packages maintenance
17:09:49 <abadger1999> tibbs|w basically correct, yes.  It should go to us to grant/deny an exception.  if the maintainer doesn't do that or refuses to follow whatever our ruling was then it would go to fesco.
17:10:45 <tibbs|w> Is that actually written down in our bundling policy?
17:10:49 <abadger1999> as for maintainers not knowing what to do.... they need to leave the bug open and ask for help.  they need to apply a patch if someone provides them with one.
17:11:01 <tibbs|w> I would hope that this kind of thing would be pretty rare.
17:11:09 <abadger1999> possibly not -- the guidelines generally don't talk about enforcement.
17:11:33 <abadger1999> maybe we want a separate "guideline" (really a policy) that lays that out?
17:11:39 <tibbs|w> Right, but the bundling policy sort of isn't a guideline.
17:11:49 <abadger1999> <nod>  yeah, I see your point.
17:12:01 <tibbs|w> The page that tells people how to submit their bundling request and such, I mean.
17:13:40 <abadger1999> here's what we have now: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#When_a_Bundled_Library_is_Discovered_Post-Review
17:14:55 <tibbs|w> Maybe just add "If there is disagreement, FESCo is the ultimate arbiter and FPC will advise" or something like that.
17:15:05 <abadger1999> tibbs|w: <nod>
17:15:24 <abadger1999> I can writeup a draft about this for next week.
17:15:32 <abadger1999> along those lines.
17:16:07 <abadger1999> RemiFedora: Do you have a linkt to the BR and %{_isa} issue?
17:16:25 <RemiFedora> last post on the devel and packaging ML
17:16:47 <RemiFedora> [Fedora-packaging] arched BuildRequires?
17:17:14 <RemiFedora> I start searching in current Guidelines but don't find anything (but probably miss it)
17:18:06 <limburgher> I didn't see it either.
17:18:55 <tibbs|w> Mainly because it's kind of common sense.
17:19:08 <tibbs|w> But, as always, common sense loses to someone who doesn't have it.
17:19:24 <geppetto> RemiFedora: https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
17:19:31 <geppetto> It's stayed in drafts forever.
17:19:44 <geppetto> But that contains all the right data.
17:19:52 <RemiFedora> yes? I found this one
17:20:05 <tibbs|w> Is that linked to an FPC ticket?
17:20:12 <RemiFedora> no
17:20:28 <geppetto> No, I just remember commenting on it before I was in FPC.
17:20:57 <tibbs|w> I only vaguely remember back that far.
17:21:14 <geppetto> I know someone brought it up again recently to the RH rpm+ team, but nothign has changed so far.
17:21:24 <geppetto> tibbs: :)
17:22:54 * RemiFedora have to go in a few minutes
17:23:19 <tibbs|w> Sounds like that draft should be pulled back from obscurity and updated.
17:23:35 <abadger1999> <nod>  Does someone want to take that on?
17:23:57 <tibbs|w> But the question of arch-specific buildrequires doesn't even seem like it requires discussion.  Given that it doesn't actually work the way people who use it think it works.
17:24:16 <abadger1999> RemiFedora: would you want to open a ticket for the draft and revise it if there's anything that needs updating?
17:24:39 <abadger1999> tibbs|w: <nod>  If we just want a ruling now about arch'd BR's... I'd vote, no arched BR's.
17:24:49 <RemiFedora> yep, I will do
17:25:04 <tibbs|w> Yeah, me as well.
17:25:40 <RemiFedora> yes, probably a single line "no arched BR" should be quite enough
17:25:57 <abadger1999> Proposal: Do not use %{_isa} with BuildRequires.  Guideline to formalize this (and good uses of %{_isa}) to come in the near future
17:26:02 <abadger1999> +1
17:26:49 * abadger1999 thinks we still have quorum
17:27:10 <tibbs|w> +1
17:27:13 <RemiFedora> +1
17:27:20 <Smoother1rOgZ> +1
17:28:35 <limburgher> +1
17:29:25 <abadger1999> #info Proposal to not use arched BuildRequires passes (+1: 5, 0:0, -1:0)
17:29:46 <abadger1999> Okay, if there's nothing else for today, I'll close the meeting in 10
17:29:56 <abadger1999> 5
17:30:09 <abadger1999> #endmeeting