Meeting:Packaging IRC log 20070306

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