16:02:18 <spot> #startmeeting Fedora Packaging Committee
16:02:18 <zodbot> Meeting started Wed May 12 16:02:18 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:36 <spot> #topic Roll call
16:04:34 <tibbs> ...
16:05:14 <limburgher> here
16:06:58 <spot> well, that was all sorts of fun
16:07:00 <spot> my laptop just rebooted.
16:07:11 <spot> so, i missed all the roll call except for noting that tibbs and limburgher were present
16:07:46 <limburgher> You missed nothing.
16:07:48 <tibbs> That was the roll call.
16:08:31 <limburgher> What did you do, try to start a kvm guest on a TK-55?
16:08:36 <spot> i know racor isn't going to be here, but how about rdieter, hans, abadger1999, SmootherFrOgZ, Rathann?
16:08:39 <spot> ouch.
16:08:41 <spot> abadger1999, rdieter, SmootherFrOgZ: ping?
16:08:49 <spot> uh, not that i know of.
16:08:59 <spot> i think this laptop has a short in it somewhere. :P
16:09:58 <spot> well, i'll wait a few more minutes for other FPC members to show up, but we're well below quorum as is
16:10:11 <abadger1999> I'm here too.
16:10:23 <spot> aha, thats 4, so... one more
16:12:32 <tibbs> Well, crap.
16:12:42 <spot> well, i suppose we could go over the items that ralf gave +1 to
16:12:49 <spot> they have at least the possibility to pass
16:12:52 <limburgher> Sounds reasonable.
16:13:12 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions
16:13:21 <spot> i made the minor changes that ralf asked for
16:13:57 <spot> this is honestly a no-brainer for me, the stuff in the guidelines now is wrong, this draft corrects it
16:14:21 <tibbs> I agree.
16:14:39 <tibbs> The only odd thing is that we're updating the guideline to reference a Fedora version that we're about to EOL (F-11).
16:15:01 <spot> tibbs: they should be the same on F-13
16:15:02 <abadger1999> Agreement here as well -- and It looks like you got the macros that panu mentioned taking out earlier as well?
16:15:04 <limburgher> Yeah, but we haven't yet.
16:15:19 <limburgher> I like the changes, they're pretty uncontroversial.
16:16:01 <tibbs> My point is that if we say "This is the way it is on F-13" instead of "F-11" then we save the guideline being outdated in six weeks or whenever it is that F-11 goes EOL.
16:16:26 <spot> tibbs: yeah, i'll make that change when i write it up
16:16:39 * limburgher nods
16:16:46 <tibbs> Also, I wonder how useful the two links to other distro macros are.
16:17:14 <tibbs> One still talks about extras and the other starts with "This page could probably be deleted".
16:17:31 <spot> it's probably safe to drop them at this point
16:17:37 <limburgher> Agreed.
16:18:18 <spot> okay, so lets vote on the draft with f13 and dropping the old macro references at the bottom
16:18:25 <tibbs> And the optflags thing?
16:18:40 <spot> what's the optflags thing?
16:18:48 <tibbs> Under "Uncovered issues" at the top.
16:19:09 <limburgher> I thought he was just highlighting something to look at later that he knows he didn't touch.
16:19:29 <spot> I'll fix it to match what is in F-13
16:19:48 <tibbs> I don't even have a 386 machine to see what value it would have there.
16:20:04 <limburgher> I'm on 386, but F-12.
16:20:05 * spot has a VM, so i can do it trivially
16:20:20 <tibbs> But, sure, getting this page to actually reflect reality is always going to be a good thing.
16:20:40 <spot> okay, so vote on: f13 changes (including optflags) and dropped macro references
16:20:46 <limburgher> +1
16:20:51 <spot> +1
16:21:17 <tibbs> +1
16:21:22 <abadger1999> +1
16:21:56 <spot> alright, with racor's +1, this passes
16:22:20 <spot> #agreed RPMMacros update, with  f13 changes (including optflags) and dropped macro references passes
16:22:27 <skvidal> catching up on scrollback: so - b/c of a lack of members present it's impossible to ratify the %{_isa} change??
16:22:44 <spot> skvidal: that is correct.
16:22:54 <tibbs> There are not sufficient committee members here to provide sufficient votes to pass it.
16:23:08 * skvidal grumbles
16:23:12 <tibbs> And even if it were, there's no guarantee that it would pass.
16:23:18 * spot is going to talk to hans, SmootherFrOgZ, and Rathann to make sure they want to continue to participate in FPC
16:23:49 <skvidal> is rdieter around?
16:23:50 <spot> so... that was the only item racor gave a +1 on
16:24:08 <spot> skvidal: he didn't respond to roll call or pings
16:24:19 * skvidal goes to look up his office number
16:24:38 <tibbs> Ralf wasn't completely opposed to the CMPI stuff, although I won't vote for it as is anyway.
16:24:57 * spot notes for the record that racor did say he was +1 to the PIC draft, but only with the naming scheme removed
16:25:12 <spot> but given that i don't know how to make the PIC draft work without the naming scheme...
16:25:27 <limburgher> And that he's not offered an alternative. . .
16:25:54 <limburgher> I was sort of hoping to have some discussion vis-a-vis PIC, lzma and thus UPX, but it will just have to wait.
16:25:56 <tibbs> Well, if you drop the third option from the initial "must", you can get by without the naming guideline.
16:25:56 <spot> the only other way I can think of is to force them into subdirs
16:26:00 <tibbs> But I'm not sure that's useful.
16:26:31 <spot> e.g. %{_libdir}/PIC
16:26:38 <spot> but that borders on violating FHS
16:26:42 <abadger1999> limburgher: I thought lzma/UPX was a bundled library problem?
16:27:09 <limburgher> It is, which is best solved by packaging lzma static libs, if I understand correctly.
16:27:57 <limburgher> Though honestly I'm getting so frustrated with the whole thing I'm *this* close to ripping LZMA back out and calling it done.
16:28:08 * spot notes that while discouraged, packaging static libs is permitted and documented
16:28:33 <limburgher> spot: I still hate to do it.
16:28:39 <spot> limburgher: yep.
16:29:07 <tibbs> I wonder what situations would force us to ship both pic and non-pic.
16:29:08 <tibbs> I guess it's just the performance thing.
16:30:37 <spot> well, that brings us to the end of our meeting
16:30:49 * skvidal is still probing for other members
16:30:52 <tibbs> Unfortunate.
16:30:54 <skvidal> give me 5 more minutes?
16:30:59 <spot> skvidal: sure
16:31:00 <limburgher> Fine by me.
16:31:00 <tibbs> We can still talk about stuff, though.
16:31:09 <spot> tibbs: floor is open for discussion
16:31:12 <skvidal> talk about the %{_isa} rule
16:31:13 <spot> #topic Open discussion
16:31:18 <skvidal> :)
16:31:33 <abadger1999> There was also nottings request.
16:31:37 <tibbs> I managed to get some info from the Java guys, but then someone else submitted their Java guideline revision.
16:31:54 <spot> abadger1999: we can talk about it, but we need quorum to vote on it
16:31:56 <tibbs> Unfortunately that's not terribly useful because it doesn't indicate what needs to change; it's just a new page.
16:32:02 <abadger1999> <nod>
16:32:09 <limburgher> re isa, would there be a mass effort to put it into practice?
16:32:37 <spot> it would be nice if there was.
16:32:54 <tibbs> I'm concerned that isa is an attempt to fix our multilib issues from the wrong end.
16:33:14 <limburgher> tibbs: Elaborate
16:33:21 <skvidal> tibbs: what's the other end?
16:33:22 <limburgher> tibbe: bitte
16:33:52 <tibbs> Actually evaluating whether we want to keep multilib in its current form at all.
16:34:15 <spot> i think that is probably a FESCo decision
16:34:21 <skvidal> ummm - that's sort of like saying "we should treat heart disease by removing the heart"
16:34:23 <limburgher> You are, we are, we should. . .?
16:34:27 <tibbs> It just seems that the draft says "multilib as we currently have it has issues, which we can work around by messing with packages"
16:34:49 <tibbs> limburgher: Your "question" doesn't make much sense to me, sorry.
16:34:57 <skvidal> tibbs: we can help the issues by making the requirements specific
16:35:06 <skvidal> tibbs: right now the reqs are 'we need something like this'
16:35:09 <tibbs> I don't disagree with that.
16:35:24 <skvidal> and yum (and other depsolvers) provide 'something like this'
16:35:27 <skvidal> but it's not specific enough
16:35:42 <skvidal> and the pkgers are blaming the depsolver for not being specific enough
16:35:48 <skvidal> when they aren't asking a specific enough question
16:35:48 <limburgher> tibbs: Sorry, who is doing the evaluating?
16:36:15 <tibbs> Is that somehow relevant?
16:36:32 <skvidal> tibbs: think of it like this - you're asking me for a piece of paper
16:36:35 <limburgher> Possibly.  Just wasn't clear.
16:36:38 <skvidal> I hand you a white piece of paper
16:36:50 <skvidal> you respond with "No,STUPID a BROWN piece of paper"
16:36:58 <skvidal> eventhough you never said brown
16:37:17 <limburgher> Sounds like some of my $_DAYJOB users.
16:37:19 * nirik would really love a "Multilib - requirements and implementation' page. So, we could decide if we could kill it, and if not, note why not exactly, so we don't have to keep talking about killing it.
16:37:24 * rdieter reads backlog, sorry I'm late
16:37:26 * spot feels that the %{?isa} solution is a solid one for the multilib universe we have today. if that multilib universe changes, we can revisit it.
16:37:53 <tibbs> Well, to extend to absurdity, nobody ever really wants the brown paper but occasionally it gets put on top.  Why do we have the brown paper in the cabinet at all?
16:37:56 <skvidal> rdieter!
16:37:57 <limburgher> spot: As long as it doesn't take the fire out of solving the larger issues, I agree.
16:38:30 * spot encourages motivated multilib reformists to work with FESCo. :)
16:38:33 <skvidal> tibbs: b/c the set of people is huge - the set of requirements is huge - so we cannot rule it out
16:38:35 <Oxf13> there is also an elephant in the room
16:39:04 <skvidal> Oxf13: there is?
16:39:05 <limburgher> 0xf13: being?
16:39:08 <Oxf13> RHEL
16:39:17 <spot> uh, why?
16:39:20 <Oxf13> RHEL will likely continue doing multilib for a while.
16:39:20 <skvidal> that only impacts reforming multilib
16:39:26 <skvidal> that does not impact %{_isa}
16:39:31 <spot> skvidal: i agree
16:39:37 <Oxf13> and while Fedora could throw out multilib, it makes RHEL's life harder.
16:39:46 <Oxf13> which makes life harder for many of our contributors
16:39:51 <spot> i doubt Fedora will ever throw out multilib as long as we have wine.
16:39:54 <skvidal> Oxf13: right and we're saying throwing out mulitlib is not up for discussion in this meeting
16:39:57 <Oxf13> which is not to say that we shouldn't throw out multilib, it's just a data point.
16:40:04 <limburgher> I seem to recall being told not to worry too much about RHEL.  Not that I agree with that, but there yo ugo.
16:40:12 <rdieter> skvidal, spot : anything needing a vote to pass?
16:40:13 <tibbs|cell> My internet sucks right now.
16:40:15 <spot> okay, so since we do have quorum now
16:40:21 <spot> lets formally look at the isa draft
16:40:26 <Oxf13> limburgher: I worry about it, since that's where my paycheck comes from
16:40:36 <spot> #topic https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
16:40:51 * LinuxCode would be more concerned about pissing off package maintainers
16:40:56 <LinuxCode> as an outsider
16:41:04 <limburgher> 0xf13: of course.  And you should.  I do too, since we use CentOS at work.
16:41:13 <tibbs> But yes, I understand how this would conveniently solve many of the issues with multilib as we currently have them.
16:41:16 <tibbs> OK, maybe I'm back now.
16:41:40 <spot> LinuxCode: i'm not sure that this will really piss off package maintainers, especially if there is an initiative to clean up existing packages in rawhide during the F-14 cycle
16:41:46 * spot would be willing to drive that effort
16:41:47 <tibbs> Final concern from me: is there any possibility of RPM handling this instead of having to mess with thousands of packages?
16:41:50 <limburgher> How would adopting isa hurt RHEL?  Assuming multilib is kept and improved, which I think it will.
16:41:57 <LinuxCode> spot, was thinking in terms of more work
16:42:07 <LinuxCode> i.e. maintain rhel/fedora/epel stuff
16:42:11 <LinuxCode> but Im an outsider
16:42:16 <LinuxCode> so ignore me
16:42:18 <LinuxCode> ;-}
16:42:19 <spot> LinuxCode: yeah, its more work, but it will likely only impact a small set of packages.
16:42:24 <LinuxCode> kk
16:42:26 <LinuxCode> ;-D
16:42:33 <spot> autodetected requires already do the right thing (mostly)
16:42:40 <Oxf13> while I'm not in FPC, my immediate reaction is this.
16:43:09 <Oxf13> If the most common thing is to require the specific isa arch, why can't that be the implicit with Requires: and we'd have to add something explicit to get a non-arch match?
16:43:22 <Oxf13> eg, why should the common case wind up having to edit nearly every spec
16:43:23 <spot> tibbs: it might be possible, but given that there are clear situations where it is not wanted
16:43:41 <skvidal> Oxf13: implicit breaks backward compat of pkgs, badly
16:44:00 <Oxf13> skvidal: we're already in that state though
16:44:04 <skvidal> Oxf13:making new implicit assumptions means we have to know the 'era' of a pkg to know what the hell it means
16:44:14 <Oxf13> because we woudln't be editing our packages for the common case
16:44:50 <Oxf13> so they'd continue "working" just as well as they have in the past when you run them on older rpm
16:44:51 <tibbs> Are there any data on the quantity of packages which would actually need fixing?
16:45:20 <Oxf13> tibbs: it would appear that nearly every archful package with a -devel requires would get touched
16:45:28 <skvidal> Oxf13: to me it feels like a emit/accept issue
16:45:38 <skvidal> be strict in what you emit
16:45:42 <skvidal> liberal in what you accept
16:45:54 <skvidal> the package requirements are not being strict in what they accept
16:45:55 <Oxf13> skvidal: what happens when an older rpm encounters the isa junk?
16:45:57 <skvidal> s/accept/emit/
16:46:02 <skvidal> what isa junk?
16:46:08 <skvidal> it's a requirement string
16:46:09 <geppetto> Oxf13: It works at rpmbuild time
16:46:14 <Oxf13> Requires: foo%{?_isa}
16:46:15 <skvidal> if the requirement isn't there it can't be matched
16:46:21 <skvidal> yes
16:46:38 <Oxf13> if you're worried about backwards compatibility...
16:46:43 <skvidal> Oxf13: it's like %{?dist}
16:46:50 <skvidal> if it is not defined it's not included
16:47:08 <Oxf13> so you just get unexpected behavior
16:47:21 <rdieter> the old behavior
16:47:27 <skvidal> unexpected?
16:47:45 <Oxf13> ... which is the the same thing you'd get if you made newer rpm assume that foo really means foo.arch
16:48:04 <abadger1999> And if I read everything correctly, that means RHEL5 and less for us.
16:48:04 <limburgher> I could be wrong but it sounds like in the unlikely event that occurs, it would just fail to the current state.
16:48:07 <geppetto> Oxf13: You mean newer rpmbuild? ... or newer yum?
16:48:07 <skvidal> so you want to change rpm
16:48:10 <spot> i think that is not a simple thing to have rpm assume a Requires is a package.
16:48:13 <skvidal> and, ultimately yum
16:48:25 <skvidal> rather than modify spec files
16:48:27 <spot> as opposed to a virtualprovide
16:48:37 <limburgher> or a file require.
16:48:40 <Oxf13> *shrug* it just seems strange that the most common case would cause us to go and hand edit thousands of spec files
16:48:42 <spot> yep.
16:48:49 <Oxf13> while the uncommon case would require ... not editing the spec file.
16:48:50 <tibbs> I wonder how rpm would know how to auto-add arch without knowing whether or not the package you're Require:ing is noarch.
16:48:59 <skvidal> Oxf13: the most common case has been assuming forever that anything providing 'foo' is good enough
16:49:06 <skvidal> it is only in the multilib world that this IS NOT the case
16:49:12 <spot> tibbs: it wouldn't. i don't think this can be sanely automated.
16:49:19 <Oxf13> right, multilib sucks, news at 11
16:49:25 <geppetto> Oxf13: The problem is that there isn't a better way ... assuming things in the yum depsolver will fail, badly
16:49:29 <Oxf13> anyway, I'll go back in my hole and wait for the flag day.
16:49:32 <tibbs> Yeah, thinking about it more, I can't see how you can get around modifying packages.
16:49:51 <spot> tibbs: which is why i'm willing to organize a cleanup initiative during F-14
16:50:27 <abadger1999> I'd like the wording to be better, but I agree to the concept.
16:50:30 <limburgher> spot: what else would you have people touch?
16:50:56 <spot> limburgher: what do you mean?
16:51:37 <limburgher> spot: for the cleanup effort.  What other things do you envision having people fix in their(or others') packages?
16:51:41 <tibbs> Is there any possibility for just doing this for problem or critpath packages or where the maintainer wants it?
16:51:58 <limburgher> tibbs: and new packages?
16:52:09 <spot> limburgher: well, i was thinking only about %{?_isa}
16:52:12 <limburgher> tibbs: i.e. add it to the review guidelines
16:52:18 <spot> tibbs: we can certainly start there
16:53:10 <spot> abadger1999: if you would prefer to rewrite the draft, we can revisit it in two weeks
16:53:12 <tibbs> Because, yes, we know we have a problem but honestly it isn't seen all that often.  Or maybe I'm just not seeing it.
16:53:15 <limburgher> spot: you weren't thinking of a general "bring things up to guidelines" effort, a sort of "rpmlint -i <everything?"?
16:53:32 <abadger1999> spot: Trying to rewrite now depending on how long discussion goes for.
16:53:32 <spot> limburgher: eh, no. that would be a much more ... massive undertaking.
16:53:51 <tibbs> Well, that would sure be nice.  But don't forget that our last effort to "bring things up to guidelines" resulted in how many merge reviews still being open.
16:54:04 <limburgher> spot:  Gotcha.  I'm not necessarily advocating that until the Merge Reviews are done (heh), just taking your temperature.
16:54:16 <limburgher> tibbs: jinx.
16:55:08 <limburgher> on that note, an effort to have RH package owners check to see if they have an open merge review they're not CCd on would go a long way.
16:55:13 <spot> okay, well, lets give abadger1999 some time to reword the %{?_isa} draft.
16:55:20 <limburgher> oh, and then actually looking at them. :)
16:55:28 <limburgher> spot: agreed.
16:55:32 <abadger1999> Sounds good.
16:55:47 <spot> #topic https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
16:55:52 <abadger1999> Everyone here likes the concept, though -- so as long as I keep the same spirit I'm not messing with anything controversial?
16:56:02 <tibbs> Well, ralf doesn't like it.
16:56:04 <spot> abadger1999: if you happen to finish it during the meeting, just speak up and we'll look at it for a vote.
16:56:24 <tibbs> But it's hard to tell if he just doesn't understand the reasons for the proposal.
16:56:25 <skvidal> tibbs: umm...
16:56:51 * spot gave up trying to figure out racor's motivations long ago. :)
16:56:57 <limburgher> spot: <sigh>
16:57:01 <tibbs> skvidal: Ralf provided commentary on the mailing list since he could not be here today.
16:57:07 <skvidal> tibbs: yah, I know
16:57:16 <spot> okay, lets talk about the VCS item
16:57:29 <tibbs> I... can't get behind the VCS thing.
16:58:13 <abadger1999> .me agrees with tibbs
16:58:24 <tibbs> It's one thing to say that you've written some tool and if you'd like to use its functionality, then drop a comment in your spec.
16:58:25 * spot asked walters to drop by
16:58:32 <walters> howdy
16:58:40 <tibbs> We don't have guidelines restricting what comments you can add to your spec, after all.
16:59:08 <limburgher> It's a Nice to Have, but many projects don't use public VCS, and I'm not clear on the problem it solves.
16:59:19 <walters> limburgher: we want to strongly encourage projects to do so
16:59:29 <walters> for reasons that i hopefully don't have to enumerate
16:59:51 <spot> a few points: its not clear as to whether this VCS comment is supposed to be mandatory or not
17:00:06 <limburgher> walters: Of course.  But how does this do that?
17:00:15 <walters> i don't think it's feasible to make it mandatory at this point
17:00:24 <limburgher> walters: When does upstream even care about our spec files?
17:00:49 <tibbs> I can't figure out what would actually use this even if our specs had it.
17:00:56 <spot> walters: so, then this draft is just to standardize the syntax for the optional VCS comment?
17:01:08 <walters> limburgher: So, this is merely a first step in what I see as several things Fedora could be doing.  For example, for GNOME Shell, I'm autobuilding upstream version control, and I want to be able to give immediate feedback to upstream if a commit makes our packaging fail
17:01:26 <walters> spot: yeah (though I'd really like to get the upstream RPM patch applied too)
17:01:55 <limburgher> walters: So you're not building from a tarball?  How are you doing this, checkout out a specified tag or somesuch?
17:02:03 <walters> limburgher: tag or arbitrary commit, yes
17:02:12 <rdieter> shrug, if you want to add vcs metadata to .specs in standard way, I'm ok with that.
17:03:00 <abadger1999> If the patch was accepted upstream then we'd have to reedit the spec files to move from comment to patch.
17:03:09 <skvidal> walters: check it out when the srpm is constructed, right?
17:03:20 <limburgher> walter: Pretty much negates the md5sum check.  Do you tar the checkout or checkout live during the build?
17:03:23 <skvidal> walters: you still have the sources inside the srpm, correct?
17:03:30 <walters> skvidal: we generate a tarball from the vcs
17:03:30 <tibbs> live checkout during build is complete fail.
17:03:41 <Oxf13> limburgher: in a proper vcs like git, the checkout is a checksum itself
17:03:42 <abadger1999> I'd rather see this in a tips and tricks section than in the Guidelines.
17:03:44 <tibbs> There's no expectation that the builder will have network access.
17:03:44 <skvidal> walters: right - okay - so the srpm is still a discrete form of the original sources
17:03:46 <Oxf13> limburgher: an immutable checksum.
17:03:52 <walters> skvidal: but the exact semantics of how fedpkg-vcs works currently is fairly independent of having the data in the .spec file
17:03:55 <limburgher> tibbs:  Amen.  I might as well throw out my laptop otherwise. . .
17:03:59 <skvidal> tibbs: right - that's why I checked on the srpm having a copy of the metadata
17:04:01 <abadger1999> (if its just documenting a good format to use to reference upstrem urls)
17:04:03 <walters> (patches to fedpkg-vcs happily accepted)
17:04:15 <skvidal> s/metadata/source/
17:04:40 <tibbs> Bottom line for me is that I don't see the point of making this a guideline at this point.
17:04:41 <limburgher> 0xf13: true, but much of the world is still on cvs, svn, etc.  I thouroughly grok, use and love git.
17:05:02 <walters> tibbs: because it will enable us to e.g. do automatic correspondence checking between tarballs and upstream VCS
17:05:23 <tibbs> No, it won't.  The tools will.
17:05:30 <walters> well, yes
17:05:39 <walters> but if we don't have the information the tools can't work
17:05:53 <tibbs> But this is optional anyway, so I still fail to see the point.
17:05:57 <limburgher> walters: only for those packages with pubic VCS of a type we support.
17:06:12 <limburgher> walters: That's online at the time we check. . .
17:06:17 <tibbs> Develop the tools, get people to use them.
17:06:28 <walters> i ****did**** develop the tool
17:06:31 <tibbs> We don't have any guidelines restricting what comments you can add to your spec.
17:06:51 <tibbs> I've never seen the tool.  Does the guideline even mention it?
17:07:01 <walters> it's more "a" tool
17:07:02 <walters> one sec
17:07:35 <walters> argh, where is the fedorahosted gitweb again?
17:07:49 <tibbs> I mean, I still think it's pointless to have a guidline to document the input that some non-mandatory tool will take.
17:08:02 <skvidal> http://git.fedorahosted.org/git/
17:08:12 <tibbs> The use of this tool seems to be completely orthogonal to the whole guideline process.
17:08:23 <walters> tibbs: http://git.fedorahosted.org/git/?p=fedora-packager.git;a=tree;h=refs/heads/fedpkg-vcs;hb=fedpkg-vcs
17:08:28 <walters> tibbs: that's the branch of fedora-packager with fedpkg-vcs
17:08:30 <tibbs> Surely we don't intend to force maintainers to use it even if it does exist.
17:08:40 <walters> no
17:09:01 <limburgher> reinforcing tibbs's point.
17:09:06 <tibbs> So, again, I fail to see the point of involving the guideline process for this.  I'd think you'd want to avoid it, honestly.
17:09:19 <walters> i'm just trying to make some tasks like "apply commit 0xcafebabe from upstream git" possible in a standard awy
17:09:54 <spot> walters: doesn't ajax already do this in his xorg packages without this?
17:10:11 <walters> well...how the xorg package works is sort of a different thing
17:10:20 <Oxf13> in the future, I'd really like us to have metadata in rpms about their upstream source control repos
17:10:20 <walters> that's more towards 0xf13's dist-git proposal
17:10:31 <Oxf13> it would make things like patch management easier and more useful in dist-git
17:10:46 <walters> which the relationship of the #VCS key to is pretty much complimentary
17:10:59 * spot is inclined to wait and see what upstream RPM does here and revisit this depending on their outcome.
17:11:15 <spot> while noting that comments are not restricted in any way
17:11:37 <walters> dgilmore: if that's the conclusion, would you be ok with merging the fedpkg-vcs branch?
17:11:57 <walters> i don't care if it's marked as "experimental" or whatever
17:12:08 <walters> i just want other people to be able to use and improve my tools without being blocked for an arbitrary amount of time
17:12:18 <spot> wait, what does that merge mean?
17:12:26 <walters> there's a huge barrier between "yum install fedora-packager" and "git clone fedora-packager..."
17:12:28 <limburgher> git merge the two branches?
17:12:48 <walters> spot: that a new executable fedpkg-vcs would appear in the fedora-packager tarball
17:13:26 <spot> walters: i'm somewhat uncomfortable with us having a tool that relies on undocumented comments.
17:13:32 <walters> but...
17:13:33 <spot> i realize that is a bit of a catch22
17:13:38 <walters> the entire point of this discussion is to document it
17:14:01 <spot> ideally, rpm would support this as a proper tag
17:14:11 <walters> yes, that patch exists
17:14:22 <dgilmore> walters: id like to do some testing on it first  but sure
17:14:24 <spot> and we would document in the guidelines how to properly use that tag
17:14:27 <rdieter> sorry, but I can't stay.  consider me +1 for arch-specific draft at least (I'll vote onlist later if it's needed on anything else)
17:14:32 <walters> dgilmore: awesome, thanks
17:15:10 <spot> i suspect i share the same concern as linus, where i don't want fedora packagers to have to depend on git to build srpms.
17:15:27 <spot> (linus feels that git should not be a requirement to build the kernel, for reference)
17:15:28 <walters> uh, this proposal is nothing of the sort
17:15:46 <abadger1999> walters: I'd get the comment format onto this page: https://fedoraproject.org/wiki/Packaging_tricks
17:15:50 <spot> walters: would there ever be packages with VCS and without Source0?
17:16:23 <walters> spot: that change could be made at a later time, and I think it probably makes sense to do so, but I don't want to conflate the distant future with a simple standardization of a comment string
17:17:17 <spot> walters: see, i don't necessarily agree with that road.
17:17:26 <spot> and since i see that this leads us there, i am hesitant.
17:17:42 <limburgher> walters: then i must not understand your huge barrier comment.
17:18:32 <limburgher> spot:  agreed.  In that future, if the internet goes away, we can't build rpms.
17:18:39 <walters> wrong
17:18:43 <walters> we can mirror upstream version control
17:18:44 <limburgher> why?
17:18:57 <walters> in fact, doing so would be a lot more efficient than mirroring tarballs
17:18:59 <limburgher> But that's not what you're proposing.  And would take boku disk.
17:19:01 <Oxf13> honestly there are many projects going this way
17:19:06 <walters> but anyways
17:19:10 <Oxf13> I've ran into a number of projects that no longer make tarballs for release
17:19:13 <walters> it's really not the subject at hand
17:19:15 <Oxf13> they just tag a git commit and move on
17:19:20 <limburgher> me too, but that's not the point.
17:19:22 <walters> there are many, many things we can do with this information
17:19:28 <Oxf13> so we're going to have to face this situation sooner or later.
17:19:46 <limburgher> Fedora should be able to hang onto software if upstream goes away.
17:19:49 <Oxf13> the usefulness of this data for dist-git alone should be reason enough to consider letting it in
17:19:55 <abadger1999> Oxf13: It's not actually new.
17:19:58 <Oxf13> limburgher: that's what local mirrors are for.
17:20:03 <tibbs> "consider letting it in"?
17:20:04 <Oxf13> abadger1999: correct it's not new, it's just growing.
17:20:14 <tibbs> It's just a comment; nothing restricts it now.
17:20:22 <abadger1999> The big problem for us is really going to be the plethora of branches -- of which, none are canonical.
17:20:32 <Oxf13> pardon?
17:21:00 <abadger1999> Oxf13: Projects for which there are numerous upstream branches and none of them are "Linux's tree".
17:21:08 <abadger1999> s/Linux/Linus/
17:21:28 <limburgher> is that common?  No master?
17:21:38 <abadger1999> That's what I see as being a new thing in the last few years.
17:21:45 <tibbs> I think it's not uncommon that master isn't what we want to package.
17:22:16 <limburgher> As long as the VCS tag has a way to specify that, it should work.  Most VCSs allow that in the url.
17:22:25 <Oxf13> abadger1999: how many times though in that situation is there not a canonical release branch?
17:22:26 <abadger1999> Anyhow.. we're getting off topic.
17:22:40 <walters> limburgher: git actually doesn't, but the proposal implements one on top of git's existing URL scheme
17:22:41 <abadger1999> Oxf13: Small and growing :-/
17:23:08 * spot notes that we no longer have quorum, so this topic is informational only
17:23:20 <Oxf13> abadger1999: *shrug* in that case you stick with a tarball if offered, and you track the VCS of whatever people use to contribute patches.
17:24:19 <spot> abadger1999: did you happen to finish the writeup for the arch-specific requires
17:24:21 <abadger1999> Oxf13: That's what I'm saying there's' a growing number of no tarball with no patches -- instead there's twenty+ branches with new features/private work/enhancements/new directions for the project/etc.
17:24:29 <abadger1999> spot: No -- only 25% done.
17:24:38 <spot> abadger1999: okay, we'll revisit it at the next meeting
17:25:04 <walters> so my takeaway action items - I should add the VCS key to the Packaging_tricks page, and hopefully dgilmore will get a chance to review the tool and update fedora-packager?
17:25:39 <abadger1999> walters: And see if you can get rpm upstream to commit or not on adding vcs to spec files.
17:25:50 <walters> abadger1999: ok
17:25:50 <abadger1999> walters: And then figuring out what that means for your goals.
17:25:52 <spot> walters: if you decide to do that, we'll consider the draft withdrawn from consideration
17:26:17 <walters> spot: was that the consensus?
17:26:24 <spot> well, we haven't voted on it
17:26:40 <abadger1999> s/we will/we'd like to/
17:26:58 <abadger1999> if that's okay with you -- otherwise we will need to discuss and vote.
17:27:00 <walters> and a vote can't be taken now because there isn't quorum, correct?
17:27:03 <limburgher> we don't have quorum but is seems consensusy.
17:27:03 <spot> so there is technically no consensus either way, but if you add it to Packaging_tricks, it sortof implies you don't want it in the guidelines proper
17:27:15 <walters> well i would like it in the guidelines
17:27:22 <walters> but i would also like to get back to work
17:27:30 <spot> then, i would say, wait on adding it to Packaging_tricks
17:27:40 <walters> ok
17:27:42 <abadger1999> Do we have enough people here to say that it wouldn't pass?
17:27:42 <spot> and we'll revisit this topic at the next meeting
17:28:05 <walters> spot: ok, sounds good
17:28:17 <limburgher> That depends, are there enough non-present FPC folk who could theoretically all +1 and pass it?  I lost count.
17:28:18 <abadger1999> racor was -1 and there's 4 of us here.
17:28:26 <abadger1999> iirc
17:28:37 <spot> abadger1999: honestly, simply documenting a syntax for a useful comment that some people in our dev community want to use, even with my reservations, i'd probably +1 it as a "should"
17:28:57 <abadger1999> Okay, so not enough to tell either way.
17:30:02 <abadger1999> Were there any questions we wanted to get answered for the library PICness page?
17:30:05 <spot> #topic Open floor
17:30:19 <spot> abadger1999: the only question i know of is how racor thinks it could be done without renaming
17:31:10 <abadger1999> I'd like some examples of packages where we would want to link static libraries into shared libraries.
17:31:42 <spot> fwiw, chromium does it.
17:31:47 <abadger1999> (Perhaps we just need a rule that static-only libraries must be compiled PIC)
17:31:58 <spot> but i don't necessarily think chromium is a champion of doing things sanely.
17:32:05 <abadger1999> :-)
17:33:47 <spot> abadger1999: ajax might be the best person to ask that
17:34:38 <abadger1999> Yeah -- Add questions to the page  and then ping ajax to address them sound good?
17:34:42 <spot> sure.
17:35:03 <ajax> i apologize for not paying more attention to that draft, i'm being pulled in a few other directions recently
17:35:18 <spot> ajax: its okay, i fixed it up as best as i could
17:37:30 <tibbs> spot: Is there any chance of us meeting more regularly?
17:37:46 <spot> tibbs: well, i scheduled the next few meetings
17:37:55 <spot> we could go back to weekly i suppose.
17:37:59 <tibbs> I'm sure you're super busy.
17:38:18 <spot> yeah, but i can make the time.
17:39:03 <spot> tibbs: i'll email folks and see if we can meet next week
17:39:37 <abadger1999> A couple informational notes: it seems like more packages have requested permission to bundle from fesco lately.  We might want to look for criteria to help with that or be more proactive about getting feedback to determine whether specific exceptions are warranted or not.
17:40:23 <spot> abadger1999: okay. i agree with this in principle, but i honestly wouldn't even know how to start codifying it.
17:40:33 <abadger1999> We no longer have any FPC members being auto-cc'd on fesco tickets with FPC relevancy... do we want to have nirik manually subscribe all FPC members to tickets that he thinks are good?
17:41:04 * nirik is happy to try and remember to do so.
17:41:16 <abadger1999> spot: I don't much either -- libiberty and libegg may or may not be some sort of pattern -- in the last fesco, they talked about "libraries intended to be cut and pasted".
17:41:16 <nirik> or if you want I think I can add people to get cc'ed on all tickets.
17:41:45 <abadger1999> but that's pretty vague.
17:41:50 * spot thinks libraries "intended to be cut and pasted" are poorly designed. :P
17:42:08 <tibbs> Can't argue with that.
17:42:08 <pjones> spot: I don't think anybody is arguing that point.
17:42:15 <tibbs> But they exist, unfortunately.
17:42:24 <abadger1999> nirik: That sounds like a good option
17:42:46 <nirik> let me see if I can see how to do that.
17:42:49 <tibbs> Well, as ex FESCo I used to just get the tickets via the mailing list, but not now.
17:43:07 <abadger1999> Same here.
17:43:45 <tibbs> It's not a problem, of course, but I guess an unintended consequence.
17:44:05 * spot as well
17:44:39 <spot> i'm not sure how "libraries intended to be cut and pasted" is anything besides an arbitrary loophole
17:44:49 <spot> intended by whom?
17:45:10 <nirik> ok, I think I can add anyone who wants... just let me know who wants it and what address to add. ;)
17:45:16 <tibbs> I think upstream intent is somehow important.
17:45:26 <spot> nirik: at least me.
17:45:41 <spot> nirik: tcallawa@redhat.com
17:45:45 <tibbs> If a library is being bundled (with patches) and the upstream of that library thinks that's a good thing, then who are we to argue?
17:46:01 <nirik> spot: added. Anyone else?
17:46:06 <spot> tibbs: eh, okay. i disagree, but i see how that is more concrete.
17:46:33 <limburgher> nirik: limb@jcomserv.net
17:46:54 <tibbs> I can see the disagreement, but the problem is that when it gets to this point we're fighting upstream instead of working with them.
17:47:23 <spot> tibbs: okay, but there is a certain amount of "Bad upstream, stop being dumb!" that I would hope we as a distro do.
17:47:49 <tibbs> We can't expect to fight them forever.
17:47:51 <nirik> limburgher: ok.
17:48:04 <tibbs> But I think the point is that we need input from all of the upstreams involved.
17:48:19 <spot> tibbs: sure, okay.
17:48:29 <limburgher> no, but we have to be willing to do so when necessary, or at least document where the stupidity is coming from.
17:48:40 <spot> i think we need to call this meeting, as we're at 1:45
17:49:00 <tibbs> Oh, thought it was called already.
17:49:01 <spot> feel free to keep discussing things if you'd like, but i'm closing it out for the logs
17:49:04 <spot> #endmeeting