17:02:09 <abadger1999> #startmeeting fpc
17:02:09 <zodbot> Meeting started Thu Dec 19 17:02:09 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:13 <abadger1999> #meetingname fpc
17:02:13 <zodbot> The meeting name has been set to 'fpc'
17:02:21 <abadger1999> tibbs, geppetto, RemiFedora, limburgher, SmootherFrOgZ: who's here?
17:02:31 * RemiFedora !
17:03:28 * limburgher here-ish.
17:03:40 <abadger1999> k
17:03:58 * geppetto is here
17:04:08 <abadger1999> racor: You here for meeting?
17:04:24 <abadger1999> With racor, that would be just enough for quorum.
17:04:34 <abadger1999> #topic Next Meeting
17:04:36 <racor> yep, /me is here, but I seem to be having connection probs
17:05:15 <abadger1999> So ... holidays coming up.
17:05:22 <limburgher> So i've heard.
17:05:33 <abadger1999> I think I'll be travelling until the 6th of January.
17:05:46 <abadger1999> Does anyone want to have meetings between now and then?
17:05:59 <limburgher> I'll be travelling some too, and in a food coma for part  of the time.  No meetings for me.
17:06:17 <geppetto> No, I'm fine with next meeting being the 9th of Jan.
17:06:23 <abadger1999> Cool.
17:06:24 <RemiFedora> holidays, so probably no meeting for me
17:06:38 <abadger1999> #info Next meeting will be January 9, 2014
17:08:06 <abadger1999> geppetto: Was there an agenda this week?
17:08:17 <geppetto> yeh
17:09:00 <Rombobeorn> I'm here in case you guys are going to discuss GNAT_add_rpath today.
17:09:53 <geppetto> crap … I wrote it but didn't send it
17:10:43 * limburgher slaps geppetto's wrist, assigns six demerits
17:11:04 <abadger1999> Phew.
17:11:13 * geppetto hangs head in shame
17:11:14 <abadger1999> At least I'm not blind :-)
17:11:34 <limburgher> abadger1999:  The day is young. . .
17:11:35 <abadger1999> So, since Rombobeorn is here, let's talk about the ada rpath first
17:12:00 <abadger1999> #topic #374 	Ada guidelines changes for Comfignat and runpaths
17:12:11 <abadger1999> https://fedorahosted.org/fpc/ticket/374
17:13:35 <abadger1999> Rombobeorn: So what's the flow of this look like?
17:13:45 <abadger1999> %prep, %build, %install as normal.
17:13:48 * SmootherFrOgZ is kind of stuck in a meeting at dayjob (sorry). :(
17:14:10 <abadger1999> #chair geppetto racor SmootherFrOgZ RemiFedora limburgher
17:14:10 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor
17:14:25 <abadger1999> Then %check is run.
17:14:37 <Rombobeorn> abadger1999, That's what RPMbuild does, yes. (Not sure I understand the question.)
17:14:37 <Rathann> oh, there's a meeting after all
17:14:40 <abadger1999> in %check, the -R flag is turned off
17:14:44 <abadger1999> #chair Rathann
17:14:44 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor
17:14:56 <abadger1999> and the test programs are compiled.
17:15:09 <abadger1999> the libraries have already been installed.
17:15:14 <abadger1999> so they are not recompiled.
17:15:26 <limburgher> Rombobeorn:  Thanks for answering my question in the trac.  In response, would LD_LIBRARY_PATH work in the test cases?
17:15:40 <abadger1999> the -R embeds %{buildroot}/path/to/libraries in the test program's rpath.
17:15:46 <abadger1999> the test programs get run.
17:16:15 <Rombobeorn> You can define and undefine GNAT_add_rpath anywhere in the spec file. You're not supposed to have it defined when the actual library or program that will be installed is built.
17:16:20 <abadger1999> %files processes, copying files from the buildroot into the rpms.
17:16:38 <abadger1999> Rombobeorn: is that the flow that you're proposing?
17:17:03 <limburgher> Norm!
17:17:23 <tibbs|w> Ugh.
17:17:58 <Rombobeorn> abadger1999, For use with testsuites, yes, that's the flow.
17:17:59 <abadger1999> #chair tibbs|w
17:17:59 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher racor tibbs|w
17:18:11 <tibbs|w> Sorry, had a flat tire this morning.
17:18:23 <tibbs|w> But is this FPC or the cloud SIG?
17:18:26 <geppetto> no problem … note that we agreed to skip the next two weeks.
17:18:33 <limburgher> Ooh. :(
17:18:33 <geppetto> tibbs: FPC :)
17:18:37 <abadger1999> Rombobeorn: okay -- I've got two questions, "or auxiliary programs that aren't installed but run during the build "  <== that doesn't seem to work with the flow
17:18:49 <tibbs|w> /topic seems wrong, then.
17:19:21 <Rombobeorn> limburgher, LD_LIBRARY_PATH can also be used, but there is a risk that the packager will make a mistake that can cause false positives or negatives. Automation avoids mistakes.
17:19:46 <abadger1999> I think zodbot is in an inconsistent state :-(
17:20:07 <abadger1999> It thinks  the cloud meeting is still going (despite an #endmeeting there) and that we're also in progress.
17:20:18 <limburgher> Rombobeorn:  True, but wouldn't this eliminate having to ensure rpathed bits aren't installed?
17:20:22 <Rombobeorn> The Templates Parser package has an example of auxiliary programs that aren't installed but run during the build.
17:20:55 <racor> Rombobeorn: Using LD_LIBRARY_PATH in testsuites or uninstalled binaries inside of rpms is the norm for ages.
17:21:13 <abadger1999> Rombobeorn: sure... but if were only allowing this macro to be used in %check, then that usage would be disallowed.
17:21:46 <Rombobeorn> Templates Parser has example programs in its manual. It actually runs the examples when generating the manual, and they link to the library, but the binaries are not installed.
17:22:05 <abadger1999> If we do allow this macro to be used in other places in the spec, then we lose the reasonable assumption that rpath isn't getting into installed files.
17:23:21 <RemiFedora> right, using it in %build havve high mistake risk
17:23:47 <Rombobeorn> The best way to ensure that runpaths don't get into packages is to use check-rpaths. It will also catch cases where the runpath is there because the optflags weren't applied.
17:24:21 <abadger1999> Rombobeorn: Sure -- but we have to work with what we have... and we don't have check-rpaths that fails builds.
17:24:40 <abadger1999> Probably won't until autoqa is given permission to block updates.
17:24:54 <Rombobeorn> racor, is it norm to hardcode LD_LIBRARY_PATH in spec files, or are upstream makefiles expected to do it?
17:25:16 <abadger1999> Rombobeorn: It's normal to hardcode LD_LIBRARY_PATH in spec files.
17:25:42 <abadger1999> LD_LIBRARY_PATH, PYTHONPATH, and other similar environment variables.
17:26:01 <geppetto> Rombobeorn: So one thing we could do is have any program using GNAT_add_rpath explicitly call check-rpath, and fail the build if that fails.
17:26:17 <geppetto> I think I'd be happy with wording that said to do that.
17:26:19 <Rombobeorn> We could write a strong recommendation that Ada packagers should have check-rpaths enabled on their workstations.
17:27:20 <limburgher> We could also write a strong recommendation that people use strncat instead of strcat.
17:27:22 <Rombobeorn> geppetto, Yeah, if we can call check-rpaths from spec files, that would be fine with me.
17:27:43 <geppetto> Rombobeorn: AFAIK you can if you build-dep on rpm-build.
17:27:59 <geppetto> limburgher: Go no, burn them both in a fire.
17:28:14 <Rombobeorn> Can you NOT build-dep on RPMbuild?
17:28:16 <limburgher> geppetto:  Reasonable.
17:28:16 <abadger1999> <nod>  If check-rpaths is used like that it would work for me.  Where would check-rpaths have to be run from?  %check to be run as late as possible?
17:28:44 <geppetto> abadger1999: I assume it'd have to be the last thing in %install?
17:29:04 <abadger1999> I'm not sure... %check is run after %install, right?
17:29:11 <racor> Rombobeorn: The case I was referring is sth. similar to this in %check: "LD_LIBRARY_PATH=$RPM_BUILD_ROOT make test"
17:29:27 <abadger1999> so I don't know if last thing in %check might be the right place.
17:30:04 <racor> Overriding LD_LIBRARY_PATH to let ld.so pickup to not yet installed shared libs
17:30:09 <geppetto> abadger1999: Well %check doesn't have to be run … so I'm not sure if that's better
17:30:22 <abadger1999> Hmm... yeah.
17:30:29 <geppetto> abadger1999: I'm also not sure if %check runs before or after %install :)
17:30:33 <abadger1999> although it would always be run on the buildsystem.
17:30:42 * abadger1999 will have to test.
17:30:49 <Rombobeorn> That's reasonably sane, racor. It gets messier when you have to set LD_LIBRARY_PATH to some directory deep within the source tree, as in the Templates Parser case.
17:31:12 <racor> geppetto: IIRC, %check is after %install
17:31:23 <RemiFedora> yes
17:31:28 <Rathann> it is after %install
17:31:51 <Rombobeorn> In my experiments, %check has happened after %install.
17:31:52 <geppetto> ok, TIL :-o
17:32:36 <geppetto> I guess I'm fine with it being in %check then, it should always work for Fedora at least
17:35:34 <abadger1999> geppetto: Do macros that use %global get defined when they are encountered or as the first step in parsing the spec file?
17:36:08 <geppetto> AFAIK when they are encountered
17:36:18 <abadger1999> Cool.
17:36:28 <geppetto> But I'm not on rpm expert :)
17:36:44 <abadger1999> heh heh.
17:37:46 <Rombobeorn> I'll test calling /usr/lib/rpm/check-rpaths from the spec and then write that into the proposal.
17:38:34 <abadger1999> Okay... so I think we could agree to the GNAT_add_rpath section if the instructions also have people run /usr/lib/rpm/check-rpaths as the last thing in %check (and have appropriate buildrequires if needed).  and someone tests that setting %global GNAT_add_rpath in %check does not affect the earlier stages of the build.
17:38:58 <abadger1999> Rombobeorn: Cool.  Are you okay to do that testing of how %global behaves as well?
17:40:41 <Rombobeorn> According to my notes, I tested with %global when I wrote GNAT_add_rpath. I could define and undefine the macro several times and control exactly where in the spec it was active.
17:41:04 <geppetto> cool
17:41:31 <abadger1999> Excellent.
17:41:59 <abadger1999> #info Rombobeorn is going to do some testing of check-rpaths and add running that to the proposal
17:42:27 <abadger1999> #topic #358     Please make some autotools guidelines.
17:42:37 <abadger1999> https://fedorahosted.org/fpc/ticket/358
17:43:19 <abadger1999> Still a general call for anyone else to finish up that draft (pretty much just filling in the patching strategy section)
17:43:40 <abadger1999> I don't know if I'll work on that or not over my vacation.
17:44:06 <abadger1999> I am planning to work on scls a bit and that might exhaust my quota of FPC work on a holiday ;-)
17:44:23 <abadger1999> #topic #369     Guidance on dealing with the bundled libev in perl-EV
17:44:34 <abadger1999> https://fedorahosted.org/fpc/ticket/369
17:45:13 <abadger1999> https://fedorahosted.org/fpc/ticket/369#comment:5
17:45:27 <abadger1999> bochecha does have a point that we could treat this like a static library.
17:45:41 <abadger1999> I guess I wouldn't be opposed to that but kinda consider it a last resort.
17:46:18 <Rathann> same upstream, eh
17:46:53 <abadger1999> I'm not sure about: the mentioned xorg-x11-server-source.. did we evaluate that?
17:46:54 <geppetto> eh, this one annoys me
17:47:13 <abadger1999> I do remember lzma, though, and we did approve this strategy for that case.
17:47:19 <limburgher> <sigh>
17:47:36 <abadger1999> Rathann: that's a good point as well.
17:48:34 <Rathann> I'd like to see an attempt to build libev as required by perl-EV
17:48:50 <Rathann> and test if other dependent packages still work
17:49:41 <Rathann> I'd volunteer to do that, but I still have a ton of tasks on my TODO list and very little spare time
17:50:41 <Rathann> using -source approach and strict version-locked Requires: would be a last-resort option in my opinion as well
17:51:10 <geppetto> yeh, I could live with myself for allowing that … but I'd rather not.
17:51:38 <geppetto> My guess is that not much else will work without help from upstream though, which isn't going to be provided.
17:51:43 <racor> abadger1999: One remark wrt. autotools, do you know about the autobook (by T. Tromey et.al). It's a bit dated, but it's still generally valid and is available on the net. However, I think we should ask the authors for permission, because it once was (is?) sold in print.
17:52:42 <abadger1999> racor: I've read parts of it in the past but haven't looked at it in years.
17:53:04 <abadger1999> I'm not sure if there's something in there about patching the generated files, though?
17:53:54 <abadger1999> So how about -- ask to try compiling libev as perl-EV requires and then seeing if anything breaks.
17:54:12 <abadger1999> If something does, then we can look into how we would treat this.
17:54:55 <abadger1999> Did we ever decide what to do with C++ header-only files?  I remember a ticket but can't remember the outcome.
17:55:34 <abadger1999> https://fedorahosted.org/fpc/ticket/337
17:55:54 <abadger1999> Looks like we didn't get to a vote but were leaning towards treating them just like static libraries.
17:58:09 <Rathann> hm the draft looks fine
17:58:40 <Rathann> but I'd say that the package can be noarch if there's no testsuite
17:59:45 <geppetto> or the testuite is in a sub-package
17:59:59 <Rathann> I think that was about %check testsuite
18:00:00 <geppetto> But I'd also guess these libraries should be pretty small.
18:00:20 <geppetto> So making them be arched all the time is probably meh.
18:00:23 <Rathann> and the idea was to ensure that tests pass on all primary arches
18:00:28 * geppetto nods
18:01:01 <abadger1999> geppetto: +1
18:01:03 <Rathann> else it's a bug and should be reported to upstream and if upstream says it's known and won't be fixed then ExcludeArch:
18:01:08 <racor> My remark in https://fedorahosted.org/fpc/ticket/337#comment:5 still applies
18:01:46 <geppetto> yeh, so remove the last line from the proposal "if the packager is sure..." … and I'll +1 it.
18:02:06 <Rathann> right
18:02:07 <racor> if <arch> is made mandatory, I'll +1
18:02:08 <abadger1999> I'd lean towards the side of caution wrt noarch too... the cost of making it arch'd by mistake is just another small package.  the cost of making it noarch by mistake is that things will miscompile or fail to build.
18:03:14 <Rathann> no objections from me
18:03:28 <RemiFedora> hm... if "devel" is a subpackage, it could be noarch, as far as the main package is narched
18:03:34 <racor> abadger1999: Also consider "real" *-static packages usually be arched
18:04:28 <racor> abadger1999: Also, *-headers packages are not unlikely to once be added real libs
18:05:34 <abadger1999> Okay -- so like this? http://fpaste.org/63277/87476320/
18:06:39 <geppetto> yeh, +1
18:06:54 <limburgher> Sure.
18:07:21 <Rathann> +1
18:07:26 <abadger1999> +1
18:07:38 <limburgher> +1 so it's official
18:08:00 <abadger1999> racor: that wording is good for you?
18:08:01 <racor> +1
18:08:04 <RemiFedora> have arched header only package also allow to properly manager dependency with _isa
18:08:05 <racor> yep
18:08:06 <RemiFedora> +1
18:09:10 <abadger1999> #topic 337 Guidelines needed for header only libraries
18:09:47 <abadger1999> #info header only libraries draft passes with a modification to require such packages to be arch'd (+1:6, 0:0, -1:0)
18:10:00 <abadger1999> #topic #369     Guidance on dealing with the bundled libev in perl-EV
18:10:07 <abadger1999> Okay -- so to finish on this one.
18:11:06 <abadger1999> I'll ask that the maintainer try to compile libev as needed for perl-EV and see if anything else breaks.  If it does, come back to us and we'll see about approving this using a static library strategy.
18:11:24 <abadger1999> #topic #375  Update to the Addon Packages naming guidelines for Python 3 Modules
18:11:31 <abadger1999> https://fedorahosted.org/fpc/ticket/375
18:12:17 <abadger1999> So this one is.... pain-filled.
18:13:03 <abadger1999> I think the table for python3 is okay now... it reflects the guidance that the python3 names should match the python2 names.
18:13:35 <Rathann> mschwendt's points are all valid
18:13:39 <abadger1999> But mschwendt is bringing up a valid point that a lot of the python2 names don't match what our package naming guidelines would expect.
18:14:23 <limburgher> Lots of old stuff.
18:14:28 <abadger1999> Yeah.
18:14:41 <limburgher> So either we keep gfathering or initiate a bunch of rename reviews.
18:14:45 <geppetto> yeh, these are all old stuff that was grandfathered in …
18:14:58 <Rathann> old stuff that doesn't follow the guidelines shouldn't be used as justification for new deviations
18:15:15 <Rathann> and definitely not as good examples :)
18:15:32 <geppetto> I don't mind requiring 666 renames, but have we ever done that before … can we?:)
18:17:14 <Rathann> I have to leave early, guys
18:17:33 <abadger1999> Rathann: well -- so the reason they're in the python3 guidelines is because we didn't want to have the python2 name be gnome-python and the python 3 name be python3-gnome.
18:17:33 <Rathann> baby bath time
18:17:49 <abadger1999> at least, if they come from the same source rpm.
18:17:58 <abadger1999> that would be very confusing.
18:18:28 <Rathann> very? I wouldn't say so
18:19:08 <Rathann> anyway, I have to go, sorry
18:19:11 <abadger1999> k
18:19:45 <abadger1999> So options -- Change the pyhton2 guidelines to mention these grandfathered modules as well.
18:20:00 <abadger1999> that should just be a clarification.
18:20:24 <abadger1999> change the python3 guidelines to mandate that all python3 modules use python3-* regardless of what the python2 module does.
18:20:35 <abadger1999> that would be an actual meaningful change.
18:21:11 <abadger1999> ask fesco to have people rename their python2 modules to the python-* naming convention.
18:21:26 <abadger1999> That last one... I'm not too sure is practical :-)
18:22:29 <geppetto> The former change is probably nicer.
18:22:38 <geppetto> There are already a bunch of py3 things though.
18:23:13 <abadger1999> yeah.
18:23:55 <limburgher> I have to go soon too, do we have something in a votable state or no?
18:25:21 * RemiFedora also have to go really soon
18:25:41 <abadger1999> I think we don't have something votable here.
18:25:57 <abadger1999> How about we think about these options and pick it back up in January.
18:26:03 <limburgher> Works for me.
18:26:13 <abadger1999> There is one more thing that is probably votable
18:26:14 <geppetto> sure :)
18:26:28 <abadger1999> https://fedorahosted.org/fpc/ticket/376
18:26:37 <abadger1999> #topic 376 Make a clarification about the use of %{__python2} in epel, in the guidelines.
18:26:57 <abadger1999> epel5 doesn't provide the python2 macros.
18:27:28 <abadger1999> so just note on the python guidelines that this will be needed (since we're moving from %{__python} to %{__python2}
18:29:08 <abadger1999> actually for hte macro I'd use:  %{!?__python2: %global __python2 /usr/bin/python2} but other than that I think it's a fairly simple, needed change
18:29:09 <abadger1999> +1
18:29:18 <geppetto> +1
18:29:27 <limburgher> +1
18:29:30 <RemiFedora> +1
18:31:16 <abadger1999> tibbs|w, racor: a vote from either of you would pass this one.
18:31:24 <RemiFedora> bye
18:31:52 <tibbs|w> +1 but I'm not sure why EPEL isn't just offloaded to the EPEL guideline page.
18:31:52 <tibbs|w> Also, I'm lagging.
18:33:02 <abadger1999> Cool.
18:33:37 <abadger1999> #info Proposal to add information on macros for epel5 to the python guidelines page approved (+:5, 0:0, -1:0)
18:33:42 <abadger1999> #topic Open Floor
18:33:52 <abadger1999> I think people have been taking off :-)
18:33:53 <limburgher> Nothing from me.
18:34:03 <abadger1999> If there's nothing else, I'll close in 10
18:34:10 <abadger1999> 5
18:34:17 <abadger1999> 0
18:34:21 <abadger1999> #endmeeting