17:01:25 <spot> #startmeeting Fedora Packaging Committee
17:01:25 <zodbot> Meeting started Wed Feb  1 17:01:25 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:28 <spot> #meetingname fpc
17:01:28 <zodbot> The meeting name has been set to 'fpc'
17:01:31 <spot> #topic Roll Call
17:01:33 * abadger1999 here
17:01:35 * Rathann here
17:02:25 <spot> geppetto, limburgher, racor, SmootherFrOgZ, tibbs|h: ping
17:02:38 * limburgher is here.
17:02:41 <tibbs|h> Howdy.
17:02:47 * racor here
17:03:49 <spot> okay, we're at 6 people present
17:04:01 <spot> hopefully the other folks will trickle in
17:04:35 <spot> #topic New Packaging Guidelines for Ruby - https://fedorahosted.org/fpc/ticket/134 - https://fedoraproject.org/wiki/PackagingDrafts/Ruby
17:04:52 <spot> the draft author posted some clarifications in comment #3
17:05:50 * SmootherFrOgZ here
17:05:51 <tibbs|h> I agree that the /gems/gems thing looks like someone screwed up.
17:06:03 <tibbs|h> But they maintain that it's supposed to be that way.
17:06:18 <spot> well, i understand how it happened
17:06:20 <spot> (now)
17:06:37 <spot> but i don't think it makes sense to name your toplevel dir "gems" when "rubygems" works just as well
17:07:20 <spot> either way, it might be a bit pedantic. i'm not sure its going to be very user visible
17:08:09 <tibbs|h> I guess it would be nice if /usr/share/X made it kind of obvious that X had something to do with ruby.
17:08:27 <tibbs|h> I mean, python could have used /usr/share/modules and that would have sucked.
17:08:33 <Rathann> so why not /usr/share/ruby?
17:08:33 <spot> tibbs|h: yeah
17:08:58 <spot> Rathann: i thought about that, but ruby is a specific interpreter, and they pointed out that they plan to support multiple interpreters
17:09:12 <spot> since the gems work without modifications for all of the interpreters
17:09:21 <tibbs|h> Which isn't exactly different from Python, in theory at least.
17:09:26 <abadger1999> <nod>
17:09:32 <spot> "rubygems" is more accurate for the contents of that directory
17:09:39 <Rathann> ok
17:09:47 * geppetto is here … just in a meeting.
17:09:52 <geppetto> Another one, that is :o
17:10:00 <racor> spot: Are they trying to replace the package-managers?
17:10:12 <spot> racor: not really.
17:10:46 <racor> spot: what then? I don't understand what they are aiming at.
17:10:49 <spot> this is no better/worse than java dropping .jar files down.
17:11:23 <Rathann> yes, but at least java jars are in /usr/share/java
17:11:40 <tibbs|h> Right, /usr/share/jars would be equally objectionable, I think.
17:11:56 <spot> Rathann: so if they changed the layout to /usr/share/rubygems, it's much more appropriate, right?
17:11:57 <Rathann> so if those gems work with multiple ruby implementations, the language is still called ruby
17:12:16 <tibbs|h> On one level it's bikeshedding, but we're just asking for the shed to indicate that it is bike-related.
17:12:16 <racor> jars .. Java ARchive ... java is in the name, gem ...?!?
17:12:36 <Rathann> I think /usr/share/ruby is the most appropriate name
17:12:36 <SmootherFrOgZ> so how they intend to define each interpreters?
17:12:53 <SmootherFrOgZ> I mean, they could define a path base on the interpreter version
17:13:00 <tibbs|h> I don't think we can know that yet.
17:13:03 <Rathann> but I won't object to /usr/share/rubygems too much
17:13:26 <tibbs|h> I'm prepared to support anything that makes it obvious that the stuff in there is ruby-related and don't care otherwise.
17:13:43 <tibbs|h> But that's just one directory name; we have the whole guideline to look at.
17:13:56 <rdieter> hi
17:14:04 <spot> my opinion is that /usr/share/rubygems/ is the cleanest way to indicate that it contains ruby gems and not pieces of the ruby interpreter
17:14:34 <limburgher> spot: <nods>
17:14:48 <spot> so, lets consider the draft with that change.
17:15:14 <racor> I am still missing an answer to whether these gems are arch-independent
17:15:36 <tibbs|h> There's a whole section about arch-dependent gems.
17:15:43 <tibbs|h> RubyGem with extension libraries written in C
17:15:47 <abadger1999> racor: Only sometimes.
17:16:02 <abadger1999> yeah, what tibbs|h said.
17:16:08 <tibbs|h> Hence %gem_extdir.
17:16:08 <spot> so the ruby files are not arch-dependent, but they may also include C libraries which are.
17:16:15 <racor> More precisely: will the data in /usr/share/[rubygems/gems] be able to cope with  multiarch'ed packages.
17:16:33 <spot> racor: yes, because the files in there will be identical
17:16:57 <rdieter> speaking of clarifying names, would it be too much to rename the macros %{gem_...} to %{rubygem_...} too?
17:17:31 <spot> we currently let them use "%{gemdir}"
17:17:36 <racor> spot: identical files don't necessarily help.
17:17:48 <rdieter> spot: ok, probably not worth it now then
17:17:51 <spot> i don't think there is another type of gem that it would be confused with in this context
17:18:26 <spot> racor: rpm in multiarch deployments is able to cope with identical files across arches
17:18:42 <spot> racor: it really only gets unhappy when files are different.
17:20:13 <racor> spot: Let me try anew: Will it be able to handle situations of noarch, single arch'ed and multi-arched packages. If the files are identical, in all these situations, they are having a problem, AFAIU.
17:20:42 <spot> well, i don't think that you'd have cases where all three are mixed for the same files.
17:20:55 <spot> most rubygems are noarch.
17:21:06 <spot> some have C extension libraries, so they're arch-specific.
17:21:31 <spot> the noarch ones don't overlap with the arch-specific ones any more than say, perl module packages would
17:22:39 <spot> To be honest, the only problem i have with this draft is the same issue I had the first time we documented Ruby:
17:22:57 <spot> the bits get installed into the %{buildroot} in %prep
17:23:00 <tibbs|h> Yes.
17:23:22 <spot> which isn't entirely true
17:23:27 <tibbs|h> Not just that, but arch-specific stuff actually gets compiled in %prep.
17:23:39 <spot> tibbs|h: yes, thats more accurate.
17:23:40 <tibbs|h> But there is no other way to do it, I think.
17:23:44 <racor> spot: perl isn't multi-arched in Fedora .. it's singled arch'ed.
17:24:16 <spot> racor: yes, i know, i was pointing out that perl handles a mix of noarch and arched modules just fine
17:24:53 <spot> racor: as to multi-arch support, since the %{gem_extdir} evaluates to %{_libdir}/gems/exts/%{gem_name}-%{version}
17:25:04 <spot> and %{_libdir} is different on the multi-arch targets
17:25:21 <spot> there should be no conflict in the differing files, should rubygems ever go multi-arch
17:26:40 * abadger1999 has added some more issues I've spotted to the ticket.
17:26:54 <spot> so, back on "code building in %prep"
17:27:12 <spot> last time we had this issue, we couldn't figure out a way to put it in %build, so we let them do it in %prep
17:27:29 <rdieter> has the situation changed?
17:27:37 <spot> not to my knowledge
17:27:39 <tibbs|h> I doubt it.
17:27:48 <abadger1999> spot: I think that's actually bad... since it leaves me unsure how you'd apply a Fedora patch to a gem with C extensions.
17:28:05 <abadger1999> (That was one of the issues I just added to the ticket)
17:28:10 <spot> abadger1999: well, you just apply the patch above the "gem install" invocation
17:28:13 <tibbs|h> I think that works OK.
17:28:23 <tibbs|h> %setup gets called normally.
17:28:34 <abadger1999> spot: the source files have been extracted at that point?
17:28:42 <SmootherFrOgZ> spot: what's the issue?
17:28:44 <spot> abadger1999: yeah, %setup -q -c -T
17:28:58 <SmootherFrOgZ> I've gem package which gem install in %%build
17:29:09 <tibbs|h> The problem with wading into this is that I can't personally remember why gem install can't be called in %build.
17:29:12 <abadger1999> Hmm...
17:29:22 <abadger1999> Then the gem install could be done in %build or %install...
17:29:25 <tibbs|h> But there was big discussion about it back then.
17:29:31 <abadger1999> There's no reason they'd need to be done in %prep
17:29:40 <spot> yeah, i wish i could remember why it didn't work right
17:29:43 <rdieter> abadger1999: +1 (unless we're missing something)
17:29:43 <SmootherFrOgZ> abadger1999: yep
17:29:46 <geppetto> tibbs|h: Installing into buildroot in %build seems bad.
17:29:56 <spot> geppetto: that was incorrect.
17:29:58 <geppetto> Much more so than possibly building in %install.
17:29:58 <SmootherFrOgZ> look at rubygem-json
17:29:59 <abadger1999> geppetto: it's not installing into %buildroot
17:30:11 <geppetto> spot: Yeh, but that's only native, right?
17:30:11 <spot> i misstated it, i meant to say "building files"
17:30:15 <abadger1999> gem install         --install-dir .%{gem_dir}
17:30:35 <spot> it's going into a temporary target, then %install just copies it into the %buildroot
17:30:38 <abadger1999> it's installing into the BUILDDIR area
17:31:48 <spot> so... okay. i think it's worth asking that the gem install block be moved to %build
17:31:56 <SmootherFrOgZ> yes
17:32:10 <spot> and perhaps we will get a reminder of the same roadblock we hit before
17:32:55 <tibbs|h> I seem to remember they were trying to rush this guideline.
17:33:18 <SmootherFrOgZ> you can add a link to rubygem-json if they do need example on how to manage %build stage if necessary
17:33:26 <tibbs|h> So if we do get an answer it may be useful to vote int the ticket instead of waiting until next week.
17:33:30 <rdieter> right, in time for ruby f17 feature
17:33:58 <SmootherFrOgZ> tibbs|h: +1
17:34:05 <spot> okay, i think if we get good answers, i'll call for a vote in the ticket
17:34:17 <limburgher> SOunds reasonable.
17:34:20 <abadger1999> errr
17:34:23 <spot> if you have any questions or points to add, please do so in comments
17:34:45 <abadger1999> I just tested a rubygem with just %setup and it didn't seem to create files.
17:35:11 <spot> oh yeah. now i am remembering
17:35:20 <spot> packages derived from gems have the gem as Source0
17:35:27 <spot> so the unpack just makes the directory hierarchy
17:35:49 <spot> or rather, the %setup invocation just makes the directory hierarchy
17:36:08 <spot> gem_install "unzips" the gem and lays out the files in the tempdir in BUILDDIR
17:36:21 <spot> (and on arch specific gems, it builds the C extension at the same time)
17:36:25 <abadger1999> yeah, which leads me back to -- how do you patch a rubygem if it has a C extension?
17:36:45 <spot> abadger1999: a very good question.
17:37:35 <abadger1999> Well, that's one of the issues I added to the ticket, so I guess they'll answer or not.
17:38:46 <spot> okay, lets move on
17:39:05 <abadger1999> Might be worthwhile having them post a sample srpm that complies with the new guidelines for us to poke.
17:39:10 * abadger1999 will request in the ticket
17:39:14 <spot> #topic New PHP Guidelines - https://fedorahosted.org/fpc/ticket/136 - https://fedoraproject.org/wiki/PackagingDrafts/PHP
17:39:17 <spot> abadger1999: agreed, thanks.
17:39:49 <spot> Remi updated the draft to include an explanation of ZTS and he renamed the executables to be prefixed with "zts-", instead of using a subdir
17:40:43 <spot> that resolved all of the outstanding issues that I had.
17:41:27 <spot> so, i'm +1 here
17:41:32 * rdieter too, +1
17:41:37 <SmootherFrOgZ> +1
17:41:41 <tibbs|h> Yeah, looks OK to me as well; I think it needs a quick pass of grammar checking but that can be fixed during the writeup.
17:41:43 <tibbs|h> +1
17:41:49 <racor> I dislike the prefix/suffix inconsistency
17:42:05 <limburgher> +1
17:42:23 <tibbs|h> racor: He changed it around a couple of times; I'm not sure why.
17:42:51 <racor> -1 ... proposal is uncooked. I'd +1, if it was consistent.
17:42:59 <geppetto> +1
17:43:18 <geppetto> I'd probably name it differently … but, w/e :)
17:43:28 <spot> rdieter, abadger1999, Rathann haven't voted yet. (my kingdom for the bot to learn how to keep votes)
17:43:28 <Rathann> I think it could be because the subdirectory was called /usr/bin/php-zts
17:43:35 <spot> Rathann: yes.
17:43:41 * rdieter voted +1
17:43:44 <spot> and he actually had that in rawhide
17:43:46 <abadger1999> Looks good
17:43:47 <abadger1999> +1
17:43:55 <spot> rdieter: indeed you did, sorry
17:44:22 <Rathann> he mentioned something about broken upgrade from dir to a file with the same name
17:44:59 <racor> spot: and now he twisted up things in confusing ways, only he might understand.
17:45:08 <spot> #action PHP draft approved (+1:7, 0:0, -1:1)
17:45:14 <spot> racor: i wouldn't go that far.
17:45:34 <spot> but anyways, your concerns are noted in the log and the vote count
17:45:42 <Rathann> +1 from me
17:45:54 <spot> okay, lets move on
17:46:13 <spot> #topic Allow Multiple File Ownership - https://fedorahosted.org/fpc/ticket/138
17:46:31 <spot> i put a proposal in a comment for a draft right before this meeting
17:46:56 <spot> this would be in replacement of the existing "Packages must not own files already owned by other packages"
17:47:10 <limburgher> I saw that, and I like it, with cwickert's comment as well.
17:47:32 <spot> limburgher: yep, i see that now, and i'm fine with it
17:47:37 <rdieter> though I still think it generally wiser for packages to require a shared subpkg for stuff like this (to avoid possible version skew), +1 to the draft
17:48:12 <spot> +1 to the draft with minor cwickert addition in comment 2
17:48:19 <limburgher> +1
17:48:26 <racor> spot: +1
17:48:29 <geppetto> +1
17:48:33 <SmootherFrOgZ> +1
17:48:54 <Rathann> if they're built from the same package, they usually have the same version
17:48:56 <geppetto> We could add some wording about co-maintenance etc. … but meh
17:49:03 <geppetto> yeh
17:49:09 <Rathann> +1
17:49:34 * abadger1999 reads quickly
17:49:42 <tibbs|h> I'm trying to think of negative implications of this.
17:49:46 <rdieter> Rathann: there's intersting cases like user installs foo-gtk2-1.0, now there's a foo-gtk3-1.1 in updates, yum install foo-gtk3 may result in conflicts now (since that won't necessarily update foo-gtk2 too)
17:50:10 <abadger1999> +1
17:50:39 <spot> rdieter: if they're built from the same SRPM, its a non-issue, because both will get updated simultaneously
17:50:51 <tibbs|h> Can't think of anything negative, really.
17:50:53 <tibbs|h> +1
17:50:56 <rdieter> spot: yum install foo-gtk3   will update an foo-gtk2 too?  I think not
17:51:17 <rdieter> if user does a, yum update prior , all will be ok, but that doesn't always happen
17:51:17 * abadger1999 seems to recall that mschwendt was the one who best knew what issues arose from files owned by multiple packages.
17:51:26 <spot> rdieter: oh, i see, if the identical file changed in the newer gtk3 bits
17:51:29 <abadger1999> but I don't remember any of the discussion
17:51:31 <rdieter> yup
17:51:37 <geppetto> They can/should add explicit conflicts when they do this.
17:51:37 <tibbs|h> I do have a question, however.
17:51:48 <tibbs|h> How do we know that file-sharing is really needed?
17:52:04 <rdieter> tibbs|h: packager's discretion
17:52:14 <spot> tibbs|h: it usually isn't, hence, the fact that cwickert is the first person who has really run into this in... oh, years.
17:52:24 <tibbs|h> Packagers could just do it by mistake, and that doesn't appear to be a problem according to the guidelines.
17:52:35 <tibbs|h> It comes up in reviews relatively often, for example.
17:52:56 <tibbs|h> Generally people duplicate documentation files between packages, for example.
17:53:13 <tibbs|h> I guess if we don't care then we cana relax that check.  And don't we have to turn off some check in RPM to allow it?
17:53:34 <spot> tibbs|h: the rpm check isn't an error, just a warning, iirc
17:54:02 <tibbs|h> I honestly can't recall.
17:54:41 <spot> I suppose we could add a line to it that says something like "In most cases, it should not be necessary for multiple packages to contain identical copies of the same file. However, if it is necesssary, multiple packages ..."
17:54:42 <geppetto> spot: the "file mismatch" is an error, or do you mean something else?
17:55:02 <spot> geppetto: no, the "multiply packaged files" error
17:55:09 <spot> err, warn
17:55:20 <geppetto> Oh, yeh, that's an rpmbuild warning IIRC.
17:55:53 <spot> tibbs|h: is that additional guidance line useful/helpful to prevent mindless multiple ownership?
17:56:06 <geppetto> I've ignored it in at least once, where I wanted 1 file from a dir. in one sub-package but all of them (maybe except the 1) in the other.
17:56:08 <spot> leaves necessary up to the packager.
17:56:09 <geppetto> Just easier :)
17:56:18 <tibbs|h> spot: Sure, I wouldn't complain.
17:56:30 <geppetto> Has everyone voted?
17:56:32 <spot> Can i get a quick round of votes on that addition?
17:56:47 <spot> "In most cases, it should not be necessary for multiple packages to contain identical copies of the same file. However, if it is necesssary, multiple packages ..."
17:56:51 <tibbs|h> +1
17:56:53 <geppetto> +1
17:56:53 <SmootherFrOgZ> +1
17:56:56 <abadger1999> +1
17:57:09 <spot> +1
17:57:18 <limburgher> +1
17:58:30 <spot> Rathann, racor, rdieter (the rs) have not voted on this addition
17:58:39 <spot> we are at +6
17:58:45 <rdieter> +1
17:58:54 <racor> +1
17:59:37 <Rathann> +1
17:59:43 <spot> #action draft from comment 1, with change from comment 2, and additional guidance from meeting is approved (+1:9, 0:0, -1:0)
17:59:49 <SmootherFrOgZ> ls
17:59:58 <spot> SmootherFrOgZ: no such command
18:00:08 <SmootherFrOgZ> :)
18:00:20 <tibbs|h> It moved to /usr/bin
18:01:24 <spot> okay
18:01:28 <spot> we're at the hour mark
18:01:43 <spot> but there is only one more ticket and one more followup
18:01:49 <limburgher> I had something too.
18:01:54 <spot> so, lemme get the followup out of the way
18:02:05 <spot> #topic php, libzip, and bundling
18:02:12 <racor> ... I've ca. 5 mins left
18:02:21 <spot> I spent some time working on this with Remi and the libzip upstream
18:02:49 <spot> libzip upstream is adding some necessary public functions to replace the private ones that PHP was using which required the bundling
18:03:06 <spot> once that is done, we will be able to unbundle libzip and re-enable the PHP zip module
18:03:24 <spot> thats all.
18:03:39 <tibbs|h> Is there a need for a temporary exception?
18:03:39 <limburgher> Sounds reasonable, ETA?
18:03:42 <rdieter> heros!
18:03:44 <geppetto> can we just deny the bundling until it happens ?:)
18:04:01 <spot> i don't know what the ETA is, libzip seems interested in fixing it
18:04:03 <tibbs|h> We denied the bundling already, and the package dropped out of the distro as far as I know.
18:04:11 <spot> the bundling is denied right now
18:04:16 * geppetto nods
18:04:31 <spot> remi was considering asking for a temporary exception
18:04:34 <spot> but he has not yet done so
18:04:38 <geppetto> That's what I meant … gives the php guys more incentive to get it fixed too then.
18:04:55 <abadger1999> Thanks spot!
18:05:22 <tibbs|h> I'd go for a temporary exemption given the current status, honestly, but if it's not being requested then that's kind of pointless.
18:05:36 <spot> limburgher: go ahead, i think the other ticket (a bundling exception) is going to be a long one, maybe good to push out for next week
18:05:44 <limburgher> K:
18:05:59 <limburgher> More a question than anything: https://fedorahosted.org/fpc/ticket/135
18:06:33 <spot> limburgher: well, the obvious answer is "no, that's bundling, use the system versions"
18:06:58 <spot> but if that's not a useful answer, i suppose we could consider it for a bundling exception
18:07:19 <rdieter> limburgher: or at least provide justifications why the system versions can't (or shouldn't) be used
18:07:45 <limburgher> No, that's what I thought but wanted it clarified.  I think I'll need to package medit, it's not in Fedora.
18:08:06 <spot> Okay. i'm being dragged away....
18:08:14 <spot> so unless there are other urgent items, i propose we end it
18:08:16 <limburgher> If I do that, use the system versions and it blows up, I'll revisit.
18:08:20 <limburgher> Nope.
18:08:25 * rdieter recalls another iris-related bundling request
18:08:29 <spot> we;ll look at ticket 138 next week
18:08:40 <spot> which is the fun psi+/iris bundling item
18:08:45 <spot> errr
18:08:47 <spot> 137, sorry
18:08:53 <rdieter> https://fedorahosted.org/fpc/ticket/137
18:08:56 <abadger1999> limburgher: Depending on how big the chunk of code, I can see giving it an exception... but would need more information
18:08:58 <rdieter> ok
18:09:09 <spot> feel free to comment in the ticket in the interim
18:09:13 <spot> thanks everyone
18:09:14 <limburgher> abadger1999: I think it's like 1 file each.
18:09:25 <limburgher> thanks!
18:09:26 <spot> #endmeeting