From Fedora Project Wiki
[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!