17:01:12 <spot> #startmeeting Fedora Packaging Committee
17:01:12 <zodbot> Meeting started Wed Jan 25 17:01:12 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:15 <spot> #meetingname fpc
17:01:15 <zodbot> The meeting name has been set to 'fpc'
17:01:22 <spot> #topic Roll Call
17:02:39 * racor is here
17:02:47 <tibbs|h> Finally I'm in the right channel at the right time.
17:03:46 <tibbs|h> I was around but busy the previous two weeks; a ping in the regular meeting channel or -devel would have gotten me here.
17:04:47 * spot is still making an agenda while we wait for people to announce their presence
17:04:52 * Rathann here
17:06:31 * geppetto is here
17:08:58 * spot grumbles at the stupid Red Hat internet connection
17:10:21 <spot> so, in between my office internet dropping, i saw 5 of us here
17:10:23 <spot> racor, tibbs|h, Rathann, geppetto, and me
17:10:24 <spot> anyone else?
17:10:30 <spot> okay, i suppose not.
17:10:42 <geppetto> abadger1999: ping?
17:10:50 * abadger1999 here
17:10:57 <spot> #topic https://fedorahosted.org/fpc/ticket/126 - bundling exception for perl-Wx-Scintilla
17:11:51 <spot> so, in reviewing this, i noted that there is no packaged version of just "scintilla"
17:12:22 <Rathann> that's actually no excuse ;)
17:12:32 <spot> and at least two other packages which claim to be based on scintilla (qscintilla and scite)
17:12:40 <Rathann> do they conflict?
17:12:42 <spot> in addition to perl-Wx-Scintilla
17:12:53 <abadger1999> right... your plan sound sreasonable... just need to get scintilla in (and then find out whether qscintilla nad scite have reason to bundle)
17:12:53 <tibbs|h> Might want rdieter_work around to talk about that, since he's pretty familiar with at least some of the scintilla stuff.
17:13:09 <spot> they don't conflict, but their copy of scintilla is compiled in
17:13:54 <tibbs|h> scintilla has been a mess for some time.  I'm not really sure why that happened.
17:13:55 <spot> i'm pretty sure the bundled scintilla in qscintilla is not the v3 code
17:14:47 <spot> rdieter_work: ping?
17:15:50 <spot> so, unless someone thinks we should permit scintilla to be an approved bundling exception across the board
17:16:14 <tibbs|h> I think it's reasonable to at least try to get the mess cleaned up.
17:16:26 <tibbs|h> But it's not us actually doing the work, so....
17:16:29 <spot> it seems like there is some work here to not only get scintilla packaged, but get perl-Wx-Scintilla to use it, and then analyze the qscintilla and scite situations
17:16:43 <spot> well, normally, i volunteer for this work
17:16:54 <spot> but at the moment, i'm really really really backlogged with stuff
17:17:11 <spot> i don't suppose anyone here wants to volunteer to work on this one
17:18:00 <Rathann> I'm up to my ears preparing for flat renovation, sorry :(
17:18:35 <spot> okay then, well, it goes in my todo pile
17:19:04 <spot> #topic Extend info about locale files - https://fedorahosted.org/fpc/ticket/128 - https://fedoraproject.org/wiki/PackagingDrafts/find_lang
17:20:06 <spot> this draft seems fine to me
17:20:18 <geppetto> Yeh, not much to comment on really … +1
17:20:38 <spot> +1 from me
17:20:52 <rdieter> here
17:21:58 <tibbs|h> This draft replaces everything up toi the "Why do we need to use %find_lang?" subsection?  Or does that bit get dropped?
17:22:02 <abadger1999> +1
17:22:56 <rdieter> +1
17:23:12 <spot> tibbs|h: looking
17:23:57 <racor> I am having some doubts on some details of this draft, nevertheless +1
17:24:28 <rdieter> tibbs|h: I guess so
17:24:40 <spot> i think it is safe to keep that subsection
17:24:49 <spot> it still is valid even with the new draft
17:25:12 <rdieter> right
17:25:33 <rdieter> racor: such as?  any suggestions to make it better?
17:25:58 <abadger1999> spot: +1
17:26:17 <Rathann> +1 from me as well
17:26:25 <racor> I am not sure if "BR: gettext" is actually mandatory.
17:26:53 <geppetto> yum spec still has it
17:27:04 <tibbs|h> It's not actually required for the %find_lang stuff, of course.
17:27:04 <spot> I see +6 on this item, I think the only voter missing is tibbs|h
17:27:16 <tibbs|h> It's _probably_ required for most autoconf packages.
17:27:40 <rdieter> tibbs|h: true, in my experience
17:27:41 <tibbs|h> +1 from me
17:27:59 <racor> tibbs|h: That's the question I am not sure about. Normally, all auto*tools based packages should not require any of these tools.
17:28:14 <tibbs|h> Sorry, I'm a bit distracted; there's a mesocyclone above my house at the moment.
17:28:24 <spot> #action Draft approved (also, we will retain the "Why do we need to use %find_lang?" subsection) (+1:7, 0:0, -1:0)
17:28:30 <rdieter> many pkgs end up using msgfmt at some point
17:29:03 <rdieter> those need BR: gettext obviously
17:29:18 <spot> #topic piglit bundling exception for glew - https://fedorahosted.org/fpc/ticket/132
17:29:46 <racor> rdieter: sure, there are packages, which require gettext, my point is: Is the strong language being used in the draft actually correct or not?
17:30:01 <racor> I am simply not sure and would have to check ...
17:30:24 <spot> racor: its never harmful, worst case, it inflates the Build env a bit, best case, it ensures proper locale generation
17:31:20 <spot> also noteworthy is that the BuildRequires: gettext language is present in the current find_lang text
17:31:39 <rdieter> good point, it's not a regression.
17:31:41 <geppetto> My inclination for piglit is to say -1 … just don't put it into Fedora, doesn't seem like a great package to package atm.
17:34:01 <spot> well.
17:34:04 <spot> i see that.
17:34:14 <spot> it seems like a useful QE test tool though.
17:34:18 <rdieter> +1 , there's little harm, sharing code doesn't make sense here. (i'd argue it's not our place to decide if something is worth packaging or not)
17:34:28 <tibbs|h> To be honest I tend to come down on the side of allowing bundling in cases where some test suite is just trying to compile some code to get a reproducible case.
17:34:29 <geppetto> Obv. they can create a repos.fedorapeople.org or w/e
17:34:40 <spot> it has a shared upstream with the glew folks
17:34:52 <spot> so it is a similar case to the sourceware exception we granted before
17:35:23 <geppetto> I guess my main thoughts are: 1) Not going to have many users. 2) Huge bundling. 3) Going to do ~25 updates per. Fedora release.
17:36:07 <geppetto> Actually … "at least" 25 updates per. Fedora release.
17:36:13 <abadger1999> So... who uses this?  Is it driver developers?
17:36:17 <abadger1999> Bug reporters?
17:36:35 <geppetto> Xorg driver devlopers, I think.
17:36:52 <tibbs|h> Well, anyone who wants to test stuff.
17:36:53 <geppetto> And Xorg driver QA.
17:36:53 <racor> What is a testsuite useful for, which is testing a bundled library?
17:37:26 <geppetto> Comment says "Yes, because it is not that much testing of this library but rather general GL and drivers implementation"
17:37:37 <racor> => -1
17:38:43 <spot> i'm very much on the fence here, my instincts tell me this is a bad idea, but given that the upstream is the same, the risk of divergence is probably very very low
17:39:00 <abadger1999> I see these two lines as being in conflict:
17:39:02 <abadger1999> "I wouldn't expect that changes be useful to anybody else."
17:39:13 <abadger1999> "Yeah from X.org/Mesa point of view this makes most sense, we've often had to patch glew with fixes we find in testing "
17:39:45 <geppetto> spot: Yeh, I'm not really worried about the bundling as such … it just seems like a package that is changing so much it's just wasting everyone's time to put it in Fedora.
17:40:07 <spot> geppetto: well, we're not the package police, so all we can look at here is the bundling
17:40:13 * abadger1999 on the fence as well
17:40:27 <tibbs|h> Indeed.
17:40:41 <geppetto> Yeh, as abadger1999 says … if they fix glew with all the bugs they fix … at least the users will get something out of the pain.
17:41:08 <geppetto> So, again, -1.
17:41:11 <racor> geppetto: I don't see much sense in Fedora shipping a package which only tests itself and not the system.
17:41:23 <spot> Yeah, okay. I'm -1 here.
17:41:59 <geppetto> racor: Well, the theory is that it's testing all the system below glew.
17:42:31 <abadger1999> +0 -- I'd be willing to think on this more and ask more questions but I'm not yet to the point where it seems like the case for bundling makes sense.
17:42:45 <spot> so, i think the vote count is this: (+1:1, 0:1, -1:3)
17:42:57 <tibbs|h> I guess my question to the last comment in that ticket would be "well, if you found bugs in glew, why not patch them globally so that everyone benefits?"
17:43:32 * Rathann is with tibbs|h on this one
17:43:32 <tibbs|h> And I guess if I don't know why they can't do that, I can't vote for this.
17:43:42 * spot doesn't see a vote from Rathann or tibbs|h
17:43:55 <Rathann> -1 with the information so far
17:43:59 <tibbs|h> Gotta say -1 at this point.
17:44:22 <spot> okay. i'll let them know we denied the request and invite them to answer tibbs's question if they want to try again
17:45:12 <tibbs|h> That's pretty much the fundamental question when it comes to bundling.
17:47:03 <spot> #topic Bundle Library Exception for iText in pdftk - https://fedorahosted.org/fpc/ticket/133
17:47:13 <tibbs|h> I can't believe this is back.
17:47:30 <spot> i have to believe that this is possible to do without bundling
17:47:49 <spot> (ignoring the EPEL aspect at this time)
17:47:52 <tibbs|h> Definitely not enough info there to make a decision.
17:48:06 <spot> i'm going to ask some of the java sig folks to take a look at this
17:48:21 <spot> as this is definitely not one of my areas of expertise
17:48:32 <tibbs|h> Yes, if a java expert can explain what's up here it would be a great help.
17:48:50 <spot> anyone opposed to tabling this until i can have them explain whether this is a valid issue or not?
17:48:52 <rdieter> not enough info indeed
17:48:58 <tibbs|h> Also, do we even want to wade into the issue of bundling stuff to work around old packages in RHEL?
17:49:36 <spot> i think we can bounce the epel issue over to the EPEL sig for resolution
17:49:54 <abadger1999> spot: +1  to both of those
17:49:58 <rdieter> tibbs|h: that is valid use-case for bundling though
17:50:03 <abadger1999> (tabling and bouncing the epel issue)
17:50:29 <abadger1999> rdieter: or getting maven into epel6....
17:50:33 <spot> okay, lets move on, we're at 50 minutes.
17:50:45 <spot> #topic https://fedorahosted.org/fpc/ticket/134 - New Packaging Guidelines for Ruby
17:50:57 <spot> https://fedoraproject.org/wiki/PackagingDrafts/Ruby
17:51:22 <tibbs|h> Wiki very slow....
17:51:27 <spot> no kidding
17:51:52 <tibbs|h> Of course I cleaned up my tabs earlier so I no longer have this open.
17:52:00 * spot wonders if we're running on the bank of POTS modems again...
17:52:01 <rdieter> i don't know much about ruby, but when they say, Each Ruby package must indicate the Ruby ABI version it depends on with a line like  Requires: ruby(abi) = 1.9.1
17:52:07 <rdieter> how does one know what to put there?
17:53:05 <zodbot> Announcement from my owner (jsmith): Fedora Board IRC meeting at 18:30 UTC (approximately 40 minutes from now) in #fedora-meeting
17:53:23 <tibbs|h> I also recall some list discussion about some serious bad interaction between rpm-installed gems and gem-installed gems.
17:53:30 <geppetto> page still not loaded, here
17:53:32 <tibbs|h> And would like to know what that's all about.
17:53:36 <rdieter> otherwise, my eyes are glazing over reading this.  tempted to just +1 rubber stamp, as it seems largely simply the ruby-sig documenting the status quo (or what they want it to be)
17:53:38 * spot is in the same boat as geppetto
17:54:03 <spot> i looked at it earlier and nothing seemed awful
17:54:05 <geppetto> rdieter: What does the diff look like?
17:54:07 <spot> but i wanted to actually diff it
17:54:15 <tibbs|h> Because if something in our packages actively gets in the way of using the language-specific install methods then there's a problem.
17:54:19 <tibbs|h> page loaded for me.
17:54:31 <rdieter> not sure what the diff is
17:54:54 <tibbs|h> rdieter: BTW, the answer to your "how do you know what to put there" is that it's not documented at all.
17:55:45 <tibbs|h> They did not appear to start with the current page, so there's no diffing.
17:55:55 <rdieter> tibbs|h: I figured.  other languages, e.g. perl, you can query at build/run time what that should be.  wonder why ruby doesn't do something like that
17:56:13 <racor> rdieter: Yeah, I'd need a diff to be able to comment on this.
17:56:40 <abadger1999> Some things I remember from the original  ruby approval.... we wanted to make sure the rubygems were usable both as gems and as regular ruby includes/imports/etc
17:57:10 * spot is looking at a diff
17:57:11 <abadger1999> We wanted to be sure things were created from source.
17:57:21 <spot> but it is pretty significant
17:57:27 <Rathann> %{gem_instdir} 	%{gem_dir}/gems/%{gem_name}-%{version}
17:57:32 <Rathann> and
17:57:38 <Rathann> %{gem_dir} 	/usr/share/gems
17:57:44 <abadger1999> Something that's come up in a review I had recently was that it isn't obvious how to patch a gem if we need to change it.
17:57:56 <Rathann> so the instdir expands into /usr/share/gems/gems/%{gem_name}-%{version}
17:58:07 <Rathann> looks fishy
17:58:13 <tibbs|h> In general this appear to be far more explanatory than the previous page.
17:59:08 <geppetto> I think this is the diff: https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&diff=267678&oldid=263895
17:59:20 <geppetto> It's … big
17:59:21 <spot> i'm betting that gem_instdir is simply not correct in the draft
18:00:17 <spot> geppetto: yeah, that looks right. i just pretended like i was committing the draft changes and told it to show me the diff before committing
18:00:25 <spot> looks the same on a quick eyeball
18:02:23 <Rathann> hm, no %build section - does it mean ruby gems are not compiled?
18:03:05 <tibbs|h> "It's complicated"
18:03:23 <Rathann> ok
18:03:59 <tibbs|h> Some of them are, but the gem install thing will build them, so it all happens in %setup.
18:04:46 <Rathann> I assume there was a good reason to do it in %setup
18:05:09 <spot> %{ruby_sitearchdir} and %{ruby_sitelibdir} were used before, but now they point to /usr/local
18:05:14 <tibbs|h> It's been that way for some time; I think originally we just concluded that it didn't really work any other way.
18:05:22 <Rathann> ok
18:05:24 <tibbs|h> spot: Yes, it appears that every package needs changing.
18:05:31 <spot> ugh.
18:05:54 <tibbs|h> I think this is part of the question I asked earlier.
18:06:05 <spot> however, this is planned for the 1.9.3 feature "Rebuilding of all Ruby packages, and all packages depending on Ruby "
18:06:14 <tibbs|h> about bad interaction between rpm-installed and "gem install"-installed gems.
18:06:54 <geppetto> tibbs|h: Yeh, from what I can see it's "now" the case that all rpms will actually be gems too
18:07:16 <geppetto> tibbs|h: So, my guess is that if you use gem install directly, it'll start overwritting rpm data.
18:07:31 <geppetto> And then the rpm updates will re-write the gem data etc.
18:07:56 <spot> geppetto: gem install should be using /usr/local/...
18:08:09 <spot> so once everything is rebuilt to use the "vendor" paths
18:08:09 <geppetto> Ahh
18:08:24 <spot> so that should not be an issue
18:08:42 <geppetto> meh … I'm +1 … without roughly the least knowledge of ruby on this channel :)
18:08:51 <geppetto> s/without/with/
18:08:56 <spot> I'd like clarification on %{gem_instdir}
18:09:07 <tibbs|h> I found a couple of typos that I can fix up after we're done.
18:09:07 <spot> i think it should be %{gem_dir}/%{gem_name}-%{version}
18:09:18 <spot> instead of %{gem_dir}/gems/%{gem_name}-%{version}
18:09:33 <abadger1999> +0 -- want more information
18:09:50 <tibbs|h> +0 as well at this point.
18:09:59 <geppetto> spot: I don't think so, because they also have gem_cache
18:10:08 <racor> I am having a problem with gem_dir == /usr/share/gems
18:10:08 <geppetto> And gem_docdir
18:10:12 <abadger1999> for instance, why we're dropping support for non-gem usage.
18:10:22 <tibbs|h> There's a mailing list thread about this; let me dig out the reference.
18:10:23 <racor> are gems arch independent and ruby independent?
18:10:49 <tibbs|h> http://lists.fedoraproject.org/pipermail/devel/2012-January/161586.html
18:10:53 <geppetto> Hmm … actually gem_cache shoudl be gem_cachedir … no?
18:10:55 <tibbs|h> racor: Not in general, no.
18:10:58 <tibbs|h> Some gems are binary.
18:11:45 <Rathann> and these go into %{_libdir}/gems
18:11:48 <racor> So gem_dir == /usr/share/gems is arch-dependent?
18:12:12 <tibbs|h> Well,
18:12:23 <racor> s/is arch-dependent/contains arch-depended data/
18:12:28 <tibbs|h> There's a "RubyGem with extension libraries written in C" section
18:12:38 <tibbs|h> And that passes         --install-dir .%{gem_dir} \
18:12:40 <tibbs|h> So....
18:13:00 <tibbs|h> Ah, but:
18:13:00 <spot> %{gem_extdir} == %{_libdir}/gems/exts/%{gem_name}-%{version}
18:13:05 <tibbs|h> During the %install section all architecture specific content must be moved from the %{gem_instdir} to the %{gem_extdir}. Usage of %{gem_extdir} assures that the binary files are placed under the proper directory under /usr according to FHS.
18:13:16 <tibbs|h> So, bloody weird.
18:13:25 <tibbs|h> They get built into the wrong place and then you move them in %install.
18:13:48 <tibbs|h> Bottom line is that all of this is working around "the way gems work".
18:14:02 <racor> I regret, I need to quit now. My vote: 0, need more information.
18:14:25 <spot> so, folks who need more info, please add comments to this ticket
18:16:00 <tibbs|h> They are trying to push our ruby packages in a direction that better integrates with the system, it appears, so I think this is moving in the right direction.
18:16:01 <spot> #topic PHP Draft Changes - https://fedoraproject.org/wiki/PackagingDrafts/PHP - https://fedorahosted.org/fpc/ticket/136
18:16:07 <tibbs|h> This just came in.
18:16:12 <spot> this is a reasonably minor change
18:16:15 <abadger1999> Would it be possible for one of the people responsible for the new ruby draft to show up as well?
18:16:18 <tibbs|h> Needs some work, though.
18:16:28 <abadger1999> A point-by-point, this is what we changed and why would be extremely helpful
18:16:29 <geppetto> PHP and Ruby in one day … !:o
18:16:34 <spot> it just defines some new macros
18:16:37 <tibbs|h> What does this mean: The php-devel package in fedora >= 17 (5.4.0) provides needed stuff to build ZTS macro and provides several new macros:
18:16:55 <spot> s/ZTS macro/ZTS module
18:16:58 <spot> RemiFedora: right?
18:17:02 <RemiFedora> yes
18:17:04 <tibbs|h> Am I expected to know what ZTS is?  How do I know if I need it?
18:17:23 <RemiFedora> and "needed stuff" means headers (and some binaries)
18:17:40 <tibbs|h> Or better, if I'm reviewing a package, how do I know if a that package should have ZTS macros in it but doesn't?
18:17:51 <RemiFedora> ZTS = Zend Threaed Safe (for Apache worker mode)
18:18:18 <tibbs|h> I guess I'm saying that those questions should be answered by the guideline if at all possible.
18:18:57 <spot> RemiFedora: how will a packager know if their php pecl package uses the ZTS macros?
18:19:05 <spot> or rather, needs to use them?
18:19:13 <RemiFedora> it's a packager choice
18:19:25 <geppetto> Also, last sentence "%{php_ztsbindir} contains the executables needed during the build of ZTS extension " should be "%{php_ztsbindir} contains the executables needed during the build of a ZTS extension, which are:"
18:19:45 <RemiFedora> by default, he build only the "standard" extension
18:19:45 <geppetto> apart from that, I guess … +1
18:20:06 <tibbs|h> RemiFedora: Should it be a packager choice?  Wouldn't we want all of the extensions available regardless of which thread model you have configured apache to use?
18:20:19 <abadger1999> Am I reading that %{php_ztsbindir} is a subdirectory of %{_bindir} ?
18:20:30 <RemiFedora> no, because packager must be sure than the used library are thread safe
18:20:48 <tibbs|h> Ah, well, then that's the kind of thing that needs to get into the guideline page.
18:21:15 <tibbs|h> Otherwise you get people just turning it on because they can, or because someone asked, but without any understanding of what might not work.
18:21:47 <spot> can we actually put binaries in subdirs of /usr/bin without violating FHS?
18:22:34 <Rathann> no
18:22:43 <tibbs|h> Well, fhx allows /usr/bin/mh explicitly.
18:23:02 <spot> tibbs|h: you sure?
18:23:12 <tibbs|h> "The following directories, or symbolic links to directories, must be in /usr/bin, if the corresponding subsystem is installed:"
18:23:35 <spot> okay, i see that
18:23:49 <tibbs|h> That's 2.3; is that the latest version?
18:23:49 <spot> but thats not a general exception
18:23:50 <geppetto> Also, /usr/bin/gda_trml2pdf/__init__.py etc.
18:23:53 <spot> tibbs|h: it is
18:24:09 <geppetto> Although that's the only offender I can see
18:24:14 <spot> it doesn't say "thou shalt not" anywhere though
18:24:18 <tibbs|h> No subdirs of /bin, but you can have subdirs in /usr/bin as far as I can tell.
18:24:31 <spot> even if it doesn't say "thou can"
18:24:32 <tibbs|h> Which I completely don't understand, but it's the FHS.
18:25:08 <spot> the implication seems to me to be that subdirs there are okay
18:25:18 <spot> given that two seemingly random examples are cited
18:25:27 <spot> /usr/bin/X11 and /usr/bin/mh
18:25:42 <abadger1999> hah, "There must be no subdirectories in /bin."  -- with our UsrMove feature, that becomes somewhat sticky :-)
18:26:00 <spot> abadger1999: let the crazy people behind UsrMove worry about that.
18:26:10 <abadger1999> spot: as in, ignore it? ;-)
18:26:18 <tibbs|h> Kind of wish they allowed only grandfathered directories for cleanliness, but in any case it doesn't appear that we can quote FHS as an objection to this.
18:26:24 * spot shrugs reluctantly
18:26:53 * abadger1999 would much prefer to have the binaries be in /usr/bin and renamed
18:26:56 <spot> RemiFedora: i think you will need to add some explanation of ZTS and provide some feedback on how packagers can determine when they should be using these new macros
18:27:05 <abadger1999> phpize-zts
18:27:37 <spot> abadger1999: yeah, me too, but if this is some sort of php logic as opposed to Remi created logic...
18:27:39 * Rathann is with abadger1999
18:27:42 <Rathann> on this one
18:28:20 <spot> either way, i've committed the minor typo fixes and we'll revisit this next week
18:28:28 <spot> we're at 90 minutes now and i am tired.
18:28:46 <abadger1999> spot: I checked the spec file:       --bindir=%{_bindir}/php-zts \
18:28:57 <abadger1999> So it appears to be something we can change.
18:29:04 * geppetto needs food, badly
18:29:18 <spot> okay. i'm going to open the floor, but i hope to be able to close it quickly
18:29:20 <spot> #topic Open Floor
18:29:27 <tibbs|h> Nothing at all from me.
18:29:59 * RemiFedora would like to raise the php-zip issue if possible
18:30:56 <rdieter> RemiFedora: do tell.
18:31:17 <RemiFedora> the extension have been removed because it used a bundled library
18:31:24 <RemiFedora> well a forked version of libzip
18:31:52 <RemiFedora> and there is now a few broken applications which cannot run because of this missing extension (ocsinventory, moodle)
18:32:23 <RemiFedora> and I think that the answer (read in some bug report) to use "pecl install zip" is not a good solution
18:32:32 <spot> RemiFedora: refresh my memory, i did some patches to use the system library here, right?
18:32:35 <spot> RemiFedora: did they work?
18:32:39 <RemiFedora> no
18:32:41 <rdieter> apparently not
18:32:43 <RemiFedora> the test suite fails
18:32:58 <spot> okay. lemme take another crack at that.
18:33:01 <RemiFedora> because there are some behavioirs change in the forked version
18:33:13 <spot> lets try to exhaust that option before we consider bundling
18:33:27 <spot> i will give that some priority this afternoon
18:34:19 <RemiFedora> thanks
18:35:03 <RemiFedora> for now upstream is really awfully against the use of system libzip
18:35:44 <rdieter> can you give a brief explanation why?
18:35:58 <RemiFedora> I'm not upstream ;)
18:36:17 <abadger1999> They have a bug report -- iirc, I didn't buy whatever argument they were making there.
18:36:30 <RemiFedora> mainly because php upstream change some behavior that libzip don't want to merge, I think
18:36:43 <spot> their bug report was not... current
18:37:00 <spot> i don't believe they ever approached libzip about it
18:37:09 * spot will have to dig out his notes here
18:37:19 <spot> i haven't thought about this in quite some time
18:37:41 <abadger1999> https://bugs.php.net/bug.php?id=39388
18:37:57 <abadger1999> There may be other bug reports as well
18:38:02 <RemiFedora> couldn't we get php-zip back in F16 and wait for another solution in F17 ?
18:38:06 <spot> yeah, thats the one.
18:38:22 <abadger1999> RemiFedora: We could get php-zip without bundling into F16.
18:38:45 <abadger1999> And then you could work on a better solution that passes all test cases for f17.
18:39:08 <tibbs|h> Well, if it's broken, what's the point?
18:39:20 <abadger1999> I guess the question is how broken is it?
18:39:31 <spot> i think i can fix it to pass the test suite
18:39:34 <tibbs|h> I guess if it's only broken in some academic way, so that apps work but the test suite fails...
18:39:37 * rdieter doesn't like just ripping stuff out without a working replacement
18:39:44 <RemiFedora> segfaut iin some situation
18:39:47 <spot> and iirc, libzip upstream was interested in merging the change
18:40:33 <RemiFedora> and changing the behavior of libzip could also affect all package which use system libzip
18:40:36 <rdieter> ok, just needs someone to champion the cause perhaps, get stuff done.
18:40:37 <spot> so let me look at it and try, and if i fail, we'll consider a bundling request with that knowledge
18:41:07 <spot> RemiFedora: again, my memory is rusty here, but iirc, the only necessary change was an API extension, not a behavioral change
18:41:39 <RemiFedora> I think (if I remember correctly)  forked version allow to add empty directory to ziparchive
18:41:57 <spot> RemiFedora: lemme look at it, pls. :)
18:42:22 <spot> any other open floor items?
18:43:48 <spot> okay. i hear none.
18:43:53 <spot> Thanks everyone for your patience.
18:43:56 <spot> #endmeeting