Meeting:Packaging IRC log 20070306

[11:00:34]  	 * spot is here
[11:00:59]  <tibbs>	I'm here.
[11:03:13]  <lutter>	I'm here
[11:03:30]  	 * thim1 is here, too
[11:04:07]  	 * thl is on the rabble seats
[11:04:44]  	 * spot counts four active voting members
[11:05:12]  <spot>	racor, f13, abadger?
[11:06:33]  Join	scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[11:06:39]  <spot>	scop: alive?
[11:06:46]  <scop>	barely ;)
[11:06:54]  <spot>	alright, thats quorum (barely)
[11:07:26]  <spot>	so, making sure i remember correctly
[11:07:27]  <f13>	ok, I"m here
[11:07:40]  <spot>	last meeting, we passed the buildroot and init scripts guideline changes
[11:08:03]  <spot>	did they get presented to FESCO for approval? (I was unable to attend)
[11:08:10]  <f13>	yes on both counts
[11:08:20]  <spot>	and they were not overridden?
[11:08:33]  <f13>	spot: although fesco would like to have the deadline removed from teh init script part
[11:08:41]  <f13>	it belongs in a feature for a release not in the guidelines
[11:09:02]  <f13>	spot: nope.  THere was actually very little conversation around the init script proposal
[11:09:08]  <f13>	mostly people wanted more guidance on init scripts
[11:09:09]  <tibbs>	I can paste the relevant log if you need to see it.
[11:09:09]  Join	ecik_ has joined this channel (n=ecik@inet20908nb-2.eranet.pl).
[11:09:16]  <scop>	http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00087.html
[11:09:35]  <spot>	ok, great.
[11:09:41]  <spot>	i'll mark those as writeup
[11:09:44]  Quit	ecik has left this server (Nick collision from services.).
[11:09:45]  Nick	ecik_ is now known as ecik.
[11:09:55]  <spot>	First item of business
[11:10:04]  <spot>	https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html
[11:10:07]  <racor>	sorry, now I'm here (got distracted by other tasks)
[11:10:10]  <spot>	aka, Firmware Guidelines v3
[11:10:29]  <thim1>	+1
[11:10:46]  <spot>	+1 (voted on the list as well)
[11:10:53]  <f13>	spot: cool, I'll write up the init script (minus the deadline) hopefully today
[11:10:55]  <scop>	+1 (ditto already on list)
[11:10:56]  <tibbs>	I think the only remaining question was whether we should prefer firmware-<foo>
[11:11:38]  <tibbs>	I don't really care either way, but firmware-<foo> seems more consistent with the existing naming guidelines.
[11:11:46]  <lutter>	+1
[11:11:57]  <f13>	hrm, wasn't there plenty of example for foo-<firmware> though?
[11:12:08]  	 * f13 looks
[11:12:32]  <scop>	I don't think firmware-foo would be consistent with naming guidelines
[11:12:37]  <spot>	neither do i
[11:12:45]  <thim1>	BTW the proposal is just SHOULDs, no MUSTs, so if there is reason enough to clal it firm-foo-ware, then that's not excluded ...
[11:12:51]  <spot>	i think its "foo-bar", with "bar for foo"
[11:12:52]  <tibbs>	kmod-blah firmware-blah seems consistent to me.
[11:12:55]  <f13>	<foo>-firmware works like foo-libs and foo-devel
[11:13:03]  <spot>	ipw2200-firmware is firmware for ipw2200
[11:13:06]  <f13>	tibbs: I find that failings of those guidelines unfortunately :/
[11:13:06]  <scop>	kmod is a special case
[11:13:16]  <spot>	kmod is always a special case.
[11:13:32]  <tibbs>	firmware is something of a special case as well.
[11:13:39]  <f13>	spot: short bus, helmet, drool cloth
[11:13:55]  <spot>	tibbs: firmware is special, kmod is what f13 just said.
[11:14:37]  <tibbs>	Anyway, +1 on the proposal, but it really seems like we aren't thinking these kind of things through.
[11:14:47]  <spot>	tibbs: i'd argue that we are.
[11:14:56]  <spot>	this item was hashed out in depth on the mailing list
[11:14:58]  <thim1>	That's 5 +, so it passes
[11:15:18]  <thim1>	Another item:
[11:15:23]  <f13>	+1 from me, so that's 6
[11:15:23]  <thim1>	Minutes and fesco report
[11:15:24]  <spot>	note that this is v3 of the draft. :)
[11:15:26]  <f13>	I forgot to vote
[11:15:50]  <spot>	thim1: ok?
[11:16:01]  <thim1>	thim1?
[11:16:08]  <thim1>	Is that what I'm sold as=
[11:16:32]  <spot>	uhh, thats what you're logged into irc as
[11:17:18]  <spot>	what about the minutes and fesco report?
[11:17:19]  <thim1>	Oh, well gaim show myself as thimm. Anyway that's me
[11:17:39]  <f13>	gaim-- :/
[11:17:42]  <thim1>	There was some complaints about missing minutes/report
[11:18:15]  <f13>	a call for help went out on packaging-list IIRC
[11:18:18]  <thim1>	f13: I'm rather irc-agnostic, I picked the first app
[11:18:21]  <spot>	would anyone like to be responsible for taking minutes?
[11:18:35]  <thim1>	Does fedora-meeting have automatic minutes?
[11:18:47]  <spot>	thim1: no, i don't think so.
[11:18:49]  <tibbs>	Posting logs is one thing.  Summarizing them is another.
[11:18:49]  <thim1>	We could cut&paste from some irc robot
[11:18:50]  <thl>	thim1, no
[11:18:54]  <f13>	maybe it was on -maintainers.
[11:19:17]  <f13>	thl: it's not a bad idea for #fedora-meeting.  Not a good idea for other channels.
[11:19:23]  <thim1>	We should perhaps recommend some ircbot on fedora-meeting
[11:19:24]  <spot>	well, the very fine grained summary is kept mostly current on Packaging/GuidelinesTodo
[11:19:32]  <tibbs>	I always keep logs and would be happy to post them.  But I've not been comfortable in the past with summarizing discussion.
[11:19:33]  <thl>	f13, agreed
[11:19:56]  <thl>	(the no was just meant as a answer to thim1's question, not as "no, please not")
[11:20:01]  <f13>	well, I think a summary of "foo passed, bar did not" and a raw IRC log is sufficient.
[11:20:11]  <f13>	thl: understood (:
[11:20:27]  <tibbs>	I'm happy to do that much.
[11:20:29]  <thim1>	Then meet on fedora-meeting and ask for a bot?
[11:20:36]  <f13>	thim1: +1
[11:20:38]  <spot>	tibbs: ok, i think thats sufficient
[11:20:45]  <f13>	I'm Ok with moving the meeting to #fedora-meeting
[11:21:05]  <thim1>	tibbs = our ircbot :)
[11:21:10]  <thim1>	tibbs: thanks!
[11:21:16]  <f13>	I think we're going to need to start scheduling the meeting room though (:
[11:21:20]  <tibbs>	We could conceivably eliminate this channel if we move the meetings.
[11:21:34]  <f13>	tibbs: I'm OK with that too, and directing to #fedora-devel
[11:21:45]  <spot>	i'm also ok with that.
[11:21:52]  <thim1>	OK, do we need a vote?
[11:21:57]  <spot>	sure, why not.
[11:21:58]  <tibbs>	One less tab is good, and this channel receives little traffic otherwise.
[11:21:59]  <thim1>	For moving to fedora-meeting?
[11:22:01]  <thim1>	+1
[11:22:03]  <spot>	+1
[11:22:04]  <tibbs>	+1
[11:22:09]  <lutter>	+1
[11:22:13]  <f13>	+1
[11:22:25]  <spot>	ok. thats that.
[11:22:26]  <thim1>	OK, next meeting on fedora-meetings, then
[11:22:33]  <spot>	Next item:
[11:22:35]  <tibbs>	fedora-meeting is free at 17:00 UTC, BTW.
[11:22:38]  <thim1>	Who can do redirection magic?
[11:22:39]  <f13>	VOte for closing this channel and redirecting to #fedora-devel ?
[11:22:43]  <scop>	fedora-meeting or fedora-meetings?
[11:22:50]  <f13>	#fedora-meeting
[11:22:52]  <spot>	i can do the redirect magic
[11:22:59]  	 * scop has a history of attending wrong channels :)
[11:22:59]  <tibbs>	I'll reserve the channel.
[11:23:02]  <f13>	scop: fesco, Fedora Board, various sigs all use that channel.
[11:23:07]  <scop>	ok
[11:23:23]  <tibbs>	Oh, crap, wiki tables suck so hard.
[11:23:25]  <thim1>	tibbs: in wiki? Thanks!
[11:23:34]  <spot>	Lets vote on redirecting this channel to #fedora-devel
[11:23:52]  <thim1>	+1
[11:23:55]  <spot>	+1
[11:23:56]  <tibbs>	+1
[11:24:09]  <f13>	+1
[11:24:24]  <lutter>	+1
[11:24:36]  <spot>	ok. i'll do it after today's meeting.
[11:24:46]  <spot>	Next:
[11:24:53]  <spot>	Disallow %config files in /usr
[11:25:01]  <thim1>	+1 :)
[11:25:01]  <spot>	aka: PackagingDrafts/UsrConfigs
[11:25:43]  	 * f13 reads the draft
[11:25:59]  Join	londo_ has joined this channel (n=georgiou@heppc218.hep.ph.ic.ac.uk).
[11:26:11]  <spot>	the FHS says that /usr should be able to be read-only
[11:26:16]  <f13>	Seems reasonable.  Might need a little wordsmithing, but I'm OK with that happening after the approval.
[11:26:26]  <spot>	that would tend to mean that any configs in /usr are violating the FHS
[11:26:43]  <f13>	spot: I think regardless of FHS, allowing configuration in /usr just feels dirty.
[11:26:49]  <spot>	"Any information that is host-specific or varies with time is stored elsewhere."
[11:27:01]  <spot>	config files fall well into that.
[11:27:02]  <f13>	as a Distribution goal, we want to restrict all our configuration into /etc, regardless of what FHS may or may not allow for.
[11:27:12]  <scop>	somehow the symlink part of the draft gives me goosebumps
[11:27:20]  <spot>	scop: why?
[11:27:25]  <tibbs>	Is hacking up the source better?
[11:27:29]  <f13>	spot: nfs mounted /usr might get fun.
[11:27:43]  <thim1>	why?
[11:27:46]  <scop>	I don't know specifically - overwriting symlinks from cpio archives/rpms can be a royal pita
[11:28:09]  <thim1>	scop: Yes, that's very ugly
[11:28:17]  <f13>	thim1: where does the symlink point when you NFS mount a /usr/ ?
[11:28:24]  <spot>	well, maybe we don't want to say use symlinks?
[11:28:44]  <thim1>	f13: Where's the conifg with nfs mounted /usr?
[11:28:47]  <f13>	I think saying existing software can have a temporary exception while a bug is filed upstream to fix it?
[11:29:01]  <thim1>	f13: That can take ages
[11:29:13]  <thim1>	Think X11 and fonts.alias or similar
[11:29:16]  <f13>	thim1: thats fine, we can make it a Feature of a Fedora release to clean it up
[11:29:23]  <f13>	or clean it up as best as we can.
[11:29:35]  <thim1>	Maybe "use a symlink as a last resort"?
[11:29:48]  <thim1>	Or drop the symlink suggestion at all?
[11:29:49]  <f13>	or just don't mark it as %config ?
[11:29:56]  <f13>	thim1: I think drop the symlink for now.
[11:30:04]  <scop>	f13++
[11:30:25]  <tibbs>	Is there agreement that %config shouldn't be used in /usr?  That's the fundamental idea behind the proposal.
[11:30:29]  <spot>	Perhaps this should be reworded to simply: No files under /usr can be marked as %config.
[11:30:34]  <thim1>	OK, the proposal is just "Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora."
[11:30:35]  <thim1>	+1
[11:30:54]  <f13>	+1
[11:30:56]  <spot>	+1
[11:31:08]  <tibbs>	+1
[11:31:10]  <racor>	-1
[11:31:13]  <scop>	+1
[11:31:22]  <thim1>	OK, it passes
[11:31:23]  <spot>	racor: why the no vote?
[11:31:33]  <thim1>	racor wants all python code to be %config ;)
[11:31:42]  <tibbs>	Isn't there a discussion still ongoing here?  Does it show any signs of actually arriving at any conclusion?
[11:31:43]  <racor>	everything has been said on the list.
[11:31:55]  <racor>	I am not going to reiterate it once more
[11:32:09]  <thim1>	OK, anyone with a better wording for the proposal?
[11:32:23]  <racor>	thim1: behave
[11:32:48]  <thim1>	That's not semantically the same
[11:33:23]  <spot>	thim1: i think your sentence is fine.
[11:33:32]  <spot>	or two sentences, rather
[11:33:36]  <thim1>	OK, next item then
[11:34:00]  <spot>	well, thats all the items i had on the agenda
[11:34:03]  	 * rdieter_away walks in late, cursing about other meetings running late.
[11:34:21]  Nick	rdieter_away is now known as rdieter.
[11:34:44]  <rdieter>	looks like I came just in time. (:
[11:34:45]  <spot>	does anyone else have anything they'd like to discuss?
[11:35:02]  <tibbs>	Who will fix up the UsrConfigs page?  I'd like it to be in approved form before I post the summary.
[11:35:07]  <rdieter>	for lack of anything else, Cmake.
[11:35:15]  <scop>	any news/thoughts about the perl/perl-devel split in devel?
[11:35:31]  <rdieter>	http://fedoraproject.org/wiki/PackagingDrafts/cmake
[11:35:31]  <spot>	rdieter: what about cmake?
[11:35:35]  <tibbs>	And I'd like to touch on rpmlint uptake of these guideline changes.
[11:35:43]  <f13>	thim1: can you update the Draft page?
[11:35:44]  <thim1>	tibbs: done
[11:35:47]  <f13>	oh haha
[11:36:02]  <tibbs>	I have used rdieter's cmake draft in one review and it was quite helpful.
[11:36:07]  <f13>	scop: lets get to that after the Draft
[11:36:11]  <f13>	er after the cmake draft
[11:36:23]  <rdieter>	it's not mine, but I'd like it considered for ratification all the same. (:
[11:36:24]  <tibbs>	The cmake draft is more of a "useful document".
[11:36:39]  <rdieter>	tibbs: ok, but so is Packaging/Python, etc...
[11:36:40]  <scop>	I have the firmware changes already in my local rpmlint working copy, will push a new release after they're ratified by FESCO
[11:37:01]  <tibbs>	rdieter: True.
[11:37:01]  <f13>	rdieter: would it make sense to create a %cmake set of macros in rpm like there are %configure ?
[11:37:21]  <rdieter>	f13: that might make sense, sure.
[11:37:41]  <spot>	rdieter: feel like writing a patch for redhat-rpm-config ? :)
[11:37:46]  <thim1>	I don't really like that the build dir is called "fedora"
[11:37:55]  <thim1>	Will be again another issue with RHEL etc.
[11:38:01]  <rdieter>	spot: heck, put the macros into the 'cmake' package might make even more sense. ??
[11:38:01]  <f13>	that should simplify the Draft if we have %macros
[11:38:02]  <spot>	thim1: you could call it goldfish
[11:38:15]  <spot>	its just a top level builddir
[11:38:17]  <tibbs>	thim1: Any suggestion?  It's just a temp dir.
[11:38:24]  <thim1>	How bout "build"
[11:38:38]  <scop>	why *is* there such a temp dir? does cmake require it for some reason?
[11:38:43]  <f13>	how about mkdtemp (:
[11:38:54]  <thim1>	Or buildroot ;)
[11:38:56]  	 * spot throws a bottle at f13
[11:39:01]  <spot>	and thimm
[11:39:05]  <thim1>	scop: No, cmake does not rquire it
[11:39:06]  <tibbs>	cmake generally does out-of-tree builds, I guess.
[11:39:13]  <scop>	hmm
[11:39:16]  <thim1>	scop: for packaging it also doesn't really make sens to buil oot
[11:39:33]  <thim1>	tibbs: the kernel does, too
[11:39:34]  <scop>	we don't recommend using VPATH builds with autotools either
[11:39:40]  <thim1>	Indeed
[11:39:50]  <racor>	gcc does, too
[11:39:51]  <scop>	(we don't recommend against them either, but that's not the point...)
[11:39:59]  <thim1>	For vtk it also triggers bugs to buil oot
[11:40:01]  <spot>	i think mkaing the macro do just "cmake -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} -DBUILD_SHARED_LIBS:BOOL=ON" with the exported optflags...
[11:40:07]  <tibbs>	So what gets hurt if we drop the mkdir fedora bit?  The spec gets shorter.
[11:40:07]  <racor>	most cross-packages must be VPATH-built ...
[11:40:10]  <spot>	then, people can call:
[11:40:14]  <spot>	%cmake ..
[11:40:22]  <spot>	if they want to do an out-of-tree build
[11:40:32]  <racor>	how about the other GNU *dirs?
[11:41:07]  	 * spot is definitely not a cmake expert
[11:41:23]  	 * rdieter isn't either, but trying to get a little proficient.
[11:41:24]  <spot>	racor: but yes, that seems sensible
[11:41:25]  <f13>	spot: that sounds best to me, make it work almost just like %configure
[11:41:55]  <rdieter>	ok, since folks seem to like the macros idea, let me come up with something, and I'll work with the cmake maintainer on that.
[11:42:02]  <thim1>	Aynone wants to make it his pet project and work with Orion?
[11:42:03]  <scop>	rdieter, thanks
[11:42:04]  <tibbs>	How much ability do we have to modify the rpm macros?
[11:42:06]  <spot>	rdieter: ok, sounds good, we'll revisit this.
[11:42:12]  <thim1>	rdieter: thanks!
[11:42:15]  <tibbs>	Does this require a core rpm package update?
[11:42:20]  <spot>	tibbs: i spoke to paul on that and he seemed to think it wouldn't be too bad
[11:42:21]  <rdieter>	tibbs: no, shouldn't.
[11:42:22]  <thim1>	shipped with cmake
[11:42:31]  <spot>	tibbs: no, we just need to alter redhat-rpm-macros
[11:42:42]  <spot>	err, s/macros/config
[11:42:44]  <rdieter>	spot: redhat-rpm-macros should need tweaking either.
[11:42:51]  <rdieter>	should not that is.
[11:42:55]  <racor>	rdieter: I hate macros - they have always been a double sided sword, helpful in short term, a nightmare in long term
[11:43:02]  <spot>	rdieter: well, we have to put the macro somewhere. :)
[11:43:08]  <scop>	rdieter, check PLD and Mandriva while doing it, to see if they already something available?
[11:43:10]  <thim1>	in cmake package
[11:43:14]  <rdieter>	spot: why not in 'cmake' itself?
[11:43:16]  <thim1>	/etc/rpm/macros.cmake
[11:43:16]  <racor>	%configure and %makeinstall are no exception
[11:43:20]  <spot>	ok.
[11:43:26]  <rdieter>	scop: good idea, will do.
[11:43:49]  <spot>	alright, now lets flame me about perl/perl-devel. ;)
[11:43:54]  <scop>	one semi-unrelated thing about the cmake draft still
[11:43:58]  <rdieter>	racor: we'll see how well it works, and if it sticks.  If not, we can work on something else better.
[11:44:02]  <thim1>	rdieter: macors in cmake is better: no backporting of redhat-rpm-config possible
[11:44:26]  <scop>	basic question: is there a technical reason why shared libs need to be excutable on Linux?
[11:44:52]  <racor>	yes - They are programs
[11:44:52]  <rdieter>	scop: excellent question, because by default, cmake doesn't do that, which breaks -debuginfo (atm)
[11:44:55]  <scop>	I know various things expect them to be, but I don't have a clue why
[11:44:59]  <f13>	scop: currently that is used to trigger rpm to do depsolving of them.
[11:45:11]  <scop>	f13 yes I know that
[11:45:17]  <tibbs>	rpmbuild keys a whole bunch of things off of the x bit.
[11:45:25]  <scop>	but *why*
[11:45:28]  <f13>	other than that, I don't know the technical reasons around it.
[11:45:32]  	 * f13 doesn't dig that deep
[11:45:45]  <thim1>	There is one lib that is really "executable"
[11:45:52]  <scop>	libc?
[11:45:52]  <rdieter>	all I know, is running ldd on non-eXecutable libs, it complains loudly.
[11:46:04]  <spot>	iirc, if they're not +x, debuginfo doesn't work on them
[11:46:09]  <scop>	rdieter, I know that too, but I think it works anyway
[11:46:14]  <f13>	rdieter: so it might be an ldd thing not an rpm thing?
[11:46:18]  <thim1>	# /lib/libc.so.6
[11:46:18]  <thim1>	GNU C Library stable release version 2.5, by Roland McGrath et al.
[11:46:18]  <thim1>	Copyright (C) 2006 Free Software Foundation, Inc.
[11:46:18]  <thim1>	This is free software; see the source for copying conditions.
[11:46:18]  <thim1>	There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
[11:46:18]  <thim1>	PARTICULAR PURPOSE.
[11:46:19]  <scop>	spot, yes, but those cannot be the *reasons*
[11:46:20]  <thim1>	Compiled by GNU CC version 4.1.1 20061011 (Red Hat 4.1.1-30).
[11:46:22]  <thim1>	Compiled on a Linux 2.6.9 system on 2007-01-05.
[11:46:24]  <thim1>	Available extensions:
[11:46:26]  <thim1>	        The C stubs add-on version 2.1.2.
[11:46:28]  <thim1>	        crypt add-on version 2.1 by Michael Glad and others
[11:46:29]  <spot>	thats a drepper question
[11:46:30]  <thim1>	        GNU Libidn by Simon Josefsson
[11:46:32]  <thim1>	        GNU libio by Per Bothner
[11:46:34]  <thim1>	        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
[11:46:36]  <thim1>	        Native POSIX Threads Library by Ulrich Drepper et al
[11:46:38]  <thim1>	        BIND-8.2.3-T5B
[11:46:40]  <thim1>	        RT using linux kernel aio
[11:46:42]  <thim1>	Thread-local storage support included.
[11:46:44]  <thim1>	For bug reporting instructions, please see:
[11:46:46]  <thim1>	<http://www.gnu.org/software/libc/bugs.html>.
[11:46:49]  	 * f13 looks at thim1
[11:46:53]  <tibbs>	However, another random library:
[11:47:00]  <tibbs>	> /lib/libutil-2.4.so
[11:47:00]  <tibbs>	zsh: 21439 segmentation fault  /lib/libutil-2.4.so
[11:47:03]  	 * spot gets his life-preserver to survive the flood
[11:47:34]  <spot>	someone should email ulrich.
[11:47:52]  <tibbs>	I nominate scop to do chmod -x all of his libs and see how the system fares.
[11:48:06]  <spot>	i'm sure he'll reply with more information on why it is needed than you ever wanted to know.
[11:48:21]  <spot>	(or he'll flame you. either way.)
[11:48:23]  <scop>	tibbs, ok, here we go...
[11:48:26]  Quit	scop has left this server ("Leaving").
[11:48:31]  <tibbs>	scop: What motivatd the question?
[11:48:32]  <thim1>	:)
[11:48:33]  <tibbs>	Doh.
[11:48:38]  <thim1>	That was impressive
[11:48:40]  Join	scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[11:48:54]  <thim1>	Looks like executable bit on libs is needed for irc ...
[11:49:00]  <f13>	scop: cute (:
[11:49:04]  	 * scop is soooooo funny
[11:49:12]  <spot>	aaaanyways
[11:49:19]  <f13>	<tibbs> scop: What motivatd the question?
[11:49:20]  <spot>	lets talk perl/perl-devel
[11:49:30]  	 * f13 puts on the flack jacket
[11:49:47]  <spot>	i posted an updated spec that splits more items into -devel (and more cleanly)
[11:50:02]  <scop>	f13, tibbs: general curiosity, always wondered about it
[11:51:01]  <thim1>	Does the perl/perl-devel split require a guideline review?
[11:51:08]  <f13>	spot: with the split, how big does perl-devel wind up being?
[11:51:14]  	 * spot looks
[11:51:31]  <tibbs>	Exempting it from the guidelines would require a vote, I think.
[11:51:33]  <f13>	thim1: if we split it no, otherwise it'll need a guideline exception
[11:51:34]  <spot>	792075
[11:51:49]  <thim1>	OK
[11:51:50]  <rdieter>	not insignificant.
[11:51:51]  <spot>	vs 11442930 for perl
[11:51:53]  <f13>	700K
[11:52:04]  <tibbs>	And I'll reiterate that I'm fine with granting it an objection if splitting it proves unreasonable.
[11:52:05]  <f13>	or is my math wrong?
[11:52:19]  <spot>	774K
[11:52:29]  <f13>	spot: I was estimating (:
[11:52:44]  <spot>	compared to the remaining 11M of perl, its not much, but still
[11:52:45]  <thim1>	It's 7%
[11:52:45]  <f13>	so not significant enough to really harp on for thigns like the LIveCD
[11:52:55]  <f13>	olpc punts perl all together so no real help to them.
[11:53:06]  <racor>	it's only the beginning, there definitely is much more to come
[11:53:12]  <f13>	yeah, I'd rather it follows the guidelines.
[11:53:19]  <f13>	if possible/reasonable.
[11:53:25]  <spot>	racor: more items that should be in devel, or more minimizing of perl?
[11:53:27]  <tibbs>	racor: What do you believe is yet to come?
[11:53:34]  <racor>	more to add to devel
[11:53:47]  <racor>	/usr/bin/perl<os>
[11:53:51]  <racor>	Test::
[11:54:11]  <thim1>	Test::?
[11:54:12]  <f13>	racor: are you in favor of the move, if done right?
[11:54:12]  <spot>	ok. do you think you'll have time to document some of these items?
[11:54:14]  <racor>	man3's
[11:54:24]  <racor>	f13: yes
[11:54:39]  <spot>	robin and i both want to do this right.
[11:54:43]  <racor>	I think, things are evolving,
[11:54:51]  <racor>	but we're not quite there
[11:54:53]  <f13>	ok, so it's just a matter of getting it right.  Everybody seems to be on the same page that this should be done.
[11:54:58]  <thim1>	So all perl packages will buildrequire perl-devel, right?
[11:55:02]  <spot>	(but we also want to get it done as quickly as possible)
[11:55:06]  <spot>	thim1: probably, yes.
[11:55:13]  <f13>	racor: are you OK with continuing to work on the split, and while it's being worked on, perl Requires perl-devel ?
[11:55:16]  <scop>	spot, thim1, probably not :)
[11:55:17]  <thim1>	global replace in CVS?
[11:55:28]  <scop>	BuildRequires: perl(ExtUtils::MakeMaker)
[11:55:31]  <thim1>	scop: Test:: for example is needed on every second package
[11:55:40]  <spot>	scop: yeah, yeah, i see the point.
[11:55:56]  <f13>	scop: that should be done regardless of the split (:
[11:56:09]  <racor>	scop: ACK, but I am seeing side-effects that still need further investigations
[11:56:14]  <rdieter>	f13++
[11:56:46]  <thim1>	I have an off-topic packaging question
[11:56:48]  <racor>	Test::-Modules normally are only being used at buildtime
[11:57:01]  <f13>	*sigh*
[11:57:10]  <f13>	I'm really lacking the energy to continue talking to steved.
[11:57:30]  <thim1>	Are we done with perl?
[11:57:32]  <tibbs>	f13: Not the nfs4 acl thing?
[11:57:55]  <f13>	tibbs: no, he decides to blow up about teh init script thing today
[11:58:07]  <thim1>	Question: do we want to disallow using %buildroot during %prep and %build?
[11:58:27]  <spot>	umm, we require that it be nuked at %install
[11:58:28]  <tibbs>	Well, there are times when you can't get around it.
[11:58:40]  <scop>	examples?
[11:58:41]  <lutter>	thim1: what's the problem this would solve ?
[11:58:42]  <spot>	i don't think that we care if people want to use it before then. :)
[11:58:47]  <racor>	tibbs: ACK
[11:58:47]  <thim1>	spot: Hm, that implies that of course
[11:59:27]  <thim1>	lztter: The super-duper buildroot works fine if it's used in conventinal setup
[11:59:42]  <thim1>	I can think of awkward ones that use it during %prep and %build
[11:59:51]  <tibbs>	scop: This nfs4-acl thing I'm looking at requires configure to be called with paths in the buildroot or it won't build.
[11:59:53]  <thim1>	tibbs: why not?
[12:00:06]  <tibbs>	Granted the package is horribly broken.
[12:00:18]  <scop>	mmh
[12:00:21]  <thim1>	Put a temp path under buildir
[12:00:22]  	 * spot cringes
[12:01:02]  <tibbs>	That package needs an autoconf expert to fix it.  That's not me.
[12:01:20]  <spot>	tibbs: gimme the url for the srpm. i'll try.
[12:01:21]  <thim1>	Well, but at least the %buildroot-in%build part can be easliy fixed
[12:01:53]  <thim1>	do we want to disallow %buildroot during %prep and %build?
[12:01:59]  <tibbs>	spot: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229342
[12:02:00]  <thim1>	Vote or discuss next week?
[12:02:03]  <spot>	i don't think so, not at this point
[12:02:39]  <racor>	I once agains fail to see what this fixes.
[12:02:55]  <thim1>	short-circuits
[12:03:13]  <spot>	ok, short-circuiting is just asking for pain. in so many ways.
[12:03:26]  <scop>	using buildroot in %prep and friends probably makes it more likely that some creep in into final installed things
[12:03:41]  <scop>	eh
[12:03:57]  <scop>	I mean some installed files may end up having buildroots embedded in them
[12:04:11]  <thim1>	vote/discuss/postpone?
[12:04:11]  <tibbs>	I certainly agree with that.
[12:04:13]  <spot>	yeah, but wouldn't that get caught?
[12:04:18]  <tibbs>	But don't we check for that already?
[12:04:28]  <scop>	we do, yes
[12:04:34]  	 * spot points to /usr/lib/rpm/check-buildroot
[12:05:08]  <scop>	we also exclude classes of files there
[12:05:33]  <spot>	the farthest i'd be willing to go is say that you SHOULD not use it before %install
[12:05:43]  <thim1>	Why not?
[12:05:58]  <thim1>	Anything you do with %buildroot before %install can be made in a temp dir under %builddir
[12:06:13]  <thim1>	At the end it's a copy operation too many, not a biggie
[12:06:27]  <racor>	and vice versa.
[12:06:34]  <spot>	write up a draft, we'll consider it next week
[12:06:46]  <spot>	i'm just not sure if we're fixing non-existant bugs here
[12:06:46]  <thim1>	We do require %install to nuke %buildroot, so it's just a logical consequence to disallow it before %install
[12:06:48]  <f13>	with clear statement as to what problems this is supposed to fix (:
[12:07:00]  <racor>	%install
[12:07:02]  <spot>	we don't have guidelines that say "don't run rm -rf / in the spec"
[12:07:11]  <racor>	rm -f $RPM_BUILD_ROOT
[12:07:37]  <thim1>	If a package uses %buildroot before %install it violates the last line ^^^^
[12:07:55]  <tibbs>	rm -f $RPM_BUILD_ROOT_DISCUSSION
[12:07:59]  <racor>	=> change rpm to clear RPM_BUILD_ROOT and this discussion is moot
[12:08:22]  <thim1>	OK, time is up
[12:08:25]  <spot>	ok, since this is going nowhere fast, interested parties, submit guideline drafts
[12:08:38]  <spot>	i'm going to eat lunch, look at nfs4-acl, then vomit (likely)
[12:08:42]  <spot>	thanks all.
[12:08:50]  <scop>	thanks
[12:08:58]  Quit	racor has left this server ("Leaving").
[12:09:04]  <lutter>	read you next week
[12:09:10]  <tibbs>	I'll summarize after lunch.
[12:09:34]  <abadger1999>	tibbs: Do you want to send the pass/fail record to -maintainers or shall I?
[12:09:38]  <thim1>	tibbs: thanks!
[12:10:07]  <abadger1999>	(Just clarifying what's included in "summaize")
[12:11:48]  Quit	scop has left this server ("Leaving").
[12:12:15]  <tibbs>	abadger1999: I'll write up the whole thing and see how it goes.
[12:12:18]  <f13>	tibbs: thanks a ton for taking that up!
[12:12:45]  <abadger1999>	tibbs: Thanks!