16:00:27 <spot> #startmeeting Fedora Packaging Committee
16:00:27 <zodbot> Meeting started Thu Aug 29 16:00:27 2013 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <spot> #meetingname fpc
16:00:31 <zodbot> The meeting name has been set to 'fpc'
16:00:37 <spot> #topic Roll Call
16:00:48 * limburgher here for 30 minutes
16:00:52 * RemiFedora here
16:01:50 * geppetto is here
16:02:25 <spot> abadger1999, tibbs, Smoother1rOgZ, racor: ping
16:02:33 * abadger1999 is here
16:02:47 * racor is here
16:03:15 <spot> okay, thats quorum
16:03:52 <spot> #topic Consider reverting decision to ban %{?_isa} in BuildRequires - https://fedorahosted.org/fpc/ticket/303
16:04:21 * Smoother1rOgZ here
16:05:13 <spot> this ticket gives me a headache, but it seems to me that until the tooling is fixed to make it safe(r) to use %{_isa} in BuildRequires, there is no real benefit to permitting it.
16:06:27 <RemiFedora> I still think a src.rpm is noarch so shouldn't use %{?_isa}
16:06:31 <spot> The simple fact that it can be wrong depending on where it is built means we shouldn't be using it.
16:07:12 <limburgher> I agree with RemiFedora.
16:07:34 <abadger1999> RemiFedora: I think panu has made it fairly clear that src rpms are not noarch.
16:07:47 <abadger1999> Their metadata differs depending on what platform they were built on.
16:08:01 <spot> I do think that Panu's comment is interesting, but that all he points out falls squarely in the realm of "our tools (including rpm) do not handle architecture specific build issues well"
16:08:41 <RemiFedora> abadger1999, yes it's technically arched, but fonctionally noarch ;)
16:08:43 <spot> we're not the fixers of tools, if anything, we are the work-around-mechanics for those tools.
16:09:23 <abadger1999> I'm in two minds... I really want the metadata to be as correct as possible as the metadata is important for checking a wide variety of things but there is a use case for rebuilding outside of mock.
16:09:52 <geppetto> yeh, if we should take anything from Panu's comments it's that we should add something somewhere to say "You aren't allowed to use %ifarch or anything resembling that for buildrequires"
16:09:54 <racor> As long as we treat srpms like noarchs (shared in repos), Panu's comment to me tells us about a bug in rpm
16:10:00 <spot> To me, it really is this simple: Can BuildRequires: foo%{?_isa} result in failed or improper builds for Fedora packages?
16:11:05 <spot> I believe the answer to that is "yes, sometimes". If so, I think the ban should stand. We can look into prohibiting other behavior if needed.
16:11:14 <abadger1999> banning %{_isa} in BuildRequires doesn't make the metadata 100% correct but it does make it more correct.  OTOH, allowing it makes it easier to rebuild on a multilib system that has the non-primary arch libraries installed which is a corner case.
16:11:35 <geppetto> right
16:11:42 <RemiFedora> agree
16:11:46 <spot> abadger1999: i'm less interested in correctness here than failed builds in the normal case.
16:11:50 <abadger1999> i thought the answer to that was no.
16:12:12 <abadger1999> can you point me to the comment that says there are failed builds because of it?
16:12:17 <abadger1999> that would definitely sway me.
16:12:20 <spot> abadger1999: no
16:12:27 * spot has no evidence one way or the other
16:12:40 <spot> and if the answer is no, i'd probably not support a ban.
16:13:20 <RemiFedora> xulrunner is an example of a package with BuildRequires:  xulrunner-devel%{?_isa}
16:13:26 <RemiFedora> sorry firefox
16:13:51 <spot> i think that koji either generates srpm from the git tree (or in the case of a scratch build, installs the srpm and regens it locall)
16:14:06 <racor> abadger1999: Which BRs would an srpm receive, which has been built on arm, but wants to pull-in i386 for building on x86_64 (similar to the GCC case)
16:14:11 <spot> so %{_isa} is evaluated on the koji builder node that gets assigned the task
16:14:32 <spot> which, I think, will always be correct for the env on that builder
16:15:07 <spot> the issue would be if the SRPM got generated on an arm builder, then a user went to use it on a different arch system without doing the same rpm -ivh && rpmbuild regen cycle
16:15:42 <spot> and that seems... like a corner case.
16:16:07 <spot> like i said, this ticket gives me a headache. :)
16:16:16 <abadger1999> racor: yeah -- they'd get the arm BR because %_isa would evaluate  to what arm needs.  If you want to pull in x86 stuff, that would likely be an explicit BuildRequire which would be different
16:16:35 <abadger1999> well there's two issues.
16:17:53 <abadger1999> 1) if a user went to use it on a multilib system and there were no %_isa in the BR's then the wrong packages might satisfy the BR's (x86 packages on a x86_64 system).
16:18:14 <racor> abadger1999: I expected as much ;)
16:19:20 <racor> provided koji, these days often builds srpms on arm ... it's only a matter of time until this issue hits
16:19:25 <abadger1999> 2) if a user went to use it on a different arch and %_isa was present, rpm-build would work because rpm-build would re-parse the spec file.  But if you had it in a yum repo and just relied on that metadata, the metadata would be specific to the arch it was built on and might lead to non-availability of the packages.
16:20:24 <spot> abadger1999: how often are people using SRPM metadata?
16:20:41 <abadger1999> ie: built on arm, BuildRequires foo%{?isa} => BR: foo.arm; If I'm on x86 and querying the repodata to find out what packages are needed to rebuild the package, it'll see foo.arm and won't be able to resolve that to a package.
16:20:49 <spot> in a way that leads to failure?
16:21:20 <abadger1999> yum-builddep (which panu points out could instead download the srpm and then figure out the dependencies) and whenever we make mass changes --
16:21:52 <RemiFedora> and mock (or koji) use yum-builddep
16:21:56 <geppetto> abadger1999: Are you sure that mock based building will reparse the specfile?
16:21:58 <abadger1999> ie: I want to update python2 to python2.8.  I need to know what BuildRequires: python to know what might break/needs to be rebuilt/etc.
16:22:35 <spot> geppetto: dunno about mock, but koji unpacks srpms from scratch builds and regenerates them
16:22:46 <abadger1999> geppetto: I think that's what panu claimed -- I'd have to review the mailing list thread to be sure I have the attribution right, though.
16:23:07 <geppetto> abadger1999: What spot said sounds more likely … mock doesn't, but koji does.
16:24:03 <geppetto> I guess if koji does it, I'm tempted to allow it and then tell all the other tools that don't work atm. to fix themselves.
16:24:50 <spot> geppetto: i think yum-builddep is the most obvious tool that needs to be fixed. i suppose we could consider arch-conditionalizing the SRPM metadata.
16:25:10 <spot> that sounds like a lot of awful work for little gain though.
16:25:29 <geppetto> Yeh, yum-builddep always using the specfile would probably fix at least 90% of stuff.
16:25:33 <dwa> fwiw, people working on secondary arches have run into this with yum-builddep
16:25:41 <dwa> so it's not just a theoretical problem
16:25:47 <spot> dwa: *nod*
16:26:11 <geppetto> It feels kind of weird to have the .src.rpm format basically be a misleading tarfile though.
16:26:32 <spot> geppetto: for it not to be, it would need to not evaluate macros at all.
16:26:41 <geppetto> Yeh
16:26:49 <spot> which may actually be the best longer term approach
16:27:09 <spot> as panu points out the other cases where macro evaluations in SRPMs result in build issues
16:27:26 <geppetto> The other minor problem is that fixing yum-builddep requires the rpm team get the "give me file XYZ from this .src.rpm" API released and usable … which has been talked about for months if not years.
16:27:47 <geppetto> But, meh.
16:27:57 <limburgher> Going AFK for about 30 minutes, I'll check back. I can vote in tickets if needed.
16:28:03 <spot> geppetto: or simply to add a "download, unpack into /tmp, act on that tree" loop.
16:28:18 <spot> but i realize why that is hackish and bad.
16:28:24 <geppetto> :)
16:28:34 <geppetto> Blah … ok, I'm +1.
16:29:01 <kalev> one thing I'd like to point out wrt %_isa is that things are likely to change when dnf comes along
16:29:05 <kalev> it has a different depsolver that might not need the %_isa hacks any more to properly depsolve stuff
16:29:29 <spot> i think I'm +1 on lifting the ban too. I understand the problem, but the workaround for users is trivial (rpm -ivh foo.src.rpm && rpmbuild -ba rpmbuild/SPECS/foo.spec)
16:29:55 <spot> kalev: i'll worry about $THE_FUTURE when it arrives. ;)
16:30:04 <kalev> :)
16:30:30 <spot> especially if it means we get to make things simpler rather than more complicated.
16:31:11 <dgilmore> spot: want me to go over how koji deals with srpms for builds?
16:31:41 <abadger1999> Sorry - my net connection dropped for a bit.
16:31:47 <spot> dgilmore: the only time fedora hands koji a SRPM (that I know of) is at a scratch build
16:31:52 <abadger1999> Last thing I read was: [09:24:03] <geppetto> I guess if koji does it, I'm tempted to allow it and then tell all the other tools that don't work atm. to fix themselves.
16:31:57 <Smoother1rOgZ> abadger1999: what you missed: < spot> i think I'm +1 on lifting the ban too. I understand the problem, but the workaround for users is trivial (rpm -ivh foo.src.rpm && rpmbuild -ba  rpmbuild/SPECS/foo.spec)
16:31:59 <spot> otherwise, builds are coming from fedpkg, right?
16:32:15 <dgilmore> spot: right, but koji rebuilds the srpm before install BuildRequires
16:32:25 <spot> dgilmore: yep,that part i understood.
16:32:40 <abadger1999> Smoother1rOgZ: Did my messages after geppetto spoke come through?  About why some things are not fixable?
16:32:41 <RemiFedora> but the srpm is only buld once for all arch ?
16:32:45 <dgilmore> because you can and people do have arch specific BuildRequires which are embeded at srpm creation time
16:32:50 <dgilmore> RemiFedora: no
16:32:57 <spot> i think there might still be a possible failure case if we don't build the SRPM for every arch, but i think we do that
16:33:10 <dgilmore> its built once for the overall task from git then rebuilt for every arch task
16:33:15 <Smoother1rOgZ> abadger1999: nope
16:33:17 <geppetto> abadger1999: no
16:33:28 <RemiFedora> dgilmore, thanks, seems clear
16:33:38 <abadger1999> well... we can fix some things but we can't fix all things -- unless we go to the root of the matter and change the repo creation to use per-arch srpms to generate the repodata.
16:33:45 <abadger1999> well... we can fix some things but we can't fix all things -- unless we go to the root of the matter and change the repo creation to use per-arch srpms to generate the repodata.
16:33:55 <abadger1999> for instance, repoquery will never be able to be fixed as by design it's parsing the repodata.
16:33:56 <dgilmore> RemiFedora: the only way for users to be sure they have deps right is to rebuild the srpm for the target arch
16:34:02 <abadger1999> the alternative would be that repoquery would have to download all fedora srpms and parse the spec files from all of them in order to know what's actually being provided and required on the user's arch.
16:34:38 <spot> abadger1999: we could theoretically generate source metadata from git, rather than from rpms
16:35:37 <spot> the issue is that the metadata just knows that the SRPM says: "BuildRequires: foo.armv7hl" or whatever arch gets evaluated from %{_isa}.
16:35:46 <spot> the spec has no such issues
16:35:46 <dgilmore> the issue is that users dont understand why they cant just rebuild a srpm we ship and have it work
16:35:58 <geppetto> abadger1999: but that's the repodata of the source repos. … I doubt many people are using that, and those that are mostly just to find the location of the .src.rpm files to download (Which will work).
16:36:01 <spot> dgilmore: that is an issue.
16:36:01 <dgilmore> you can hit issues with i686 and x86_64
16:36:08 <abadger1999> spot: yeah -- theoreticalyl.. Probably would need some caching otherwise we'd have to parse the spec files from the git trees everytime we create an arpm yum repo.
16:36:31 <spot> abadger1999: yeah, if we did that, we'd want to be clever about it
16:36:36 <abadger1999> geppetto: The use case is when Fedora makes changes and needs to know what BuildRequires are.
16:37:03 <geppetto> Yeh, anyone that is trying to mass query build requires is going to have a bad time.
16:37:13 <abadger1999> geppetto: We're going to remove python2 from the distro.  Need to generate the list of packages that have build-time deps on that that will break.
16:37:16 <spot> abadger1999: we could arguably make that repo once per day, or if someone could figure out how to do per-package diffs to that metadata, we could apply those in flight
16:37:17 <abadger1999> things like that.
16:37:42 * spot is hand-waving wildly, but the idea remains
16:37:46 <abadger1999> <nod>
16:38:14 <abadger1999> dgilmore: are there cases where they actually can't rebuild an srpm we ship?
16:38:40 <spot> Given all of this, I think using %{_isa} in BuildRequires solves a problem for the secondary arches and does not create an unresolvable issue for users (just use the SRPM).
16:38:42 <abadger1999> dgilmore: from reading the comments it sounds like that occurs if you leave out %{_isa} but should work if you do enter %{_isa}.
16:38:53 <dgilmore> abadger1999: if they dont rebuild the srpm for the buils target first yes
16:39:41 <spot> perhaps rpm could be extended to detect the evaluation of %{_isa} during the creation of a SRPM
16:39:58 <dgilmore> abadger1999: if you dont use %{_isa} in the BuildRequires the chances of building the srpm a higher.
16:40:04 <spot> and taint the SRPM in a way that a user running rpmbuild blindly would be warned
16:40:13 <dgilmore> abadger1999: but there can be cases where it will fail
16:40:30 <dgilmore> really the user should be rebuilding the srpm for their target
16:40:42 * spot would prefer it if someone smarter than me is trying to solve the tooling problems though.
16:40:49 <dgilmore> spot: %{_isa} doesn't help or hurt secondaris
16:41:01 <dgilmore> since all koji build repos are single arch
16:41:04 <spot> since, as panu makes clear, they go beyond %{_isa}.
16:41:30 <abadger1999> dgilmore: when you say chances are higher, are we talking at the rpmbuild level or at the yum-builddep level?
16:42:32 * abadger1999 knows yum-builddep is more broken with %{_isa} but thought that panu was saying that rpm-build reparsed the spec and thus it was able to handle it.
16:42:55 <dgilmore> abadger1999: well if we take the srpm from the i686 build and you try to rebuild it on x86_64 without %{_isa} so long as there is no "%ifarch x86_64 BR foo" it should build on x86_64
16:43:30 <abadger1999> <nod>
16:43:35 <dgilmore> abadger1999: as soon as you add in %{_isa} to BR's you cant rebuild the srpm on x86_64 without rebuilding the srpm first
16:43:45 <spot> abadger1999: i'd have to look at the rpm code to see if rpmbuild is unpacking the srpm first or operating on the srpm itself.
16:43:56 <abadger1999> dgilmore: huh.. that conflicts with what I thought panu was saying.
16:44:01 * spot really would prefer not to do that.
16:44:06 <dgilmore> spot: it operated on the headers in the srpm
16:44:11 <dgilmore> not on the spec
16:44:39 <spot> dgilmore: okay, assuming that is true, we can open a bug on rpmbuild to not do that.
16:44:50 <abadger1999> well, if that's the case, then I'm -1 on lifting the ban.
16:45:19 <dgilmore> spot: its why we rebuild the srpms in koji before installing BuildRequires
16:45:27 <abadger1999> as it's broken either way and it seems broken for a more standard path if %{_isa} is used.
16:45:37 <dgilmore> its possible that rpm has changed behaviour recently
16:45:52 * abadger1999 may end up having to test this to find out what curent rpm does today.
16:46:00 <spot> anyone opposed to tabling this issue while we ask panu about rpmbuild specifically?
16:46:11 <abadger1999> +1 table
16:46:25 <Smoother1rOgZ> no
16:46:31 * dgilmore has no vote but seems more data is needed
16:47:01 <RemiFedora> +1 for tabling
16:47:53 <geppetto> I'm not opposed, but I'm pretty sure rpmbuild currently doesn't use the spec, just the .src.rpm … like yum-builddep
16:48:55 <dgilmore> geppetto: that is my understanding
16:49:20 * abadger1999 looks around for an x86 to test an arpm on
16:49:56 <spot> #action tabled, pending data around rpmbuild
16:50:22 <spot> #topic No_bin_deps redux - https://fedorahosted.org/fpc/ticket/314
16:51:24 <spot> Unless we plan to drop the symlinks to /bin and /sbin, this issue seems irrelevant to me.
16:51:40 <spot> Given that the FHS requires that we have /bin and /sbin... where is the issue?
16:51:44 <abadger1999> The problem is the rpm metadata.
16:51:57 <abadger1999> If you have %files /bin/sh
16:51:59 <spot> oh, i see.
16:52:02 <abadger1999> Then the rpm Provides /bin/sh
16:52:07 <abadger1999> If you have %files
16:52:12 <abadger1999> /usr/bin/sh
16:52:13 * limburgher is back, reading.
16:52:18 <abadger1999> Then the rpm Provides: /usr/bin/sh
16:53:03 <abadger1999> That then runs into historical Requires, autoRequires, etc.
16:53:14 * spot sighs
16:53:18 <spot> i hate usrmove. :(
16:53:27 <abadger1999> yep.  I do too.
16:53:40 <RemiFedora> as long as we have some provides /bin/foo, we need to requires /bin/foo.
16:53:57 <geppetto> why are we talking about this again?
16:53:58 <spot> RemiFedora: or we need to fix the "provides /bin/foo"
16:54:09 <RemiFedora> exactly
16:54:22 <geppetto> Didn't we discuss this weeks and ago and decide the same thing … usrmove was idiotic, can't just break more stuff now.
16:54:55 <abadger1999> i don't know -- there's no vote recorded in the ticket... fesco did discuss it and said, there's an fpc ticket open -- they should decide.
16:55:11 <geppetto> ok, then … -1
16:55:18 <abadger1999> so there's two proposals inthe ticket.
16:56:26 <abadger1999> akozumpl's https://fedoraproject.org/wiki/User:Akozumpl/No_bin_deps which says, fix Requires: to not use /bin.
16:56:39 <abadger1999> (explicit requires... autorequires are not taken care of)
16:56:47 <abadger1999> and mine which says he opposite:
16:56:59 <geppetto> https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove … doesn't seem that bad.
16:57:04 <abadger1999> relax the current guidelines so that maintainers can install into /bin.
16:57:06 <geppetto> If that's the second proposal.
16:57:09 <abadger1999> yeah.
16:57:29 <geppetto> I'm certainly +1 on letting people install into /bin
16:57:30 <abadger1999> That and removing the current wording that says that maintainers must use /usr/bin instead of /bin in %files
16:57:55 <spot> it looks like the only offenders on my F19 box are: bash, coreutils, cpio, findutils, gawk, gettext, gzip, iputils, procps-ng, systemd, tar, util-linuz, and vim-minimal
16:58:02 <abadger1999> +1 to mine as well.
16:58:17 <abadger1999> glibc should be in there as well (for the dynamic linker)
16:58:26 <geppetto> spot: Bash isn't an offender, to be fair … it has an explicit provides.
16:58:38 <spot> abadger1999: i just did a loop on what provides things in /bin (as opposed to /usr/bin)
16:59:50 <spot> adding /sbin | /usr/sbin pulls in iputils, policycoreutils, iproute, initscripts, procps-ng
16:59:55 <abadger1999> <nod>  the current guidelines (that I want to kill) catch /lib and /lib64 as well.
17:00:09 <abadger1999> (which is where the dynamic linker lives)
17:00:46 <spot> okay.
17:00:53 * spot is +1 to https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove
17:01:06 <geppetto> But letting people install into /bin is more about letting well known names be in the correct place, than saving any current offenders … the fact that coreutils has 666 provides just so it can provide the well known names of /bin/rm and obey the "must install into /usr/bin" makes me want to hurt people.
17:01:35 <abadger1999> <nod>
17:01:43 <abadger1999> +1 to  https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove
17:01:56 <spot> Proposal on the table for votes is: https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove
17:02:18 <spot> Vote is at +1:2, 0:0, -1:0
17:02:27 <RemiFedora> +1
17:02:33 <abadger1999> +1
17:02:42 <Smoother1rOgZ> +1 for the record
17:02:50 <geppetto> +1
17:03:06 <spot> Vote is at +1:5, 0:0, -1:0
17:03:33 <spot> racor, limburgher, if still here, you're our missing voters.
17:03:57 <limburgher> +1
17:04:19 * RemiFedora counts 6 spot abadger1999 RemiFedora abadger1999 Smoother1rOgZ geppetto
17:04:30 <RemiFedora> well 7 with limburgher
17:04:38 <spot> #action https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove approved as replacement for ban on /bin /sbin /lib* files. (+1:6, 0:0, -1:0)
17:04:44 <spot> RemiFedora: you counted abadger1999 twice. ;)
17:04:53 <RemiFedora> oooops sorry
17:04:59 <spot> and while he is certainly worthy of being counted twice in some things, not in this. ;)
17:05:01 <racor> Sorry, was disrupted and will have to quit, RSN
17:05:14 * abadger1999 got counted twice in yesterday's fesco meeting too -- but there it was one +1 and one -1
17:05:16 <racor> +1 for UsrMove
17:05:33 <racor> bye
17:05:36 <abadger1999> racor: bye
17:06:31 <spot> we're over an hour, but we have lots of tickets to go
17:06:57 * abadger1999 can stay
17:07:12 <geppetto> we've been bumping a couple each week, but I can stay for at least another 30 mins.
17:07:14 * Smoother1rOgZ too
17:07:24 <RemiFedora> :me can stay for 1/2h too
17:07:25 <spot> okay, lets just keep going for a bit
17:07:41 <spot> #topic Bundling exception for IQmol - https://fedorahosted.org/fpc/ticket/332
17:08:12 <abadger1999> So this is squarely in our grey area.
17:08:23 <abadger1999> I took a look at both projects and they do not build *.so files.
17:08:30 <abadger1999> But they both have upstream release tarballs.
17:08:50 <abadger1999> One of them recently put out a beta release (last stable release in 2010)
17:09:20 <spot> abadger1999: should we assume the lack of a shared library implies an implicit upstream request to bundle that code?
17:09:31 <Smoother1rOgZ> hm...
17:09:33 <abadger1999> nothing on the web sites explicitly says "please copy into your programs and modify to change behaviour"
17:09:40 <abadger1999> so.... it's our grey area.
17:10:15 <spot> okay, so if we think about it like this:
17:10:24 <abadger1999> spot: I think that's up to us?  We could do as raor suggested and submit patches upstream to build as a shared library -- we've done that i nthe past.
17:10:35 <abadger1999> *racor
17:10:41 <Smoother1rOgZ> is +1 to build them
17:10:52 <abadger1999> or we could say, we now consider things like this to be copylibs.
17:10:55 <Smoother1rOgZ> we can write the .pro file to do that
17:10:58 <spot> no other program is expecting to find this software as shared libraries. even if we make them in Fedora, we'd have to patch everything that uses it.
17:11:17 <abadger1999> and do the same when other people submit similar code.
17:11:19 <spot> and we can generally assume the upstreams may not take those patches because it is fedora specific behavior
17:11:41 <abadger1999> spot: well -- building a shared library might be taken by the upstream for the bundled code.
17:12:08 <Smoother1rOgZ> spot: no if we patch to have only .pro files
17:12:23 <spot> i would almost prefer that we ask the upstreams to make shared libraries in these cases, and if they decline (or do not respond within, say, a month), we permit them to be copylibs.
17:12:28 <abadger1999> afaics, no one's tried to contact those upstreams about that.
17:13:15 <abadger1999> is it esy to write qmake .pro files that build shared libraries?
17:13:26 <Smoother1rOgZ> abadger1999: it is
17:14:25 <spot> even more reason to ask upstream to make that change, and if they do, deny the bundling request.
17:14:36 <abadger1999> k.  So we could submit patches upstream which would make things ultra clear about whether they care or not.
17:14:37 <abadger1999> Yeah.
17:15:11 <spot> if upstream_has_separate_tarball && upstream_generates_shared_library; then copylib=false
17:15:46 <RemiFedora> yes
17:15:58 <spot> elif !upstream_generates_shared_library; then try_to_fix_upstream()
17:17:11 <spot> okay, returning to english... i think i'd be okay with asking this ticket to poke the two upstreams here and see if they will add the support for shared lib generation or not
17:17:21 <spot> then revisiting it based on their answers
17:17:29 <abadger1999> spot: if upstream generates any library... static is still better than bundled
17:17:31 <spot> bonus points if Smoother1rOgZ makes patches for them.
17:17:44 <Smoother1rOgZ> sure thing
17:17:54 <abadger1999> spot: sounds like a plan to me.
17:17:59 <spot> +1 to that proposal
17:18:02 <abadger1999> +1
17:18:07 <Smoother1rOgZ> +1
17:18:07 <RemiFedora> +1
17:18:18 <geppetto> +1
17:19:01 <limburgher> +1
17:20:24 <spot> #action Request for library generation from upstream before considering copylib exception approved (+1:6, 0:0, -1:0)
17:20:50 <spot> Smoother1rOgZ: thanks in advance for making patches
17:21:10 <Smoother1rOgZ> np
17:21:15 <spot> #topic Create a macro for selecting the proper ruby-(abi|release) version - https://fedorahosted.org/fpc/ticket/334
17:21:27 <spot> oh, how i love ruby. let me count the ways. *cough*
17:22:20 <spot> this ticket seems to be the ruby community arguing with each other. :/
17:23:00 <abadger1999> yeah
17:23:17 <abadger1999> skottler does not appear to be around this morning.
17:24:03 <spot> it might be possible to make an expansion macro that gets passed an "abi" version.
17:24:24 <spot> "%rubi_abi_requires 18"
17:24:39 <spot> that expands to the conditional hell in comment 1
17:24:55 <spot> 1.8, rather.
17:25:12 * abadger1999 notes that the conditional is overcomplex... there only needs to be an %if %else... not an %if %if %else
17:25:23 <spot> abadger1999: no, it does, because of epel
17:25:40 <abadger1999> of course, the original macro could be wrong in a different way.
17:25:42 <samkottler> abadger1999: I'm here :)
17:25:53 <abadger1999> ah -- sorry, I looked for skottler :-/
17:26:26 <abadger1999> spot: in the original comment's macro, the epel and the fedora < 17 case are the same.
17:26:30 <samkottler> abadger1999: the original macro in that ticket was off the top of my head so it might be wrong, but it shows how complex the conditional logic is
17:26:36 <geppetto> I"m still confused about how this will help … is the idea to create this macro now and then people can start using it in like 5-10 years?
17:26:36 <samkottler> and that's in every spec
17:26:42 <spot> abadger1999: good point
17:26:54 <spot> so it is just
17:26:57 <geppetto> Or is the plan to backport the macro. somehow?
17:27:03 <spot> %if 0%{?fedora} && 0%{?fedora} < 17
17:27:07 <limburgher> Going AFK. . .again. . .apologies. . .
17:27:08 <spot> Requires: %{?scl_prefix}ruby(abi) = 1.8
17:27:08 <spot> %else
17:27:15 <spot> Requires: %{?scl_prefix}ruby(release)
17:27:17 <spot> %endif
17:27:21 <abadger1999> limburgher: no problem, we're over time as it is.
17:27:41 <samkottler> spot: yes, and it gets a lot more complicated than that when SCL is used, but that's a whole other topic
17:28:00 <spot> samkottler: lets leave SCL aside for when I'm a lot drunker.
17:28:10 <samkottler> spot: lol +1
17:28:46 <spot> i'm not necessarily opposed to having a %ruby_abi_requires macro that evaluates out to the above
17:28:56 <spot> but a single conditional isn't that darned bad, imho.
17:29:04 <spot> i'm inclined to say "suck it up, buttercup".
17:29:16 <abadger1999> yeah .. what's vondruch's objection exactly?  I don't see any downside to a macro that sums this all up?
17:29:30 <samkottler> abadger1999: he's just saying what spot's saying
17:29:41 <geppetto> Again, I'm not opposed to the macro. addition … but it seems like most packages won't be able to use it.
17:29:53 <samkottler> basically it's a PITA to have this conditional everythough, though. it's always the same
17:30:04 <samkottler> everywhere**
17:30:55 <abadger1999> Would we be able to add the macro into osmething that epel ruby packages would BR anyway?
17:31:50 <spot> samkottler: the irony is that if we did macroize it, you'd have to conditionalize the macro existing.
17:31:58 <spot> because Ruby in RHEL isn't likely to add it
17:32:05 * samkottler throws something on the ground
17:32:48 <samkottler> at that point it gets so complex that it's probably not worth it TBH
17:33:04 <RemiFedora> spot, probably not easy but worth trying to request for it in RHEL.
17:33:08 <spot> samkottler: i think if you want to go down this road, your first hurdle is to add it to RHEL.
17:34:11 <spot> I _think_ this is the macro you'd want
17:34:14 <spot> %ruby_abi_requires() \
17:34:14 <spot> %if 0%{?fedora} && 0%{?fedora} < 17 \
17:34:15 <spot> Requires: %{?scl_prefix}ruby(abi) = %{?*} \
17:34:15 <spot> %else \
17:34:15 <spot> Requires: %{?scl_prefix}ruby(release) \
17:34:16 <spot> %endif \
17:34:18 <spot> %{nil}
17:34:26 <spot> then, you could use:
17:34:34 <spot> %ruby_abi_requires 18
17:34:38 <spot> err... 1.8.
17:34:42 <samkottler> spot: I think it's a reasonable thing to get into RHEL
17:35:02 * spot proposes we table this ticket until RHEL adds it
17:35:20 <RemiFedora> sport why not asimple %global ruby_abi_requires ruby(release)
17:35:26 <samkottler> I will start the RHEL conversation and then give a status update on the ticket
17:35:47 <spot> RemiFedora: for RHEL? or for Fedora?
17:35:52 <RemiFedora> for fedora
17:36:01 <spot> RemiFedora: still doesn't solve the EPEL problem.
17:36:20 <RemiFedora> yes
17:36:32 <spot> although, with f17 EOL now, i think we could just do that.
17:36:47 <RemiFedora> so need a bug against rhel-6 and lot of patience
17:37:08 <samkottler> I'll file the bug
17:37:11 <spot> although, tbh
17:37:16 <RemiFedora> FYI I can have some macro added in php and waiting for other in php-pear
17:37:20 <spot> if RHEL had ruby(release)...
17:37:27 <spot> then we need no macro. ;)
17:37:45 <spot> but i digress.
17:37:52 * abadger1999 notes that the macro should include the release in it... otherwise you still have to conditionalize which version you want.
17:37:58 <spot> #action tabling on RHEL adding support for the macro.
17:38:04 <abadger1999> but yeah +1 to table
17:40:59 <geppetto> +1
17:41:34 <RemiFedora> seems simpler to ask RHEL to provide ruby(release)....
17:41:48 <spot> and with that, i think we're done for this week.
17:41:57 <spot> thanks everyone for the extra long meeting.
17:41:58 <RemiFedora> as this is versionned
17:42:24 <spot> RemiFedora: indeed.
17:42:43 <abadger1999> Thanks spot.
17:42:47 <spot> #endmeeting