16:59:31 #startmeeting FESCo meeting 7/31/09 16:59:33 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 16:59:40 * nirik is here. 16:59:51 * pingou around 16:59:53 * sharkcz here 17:00:05 * jwb is here 17:00:14 Present. 17:01:00 sorry for the false alarm re: lunch 17:01:02 * dgilmore is here 17:01:07 * skvidal is here 17:01:09 got the food to go :) 17:01:17 anyhow, let's get started 17:01:35 #topic mikeb as sponsor 17:01:40 .fesco 211 17:01:52 looks like he withdrew his request. 17:01:52 +1 17:01:52 * notting is here 17:02:26 I disagree that we should base this on quantity. I think that him doing more reviews to gain visibility and prove his understanding would be good too tho. 17:02:29 but that being said, I'd still be +1 17:02:32 because of the nosie made about it 17:02:47 yes, same here, i dont think that quantity is a good indicator. 17:03:14 he withdrew his request 17:03:22 he did 17:03:25 he also mentioned a desire to work on the backlog 17:03:26 move on 17:03:26 so, lets ask him to reapply in a month or something... 17:03:31 yeah 17:03:33 Well, feedback from the sponsors list was overwhelmingly negative. 17:03:45 based on quantity 17:03:49 If you think sponsors are basing their feedback on the wrong criteria, we need to get the criteria fixed. 17:03:52 based on flawed criteria. 17:04:17 Please don't ask our opinions if you don't like the answers you receive. 17:04:17 Or rather, clearly defined, because it seems they aren't. 17:04:36 they aren't. And they shouldn't be. 17:04:57 it's a subjective thing, really 17:05:01 I agree with tibbs, it's ridiculous to ask for feedback from the sponsors and then to ignore it. 17:05:02 So you won't define criteria, but yet you can easily say that someone else's criteria are flawed? 17:05:02 * nirik notes there was only one -1 17:05:04 jds2001, then you can't really say their criteria is flawed 17:05:10 That's really a poor method of argumentation. 17:05:30 And saying they're basing their decision on flawed criteria doesn't make sense when there are no criteria defined at all. 17:05:42 tibbs: sorry, I meant that other things should be taken into account 17:05:49 there was one -1 (from someone who thinks quantity is important) and a bunch of discussion about the process from various other people. 17:05:51 So I stay with my -1 vote. 17:05:54 * jds2001 notes the feedback was based on quantiy of reviews. 17:06:07 solely, and nothing else. 17:06:17 umm 17:06:27 why are we discussing a withdrawn item? 17:06:29 nirik: What you call "discussion" was "I agree" to the person saying -1. 17:06:30 let's move along 17:06:44 agreed. 17:06:49 And I think I've seen more than one explicit -1 too, but I may be remembering wrong. 17:07:07 #topic Fedora packages as canonical upstreams 17:07:11 Kevin_Kofler: I just reread the thread. Thats the only -1. ;) anyhow... 17:07:11 .fesco 210 17:07:29 This was proposed to FPC, but it's not really FPC's decision. 17:07:45 so there's some sticky situations here. 17:07:46 -1 to removing the exception, it makes no sense. 17:07:58 If there is code, then the exception needs to be removed. 17:08:07 jds2001, huh? 17:08:14 There are plenty of upstreams with no tarballs, only some SCM, some SRPMs or other source packages etc. 17:08:16 If there's not, then it can stay (I particularly looked at basesystem) 17:08:18 what would be valid as a upstream here? a fedorapeople link? 17:08:32 nirik: or a fedorahosted project 17:08:36 nothing extravagant 17:08:38 There are also plenty of upstreams which just dump a tar.bz2 into some directory. 17:08:43 but basesystem has nothing. 17:08:45 so this is saying that every package needs a Source0: that is a url? 17:08:51 Kevin_Kofler, those aren't want this is about... 17:08:51 If we do that, is that really more helpful than just having it in the SRPM? 17:08:55 nirik: thats how i read it. 17:08:56 We complain when suse makes you pull sources out of one of their packages. 17:09:04 Kevin_Kofler, ah, i see where you are going 17:09:07 jwb: Why should we be held to higher standards than other upstreams? 17:09:13 right, got it now 17:09:28 I see advantages of this, but it could cause issues too. 17:09:39 at the time the exception was drafted, we didnt have something like fedorahosted. 17:09:54 pointing to a git repo is imo valid. 17:10:02 or an ftp site, or whatever 17:10:07 ok, i have 3 issues with this 17:10:13 1) it's scoped to RH when it shouldn't be 17:10:13 not wanting to wade thru a flamefest, I would like to defer this till next week and ask for feedback on fedora-devel. Perhaps there are situations here that we need to deal with? 17:10:32 still, i'm not sure that making people open up FH projects just to have a place to dump tarballs is efficient 17:10:32 2) i agree with Kevin_Kofler that it doesn't really seem to be needed 17:10:40 and 3) what notting just said 17:10:49 so i'm -1 17:11:01 To be fair, I guess Rahul should be asked why he thought this was necessary. 17:11:03 notting: they could put it on fedorapeople. 17:11:14 jds2001, how is that better? 17:11:17 jds2001: but thats true of anything right? 17:11:25 right 17:11:25 jds2001: do we have an example package? 17:11:35 He submitted the original draft. FPC has no opinion on the issue. 17:11:44 obviously, any $foo-filesystem that's just a spec doesn't count 17:11:49 i looked at basesystem last night. It has nothing 17:12:01 basesystem needs to just go away anyway. 17:12:05 it would stand to lose from removing this exception actually 17:12:07 * j-rod finally starts paying attention 17:12:09 kde-settings has a fedorahosted.org SVN these days, but no tarballs. 17:12:17 tibbs: i agree... 17:12:22 Kevin_Kofler: that's fine. 17:12:23 there are a number of packages that don't use a url. For various reasons. 17:12:28 * skvidal tries to understand which direction to vote 17:12:36 I don't believe tarballs are in any way required in any case. 17:12:37 it's a tricky issue 17:12:38 are we voting to remove the exception? 17:12:42 perhaps we should ask the submitter to rewrite? 17:12:44 We export from SVN and make new-sources with the resulting tarball. 17:12:47 skvidal: i say defer 17:12:51 NEEDINFO 17:12:51 if I vote +1 am I in favor of the exception or in favor of removing the exception 17:12:59 Why is this necessary? 17:13:04 jds2001: agreed - and I don't think this is particularly pressing 17:13:07 skvidal: youre in favor of removing it. 17:13:08 +1 to removing the exception, there is no excuse not to publish tarballs 17:13:19 jds2001: I can't answer why it's necessary, sorry. 17:13:29 I don't know why Rahul wants this to go away. 17:13:33 Kevin_Kofler: you publish tarballs at http://cvs.fedoraproject.org/lookaside/pkgs/kde-settings/ 17:13:34 +1, no exception, you're not that special. :) 17:13:59 j-rod, for RH packages, or anything? 17:14:03 ("you" being nebulous, not anyone in particular...) 17:14:09 it's flawed as written 17:14:14 it needs clarification at best 17:14:20 notting: Sure, but that's the case for the packages covered by that exception as well. :-) 17:14:25 it is, if there's an exception it shouldnt be limited to RH 17:14:33 I probably need to re-read, I only vaguely recall details 17:14:40 You necessarily have something in the lookaside cache to build your SRPM. 17:14:43 I don't believe the current exception is limited to Red Hat. 17:14:57 Red Hat is used by way of example. 17:15:13 Rahul's draft is simply incorrect on that point, which I mentioned in the FEESo ticket. 17:15:36 it would also be nice to have a list of affected packages or how to identify them (can they be identified)? 17:15:42 tibbs, i know you noted it. i don't want to vote on something that has noted incorrect information 17:15:53 i tried last night, but it's hard :( 17:15:55 anyhow, I am 0 on this now, I want more info on it's goals and if it's RH specific, etc. 17:16:12 nirik: I don't believe it's easy to find packages which do this. 17:16:21 anyhow, shall we move on? 17:16:30 Technically they need a comment about it, but I doubt they all do and I doubt there's anything you could grep for. 17:16:36 right. Since no url could be us repackaging the source, or a vcs checkout, or other. 17:16:43 * notting is -1. i don't feel setting up a FH tarball repo is really any improvement over pointing people at cvs.fp.o/looksaide/ 17:17:24 though i'll laugh at the first package that actually puts that URL in their spec file 17:17:35 so let's defer. 17:17:38 notting: huh? 17:17:40 oh, hrm, if people can just fetch the tarball there... 17:18:03 notting: Source0 is supposed to be http:////tarball.tar.gz 17:18:06 Well, the source has to be in the package regardless, so sure, you can grab it from the lookaside. 17:18:22 jds2001: Only when that actually makes sense. 17:18:24 * j-rod gets it :) 17:18:31 jds2001: using the lookaside URL as the URL tag in their spec file 17:18:36 it could be that the intent here is to move projects to fedorahosted not just for the tar download, but for bugtracker, wiki, more active community, etc. 17:18:51 jds2001, and that url can be cvs.fp.org/lookaside/pkgs// 17:18:51 * nirik votes we ask mether to re-write and move on for now. 17:18:59 notting: oh yeah, I'd laugh at that to :) 17:19:08 nirik: yes, but forcing that on any project that may not have a current upstream is a bit out of our scope, i think 17:19:09 sounds good 17:19:15 notting: agreed. 17:19:17 jds2001, it illustrates how really silly this all is 17:19:29 FWIW, another case where a URL doesn't make sense is kde-apps.org/kde-look.org where they have strange?url=s&with=parameters. You can't give such a URL and have it be a valid Source0... 17:19:34 But that's already covered by the guidelines. 17:19:52 #agreed Proposal is deferred until additional information can be obtained. 17:20:04 I'll update the ticket with the concerns later 17:20:10 ok, so clarification on what upstreams this should actually apply to definitely needed 17:20:21 yep 17:20:29 #topic FPC report 17:20:33 .fesco 232 17:21:13 i need to read these.... 17:21:37 one at a time? 17:21:40 yeah 17:21:46 dos2unix im +1 on 17:21:51 https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix 17:21:55 +1 17:21:56 +1 on dos2unix. No brainer. 17:22:00 * notting is +1 to this. 17:22:10 +1 from me too, makes a lot of sense and FC3 is dead. 17:22:11 +1 dos2unix 17:22:13 +1 17:22:45 +1 17:23:13 ? on the autoprovides/req filtering 17:23:18 the summary says 17:23:30 MUST: When filtering automatically generated RPM dependency information, the filtering system implemented by Fedora must be used, except where there is a compelling reason to deviate from it. 17:23:37 #agreed dos2unix draft is approved 17:23:43 how will a "compelling reason" be defined? 17:23:49 skvidal: that means the macros below 17:23:59 skvidal: reviewer discretion, I guess 17:24:02 I'm confused by the "These filtering macros MUST only be used with packages which meet the following criteria: ..." part. 17:24:24 There are several packages currently using Provides/Requires filtering which don't fulfill those criteria. 17:24:26 For example xchat. 17:24:52 The issue is that you break multilib when you disable the internal dependency generator. 17:25:13 Also some packages which should use such filtering, like the KDE packages with plugins which are mentioned in the rationale. 17:25:19 as i understand it, until we have a solution that honors multiarch coloring, this is not recommended for any package that may end up needing it, just to avoid things breaking by accident 17:25:36 you could do it in xchat, as long as you know enough to know that the subpackages that put things in %{_bindir} will never be multilib 17:25:50 i need to step away for a few min 17:25:54 but that's hard to put in a guideline, so it's more conservative by default 17:26:12 now, my concern is that by limiting it to noarch, you'll have no takers :) 17:26:29 Perl needs this all the time. 17:26:37 What do we do about the KDE packages with plugins? Just ignore the bogus Provides as we've always done until we have a solution for the multiarch coloring problem? 17:26:57 Any such solution is going to have to come from the RPM folks. 17:27:05 Or at least will require changes in RPM itself. 17:27:12 Understood. 17:27:45 so, i think the 'compelling reason' needs to explicitly list 'package does not meet the criteria listed below'. as i don't want to make those people *stop* filtering 17:27:53 " you could do it in xchat" -> But the guideline says I MUST NOT do it. :-( 17:28:30 Well, it says the macros are banned, but what xchat does now is the same done by hand. 17:29:18 * nirik wonders if the first MUST there could just be fixed by rpm only adding provides to .so's in the library path... 17:29:29 So you somehow know that xchat will never ever be multilib? 17:29:54 If you can tell us how you know that, we can modify the draft. 17:30:01 Well, there's no xchat-devel, but some people have asked for one to build plugins. 17:30:18 So we could end up with a mess. 17:30:34 Input given to FPC didn't indicate that a -devel package was required for something to be multilib. 17:31:09 tibbs: i, like kkofler, am concerned about the 'must'-ness of the proposal - i don't want to ban\ the people who cannot use it now 17:31:14 I suppose we could say it's acceptable if the package can never be multilib, without stating just how you'd know this. 17:31:21 It's trivial to remove the Provides filtering from xchat, but then we'll have xchat providing perl.so and python.so and xchat-tcl providing tcl.so. 17:31:53 (That's why the filtering got added in the first place.) 17:32:27 * nirik has another case in 'heartbeat'. :( It's not currently filtering, but perhaps it should be. 17:32:45 People generally don't like it when those things are in guidelines, but I don't think more than a couple of people actually understand the multilib driteria. 17:32:50 criteria. 17:32:54 can't we get rpm to not add those when the .so's are not in a 'standard' place? then people who need to add them in weird places could be the exception. 17:32:55 I think there are several affected packages which probably should be doing filtering. 17:33:06 E.g. pretty much any KDE packages including KParts or other KDE plugins. 17:33:09 nirik: likely 17:33:29 (That's most of the core KDE modules and a few third-party KDE applications.) 17:33:48 And you're certain that none of those packages will ever be multilib? 17:34:02 Most definitely not. 17:34:06 If you're not, the work needs to be directed at rpm to fix the underlying issue. 17:34:11 nirik: ld.so.conf.d could contain a file which magically makes your libraries part of the ystem 17:34:12 That's exactly how this solution is failing us. 17:34:27 So you know of a better solition? 17:34:29 So on one hand, we MUST filter and on the other hand we MUST NOT filter as we break multilib. 17:34:48 heartbeat is multilib. 17:35:17 The draft as presented avoids that issue. It is not as useful as the utopian solution that does not exist. If you wish to vote against it based on that, you have the option. 17:35:24 nirik: Some of the affected KDE packages are, too, at least the -libs subpackages are. 17:35:51 Maybe FESCo has the power to get the rpm folks to offer a better solution. FPC doesn't. 17:36:04 tibbs: that'd be nice :) 17:36:11 but unlikely to happen :) 17:36:44 So are there any unanswered questions relating to this draft that I could help with? 17:36:45 Has rdieter commented on the KDE plugins (in partly-multilib packages) issue during the FPC discussion? 17:36:45 We can certaintly request that the RPM folks tell us their preferred solution, though 17:37:52 I do not recall any discussion relating to KDE in the discussion. 17:38:09 redundandancy. 17:38:16 tibbs: is it possible to say 'mandatory to use this if your packages meet the criteria. if they do not, use this only if you Really Know What You're Doing"? 17:38:27 lame, i know. 17:38:32 It is certainly possible to do that. 17:38:38 Or what I suggested earlier. 17:39:12 But I believe that any allowance of this with multilib packages, or packages that could ever become multilib, can break the distro. 17:39:16 The rationale mentions KDE plugins as an example of stuff which should be filtered though (which is how that issue caught my attention). 17:39:25 yeah, a 'as long as none of your subpackages will ever be mutilib' is a fine clarification 17:40:02 with that, i'm +1 17:40:02 If you define every multilib conflict as "breaking the distro", our distro is very "broken". ;-) 17:40:14 The problem, as I understand it, is that a package can become multilib even though no changes are made to it via dependencies that are multilib. 17:40:15 There are still plenty of unfixed multilib conflicts. :-( 17:40:29 * nirik grumbles again about slaying multilib, then shuts up since that will never happen. 17:41:11 And as multilibs are not installed by default nowadays unless some 32-bit app requires them, most people don't notice most conflicts. 17:42:42 I guess I am +1 with the clarification... but we should press rpm devs for more changes there to help this. 17:42:48 Kevin_Kofler: umm 17:42:52 Kevin_Kofler: that's incorrect 17:42:53 nirik: Same here. 17:43:02 the default is to only install the "best" arch for the platform 17:43:08 that's been the default for quite some time 17:43:23 skvidal: That's what I mean. 17:43:36 multilibs are not installed by default 17:43:40 if I am on x86_64 17:43:44 and I run yum install foo 17:43:45 If you install e.g. wine or some proprietary app, it'll drag in the 32-bit libs, otherwise it won't. 17:43:56 and there exists foo.i386 and foo.x86_64 17:44:01 yum will not install foo.i386 17:44:04 * nirik thinks this is digressing. 17:44:07 I know. 17:44:09 and wine is i386 only 17:44:21 +1 begrudgingly, a la nirik 17:44:37 same here, +1 17:44:42 +1 i guess 17:45:23 that's at least 5 +1 17:45:36 * jds2001 was still counting, thanks j-rod :) 17:45:48 As for killing multilibs, a proposal for next week: restrict multilibs to wine, redhat-lsb and their dependencies. Rationale: way too much stuff which will never be needed multilib is multilib. The people who really need that stuff should just use the i?86 repo and deal with the conflicts. 17:46:08 Kevin_Kofler: write up a proposal. ;) 17:46:25 #agreed AutoProvidesAndRequiresFiltering is approved 17:46:31 next? 17:46:36 yes please 17:46:40 +1 to the clarifications on no bundled libraries 17:46:42 With clarification; I will submit this to FPC on wednesday. 17:47:01 +1 on no bundled libs 17:47:07 #info With clarification; tibbs will submit this to FPC on wednesday. 17:47:28 +1 no bundled libs. Makes sense and is good to note in the guidelines with rationale, etc. 17:47:30 +1 on no bundled libs, although the formatting on the list items has gone wonky 17:47:34 +1 17:47:43 IMHO it should be clarified to allow significantly modified libraries. 17:48:02 It's an unacceptable burden to force packages using such libraries to be ported to the system version. 17:48:03 it would be nice to have some way to identify existing packages with them, but I suppose we will just need to file the bugs as we see them. 17:48:09 Sometimes it's just even plain impossible. 17:48:15 Changes are made to libraries for a reason. 17:48:22 Kevin_Kofler, why can't those be packaged as forks? 17:48:26 Kevin_Kofler: you mean forked libraries ? 17:48:34 +1 i think there is no reason for any app to bundle libraries 17:48:36 nirik: Significantly-forked ones. 17:48:50 ugh 17:48:53 stop forking the libraries 17:48:56 Kevin_Kofler, so package the forked library for fedora... 17:49:05 jwb: What's the point of libfoo-fork-for-app1, libfoo-fork-for-app2 etc. packages? 17:49:14 (if nothing else uses the respective fork) 17:49:19 maybe people will stop forking shit then? 17:49:21 Kevin_Kofler: did you read the page? do you see why this is bad? 17:49:24 Kevin_Kofler: to make it clear people are doing dumb things 17:49:27 sorry, i redact my shit comment 17:49:45 * jwb hall monitors himself 17:50:01 nirik: The problem is that it's not our (the packagers') decision to fork the libraries. 17:50:24 Kevin_Kofler, it is their decision to package the package though. it's part of being a maintainer 17:50:25 And application developers are not going to let us interfere with how they develop stuff. 17:50:29 Kevin_Kofler: true, but we should work hard with upstream to fix things... not just blindly ship the forked internal copy. 17:50:31 * jds2001 sets jwb -v :D 17:50:35 They'll just end up in some third-party repository or we'll miss out on them entirely. 17:51:04 jwb: How do you "fix" such a package? 17:51:20 educate upstream 17:51:24 If it requires a forked library because it really requires the changes in the library, how do you suggest a packager handles that. 17:51:26 get them to send patches to the lib 17:51:28 you talk with both upstream for the package and the base library. 17:51:32 j-rod: Upstream won't let themselves be educated. 17:51:39 package the forked library as a fork, make the package use that. if they don't want to do that, try to work with upstream. if upstream doesn't care, then the burden is on them as the maintainer 17:51:41 They'll just go to another repository or ignore Fedora entirely. 17:51:42 that's not universally true 17:51:49 Kevin_Kofler: i think you have a very narrow world view here. 17:51:52 Kevin_Kofler: do you have a specific example? or are you just playing devils advocate here? 17:52:07 Some packages with forked libs are already in Fedora. 17:52:13 Audacity has a forked PortAudio. 17:52:20 It will not work at all without the patches. 17:52:20 they are, and they need to be repaired. 17:52:24 are bugs filed? 17:52:27 sounds like an audit is required 17:52:32 I note that this draft includes only rationale. 17:52:38 It's not changing any policy at all. 17:52:44 yes, nothing is actually changing. 17:52:47 * nirik nods. 17:52:49 nirik: I filed a bug, it was closed as NOTABUG as it cannot be fixed. 17:52:59 was effort made to resolve it? 17:53:04 And PortAudio's upstream is almost dead. 17:53:04 with both upstreams? 17:53:05 well, that is an incorrect resolution 17:53:17 Kevin_Kofler: it should be reopened and blocking the bug in the page there. 17:53:19 maintainer fail 17:53:20 jwb: Well, it could be CANTFIX too. 17:53:32 then they should request an exception from fesco. 17:53:33 also an incorrect resolution 17:53:50 PortAudio didn't reply to my patch to support non-mmap ALSA at all either. 17:53:55 Fedora is now carrying that as a patch. 17:53:59 Upstream is basically dead. 17:54:08 Good luck getting them to merge Audacity's invasive patch. 17:54:10 the correct resolution for someone that is not following guidelines because it would incur additional work is CLOSED->LAZY 17:54:28 jwb: It doesn't just incur additional work, it is IMPOSSIBLE. 17:54:35 no it's not 17:54:37 The application just plain WILL NOT WORK with the unpatched library. 17:54:38 bug 471782 17:54:39 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=471782 medium, medium, ---, gemi, CLOSED NOTABUG, Please build audacity against the system portaudio 17:54:51 Kevin_Kofler, so the maintainer packages the forked library and makes the package use that 17:54:55 that is not IMPOSSIBLE 17:55:07 The name, soname etc. will conflict. 17:55:09 portaudio is dead upstream? so, why not just drop it 17:55:15 * jds2001 doesnt get the point of the discussion about adding a few paragraphs of reasoning.\ 17:55:21 Kevin_Kofler, not if properly forked 17:55:24 Unless they make it static only, then only -devel will conflict, but that's also against the guidelines. 17:55:25 we are WAY off topic. 17:55:42 The point is that libraries forked by applications are NEVER properly forked. 17:55:47 They won't change the name or anything. 17:55:55 They just patch it and link it in statically in one way or the other. 17:55:57 there will be times when nothing can be done. Then the package should be removed or a exception granted by fesco 17:56:15 but all other avenues should be followed first. 17:56:22 Shall we vote on adding the few paragraphs? 17:56:31 upstream portaudio seems to not be dead from what I can see 17:56:34 +1 17:56:44 +1, makes sense I agree with it. 17:56:45 they had some issues, but look to be moving again 17:56:47 We shall vote to remove the "clarifications" on forking and explicitly allowing forked libs instead. 17:56:58 -1 17:57:01 s/allowing/allow/ 17:57:27 allowing forked bundled libs should be the very very very last resort. 17:57:35 what are we voting on 17:57:52 jwb: adding the paragraphs. 17:57:54 jwb: I have no idea at this point 17:57:57 to which im +1 17:58:09 jds2001: but you just said -1 17:58:11 the FPC rationale at: https://fedoraproject.org/wiki/No_Bundled_Libraries 17:58:12 didn't you? 17:58:18 skvidal: to Kevin_Kofler's proposal 17:58:20 +1 allowing forked/bundled libs should not happen. at least not without a plan to unfork/unbundle 17:58:32 +1 to the PFC link above here. 17:58:39 +1 17:58:54 +1 for the fpc thing 17:59:02 * notting reaffirms his +1 vote to the proposal 17:59:09 +1 for the fpc guidelines 17:59:12 0 - the clarifications are good in principle, but I don't agree with the details on forking 17:59:16 #agreed Clarification on no bundled libraries is approved. 17:59:30 +1 for the FPC guidelines 17:59:38 next for removing prebuilt binaries. 17:59:51 this proposal makes sense, +1 17:59:57 * jds2001 reads it as 17:59:58 yeah, seems sane 18:00:00 +1 18:00:04 'remove them during %prep' 18:00:31 +1 18:00:37 so i have a dumb question 18:00:44 it seems a bit odd to have FPC approve exceptions. 18:00:46 does this include pre-generated configure scripts? 18:00:52 because OMG pain... 18:00:54 since fesco does all the other exceptions it seems like. 18:00:58 jwb: explicitly not 18:01:00 I think. 18:01:13 * jds2001 doesn't see that as a "program binary" 18:01:21 * nirik notes the BinaryFirmware link is broken/nonexistant there. 18:01:21 configure is a program? 18:01:24 +1, this is much better than the one that was proposed before 18:01:32 but maybe tibbs can clarify on that 18:01:32 jwb: configure is PAIN 18:01:33 configure is executable. 18:01:36 jwb: not a very good one. 18:01:40 +1 18:01:40 "Is it executable? If so, it is probably a program binary." 18:01:41 +1 18:01:49 notting, pjones: beside the point 18:01:54 jwb: configure is a shell script 18:02:07 notting, look at the criteria in the proposal... 18:02:07 It certainly wasn't the intention to somehow force removal of configure scripts. 18:02:12 having prebuilt binaries and shard objects is bad 18:02:15 perhaps there should be some additional guidance using 'file' 18:02:18 "is it executable? if so, it's probably a program binary" 18:02:29 The old guidelines weren't any different there though. 18:02:34 Ive had sparc builds fail trying to link x86 objects to sparc ones 18:02:38